Week 6 - Relational Database Theory

The relational model was developed by E.F. Codd around 1968 as a mathematical principle to visualize large data, make it more scalable, enhance its performance, and make it portable. In simple terms, a relational database uses relations between values and symbols to organize data. The theory behind a relational database consists of rules and terminology that dictate how the relational database is represented and interpreted. 

One representation of a relation can be shown as a table independent of the order in which its given (i.e. rows and columns). However not every table displays a relation therefore the terminology used to describe the anatomy of a relation is different than that of a table (i.e. the word table is substituted for relation, tuple for row, and attribute for column). A set of attributes is also referred to as the head, and the degree refers to the number of attributes. A set of tuples is also referred to as the body, and the cardinality refers to the number of tuples. Attributes correspond to names and types, while tuples correspond to the values that are defined by the attributes. 

The relational database theory is different from structured query language (SQL) which is another communicative method for databases that stems from the relational database theory. For example, SQL automatically orders the data whereas for a relational database the order of the data is arbitrary, and SQL allows the data inputted into rows to be duplicated unlike relational databases which cannot have duplicate tuples.

Why do we use the relational database theory? One reason is that it will save time from having to arbitrarily guess which database design to use. The objective of a good database is to reduce the redundancy of data to save storage space and avoid inconsistencies, and to ensure that the data is secure, accurately represented, and maintains its integrity. The emergence of inconsistencies due to abstraction or “accurate data extraction” is avoidable by using the relational database theory, and many of these inconsistencies include deletion errors, incorrect or multiples of results, and comparison of unrelated variables. Relational databases can be customized for particular applications; in smart buildings these applications include energy efficiency measures and building automation systems. These databases are well known and accepted as an industry standard as opposed to NoSQL which tends to pose fewer benefits in most situations.

References:

[1] http://archive.oreilly.com/oreillyschool/courses/phpsql2/phpsql203.html

[2] https://dvikan.no/ntnu-studentserver/kompendier/an-introduction-to-relational-database-theory.pdf

[3] https://en.m.wikipedia.org/wiki/Relational_database

[4] https://www.ntu.edu.sg/home/ehchua/programming/sql/relational_database_design.html

Comments:

Richard Kimball – You mentioned normalization of databases which is not a concept that I came across in my research and will be sure to review. It is important that as the amount of data increases with the emergence of new technologies, that databases are able to be enlarged to accommodate growing needs. With the increase in size of databases it will likely become more difficult to track the accidental changes or potential losses in data. I think security of this information especially when being transferred will bring about new ideas to this field.

YIDI LI – The Database Manager Program sounds like it would be beneficial not only in construction firms presently but for future construction practices under the assumption that artificial intelligence technologies would be programed to assist in construction design. While this could be far beyond the realm of possibility, I think these databases could interact with technologies, even dictate or send data, which would allow for projects to be monitored by machines instead of humans. 

Nick Maloney – I discussed relational databases and the use of SQL lead me to inquire about why SQL and other databases employ different languages. From a proprietary business standpoint it makes sense however I think that the transition between using one database or another could be made easier if the languages were similar. Perhaps the two databases could even work together and do so very efficiently if they were the same language.