Hi, I am creating a high level conceptual data model (BTM) for logistics industry. I have such data domains as Clients, Employees, Services, Operations, Operations Documents, Service Documents, Location, Timetables, Rolling Stock.
1) I have a hard time deciding where I should put "Operations Plan" - as a separate data domain or under Operations or Timetable data domains.
2) I also have hard time positioning train data entity. A train is not really a rolling stock as it consists of locomotives and wagons. The later are physical assets, while the former is a combination of these assets traveling on the road, on the specific route at the specific time.
I am new to data modelling and I am following Steve's method of Who, What, When, Where, Why and How - I am trying to put my data domains and data entities under these categories. Makes life easier. So my questions is - where would you put "work plan" and "train".
Although I understand the help the 6W will give you in determining scope, I strongly advise to not model the data domains as such. Data domains are affected and steered by the 6Ws, but the data domains are not aligning with them.
To fully understand data they need to be identified as re-use of patterns in the entire data chain. Putting a ribbon around the various parts of the total model is the hard part. Use the 6Ws as a talking stick, but try to find the re-use in the enterprise to organize your models.
I've had exposure to the logistics industry through the Dutch railway company. They've built an architecture using Fact Oriented Modeling, but the architectural idea's are independent to any modeling method or tool.
Thanks. In a conceptual data model, you only care about high-level design - which tables should exist and the relationships between them. At this stage, you recognize the entities in your model and the relationships between them. The logical model comes after conceptual modeling when you explicitly define what the columns in each table are. When writing a logical model, you can also take into account the actual database system you are developing for, but only if it affects the design (i.e., if there are no triggers, you may want to remove some redundancy column, etc.)