No history yet

Архитектура отельной БД

Проектирование реляционной схемы

Основа любой системы управления отелем (PMS) — это ее база данных. Правильно спроектированная схема не просто хранит информацию, а обеспечивает целостность данных и высокую производительность. Она должна отражать реальные бизнес-процессы: от управления номерным фондом до обработки бронирований.

Мы будем использовать PostgreSQL, мощную реляционную СУБД, идеально подходящую для сложных запросов и обеспечения надежности транзакций. Вместо написания SQL-запросов вручную, мы воспользуемся SQLAlchemy — ORM (Object-Relational Mapper) для Python. Это позволит нам работать с базой данных через привычные классы Python, что значительно ускоряет разработку и делает код более читаемым.

Основными сущностями в нашей системе будут типы номеров, сами номера, гости и бронирования. Давайте рассмотрим, как связать их в единую логическую структуру.

Типы номеров и сами номера

В любом отеле есть разные категории номеров: «Стандарт», «Люкс», «Семейный». Это — типы номеров (RoomType). У каждого типа есть свои характеристики: цена, вместимость, описание. Каждый физический номер в отеле, например, комната 101 или 205, относится к определенному типу. Это и есть сущность Room.

Таким образом, между RoomType и Room возникает связь «один ко многим»: один тип номера может соответствовать множеству физических номеров. Но каждый конкретный номер может принадлежать только одному типу.

В коде SQLAlchemy эти отношения описываются с помощью ForeignKey и relationship. Поле room_type_id в модели Room является внешним ключом, который ссылается на первичный ключ в RoomType. Атрибут status в Room крайне важен для операционной деятельности: он показывает, свободен ли номер, занят, или находится на уборке.

from sqlalchemy import Column, Integer, String, Numeric, ForeignKey
from sqlalchemy.orm import relationship, declarative_base

Base = declarative_base()

class RoomType(Base):
    __tablename__ = 'room_types'
    
    id = Column(Integer, primary_key=True)
    name = Column(String, nullable=False)
    price_per_night = Column(Numeric(10, 2), nullable=False)
    
    rooms = relationship("Room", back_populates="room_type")

class Room(Base):
    __tablename__ = 'rooms'
    
    id = Column(Integer, primary_key=True)
    room_number = Column(String, nullable=False, unique=True)
    # Статус: 'available', 'occupied', 'cleaning', 'out_of_order'
    status = Column(String, nullable=False, default='available')
    
    room_type_id = Column(Integer, ForeignKey('room_types.id'))
    room_type = relationship("RoomType", back_populates="rooms")

Моделирование бронирований

Бронирование (Booking) — это центральная сущность системы, связывающая гостя (Guest) с конкретным номером (Room) на определенный период времени. Здесь у нас несколько связей:

  • Booking и Guest: Один гость может совершить много бронирований. Это связь «один ко многим».
  • Booking и Room: Один номер может быть забронирован много раз (в разное время). Это также связь «один ко многим».

Модель Booking должна содержать даты заезда и выезда, ссылки на гостя и номер, а также свой собственный статус. Статус бронирования ('confirmed', 'checked_in', 'checked_out', 'cancelled') позволяет отслеживать жизненный цикл каждого заказа и является ключевым для бизнес-логики, например, для автоматического изменения статуса номера при заезде гостя.

Важнейшая задача схемы — предотвратить двойное бронирование одного и того же номера на пересекающиеся даты. Это достигается с помощью ограничений на уровне базы данных, например, с использованием EXCLUDE в PostgreSQL, и валидации на уровне приложения.

from sqlalchemy import Date, Enum
# ... (предыдущие импорты и модели)

class Guest(Base):
    __tablename__ = 'guests'

    id = Column(Integer, primary_key=True)
    first_name = Column(String, nullable=False)
    last_name = Column(String, nullable=False)
    email = Column(String, unique=True, index=True)

    bookings = relationship("Booking", back_populates="guest")

class Booking(Base):
    __tablename__ = 'bookings'

    id = Column(Integer, primary_key=True)
    check_in_date = Column(Date, nullable=False)
    check_out_date = Column(Date, nullable=False)
    
    status = Column(
        Enum('confirmed', 'checked_in', 'checked_out', 'cancelled', name='booking_status_enum'),
        nullable=False,
        default='confirmed'
    )

    room_id = Column(Integer, ForeignKey('rooms.id'))
    guest_id = Column(Integer, ForeignKey('guests.id'))

    room = relationship("Room")
    guest = relationship("Guest", back_populates="bookings")

Взглянув на полную схему, мы видим, как все части системы связаны между собой. RoomType определяет свойства для Room. Room и Guest объединяются через Booking, создавая полную картину заказа.

Индексация и производительность

Когда в базе данных накопятся тысячи бронирований, скорость поиска станет критически важной. Представьте, что вам нужно мгновенно найти все свободные номера «Люкс» на следующей неделе. Без правильной индексации такой запрос будет медленно сканировать всю таблицу бронирований.

Чтобы этого избежать, необходимо создавать индексы. Индексы — это специальные структуры данных, которые позволяют базе данных быстро находить строки по значениям в определенных столбцах. В нашей схеме наиболее важными кандидатами для индексации являются:

  • Даты заезда и выезда (check_in_date, check_out_date) в таблице Booking. Это ускорит поиск доступных номеров в заданном диапазоне дат.
  • Внешние ключи (room_id, guest_id, room_type_id). PostgreSQL автоматически создает индексы для первичных ключей, но для внешних ключей это хорошая практика.
  • Поля статусов (status) в таблицах Room и Booking, так как по ним часто будет производиться фильтрация.
  • Email гостя (email) для быстрого поиска клиентов.

Создание продуманной схемы — это только первый шаг. Для управления изменениями в этой схеме по мере развития проекта используются инструменты миграций, такие как Alembic. Он позволяет версионировать структуру базы данных так же, как мы версионируем код с помощью Git.

Quiz Questions 1/5

Какая связь существует между сущностями RoomType (тип номера) и Room (номер) в схеме базы данных отеля?

Quiz Questions 2/5

Какова основная цель поля status (например, 'confirmed', 'checked_in') в таблице Booking?

Эта структура базы данных является надежным фундаментом для создания полнофункциональной системы управления отелем. Она обеспечивает целостность данных и готова к масштабированию.