Hi, I am following the Project Booking assignment and have some questions.
In the picture above, that is illustrated in the exercise, it seems that the room and the amenity has many to many relationship. Why would it be? I was thinking that each room has many amenities, so in actual case the relationship between room and amenity should be one to many. I can't wrap my head around this.
Hi Tony,
And it has. The Romm and the RoomAmmenity have a relationship of 1 to many.
1 room in Room can have many ammenitys in RoomAmmenity.
But instead of using just those two entities, that would require a field with the amenity name, and eventually other fields, we choose to normalise it and we create another entity, called Ammenity, that has information about amenities.
Now, when we want to say that a room has an Ammenity, we just create an entry in the RoomAmmenity saying which is the room and which is the Ammenity.
Other advantage is that now we can say exactly which amenities we have available to use, and use a combo box to show this list in the page where we assign amenities to a room.
Was I able to clarify it?
Cheers.
A Room can have multiple Amenities of different types, and multiple Rooms can have the same type of Amenity. Here Amenity is not an instance, but a type... think Safe Deposit Box or 32" TV:
If there's a Unique Index on the RoomAmenity's pair of reference attributes (RoomId and AmenityId), then a room will not be able to have more than one 32" TV, if there's no such Index, then we can have a larger Room (think a suite) having two such 32" TV (one in the foyer and another in the bedroom)
Hi Eduardo and Jorge,
Think I get it. So if a room has many amenities, we actually do not want the room entity to display all amenities in one row. Let say room X has 2 amenities (Amenity A and B), and assuming each row inside the room entity uniquely identifies a room (just so that we do not pollute the room entity table so we can populate the room list table properly under room page in UI, or etc) , we cant display another row with room X again with amenity B if the previous row has already been declared for room X with amenity A. ( There is another option to make the room entity display all amenities for a room in one row by making the amenity column hold a list though...)
So we create a separate table called roomAmenity to gather the room and amenity relationship. Now in this entity, every row will have a uniquely identified composite key consists of the room id and the amenity id. The added advantage here is we can reuse the amenity static entity table in the combo box.
Correct me if I were wrong.
The only thing I wouldn't say is that you will have a composite key.
Your RoomAmenity entity still have an Identifier (Id), that uniquely identifies each row.
But you can add a unique index (a database constraint will be created), to both FKs, so that the database will not accept repeated lines in RoomAmenity.
OutSystems entities do not accept composite keys.
Cheers