1. Data Modeling Using the Entity-Relationship Model

2. Using High-Level Conceptual Data Models for Database Design

3. Phases of Database Design
Requirements
Collection and
Analysis
Phases of Database Design
Functional Requirements
Data Requirements
FUNCTIONAL ANALYSIS
CONCEPTUAL DESIGN
Conceptual Schema
(in a high-level data model)
High-level Transaction
Specification
LOGICAL DESIGN
(DATA MODEL MAPPING)
Logical (Conceptual) Schema
(In the data model of a specific DBMS)
APPLICATION PROGRAM
DESIGN
First step shown is requirements collection and analysis. This step, the database designers interview user to user stand and document their requirements. The results is set of user requirements.
The requirement have be collected and analyzes, the next step is to create a conceptual schema for the database, using a high level conceptual schema for the database. The conceptual schema is a description of the data requirements of the users and includes detailed description of the entity types, relationships and constraints. Present by using high level data model. Because concepts do not include do not include implementation details, they are usually easier to understand and can be used to communicate with user.
The next step is actual implementation of the database, using a commercial DBMS. Most commercial DBMS use an implementation Data Model such as relation model or the object-relational database model. This step is transformed from the high-level data model into the implementation data model.
The last step is the physical design phase. During which the internal storage structures, indexes, access paths, and file organizations for the database files are specified.
PHYSICAL DESIGN
TRANSACTION
IMPLEMENTATION
Internal Schema
Application Program

4. Phases of Database Design
Requirements
Collection and
Analysis
Phases of Database Design
The next step is to create a conceptual schema for the database, using a high level conceptual schema for the database.
The conceptual schema is a description of the data requirements of the users and includes detailed description of the entity types, relationships and constraints, present by using high level data model.
Because concepts do not include do not include implementation details, they are usually easier to understand and can be used to communicate with user.
Data Requirements
Functional Requirements
FUNCTIONAL ANALYSIS
High-level Transaction
Specification
APPLICATION PROGRAM
DESIGN
TRANSACTION
IMPLEMENTATION
Application Program
CONCEPTUAL DESIGN
The last step is the physical design phase. During which the internal storage structures, indexes, access paths, and file organizations for the database files are specified.
First step shown is requirements collection and analysis. This step, the database designers interview user to understand and document their requirements.
The next step is actual implementation of the database, using a commercial DBMS. Most commercial DBMS use an implementation Data Model such as relation model or the object-relational database model. This step is transformed from the high-level data model into the implementation data model.
Conceptual Schema
(in a high-level data model)
LOGICAL DESIGN
(DATA MODEL MAPPING)
Logical (Conceptual) Schema
(In the data model of a specific DBMS)
First step shown is requirements collection and analysis. This step, the database designers interview user to user stand and document their requirements. The results is set of user requirements.
The requirement have be collected and analyzes, the next step is to create a conceptual schema for the database, using a high level conceptual schema for the database. The conceptual schema is a description of the data requirements of the users and includes detailed description of the entity types, relationships and constraints. Present by using high level data model. Because concepts do not include do not include implementation details, they are usually easier to understand and can be used to communicate with user.
The next step is actual implementation of the database, using a commercial DBMS. Most commercial DBMS use an implementation Data Model such as relation model or the object-relational database model. This step is transformed from the high-level data model into the implementation data model.
The last step is the physical design phase. During which the internal storage structures, indexes, access paths, and file organizations for the database files are specified.
PHYSICAL DESIGN
Internal Schema

5. Entity Relational Data Model
ER-Model describes data as
Entities
Attributes
Relationships

6. Entities and Attributes
Entity is thing in the real world with an independent existence.
Entity may be an object with a physical existence for example person, car house or employee
Entity may be an object with a conceptual existence for example a company, a job, a university course.

7. Attributes
Attribute is the particular properties that describe entity.
The attribute values that describe each entity become a major part of the data stored in the database.
For example
Employee entity may describe by
Name, Age, address, salary and job.

8. Attribute & Attribute Value
Student
Name
Faculty
Major ID
Kamonphon Science IT
PiyathiDa Science Comp SC.
Attribute Value

9. Each entity has attributes
A particular entity will have a value for each of its attributes
The attribute values that describe each entity become a major part of the data stored in the database.

10. Attribute Type Composite Attributes Single-Valued Multi Valued
Atomic Attribute
Composite Attributes
Single-Valued
Multi Valued
Stored Attribute
Derived Attribute

11. Atomic Attribute
Atomic Attribute is an attribute that is not divisible.
Called Atomic or Simple Attributes.
Example
Student
Atomic Simple
First Name
Last Name
Age

12. Composite Attributes
Composite Attributes can be divided into smaller subparts, which represent more basic attributes with independent meanings.
Composite
Attribute
Address
Street Address
Tambol
District
Province
ZipCode
Composite
Attribute?
Atomic
Attribute

13. Single-Valued VS Multi Valued Attributes
Single-Valued : attribute has a single value for a particular entity
Multi Value Attribute: has multiple values

14. Example Attribute Age Attribute Value Degree B : 27 Years
A : B.Sc.
B : B.Sc, M.Sc., Dr. Eng.
Age
A : 24 Years
B : 27 Years
Attribute Value

15. Stored VS Derived Attributed
Stored Attribute
Derived Attribute: an attribute value can be determined from another attribute / related entity.

16. Example Attribute Age Attribute Value Birth Day B : 40 Years
A : 13 July 1980
B : 23 Dec 1964
Age
A : 24 Years
B : 40 Years
Stored Attribute
Attribute Value
Derived Attribute

17. Key Attribute
An attribute that whose values are distinct for each individual entity in the entity set.
Unique
Not Null

18. Null Value
Some case a particular entity may not have an applicable value for an attribute.
Example
Degree attribute applied only to a person with collage degree.
For this situations, a special value called null is create.

19. Entity Type Regular Entity Type Weak Entity Type
Entity that do have a key attribute
Weak Entity Type
Entity that do not have key of their own.
Depend on other entities
Other entities are called owner entity
Relationship between Owner and Weak entities is called “identifying relationship”

20. Example
Entity
Employee
Department
Project
Dependent

21. Entity Type, Entity Sets, Keys, Value Set
Entity type defines a collection (or set) of entity that have same attributes.
Each entity type in the database is described by its name and attributes.
Entity set is the collection of all entities of a particular entity type in a database at any point in time.
The entity set usually referred to using the same name as the entity type.

22. Key attribute of Entity type
Key or Uniqueness constraint
an attribute whose values are distinct for each individual entity in entity set

23. Relationship
There are several relationship among the various entity types.

24. Relationship Type
Relationship type R among n entity types E1,E2,…,En defines a set of association or relationship set among entities from these entity types.
Mathematically,
the relationship set R is a set of relationship instances ri,
where each ri associates n individual entities (e1,e2,…, en) and each entity ej in ri is a member of entity type Ej,
1 ≤ j ≤ n.

25. Relationship Degree
Degree of a relationship type is the number of participating entity types.
For example
Degree of a Relationship among Teacher and Student entities is two.
A relationship degree two and three are called binary and ternary, respectively.

26. Constraint on Relationship Types
Two main Type of relationship constraints
1. Cardinality ration
2. Participation

27. Cardinality Ratios
Cardinality ratio specifies the maximum number of relationship instances that an entity can participate
1 to 1 Relationship (1:1)
1 to many relationship (1:N)
Many to Many relationship (N:M)

28. 1:1 Relationship R1 R2 R3 R4 E1 E2 E3 E4 E5 E6 E7 D1 D2 D3 D4
Entity E2
Entity E1
Relationship

29. 1 to Many Relationship R1 R2 R3 R4 E1 E2 E3 E4 E5 E6 E7 D1 D2 D3 D4
Entity D
Entity E
Relationship

30. Many to Many RelationshipJ1 J2 J3 J4
Entity J
Entity E
Relationship

31. Participation Constraints and Existence Dependencies
Participation Constraints specified whether the existence of an entity depends on its being related to another entity via the relationship type.
It specifies the minimum number of relationship instance that each entity can participate in, and is sometimes called the minimum cardinality constraint.

32. Participation type
Partial
Total participation
(existence dependency)

33. Total participation R1 R2 R3 R4 E1 E2 E3 E4 E5 E6 E7 D1 D2 D3 D4
Entity D
Entity E
Relationship

34. Partial participationD1 D2 D3 D4 E1 E2 E3 E4 E5 E6 E7
Entity E
Entity D
Relationship

35. Symbol
Entity
Weak Entity
Relationship

36. Weak Entity
Attribute
Key Attribute
Composite Attribute
Derived Attribute

37. partial
Total E1 E2 R E1 E2 R 1 N
Cardinality Ratio