Changes between Version 3 and Version 4 of RelationModel


Ignore:
Timestamp:
06/08/26 21:55:08 (12 days ago)
Author:
231085
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • RelationModel

    v3 v4  
    183183- `uploaded_at` — datetime, required.
    184184
    185 == Availability
    186 Represents a window of time during which a specific room is offered (or explicitly blocked). It is modeled as its own entity so that availability rules can vary per room and over time, and so the system can validate bookings against concrete windows rather than implicit assumptions.
    187 
    188 **Candidate keys:**
    189 - `availability_id` — surrogate primary key.
    190 
    191 **Attributes:**
    192 - `availability_id` — numeric, required.
    193 - `room_id` — numeric, required. The room this window applies to.
    194 - `available_from` — date, required.
    195 - `available_to` — date, required. Must be ≥ `available_from`.
    196 - `available_time_from` — datetime, required.
    197 - `avaliable_time_to` — datetime, required.
    198 - `is_available` — boolean, required. `TRUE` for open windows, `FALSE` for blocked windows.
    199 - `description` — text, optional.
     185== AvailabilityBlock
     186Represents a period during which a specific room is unavailable. Typical examples include maintenance, cleaning, renovations or host-defined unavailable periods.
     187
     188**Candidate keys:**
     189- `unavailability_id` — surrogate primary key.
     190
     191**Attributes:**
     192- `unavailability_id` — numeric, required.
     193- `room_id` — numeric, required. The room this applies to.
     194- `blocked_from` — date, required.
     195- `blocked_to` — date, required. Must be ≥ `blocked_from`.
     196- `blocked_time_from` — datetime, required.
     197- `blocked_time_to` — datetime, required.
     198- `description` — text, optional.
     199
     200== AvailabilityWindow
     201Represents a specific date on which a room is available for booking. This is used to explicitly store room availability.
     202
     203**Candidate keys:**
     204- `availability_window_id` — surrogate primary key.
     205
     206**Attributes:**
     207- `availability_window_id` — numeric, required.
     208- `room_id` — numeric, required. The room this applies to.
     209- `available_date` — date, required.
     210- `status` — text, required.
    200211
    201212== Booking
     
    299310
    300311== CancellationPolicy
    301 Represents the refund rules that a property applies when a booking is cancelled. It is modeled as a reusable entity because the same policy can be attached to multiple properties via the join table `CancellationPolicy_Property`.
     312Represents the cancellation and refund rules applied to a specific property. The policy determines how much of the booking amount is refunded depending on when the cancellation occurs.
    302313
    303314Candidate keys:
     
    386397----
    387398
    388 `applies_to (Availability – Booking)` [[BR]]
    389 Links bookings to the availability windows they consume. Modeled as M–N through the join table `Availability_Booking`, since a booking may span more than one availability window and a window may contain multiple bookings (on different sub-dates).
    390 
    391 ----
    392 
    393399`paid_with (Booking – Payment)` [[BR]]
    394400Represents the financial settlement of a booking. Modeled as N–1: multiple bookings can be associated with a single payment (e.g., batch payments), while each booking references one payment. Implemented through `booking_id` in `Payment` (and a back-reference in `Booking`).
     
    439445Represents that a user receives notifications. Modeled as 1–N: each notification belongs to exactly one user, while a user can receive many. Implemented via `user_id` in `Notification`.
    440446
    441 ----
    442 
    443 `governs (CancellationPolicy – Property)` [[BR]]
    444 Represents that a cancellation policy governs the refund rules of a property. Modeled as M–N through the join table `CancellationPolicy_Property`, since a single policy can be reused across many properties and a property can fall under multiple policies (e.g. seasonal variations).
    445447
    446448= Business rules and constraints
     
    449451
    450452- A user becomes a `Host` only after one of their `HostApplication` records has `status = APPROVED` and a `reviewed_by_admin_id`.
    451 - A `Booking` may only be created on a `Room` whose `Availability` covers the requested `[check_in_date, check_out_date)` and whose status is `AVAILABLE`.
     453- A `Booking` may only be created on a `Room` whose `AvailabilityWindow` covers the requested `[check_in_date, check_out_date)` and whose status is `AVAILABLE`.
    452454- `guests_count` on a `Booking` must not exceed `Room.capacity + Room.extra_capacity`.
    453455- A `Review` may be created only if the underlying `Booking` belongs to the same `guest_id` and has `booking_status = COMPLETED`.