Logical data design, Pick style

Well said Mark. That's one of the reasons I opted for using Pick in
my direct sales chair manufacturing company nearly thrity years ago.
The people that were trying to compete with Pick were showing their
ignorance by asking me all kinds of questions that to me were totally
irrelevant.

In saying that I am not trying to be critical of Dawn. She is a
delightful person who TommyD and I had lunch with a couple of weeks
ago. However, she does not come at Pick like many of us did so we also
need to educate her how she can go up against her friend Fabian Pascal.
In true enterpreneurial fashion I just bought Fabian's $29.95 book,
Understanding Relational Databases" for $2.25 on eBay so I can see
where Fabian is coming from. However, to me it is not winning the
debate, it's about winning users and entrepreneurs will remain the
prime target audience for Pick, probably forever.

Henry Keultjes
Mansfield Ohio USA

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. 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.

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

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

Anything else is a waste of time and my effort.

Mark Brown


8. Look for functional dependencies and put it into Boyce-Codd normal
form sans 1NF.

I have a lot of other notes, but this should be good enough for a
discussion starter, I hope. Your thoughts? --dawn

P.S. Blog is at http://www.tincat-group.com/mewsings, latest entry is
on MV NULLs.


.