agenda for week 1/31 & 2/2
DESCRIPTION
Agenda for Week 1/31 & 2/2. Learn about database design Vocabulary Modeling tool: Entity relationship diagram (ERD) Practical modeling concepts Do database design Practice creating ERD’s Primarily from “draftsman” perspective. Database Design. - PowerPoint PPT PresentationTRANSCRIPT
Agenda for Week 1/31 & 2/2
Learn about database design Vocabulary Modeling tool: Entity relationship diagram
(ERD) Practical modeling concepts
Do database design Practice creating ERD’s Primarily from “draftsman” perspective
1
2
Database DesignGoal for the database design section of the
class: Be able to design a “good” database for a business application.
Objectives: Know how to read, understand, and create a
database model using a modeling tool - ERD’s. Understand the three reasons we store data in a
database. Know the process of completing a database design. Understand the structure and limitations of the
relational model. Know how to identify and differentiate the required
components of a database design.
3
What is database design?
Database design is the process of planning the structure or blueprint of stored data for an organization.
Process of database design
Can be understood from three different perspectives: Architect: Planning types of data necessary
to achieve the goals of the system. Engineer: Identifying detailed data
requirements and designing the structure of the data.
Draftsman: Creating a model to depict the data that will be stored in a database.
4
5
Data design is documented with a data model
Most commonly used data modeling tool is an entity-relationship diagram (ERD).
An ERD contains: Entities. Attributes. Identifiers (primary key for each entity). Relationships. Cardinalities of the relationships. Foreign keys to support the relationships.
6
All About Entities Entities are nouns that describe the person, event,
place, or thing about which we want to store data. The name of an entity is singular, not plural. Examples:
customer, book, order, invoice, employee, supplier. An entity usually becomes a table in a database. An entity instance is a single occurrence of an entity (a
row in a table, or a record in a file). Entities almost always have more than one entity
instance. (Tables have more than one row – it is not common to create a table that has only one row.) For example, you might be interested in storing information
about the “chief financial officer” of an organization. If there is just one CFO, then you wouldn’t create an entity for CFO, you would create an entity for “employee” and figure out another way to store the fact that a specific employee is the CFO.
7
Attributes
An attribute is a characteristic or property of an entity.
Synonyms include: Element, property or field.
Examples of attributes for an “employee” entity: Last name, First Name, Employee ID, Address,
City, State, Zip, Phone, Title, Starting employment date.
Attributes can be: Stored vs. derived. Simple or complex.
8
Identifying Attributes (Identifiers)
An attribute that could uniquely identify an instance of an entity is called a “candidate key”. A candidate key that the analyst chooses to uniquely
identify an instance of an entity is called a “primary key”.
Primary keys are also referred to as identifiers.Sometimes more than one attribute is needed to
uniquely identify an instance of an entity. A group of attributes identifying an entity instance is
called a “concatenated key.” Synonyms for concatenated key are “composite key”
and “compound key”.
Primary keys
Each entity must have a primary key.Two basic types of primary key:
“Natural” primary key: primary key is created from existing attribute or attributes.
“Surrogate” primary key: primary key is a “made up” attribute that has no function other than serving as a primary key.
For right now, we are going to try and use natural primary keys as much as possible.
9
10
A bit about relationships
Entities do not usually exist in isolation. A connecting line between two entities on an ERD
represents a relationship.A relationship can be depicted as a diamond or
as a simple line.A relationship is a natural business association
existing between two or more entities.A relationship creates a business rule.A verb phrase describes the relationship.
11
Cardinality of a relationship
Cardinality is a constraint on the number of entity instances that participate in a relationship.
Cardinality describes the minimum and maximum number of instances that one entity has with another entity in a relationship.
Cardinality also describes whether the relationship is mandatory or optional.
We use the crow’s foot notation to depict cardinality in our ERD’s in this class.
purchase order has item
man married_to woman
purchase order is_placed_with supplier
Examples: Binary relationship with explicit relationship symbol
man woman
purchase order supplier
is married to
is placed with
purchase order line item item
has contains
Examples: Binary relationship without explicit relationship symbol
employee
manages
Examples of Unary Relationships
inventory item
Person
Is married to
is part of
Employee Equipment
Assignment
Workspace
Isassigned
Is assigned
Isassigned
Example of a ternary relationship
location
patient
employee
test
treatmentvisit
Example of an n-ary relationship
Example of a context ERD
patient
treatment
employee
item
gets treatmentfrom
givestreatment to
provides atreatment for a
patient
has a
is had by
is provided by anemployee for a
patient
is managedby
is acomponent
of
location
isavailable
is usedfor
Context DataModel
Example of a logical ERD
Example of a Physical ERD
Patient
PK patientID
name address
Location
PK locationID
description address billing_code
PatientTreatment
PK patienttreatkey
date timeFK1 patientIDFK2 locationIDFK3 treatmentIDFK4 employeeID results
Treatment
PK treatmentID
insurance_code signup_dateFK1 itemID
Item
PK itemID
description
ItemComponent
PK ItemComponentKey
componentIDFK1 itemID quantity
Employee
PK employeeID
name office phoneFK1 mgrID
manages
has
Is delivered
at
Is given
by
Is of
usesIs
composed of
Strong entity
A strong entity is an entity that exists whether or not there is a relationship between it and another entity.
For example, you probably want to store data about employees, regardless of the fact that an employee provides services to a patient at a clinic.
20
21
“Weak” or Associative Entities
An entity that does not exist unless it is linked to a strong entity.
For example, the patient treatment entity doesn’t exist unless a patient has a treatment.
On a logical ERD, a weak entity frequently borrows all or part of its primary key from another entity.
22
Orderid
OrderDate
CustName
Itemid
ItemName Itemcost
Sellprice
Quantity
1234 08/30/2011 Jones A72 Martini Glasses – 4 pack 7.50 19.95 12
1234 08/30/2011 Jones A43 Tumbler, 12 oz – 8 pack 9.20 22.95 16
3900 08/26/2011 Smith A72 Martini Glasses – 4 pack 7.50 19.95 5
3900 08/26/2011 Smith B33 Ketchup Dispensers – 12 pack
8.70 25.95 22
3900 08/26/2011 Smith B97 Salt Shakers – 2 pack 2.20 9.95 3
8911 08/29/2011 Resco A43 Tumbler, 12 oz – 8 pack 9.20 22.95 35
8911 08/29/2011 Resco A72 Martini Glasses – 4 pack 7.50 19.95 235
Return to First Week Exercise Data (condensed)
23
Need for Associative Entity
M:n relationship cannot be stored without data redundancy. A m:n relationship usually has attributes that are part of the
relationship. In the example below, you must decide where to store the quantity ordered for a given item on a given order.
Intersection entity is used to divide a m:n relationship.
Order
PK order_ID
order_date cust_name
Item
PK item_id
name item_cost sell_price
has
Is on
OrderID Order_date CustName
1234 08/30/2011 Jones
3900 08/26/2011 Smith
8911 08/29/2011 Resco
ItemID Name Itemcost
Sellprice
A72 Martini Glasses – 4 pack 7.50 19.95
A43 Tumbler, 12 oz – 8 pack 9.20 22.95
B33 Ketchup Dispensers – 12 pack 8.70 25.95
B97 Salt Shakers – 2 pack 2.20 9.95
25
Possible Solution #1: Put the quantity ordered (qty_ordered) in the item entity, and create a concatenated primary key
OrderID Order_date CustName
1234 08/30/2011 Jones
3900 08/26/2011 Smith
8911 08/29/2011 Resco
OrderID ItemID Name Itemcost
Sellprice
Quantity
1234 A72 Martini Glasses – 4 pack 7.50 19.95 12
1234 A43 Tumbler, 12 oz – 8 pack 9.20 22.95 16
3900 A72 Martini Glasses – 4 pack 7.50 19.95 5
3900 B33 Ketchup Dispensers – 12 pack 8.70 25.95 22
3900 B97 Salt Shakers – 2 pack 2.20 9.95 3
8911 A43 Tumbler, 12 oz – 8 pack 9.20 22.95 35
8911 A72 Martini Glasses – 4 pack 7.50 19.95 235
Possible solution#1: Results in redundant data for item name, cost and sell price
Possible solution #2: Uses an intersection entity (Orderline) to avoid redundant data.
28
OrderID Order_date CustName1234 08/30/2011 Jones
3900 08/26/2011 Smith
8911 08/29/2011 Resco
ItemID Name Itemcost
Sellprice
A72 Martini Glasses – 4 pack 7.50 19.95A43 Tumbler, 12 oz – 8 pack 9.20 22.95B33 Ketchup Dispensers – 12 pack 8.70 25.95B97 Salt Shakers – 2 pack 2.20 9.95
OrderID ItemID Qty_ordered
1234 A72 12
1234 A43 16
3900 A72 5
3900 B33 22
3900 B97 3
8911 A43 35
8911 A72 235
Possible Solution #2: Another table, but less data redundancy
Foreign Key
A way of supporting the relationship between two tables.
The primary key of one table is added to another table to link the two tables together.
In a 1:M relationship, the primary key of the entity on the “1” side of the relationship is added to the entity on the “M” side of the relationship.
29