Re: Clues on modeling a really simple concept
Date: Wed, 8 Apr 2009 14:50:58 -0700 (PDT)
On 8 abr, 14:10, "Walter Mitty" <wami..._at_verizon.net> wrote:
> "Spike" <fau..._at_gmail.com> 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.
Thank you! Received on Wed Apr 08 2009 - 23:50:58 CEST