0% found this document useful (0 votes)
48 views44 pages

Chapter 3

The document discusses conceptual database design. It describes the key components of an entity-relationship model including entities, attributes, relationships, and constraints. It also provides examples of how to develop entity-relationship diagrams.

Uploaded by

Sura OG
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
48 views44 pages

Chapter 3

The document discusses conceptual database design. It describes the key components of an entity-relationship model including entities, attributes, relationships, and constraints. It also provides examples of how to develop entity-relationship diagrams.

Uploaded by

Sura OG
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 44

Haramaya University

COLLEGE OF COMPUTING AND INFORMATICS


Department of Software Engineering

Chapter Three
Data Mining Project on
“Prediction of Chronic Kidney Disease Using Data Mining Classification
Conceptual Techniques”Database Design
By
Yohans Samuel
Database Development Life Cycle
The major steps in database design are;
• Planning: is identifying information gap in an organization and propose a

database solution to solve the problem.


• Analysis: concentrates more on fact finding about the problem or the

opportunity. Feasibility analysis, requirement determination and structuring, and


selection of best design method are also performed at this phase.
• Design: in database designing more emphasis is given to this phase.

• Implementation: the testing and deployment of the designed database for use.

• Operation and Support: administering and maintaining the operation of the

database system and providing support to users.


2
Database Design
 The prime interest of a database system will be the Design part which is
divided into other three phases.
 These phases are:
1. Conceptual Design
2. Logical Design, and
3. Physical Design
In developing a good design, one should answer such questions as:
• What are the relevant Entities for the Organization ?
• What are the important features of each Entity ?
• What are the important Relationships ?
• What are the important queries from the user ?
• What are the other requirements of the Organization and the Users ?

3
Conceptual Database Design
• Conceptual design is the process of constructing a model of the information
used in an enterprise, independent of any physical considerations.
• It is the source of information for the logical design phase.
• Mostly uses an Entity Relationship Model to describe the data at this level.
• Conceptual design revolves around discovering and analyzing organizational
and user data requirements.
• The important activities are to identify :
• Entities
• Attributes
• Relationships
• Constraints
• Based on these components develop the ER model using ER diagrams

4
The Entity Relationship Diagram (ER Model)
Entity-Relationship modeling is used to represent conceptual view of the
database.
The main components of ER Modeling are:
• Entity:
• Corresponds to entire table, not row
• Represented by Rectangle
• Attributes:
• Represents the property used to describe an entity or a relationship
• Represented by Oval
• Relationships:
• Represents the association that exist between entities
• Represented by Diamond
• Constraints:
• Represent the constraint in the data
5
ER-Diagram Components
Entity
• Any thing real or abstract about which we want to store
Course
data
Entity types fall into five class
• Roles- Employee
• Events- Payment
• Location-Campus
• Tangible things-Book
• Concepts-course
Relationship
• A data relationship is a natural
association that exists between one
or more entities.
Example: employee process payment.
Attribute
• It is a characteristics of a particular entities
Example: Name , address
• An attribute that uniquely identifies one and
6
only one entity is called primary key
Developing an E-R Diagram

Before working on the conceptual design of the database, one has to know and
answer the following basic questions.
• 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 that hold? Constraints on each data with

respect to update, retrieval and store.


• Represent this information pictorially in ER diagrams, then map ER

diagram into a relational schema.


7
Developing an E-R Diagram…

• To identify the entities, attributes, relationships, and constraints on the data,

there are different set of methods used during the analysis phase.
• These include information gathered by:

• Interviewing end users individually and in a group


• Questionnaire survey
• Direct observation
• Examining different documents

8
Developing an E-R Diagram…

• The basic E-R model is graphically depicted and presented for review.

• The process is repeated until the end users and designers agree that the E-R

diagram is a fair representation of the organization’s activities and functions.


• Checking for Redundant Relationships in the ER Diagram. Relationships

between entities indicate access from one entity to another


• The last phase in ER modeling is validating an ER Model against

requirement of the user.

9
Graphical Representations in ER Diagramming

 Entity is represented by a rectangle containing the name of entity.

Strong Entity Weak Entity


Connected entities are called relation participant.

10
Graphical Representations in ER Diagramming

11
Steps to create an ERD

Not necessarily done in this order but do all these steps


1. Identify entities
2. Identify/Create relationships
3. Add attributes to entity
4. Identify primary key
5. Add cardinality notation (both directions of relationship)
6. Add assumptions, notes, title.

12
Summary of notation for ER diagrams

13
Example:1
Build an ER Diagram for the following information:
A student record management system will have the following two basic data
object categories with their own features or properties:
• Student will have an Id, Name, DoB, Dep’t, Age, GPA and

• Course will have an Id, Name, Credit Hours

Whenever a student enroll in a course in a specific Academic Year and


Semester, the Student will have a grade for the course

14
Graphical Representations in ER Diagramming

Student

15
Example:2
Build an ER Diagram for the following information:
A Personnel record management system will have the following two basic data
object categories with their own features or properties:
• Employee will have an Id, Name, DoB, Age, address,Tel,Email ,and

• Department will have an Id, Name, Location,Head

Whenever an Employee is assigned in one Department, the duration of his


stay in the respective department should be registered.

16
Structural Constraints on Relationship

• Multiplicity constraint is the number or range of possible occurrence of an entity type/relation

that may relate to a single occurrence/tuple of an entity type/relation through a particular


relationship.
• Mostly used to insure appropriate enterprise constraints.

One-to-one relationship:
• A customer is associated with at most one loan via the relationship borrower
• A loan is associated with at most one customer via borrower

17
Structural Constraints on Relationship

E.g. Relationship Manages between STAFF and BRANCH


The multiplicity of the relationship is:
• One branch can only have one manager
• One employee could manage either one or no branches

18
Structural Constraints on Relationship

One-To-Many Relationships

• In the one-to-many relationship a loan is associated with at most one

customer via borrower, a customer is associated with several (including 0)


loans via borrows

19
Structural Constraints on Relationship

 E.g. Relationship Leads between STAFF and PROJECT


The multiplicity of the relationship
• One staff may Lead zero or more project(s)
• One project is Lead by one staff

20
Structural Constraints on Relationship

Many-To-Many Relationship

• A customer is associated with several (possibly 0) loans via borrows

• A loan is associated with several (possibly 0) customers via borrows

21
Structural Constraints on Relationship

 E.g. Relationship Teaches between INSTRUCTOR and COURSE

The multiplicity of the relationship

• One Instructor Teaches zero or more Course(s)

• One Course Thought by Zero or more Instructor(s)

22
Participation of an Entity Set in a Relationship Set
• Participation constraint of a relationship is involved in identifying and setting the
mandatory or optional feature of an entity occurrence to take a role in a relationship.
There are two distinct participation constraints with this respect, namely: Total
Participation and Partial Participation
• Total participation: every tuple in the entity or relation participates in at least one
relationship by taking a role. This means, every tuple in a relation will be attached
with at least one other tuple. The entity with total participation in a relationship will
be connected to the relationship using a double line.
 E.g. 1: Participation of EMPLOYEE in “belongs to” relationship with
DEPARTMENT is total since every employee should belong to a department.
Participation of DEPARTMENT in “belongs to” relationship with EMPLOYEE is
total since every department should have more than one employee.

23
Participation of an Entity Set in a Relationship Set
• Partial participation: some tuple in the entity or relation may not participate in

the relationship. This means, there is at least one tuple from that Relation not
taking any role in that specific relationship. The entity with partial
participation in a relationship will be connected to the relationship using a
single line.

24
Exercises
What is the cardinality and existence of each of the following relationships in
just the direction given? State any assumptions you have to make.

1. Student to degree
2. Child to parent
3. Player to team

25
Enhanced Entity Relationship Model (EER)

• The enhanced entity relationship model provides certain extensions to the

basic E-R model to overcome the basic problems of E-R model which is
called a connection traps.

 EER Features

o Generalization and Specialization

o Sub classes and Super classes

o Attribute Inheritance

26
Generalization

• Generalization is the process of defining a more general entity type from a set

of more specialized entity types.


• A generalization hierarchy is a form of abstraction that specifies two or more

entities that share common attributes can be generalized into a higher-level


entity type.
• is considered as bottom-up definition of entities.

• Generalization hierarchy depicts relationship between higher level superclass

and lower level subclass.

27
Generalization

28
Specialization

• is the result of subset of a higher level entity set to form a lower level entity set.

• The specialized entities will have additional set of attributes (distinguishing

characteristics) that distinguish them from the generalized entity.


• is considered as Top-Down definition of entities.

• Specialization process is the reverse of the Generalization process. Identify the

distinguishing features of some entity occurrences, and specialize them into


different subclasses.

29
Specialization

30
Sub classes and Super classes

Sub Class/ Sub Type


• An entity type that includes one or more distinct attributes from the generalized or

super class.
• When one generalized Superclass has various subgroups with distinguishing features

and these subgroups are represented by specialized form, the groups are called
subclasses.
Super Class/ Super Type
• An entity type whose tuples share common attributes. Attributes that are shared by

all entity occurrences (including the identifier) are associated with the supertype i.e
the generalized entity 31
Relationship Between Superclass and Subclass
• The relationship between a superclass and any of its subclasses is called a
superclass/subclass or class/subclass relationship
• An instance can not only be a member of a subclass. i.e. Every instance of a subclass
is also an instance in the Superclass
• A member of a subclass is represented as a distinct database object, a distinct
record that is related via the key attribute to its super-class entity.
• The relationship between a subclass and a superclass is an “IS A” or “IS PART OF”
type.
• Subclass IS PART OF Superclass
• Manager IS AN Employee
• Superclass attributes are shared by all subclasses of that superclass

• Subclass attributes are unique for the subclass.


32
Relationship Between Superclass and Subclass
• All subclasses or specialized entity sets should be connected with the superclass using
a line to a circle where there is a subset symbol indicating the direction of
subclass/superclass relationship

33
Attribute Inheritance

• An entity that is a member of a subclass inherits all the attributes of the entity as

a member of the superclass.


• The entity also inherits all the relationships in which the superclass participates.

• An entity may have more than one subclass categories.

• All entities/subclasses of a generalized entity or superclass share a common

unique identifier attribute (primary key). i.e. The primary key of the superclass
and subclasses are always identical.

34
Attribute Inheritance

35
Constraints on specialization and generalization

Based on Definition
• Predicate Defined Subclass

• User Defined Subclass

Based of Membership
• Disjoint Subclass

• Overlapping Subclass

Based on Completeness of Participation


• Total Specialization

• Partial Specialization
36
Constraints on specialization and generalization

Predicate Defined Subclass


• it’s also called condition defined subclass.We can determine to which subclass an entity

belongs by placing a condition on some attribute in the superclass and this attribute is
called “Defining Attribute”.
 Example: – JobType is an attribute of superclass “Employee”, based on the value of this

attribute, we can determine if an employee belongs to “Secretary”, “Technician”, or


“Engineer”.
User Defined Subclass
• if the membership in a subclass is not defined based on an attribute, then this subclass is

called “User Defined Classes”.


37
Constraints on specialization and generalization

38
Constraints on specialization and generalization

Completeness Constraint.
• The Completeness Constraint addresses the issue of whether or not an occurrence of a

Superclass must also have a corresponding Subclass occurrence.


• The Total Specialization Rule specifies that an entity occurrence should at least be a

member of one of the subclasses. Total Participation of superclass instances on


subclasses is diagrammed with a double line from the Supertype to the circle.
• The Partial Specialization Rule specifies that it is not necessary for all entity ccurrences in the

superclass to be a member of one of the subclasses


• Partial Participation of superclass instances on subclasses is diagrammed with a single line from

the Supertype to the circle.

39
Constraints on specialization and generalization

40
Constraints on specialization and generalization

Disjointness Constraints.
 Specifies the rule whether one entity occurrence can be a member of more than one subclasses.

• The Disjoint Rule restricts one entity occurrence of a superclass to be a member of

only one of the subclasses. Example: a EMPLOYEE can either be SALARIED or


PART-TIMER, but not the both at the same time.
• The Overlap Rule allows one entity occurrence to be a member of more than one

subclass. Example: EMPLOYEE working at the university can be both a STUDENT


and an EMPLOYEE at the same time.
• This is diagrammed by placing either the letter "d" for disjoint or "o" for overlapping

inside the circle on the Generalization Hierarchy portion of the E-R diagram.

41
Constraints on specialization and generalization

42
Thank You!
Project Titles
• Database Design - Phase I - May 11,2023
• Database Implementation - Phase II - Before class end

1. Farm Management System - Eden


2. Transport Management System - Ahmed Endris
3. Housing Management System - Abubeker
4. Instructor’s Office Placement System - Asmare
5. Department Selection System - Abdinaf
6. HU Clubs Management System - Ahmed Muhammed
7. HUSESA Database - Ayana
8. Enterprise Management System - Daniel
44

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy