A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
Recently, I attended a meeting with a group of senior software professionals to review an older system. A checklist was circulated that included the items that needed to be brought to the meeting, one of which as a set of ERDs for the system. Being the seasoned professional that I am, I replied to the request. About half-way through the meeting, the most senior guy asks if I forgot the ERDs. I then realized that he did not know the difference between an ERD and a database model.
With the above said, an ERD is NOT a relational database model. The ERD (a.k.a. Chen ERD) is a process data modeling tool that is independent of automation. An ERD enumerates entities (people, places, and things), and how these entities relate to each in a system, manual or automated (here is an example of a proper ERD: http://yourdon.com/strucanalysis/wiki/images/b/b9/Figure121.jpg ). ERDs were heavily used during the period of time when SSADM (structured systems analysis and design method) was the flavor of the month in software development. They were usually accompanied by a set of data-flow diagrams (DFDs).
Today, ERDs and DFDs are seldom used; however, IMHO, they superior to their RUP counterparts. They were much easier for system users to understand, which led to better/clearer communication between the design team and end users.
Food for thought...
Friday, July 27, 2007
Well Food, I probably would have made the same mistake as your senior guy. When I think of ERD's, I think of the Crow's Feet variation
I acknowledge that you are correct, I just would have made the same mistake.
Friday, July 27, 2007
That's true. But that doesn't change the fact that when most people want "a diagram of a database", the diagram they expect to get will be in ERD form.
Friday, July 27, 2007
True but I think you need to consider your audience.
To software developers, the ERD is the database model since that is the representation of the logical data model and they are coding to that model. ERD is one relatively efficient way of presenting the logical design; there are others.
You correctly point out that there is also a physical data model (i.e. the mapping of the logical model to the physical hardware and database technology) however that is typically viewed as the realm of the database architect and not of any concern of the software developers.
Finally, a really good system architect will understand the trade-offs between various software and database model options and assign elements of the architecture to the appropriate places (e.g. should this be done in application software or as a trigger or stored procedure?)
Where ERD fails is in presenting triggers, constraints and (usually) indexes to the audience.
Alot of DB terminology gets screwed up. Most people think a transaction includes select. They think every user action in the database is a transaction.
update table a;
update table b;
is two transactions.
That being said ERDs are useful during requirements and early design phase to flesh out details about your system. After you convert them to a physical model, it is generally not worth the effort to keep them in synch with your physical model as it changes.
Most people think a diagram with tables and lines on it is an ERD and do not know what an ERD is.
Monday, July 30, 2007
"A checklist was circulated that included the items that needed to be brought to the meeting, one of which as a set of ERDs for the system."
The correctness of the terminology aside, it sounds like they had a set of references they wanted handy during the meeting. If they wanted to discuss changing a particular requirement, it helps if you can ballpark the impact of the proposed change on the spot. For example, if Sales wanted a certain report, do you you already capture all of the necessary data, or do you need to set up additional tables, columns, form fields, validation checks and so on?
If I'm correct, for their intents and purposes, Steve nailed it on the head. They don't care whether it's called a database model or an entity relationships diagram. They just want to know if your system will support what they asked for, or if you need to do extensive work to add it.
More to the point, again, in the context of this meeting, I'm not sure what value it adds to educate them on the difference between an ER diagram and a model. Let's assume for the sake of argument that you succeed and they correctly ask for the data models next time. You should still be able to answer their question either way.
I apologize for my tone. And I also freely admit I may have misunderstood the purpose of the meeting entirely.
I think it's important people know the difference between an ER diagram and a database model. I also think there's a time and place for it, such as in an academic whitepaper.
I also respectfully point out that the higher you climb the ladder and the more decision making, non-programmers you deal with, the easier it is to retain your sanity if you turn off that part of your brain and focus more on what they really want verses what they're literally asking for. In this regard, you should bring either the ER diagram or the database model or both, whichever makes it easier for you to answer their questions.
If they're so anal that they expect to see an actual document describing the database model and clearly labeled as an ER diagram before they can check off that little box on the checklist, you have my blessing to look for another job.
Monday, July 30, 2007
I'm not such a big fan of using pictures to describe databases in the first place. They are good at a high level, but when you get to the nitty gritty details, they start to look like wiring diagrams.
If you've ever worked with wiring diagrams, you'll know they're no fun.
Also, people tend to think that pictures take the place of well formed sentences. Actually, well formed sentences, plus clear pictures, are better than either by themselves.
Its about the difference between conceptual, logical and physical models.
for conceptual you have ERD (entity-relation_SHIP_) or ORM (Object Role Model) with terms entity, relationship. For ERD you have notations IDEF1x, Martins IE (crow foot)
For Logical you can map ERD or ORM to relational, (or historical Network or Hierarchical - think xsd) with terms relation, tuple, key. For relational you have notation relational or CODASYL (arrows in other direction)
For physical you have SQL DDL with terms table, column. row.
Confusion arises because crow foot notation (conceptual model) is often used with relational model (logical)
Tuesday, July 31, 2007
Glad to see ORM - Object-Role Modeling - is finally coming into its own! Also that the confusing alternate - and different - term "Object-Relational Modeling" seems to be fading out of use.
I used Dr. Halpin's early version of ORM - Asymetrix Infomodeler - around 1995 and found it superb for nailing down real-world relationships and documenting them in plain English that you could discuss with the client - and then generating correct and complete DML for the database. After he joined MS, the ORM concept was initially not well understood - they put out a version of Visio that only did the graphics without the semantics - but I will have to get into it again and see what the current offerings are...
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz