Odorizzi - B5 Relational Database Theory

Relational Database theory was developed by E.F. Codd, detailed in his first publication in 1969. The simplest and most generic definition of relational databases that I found is as follows: “A persistent storage mechanism that enables you to both store data and optionally implement functionality.”

I am going to organize this post the way I approached my reading - by gradually building my understanding of what a database is, the terminology associated with a database, and how a relational database layers a large degree of functionality.

I started by gaining a sense of what is a database? A major source of the information I’m going to talk about came from an online textbook, “An Introduction to a Relational Database Theory” by Hugh Darwin (2010). Darwin defines a database as “an organized, machine-readable collection of symbols, to be interpreted as a true account of some enterprise. A database is machine-updatable too, and so must also be a collection of variables.” The symbols that Darwin refers to is what we would typically think of as data, which is classified by attributes that describe the data - which is how I interpret his statement about “a true account of some enterprise”

With regard to relational databases, I learned that an important distinction to clarify is the difference between a ‘table’ and a ‘relation,’ both of which look like your standard datatable. However, the distinction is that a ‘relation’ consists of data that is definitively associated with each other. In Figure 1.6 from Darwin’s book, the attribute values can be read across the relation like a sentence: “A student named Anne has a student ID of S1 and is registered for Course ID C1.” This sentence is intuitively derived by looking at the ‘relation.’ A ‘table’ on the other hand can be a ‘relation,’ but does not necessarily have any association between the entries, as can be seen in Figure 1.5 from Darwin’s book. A relational database is one that organizes data into a collection of relations.

Databases are maintained by Database Management Systems (DBMS), and relational databases are specifically maintained by Relational Database Management Systems (RDBMS). As a user, we interact with the RDBMS, not the database. The chain of operations involves a command being generated from a application program and the RDBMS responding to the commands. This could involve executions such as alterations to the database (create, destroy, update, or constrain variables) or the supply of queries (results from the database). RDBMSs are typically operated on a server such that multiple concurrent users can be supported.

The power of relational databases becomes evident when behavior is established between the attributes of the database. At the simplest level, RDBMS can be used for storage, retrieval, deletion, security, and integrity of data within a database. This can quickly expand in complexity as numerous relations can be linked together to invoke specific procedures for storing data entries within the database, processing the data, etc.

I know I’m only skimming the surface of relational database theory and its capacity, but I think this gives a general overview of the potential and workings of a relational database.

Citations:

Darwin, Hugh. “An Introduction to Relational Database Theory.” booboon.com.  2010.

<https://dvikan.no/ntnu-studentserver/kompendier/an-introduction-pto-relational-database-theory.pdf>

“Relational Databases 101: Looking at the Whole Picture.”  Agiledata.org.  2018.

<http://www.agiledata.org/essays/relationalDatabases.html>

Comments:

To Sarah Hollis:

Having only just heard of SQL in passing in my reading for this post, thank you for giving a nice overview! I had heard of VBA coding in Excel - but I did not realize that SQL was a language used majorly by Microsoft. It sounds like SQL is immensely powerful as a consequence of its key commands that you listed. I wonder what the equivalent code would require if java or c++ would be used instead. I do not have any experience in any of these languages - but if SQL is backed by ANSI and is standardized, it must have significantly more power.

To Zac Arnold

Nice use of your personal experience to offer some insights into database usage in the industry. I know on my co-op, there was one job that I was on CA for where we would use dropbox as a tool to share files between subcontractors, but the official submittals for shop drawings would be processed through Newforma. You talked about a lot of databases that I have previously had no exposure to. It seems remarkable to catalog and schedule out every activity of a construction project, but makes complete sense from an efficiency standpoint. The ability to access real-time data in the field through CMiC also seems immensely powerful. The flow of information into and out of that database must be extremely complex!

To Sherry Xiaoyu Liu

Great post! This was very informative and broke down the concepts of Object Oriented Databases very fundamentally. I had a post on relational databases, so it was interested to mark the differences in their structures. I would be interested to see the applications that use Object Oriented Databases. From your last statement, databases such as University course registration databases (transactional data) would be better suited for relational databases. I still don’t have a sense of which applications would be best suited for object oriented databases. Regardless, I think the object structure is very interesting. Breaking down the classification of every object into state and behavior are two very large umbrellas to cover all of the attributes of an object.