Sei sulla pagina 1di 43

Database Management Systems

Chapter 2:
Introduction To Database Design
“The Entity-Relationship Model”
2
Overview of Database Design

• Conceptual design: (ER Model is used at this stage.)


– What are the entities and relationships in the enterprise?
– What information about these entities and relationships
should we store in the database?
– What are the integrity constraints or business rules that
hold?
– A database `schema’ in the ER Model can be represented
pictorially (ER diagrams).
– Can map an ER diagram into a relational schema.

3
Overview of Database Design

• A relational database is a collection of relations or


two-dimensional tables.
Data Models:
• Models are a cornerstone of design “represent
something in the world”. Engineers build a model of a
car to work out any details before putting it into
production. In the same manner, system designers
develop models to explore ideas and improve the
understanding of database design.

4
Overview of Database Design

Purpose of model:
•Models help communicate the concepts that are in
people’s minds.
•contains sufficient detail for a developer to build a
database system

5
2.1 Database Design And Er Diagrams
The database design process can be divided to six steps, The ER
model is most relevant to the first three steps:
1. Requirements Analysis
–The first step in designing a database application is to understand what data
to be stored in the database. In other words, we must find out what is the
users want from the database.
2. Conceptual Design
–The information gathered in the requirement analysis step is used to
develop a high-level description of the data stored in the database. This step
is often carried out using Entity relationship (ER) model.
–(Conceptual design is the process of constructing a model of information use
in organization)
3. Logical Database Design
–Working with ER model to produce an initial design for the database to
deliver a model (schema) viewed as relations and tables.

6
2.1 Database Design And Er Diagrams

4. Schema Refinement
• The fourth step analysis the collection of relation to identify potential
problems. Schema refinement make sure the there is no problems in
conceptual analysis. Normalization is used for schema refinement.
5. Physical Database Design
• In this step we must consider typical expected workload that our
database must support and further refine the database design to
ensure that it meets desired performance criteria.
6. Security Design
• In this step we identify different users groups and different roles
played by various users. Also, we identify parts of database the user
or/and role can access

7
Benefit of ER

• Documents information for the organization in a


clear, precise format
• Provides a clear picture of the scope of the
information requirement
• Provides an easily understood pictorial map for
database design
• Offers an effective framework for integrating multiple
applications

8
ER Model Basics
2.2 Entities, Attributes, And Entity Sets
• Entity: Real-world object distinguishable from other
objects. An entity is described (in DB) using a set of
attributes.
• Entity Set: A collection of similar entities. E.g., all
employees.
– All entities in an entity set have the same set of
attributes.
– Each entity set has a key. ssn
name
lot
– Each attribute has a domain.
Employees

9
ER Model Basics
2.3 Relationships And Relationship Sets
since
name dname
ssn lot did budget

Employees Works_In Departments

• Relationship: Association among two or more entities.


– E.g., Ali works in Pharmacy department.
• Relationship Set: Collection of similar relationships.
– An n-ary relationship set R relates n entity sets E1 ... En; each
relationship in R involves entities e1 E1, ..., en  En
• Same entity set could participate in different relationship
sets, or in different “roles” in same set.
10
Key Constraints

• Consider Works_In: An since


employee can work in name dname

many departments; a ssn lot did budget

department can have


many employees. Employees Manages Departments

• In contrast, each
department has at most
one manager, according
to the key constraint on
Manages.
1-to-1 1-to Many Many-to-1 Many-to-Many

11
Weak and Strong entities

• Weak entity: An entity type that is existence dependent


on some other entity (strong entity). A weak entity can be
identified uniquely only by considering the primary key of
another (owner) entity.
• Strong entity: An entity type that is independent of any
other entity. Strong entity Staff

Weak entity Children

– In drawing weak entity describes by double rectangle.


– The existence of the children depends of the existence of staff.

12
Weak and Strong entities

• In weak entity, the primary key is the primary key of


the strong entity, plus the primary key of the weak
entity.
• Staff(staff_no, name ,…)
• Childer(staff_no,child_no, name,….)

13
Relationship

• Relationship is an association among several entities.


It is a link among entities.
– It should be given a name called relationship name.
• Kinds of Relationship:
• one to many (1 : M)
• one to one (1:1)
• many to many
1-to Many 1-to-1 Many-to-Many
since
name dname
ssn lot did budget

Employees Works_In Departments

14
One to many (1 : M)

• One-to-many relationship are the most common


relationship.
– These are called one-to-many because the maximum connector
on one end is M (for many), and the maximum connector on
the other end is 1.
• Example: student to department:
Register in
Student Department

– student only can register in one department, however,


department can have more than one student
– Note that the foreign key always will be at the many side

15
One to many (1 : M)

Register in

Student Department

Register in
M 1
Student Department

Register in
∞ 1
Student Department

16
One to many (1 : M)

has
Building Classroom

• In this case there are many classrooms in one


building and one building for many classroom.

• Building(Build_no, name, location)


• Class_room(Build_no,class_no, capacity)
– Build_no references Building

17
One to one (1:1)

• One to one (1:1): The maximum connectivity on both


directions are 1.
Manages

Head of Department Department

– That means for each department there is a head of


department mange it, and for each head of department
there is a department to mange. In relation the foreign key
can goes to any side of the two tables.
• Note: Many times it is possible to merge the two entities in
one if the relation is (1:1).
– DEPARTMENT(Dept_code ,Depname ,Head_of Dept_no)
» Head_Of_Dept_no references HEAD_OF_DEPARTMENT.
– HEAD_OF_DEPATRMET(Head_of_Dept_no, Head_of_Dept_name)
18
One to one (1:1)

has

Patient Medical Profile

• The patient has only one medical profile and the


profile is only for one patient.

19
Many to Many (M:M)

• A many-to-many relationship occurs when the


maximum connectivity for both tables linked by
the connector is M.
• For example :Student registers in many courses and
course has many student.
Studies
Student Course

– This structure cannot be implemented in relational


databases. The only type of relationship that can be
implemented in a relational database are ones with one-
to-many relationship. Remember that one-to-one
connectivity is a subset of one-to-many relationship
20
Many to Many (M:M)

• So there is a problem to define the entities as tables,


so a link entity always represented to resolve the
problem
Studies studied by

Student Student course Course

– Notes that link entity also a weak entity because it


depends on the existence of the other two entities

21
Many to Many (M:M)

• Logical tables: Studies studied by

Student Student course Course

– STUDENT (Studentno, Student _Name)


– COURSE (Course_code, course_name)
– STUDENT_COURSE(studentno,courseno)
– Studentno references STUDENT.
– Courseno references COURSE.

• Note: in STUDENT_COURSE table the primary key is both


studentno and courseno which called combined key. Also,
the studentno and courseno is a foreign key
22
Optionally

• In any of the cases an optionally sign may be added


to show that the entity may have a relation with the
other entity.
drive
Employee O Car

• In this case not necessary the employee will have a car.


However car must be driven by employee
• Logical design
• EMPLOYEE (staffno, staffname, address)
• CAR (registrationno, staffno, make, model )
– Staff_no references EMPLOYEE.

23
Optionally

• If both sides has optionality, for better design to be


represented using a third relation to show the
relationship itself in a link entity: both keys are posted as
foreign keys.
drive
Employee O O Car

• EMPLOYEE (staffno, staff_name,address)


• CAR (registrationno, make, model)
• DRIVES (staffno, registrationno)
– Staffno references EMPLOYEE
– Registeertionno references CAR.
drive drive by

Employee Drives Car

24
Recursive

• Some times, an entity might be related to itself. The one-


to-many recursive relationship structure is used to
represent hierarchical structures such as organizational
charts and family trees.
– For example, employee manages by another employee.
Supervised
Employee
by

– example indicates that an employee does not have to have a


supervisor (for employees at the top of the organizational
chart) but can have at most one supervisor. The recursive
relationship indicates that the supervisor is also an employee.
An employee might supervise no employees (for employees at
the bottom of the organizational chart)
25
Recursive

• Logical tables
• EMPLOYEE(empno, empname, empaddr, supervised_by).
• supervised_by references to EMPLOYEE

• Another Example:

Treated
Doctor by

26
Rules for building logical design

1) One to many (1 : M)
– In the 1:M foreign key ALWAYS goes at the many end of
the relationship to avoid repeating groups.
• Example
Registered in

Student Department

– DEPARTMENT(deptcode, name, collegeno, no_of_student)


– STUDENT (studentno, name, address, deptno)
• Deptno references DEPARTMENT(deptcode)

27
Rules for building logical design

2) one to one (1:1):


– Using the 1:1 without optionality then can combine the
two relations data or put the foreign key in any of the two
relations.
• Example: manages
Head of
Department
Department

– DEPARTMENT(Deptno, Dep_name, location, Head_of_Dept_no)


• Head_Of_Dept_no references HEAD_OF_DEPARTMENT(no).
– HEAD_OF_DEPATRMET(no, name, address)

28
Rules for building logical design

2) one to one (1:1):


– If there is optionality then place the foreign key in optional
relation to avoid null values.
•Example: EMPLOYEE
Drives
O Car

•An employee may drive an organization’s car, place the foreign key
staffno into CAR:
– EMPLOYEE) staffno, staffname, address)
– CAR (registrationno, staffno, make, model(
• Staff_no references EMPLOYEE(staffno(

29
Rules for building logical design

2) one to one (1:1):


– If both sides has optionality for better design to be
represented using a third relation to show the relationship
itself in a link entity: both keys are posted as foreign keys
Drives
EMPLOYEE O O Car

– EMPLOYEE (staffno, staff_name, address)


– CAR (registrationno, make, model)
– DRIVES (staffno, registrationno)
• Staffno references EMPLOYEE(staffno)
• Registeertionno references CAR(registrationno)

30
Rules for building logical design

3) Many to Many:
– Always need a link entity to show the relationship
regardless of optionality. The link entity primary key is the
combined of the two entities primary keys and it self is a
foreign key. Student
Student Course
course

•The tables for the relation can be written as:


– STUDENT(studentno, studentname, address)
– COURSE(courseno, coursename, credit_hours)
– STUDENT_COURSE)studentno, courseno)
• Studentno references STUDENT(studentno(
• Courseno references COURSE(courseno)
31
Rules for building logical design

4) Recursive:
– In recursive the foreign key references the primary key of
the same table.

Supervised
by
Employee

– EMPLOYEE(empno, empname, empaddr, supervised_by).


• supervised_by references to EMPLOYEE(empno)

32
Degree of relationship type

• The entities involved in a particular relationship type


refer as participants in that relationship.
• The number of participants in a relationship called
degree of that relationship.
– A relationship that has two entities called binary.

Student Course

– The relationship which has three entities is called


Ternary.

33
Example of Ternary relationship

• Which means student


Student Course
register a course in a
certain class room. Class room

• In ternary relationship a Student


Course-
Course
student
linked entity also used,
for example:
Class room

34
Example of Ternary relationship

• In this case the linked entity will take the primary key
of the three entities.
– STUDENT (stdentno, student_name, address)
– COURSE (course_no, course_name, grade)
– CLASS_ROOM(c_no, class_location)
– COURSE_STUDENT(student_no, course_no, c_no, class_time)
• Student_no references STUDENT
• Course_no reference COURSE
• C_no references CLASS_ROOM

35
Degree of relationship type

• The relationship which has four entities is called


quaternary

B C

36
Example 1

• A company do projects, many employees assign for a


project, no employee work for more than one
project.
• Each employee belongs to one department.
• Projects need parts.
• Certain suppliers provide the parts for the projects.
• A part may contain other parts.
• Draw an E-R Diagram for the above

37
Example 1

Employee Works in Project


M 1

M
M
Belongs to

Needs
M
1

Department Part

M
Provides
1
Supplier

38
Example 2

• Each drug is sold by a drug company, drug is only sold by only one
company. For each drug , the trade name and formula must be
recoded. The trade name identified the a drug uniquely from the
product of the company.

• Each drug company is identified by name and has a phone number.

• Each patient has only one doctor, each doctor has at least one
patient. Patients are identified by an SSN, and their names ,
addresses, and ages are recorded.

39
Example 2 …

• Doctors are identified by an SSN. For each doctor, the name,


specialty, and years of experience must be recorded.

• Each pharmacy sells several drugs. A drug can be solid at several


pharmacies. Each pharmacy has a name , address and phone
number. Each pharmacy sells several drugs and has a price for
each. A drug can be solid at several pharmacies and the price is
varied from pharmacy to another.

40
Example 2 …

• Doctors prescribe (suggest) drugs for patients. A doctor could


prescribe one or more drugs for several patients. Each prescription
has a date and a quantity associated with it.
– You can assume a doctor prescribes the same drug for the same
person more than one time, the last time only recorded

• A drug company have contract with pharmacies. A drug company


can contract several pharmacies, and a pharmacy can contract
several drug companies. For each contract you have to store a start
date , an end date , and the text for contract.

41
Example 2 …

42
Summary of Conceptual Design

• Conceptual design follows requirements analysis,


– Yields a high-level description of data to be stored
• ER model popular for conceptual design
– Constructs are expressive, close to the way people think about
their applications.
• Basic constructs: entities, relationships, and attributes (of
entities and relationships).
• Some additional constructs: weak entities, ISA
hierarchies, and aggregation.
• Note: There are many variations on ER model.

43

Potrebbero piacerti anche