0% found this document useful (0 votes)
41 views

Fundamentos de SQL

The document discusses ER modeling and outlines the lecture on L08 which covers ER modeling concepts including entities, attributes, relationships and cardinalities as well as examples of how to represent these concepts using both Chen notation and Crow's feet notation for ER diagrams. It also provides an overview of the database design process which involves requirements analysis, conceptual design using ER modeling, and logical, physical, and security design.

Uploaded by

Victor
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
41 views

Fundamentos de SQL

The document discusses ER modeling and outlines the lecture on L08 which covers ER modeling concepts including entities, attributes, relationships and cardinalities as well as examples of how to represent these concepts using both Chen notation and Crow's feet notation for ER diagrams. It also provides an overview of the database design process which involves requirements analysis, conceptual design using ER modeling, and logical, physical, and security design.

Uploaded by

Victor
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 60

L08: ER modeling

CS3200 Database design (sp18 s2)


2/5/2018

2
Announcements!
• Jupyter: setup on your laptops, we start using next week
• HW3 solutions: posted earlier (no FMs)
• Confidential or anonymous questions on HW?
- please post on Piazza "visible to instructors only"
• Anonymous question to instructor only: Google feedback form
• Exam1 (Mon Feb 12): Laptop, BlackBoard, Postgres, SQL only. Vote:
- Variant 1: closed book, one letter cheatsheet allowed
- Variant 2: open book, more time-constrained, graded very carefully

• Outline
- HW2
- ER modeling
3
HW2

4
Company/Product 395

Company Product
cid pname
cname price
city cid

5
Big IMDB schema (Postgres)

Genre Movie Movie_directors Directors


mid id did id
genre name mid fname
year lname

Casts
pid
mid
Actor
role
id
fname
lname
gender

6
ER modeling

7
Data modeling and Database Design Process
name
1. ER Diagram
Conceptual Model: Patient patient_of Doctor
("technology independent")
describe main data items zip name dno

2. Relational Database Design


Logical Model
("for relational databases"):
Tables, Constraints
Functional Dependencies
Normalization:
Eliminates anomalies
3. Database Implementation
Physical Model
Physical storage details
Result: Physical Schema
8
Database Design
• Database design: Why do we need it?
- Agree on structure of the database before deciding on a particular implementation

• Consider issues such as:


- What entities to model
- How entities are related This the first project
- What constraints exist in the domain
- How to achieve good designs

• Several formalisms exist


- We discuss two flavors of E/R diagrams
• Chen notation: Stanford GUW book
• Crow feet notation
9
Database Design Process
1. Requirements Analysis 2. Conceptual Design 3. Logical, Physical, Security, etc.

1. Requirements analysis
- What is going to be stored? Technical and non-
technical people are
- How is it going to be used? involved
- What are we going to do with the data?
- Who should access the data?

10
Database Design Process
1. Requirements Analysis 2. Conceptual Design 3. Logical, Physical, Security, etc.

2. Conceptual Design
- A high-level description of the database
- Sufficiently precise that technical people can understand it
- But, not so precise that non-technical people can’t participate

This is where E/R fits in.


11
Database Design Process
1. Requirements Analysis 2. Conceptual Design 3. Logical, Physical, Security, etc.

3. More:
- Logical Database Design
- Physical Database Design
- Security Design

12
Database Design Process
1. Requirements Analysis 2. Conceptual Design 3. Logical, Physical, Security, etc.

E/R Model & Diagrams used


This process is
iterated many
name times
name category
price
Product Makes Company

E/R is a visual syntax for DB design which is precise enough for


technical points, but abstracted enough for non-technical people
13
Interlude: Impact of the ER model
• The E/R model is one of the most cited articles in Computer Science
- “The Entity-Relationship model – toward a unified view of data” Peter
Chen, 1976

• Used by companies big and small


- You’ll know it soon enough

• "Chen notation": different from "UML"

14
Some comments on
Notations

15
Different sources, different notations

16
Comparison of ERD frameworks A variant of
"UML"
Chen's Crow's Feet

Strong entity Entity name Entity name

Weak entity Entity name Entity name

Entity with attributes Entity name Entity name

Attribute name
Attribute name Attribute name Attribute name
Attribute name
Attribute name

17
Comparison of ERD frameworks A variant of
"UML"
Chen's Crow's Feet

Strong entity Entity name Entity name

Weak entity Entity name Entity name

Entity with attributes Entity name Entity name

Attribute name
Attribute name Attribute name Attribute name
Attribute name
Attribute name
Color is not part
of the standard…
18
Attributes
Chen's Crow's Feet

Attribute Attribute Name Entity name


PK attribute Attribute Name PK attribute Attribute name
Attribute name
Derived attribute Attribute Name Attribute name
Composite attribute (Attribute name,
Multi-valued attribute Attribute Name Attribute name)
Attribute name
Composite attribute
Attribute Name Derived attribute [Attribute name]
{Attribute name}
Attribute Name Attribute Name Multi-valued attribute …
Attribute Name

19
Relationships

20
Types of Binary Relationships

21
Redo this ER diagram with Crow's feet notation

Source: Janusz Szczypula, 95703 Database Management, 2011.


22
Source: Janusz Szczypula, 95703 Database Management, 2011.
24
Modeling Notation

Source: Table A-1, Hoffer et al, 10th ed, 2010.


25
Modeling Cardinality/Optionality Notations

Source: Table A-1, Hoffer et al, 10th ed, 2010.


26
Crow's feet notation and alternatives

Source: http://en.wikipedia.org/wiki/Entity-relationship_model
27
IMDB movie database in Lucidchart

28
Entities

29
Entities and Entity Sets
• Entities & entity sets are the primitive unit of the E/R model

- Entities: the individual objects, which are members of entity sets


• Ex: A specific person or product

- Entity sets: the classes or types of objects in our model


• Ex: Person, Product
• These are what is shown in E/R diagrams - as rectangles
• Entity sets represent the sets of all possible entities

Product
These represent entity sets
Person
30
Entities and Entity Sets
• An entity set has attributes
- Represented by ovals attached to an entity set

Shapes are important.


Colors are not.
name category
price
Product

31
Entities vs. Entity Sets
Entities are not explicitly
• Example: represented in E/R diagrams!

Entity
name category

Name: Xbox
price
Category: Total Name: My Little Pony Doll Entity
Multimedia System Category: Toy
Attribute Product
Price: $250 Price: $25

Product

Entity Set

32
Keys
• A key is a minimal set of attributes that uniquely identifies an entity.

Denote elements of the Here, {name, category} is not a key (it


primary key by underlining. is not minimal).

name category If it were, what would it mean?


price
Product

The E/R model forces us to designate a single primary key, though there
may be multiple candidate keys 33
33
Identifiers (Keys)
• Identifier (Key): An attribute (or combination of attributes) that
uniquely identifies individual instances of an entity type
- Can be simple or composite
- Will not be null
- Will not change in value
• e.g., family name, or telephone number, or street address, if those can change over
time (say through marriage...)
- Substitute new, simple keys for long, composite keys
• Candidate Key: an attribute (or set of) that could be a key…satisfies
the requirements for being a key
• Primary Key
34
Naming Entities
Poor Examples Good Examples
FormerStudentFromIowa Student
Customers Customer
ClientsWhoCameToBigEvent Employee
ObscureRecmdForFrtherAction Invoice
Order Purchase Order
Flight
• Guidelines for naming entity types:
- Use singular nouns
- Names should be specific to the organization
- Be concise
- Abbreviations are ok, as long as they are standardized
- Event entity types should be named for the result of the event (e.g., "Order")
- Be consistent

35
Exercise (Part I): Entities / Attributes
• Identify the entities that appear on the report card
• Identify the attributes of each previously identified entity

Source: Hoffer, Ramesh, Topi, "Modern database management," 10th ed, 2010.
36
Attributes
• A property or characteristic of an entity type

• Classifications of attributes:
- Identifier Attributes
- Required versus Optional
- Stored versus Derived
- Single-Valued versus
Multivalued Attribute
- Simple versus Composite

Source: Hoffer, Ramesh, Topi, "Modern database management," 10th ed, 2010.
37
Example: Describe the Attributes

Multivalued
Attribute (e.g.,
SQL, Python, ...)

Derived
Attribute

Source: Hoffer, Ramesh, Topi, "Modern database management," 10th ed, 2010.
38
Naming Attributes
Poor Examples Good Examples
TheDayThatThisPersonEnrolled Date
Birth_Date
NumEnrollInSpecificClass NumberEnrolled
Student_Names StudentName
ClientLastName CourseID
Employee_ID

• Guidelines for naming attributes:


- Be concise
- Use singular nouns or noun phrases
- Names should be unique (at least within an entity type)
- Follow a standard format (e.g., either Camelcase or "_")
- Similar attributes should use the same qualifiers and classes
(e.g., CustomerID, ProductID)
39
Example: modeling flights
• Assume you want to model "flights"
• Attributes: FlightNumber, Date, NumberOfPassengers
• What would be the key / identifier?

40
Example: modeling flights
• Assume you want to model "flights"
• Attributes: FlightNumber, Date, NumberOfPassengers
• What would be the key / identifier?

41
Identifier Examples: Simple and Composite
• Simple identifiers:
- Single attribute uniquely
identifies each entity instance
- Identifier attribute underlined

• Composite identifiers:
- Multiple attributes required to
uniquely identifies each entity
instance
- Identifier attribute underlined
and composite attributes listed
below in (parentheses)

Source: Hoffer, Ramesh, Topi, "Modern database management," 10th ed, 2010.
42
Example: modeling time-dependent data
• Assume you have an entity "product"
• The price can change over time
• You would like to preserve the history of prices and the time period

43
Example: modeling time-dependent data
• Assume you have an entity "product"
• The price can change over time
• You would like to preserve the history of prices and the time period

44
Example: modeling time-dependent data
• Assume you have an entity "product"
• The price can change over time
• You would like to preserve the history of prices and the time period

Time-stamping is
commonly done with
a multi-valued and
composite attribute
(or associative
entities: see later)
Source: Hoffer, Ramesh, Topi, "Modern database management," 10th ed, 2010.
45
Relationships

46
The R in E/R: Relationships
• A relationship is between two or more entities

name name
category
price
Product Makes Company

47
name category
name

price
makes Company
Product

stockprice

buys employs

Person

address name ssn


48
What is a Relationship?
• A mathematical definition: B=
A= 1 a

- Let A, B be sets 2 b
• A={1,2,3}, B={a,b,c,d} c
3
d

49
What is a Relationship?
• A mathematical definition: B=
A= 1 a

- Let A, B be sets 2 b
• A={1,2,3}, B={a,b,c,d} c
3
d
- A x B (the cross-product) is the set of all pairs (a,b)
• A  B = {(1,a), (1,b), (1,c), (1,d), (2,a), (2,b), (2,c), (2,d), (3,a), (3,b), (3,c), (3,d)}

50
What is a Relationship?
• A mathematical definition: B=
A= 1 a

- Let A, B be sets 2 b
• A={1,2,3}, B={a,b,c,d}, c
3
d
- A x B (the cross-product) is the set of all pairs (a,b)
• A  B = {(1,a), (1,b), (1,c), (1,d), (2,a), (2,b), (2,c), (2,d), (3,a), (3,b), (3,c), (3,d)}

- We define a relationship to be a subset of A x B


• R = {(1,a), (2,c), (2,d), (3,b)}

51
What is a Relationship?
• A mathematical definition: B=
- Let A, B be sets A= 1 a

- A x B (the cross-product) is the set of all pairs 2 b


- A relationship is a subset of A x B c
3
d

• Makes is a relationship: it is a subset of Product  Company:

makes Company
Product

52
What is a Relationship?

name name
category
price
Product Makes Company

A relationship between entity sets P and C is a


subset of all possible pairs of entities in P and C, with
tuples uniquely identified by P and C’s keys

53
What is a Relationship?

Company Product

name name category price


GizmoWorks Gizmo Electronics $9.99
GadgetCorp GizmoLite Electronics $7.50
Gadget Toys $5.50

name name
category
price
Product Makes Company

A relationship between entity sets P and C is a


subset of all possible pairs of entities in P and C, with
tuples uniquely identified by P and C’s keys
54
What is a Relationship?

Company C × Product P
Company Product

name name category price C.name P.name P.category P.price

GizmoWorks Gizmo Electronics $9.99 GizmoWorks Gizmo Electronics $9.99

GadgetCorp GizmoLite Electronics $7.50 GizmoWorks GizmoLite Electronics $7.50


Gadget Toys $5.50 GizmoWorks Gadget Toys $5.50
GadgetCorp Gizmo Electronics $9.99
GadgetCorp GizmoLite Electronics $7.50
GadgetCorp Gadget Toys $5.50
name name
category
price
Product Makes Company

A relationship between entity sets P and C is a


subset of all possible pairs of entities in P and C, with
tuples uniquely identified by P and C’s keys
55
What is a Relationship?

Company C × Product P
Company Product

name name category price C.name P.name P.category P.price

GizmoWorks Gizmo Electronics $9.99 GizmoWorks Gizmo Electronics $9.99

GadgetCorp GizmoLite Electronics $7.50 GizmoWorks GizmoLite Electronics $7.50


Gadget Toys $5.50 GizmoWorks Gadget Toys $5.50
GadgetCorp Gizmo Electronics $9.99
GadgetCorp GizmoLite Electronics $7.50
GadgetCorp Gadget Toys $5.50
name name
category
price
Product Makes Company
Makes

C.name P.name
A relationship between entity sets P and C is a GizmoWorks Gizmo
subset of all possible pairs of entities in P and C, with GizmoWorks GizmoLite
tuples uniquely identified by P and C’s keys GadgetCorp Gadget
56
What is a Relationship?
• There can only be one relationship (instance) for every
unique combination of entities This follows from our
mathematical
definition of a
• This also means that the relationship is uniquely relationship- it’s a SET!

determined by the keys of its entities


KeyMakes = KeyProduct ∪ KeyCompany

• Example: the “key” for Makes (to right) is


{Product.name, Company.name} name
since name
category
price
Product Makes Company

Why does this make sense?


57
Relationships and Attributes
• Relationships may have attributes as well.

since name
name category
price
Product Makes Company

For example: “since” Note: “since” is Note #2: Why not


implicitly unique per “how long”?
records when company
pair here! Why?
started making a product

58
Decision: Relationship vs. Entity?
• Q: What does this say?
date

name category name

price

Product Purchased Person

• A: A person can only buy a specific product once (on one date)

Modeling something as a relationship makes it unique; what if


not appropriate?
59
Decision: Relationship vs. Entity?
• What about this way?

date PID# quantity

name
name category Purchase

price
ProductOf BuyerOf
Product Person

• Now we can have multiple purchases per product, person pair!

We can always use a new entity instead of a relationship. For example, to


permit multiple instances of each entity combination!

60
Overview: 3 important concepts for relationships

• Cardinality ("arity"): number of entity instances


that participate (~mainly max)

• Participation constraints:
mandatory or optional (equivalent to
minimum cardinality 0 or 1)

• Degree: number of entity


types that participate

Random question: Why "relational model"?


61
Relations
Definition: Let A and B be sets. A binary relation from A to B
is a subset of AB.
Example: R = {(1, 2), (1, 3), (1, 4), (2, 3), (2,4), (3,4)}
(R = {(a, b) | a < b} with a, b from A=B={1, 2, 3, 4})

A B
Definition of Function:
1 1 4 X X X For nonempty sets A
and B, a function f from
3 X X A to B, denoted f:AB,
2 2 is a relation from A to B
2 X in which every element
of A appears exactly
3 3 B 1 once as the first
component of an
R 1 2 3 4 ordered pair in the
relation.
4 4
A
62

You might also like