Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: Can FK be nullable/optional by design?

Re: Can FK be nullable/optional by design?

From: Bob Badour <>
Date: Tue, 16 Dec 2003 22:57:15 -0500
Message-ID: <>

"Tobin Harris" <> wrote in message news:brnvmp$5gqn4$
> "Bob Badour" <> wrote in message
> > Chris Date's _Introduction to Database Management Systems_ makes a good
> > start at them. I would seem foolish to try to teach them in an email
> > message.
> Don't worry Bob, I wasn't expecting you to seem foolish, or give a full
> tutorial.
> > One would start with "What is data?" and "What does it mean to manage
> data?"
> > From there, one would move to: "What principles facilitate or guide
> > effective data management?" And onward...
> Ok, this makes sense.
> > Since you apparently think one can easily enumerate them in an email,
> > would you describe as the fundamentals?
> I hadn't even considered whether it was difficult or not. I was simply
> interested in what your perceived "fundamentals" entailed, mainly so I
> go and learn more... I kind of expected you to mention some general
> which may or may not have included:
> Normalization - learning how to extrapolate to 1st, 2nd and 3rd normal
> schemas
> Integrety - learning that integrety applies at various levels - Domain,
> Column, Table, Database (Referential)
> Data Types - seen as sets of permissable values that enforce business
> by constraining the data that is stored.
> Top-Down Analysis - learning to identify entities and business rules by
> reading existing documentation, verbal communication etc
> Bottom Up Analysis - learning to derive and normalise attribute listings
> Keys and Identity - different types and why

Your list of "fundamentals" does not answer any of the questions "What is data?", "What does it mean to manage data?" or "What principles facilitate or guide effective data management?"

Of the items in your list above, integrity and data types are fundamental, but your elaborations above are anything but fundamental.

One can come up with any number of taxonomies for integrity constraints--Chris Date has published enough of them in his career. The taxonomy I find most enlightening is: All integrity constraints constrain variables. Integrity is fundamental because it is fundamental to the manipulation function when managing data.

A data type does not enforce business rules--the integrity function of the dbms does this. Data type is fundamental to computing and not only to data management. A data type comprises both a set of values and a set of operations on those values. With respect to the relational model, Date and Darwen have observed that data types define what we can make statements about, and relations make statements about them. Received on Tue Dec 16 2003 - 21:57:15 CST

Original text of this message