(This is a rewrite of a 12/10/16 post, to bring it in line with McGoveran's interpretation of Codd's RDM.)
Here's what's wrong with last week's picture, namely:
"A
quick-and-dirty definition for a relational database might be: a system
whose users view data as a collection of tables related to each other
through common data values.
The whole basis for the
relational model follows this train of thought: data is stored in
tables, which are composed of rows and columns. Tables of independent
data can be linked, or related, to one another if they each have columns
of data that represent the same data value, called keys. This concept
is so common as to seem trivial; however, it was not so long ago that
achieving and programming a system capable of sustaining the relational
model was considered a longshot with limited usefulness.
If
a vendor’s database product didn’t meet Codd’s 12 item litmus tests,
then it was not a member of the club ... these rules determine whether
the database engine itself can be considered truly “relational”. These
rules were constructed to support a data model that would ensure the
ACID properties of transactions and also eliminate a variety of data
manipulation anomalies that frequently occurred on non-relational
database platforms (and **still do**)." --Kevin Kline, SQLBlog.com
Note: This is a 11/24/17 re-write of Part I of a three-part series that replaced several older posts (the pages of which which now redirect here), to bring in line with the McGoveran formalization and interpretation [1] of Codd's true RDM.
"The principle of orthogonal design (abbreviated POOD) ... is the second of the two principles of database design, which seek to prevent databases from being too complicated or redundant, the first principle being the principle of full normalization (POFN). Simply put, it says that no two relations in a relational database should be defined in such a way that they can represent the same facts. As with database normalization, POOD serves to eliminate uncontrolled storage redundancy and expressive ambiguity, especially useful for applying updates to virtual relations (views). Although simple in concept, POOD is frequently misunderstood ... is a restatement of the requirement that a database is a minimum cover set of the relational algebra. The relational algebra allows data duplication in the relations that are the elements of the algebra. One of the efficiency requirements of a database is that there be no data duplication. This requirement is met by the minimum cover set of the relational algebra." --Wikipedia.org
Well, not quite.
My April column @All Analytics.
A R-table with attributes defined only on simple domains takes a less convoluted form -- a normal form -- devoid of nesting. If R-tables are in the preferred normal form i.e., components meaningful to applications (here, employee attributes) are simple domains in their own right and a true RDBMS enforces value atomicity -- first order logic is sufficient. This imposes some limitations on the expressive power of data languages, but they are declarative and PDI and simplicity are preserved. A true RDBMS enforces atomicity via a data language that does not allow applications to access attribute components not explicitly defined on their own domains.
Read it all. (Please comment there, not here)
FYI: I have revised all three parts of the series on 1NF -- mainly refinements and clarifications.
