Download ER model

CSE 880:Database Systems
ER Model and Relation
Schemas
1
Major Steps for Database Design and
Implementation
1. Requirements Collection and Analysis:
Produces database requirements such as types of data,
types of updates, data flow and states, types of transactions, etc. Process may include survey questionnaire, interviews with new and existing users and
key personnel, study exiting operations and operating documents.
2. Conceptual Database Design:
Produces a conceptual schema for the database. Meet
with a few people who are knowledgeable and experts
in the application domain to detail out the design.
This includes defining entity types relationship types,
constraints, etc. (ER model). This does not include implementation details related to a particular
database system.
3. Logical Database Design:
Produces logical schema for a specific database system by mapping conceptual schema into a data model
available for implementation. For example, relational
2
tables may be defined from ER diagram in this step.
This may be done in two steps. First use general
mapping rules to create tables from the ER diagram
and then map these tables into the available database
system.
4. Physical Database Design:
Storage structure design, creating indices, clustering, partitioning and placement of database files, etc.
One of the criteria used in physical database design
is to optimize performance.
5. System Implementation and Performance
Tuning:
After the logical and the physical designs are completed, database system is implemented. Schemas
are defined in the database system using DDL. Compiling and loading databases are done. Check for
database integrity. Perform further performance tuning. (Performance tuning is an ongoing process normally handled by a database administrator)
3
An Example Requirements
Specification
(Conceptual Database Design)
Consider the following set of requirements for an Employees
database that is used to keep track of employees information for a company.
1. The database should keep track of an employee’s id,
social security number, address and phone number,
birth date, sex, supervisor, department, Salary and
projects.
2. The department has the following information: department id, department name, department locations,
phone, employees, number of employees, manager,
projects.
3. Projects has the following information: Project title,
project number, project manager, employees working
on the project, department controlling the project.
4. Employee dependents has the following information:
Dependent name, BDate, relationship to employee.
5. What is the next step?
4
Entity Relationship (ER) Model
(Conceptual Database Design)
1. ER model describes data as entities, relationships, and attributes.
2. entities: object with independent existence.
entity: <Student ID:s1, Student name: John, Student address: 10 elm street>
not an entity: <student ID:s1, student name: John, Student address: 10 elm street, Depatment name: CSE, Department Tel. NO.: 517-353-3010> Department information can exists by itself without being with student information.
3. relationship: Student belonging to a department is a relationship between a student entity and a department entity.
4. Attributes: particular property that describes an entity:
Student ID is an attribute of the entity for student.
Student name is another attribute.
5. An ER diagram for the above:
ID Name address
ID Name Tel. No
\
|
/
\
|
/
---------------|student| -- students department--- |department|
---------------5
Why ER Model?
1. Data requirements specification is first captured by
using an ER model, and then ER model is mapped
into relational data model.
2. Why use ER model first?
• Real world information is more naturally mapped
into ER model than into relational data model.
• In relational data model many data relationships
are captured through data values at query time
using programs while in ER diagram these relationships are explicit in Data definition.
• ER model is pictorial and more comprehensive.
• ER model can be more easily reviewed and modified at design time than relational data model.
6
Examples Comparing Relational
Model and ER model
• Semantic that the name is a composite attribute such
as first, middle and last names cannot be captured by
relational model but can be captured in ER model.
• In relational data model Employees and Departments
are related through the foreign keys (referential integrity constraint) while in ER diagram this relationship is more explicit.
• For a company database, data such as Employees
and Departments objects exist by themselves while
the fact that an employee belongs to a department
depends on the existence of the employee and the
corresponding department object. In other words,
Employees and Departments objects exist independently while an employee belongs to a department is
a relation between them. Similarly, in a STUDENT
database Students and Courses objects can exist by
themselves while the fact that a student taking a
particular course can be created only after the Students and Courses objects are created. This difference in semantics between entity and relationship of
7
real word information is more naturally captured by
ER model than in relational model by considering
Employees and Departments as entity types and the
information ”an employee works for a department”
as the relationship between Employees and Departments. Similarly, in STUDENT database Students
and Courses are created as entity types and the information ”a student taking a course” is a relationship
between Students and Courses.
• An example of an ER diagram:
Figure 3.2. (Elmasri/third Edition)
8
Definitions
1. Entities and Entity types:
• Entity:
An object that has independent existence.
Example:
in a Company database Employee object
< ssN o : 00−111−2222, N ame : JohnDoe, Dept :
CSE >
is an entity
In a Company database
< N ame : JohnDoe, Department : CSE >
may not be an entity because it is relationship.
• Entity Type:
Defines a set of entities that have the same attributes and it must have a key.
Example: Employees (ssNo, Name, Dept); ssNo
is the key.
• Entity set:
A set of entities of a particular entity type. Normally, entity type name is used to represent the
entity set.
Example: entity set Employees: {(s1,n1,d1),(s2,n2,d2)}
9
• Weak Entity Type and identifying relationship type:
Entity type that does not have key attributes of
its own.
Example: Entity EmployeeDependent depends
on the entity type Employee. Normally weak entities have partial keys and become unique when
combined with the key of its parent entity. Thus
the relationship between the weak entity and it’s
parent entity is called the identifying relationship
type.
2. Relationships and Relationship types:
• Relationship type is the association between entity types. For example, relationship type WorksFor associates one entity type Employees with
another entity type Departments
• Relationship Degree: Number of participating
entity types:
Relationship type WorksFor is of degree two (binary relationship).
Relationship type Supply between Suppliers, Parts
and Projects is of degree 3 (ternary relationship).
• Attributes of Relationship type:
10
Relationship types can have attributes just like
in entity types. WorksFor can have attributes
Hours and RateOfPay.
• Entity types, Relationship types and Attribute
types:
Whether data is entity or relationship or attribute
depends on the application. For example, WorksFor can be an attribute in the Employee entity
type. WorksFor may contain department number, the employee works for.
3. Simple and Complex Attributes:
• Attributes (simple): Particular properties that
entities describe.
Example: ssNo, Name, Dept
• Composite Attributes: Consists of a set of
simple (atomic) attributes. It can be a hierarchy
of simple attributes.
Example: The composite attribute Name is composed of the three simple attributes FirstName,
MiddleName and LastName
• Multivalued attributes: An attribute with
multiple values for an entity. Important information for mapping into relational data model
11
because attribute values in relational model are
atomic.
Example: Department Locations (if a department has several locations)
• Stored attributes: Attributes whose values
are stored in the table.
Example: BirthDate
• Derived attributes: Attributes whose values
are computed from values of other attributes at
query time. This approach avoids storing replicated information.
Example: Age (can be computed from birth date).
• NULL values: Value is not known yet.
Example: Local address of a new employee may
not be known yet.
• Complex attributes: Nesting of composite
and multivalued attributes.
AddressPhone: ({P hone(areaCode, P honeN umber)},
Address(StreetAddress(number, Street), City, State, Zip))
4. Notations:
Figure 3.15 (third edition)
12
Constraints on Relationship types
Constraints are useful for efficiently mapping ER diagram into relational tables.
1. Cardinality constraints indicate whether an entity of
one type can relate to one or more than one entities
in another type.
A database may not allow a professor to be a chair of
more than one departments. Further, a department
is not allowed to have more than one professor as
chair. Note these two constraints are different. If the
second constraint was not there, a department could
have two professors as chairs while not violating the
first constraint.
2. Cardinality Constraints for Binary Relationships:
Three types: 1:1, 1:N, N:M.
• 1:1 relationship:
Employees Manages Departments.
An employee manages at the most one department and a department is manged by at most
one employee as manager.
Figure 3.12 (third edition)
13
• 1:N (1 to many) relationship:
Employees WorkFor Departments.
An employee can work for at the most one department but a department can have more than
one employees working for it.
1 is on the Departments side and N is on the Employees side of the relationship Workfor in the ER
diagram.
Figure 3.9 (third edition)
• N:M (many to many) relationship:
Employees workOn Projects
An employee can work on (workOn) more than
one projects and a project can be worked on
(workOn) by more than one employee.
Figure 3.13 (third edition)
• How about ternary relationship?
Figure 3.10 (third edition)
3. Participation Constraints (with respect to a relationship):
Whether some or all of the entities are participating
in a relationship. Thus an entity exits with respect
to a relationship if the entity is related to another
entity via the relationship. The participation is a
total participation when every entity in the entity
14
set satisfies this constraint else it is a partial participation. For example, for total participation, every
Employee in the Employee entity set must belong to
some department for the WorksFor relationship.
Figure 3.2 (Elmasri/third edition)
4. Refer to Figure 3.14, 3.15 of the text booki (third
edition).
15
Mapping ER Model to Relational
Schemas
(Details in section 9.1)
A
|
S
/\
T
---/ \
---|X| |-- R --|Y| |
---\ /
---\/
primary key of S: X
primary key of T: Y
T is total participation in R.
1. R is of 1:1 relationship type:
S(X), T(Y,X,A) foreign key X in T.
2. R is of 1:N relationship type (N is on the side of T):
S(X), T(Y,X,A) foreign key X in T
3. R is of N:M relationship type:
S(X), T(Y), R(X,Y,A)
foreign keys: Primary key of R: (X,Y)
Two foreign keys in R: X and Y.
16