Re: Suggested course of study...

"Kevin Stevens" <kstevens_at_localnet.com> wrote:
> I have found myself fascinated by database modeling and design. Given that
 I
> am no math whiz and am thinking about this as a new career at 36, what do
> the gurus of the group think is a baseline level of knowledge that would
> allow me to design databases for small to medium size companies? I am
> thinking about this as either an independent contractor or in-house.
>
> I want to get a firm grasp on theory and design principles before learning
> any particular RDBMS implementation.
>

<snip>

Kevin,

The common sense approach to designing databases works very well for 80 - 90% of the cases. What helps me most is to sit and write down definitions of all the entity types, attribute types and relationship types.

Definition shape of an entity type:
<entity type name> is a <general accepted notion> that <things that make the notion a <entity type name>. Example: A Human (=entity type name) is a (mamal = notion) that knows he is going to die (= things that make a mamal human).
A good definition of should be reversable, and still true. The trick is to think about the definition as that it defines everything that belongs to that entity type. Every entity that complies to the definition will end up in the resulting table.

Definition shape of an attribute type.
An <attribute type name> is a <name, number, amount, percentage, promillage, text, date, time, indication (yes / no; true / false), code, and maybe two or three more that I can't remember at the moment> that <role to entity type>.
This latter is the most important part. If you can't find a way to define an attribute type that includes the entity type name, then the attribute type can't be an attribute type of this specific entity type. The same is true if you're having trouble coming up with a definition with the entity type name in it. Wacky definitions always point out the sore spot in the model. Example: Telephone (attribute type name) is a number where Customer (= entity type name) can be reached.

Definition of a relationship type.
These I find the hardest to define. The trick is to think of the tables and define why the foreign key entered there is this specific occurrence and not another one.
So if you have an Customer -< Order -< Orderline example and in the order there is a valuta code foreign key, then the definition should answer the question: Why is this order in GBP and not in USD? Which is the discriminating factor here?
Example:
IF Order is shipped to Country, THEN it should be payed in the valuta of that country.

These excercises can be done together with the business specialist you are developing your datamodel for.

I know this isn't high relational calculus, but is helps the 'common sense' approach to get it right 99,999% of the time.

I hope this helps,

Arjan Bos Received on Tue May 02 2000 - 00:00:00 CEST