Re: Clues on modeling a really simple concept

From: Walter Mitty <>
Date: Wed, 08 Apr 2009 12:10:30 GMT
Message-ID: <Wu0Dl.2354$>

"Spike" <> wrote in message

> I think (and hope) i have not expressed myself correctly.
> Im modeling this software for fun. It is a private project. No
> requirements to relax and no security issues because it is just a
> draft, an idea.
> I just wanted some clues on this kind of things. As simple as "This is
> what i would do: ...".

I had no idea that the purpose of the project was just for you to have fun. In that case, my advice is short and sweet: suit yourself. I haven't got a clue about what kind of design will give you the most fun.

As far as what I would do goes, I'd follow the pattern I learned, back in the 1980s. This pattern is by no means the prevailing one in this newsgroup, although there are certain points in common between my practice and prevailing opinion.

I would develop not one model, but three models, called the conceptual model, the logical model, and the physical model. These are data models, not really object models. There's a relationship between data modeling and object modeling, but that's really a subject for a different discussion.

For the conceptual model, I would use a variant of ER modeling. An ER model doesn't tell you how to design the database. It just gives you a formal description of what the data looks like, from an analysis of the requirements. As the requirements change, so does the ER model. An ER model doesn't have any foreign keys in it (although some modelers don't agree). Normalization and performance are not relevant. One result of ER modeling is what some people have called a "pretty picture" of the data. Pretty pictures help me think, and help me discuss data with other people. Keys are included here to identify entities. sometimes, a synthetic key has to be concocted because the subject matter experts are too informal in their handling of the data. Relationships are identified by identifying the participating entities.

For the logical model, I would use relational modeling. This model contains some elements of design in it, but omits details that are added in physical design. This model is relevant to both database construction and application construction. Foreign keys have been plugged in to represent relationships between relations. normalization is relevant here, for the sake of flexibility in manipulating the data. Performance is still not the major issue. Coming up with a relational model once you have a good ER model can be fairly mechanical. The logical model is specific to a class of DBMSes, but not to one DBMS. If I'm going to design a "denormalized" database, I would want to document any departures from normalization in this logical model, at the very least. I wouldn't do that in this case.

For the physical model, I would use the SQL model, augmented by whatever DBMS specific features are needed to actually construct a database. Table design in SQL is almost automatic if you have a good logical model. Table design includes columns and constraints. It also includes index design, and other elements of design particular to some DBMS, such as Oracle. In addition to the logical model, I'd consider data volumes, traffic levels, hardware, response time requirements, etc.

From the physical model, it's almost automatic to generate a create script that will make an empty database. Generating the applications that will populate the database and keep it current is a little more work, and outside the scope of this summary.

For a project of the scope of your photo gallery project, the above description is harder to write up is this comment than it is to actually do. I would just use pencil and paper or whiteboard instead of some fancy tool. For a big project, involving hundreds or thousands of attributes, I'd want a good tool to keep track of the details and to partially automate the conversion form one model to another.

Would this be fun? A little, for me. Would it be fun for you? Again, I haven't a clue.

From here we could branch off into two side discussions: what is prevailing opinion in this newsgroup, and how does it obviate some of the steps I've outlined above? And, what's the relationship between object modeling and data modeling?

Whatever you do, make it fun. Good luck. Received on Wed Apr 08 2009 - 14:10:30 CEST

Original text of this message