A Brain-Friendly Guide

Head First

Dra
Load important concepts directly into your brain Avoid embarrassing mistakes

SQL

ft V ers

A learners companion to database programming using SQL

ion

Master out of this world concepts

Learn what matters, when it matters

Bend your mind around dozens of puzzles and exercises

# Lynn Beighley
this is a new chapter

Head First SQL

by Lynn Beighley Copyright 2007 OReilly Media, Inc. All rights reserved. Printed in the United States of America. Published by OReilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. OReilly Media books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (safari.oreilly.com). For more information, contact our corporate/institutional sales department: (800) 998-9938 or [email protected].

Printing History:
August 2007: First Edition.

The OReilly logo is a registered trademark of OReilly Media, Inc. The Head First series designations, Head First SQL, and related trade dress are trademarks of OReilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and OReilly Media, Inc., was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and the authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.

Dra

ISBN-10: 0-596-52684-9 ISBN-13: 978-0-596-52684-9 [M]

ft V ers

ion

7 multi-table database design

Outgrowing your table

Dra

My little man is growing up. Maybe hell finally move out.

ft V ers

ion

Sometimes your single table isnt big enough anymore. Your need for data has grown, and that one table youve
harder to write. Youve gone as far as you can go. Its a big world out there, and sometimes you need more than one table to contain your to data, control it, and ultimately, be the master of your own database. been using just isnt cutting it. Your SELECTs are getting messy and

this is a new chapter

one-to-one relationships

Relationships between tables

We know how to connect the tables through foreign keys now, but we still need to consider how the tables relate to each other. In the my_contacts table, our problem is that we need to associate lots of people with lots of interests. This is one of three possible patterns youll see again and again with your data: onetoone, onetomany, and manytomany and once you identify the pattern your data matches, coming up with the design of multiple tablesyour schemabecomes simple.

Patterns of data: onetoone

Lets look at the first pattern, onetoone,and see how it applies. In this pattern a record in Table A can have at most ONE matching record in Table B. So, say Table A contains your name, and Table B contains your salary details and Social Security Numbers, to isolate them from the rest of the table to keep them more secure.

Dra
employees
first_name Beyonce Shawn Shakira

Both tables will contain your ID number so you get the right paycheck.

ft V ers
Table A ONE of these records
last_name Knowles Carter Ripoll ssn 234567891 345678912 123456789

Table B

Each person in employees can only have one Social Security number, and each SSN maps to only one person. One person, one SSN, makes this a onetoone relationship.
employee_id 1 2 3

ion
matches up TO
salary
2 5 7

ONE of these records

salary_level

employee_id 6 35 1

tionship, since These tables also have a onetoone relaemployee_id, is the primary key of the employee table, ry table. being used as the foreign key of the sala
2
Chapter 7

multi-table database design

Patterns of data: when to use onetoone tables

So we should be putting all our onetoone columns in new tables?

Dra

Actually, no. We wont use one-to-one tables all that often. There are only a few reasons why you might connect your tables in a one-to-one relationship.

When to use onetoone tables

It generally makes more sense to leave those rare one-to-one columns in your main table, but there are a few advantages you can get from pulling those columns out at times:

1. Pulling the data out may allow you to write faster queries. For example, if most of the time you needed to query the SSN and not much else, you could query just the smaller table. 2. If you have a column containing values you dont yet know, you can isolate it and avoid NULL values in your main table. 3. 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.

ft V ers

ion

One-to-One: a single table, or (sometimes) two tables related with primary and foreign keys.
you are here 4

one-to-many relationships

Patterns of data: onetomany

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.

Table A

Table B

ONE of these records

The state column in my_contacts is a good example of a one-to-many relationship. Each person has only one state in the state column for his address, but more than one person in my_contacts may live in any given state. In this example, weve moved the state column to a new child table, and changed the state column in the parent table to a foreign key, the state_id column. Since its a one-to-many relationship, we can use the state_id in both tables to allow us to connect them.

Dra
matches up TO

One record in Table A can match MANY records in Table B, but any one record of Table B can only match ONE record in Table A.

ft V ers
states state state_id

MANY of these records

One-to-Many: split the data into two tables related with primary and foreign keys.

ion

my_contacts last_name first_name phone email gender birthday profession city

contact_id

The connecting line has a black arrow at the end to show that were linking one thing to many things. Each row in the states table can have many matching rows in my_contacts, but each row in my_contacts has only one matching row in the states table. For example, the state_id for California may show up more than once in my_contacts, but each person in my_contacts will only have one state_id.

Because the st can repeat, thisate_id be a primary key.cant is a foreign key beThis it references a ke cause another table.. y from

state_id status seeking

Chapter 7

multi-table database design

Patterns of data: getting to manytomany

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.

woman_id 1

Dra
Carrie 2 3 4 1 2 3 4 Carrie

woman

Samantha Charlotte Miranda

Imagine they loved the shoes so much, the women all bought a pair of the shoes they didnt already own. Heres how the links from women to each shoe names would look then.

ft V ers
1 2 3 4 1 2 3 4

shoe_id

shoe_name Manolo Strappies Crocs Clogs Old Navy Flops Prada Boots

woman_id

woman

shoe_id

ion

shoe_name

Manolo Strappies Crocs Clogs Old Navy Flops Prada Boots

Samantha Charlotte Miranda

Can you say: Duplicate records? How can we fix the tables without putting more than one value in a column and winding up like Greg did with his queries for Regis?
you are here 4