24
CSE 156 1 Designing Relational Databases Stephen Scott

Designing Relational Databases

  • Upload
    trent

  • View
    59

  • Download
    0

Embed Size (px)

DESCRIPTION

Designing Relational Databases. Stephen Scott. Introduction. Now that we know basic database terminology, it’s time to delve into designing one - PowerPoint PPT Presentation

Citation preview

Page 1: Designing  Relational Databases

CSE 156 1

Designing Relational Databases

Stephen Scott

Page 2: Designing  Relational Databases

CSE 156 2

Introduction

• Now that we know basic database terminology, it’s time to delve into designing one

• The problem: given a text-based description (specification) of a design problem, come up with a concrete specification of the database and the SQL statements to implement it

• Where to begin????

Page 3: Designing  Relational Databases

CSE 156 3

The General Process1. Identify the entities (tables), and the attributes (fields)

that are associated with each one• Kind of like naming the objects in a software design problem• E.g. a winery is an object, and each has a name

2. Identify the relationships between the entities, and their cardinality

• E.g. a wine comes from a single winery, but one winery makes multiple wines

3. Use this information to build an initial entity-relationship (ER) model

• A graphical representation of our database• Represents each entity, their attributes, and the relationships

(including cardinality) between the entities

Page 4: Designing  Relational Databases

CSE 156 4

The General Process (cont’d)4. Identify or add a primary key for each table

• Must be unique• Many possibilities• Keep it simple, if possible!

5. Label the weak entities of the ER model• Entities that depend on other entities

6. Convert the ER model to SQL• Start with regular entities, then the weak ones, then

do the relationships: one-to-one, then one-to-many, then many-to-many

Page 5: Designing  Relational Databases

CSE 156 5

An Example SpecificationThe owner of a local scuba store wants to track his customers and their purchases. Each customer has a first and a last name and has a highest certification level (e.g. Open Water, Advanced OW) from some agency (e.g. PADI, NAUI, SSI). Also, each customer has purchased a (possibly empty) set of items from {BCD, regulator, wet suit, dry suit, mask, tank, fins, snorkel}, but at most one item of each type. Each such item has a manufacturer, and multiple manufacturers make similar items. Each manufacturer has a name and address. For simplicity, assume that each manufacturer makes only one item of each type.

•(Also assume that store owner is insane and destroys all serial numbers and other identifying information on each product.)

Page 6: Designing  Relational Databases

CSE 156 6

Step 1

• What are the entities and their attributes?

Page 7: Designing  Relational Databases

CSE 156 7

Step 1• What are the entities and their attributes?

1. Customer– First name (string)– Last name (string)

2. Certification – Level (one of {Open Water, Advanced OW, …})– Agency (one of {PADI, NAUI, SSI, …})

3. Item– Type (one of {BCD, regulator, …})

4. Manufacturer– Name (string)– Address (string)

Page 8: Designing  Relational Databases

CSE 156 8

Step 2

• What are the relationships between the entities?

Page 9: Designing  Relational Databases

CSE 156 9

Step 2• What are the relationships between the entities?

1. A customer has a certification level– Each customer has one highest level, and each

level can be held by multiple customers One-to-many

2. A customer purchases items– Each customer can purchase multiple items, and

each item can be purchased by multiple customers

– E.g. each customer can own 0 or more from {BCD, regulator,…}, and a regulator can be owned by multiple customers Many-to-many

Page 10: Designing  Relational Databases

CSE 156 10

Step 2 (cont’d)• What are the relationships between the entities?

3. An item is made by a manufacturer– Each item has only one manufacturer, but a manufacturer

can make multiple items One-to-many

Page 11: Designing  Relational Databases

CSE 156 11

Step 3: Initial ER Model

• Entities represented by rectangles• Attributes represented by ellipses,

connected to entities by lines• Relationships represented by diamonds• Lines connect entities to relationships,

cardinality labeled by letters

Page 12: Designing  Relational Databases

CSE 156 12

Step 3: Initial ER Model

customer item

manufacturer

buys

makes

first name last name itemtype

address

name

M N

1

N

has

certification

level

agency

1

N

Page 13: Designing  Relational Databases

CSE 156 13

Step 4: Primary Keys

• Combination of level and agency uniquely defines a certification

• Customer may not be uniquely identified by first and/or last name, so we’ll add a customer ID (int)Even if combination is unique for each customer, a

numeric ID is less prone to spelling errors when inserting, querying, etc.

• We’ll do the same with manufacturer• With respect to a particular manufacturer, type

uniquely identifies item– More on this later

Page 14: Designing  Relational Databases

CSE 156 14

Step 4: Primary Keys

customer item

manufacturer

buys

makes

first name last name itemtype

address

name

M N

1

NcustID

manufacIDhas

certification

level

agency

1

N

Page 15: Designing  Relational Databases

CSE 156 15

Step 5: Label Weak Entities

• Are there any entities that cannot exist without another?

Page 16: Designing  Relational Databases

CSE 156 16

Step 5: Label Weak Entities• Are there any entities that cannot exist without

another?– A manufacturer and a customer and a certification can

each exist on its own– An item cannot exist unless it is manufactured (but it

doesn’t depend on a customer)• So item fully participates in the makes relation, and is connected

by a double line

– Also, type uniquely defines an item, but only when a manufacturer is specified (since multiple manufacturers make e.g. BCDs, but each manufacturer only makes one)

• So item is a weak entity and gets a double box

Page 17: Designing  Relational Databases

CSE 156 17

Step 5: Label Weak Entities

customer item

manufacturer

buys

makes

firstname lastname

address

name

M N

1

NcustID

manufacID

itemtype

has

certification

level

agency

1

N

Page 18: Designing  Relational Databases

CSE 156 18

Step 6: Convert to SQL1. Regular (non-weak) entities:CREATE TABLE customer ( customerID int NOT NULL AUTO_INCREMENT, firstname varchar(30) NOT NULL, lastname varchar(30) NOT NULL, PRIMARY KEY (customerID) ) type=MyISAM;

CREATE TABLE manufacturer ( manufacID int NOT NULL AUTO_INCREMENT, name varchar(50) NOT NULL, address varchar(100) NOT NULL, PRIMARY KEY (manufacID) ) type=MyISAM;

CREATE TABLE certification ( level enum(‘Open Water’,’Advanced OW’,’Rescue Diver’,. . .) NOT NULL, agency enum(‘PADI’, ‘NAUI’, ‘SSI’, . . .) NOT NULL, PRIMARY KEY (level,agency) ) type=MyISAM;

Page 19: Designing  Relational Databases

CSE 156 19

Step 6: Convert to SQL (cont’d)

2. Weak entity:– item is uniquely identified if manufacturer is

also specified, so add manufacID as a primary key for item

CREATE TABLE item ( itemtype enum(‘BCD’,’regulator’,’wet suit’,. . .)

NOT NULL, manufacID int NOT NULL, PRIMARY KEY (manufacID,itemtype) ) type=MyISAM;

Page 20: Designing  Relational Databases

CSE 156 20

Step 6: Convert to SQL (cont’d)3. No one-to-one relationships, so do one-to-many:

– The idea is as follows: if a certification can be held by multiple customers, then we need to relate each customer to the held certification

– Easiest way is to add certification’s primary key(s) to item, to serve as foreign keys:

CREATE TABLE customer ( customerID int NOT NULL AUTO_INCREMENT, firstname varchar(30) NOT NULL, lastname varchar(30) NOT NULL, level enum(‘Open Water’,’Advanced OW’,’Rescue Diver’,. . .) NOT NULL, agency enum(‘PADI’, ‘NAUI’, ‘SSI’, . . .) NOT NULL, PRIMARY KEY (customerID) ) type=MyISAM;

– We have a similar case for the makes relation, but in this case we don’t need to update the item table, since we already added manufacID to it (since item was weak)

– Note that if item were not weak, then we would add manufacID as a foreign (but not primary) key, to capture the relationship

Page 21: Designing  Relational Databases

CSE 156 21

Step 6: Convert to SQL (cont’d)

4. Many-to-many relationships:– Each item can be purchased by multiple customers,

and each customer can purchase multiple items– Thus we need to be able to relate each customer to

multiple purchases, and vice-versa– Create a new table that takes the primary keys of the

related entities as its primary keys– Note that since item is weak, one of its primary keys

is manufacID, so we need to add that as well

Page 22: Designing  Relational Databases

CSE 156 22

Step 6: Convert to SQL (cont’d)

4. Many-to-many relationships (cont’d):CREATE TABLE purchase ( itemtype enum(‘BCD’,’regulator’,’wet suit’,. . .)

NOT NULL, manufacID int NOT NULL, customerID int NOT NULL, PRIMARY KEY (manufacID,itemtype,customerID) )

type=MyISAM;

(Where’d the AUTO_INCREMENT go?)

Page 23: Designing  Relational Databases

CSE 156 23

Final Notes

1. Relationships can have attributes as well!– E.g. if a purchase has a date

CREATE TABLE purchase ( itemtype enum(‘BCD’,’regulator’,’wet suit’,. . .)

NOT NULL, manufacID int NOT NULL, customerID int NOT NULL, dateofpurchase timestamp(8), PRIMARY KEY (manufacID,itemtype,customerID) )

type=MyISAM;

Page 24: Designing  Relational Databases

CSE 156 24

Final Notes (cont’d)In ER diagram:

(could also add date and certification number to “has” relationship)

2. Also, be careful about one-to-one relationships!– Ask if they’re really necessary

customer itembuysM

N

dateofpurchase