Professional Documents
Culture Documents
1
Database Models
• Introduction to Modeling
2
Database Models
• A specific DBMS has its own specific Data Definition Language, but
this type of language is too low level to describe the data
requirements of an organization in a way that is readily
understandable by a variety of users.
• We need a higher-level language.
• Such a higher-level is called data-model.
–A data model is a collection of tools or concepts for describing data,
the meaning of data, data relationships, and data constraints.
• A model is a representation of real world objects and events and their
associations.
• The main purpose of Data Model is to represent the data in
understandable way.
3
Database Models … Cont’d
4
Hierarchical Model
5
Hierarchical Model… Cont’d
6
Network Model
7
Network Model … Cont’d
8
Relational Model
• Developed by Dr. Edgar Frank Codd in 1970 (famous paper, 'A
Relational Model for Large Shared Data Banks')
• Terminologies originates from the branch of mathematics called set
theory and relation.
• Can define more flexible and complex relationship.
• Viewed as a collection of tables called “Relations”.
• Relation: Two dimensional table.
• Stores information or data in the form of tables ( rows and columns).
• A row of the table is called tuple which is equivalent to record.
• A column of a table is called attribute which is equivalent to fields.
• Data value is the value of the Attribute.
9
Relational Model … Cont’d
• Records are related by the data stored jointly in the fields of records in
two tables or files. The related tables contain information that creates the
relation
• The tables seem to be independent but are related some how.
• No physical consideration of the storage is required by the user
• Many tables are merged together to come up with a new virtual view of
the relationship
10
Relational Model … Cont’d
Relational Data model (also called the second generation data
model), describes entities and their relationships in the form of table
11
Chapter -3.2
Data Modeling using Entity-Relationship Model
12
Outline
3.1 Introduction to the E-R Model
3.2 Entity
3.3 Attributes
3.4 Relationships
3.5 Degree of a Relationship
3.5.1 Unary Relationship
3.5.2 Binary Relationship
3.5.3 Ternary Relationships
3.6 Constraints on Relationships
3.7 Maximum Cardinality
3.8 Minimum Cardinality
3.9 Total Participation
3.10 Partial Participation
3.11 Weak Entity Types
3.13 Other E-R Notations
13
Database Design
Database design consists of several tasks:
•Requirements collection and analysis:
–DB designers interview DB users
–Should be specified in a complete form
–May include functional requirements such as the operations that
will be applied.
•Conceptual Design- create conceptual schema which:
–Is the concise description of the data requirements of users
–Includes detailed descriptions of entity types, relationships and
constraints
–Can be used to ensure that all requirements are met.
14
Database Design..Cont’d
• Logical Design,
–Actual implementation of the DB
–Also called data model mapping
–Result is db schema in the implementation data model
• Physical Design
–Physical implementation of the logical design
• In general, one has to go back and forth between these tasks to refine
a database design, and decisions in one task can influence the choices in
another task.
• In developing a good design, one should ask:
–What are the important queries and updates?
–What attributes/relations are involved?
15
Database Development Process in Short
16
The Three levels of Database Design
17
3.1 Introduction to the E-R Model(1)
The entity relationship(E-R) model is :
– A high-level(conceptual) data model
– It perceives the mini-world as a collection of basic objects called entities.
– It also contains the descriptions of entities called attributes and the relationship between/among
the entities
E-R modeling is mainly used to create the conceptual schema for the database from the collected
system specifications
18
3.1 Introduction to the E-R Model(2)
An entity-relationship model describes data in terms of the following:
– Entities
– Relationship between entities
– Attributes of entities
19
ER-diagram Symbols
20
21
3.1 Introduction to the E-R Model(3)
Lname CName
FName ID No. CCode Credit
22
3.1 Introduction to the E-R Model(4)
Mezgebo
DBMS
e1 c1
Hailu C2 4
MIT/1999/2 CSE101
POC
23
3.2 Entity(1)
An entity is an object that exists and which is distinguishable from other objects
– Can be a person, a place, an object, an event, or a concept
– Examples:
Person: Student, Employee, etc.
Object: Computer, Airplane, Machine , etc.
Place: City, Park, Room, Warehouse , etc.
Event: War, Marriage, Lease , etc.
Concept: Project, Account, Course , Holiday , Job , etc.
24
3.2 Entity (2)
An entity type defines a collection of entities that have the same attributes
Example:
– Entity type: STUDENT
– Entity instance: Student with ID number MIT/0002/2001
– Entity set: Collection of all students
25
3.3 Attributes
An attribute is a property or characteristic of an entity type
– We describe an entity with a set of attributes
– Examples:
STUDENT = {Reg. No, Fname , LName, Address, Phone, Email, DOB}
ORDER = {Order ID, Date of Order, Amount of Order}
ACCOUNT = {Account No, Account type, Balance}
CITY = {Name, State, Population}
– Types of Attributes :
Simple, composite, single-valued, multi-valued, stored, and derived
26
Attributes in E-R Diagram
27
Simple VS Composite Attributes
A simple or an atomic attribute cannot be further divided into smaller components
– Examples:
Age
DOB
A composite attribute, however, can be divided into smaller subparts where each subpart is either
atomic or composite
– Examples:
Name: First Name, Last Name
Address: Street, City, State, ZipCode
28
Single-Valued VS Multi-Valued Attributes
Single-valued attributes have a single value for an entity instance
– Examples:
Name
Date Of Birth
Reg. No
Multi-valued attributes, on the other hand, may have more than one value for an entity instance
– Denoted with a double-lined ellipse
– Example:
Languages: Stores the names of the languages that a student speaks
College Degree: BSC., MSC. ,M.Tech. ,PHD, etc.
Phone number: Mobile phone , Office phone , Home phone
29
Stored VS Derived Attributes
The value of a derived attribute can be determined by analyzing other attributes
– Therefore, no need to store them in the database
– Example:
Age: Can derived from the current date and the attribute DateOfBirth
An attribute whose value cannot be derived from the values of other attributes is called a stored
attribute
30
Complex Attributes
Complex Attributes
Example:
Grouping components of a composite attribute between parentheses ( ),
Separating the components with comma, and
Displaying multivalued attributes between braces {}.
Example: A person with more than one address and phone number.
31
Key Attribute
A key attribute (or identifier) is a single attribute or a combination of attributes that uniquely
identify an individual instance of an entity type
– Underlined in an E-R diagram
– Example:
Student: StudentID
32
Candidate Key Attribute
Sometimes no single attribute can uniquely identify an instance of an entity type
A composite key is a composite attribute that uniquely identifies each entity instance
– Example:
City: {Name, State}
35
Attributes of Relationships
An attribute on a relationship stores information related to the relationship
– Much like attributes on entity types
Relationship
Attribute
36
3.5 Degree of a Relationship
The number of entity sets that participate in a relationship is called the degree of relationship
Three common degrees in a database:
3.5.1 Unary (degree 1) –Recursive relationship
An association between two instances of the same entity type
R є E1 x E1
E.g. An employee supervises another employee
Supervisee
EMPLOYEE SUPERVISION
Supervisor
37
Role names in a recursive relationship
EMPLOYEE SUPERVISION
e1
2
1 r1
e2 2
1 r2
e3 2
1 r3
e4
2
e5 1
1 r4
e6 2
1
r5
e7
2
r6
38
Recursive Relationship
Recursive relationship is a kind of relationship when an entity type relates to itself
In this case role names are essential to distinguish the meaning of each participation in the
relationship
In the slide given above the mark “1” represents the Supervisor role , and the mark “2” represents
the Supervisee role
Hence from the diagram in the previous slide we can easily know :
– e1 supervises e2 and e3
– e3 supervises e5 and e6
– e4 supervises e1 and e3
39
3.5.2 Binary Relationship
40
3.5.3Ternary Relationship
-Ternary (degree 3)
An association among three different entity types
R є E1 x E2 x E3
E.g. A bank employee who has a specific job in a bank branch
Emp_Name Assets
Bankname BranchName
EMP_ID Emp_Salary
JOB
TITLE
LEVEL
41
Ternary Relationships – Extra examples
Musical Performance
Example
Student “Uses”
Equipment for a
Project Example
42
3.6 Constraints on Relationships
The cardinality of a relationship defines the number of instances of one entity type that can be
associated with instances of another entity type
The maximum cardinality of a relationship defines the maximum number of instances of one
entity type that can be associated with instances of another entity type
43
3.7 Maximum Cardinality(1)
Relationship types by maximum cardinality:
– One-to-One
– One-to-Many (and Vice-Versa)
– Many-to-Many
One Many
44
Maximum Cardinality(2)
How do you know the maximum cardinality between two entity types?
Let’s say we have 2 entity types called X and Y
X R Y
45
Maximum Cardinality(3)
YES NO One-2-Many
No YES Many-2-One
NO NO One-2-One
46
Maximum Cardinality(4)
One-2-One Relationship
– An entity in X is associated with at most one entity in Y , and vice-versa.
– E.g. Each passenger has his own Ticket
Many-2-Many Relationship
An entity in X is associated with any number(zero or more) of entities
in Y ,and an entity in Y is associated with any number (zero or more )
of entities in X
48
Many-to-one (M:1) Relationship Example
EMPLOYEE WORKS_FOR DEPARTMENT
e1 r1 d1
e2 r2
e3
d2
r3
e4
r4 d3
e5
r5
e6
e7
r6
r7
49
Many-to-many (M:N) Relationship Example
r9
e1 r1 p1
e2 r2
e3 p2
r3
e4
r4
e5
p3
r5
e6
e7
r6
r7
r8
50
Exercise
51
3.8 Minimum Cardinality(1)
52
3.8 Minimum Cardinality(2)
The minimum cardinality of a relationship is defined as the minimum number of instances of one
entity type that must be associated with each instance of another entity type
Minimum cardinality is also called participation constraint or
existence dependency constraints. There are 2 types of participation constraints:
1.Total participation
2.Partial participation
Optional
Mandatory
53
3.9 Total Participation
Total participation: every entity in the entity set participates in at least one
relationship in the relationship set. The entity with total participation will be
connected with the relationship using a double line.
The example below shows that the participation of the entity set Department in the relationship
set Manages is total . This is because every department must have a manager .
Employee 1 1 Department
Manages
54
3.9 Total Participation… Continued
55
3.10 Partial Participation
In partial participation , some entities (not all entities) in the entity set occurs in the relationship in
the relationship set. That is some entities may not participate in any relationship in the
relationship set.
The example below shows that the participation of the entity set Student in the relationship set
Leader is partial because it is not possible for every student entity to be a leader.
56
3.10 Partial Participation Continued
57
A strong entity type exists independent of other entity types. They have their own primary keys
A weak entity type is an entity type that doesn’t have a primary key of its own. It depends on
another entity type called the owner or identifying entity type to be uniquely identified
It needs Foreign keys in conjunction with its attributes to create a primary key
A weak entity type always has a total participation constraint with respect to its identifying
relationship
FNAME LNAME
EMP_ID EMP_FNAME
HAS
EMPLOYEE DEPENDENT
EMP_LNAME EMP_ADDRESS
DOB
58
3.11 Weak Entity Types(2)
From the previous slide we can see that DEPENDENT is a weak entity type. It is not an object of
interest to be stored in the database but it should be stored because of the existence of another entity
type – the EMPLOYEE – which it is related with
DEPENDENT is described by the dependent’s first name , last name and birth date
It is related with the owner entity type via the identifying relationship type HAS
The participation of the weak entity type in the indentifying relationship type is always total. But
this doesn’t mean that all total participations involve weak entities
59
Other Notations for E-R diagrams
There are different notations for E-R diagrams.
Crow’s Foot Notation:
Known as IE notation (most popular)
Entity:
–Represented by a rectangle, with its name on the top. The name is
singular (entity) rather than plural (entities).
60
Other Notations for E-R diagrams…Continued
Crow’s Foot Notation…
Attributes:
Identifiers are represented by underlying the name of the
attribute(s)
61
Example Model Crow’s Foot Notation…Continued
62
Thank You!
ANY ???
63