Re: Clues on modeling a really simple concept
Date: Wed, 08 Apr 2009 12:10:30 GMT
Message-ID: <Wu0Dl.2354$Q52.1317_at_nwrddc02.gnilink.net>
"Spike" <fauria_at_gmail.com> wrote in message
news:ef1e17c0-8725-4c79-ac80-35d33dda975c_at_f19g2000yqo.googlegroups.com...
> I think (and hope) i have not expressed myself correctly.
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,
>
> 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: ...".
>
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