The term relational database refers back to E.F. Codd's relational model of data, which was first discussed in an IBM research report from 1969. Another key article in the development of this theory is "A Relational Model of Data for Large Shared Data Banks", published by Communications of the ACM (Bostrup). As part of his writing, Codd created a list of 12 rules (Bostrup) which form the foundation for RDT. These include:
- All information in the database must be represented ONLY as values in a table
- Each data point/value will be logically accessible via a combination of "table name, primary key value and column name".
- Null values are allowed for the purpose of representing missing information in a "systematic way"
- The database description is represented in the same way as all other data so that the same relational language can be used throughout the database
- A relational system may contain several languages. "However, there must be at least one language whose statements are expressible, per some well-defined syntax, as character strings and whose ability to support all of the following is comprehensible: data definition, view definition, data manipulation (interactive and by program), integrity constraints, authorization and transaction boundaries (begin, commit, and rollback)".
- "All views that are theoretically updateable are also updateable by the system."
- Manipulating a "base relation or a derived relation as a single operand" applies to data retrieval, insertion, update and deletion.
- The database features physical data independence which means that application programs and individual activities remain "logical" even when changes are made in storage representation or methods of data access.
- The database also features logical data independence, which is similar to rule number 8
- There is also a sense of integrity independence which means that integrity constraints must be "definable in the relational data sublanguage and storable in the catalog, not in the application programs".
- Distribution independence is also important so that "the data manipulation sublanguage of a relational DBMS [can permit] application programs and terminal activities to remain logically unimpaired whether and whenever data are physically centralized or distributed".
- Even if the system does allow a lower level language to be used, it must not interfere with the higher level relational language that ultimately governs the database.
These rules are all intended to create a much simpler, more consistent and more logical means of storing data. Prior to the invention of this method, databases were usually organized in a hierarchical manner, which has been proven to be more complex than Codd's method.
References
Bostrup, Tore. "Introduction to Relational Databases - Part 1: Theoretical Foundation" 2008.
http://www.codeguru.com/csharp/.net/net_data/article.php/c19615/Introduction-to-Relational-Databases--Part-1-Theoretical-Foundation.htm
Wikipedia
http://en.wikipedia.org/wiki/Relational_database
Comments
To J Schwakoff: Your description was so helpful! All of the information I found online seemed so difficult to understand but your explanation of the table really simplified the concept for me.
To Justin Hileman: I love how you were able to use an example that we're all familiar with - RSMeans. I've used it a lot in my classes and I'd be interested to learn about other applications of databases in the construction field that I'm not familiar with.
To Jiaao Wu: I appreciated how you associated databases with several different building systems. I really appreciated the connection you made between databases and our AE 390 design project. It was nice to see a non-conventional use of a database since that application required more than just a listing of system components and involved both the designer and the project owner.
No comments:
Post a Comment