LAB– THE RELATIONAL DATABASE MODEL

OVERVIEW

In this lab we will learn the about the relational database model and how it is put into practice using the Microsoft SQL server instance on the IST Students server.

LEARNING OBJECTIVES

By the time the lab is complete you should be able to:

Connect to Microsoft SQL Server and log-on to your database and use its basic capabilities.

Explain the basic concepts of the relational model

Describe the relational database terminology.

Explain the importance of Entity integrity and Referential integrity

Describe how and when to use logical domain to constrain and clean data input.

Understand primary, foreign and surrogate keys

Demonstrate how to create database objects and enter data on SQL server.

Describe the characteristics of good naming conventions and explain why they are important

WHAT YOU WILL NEED

To complete this lab, you will need:

1. Your IST Students logon and password.

2. SQL Server Management Studio (or SQL Server Management Studio Express) so that you can connect to your SQL Server database. This is installed in the iSchool labs.

3. You should have completed the pre-lab “How to Connect to IST Students” If you haven’t done that lab yet, shame on you. Do it now.

LAB GOALS

This lab consists of 3 parts:

1. A Refresher course on how to connect to Microsoft SQL Server

2. A Basic overview of the Relational Model as implemented in this DBMS

3. A tour of the advanced concepts of the relational model.

1 / 16

SETUP: CONNECTING TO YOUR DATABASE ON IST STUDENTS

First connect to your database on IST Students. You should know how to do this already, but in case you don’t:

1) On your computer open SQL Server Management Studio. This program is available from the Windows Start menu.

2) Once the program launches, a Connect to Server dialog will appear.a. For server type, choose Database Engineb. For server name, enter iststudents.syr.educ. For Authentication, choose SQL Server Authenticationd. For Login enter your IST Students logon.e. For Password enter your IST Students password.f. Don’t check remember password if you’re in the iSchool labs.

3) When you’re ready, click Connect to log in to the Server. On the left-hand side of the screen, you will see the Object Explorer:

2 / 16

4) Double-Click the Databases folder to open it, and find your database. It should be the same name as your IST Students logon. When you find it, Double-click on it and you will open the objects in your database:

5) Kudos. You are now armed and dangerous!

PART 1: RELATIONAL BASICS

In this first part we’ll explore the basics of relational model as implemented in the Microsoft SQL Server Database Management System. We’ll learn about tables and table based-constraints which help us ensure our data remains “ARTC.”

1.A: OVERVIEW

Tables are the heart and soul of relational database management systems. They serve as containers for your data. The primary purpose of a DBMS is to manage data and metadata. These tables have structure (metadata) which defines what kind of data is allowed to go in them.

In this example we’re going to create a table called college_students which will contain (you guessed it) data about college students. What type of data are we talking about? How about these: Name, GPA, Class (Freshman, Sophomore, etc…), Date of Birth, and Whether or not the student is a sports fan. That should give us a great start.

1.B: CREATE YOUR F IRST TABLE

Let’s make the table we described in 1.A:

1) Right-Click on the Tables folder under your database and select New Table…

2) This will bring up a window where you can specify the columns for your table. Enter the following columns and data types for your table.

3 / 16

Be sure to clear the box titled Allow Nulls for each row. This will require you to enter values for each column you defined.

NOTE: At this step you’re creating the physical domain of the table – you’re constraining data by type. (Put a date here, put a number there, etc…)

3) Next, we need to make the student_id column a surrogate key. If you recall from class, a surrogate key is a column for which the DBMS automatically enters a unique value. To do this.

a. Click on the Column Name student_id b. Under Column properties (should be at the bottom of the window) find the property named

Identity Specification and change the (Is Identity) setting to Yes like this:

4) Double check your work. No. Scratch that - triple check it. When you think you’re done, let’s commit your table to the DBMS. This will write out your table definition and make it “permanent” (or in database lingo: persistent).

5) Now it’s time to save your table. Click in the menu File Save Table A dialog will ask you to choose a name for this table. Let’s call it college_students and click Ok

At this point you might be asking yourself: “What the #$%*&? Did I just do?” Well, you created a table (a “container” for your data). This table is metadata (it is just structure) and there are no data in the table. For example you haven’t added and students yet, just defined what it means to be a student.

6) We don’t need the table definition open anymore so let’s close it. You can do this by clicking the x on right side of your table definition:

4 / 16

7) Now let’s find our table in our database. Double-Click on the Tables folder to open it. You should see your college_students table:

Furthermore, if you Double-click on the table itself you will see all of the metadata associated with this table. In this screenshot, I’m taking a peek at the columns we just created for this table:

TANGENT: I’d like to take a minute and discuss an important side topic: conventions. If you noticed, I called the student table college_students, and I prefixed each column with “student_” for example GPA is student_gpa. You’ll also notice I used all lower_case, too. The question is why? These are known as conventions they’re not required but a good idea none the less. Conventions provide with consistency in our work, allow us to make various assumptions which subsequently make us more productive. At least that’s the story. The bottom line here is the conventions you adopt are not nearly as important as having them in the first place.

So which conventions do I use in this class?

Tables start with their schema, or domain. This helps us differentiate between college_students and kungfu_students, for example.

Tables are plural. It’s called college_students not college_student because when you open the table there’s more than one row, and each row is a….. wait for it…. Student!

Columns in tables are prefixed with the table name. This helps reduce ambiguity so you can easily tell the difference between a student_name and a course_name for example.

Since College_Students and college_students would be two different tables. All lowercase is used. Use an underscore “_” in place of spaces. This avoid delimiting like this [college student] Contraints begin with a code prefix u => unique, pk Primary Key, d default, ck check, fk

Foreign Key

5 / 16

1.C: LET’S ADD SOME DATA!

Next let’s add rows of data to our table so we can see how it all comes together:

1) To add Data interactively, Right-Click on the college_students table and select Edit Top 200 Rows

2) The edit screen will appear as follows:

Notice the NULL under student_id is greyed out. This is because it’s a surrogate key (the DBMS will provide its value).

3) Let’s add the first student, enter the following, pressing the TAB key to move from cell to cell:

Notice the pencil in the row’s margin. This indicated we’re editing the row and it has not been committed to the DBMS yet. Same with the red !. It’s telling you the data you’re seeing is not in the DBMS.

4) Once you hit the TAB key an extra time, the row is committed to the database, and the surrogate key value is revealed, too.

This data has been committed to the database table and is now permanent. It will remain there until we issue a command to remove it.

5) Next let’s learn why logical domain (something we have not added to this table) is so important. Type the following totally bogus student in the next row:

6 / 16

6) And notice how if you press TAB on more time, the DBMS gladly accepts this bogus student:

But Why is this a bad student? Can you have a 5.0 GPA? Is there such thing as a “Staleman” and can you be born in the future? No, No and No.

I hope this helps enforce the rational of logical domain. Physical domain represents what you’re allowed to enter into a column: numbers, dates, characters, etc… Logical domain takes is a step further by containing columns to only values that make sense. For example, consider:

A GPA should be between 0.0 and 4.0 Valid student classes are “Freshman”, “Sohpomore”, “Junior” and “Senior” Valid student DOB would be more than 18 years from today’s date. Also we probably don’t want two students with the same name (not realistic here, but roll with it

for now).

7) In the next section, we will learn how to add these constraints, for now let’s finish up by removing the row we just added. To Delete the row, Right-Click on the row in question, and choose Delete

8) You will be asked to confirm your delete operation. Click Yes to confirm. You should now see one row:

9) Final step: Close the table row editor by clicking the x in the upper right corner.

PART 2: IMPLEMENTING THE LOGICAL MODEL

In this final part we will re-design our database to implement the logical model, by adding database constraints. After the constraints are added we will test our changes by trying to enter sample data.

2A: ADDING A PRIMARY KEY

7 / 16

First, let’s add a primary key constraint. It’s good practice to have a primary key on every table. We learned from class a good primary key is meaningless yet guaranteed to be unique. Since we added a surrogate key we already have the perfect candidate for primary key!

1) Right-Click on the college_students table and select Design from the menu.

2) You will be back at the table designer. Right-Click on the student_id column and select Set Primary Key from the menu. You should now see this:

3) The gold key indicated you’ve set a primary key constraint on this table. Let’s commit our changes to the database by clicking in the menu File Save college_students.

4) Leave the table designer open for the next step: Adding a unique constraint.

2B: ADDING A UNIQUE CONSTRAINT

A Unique constraint says no two rows can have the same value. It’s like a primary key, but enforced over data which would not normally be used as primary key such as emails, Social Security Numbers, etc. (BTW - The reason those make for “bad” primary keys is they have significance. Good primary keys are insignificant.)

1) Let’s add a unique constraint to the student_name so that no more than one unique name can be added. From the table designer window Right-Click anywhere and choose Indexes/Keys… from the menu.

8 / 16

2) This will bring up the Indexes/Keys dialog. You should see the primary key constraint you added here.

Click the Add button to add the new constraint.3) Now change the properties of the constraint you just added.

a. Set the columns to student_name (click in the column to edit)b. Set the type to Unique Key c. Set the (name) to U_student_name when you’ve done it correctly you should see:

4) Click the Close button to dismiss the dialog, then save the table to commit the changes: menu File Save college_students.

5) Leave the table designer open for the next step: Adding a check constraint.

2C: ADDING A CHECK CONSTRAINT

Next we’ll add a check constraint. A check constraint is a logical condition which must be satisfied before a row is inserted into a table. Check constraints are used to ensure certain data conditions are met such having a GPA between 0.0 and 4.0. They really help keep inaccurate data out of the table.

9 / 16

1) Let’s create a check constraint on the student_gpa column. From the table designer Right-Click anywhere and from the context menu, choose Check Constraints…

2) This will bring up the Check Constraints dialog. Click the Add button to add a new check constraint. Thena. For expression, type: student_gpa between 0 and 4b. For the (Name), use CK_student_gpa_between_0_and_4

3) Your changes should appear as follows:

5) If things look correct, click the Close button to dismiss the dialog, then save the table to commit the changes: menu File Save college_students.

6) Final step: Close the table designer editor by clicking the x in the upper right corner.

2D: LOOKUP TABLE AND FOREIGN KEY CONSTRAINT

10 / 16

Dealing with student class (Freshman, Sophomore, Junior, Senior) poses a unique challenge as we cannot simply write a formula to constrain the text. Text, unlike dates and numbers, has no “ordinal” values. The common approach for solving this problem is to build a lookup table – a table which contains the acceptable values, and then add a foreign key constraint to the main table. The lookup table usually has the acceptable values as it’s primary key, but could also use a surrogate key as well.

In this example we’ll create a college_classes table containing one column, a primary key containing our values of Freshman, Sophomore, Junior, and Senior. We’ll then add a foreign key on the student_class column in the college_students table which enforces the desired behavior. How? Foreign keys constraints, by definition, establish referential integrity. Referential Integrity states you cannot have a value as foreign key which is not already a primary key value in the adjoining table. It’s by this magic that we are able to constrain what is entered into the student_class column!

To help you understand what’s going on here, let’s think about this conceptually (at a higher level). Any student in our college_students table is going to have one and only one class. (For example Terry Cloth is a freshman), on the other hand any row in our college_classes table can have many students. (For example there are several Seniors in our IST359 class.) When you think of the relationship between these two tables, it’s a one to many relationship - we call this the cardinality of the relationship. The foreign key constraint goes in the table on the many side, which would be the college_classes table.

1) First we’ll need to create the college_classes table. I won’t give you specifics this time, so ifI you need a refresher follow along with some of the previous steps in the lab.

a. Add one column to the table called class_name of type varchar(50) not allowing null.b. Make sure to set a primary key constraint on class_namec. Make sure to save the table as college_classes

2) When you’re done you should have something like this:

3) Close the table designer, and open the table in edit mode.4) Add the following 4 rows of data, like this:

5) After you’ve added these 4 rows close the college_classes table.6) Close the college_classes table from edit mode. Now we’re ready to add the foreign key constraint to the

college_students table. We couldn’t do this step until the college_classes table was created because a foreign key constraint requires two tables.

7) Open the college_students table in Design mode. (Just like in step 3.A.1)

11 / 16

8) Right-Click anywhere in the designer space and choose Relationships…

9) The Foreign Key Relationships dialog will appear. Click Add to create a new foreign key. Change the values of the Tables And Columns Specification by clicking on the […] button. The next dialog is an exercise in patience. Bad UI design.

a. Set the Foreign Key Base Table to college_studentsb. Set the Foreign Key Columns to student_classc. Set the Primary / Unique Key Base Table to college_classesd. Set the Primary / Unique Key Columns to class_name

10) When you’re done the dialog should look like this:

12 / 16

11) If it does click Close. Then Save your table. Woah! This time you get a warning message:

Why? Because this constraint affects both tables.12) Click Yes to save changes to the tables, then Close the Table Designer. Stick a fork in it! Its’ done.

2E: TESTING OUR CONSTRAINTS

What good are all these fancy constraints if we can put them to the test, right? Let’s take them for a spin, shall we?

1) Open the college_students table in Edit mode.2) Let’s try out our unique constraint. Enter this data:

13 / 16

3) When you press TAB to save this row, you will see this error message

Which, frankly, makes sense. We added a rule that says “no duplicate student_names” then we tried to add the same name and…. Busted.

TANGENT: This error message (or any of the SQL Error messages, for that matter) isn’t meant for the end user. For example, show this error message to your Grandmother and she’ll be confused as hell (Unless of course, your gram is an uber 1337 DBA ) Typically this error would be returned to an application, such as a website which would then be sugar coated into a more user-friendly error message. My point is these constraints are for your users, they’re your last line of defense for keeping crap data out of your database.

4) Click Ok to close the error message dialog, and you’re back in edit mode. Now let’s try out the check constraint, edit the line to look like this (edits have been highlighted):

14 / 16

5) When you press TAB this time to save, you get this error:

There’s our check constraint firing because we tried to sneak in a 5.0 GPA. Bzzt. Access denied. I love it when a plan comes together!

6) Click Ok to close the error message dialog again and you’re back in edit mode. Now let’s try out the foreign key constraint, edit the line to look like this (edits have been highlighted):

7) Press TAB to try and save and you will see the foreign key constraint fire:

This one’s a little hard to decipher, so I’ll give you my liberal interpretation. “Dude. You tried to enter ‘Staleman’ in the foreign key column but I don’t have a corresponding primary key in my college_classes table. Do not pass go. Do not collect $200.”

15 / 16

8) Nobody likes to leave on a sour note, so let’s click Ok and try once more, enter:

9) And press TAB and the row should commit. Notice the student_id column. The value isn’t a 2 it’s a 6. (Yours might be different, but there’s no way it’s a 2) Why? Well every time a constraint fires, you tried to commit the row, but it failed. With each attempt to commit, a surrogate key value is used up. The DBMS needs to do this in order to deal with the fact that normally multiple users are adding data at the same time. If it didn’t do this there’s a remote change two different people could get the same number.

This concludes our lab.

LAB QUESTIONS

1) Is a table data or metadata? Explain.

2) Throughout the lab we used the term “persist” as in persist changes to a table. What does it mean in this context?

3) What is the difference, if any, between a primary key constraint and a unique constraint?

4) What is a convention?

5) Can you control the number used by a surrogate key? Does it matter? Explain.

6) How does physical domain differ from logical domain?

7) What are your options for creating a table column which only accepts exactly 5 characters?

8) What are your options for creating a column which only accepts dates for the current year?

9) Explain how we used a lookup table in this lab.

10) Explain the term “cardinality”

16 / 16