Copyright © 1998-2011 Curt Hill
Entities and Relationships
The basics and what they have to do with database
Copyright © 1998-2011 Curt Hill
Entities and Relationships• Entity
– Usually a real world thing• College: faculty, course, students
– Each entity has attributes• People have names, ages• Courses have names, hours, times
• Relationship– A logical connection between two or
more entities– These may have attributes
Copyright © 1998-2011 Curt Hill
Relationships
• In mathematics a relation is an represented by an ordered n-tuple
• Each record is an ordered n-tuple– Every table expresses relationship– Table is a file with just one record
type
• Relationships may span tables
Copyright © 1998-2011 Curt Hill
Relationship Arity or Cardinality
• How many are on either side of the relationship
• One to one– A person and SSN– Keys need this arity
• One to many– Instructor to student in a course
• Many to many– People to organizations– Hardest to represent
Copyright © 1998-2011 Curt Hill
Table Use• We use a table to collect a group
of entities of the same type– The student table
• The attributes of the relationship form the fields of a record
• One to one relationships are just a field in the table
• One to many relationships and many to many relationships are often their own table
Copyright © 1998-2011 Curt Hill
ER Model• The Entity-Relationship model
helps us to think about and design a database
• The only data in a database consists of entities, relationships and their attributes
• Helps us to bridge the gap between informal user desires to a formal database design
Copyright © 1998-2011 Curt Hill
Entity-Relationship Diagrams• A pictorial mechanism to show
what is going on• Not standardized
– They come in many variations
• Entities – rectangles• Attributes – ovals• Relationships – diamonds• Connections – lines
Copyright © 1998-2011 Curt Hill
A simplified ER diagram
Licenses
Manufacturer
Dealer
Car
Shipper
Builds
Stocks
Contracts
Transports
Copyright © 1998-2011 Curt Hill
A manufacturing ER diagram
• Last one had no attributes for several reasons
• Often that is how we get started– Refine as we go along
• These tend to be both formal and informal
• The graphic had no space
Copyright © 1998-2011 Curt Hill
ER diagram Again
Licenses
Manufacturer
Dealer
Name Address
TypeStartDate
Address
Fee
Name
MID
Lines
DID
LID
Copyright © 1998-2011 Curt Hill
Legend on the above• Two perpendicular lines indicate an
arity of one• Terminating with three lines indicates
an arity of many• Underlined name indicates key
– There may be more than one
• Relationships do not have to be between just two different types of entities– Binary, ternary, n-ary– One or more different tables
Variants
• The above diagram is often called Crow’s Foot diagram– The arity relationship is done using
crow’s feet or perpendicular lines
• The alternative is called Chen notation– This must 1,n,m to identify
Copyright © 1998-2011 Curt Hill
Copyright © 1998-2011 Curt Hill
ER diagram Again
Licenses
Manufacturer
Dealer
Name Address
TypeStartDate
Address
Fee
Name
MID
Lines
DID
LID
1
M
Copyright © 1998-2011 Curt Hill
Participation Constraints
• Total: every record in the table participates in this relationship– All manufacturers have dealers– Usually a heavy line
• Partial: there may be some records without this relationship– Suppose dealers includes used car
dealers– Some have no license from a
manufacturer– Denoted by a light line
Copyright © 1998-2011 Curt Hill
Some Definitions
• Entity set– Any set of similar entities– Could be a whole table or subset of
this table’s records
• Relationship set
Copyright © 1998-2011 Curt Hill
Steps for DB Design
• Requirements• Conceptual• Logical• Schema Refinement• Physical Design• Application• Security
Copyright © 1998-2011 Curt Hill
Requirements
• What to find– What data is needed– What applications will be needed
• How to go about it– Interview the staff– Study any prior systems
Copyright © 1998-2011 Curt Hill
Conceptual
• When the requirements are understood, then take a shot at the high level design
• This is a high level approach• A simple model is required since it
must be understood by non-technical personnel
Copyright © 1998-2011 Curt Hill
Logical
• Choose a DBMS• Translate conceptual design into a
schema supportable by the DBMS– Table definitions– Relationships– Primary and foreign keys
Copyright © 1998-2011 Curt Hill
Schema Refinement
• It is never perfect the first time• Put the tables in the desired
normal form• There are objective techniques to
drive the process
Copyright © 1998-2011 Curt Hill
Physical Design
• Performance is the key in this step• What expected usage will be• Where to use indexing or other
performance enhancements or re-factor the tables
Copyright © 1998-2011 Curt Hill
Applications
• The requirements of the applications that interface with the database cause the last refinement
• These applications may interface with the web as well
Copyright © 1998-2011 Curt Hill
Security
• Tailoring the views with security in mind
Top Related