• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

FBN Object Design

 
Saha Kumar
Ranch Hand
Posts: 218
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I am designing the object model, and have some confusion on: itinerary -> segments -> flights -> equipment -> seats.

My thinking is as follows: There must be a flight table in the database which gets updated many times during an hour to delete old flights, etc. There must also be an equipment table which contains static data pertaining to each airplane. Should the object model contain objects to contain this data? I know that we do not have to list all of the data fields in the model, but feel as architects we should have an idea about the sort of data we want in the model. For example, I am thinking that the equipment class in the model would only have a primary key for the flight and a primary key for the plane; the flight primary key would point to a table which gets updated quite frequently and the equipment primary key would point to a table with detailed static data about the plane (not the seats). This data separation would help the efficiency of the booking system. So I am saying that the booking data would be in separate tables from the table containing all flights and the plane's static data.

I am wondering if we should model for data which must exist, but is not populated by any of the four use cases.

I believe these details should be reflected in the class design. Is this correct?

Thanks for any help.

Saha
 
Required Field
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are right that Equipment in the domain model is supposed to represent an airplane (which is not mentioned in the business domain model drawn by the business analyst).

Now you can either assume in the domain model that the persistence table structure is deferred to the DAO layer OR add another class called Airplane AND/OR show a data-model containing all the tables and their relationships (TBL_ITINERARY, TBL_EQUIPMENT, TBL_PLANE etc)

I prefer the first approach.

Basically, remember that the table associations in the data model don't necessarily have to be the same as the class/object associations in the domain model! That is precisely the advantage of having a data-access layer!




Originally posted by Saha Kumar:
Hello,

I am designing the object model, and have some confusion on: itinerary -> segments -> flights -> equipment -> seats.

My thinking is as follows: There must be a flight table in the database which gets updated many times during an hour to delete old flights, etc. There must also be an equipment table which contains static data pertaining to each airplane. Should the object model contain objects to contain this data? I know that we do not have to list all of the data fields in the model, but feel as architects we should have an idea about the sort of data we want in the model. For example, I am thinking that the equipment class in the model would only have a primary key for the flight and a primary key for the plane; the flight primary key would point to a table which gets updated quite frequently and the equipment primary key would point to a table with detailed static data about the plane (not the seats). This data separation would help the efficiency of the booking system. So I am saying that the booking data would be in separate tables from the table containing all flights and the plane's static data.

I am wondering if we should model for data which must exist, but is not populated by any of the four use cases.

I believe these details should be reflected in the class design. Is this correct?

Thanks for any help.

Saha

[ February 27, 2006: Message edited by: Akshay Shrivastava ]
 
Saha Kumar
Ranch Hand
Posts: 218
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your reply...I was thinking the same.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic