Relational databases are something many of us learned about in our first database management class – INFO 210. To understand relational database theory, it is important to first understand what a database is. A database is a collection of organized information, or data, all related to a central idea or topic. Digital databases hold this information digitally, either on a hard drive or in cloud storage.
A relational database is a type of digital database. The relational database is based on the relational model of data. The relational model of data is centered around the idea of tables. There are a set of tables, each of which has its own category, containing the data that makes up the database. The data is organized into rows (tuples) and columns (attributes). Each row is one instance of data, containing information about each attribute relative to that data line. Each row contains a unique identifier, or key, to identify it from the other rows. Relational databases are easy to reorganize and enter or delete data from due to their structured nature. The central idea in relational databases is that these separate tables are connected, or related, in specific ways via keys or constraints. The related set of tables come together to create the database.
Tables can be related in several ways. Two tables can have a one to one, one to many, or many to many relationship between them. In a one to one relationship, the primary key of each unique tuple appears in each table exactly once. An example of this would be a table with information about a student and a table with information about their university ID card. Each student has only one university ID card, and each university ID card is issued to only one student. In a one to many relationship, a primary key exists only once in one table, and potentially many times in the second table. An example of this would be a table with information about a student and a table with information about college departments. Each student is only a part of one department, but a department can potentially have many students within it. In a many to many relationship, a primary key can appear potentially many times in both tables. An example of this would be a table with information about students and a table with information about clubs. A student can be part of potentially many clubs, and a club can have potentially many students as part of it. In this case, it is best to create an intermediate table between the two to eliminate the complex many to many relationship.
The structured query language (SQL) is based on relational database theory. This language is used for all querying and maintenance of the relational database. A query is a request for information from the database. The results returned from the query show a subset of all of the data within the database that fits within the constraints applied in the query statement.
Sources
Comments
Sarah: I used SQL in one of my database classes, but I didn't know some of the things you discussed in your post! For example, I didn't know that SQL was unique in that it is able to access more than one data file with one command. One thing you note is that SQL is relatively easy to learn due to its few and simple commands, and I definitely agree with that. It was a really easy language to learn, it was really intuitive. This makes it accessible to many people, and improves people's understanding of databases.
Zac: Your take of storage and sharing systems as databases was an interesting one. These types of systems are not something I would have considered a database, but I suppose as compared to the definition you provide from Wikipedia that they can be considered a type of database. These systems are absolutely a necessity in the construction industry, specifically in estimating and project management as you mentioned. I think your example of a scheduling database is a really great one. Specifically thinking of it in terms of a relational database, each activity can have information related to its specific instance in the schedule, as well as information related to it as an activity in general.
Sherry: As I was reading your first paragraph I came to the same conclusion as you - it is quite difficult to understand the difference between object oriented databases and relational databases when I'm not even sure I know what an "object" is. After reading your post, I'm still a little fuzzy about what exactly an object is, but I understand much more than before reading! I think one of the difficulties in understanding object oriented databases is that, compared to relational databases, they are a lot less intuitive. We use tables all the time, and understand how to fill data into a table in a meaningful way. Without that concrete structure, objects are a little more difficult to understand.
Sarah: I used SQL in one of my database classes, but I didn't know some of the things you discussed in your post! For example, I didn't know that SQL was unique in that it is able to access more than one data file with one command. One thing you note is that SQL is relatively easy to learn due to its few and simple commands, and I definitely agree with that. It was a really easy language to learn, it was really intuitive. This makes it accessible to many people, and improves people's understanding of databases.
Zac: Your take of storage and sharing systems as databases was an interesting one. These types of systems are not something I would have considered a database, but I suppose as compared to the definition you provide from Wikipedia that they can be considered a type of database. These systems are absolutely a necessity in the construction industry, specifically in estimating and project management as you mentioned. I think your example of a scheduling database is a really great one. Specifically thinking of it in terms of a relational database, each activity can have information related to its specific instance in the schedule, as well as information related to it as an activity in general.
Sherry: As I was reading your first paragraph I came to the same conclusion as you - it is quite difficult to understand the difference between object oriented databases and relational databases when I'm not even sure I know what an "object" is. After reading your post, I'm still a little fuzzy about what exactly an object is, but I understand much more than before reading! I think one of the difficulties in understanding object oriented databases is that, compared to relational databases, they are a lot less intuitive. We use tables all the time, and understand how to fill data into a table in a meaningful way. Without that concrete structure, objects are a little more difficult to understand.
