Lecture-2 - Relational Model.pptx

Editor's Notes

• #3: The Relational Model is more than 35 years old, and it's really the foundation of database management systems. It's spawned a many billion dollar industry. The relational model underlies all commercial database systems at this point in time. It's actually an extremely simple model and that's one of its benefits. Furthermore, it can be queried. By that it means we can ask questions of databases in the model using High Level Languages. High Level Languages are simple, yet extremely expressive for asking questions over the database. And finally, very importantly there are extremely efficient implementations of the relational model and of the query languages on that model.
• #17: The schema of a database is the structure of the relation. So the schema includes the name of the relation and the attributes of the relation and the types of those attributes. Where the instance is the actual contents of the table at a given point in time. So, typically you set up a schema in advance, then the instances of the data will change over time.
• #21: There's also a special value that's in any type of any column and that's a special value known as null, and nulls are actually quite important in relational databases. Null values are used to denote that a particular value is maybe unknown or undefined. Let's say, student named Usman, for whatever reason, doesn't have a GPA. Maybe Usman is home schooled, maybe Usman doesn't want to reveal his GPA. So then the database would contain a null value for Usman. Or, for example, maybe Ali doesn't want to have his photo in the database, so then Ali would have a null value for his photo, again nulls can go anywhere. Now null values are useful but one has to be very careful in a database system when you run queries over relations that have null values. So, let's suppose we're asking a query over our student table of all students whose GPA is greater than 3.5. So when we run that query on our database obviously we'll get Ali out, obviously we won't get Ahmed out, but should we get Usman? The answer is No. We don't know for a fact that Usman's GPA is greater than 3.5, so we'll only get one student out from that query. Now let's suppose we had another query, where we were gonna ask for the GPA less than or equal to 3.5. So, similarly where we would not have Ahmed in result and we would certainly have Ali in the result and similarly would not have Usman in the result because we don't know that his GPA is less than or equal to 3.5. So far so good, but it gets a little weird is when we add an or here in our query, we say I want everyone who's GPA is greater than 3.5 or who's GPA is less than or equal to 3.5. And even though it looks like every tuple should satisfy this condition, that it's always true, that's not the case when we have null values. So, that's why one has to be careful when one uses null values in relational databases.
• #26: Let's move on to our next concept which is the concept of Key. Key is again another important concept in relational databases. And, a key is an attribute in of a relation where every value for that attribute is unique. So if we look at the student relation, we can feel pretty confident that the ID is going to be a key. In other words, every tuple is going to have a unique for ID. Thinking about the University relation, it's a little less clear. You know what, we're allowed to have sets of attributes that are unique and that makes sense in the University relation. Most likely the combination of the name and city of a university is unique, and that's what we would identify as the key for the University relation. Now, you might wonder why it's even important to have attributes that are identified as keys. There's actually several uses for them. One of them is just to identify specific tuples. So if you want to run a query to get a specific tuple out of the database you would do that by asking for that tuple by its key. And related to that database systems for efficiency tend to build special index structures or store the database in a particular way. So it's very fast to find a tuple based on its key.
• #33: Okay, just to wrap up, how one creates relations or tables in the SQL language. It's very simple, you just say "create table," give the name of the relation and a list of the attributes. And if you want to give types for the attributes. It's similar except you follow each attribute name with its type. So to wrap up, the relational model has been around a long time. Has started a huge industry. It's used by all database systems. As you've seen it's a very simple model and will shortly see that it can be queried with very nice languages. And, finally, it's been implemented very efficiently. Definitely
• #35: So, the first step is to design the schema of the database and then create the schema using a data definition language. So as we discussed in previously in a relational database the schema consists of the structure of the relations and the attributes of those relations. So we set those up inside our big disk. Once that's ready, the next step is to load up the database with the initial data. So it's fairly common for the database to be initially loaded from data that comes from an outside source. Maybe the data is just stored in files of some type, and then that data could be loaded into the database. Once the data is loaded, then we have a bunch of tuples in our relation. Now, we're ready for the fun part which is to query and modify the data. And so that happens continuously over time as long as the database is in existence. So let's just say for now that we're going to have human users that are directly querying the database. In reality, that typically happens through say an application or a website. So, a user will come along and we'll ask a question of the database and we will get an answer. He might come along and ask another question Q2 and he'd get another answer back. The same human or maybe a different human might ask to modify the database. So, they might want to insert new data or update some of the data and the database will come back and say, "Okay, I made that change for you." So that's the basic paradigm of querying and updating relational databases.
• #37: Relational databases support ad hoc queries and high-level languages. By ad hoc, we mean that you can pose queries that you didn't think of in advance. So it's not necessary to write long programs for specific queries. Rather the language can be used to pose a query as you think about what you want to ask. And as mentioned in previously the languages supported by relational systems are high level, meaning you can write in a fairly compact fashion rather complicated queries and you don't have to write the algorithms that get the data out of the database. So, let's look at an example of a few queries. Let's go to our imaginary database of students who are applying to universities. And here's just three examples of the types of things that you might ask of a relational database. You might want to get all students whose GPA is greater than 3.7 who are applying to Comsats and NUST only. You might want to get all engineering departments in ISB with fewer than 500 applicants or you might ask for the university with the highest average accept rate over the last five years. Now these might seem like a fairly complicated queries but all of these can be written in a few lines in say the SQL language or a pretty simple expression in relational algebra. So, some queries are easier to pose than others, that's certainly true. Though the 3 queries you see here are as I said pretty easy to pose. Now some queries are easier for the database system to execute efficiently than others. And interestingly it's not necessarily. These two things aren't necessarily correlated. There are some queries that are easy to post but hard to execute efficiently and some that are vice-versa. Now, just a bit about terminology. Frequently, people talk about the “query language” of the database system. That's usually used sort of synonymously with the DML or Data Manipulation Language which usually includes not only querying but also data modifications.
• #38: In all relational query languages, when you ask a query over a set of relations, you get a relation as a result. So let's run a query Q say over these three relations shown here and what we'll get back is another relation. When you get back the same type of object that you query, that's known as closure of the language. And it really is a nice feature. For example, when I want to run another query, say Q2, that query could be posed over the answer of my first query and could even combine that answer with some of the existing relations in the database. That's known as compositionality, the ability to run a query over the result of our previous query. Now, let me talk briefly about two query languages. We'll be learning these languages in detail later, but I'm just going to give the basic flavor of the languages here. Relational algebra is a formal language. Well, it's an algebra as you can tell by its name. So it's very theoretically well-grounded. SQL by contrast is what I'll call an actual language or an implemented language. That 's the one you're going to run on an actual deployed database application. But the SQL language does have as its foundation relational algebra. That's how the semantics of the SQL language are defined.
• #40: Now let me just give you a flavor of these two languages and I'm going to write one query in each of the two languages. Let's start in relational algebra. So we're looking for the ID's of students whose GPA is greater than 3.7 and they've applied to Comsats. In relational algebra, the basic operators language are Greek symbols. Again, we'll learn the details later, but this particular expression will be written by a Pi followed by a Sigma. The Pi says we're going to get the ID, the Sigma says we want students whose GPA is greater than 3.7 and the university that the students have applied to is Comsats. And then that will operate on what's called the natural join of the student relation with the apply relation. Again, we'll learn the details of that in later. Now, here's the same query in SQL. And this is something that you would actually run on a deployed database system, and the SQL query is, in fact, directly equivalent to the relational algebra query.
• #41: View is the result set of stored queries .