Re: Logical data design, Pick style


"dawn" wrote

Mark Brown wrote:

"dawn" wrote

If you don't do logical data modeling relational model style, using
1NF, then how do you model the data?
[snip]


Way too much work. I could pretty much have the db designed in the time
it
took you to write all those questions.

I don't doubt it -- it took me years to come up with what it was that I
might be doing in my head. I want to be able to teach this approach.
The RM is the only design approach taught in most college db courses,
in part because you can say "do this, then this".

It's more like:

What info does the user want to see (on their reports), what info do they
need to enter to get there, what processes are needed to feed the raw
data
in and get the resultant data out.

This is all part of my step 1, the conceptual model.


1NF? Boyce-Codd? Stong entities? What the hell is that stuff and why
is
it getting in the way of my data processing?

LOL. I know you know how to get from a conceptual model to a logical
design without thinking about what your brain is doing. So, how would
you instruct someone who has been infected with instructions about 1NF
to do this?

What goes on an invoice? What needs to be saved behind the scene? What
data may be useful periodically, like weekly, monthly and yearly?

Again, part of getting the conceptual model, the requirements. I'm
trying to get from there to the design for implementation in the
database. In Pick, the conceptual model and the design are very close
to the same, where in the relational model you have to get things into
first normal form, for example, so there is an entire discipline with
text books, training, etc in going from the conceptual model to the
logical model. The temptation with Pick is to say that you think about
what you need and then you do it. That cannot compete with the piles
of RM documentation on the topic, so I figured I'd have to use more
words to say it ;-)

[snip]

Dawn-

I the interest of full disclosure I must warn you that I spent some of my
early formidable MV training at the knee of Grand Dragon Brown, but I see a
serious flaw in your attempted instructional approach.

There is an academic tendency to seek out agreement from fellow academics to
promote acceptance of a particular approach. Any type of method that does
not clearly flow directly from previously accepted practice is immediately
suspect and often discredited out of hand with little or no examination.
Such is the myopathy of academia that practical use of archaic and
time-consuming descriptions, charts, constraints, etc, leads to unnecessary
quibbling over details that always increase the price of any practical
solution (assuming one eventually is produced) and often causes such delays
that the specification changes dramatically along the way simply because the
environment surrounding the proposed solution has changed.

Whenever an attempt is made to limit the use of MV databases to that
available in SQL design (1NF) something special and significant is lost.
I'll cover some obvious things that might help you explain the situation to
students:

1) Re-designing and (gag) re-building SQL tables and cross-references is
difficult, time-consuming, and often results in breaking a previously
working application. So in SQL a high priority is (rightly) placed on
making the design correct the first time. Complex calculations to estimate
the additional storage and computational horse-power to handle the changes
is also helpful.

In MV adding functionality and modifying database design is easy and often
trivial. Efficient storage and default id hashing make estimates of
additional storage or power largely unnecessary. Hence, less emphasis on
early design and more concentration on what should be accomplished.

2) The first normal form (1NF) description of data is more stale than a
ten-year-old biscotti. Using this constraint as a basis for building a
modern data design is the definition of useless self-flagellation. Mark
might approve of this however, where it involves SQL types whipping
themselves with Cat-5 cables in dark closets while trying to fit 1NF into
XML, (round peg/square hole.)

In MV we turn glassy-eyed at the thought of producing elaborate flow-charts
when we can better use the time to produce a functional proof-of-concept
with actual code and sensible reports.

3) Perhaps most importantly, the MV ethos is heavily weighted towards
practical action, the SQL ethos is heavily weighted towards normalized data.
For example; it is a common charge from the SQL crowd that allowing a
single-value attribute (field) to become a multi-valued attribute is simply
unacceptable and is evidence that an MV database can be easily broken. They
have no concept of how easily this change can be accomplished without
breaking an application, nor how useful it can be in actual practice. To
them it would require changing a field from containing a data value to one
containing a reference to yet another table which is admittedly a huge
***-puckering PITA, in MV its "ho-hum, next requirement please..."

Too long already, but I must conclude with total agreement with GD Brown -
1NF? Boyce-Codd? Strong entities? What the hell is that stuff and why
is
it getting in the way of my data processing?

BFaux -


.