Ralph Shumaker wrote:
> James G. Sack (jim) wrote:
I've changed the subject line again to keep from confusing anyone who
tuned in late. ;-)
I am re-starting my comments on a clean page, because I was feeling
overwhelmed by detail. But I think I do have a better grasp after that
first exchange, so let's now look for a more succinct description of the
objectives and constraints.
My way of putting things here, may not exactly be approved professional
database analyst methodology, and if my casual approach invites bad
design decisions, perhaps someone better qualified will contribute some
additional guidance.
1) what are the essential "things" of interest here. And what are the
components required to uniquely identify such items?
- key blanks (manufacturer, blank-name)
- car series (manuf. model, year(range), [maybe more])
more: might mean some production sub-set
(eg, produced in St Louis, May-Aug)
(what else?)
Note that there may be some derivative information, that may be
interesting (of interest) but uniquely determined by the primary. Now
might be the time to switch to kee so that "key" can signify a database
unique index.
Also, there may be additional properties (options, accessories) which
may be of interest to (say) customers but irrelevant to the questions
the locksmith may be concerned with -- color, seat covers, etc.
2) what are the "relations" (or information associations) among the things?
- (one or more) car-series X accepts (one or more) key-blank Y
Ahhh but there may be additional data components in this relation (aka
"table") beyond the simplistic view above:
preference-code , source-reference, experience-rating,
notes, ...
So, in my naive view of the problem, it's just a one-relation database,
although it may turn out there are additional benefits to further factor
the "things" into separate relations (as hinted above: manuf. etc)).
This ties into a couple of things you said earlier about both avoiding
data duplication _and_ it enables some freedom in the user interface, in
allowing (say) a car to be specified in stages (using lookup tables for
pick-lists/combo-boxes).
Probably the first addition needed to the simplistic model above is
maybe transponder information? I didn't put that in, above because I
don't know anything about how that works. Perhaps you could give the
nickel explanation.
Now, there is more information needed about purpose, upon consideration
of which the identification of things and relations may need to be refined.
I like to approach this in terms of condensing the objectives into "use
cases" or "actor-interactions" (to give a couple of the jargon terms
used in the requirements analysis business).
(Maybe) there's only one actor/role/person interfacing with the system,
namely the locksmith?
Question Actions:
Q1) what blank could/should be chosen to make a key for car X
Q2) what additional information goes with a car-X - blank-Y choice
Q3) what other alternatives to blank Y might be considered
(eg, from other car-key entries)
Recording Actions:
R1) update/edit per determination of what does/doesn't work
R2) add/edit notes
R3) general add/delete/edit of table entries
Maybe I should stop here for a bit. :-)
Regards
..jim
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
