Hi

When I started designing Enterprise Data Models about 10 years ago they had lots and lots of Entities, (usually around 50 or more) and were understandable only by other Data Modellers and with great difficulty.

Over the last 5 years, I have favoured an approach that has a Top-Level Model with a number of Subject Areas - not more than ten.
The objective of the Top-Level Model is to establish communication with senior management.

This Top-Level EDM is then the starting-point for creation of an EDM for each Subject Area.

Here is an example for Investment Banking on my Database Answers Web Site :-
Enterprise Data Model for Investment Banks

I wonder what Best Practice suggests about what an EDM looks like ?

I look forward to hearing what other people think ;-0)

Barry Williams
Principal Consultant
Database Answers Ltd.
London, England

in that case there shouldn't be any crows feet or cirles on the lines, and really, the lines shouldn't be there either

so you have just the boxes

then you could remove the boxes and put a bullet in front of each entity name

and vwalah!! senior management powerpoint slide!!

You're Canadian, so I'm sure you must know that should be "voilà" - are you dumbing down for others?!

whoa, nice job on the accent, eh

i do realize that french has that word, but mine is the anglicized version

english has that habit, you know, of borrowing/stealing words from other languages

so when you apply for that data architect job, you'd better have data modelling on your rezoom

I wouldn't normally bother with the accent, but thought as I was being pedantic I should (copied and pasted from a Google result).

Oh well, "say lavy" as they say(?)

Hopefully it doesn't look like an ER model. In my personal experience, over-reliance on ER diagrams and related techniques is largely to blame for the failure of many (possibly even most?) data models. By "failure" I mean models that satisfy the data architects but are incomprehensible to business customers and irrelevant or too late for the developers.

I much prefer ORM (NOTE: never to be confused with O/RM)

Accounts have "account_id" but not an account number? What are the business keys in the other tables? If the business owner / domain expert can't work out what identifies each fact in the business process then she can't honestly tell you whether the model is correct or not. Neither can anyone else.

and i have the scars to prove it

i've fought that battle, too (and even won it once)