Segment - Ternary Relationship

Biju Narayanan
Greenhorn
Posts: 6
Problem:- Flight Reservation Design

In my analysis model, Customer has a many to many relation with Itinerary.
One customer can have many iternary and one itinerary can belong to many customers (A family going together).

Customer[0..*] -------> [0..*] Itinerary

Itinerary has an aggregation relation ship with segment. Iternary contain one or more segments

Itinerary ---->[0..*] Segments

Each segment is a realization of relation between flight and reservation. Flight and reservation is a many to many relation

Flight [1..*] <---------> [0..*] Reservation.

Segment is a realization of relation ship between Flight and reservaton. While Itinerary has an aggregation relationship segments. By deducing this, Segment is a realization of ternary [n-array] relation ship between Itinerary , Reservation and Flight.

Can anybody advice, am I going wild in these relation ships making it big blunder?

Jim Janssens
Ranch Hand
Posts: 210
well, I gave it a shot understanding your explanation :

1. I find it very unlogical to have a many-to-many for customer and itinerary. I understand your idea, but it seems complex and not very realistic. When a family books a trip, it will be one person only that makes the reservation. I can understand that when a member from that persons family has an account too, you could make this itinerary 'shared' so that when the other person logs in, he sees that itinerary,with a note that is was booked for him by customer x (so you could create a sort of 'friends' list with who you can share your itineraries with)

But even then, the customer that actually payed for the itinerary remains the physical owner...so it has no real added value to have it a many-to-many if you ask me (only more complex)

2. An itinerary with zero segmens seems unlogical too. You cannot have an itinerary without a segment in the original BODM. If I understand you right, your itinerary points to zero or more segments(with 'segment' being the interface and 'flight' the actual class). So in practise an itinerary will point to zero or more flights. How can you have an itinerary without a flight ?

3. I do agree about the aggregation thing. If you delete a flight, the itinerary becomes obslelete as well. However, how can you indicate that an itinerary may ONLY be deleted if no more flights point to it ? I would certainly add a a note or something to explain this (unless there is a special form of aggregation that indicates this behaviour ?)

EDIT:

Anyway, if you believe in your approach and you can justify it in the assumptions (and it correct according UML and normal human standards ) it should not pose a problem ...
[ December 19, 2005: Message edited by: Koen Serneels ]

Biju Narayanan
Greenhorn
Posts: 6
Thank you: I appretiate your response.

For #1. I agree, that it is logical to make it a One to many relationship between Ccustomer and Itinerary.

Customer -------> [0..*] Itinerary

For #2. My mistake. It is

Itinerary <>----> [1..*] Segments

The third point is that :
Segment is a realization of ternary [n-array] relation ship between Itinerary , Reservation and Flight.

Itinerary [1]
|
|
|
Reservation[0..*] ----<>------- Flight [1..*]
|
|
|
Segment [Realization]