The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Conceptual Data Model, Is it worth learning/doing ?

Hi All,

I am database programmer for couple years now. During these years, when design a new application, I normally go direct to Physical Data Model, doing the normalization on the fly.

Now, I want to improve my data model/design skill, so I would like to ask if it is actually a good idea to learn dan do Conceptual data modelling for my project. Or I should spend my limited time on improving my software design skill instead.

Please enlight me. Thanks
Aspired Enterprise Architect Send private email
Wednesday, March 02, 2005
 
 
Pick up (and read) Database Design for Mere Mortals.

It is a crash course and some of it may be review, but it's enlightening at times.  I read it about 2 years ago after coming off a project with a large multi-terabyte database.

I already knew some of the things purely by making the same mistakes, but I felt like that gave the book credibility.

My Associate Link:  http://www.amazon.com/exec/obidos/ASIN/0201752840/caseysoftware-20?creative=327641&camp=14573&link_code=as1
KC Send private email
Wednesday, March 02, 2005
 
 
Yes, it is worth learning.
Dino
Wednesday, March 02, 2005
 
 
I'm going to take flak for what I'm about to say from the DBA's out there... but here's my 2 cents worth...

"when design a new application, I normally go direct to Physical Data Model, doing the normalization on the fly."

What's so wrong about doing normalization on the fly?  I mean, philosophically?  The only time it can really hurt is if you've got a production system in place, and all of the software which consumes database services can't be upgraded at the exact same time as the table modifications are made.  And besides, isn't robustness and the ability to change table structures "on the fly" (or slightly slower, but in a still reasonable timeframe) the whole point of a three-tier design, where the client goes only to a middle layer for data access, and never talks to the tables themselves?  Also, many times in PERFORMANCE programming, don't you realize that sometimes you need to denormalize for some scenarios? Never had that happen to you, no?  Well, I'd like to hear from the people who have worked on Oracle 15 years ago... when processing power was EXPENSIVE and disks were SLOW.

Okay DBA's, fire away.  It's okay to call me a "total idiot" -- just back up your own assertions with an article, or URL, or a story from your own experience.

Note that me saying "what's wrong with normalization on the fly" is not the same thing as me saying "what's wrong with not learning how to normalize data".  They are NOT the same statement!  I believe people should learn how to normalize, but they should also learn how and when to DENORMALIZE, if it is necessary for performance, and what the implications of such a decision are (in terms of code, application maintainability, etc.).

Okay, now all you DBA's out there can feel free to UZI me to death! (well, verbally anyway! :-) )

Peter
Peter Sherman Send private email
Wednesday, March 02, 2005
 
 
"Or I should spend my limited time on improving my software design skill instead."

Why not go 50/50 on each?
Peter Sherman Send private email
Wednesday, March 02, 2005
 
 
Pick up (and read) Database Design for Mere Mortals:

KC: 

While I agree that the book does cover what it promises to cover, I have to not recommend it just due to the writing style.  This is one of the most tedious IT/programming books I've ever read and you know that's saying something! 

The problem is this (and I'm sure you'll find some Amazon reviewers who agree with me):  This books is unnecessarily bloated due to a ridiculous amount of repetition -- he's CONSTANTLY going back over the interviewing/design process which remains unchanged throughout.  It's hard to explain how bad this is to someone if they haven't actually read it.

So yes, the book conveys useful information and unlike a lot of books, it doesn't cut to many corners to do it.  BUT what this book goes to show you is that writing style, even in a technical book, does count for something.  Reinforcement of concepts is good, but you can go overboard with it too.
Crimson Send private email
Wednesday, March 02, 2005
 
 
Other than the trivial case it is always worth learning and using conceptual data modelling, not simply because you preduce a closer mapping between real life processes and the structure you store the data in but because it can be used to converse with the users.  That is the real users, not the people who think they know what they're doing.

If you deal in the facts of what people do then you're far more likely to come up with something that the users will recognise and use intuitively.

Read everything that Terry Halpin has ever written and look at the FORML language as well as ORM.  http://www.orm.net/halpin.html
Simon Lucy Send private email
Wednesday, March 02, 2005
 
 
Sorry for my bad grammar. Thanks for the replies

"Other than the trivial case it is always worth learning and using conceptual data modelling, not simply because you preduce a closer mapping between real life processes and the structure you store the data in but because it can be used to converse with the users."

Anyway, actually does end user understand how to read Conceptual Data Model ( with its symbols, cardinality, optionality, etc) ?
Btw, I am currently reading Data Modeling Essentials. At the first time, after never see Conceptual Data Model for a long time, I have difficulty to read the model.

thanks.
Aspiring Enterprise Architect Send private email
Thursday, March 03, 2005
 
 
Crimson:

Actually, I read it after coming off a long string of deep technical books while working on my Masters, so I appreciated the change.  It's quite informal and you can feel like the guy is talking to you.

OP:

Look into some stuff on Design Patterns.  Martin Fowler is one of the most established people in this area and I've found his "Patterns of Enterprise Application Architecture" and "Refactoring" to be good non-technology specific sources.  Though I would suggest a pretty high understanding of atleast 1-2 programming languages before you dive into either.
KC Send private email
Thursday, March 03, 2005
 
 
That's where FORML helps, FORML is a natural English parsing of the diagrams so that two ellipses (called Question and Answer) connected by a two compartment box with a dot on the first ellipse, the word has above the box and double headed arror extending for half the box translates as:

Question(QuestionID) is an entity object type.
    Every Question is identified by one distinct QuestionID.
    Physical Microsoft Visual FoxPro datatype: Char(10).
Question has Answer
    Each Question has some Answer.
    For each Answer a, at most one Question has Answer a.
Answer(AnswerID) is an entity object type.
    Every Answer is identified by one distinct AnswerID.
    Physical Microsoft Visual FoxPro datatype: Char(10).

Different parsers of the diagram will give slightly different results but the facts will be the same.
Simon Lucy Send private email
Friday, March 04, 2005
 
 
Whatever methodology is used to produce a conceptual model, it is always important to have a business view of the system you are dealing with.

Remember, a physical model is an implementation model, it will change over time for reasons that are not necessarily related to business change. It will be tuned for better performance, re-designed to split tables or cater for data migrations. The conceptual model describes your real-life environment and should be independent of technological choices (RDBMS/LDAP/XML/Flat file, etc.?).

A conceptual model is the reference when dealing with implementation issues, it should be easier to read (if it's not then there's a problem with the design). I am currently working on a system which has only few entities but a lot more tables that are irrelevant to the business view, they are simply here because of implementation decisions.
Serge Send private email
Wednesday, March 16, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz