Re: Logical data design, Pick style
- From: "dawn" <dawnwolthuis@xxxxxxxxx>
- Date: 30 Mar 2006 03:02:20 -0800
Mark Brown wrote:
"dawn" <dawnwolthuis@xxxxxxxxx> wrote in message
news:1143682026.943058.213890@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I accidentally posted this to cdt first, oops, thus the >'s
I'll be back in the office next week Tuesday, but while I'm online I
thought I'd toss out a question. I've done a little work on the
following question, but have more to do and thought others might be
interested in jumping in on this one:
If you don't do logical data modeling relational model style, using
1NF, then how do you model the data?
1. Entity-relationship models or the analogous UML diagrams are good
for identifying and communicating conceptual data models. The topic of
conceptual modeling is bigger than this, but the focus of this question
is the "logical data model" or "implementation data model."
2. Take the conceptual model and look for strong entities -- those
that exist independent of other entities. Model those as files.
3. Identify unique keys for these files.
4. Identify some high level types for these files, including the old
designations of master files, transaction/event files, and code files.
5. Decide whether you will pour all code files together or use one
code file for typical abbreviation-description tables (see a previous
discussion on this topic a few months ago).
6. Add in all properties for these entities as attributes/fields in
these files.
7. Add in foreign keys where appropriate as well as the redundant
"return links"
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 ;-)
Anything else is a waste of time and my effort.
I suspect that is an overstatement, but I understand your angle. I'm
trying to bridge a chasm by using some of the terminology used for
SQL-DBMS development and try to be explicit about what Pickies do,
whether they know it or not. For example, you actually do think about
putting return links into your files, even if you didn't explicity see
them in any report.
I'm putting this machine away now, so I'll read others later. Thanks
for the "You might be a Pickie if..." response.
You might be a Pickie if you didn't know you designed a database, you
just type the sucker in.
You might be a Pickie if you teach someone to design a database by
showing them TCL (or the colon prompt to the PI/U2 folks)
Cheers! --dawn
.
- Follow-Ups:
- Re: Logical data design, Pick style
- From: Bruce Nichol
- Re: Logical data design, Pick style
- From: B Faux
- Re: Logical data design, Pick style
- References:
- Logical data design, Pick style
- From: dawn
- Re: Logical data design, Pick style
- From: Mark Brown
- Logical data design, Pick style
- Prev by Date: Re: Logical data design, Pick style
- Next by Date: D3 Linux - Large file - very slow restore
- Previous by thread: Re: Logical data design, Pick style
- Next by thread: Re: Logical data design, Pick style
- Index(es):
Relevant Pages
|
|