| | 144 | * Designs |
| | 145 | * The Designs relationship links architects to buildings they designed. Modeled as many-to-many because projects often involve multiple architects, and architects work on multiple buildings. |
| | 146 | * Cardinality: Many-to-Many (M:N) |
| | 147 | * Participation: Partial on both sides. |
| | 148 | |
| | 149 | * Has (Building-Floor) |
| | 150 | * The Has relationship represents floors contained within buildings. Each floor belongs to exactly one building, while buildings contain multiple floors. |
| | 151 | * Cardinality: One-to-Many (1:N) |
| | 152 | * Participation: Total on Floor side because every floor needs a building, partial on Building side buildings under construction may lack final floor definitions. |
| | 153 | |
| | 154 | * Has (Unit-Floor) |
| | 155 | * The Has relationship represents units contained within floors. Each unit is on exactly one floor (in most real world scenarios the unit can span multiple floors but it has a door on one floor only), while floors contain multiple units. |
| | 156 | * Cardinality: One-to-Many (1:N) |
| | 157 | * Participation: Total on Unit side (every unit needs a floor), partial on Floor side (may lack unit definition in early stages of construction). |
| | 158 | |
| | 159 | * Manages (Admin-Building) |
| | 160 | * The Manages relationship indicates which admin created and manages a building. Each building has one managing admin for clear accountability, while admins manage multiple buildings. Necessary for access control. |
| | 161 | * Cardinality: One-to-Many (1:N) |
| | 162 | * Participation: Total on Building side, partial on Admin side. |
| | 163 | |
| | 164 | * Manages (Admin-Floor) |
| | 165 | * The Manages relationship indicates which admin created and manages a floor. Each floor has one managing admin responsible for floor details and layout images, while admins manage multiple floors. |
| | 166 | * Cardinality: One-to-Many (1:N) |
| | 167 | * Participation: Total on Floor side, partial on Admin side. |
| | 168 | |
| | 169 | * Manages (Admin-Unit) |
| | 170 | * The Manages relationship indicates which admin created and manages a unit. Each unit has one managing admin for accountability on pricing and availability, while admins manage multiple units. |
| | 171 | * Cardinality: One-to-Many (1:N) |
| | 172 | * Participation: Total on Unit side, partial on Admin side. |
| | 173 | |
| | 174 | * About |
| | 175 | * The About relationship indicates which unit the inquiry is about. Each inquiry adheres to one unit, while units can receive multiple inquiries. Enables filtering inquiries by unit. |
| | 176 | * Cardinality: One-to-Many (1:N) |
| | 177 | * Participation: Total on Inquiry side, partial on Unit side. |
| | 178 | |
| | 179 | * Makes |
| | 180 | * The Makes relationship indicates which client submitted an inquiry. Each inquiry has one submitter, while clients can make multiple inquiries. |
| | 181 | * Cardinality: One-to-Many (1:N) |
| | 182 | * Participation: Total on Inquiry side, partial on Client side. |
| | 183 | |
| | 184 | * Responds |
| | 185 | * The Responds relationship indicates which agent handles an inquiry. Each inquiry has one assigned agent to ensure accountability, while agents handle multiple inquiries. |
| | 186 | * Cardinality: One-to-Many (1:N) |
| | 187 | * Participation: Total on Inquiry side, partial on Agent side. |
| | 188 | |
| | 189 | * Books |
| | 190 | * The Books relationship indicates which client scheduled an appointment. Each appointment has one booker, while clients can book multiple appointments. Necessary for enabling appointment management. |
| | 191 | * Cardinality: One-to-Many (1:N) |
| | 192 | * Participation: Total on Appointment side, partial on Client side. |
| | 193 | |
| | 194 | * Viewing |
| | 195 | * The Viewing relationship indicates which unit is shown during an appointment. Each appointment shows one unit, while units can have multiple viewings. |
| | 196 | * Cardinality: One-to-Many (1:N) |
| | 197 | * Participation: Total on Appointment side, partial on Unit side. |
| | 198 | |
| | 199 | * Conducts |
| | 200 | * The Conducts relationship indicates which agent conducts an appointment. Each appointment has one conducting agent, while agents conduct multiple appointments. Necessary for scheduling appointments. |
| | 201 | * Cardinality: One-to-Many (1:N) |
| | 202 | * Participation: Total on Appointment side, partial on Agent side. |
| | 203 | |
| | 204 | * Provides |
| | 205 | * The Provides relationship indicates which agent created a timeslot. Each timeslot has one managing agent who controls their availability, while agents create multiple timeslots across different times. |
| | 206 | * Cardinality: One-to-Many (1:N) |
| | 207 | * Participation: Total on Timeslot side, partial on Agent side. |
| | 208 | |
| | 209 | * Scheduled_at |
| | 210 | * The Scheduled_at relationship links appointments to timeslots. Each appointment occurs at one timeslot, and each timeslot accommodates one appointment maximum to prevent double-booking. When appointments are created, timeslot status changes to "Booked". |
| | 211 | * Cardinality: One-to-One (1:1) |
| | 212 | * Participation: Total on Appointment side, partial on Timeslot side. |
| | 213 | |
