4. Assign a "candidate" unique identifier to the entities. This identifier will always be referred to as a "candidate" since the assigning of keys is a function of database design. As a matter of fact, the assigning of table keys is the most important factor in database design. Another reason the identifier is referred to as a "candidate" is that you're constantly reminding everybody that this is how it looks today. It can change tomorrow.

It is almost an industry standard to name these "candidate" identifiers "Id" -- adapt if you must. So we have:

    Department: Id, Name
    Employee: Id, Name
    Project: Id, Name
    Task: Id, Name

5. Review where we are:

    Purchase Order
        WeekEnding, TotalHours
        Date, Hours

Now you can't just go moving stuff around without remembering where you got it -- where it came from. So we need to add the relationship the new entities have to the original business object.

5. Creat and document the relationship:

    Purchase Order
        Department.Id, EmployeeId, WeekEnding, TotalHours
        ProjectId, TaskId, Date, Hours

Back in the day, the database designer would look at that business obect and build a "file structure" database that looked like the object and represented by this data model. It would even have the same names as the object:

If the traditional database design approach were taken, based on this business object, the database would consist of two tables. One table would contain the form heading stuff and the second table would contain the line item detail stuff.

And that's why we've been building and rebuilding systems and databases forever. There's a whole lot data and many more relationships missing with the traditional approach.

Here's what's really in the "simple" Purchase Order.

The solid blue lines represent the objects required to support the Purchase Order and all of it's underlying relationships. The dotted lines represent data not discovered but implied.

Do you think a manager might want to have his or her project hours at his or her fingertips?

Hopefully, this tutorial will take you from modeling that legacy view of a business object to being a Pro-From-Dover data modeler. Oh, and this is the "short-cut" method.

Remember, you might have a pile of 20, or 50, or 100 business objects to look at. Again, put the simplest ones on top and work your way to complexity. You will be smarter once you get to the fraked-up objects.

So move apace. You don't have to get each object analyzed perfectly. You will find some attributes that "have no home." Put them on your "orphans" list. It's not unusla to find data in complex business objects whose "home" -- its entity -- has yet to be discovered. Some "orphans" will exist during tornover to the design phase. As long as they are documented, they remain until, usually with some conversation with the business user a "home" is found for them. I have seen data that nobody knew what it was. They never saw it. They never used it -- and that's how I documented it and moved on.