Consistency The DBMS must ensure the database will always be in a consistent state. Whenever data is modified, the database will change from one

Transcription

1 Data Management We start our studies of Computer Science with the problem of data storage and organization. Nowadays, we are inundated by data from all over. To name a few data sources in our lives, we have spreadsheets, s, reports, and invoices and even snail mail. Unless we have our data organized in some fashion, we will drown in our data. Since originally computers were very expensive, the first attempts to organize data were for commercial use. Businesses developed databases to organize their data. Over the past thirty years the models developed to store data have pretty much remained the same, which is remarkable considering how quickly the rest of computer technology has changed. One data model, the relational model, is, by far, the most popular model. We will explore the world of the relational data model. Database Management System and Database Design A database is where data is stored in some organized fashion. Before we examine what a database is, we must first understand where a database resides. Databases are contained and accessed through a Database Management System or a DBMS. The DBMS are the interfaces which we communicate with when accessing a database. Examples of popular DBMS s are Microsoft SQL Server, Oracle, IBM DB2, and MySQL, and Microsoft Access. DBMS Operations Supported A DBMS must provide at a minimum the following operations to a user. These operations are known by the acronym CRUD, which stand for Create, Read, Update, and Delete. That is a user must have the ability to add data, delete data, modify existing data, and to read data. DBMS Requirements In addition to operations are provided to users, a DBMS must provide the following services. These services are known by the acronym ACID, which stand for Atomicity, Consistency, Isolation, and Durability, which we will now explain. Atomicity Database transactions must be all or nothing. That means, for example, If I have a record, and I am updating fields A, B, and C in one operation, then one of two things must occur. Either fields A, B, and C are all updated or none of these are updated. There can never be the case where fields A and B are updated and C was not modified.

2 Consistency The DBMS must ensure the database will always be in a consistent state. Whenever data is modified, the database will change from one consistent state to another consistent state. In the non-database world, an example of non-consistency would be, for example, if I upload the files for my web site, but only some of the files upload. Now when people click on my web site, they get page not found. In a database, an example of a consistent state would mean that the customer in the Order table must also exist in the Customers table. Trying to create an order for a non-existent customer would make the database inconsistent and should fail. A formulation that we may derives from this is, all foreign keys (FK) must exist as primary keys (PK) in their respective tables. Isolation Isolation means that from a User s perspective, he is the only person using the database. All of the User s requests are not affected by the requests of any other User. For example, if both Aron and Beth simultaneously request that fields A, B, and C should be updated with different values, both Aron and Beth can be confident that fields A, B, and C will be updated with the values they requested. There is no guarantee whose updates will be processed last, those of Aron or Beth. But since both requests will complete, only last request will remain in the database. As an example, let s imagine making an order from Amazon.com that updates the Order table and the Product table. Particularly, I want to add an order to the Order table and at the same time decrease the quantity available on the Product table. Let s say there are 3 Oranges available for sale. Jay orders 1 orange and Sara orders 3. Both Jay and Sara attempt to access both tables. Potentially Sara can take all the oranges from the Product table, so zero oranges are available. At the very same time, Jay has created an order in the order table and either decrements the Product table creating a negative quantity or he fails creating an order with zero quantity. Durability This requires that the user is guaranteed that their data will persist. In other words, even though someone will pull the plug on the server the DBMS is running on, no data or very little data will be lost. This may also mean failover support. That is, if the main database server gets attacked by a person wielding a

3 sledge hammer, a backup server will automatically kick in and pick up where the first one left off. Need for Relational Database Design Before explaining the relational model, it is useful to understand the issues facing the database designer. By far, the most important issue facing the database designer is data duplication which can lead to data integrity issues. In general, speed is very critical, especially when dealing with real time processes, however, getting it right trumps getting it quickly. Let s imagine, I am an employer and we have a workbook for my business. My workbook contains three worksheets. One, called Assignments, lists the work assignments of all my employees. A second worksheet, called Personal, lists the addresses and contact information for all employees. A third worksheet, called Performance rates the performance of all employees. A Column common to all Worksheets is Employee Name. What happens if one of my employee s marries and changes their name, and I only change the name on one worksheet? What happens if I am in a rush and only enter employee information on one worksheet and not the others? What is to prevent me from spelling the employee name differently on different worksheets? What if someone is editing the spreadsheet and they have left for the day without closing the workbook? These examples, point to simple ways where data integrity can be lost. In addition, how do I handle historical data? Let s say I want to remember previous assignments, previous performance ratings, previous addresses? How can I implement this with a spreadsheet? The Hierarchal model You may be thinking, let s try the file cabinet solution. We will create a separate file, or in our case, a separate workbook for every employee. This way the employee name will only be in one location, the workbook name. This is actually a database design that was common before the use of the relational model. This was called the hierarchal model. The problem with this model, are fairly obvious. To view an employee s information, I have to open a separate workbook for each employee. How do I view/edit employee information for many employees? For example, to change the

4 responsibilities for all employees who live in a certain area, I have to open each workbook, find the appropriate worksheet and then change the date. If I forget to modify all the workbooks, then I have lost my data integrity. The Data Model Just like it is always better to first create an architectural design before we build a building, the same is true before we create a database. This design is called a data model. A data model is represented using an entity relationship diagram or ERD. An ERD consists of Entities, Relationships, Cardinality, Primary Keys, Attributes, Foreign Keys, and Rules. Entity An entity contains a bunch of related data consisting of many fields of data. The fields in an Entity should all have some relevance to the overall entity. For example, the Student entity may have fields like First Name and Address. It should not have a field called Course Attended as this field doesn t really describe the student. It does describe what the Student has studied and should be in a different entity called Courses Attended. Primary Key Each entity has one or more fields that uniquely identify that identity. These fields are known as the Primary Key (or PK) for that entity. For example, the Student entity may have Student ID as it s PK while the Courses Attended entity will have Course ID and Student ID as its PK. Attributes All fields in an entity are known as attributes of that entity. Relationships Entities almost never exist by themselves. Almost always they have relationships with each other. For example, the Student entity will relate to the Courses Attended entity. One without the other is not very useful. Cardinality and Rules These define exactly what relationship two entities have with each other. For example, if a Student may take many classes at the same semester, there will exist a one to many relationship between the Student entity and the Courses Attended entity. If a Class can be taken by more than one student at a time, there will exist a one to many relationship between the between the Courses Attended entity and the Student entity. Foreign Keys The way that entities point to each other is by placing their Primary Key inside other entities. Keys for entities outside the entity they are located are called foreign keys, since they point to other entities. For

5 example, the Primary Key for Courses Taken will be the combination of the Student ID field and the Class ID field. Student ID and Class ID are themselves primary keys of their respective Student and Class tables. Each Courses Taken entity will therefore point to a specific student and a specific class. Relational Model - The relational model is how a data model translates into a relational database. Entities become tables, Keys and attributes become columns, and cardinalities become data constraints. Below is an example of an Entity Relationship Diagram or ERD. ERD of Class Enrollment

6 The Relational Model A short explanation of the Relational Model. At its basic level, the relational model consists of tables that can relate to each other. A table is a grid consisting of at least one column and zero or more rows. Usually all the data in each column must be of the same type. For example: All data in the Salary column must be of type Money; All data in the Name column is of type String; and all the data in the Date Started column are of type Date. The relational model allows tables to relate or join with each other so that data in different tables can be usable together. For example: I can view John Smith s name from the Employee table, together with his salary from the Salary table, and his job title from Human Resources table at one time without having to access each table looking for his record. The Relational Model addresses data integrity issues using the following rule. Data, whenever possible, should only exist once in the database. Another rule that follows is, whenever data will be repeated we place this data in its own table removing data duplication. You are probably wondering, how John Smith can be in three or more tables without violating the rule that data should only appear once! The answer is that we add a row in the table which will contain his name, e.g. the Employee table, and then I will add another column or columns that will uniquely identify John Smith throughout the database. For Example, in the Employee table, I will create a column called Employee ID of type Number. The Employee ID will be a unique value. Only John Smith with get this ID. In fact, each employee in the Employee table will get their own Employee ID. So, in the Employee table we will have a row with both John Smith and his Employee ID. In all the other tables where we wish to refer to John Smith, we will use John s Employee ID not his name. We mentioned, the relational model allows us, in fact requires us to have many tables. Why do we need all these tables? Why not put all our data in one table? The following example illustrates the need and advantage of having multiple tables. Using our Employee example, let s start with following data as is seen in the table below. We have the following columns: Name, Salary, Salary Start Date, Position, and Position Start Date. When we add a new position, because of the table design we are forced to repeat ALL the date from the previous row even though this data is unchanged. Not only are we wasting space, but, even worse, we are duplicating data (See highlighted data below).

7 One Huge Table Name Salary Salary Start Date Responsibility Resp. Start Date John 100 1/1/2010 Asst. Mgr. 1/1/2015 John 100 1/1/2010 Manager 1/1/2016 Fred 200 1/1/2014 CEO 1/1/2014 Fred 400 1/1/2015 CEO 1/1/2014 So what is the solution? Let s create three tables. An Employee Table, a Salary Table, and a Responsibility table. In addition, we will need a new column called Employee ID. This process, breaking up one table into multiple tables, is called Normalization. Employee Employee ID Name 1 John 2 Fred Salary Employee ID Salary Salary Start Date /1/ /1/ /1/2015

8 Responsibility Employee ID Responsibility Resp. Start Date 1 Asst. Mgr. 1/1/ Manager 1/1/ CEO 1/1/2014 Primary Key Now that we have separated our data into separate tables, how do we get our data back? How do we view all the information that exists about Fred and John? First we need a way to identify which rows belong to Fred and which to John. In general, we need a way to uniquely identify every row in a table. We do this by creating or identifying a column or columns that uniquely identify every row. This column or group of columns is called the Primary Key. Every table requires a primary key. In the tables above, I have shaded the columns that comprise the primary key in orange. Retrieving and Modifying Data from Tables SQL (Structured Query Language) is the language which we speak with relational databases. The basic SQL language has very few words and can quickly be mastered. Below are the SQL statements needed to perform basic CRUD (Create, Read, Update, Delete) operations on the Employee table. Create INSERT INTO Employee ([Employee ID], Name) VALUES (1, John ) Read SELECT Name FROM Employee WHERE Employee ID] = 1 Update UPDATE Employee SET Name = Johnny WHERE Employee ID] = 1

9 Delete DELETE FROM Employee WHERE Employee ID] = 1 What about retrieving data from multiple tables? As we can see from the figure below, by connecting those rows with identical primary keys of each row, we end with the following result. Result of Joining All Three Tables Name Salary Salary Start Date Responsibility Resp. Start Date John 100 1/1/2010 Asst. Mgr. 1/1/2015 John 100 1/1/2010 Manager 1/1/2016 Fred 200 1/1/2014 CEO 1/1/2014 Fred 400 1/1/2015 CEO 1/1/2014

10 Below is an example using SQL in a database type MySql. USE FALL2016; DROP TABLE STUDENTS; CREATE TABLE STUDENTS ( STUDENTID int NOT NUll, FIRSTNAME varchar(50), LASTNAME varchar(50), PRIMARY KEY(STUDENTID)); SELECT * FROM `STUDENTS` WHERE STUDENTID = 1; INSERT INTO STUDENTS SELECT 1, 'Fred', 'Friendly'; INSERT INTO STUDENTS SELECT 2, 'Sara', 'Saranson'; INSERT INTO STUDENTS SELECT 3, 'Boris', 'Borison'; DELETE FROM STUDENTS WHERE STUDENTID = 1; UPDATE STUDENTS SET FIRSTNAME = 'Larry' WHERE STUDENTID = 3; SELECT * FROM STUDENTS;