1. Database Relationship Modeling Building Database Relationships

2. page 21/4/2014 Presentation Database Relationship Modeling Before you create a database, you must answer the following questions: What is the purpose of this database and who will use it? What tables (data) will this database contain? What queries and reports do the users of this database need? What forms do you need to create? Answering the above questions will lead you to a good database design, and help you create a database that is useful and usable.

3. page 31/4/2014 Presentation Database Relationship Modeling If you start out with poorly arranged data, you could be in big trouble down the line, trouble from which you might never recover. Even experienced database administrators have been known to discover, halfway into a project, that their data design is flawed and they have no choice but to throw out all the code they've written so far and start from scratch. As you tackle your first database, be prepared to make some mistakes.

4. page 41/4/2014 Presentation Gregs Database If Gregs friend Nigel has asked Greg to help him find a woman to date with similar interests, can he easily query the data with the table we have currently? SELECT * FROM my_contacts WHERE gender = 'F' AND status = 'single' AND state='TX' AND seeking LIKE '%single M%' AND birthday > '1970-08-28' AND birthday < '1980-08-28' AND interests LIKE'%animals% AND interests LIKE '%horse% AND interests LIKE '%movies%'; This query will take too long to write as the database grows Your table design should do the heavy lifting for you. Dont write convoluted queries to get around a badly designed table.

5. page 51/4/2014 Presentation Other options for searching Ignore the interests column – No, Interests ARE important. We shouldnt ignore them, theres some valuable information in there. Query just first interest – Only women who had animals listed first in their interests will show up in the results, using SUBSTRING_INDEX: SELECT * FROM my_contacts WHERE gender = 'F' AND status = 'single' AND state='MA' AND seeking LIKE '%single M%' AND birthday > '1950-08-28' AND birthday < '1960-08-28' AND SUBSTRING_INDEX(interests,,,1) = 'animals'; No, you may miss something from another interest column that might be important to the match. Create multiple columns to hold one interest in each – No, it makes querying even more complicated. Think about all of the AND/OR statements.

6. page 61/4/2014 Presentation We need to move the non-atomic columns in our table into new tables. Schema - A representation of all the structures, such as tables and columns, in your database, along with how they connect. Creating a visual depiction of your database can help you see how things connect when youre writing your queries, but your schema can also be written in a text format. Think outside of the single table

7. page 71/4/2014 Presentation Every time we looked at a table, we either depicted it with the column names across the top and the data below, or we used a DESCRIBE statement. Those are both fine for single tables, but theyre not very practical to use when we want to create a diagram of multiple tables. Heres a shorthand technique for diagramming the current my_contacts table: The primary key will be referenced differently in Visio.

8. page 81/4/2014 Presentation How to go from one table to two Heres our current my_contacts table. Our interest column isnt atomic, and theres really only one good way to make it atomic: we need a new table that will hold all the interests. Remove the interests column and put it in its own table. Add columns that will let us identify which interests belong to which person in the my_contacts table. We need a unique column to connect these. Luckily, since we already started to normalize it, we have a truly unique column in my_contacts: the primary key. We cant just use first and last names, what if someone else has the same name?

9. page 91/4/2014 Presentation The Foreign Key We can use the value from the primary key in the my_contacts table as a column in the interests table. Better yet, well know which interests belong to which person in the my_contacts table through this column. Its called a foreign key The FOREIGN KEY is a column in a table that references the PRIMARY KEY of another table.

10. page 101/4/2014 Presentation Foreign key facts A foreign key can have a different name than the primary key it comes from. The primary key used by a foreign key is also known as a parent key. The table where the primary key is from is known as a parent table. The foreign key can be used to make sure that the rows in one table have corresponding rows in another table. Foreign key values can be null, even though primary key values cant. Foreign keys dont have to be uniquein fact, they often arent.

11. page 111/4/2014 Presentation Foreign key facts A NULL foreign key means that theres no matching primary key in the parent table. Although you could simply create a table and put in a column to act as a foreign key, its not really a foreign key unless you designate it as one when you CREATE or ALTER a table. The key is created inside of a structure called a constraint. You will only be able to insert values into your foreign key that exist in the table the key came from, the parent table. This is called referential integrity.

12. page 121/4/2014 Presentation CREATE a table with a FOREIGN KEY

13. page 131/4/2014 Presentation Relationships between tables In the my_contacts table, our problem is that we need to associate lots of people with lots of interests. Relationships: one-to-one 1:1, one-to- many 1:M, and many-to-many M:M

14. page 141/4/2014 Presentation Types of Relationships One to one - exactly one row of a parent table is related to one row of a child table. One to many - A record in Table A can have MANY matching records in Table B, but a record in Table B can only match ONE record in Table A. Many to many A student takes many classes and a class has many students

15. page 151/4/2014 Presentation Patterns of data: one-to-one In this pattern a record in Table A can have at most ONE matching record in Table B. Say Table A contains your name, and Table B contains your salary details and Social Security Numbers, in order to isolate them from the rest of the table to keep them more secure. Both tables will contain your ID number so you get the right paycheck. The employee_id in the parent table is a primary key, the employee_id in the child table is a foreign key. In the schema, the connecting line is plain to show that were linking one thing to one thing.

16. page 161/4/2014 Presentation When to use one-to-one tables It generally makes more sense to leave one-to-one data in your main table, but there are a few advantages you can get from pulling those columns out at times: Pulling the data out may allow you to write faster queries. For example, if most of the time you need to query the SSN and not much else, you could query just the smaller table. If you have a column containing values you dont yet know, you can isolate it and avoid NULL values in your main table. You may wish to make some of your data less accessible. Isolating it can allow you to restrict access to it. For example, if you have a table of employees, you might want to keep their salary information out of the main table. If you have a large piece of data, a BLOB type for example, you may want that large data in a separate table.

17. page 171/4/2014 Presentation Patterns of data: one-to-many One-to-many means that a record in Table A can have many matching records in Table B, but a record in Table B can only match one record in Table A. The connecting line has a black arrow at the end to show that were linking one thing to many things. Each row in the professions table can have many matching rows in my_contacts, but each row in my_contacts has only one matching row in the professions table. For example, the prof_id for Programmer may show up more than once in my_contacts, but each person in my_contacts will only have one prof_id.

18. page 181/4/2014 Presentation Patterns of data: many-to-many Many women own many pairs of shoes. If we created a table containing women and another table containing shoes to keep track of them all, wed need to link many records to many records since more than one woman can own a particular make of shoe. Suppose Carrie and Miranda buy both the Old Navy Flops and Prada boots, and Samantha and Miranda both have the Manolo Strappies, and Charlotte has one of each. Heres how the links between the women and shoes tables would look.

19. page 191/4/2014 Presentation Sharpen your Pencil

20. page 201/4/2014 Presentation Sharpen your Pencil

21. page 211/4/2014 Presentation Patterns of data: a junction table As you just found, adding either primary key to the other table as a foreign key gives us duplicate data in our table. We need a table to step in between these two many-to-many tables and simplify the relationships to one-to-many. This table will hold all the woman_id values along with the shoe_id values. We need what is called a junction table, which will contain the primary key columns of the two tables we want to relate.

22. page 221/4/2014 Presentation Patterns of data: many-to-many The secret of the many-to-many relationshipits usually made up of two one-to-many relationships, with a junction table in between. We need to associate ONE person in the my_contacts table with MANY interests in our new interests table. Each of the interests values could also map to more than one person, so this relationship fits into the many-to-many pattern. The interests column can be converted into a many-to-many relationship using this schema. Every person can have more than one interest, and for every interest, there can be more than one person who shares it:

23. page 231/4/2014 Presentation Questions Do I have to create the middle table when I have many-to-many relationship? Yes, you should. If you have a many-to-many relationship between two tables, youll end up with repeating groups, violating first normal form. What if I still dont mind repeats? Joining tables helps preserve your data integrity. If you have to delete someone from my_contacts, you never touch the interests table, just the contact_interest table. Without the separate table, you could accidentally remove the wrong records. And when it comes to updating info, its also nice

24. page 241/4/2014 Presentation Name that Relationship

25. page 251/4/2014 Presentation Questions? We will have part 2 of data modeling, then examples and exercises will follow.