Re: Clues on modeling a really simple concept

On 8 abr, 14:10, "Walter Mitty" <wami..._at_verizon.net> wrote:
> "Spike" <fau..._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.
>
> > 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.

Thank you! Received on Wed Apr 08 2009 - 23:50:58 CEST