Changes between Version 6 and Version 7 of ERModel


Ignore:
Timestamp:
06/09/26 14:13:53 (12 days ago)
Author:
223091
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ERModel

    v6 v7  
    1 = Entity-Relationship Model v01 =
     1= Entity-Relationship Model v.01 =
    22
    33== Diagram ==
     
    55[[Image(ERModel_v01.png, width=100%)]]
    66
     7A full-page width image of the latest version of the entity-relationship diagram is shown above.
     8
    79(Attached files: ''ERModel_v01.xml'' and ''ERModel_v01.png'')
    810
    911== Data requirements ==
    1012
     13This section lists all entity sets and relationships included in the entity-relationship model. For each entity set, the description, candidate keys, selected primary key, attributes, data types, and restrictions are documented. For each relationship, the meaning, cardinality, and participation constraints are described.
     14
    1115=== Entities ===
    1216
    1317==== Buildings ====
    14 *'''Description:''' Represents a physical building that contains multiple reservable rooms.
    15 *'''Candidate keys:'''
    16  * building_id (selected as primary key because it is stable and guaranteed to be unique)
    17  * (optional candidate) (name, address) if institutional rules guarantee uniqueness; however, this is not considered sufficiently reliable and therefore not selected
    18 *'''Attributes:'''
    19  * ''building_id'' (NUMBER or NUMBER(9,2)) – required, unique identifier (PK)
    20  * ''name'' (VARCHAR2(128)) – required
    21  * ''address'' (VARCHAR2(128)) – required
     18
     19'''Description:''' Buildings represents physical buildings that contain multiple reservable rooms. This entity is needed because rooms are located in specific buildings, and the system must be able to group rooms by their physical location.
     20
     21'''Candidate keys:'''
     22
     23* building_id – selected as the primary key because it is stable and guaranteed to be unique.
     24* (name, address) – possible candidate key only if institutional rules guarantee uniqueness, but it is not sufficiently reliable and therefore it is not selected as the primary key.
     25
     26'''Attributes:'''
     27
     28* ''building_id'' (NUMBER or NUMBER(9,2)) – required, unique identifier, primary key.
     29* ''name'' (VARCHAR2(128)) – required, building name.
     30* ''address'' (VARCHAR2(128)) – required, physical address or location description of the building.
    2231
    2332==== Rooms ====
    24 *'''Description:''' Represents a reservable room (e.g., classroom, office, meeting room, lab) located in exactly one building.
    25 *'''Candidate keys:'''
    26  * room_id (selected as primary key because it is stable and unique)
    27  * room_code (candidate key if guaranteed to be unique across the organization)
    28 *'''Attributes:'''
    29  * ''room_id'' (VARCHAR2(128) or NUMBER) – required, unique identifier (PK)
    30  * ''room_code'' (VARCHAR2(128)) – required; recommended UNIQUE constraint
    31  * ''capacity'' (NUMBER) – required; constraint: capacity > 0
    32  * ''type'' (VARCHAR2(128)) – required; suggested domain: {classroom, office, meeting_room, lab, ...}
     33
     34'''Description:''' Rooms represents reservable rooms such as classrooms, offices, meeting rooms, or laboratories. Each room is located in exactly one building and can be reserved by users for specific dates and time intervals.
     35
     36'''Candidate keys:'''
     37
     38* room_id – selected as the primary key because it is stable and unique.
     39* room_code – candidate key if it is guaranteed to be unique across the organization.
     40
     41'''Attributes:'''
     42
     43* ''room_id'' (VARCHAR2(128) or NUMBER) – required, unique identifier, primary key.
     44* ''room_code'' (VARCHAR2(128)) – required, recommended to be unique.
     45* ''capacity'' (NUMBER) – required, must be greater than 0.
     46* ''type'' (VARCHAR2(128)) – required, suggested domain: {classroom, office, meeting_room, lab, ...}.
    3347
    3448==== Equipment ====
    35 *'''Description:''' Represents a type of equipment that may exist in rooms (e.g., projector, whiteboard, microphone).
    36 *'''Candidate keys:'''
    37  * equipment_id (selected as primary key)
    38  * name (candidate only if guaranteed unique; typically not guaranteed)
    39 *'''Attributes:'''
    40  * ''equipment_id'' (VARCHAR2(128) or NUMBER) – required, unique identifier (PK)
    41  * ''name'' (VARCHAR2(128)) – required
     49
     50'''Description:''' Equipment represents types of equipment that may be available in rooms, such as projectors, whiteboards, microphones, or computers. This entity is needed so that equipment can be managed independently and assigned to different rooms.
     51
     52'''Candidate keys:'''
     53
     54* equipment_id – selected as the primary key because it is stable and unique.
     55* name – possible candidate key only if equipment names are guaranteed to be unique, but this is usually not guaranteed.
     56
     57'''Attributes:'''
     58
     59* ''equipment_id'' (VARCHAR2(128) or NUMBER) – required, unique identifier, primary key.
     60* ''name'' (VARCHAR2(128)) – required, name of the equipment type.
    4261
    4362==== !RoomEquipment ====
    44 *'''Description:''' Associative entity that models the many-to-many relationship between Rooms and Equipment. It stores the quantity of a specific equipment type available in a room.
    45 *'''Candidate keys:'''
    46  * (room_id, equipment_id) – selected as primary key (natural composite key)
    47 *'''Attributes:'''
    48  * ''room_id'' (FK reference to Rooms) – required
    49  * ''equipment_id'' (FK reference to Equipment) – required
    50  * ''quantity'' (NUMBER) – required; constraint: quantity ≥ 0 (typically > 0 when present)
     63
     64'''Description:''' !RoomEquipment is an associative entity that models the many-to-many relationship between Rooms and Equipment. It stores information about which equipment type is available in which room and in what quantity.
     65
     66'''Candidate keys:'''
     67
     68* (room_id, equipment_id) – selected as the primary key because the same equipment type should appear only once for the same room.
     69
     70'''Attributes:'''
     71
     72* ''room_id'' (FK reference to Rooms) – required, part of the composite primary key.
     73* ''equipment_id'' (FK reference to Equipment) – required, part of the composite primary key.
     74* ''quantity'' (NUMBER) – required, must be greater than or equal to 0; normally greater than 0 when an equipment entry exists.
    5175
    5276==== Users ====
    53 *'''Description:''' Represents system users who can create reservations and, if authorized, approve or reject them.
    54 *'''Candidate keys:'''
    55  * user_id (selected as primary key)
    56  * username (candidate key; must be unique)
    57  * email (candidate key; must be unique)
    58 *'''Attributes:'''
    59  * ''user_id'' (VARCHAR2(128) or NUMBER) – required, unique identifier (PK)
    60  * ''username'' (VARCHAR2(128)) – required; UNIQUE constraint recommended
    61  * ''email'' (VARCHAR2(128)) – required; UNIQUE constraint recommended; must follow standard email format
    62  * ''full_name'' (VARCHAR2(128)) – required
    63  * ''role'' (VARCHAR2(128)) – required; suggested domain: {regular, admin, approver}
     77
     78'''Description:''' Users represents people who have access to the reservation system. Users can create reservations, and users with appropriate roles can approve or reject reservation requests.
     79
     80'''Candidate keys:'''
     81
     82* user_id – selected as the primary key because it is stable and unique.
     83* username – candidate key because usernames should be unique.
     84* email – candidate key because email addresses should be unique.
     85
     86'''Attributes:'''
     87
     88* ''user_id'' (VARCHAR2(128) or NUMBER) – required, unique identifier, primary key.
     89* ''username'' (VARCHAR2(128)) – required, recommended to be unique.
     90* ''email'' (VARCHAR2(128)) – required, recommended to be unique, must follow a valid email format.
     91* ''full_name'' (VARCHAR2(128)) – required, full name of the user.
     92* ''role'' (VARCHAR2(128)) – required, suggested domain: {regular, admin, approver}.
    6493
    6594==== Reservations ====
    66 *'''Description:''' Represents a reservation request made by a user for a specific room, date, and time interval. The system must prevent overlapping reservations for the same room and time interval.
    67 *'''Candidate keys:'''
    68  * reservation_id (selected as primary key)
    69  * (room_id, reservation_date, start_time, end_time) may form a natural candidate key under strict business constraints; however, a surrogate primary key is preferred
    70 *'''Attributes:'''
    71  * ''reservation_id'' (VARCHAR2(128) or NUMBER) – required, unique identifier (PK)
    72  * ''reservation_date'' (DATE) – required
    73  * ''start_time'' (DATE or TIME representation) – required
    74  * ''end_time'' (DATE or TIME representation) – required; constraint: end_time > start_time
    75  * ''status'' (VARCHAR2(128)) – required; suggested domain: {pending, approved, rejected, cancelled}
     95
     96'''Description:''' Reservations represents reservation requests made by users for specific rooms, dates, and time intervals. This entity is central to the system because it stores when and by whom a room is reserved. The system must prevent overlapping reservations for the same room and time interval.
     97
     98'''Candidate keys:'''
     99
     100* reservation_id – selected as the primary key because it is stable and unique.
     101* (room_id, reservation_date, start_time, end_time) – may form a natural candidate key under strict business constraints, but a surrogate primary key is preferred for easier referencing.
     102
     103'''Attributes:'''
     104
     105* ''reservation_id'' (VARCHAR2(128) or NUMBER) – required, unique identifier, primary key.
     106* ''reservation_date'' (DATE) – required, date of the reservation.
     107* ''start_time'' (DATE or TIME representation) – required, start time of the reservation.
     108* ''end_time'' (DATE or TIME representation) – required, must be greater than start_time.
     109* ''status'' (VARCHAR2(128)) – required, suggested domain: {pending, approved, rejected, cancelled}.
    76110
    77111==== Approvals ====
    78 *'''Description:''' Represents an approval decision for a reservation, created by an authorized user (admin/approver). Each approval records the decision, decision time, and an optional note.
    79 *'''Candidate keys:'''
    80  * approval_id (selected as primary key)
    81  * reservation_id may be unique if the business rule enforces at most one approval per reservation
    82 *'''Attributes:'''
    83  * ''approval_id'' (VARCHAR2(128) or NUMBER) – required, unique identifier (PK)
    84  * ''decision'' (VARCHAR2(128)) – required; suggested domain: {approved, rejected}
    85  * ''decision_time'' (DATE) – required
    86  * ''note'' (VARCHAR2(128)) – optional
     112
     113'''Description:''' Approvals represents approval decisions for reservations. An approval is created by an authorized user, such as an administrator or approver. This entity stores the decision, decision time, and an optional note.
     114
     115'''Candidate keys:'''
     116
     117* approval_id – selected as the primary key because it is stable and unique.
     118* reservation_id – may be unique if the business rule enforces at most one approval per reservation.
     119
     120'''Attributes:'''
     121
     122* ''approval_id'' (VARCHAR2(128) or NUMBER) – required, unique identifier, primary key.
     123* ''decision'' (VARCHAR2(128)) – required, suggested domain: {approved, rejected}.
     124* ''decision_time'' (DATE) – required, date and time when the decision was made.
     125* ''note'' (VARCHAR2(128)) – optional, additional explanation for the decision.
    87126
    88127=== Relationships ===
    89128
    90129==== has (Buildings–Rooms) ====
    91 *'''Meaning:''' A building contains rooms.
    92 *'''Cardinality:''' Buildings (1) — Rooms (N)
    93 *'''Participation:'''
    94  * Room participation is total (each room must belong to exactly one building).
    95  * Building participation is partial (a building may contain zero or more rooms).
     130
     131'''Meaning:''' The relationship has connects Buildings and Rooms. It shows that a building contains rooms.
     132
     133'''Cardinality:''' Buildings (1) — Rooms (N)
     134
     135'''Participation:'''
     136
     137* Room participation is total because each room must belong to exactly one building.
     138* Building participation is partial because a building may contain zero or more rooms.
    96139
    97140==== contains (Rooms–!RoomEquipment) ====
    98 *'''Meaning:''' A room contains equipment entries with associated quantities.
    99 *'''Cardinality:''' Rooms (1) — !RoomEquipment (N)
    100 *'''Participation:'''
    101  * !RoomEquipment participation is total (each entry must refer to exactly one room).
    102  * Room participation is partial (a room may have no equipment registered).
     141
     142'''Meaning:''' The relationship contains connects Rooms and !RoomEquipment. It shows that a room may contain registered equipment entries with quantities.
     143
     144'''Cardinality:''' Rooms (1) — !RoomEquipment (N)
     145
     146'''Participation:'''
     147
     148* !RoomEquipment participation is total because each equipment entry must refer to exactly one room.
     149* Room participation is partial because a room may have no equipment registered.
    103150
    104151==== used_in (Equipment–!RoomEquipment) ====
    105 *'''Meaning:''' Equipment types appear in room-equipment entries.
    106 *'''Cardinality:''' Equipment (1) — !RoomEquipment (N)
    107 *'''Participation:'''
    108  * !RoomEquipment participation is total (each entry must refer to exactly one equipment type).
    109  * Equipment participation is partial (an equipment type may exist without being assigned to any room).
     152
     153'''Meaning:''' The relationship used_in connects Equipment and !RoomEquipment. It shows that an equipment type can be used in room-equipment entries.
     154
     155'''Cardinality:''' Equipment (1) — !RoomEquipment (N)
     156
     157'''Participation:'''
     158
     159* !RoomEquipment participation is total because each entry must refer to exactly one equipment type.
     160* Equipment participation is partial because an equipment type may exist without being assigned to any room.
    110161
    111162==== is_reserved_for (Rooms–Reservations) ====
    112 *'''Meaning:''' Each reservation is made for exactly one room.
    113 *'''Cardinality:''' Rooms (1) — Reservations (N)
    114 *'''Participation:'''
    115  * Reservation participation is total (each reservation must specify a room).
    116  * Room participation is partial (a room may have zero reservations).
     163
     164'''Meaning:''' The relationship is_reserved_for connects Rooms and Reservations. It shows that each reservation is made for one specific room.
     165
     166'''Cardinality:''' Rooms (1) — Reservations (N)
     167
     168'''Participation:'''
     169
     170* Reservation participation is total because each reservation must specify exactly one room.
     171* Room participation is partial because a room may have zero reservations.
    117172
    118173==== makes (Users–Reservations) ====
    119 *'''Meaning:''' Users create reservations.
    120 *'''Cardinality:''' Users (1) — Reservations (N)
    121 *'''Participation:'''
    122  * Reservation participation is total (each reservation must be created by exactly one user).
    123  * User participation is partial (a user may create zero reservations).
     174
     175'''Meaning:''' The relationship makes connects Users and Reservations. It shows that users create reservation requests.
     176
     177'''Cardinality:''' Users (1) — Reservations (N)
     178
     179'''Participation:'''
     180
     181* Reservation participation is total because each reservation must be created by exactly one user.
     182* User participation is partial because a user may create zero reservations.
    124183
    125184==== has_approval (Reservations–Approvals) ====
    126 *'''Meaning:''' A reservation may have an associated approval decision.
    127 *'''Cardinality:''' Reservations (1) — Approvals (1), optional on the reservation side
    128 *'''Participation:'''
    129  * Approval participation is total (an approval cannot exist without a reservation).
    130  * Reservation participation is partial (a reservation may exist without an approval record, e.g., pending state).
     185
     186'''Meaning:''' The relationship has_approval connects Reservations and Approvals. It shows that a reservation may have an associated approval decision.
     187
     188'''Cardinality:''' Reservations (1) — Approvals (1), optional on the reservation side.
     189
     190'''Participation:'''
     191
     192* Approval participation is total because an approval cannot exist without a reservation.
     193* Reservation participation is partial because a reservation may exist without an approval record, for example while it is still pending.
    131194
    132195==== approves (Users–Approvals) ====
    133 *'''Meaning:''' Authorized users approve or reject reservations.
    134 *'''Cardinality:''' Users (1) — Approvals (N)
    135 *'''Participation:'''
    136  * Approval participation is total (each approval must be created by exactly one user).
    137  * User participation is partial (not every user must approve reservations).
     196
     197'''Meaning:''' The relationship approves connects Users and Approvals. It shows that authorized users approve or reject reservations.
     198
     199'''Cardinality:''' Users (1) — Approvals (N)
     200
     201'''Participation:'''
     202
     203* Approval participation is total because each approval must be created by exactly one user.
     204* User participation is partial because not every user must approve reservations.
    138205
    139206== Design Assumptions ==
    140207
    141208* Each room belongs to exactly one building.
     209* A reservation is created by exactly one user.
     210* A reservation is made for exactly one room.
    142211* A reservation cannot overlap with another reservation for the same room and time interval.
    143 * A reservation may exist without an approval (status = pending).
     212* A reservation may exist without an approval record while it is still pending.
    144213* Equipment types may exist without being assigned to any room.
    145 * Only users with appropriate roles (admin/approver) are allowed to create approval records.
     214* The !RoomEquipment entity is used to model the many-to-many relationship between Rooms and Equipment.
     215* Only users with appropriate roles, such as admin or approver, are allowed to create approval records.
    146216
    147217== Entity-Relationship Model History ==
    148218
    149 * '''v01''' – Initial version of the ER model. Includes: Buildings, Rooms, Equipment, !RoomEquipment (associative entity), Users, Reservations, and Approvals, together with all required relationships, cardinalities, and participation constraints.
     219* '''v01''' – Initial version of the ER model. This version includes Buildings, Rooms, Equipment, !RoomEquipment as an associative entity, Users, Reservations, and Approvals. It also defines the required relationships, cardinalities, participation constraints, candidate keys, primary keys, and main entity attributes.