B5 - Relational Database Theory

A database is an organized set of data generally accessed across a computer system. Interaction between a database and the end user is generally done through the database management system which helps bridge the gap between the data and the user by interacting with and analyzing the data. When databases become more complex, computer scientists tend to rely on formal design and modeling techniques to understand and create databases. In general there are two primary types of databases: relational database systems which became popular in the 1980s and rely on rows, columns, and tables as well as a specific language known as Structured Query Language (SQL). More recently, non-relational databases gained popularity, typically referred to as NoSQL, however, I am going to briefly focus on relational databases for the purposes of this post.

Relational database theory was initially proposed by EF Codd in 1970. The model sorts data into tables (also called “relations”) of rows and columns. Rows, referred to as “tuples” represent instances of that type and columns represent values attributing to that instance. A relation is defined as a set of tuples that share the same attributes. Each row in a table has a unique key. Rows can be linked to other rows in other tables through the addition of a column for the key of the linked row. While the relational database theory continues and can get much more complex, I am just covering the very basics of relational database theory.

Relational database theory is used today, and is being implemented in some instances to improve efficiency. Amazon Aurora, for example is a relational database built for the cloud that “combines the performance and availability of high-end commercial databases with the simplicity and cost-effectiveness of open source databases” [1]. According to Amazon, Aurora is up to five times faster than standard databases and provides security and reliability without sacrificing costs by automating repetitive, time-consuming administration tasks such as “hardware provisioning, database setup, patching, and backups” [1].

While my knowledge of databases is still minimal (due to the fact that we have yet to cover them in class) I do look forward to learning about what a database is, the fundamentals of relational databases, and how they apply specifically to the AEC industry.


Sources:

[1] Amazon Aurora – Relational Database Built for the Cloud - AWS. (2019). Amazon Web Services, Inc.. Retrieved 12 February 2019, from https://aws.amazon.com/rds/aurora/
[2] Relational Databases 101: Looking at the Whole Picture. (2019). Agiledata.org. Retrieved 12 February 2019, from http://www.agiledata.org/essays/relationalDatabases.html
[3] Relational Database Theory. (2019). Archive.oreilly.com. Retrieved 12 February 2019, from http://archive.oreilly.com/oreillyschool/cours



Comments:

Alec: I really like your article. After doing research on databases, it was difficult for me to immediately envision ways that the AEC industry could directly utilize databases. I’m curious what percentage of firms use formal databases currently and how many use the idea of databases but in an informal, less efficient manner.

Ren: I enjoyed reading your take on this topic. You seemed to take a more technical approach explaining and defining the key terminologies. This was something I struggled to do as I still have not mastered databases conceptually. I think your explanation, specifically regarding the need for keys, was very thorough.

Yidi: Your article explains how databases can be utilized in the AEC industry. Similar to Alec’s article, you identify the array of data that a construction firm may need to keep track of at once, which, I agree, is certainly a place wherein databases can be utilized. My question is that for larger firms, it seems that databases are the only solution to managing this amount of data, so what are firms who aren’t using databases utilizing to keep track of their numbers? I’m curious what the alternatives are to databases. Great article though.