I can't model the following rule: "For each screening a seat can have only one ticket".
Asked
Active
Viewed 939 times
-1
-
Do you want to know about modeling techniques or how to implement a 1..1-0..1 relation? Please, state your question properly. – Boris Schegolev Aug 18 '16 at 22:17
-
Instead of 3 binary relationships, a single ternary relationship might be more useful. – reaanb Aug 19 '16 at 06:35
-
@BorisShchegolev I am not a native speaker. Anyway, I would like to know how to implement a relation between those 3 entities such that there cannot be two tickets related to both the same seat and screening. – PaoloP Aug 19 '16 at 15:51
-
@reaanb Hi, I edited the diagram because I got the cardinalities wrong. Anyway, I tried using a single ternary relationship but then each seat is related to many screening-ticket couples, so how can I make sure there are not two tickets related to both the same screening and the same seat? (sorry for my english) – PaoloP Aug 19 '16 at 16:04
-
can you share the whole exercise? – Jorge Wander Santana Ureña Jan 04 '20 at 18:01
2 Answers
0
The stated business rule says "only one", clearly hinting at uniqueness of something.
How are you supposed to model "uniqueness of something" using this particular ER dialect ? It doesn't look like it's very well suited for this puprpose.

Erwin Smout
- 18,113
- 4
- 33
- 52
-
Hi @ErwinSmout, I am not a native speaker so maybe I did not phrase my question correctly. I have to model a movie theater booking system and I am stuck at the ER diagram because I don't know how to make sure there aren't two seats related to both the same seat and the same screening. Initially thought I could do that using the cardinalities, but I am not sure about that anymore. Anyway, I must use that ER dialect because that's what my university professor wants. – PaoloP Aug 19 '16 at 16:10
-
0
At first, I wanted to model it as:
(For more about the notation, see my answer to is optionality (mandatory, optional) and participation (total, partial) are same?)
But this only enforces the functional dependency:
(Screening, Seat) -> Ticket
and not
Ticket -> Screening, Seat
So this may be a better option:
The diamond-in-rectangle is an associative entity - a relationship that is the subject of another relationship.