At this point in the Feasibility Study, this is a work in progress, only available to the BA and immediate team. For instance, I know I have yet to add the Purchase Order and Purchase Order Line entities (though I have added a foreign key in the Entity Descriptons, below, from the Product entity to the (most recent) restocking purchase order placed).

These were overlooked in this very early draft, and noticed when writing the EPDs (elementary process descriptions) and reviewing the data flows on the top level DFD against the LDS (as a completeness check).

...just like happens in a real project!

In looking at the tables below, if you didn't know, an underlined data item is a primary key. If there is more than one part to the primary key, all parts are underlined.

Brackets around a sequence of keys indicate that they are taken together and are the constituent parts of the key of the master.

If a non-key data item is the primary key of another entity then it is marked with an asterisk. This is known as a "foreign" key.

If a data item is optional (i.e. a value isn't always present) then it is marked with an "O"

For more info and a fuller descripion, see logical data structure notation

You can usually assume (but always check) that the attributes for an address are fully understood by the physical design team.

IMO, nothing is gained by dividing it down into house / flat number, street name, etc. during requirements analysis and specification. Physical design, yes.

This entity resolves the many to many relationship between Product and Supplier: each product is avaliable from many suppliers; each supplier may supply many products.

But also note that there are real, business data items associated with the resolver enity - for example, the supplier's code for the product, their price and whether they are the preferred one for that product or not. Would these have been noticed if we hadn't looked in to the M:M?

Some would argue that Product Description and Base Selling Price are derived items (they come from the Product entity and therefore should not be allowed for here).

The contra argument is that we don't want every historical order line's price to change if / when Marketing decide that they are going to change the base price of a product (similarly for Product Description).

That would be crazy. We need the price and description used at the time the order was taken.

An alternative would be to create a new version of each product, every time it is changed. Then a sales order line can reference the product and version.

If versioning is required, it can be dealt with at the physical design stage, but you will need to document which entities need versioning.

Of course, there will be a cost associated with versioning in terms of more to implement, more complex testing required, reports become more complex to write, on-going maintenance is more difficult...