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.
Kerry,
ReplyDeleteGreat breakdown of the database language and design system. I learned as much from your post as I did in the first few weeks of my INFO 210 class. All joking aside, learning the logic behind SQL and other databases is very interesting to me and beneficial because it helps us think as engineers. Even if database design isn't something we will be doing post graduation, being able to visualize how a system will look solely off of a word problem is a skill that is invaluable to us.
Kerry,
ReplyDeleteYour post was very helpful and allowed me the opportunity to be able to understand what a relational database is, especially since I did not have to take INFO 210. I think what helped me the most was the examples you provided after describing the 3 types of relations table can have. One question I still have though would be when is a many to many relationship needed or useful? You had mentioned the complexity of creating and that putting another table together to reduce this complexity.
Kerry,
ReplyDeleteThank you for this post, it was like a light-bulb turning on above my head. The source I had used was describing some database strategies using the term "one to many" and I had no idea what they were trying to say, but your topic cleared up what they mean in terms of a database. Between your post and Sherry's, I think I have a decent idea of these types of databases, although I am still a bit fuzzy on the differences between the two. The relational database does seem to drive the SQL model that I had looked into for my blog post, as every command is based on relationships and using them to narrow down the data that you want.
Kerry,
ReplyDeleteThis is a good introduction about relational database for someone who does not take INFO 210, or take a course in database management system. It looks like relational database has been a standard for constructing a data set for years, and most of our presentations involving with tabulated information uses relational database to present. Your examples are familiar about processing everyday data using relational database, which reduces the abstraction of theoretical discussion. Great work!
Kerry,
ReplyDeleteI remembered learning about relational database theory from INFO 210 and I think you did a really good job summarizing it and getting the key points across. I brought up these types of databases in my blog post for the week. I think that these databases are easy to implement and that SQL is a language that can be easily picked up. Relational databases exist everywhere and I talked about RS Means online as an example of a database in the construction field.
Kerry M,
ReplyDeleteYour post on relational database theory was very interesting! I also took the INFO 210 class, and I think you did a really good job describing what a database is. Knowing that most of our class hasn’t taken that class, your post was very clear and informative for people who don’t know anything about databases. With the emergence of Dynamo, I feel like relational databases would be used more and more in our field.