1. Chapter 8 Conceptual Data Modeling (概念性的資料建模)

2. Chapter Outline Three main phases of database design
Use ER modeling technique to build an ER model
Document the process of conceptual data modeling
The produced documents
Entity–Relationship (ER) diagrams
A data dictionary

3. Phases Of Database Design
Database design has 3 main phases:
Conceptual data modeling
Building conceptual representation of the database
Identifying important entities, relationships, and attributes
Logical database design
Translate conceptual representation into logical structure of a database
Convert the conceptual model into a set of tables
Physical database design
Tailor tables to a specific DBMS (針對一個特定的DBMS)
Decide how the logical structure of the database is to be physically implemented in the target DBMS
Tailored to a specific DBMS
針對一個特定的DBMS

4. Conceptual Data Modeling
The output of this step is an ER model.
The model is a representation for the data requirements of an organization that is to be supported by a database.
Need to check that
the model is capable of supporting user transactions.

5. Steps In Conceptual Data Modeling
Step 1 Create and check ER model
Step 1.1 Identify entities
Step 1.2 Identify relationships
Step 1.3 Identify attributes associated with entities
or relationships
Step 1.4 Determine attribute domains
Step 1.5 Determine candidate, primary, and alternate
key attributes
Step 1.6 Check that model supports user transactions
Step 1.7 Review model with user

6. Conceptual Data Modeling
In requirements collection and analysis stage (Chapter
4.4.4: Fact-finding), two merged views were identified for
StayHome :
Branch View: consisting Manager, Supervisor, and Assistant user views
Business View: consisting Director and Buyer user views
In this chapter, we will build a local conceptual data model
for the Branch View

7. Managing The User Views
Branch view
Merge the requirements for the Manager, Supervisor, and Assistant user views

8. Step 1 Create And Check ER Model
Objective
To build an ER model for the data requirements of an organization (or part of an organization) to be supported by the database
ER data model comprises:
Entities
Relationships
Attributes and Attribute Domains
Primary Keys, and Alternate Keys
Integrity Constraints
Step 1 Create and Check ER Model

9. Step 1.1 Identify Entities
Objective
To identify the main entities required by users.
“What type of data do the users work with?”
Look for
objects that have an existence in their own right
e.g., objects such as people, places, or concepts of interest : nouns or noun phrases
Step 1 Create and Check ER Model

10. Step 1.1 Identify entities
For example:
Staff is an entity because staff exist whether or not you know their names, addresses, and salaries.
Grouping staff ID number and staff name into an entity called Staff
Videos have an independent existence
Grouping video catalog number, title, daily rental rate, and purchase price into an entity called Video
Step 1.1 Identify entities

11. Examples of identified Entities
For the Branch user views of StayHome, you may identify the following entities
Branch
Video
Member
Actor
Staff
VideoForRent
RentalAgreement
Director
Step 1.1 Identify entities

12. Document Entities In Data Dictionary
Step 1.1 Identify entities

13. Step 1.2 Identify Relationships
Objective
To identify the important relationships that exist between the identified entities
Indicated by verbs or verbal expressions
Branch Has Staff
Branch IsAllocated VideoForRent
VideoForRent IsPartOf RentalAgreement
Step 1.2 Identify relationships

14. Identify Relationships
Focus on required relationships between entities.
Ensure that all explicit or implicit relationships in the users' requirements specification are noted.
Usually, missing relationships become apparent when you check that the model supports the transactions required by users.
It is possible, but very rare, that an entity can have no relationship with other entities in the database but still play an important part in meeting the users' requirements.
Step 1.2 Identify relationships

15. Identify Relationships
In most cases, the relationships will be binary.
Be careful to look out for
complex relationships involving more than two entities
recursive relationships involving only one entity
For the Branch user views of StayHome, the following non-binary relationships are identified :
Registers: a ternary relationship involving Branch, Member, and Staff
Supervises: a recursive relationship involving Staff.
Step 1.2 Identify relationships

16. First Draft Of The Relationships
ERD
Step 1.2 Identify relationships

17. First Draft Of The ER Diagram
Step 1.2 Identify relationships

18. Determine Multiplicity (多重性) Constraints of Relationships
ERD
Step 1.2 Identify relationships

19. Adding Multiplicity Constraints to the ER Model
Step 1.2 Identify relationships

20. Identify Relationships
Document relationships in data dictionary
Step 1.2 Identify relationships

21. Typical questions given to users :
Step Identify the Attributes Associated with Entities or Relationships
Objective
To associate attributes with the appropriate entities or relationships
Typical questions given to users :
1. What type of data do you work with?
2. What type of data do you need to hold on your X?
Step 1.3 Identify the attributes associated with entities or relationships

22. Simple/Composite Attributes
The option to represent address as a simple or composite attribute is determined by the users' requirements.
Example:
lf users do not need to access the separate components of an address, you should represent the address as a simple attribute.
If users do need to access the individual components of an address, you should represent the address as a composite attribute, made up of the required simple attributes.
Step 1.3 Identify the attributes associated with entities or relationships

23. Single/Multi-valued Attributes
Most attributes will be single-valued, but occasionally you may encounter a multi-valued attribute
For example, you may identify the Branch attribute telNo (telephone number) as
a multi-valued attribute, or
a separate entity.
This is an alternative, and equally valid, way to model that a branch has several telephones.
In Step 2.1, multi-valued attributes are mapped to tables, so both approaches produce the same result.
Step 1.3 Identify the attributes associated with entities or relationships

24. Derived Attributes (衍生的屬性)
Attributes whose values can be found by examining the values of other attributes.
All derived attributes must be shown in the data model to avoid a potential loss of information, which may occur if the attribute or attributes on which the derived attribute is based are deleted or modified.
Step 1.3 Identify the attributes associated with entities or relationships

25. Potential Problems (Attributes associated with more than one entity)
Attributes seem to be associated with more than one
Entity. This can indicate the following:
1. It may be that you’ve identified several entities that can be represented as a single entity.
For example, you may have identified entities Manager and Supervisor both with the attributes staffNo (staff number), name, and salary, which can be represented as a single entity called Staff with the attributes staffNo, name, position, and salary.
Step 1.3 Identify the attributes associated with entities or relationships

26. Potential Problems (Attributes associated with more than one entity)
It may be that you’ve identified a relationship between entities.
In this case, you must associate the attribute with only one entity, namely the parent entity, and ensure that the relationship was previously identified in Step 1.2.
Step 1.3 Identify the attributes associated with entities or relationships

27. Potential Problems (Attributes associated with more than one entity)
For example, you may have identified the entities Branch and Staff with the following attributes:
The presence of the managerName attribute in Branch is intended to represent the relationship
Staff Manages Branch
In this case, the managerName attribute should be omitted from Branch and the relationship Manages should be added to the model
Branch branchNo, street, city, state,
zipCode, managerName
Staff staffNo, name, position, salary
Step 1.3 Identify the attributes associated with entities or relationships

28. StayHome Attributes For Entities
Branch
Staff
Video
Director
Actor
Member
RentalAgreement
VideoForRent
branchNo, address (composite: street, city, state, ZipCode),
telNo (multi-valued)
staffNo, name, position, salary
catalogNo, title, category, dailyRental, price
directorName
actorName
memberNo, name (composite: fName, lName), address
rentalNo, dateOut, dateReturn
videoNo, available
Step 1.3 Identify the attributes associated with entities or relationships

29. Attributes For Relationships
You may have difficulty associating the attribute representing the date a member is registered at a branch, dateJoined, with a particular entity.
There are potentially three entities associated with this attribute
Member, Branch, and Staff
However, this attribute cannot be associated with any of these entities
Step 1.3 Identify and associate attributes with entities or relationships

30. Attributes For Relationships
A member can register at many branches, a member of staff can register many members at many branches, and a branch has many members.
The solution is to associate the dateJoined attribute with the Registers ternary relationship,
which relates the Member, Branch, and Staff entities.
ERD
Step 1.3 Identify and associate attributes with entities or relationships

31. Documenting Attributes
Record the following information for each attribute:
Attribute name and description
Data type and length
Any aliases that the attribute is known by
Whether the attribute must always be specified
Allows or disallows nulls
Step 1.3 Identify and associate attributes with entities or relationships

32. Documenting Attributes (Cont…)
Record the following information for each attribute:
Whether the attribute is multi-valued
Whether the attribute is composite
If so, which simple attributes make up the composite attribute
Whether the attribute is derived
If so, how it should be computed
Default values for the attribute
Step 1.3 Identify and associate attributes with entities or relationships

33. Step 1.4 Determine Attribute Domain (值域)
A domain is a set of values from which one or more attributes draw their values
A domain specifies:
The set of allowable values for a given attribute
The size and format of a given attribute
Step 1.4 Determine attribute domains

34. Examples of Attribute Domain
The attribute domain of valid branch numbers
A four-character, fixed-length string, with
the first character as a letter
the next three characters as digits in the range
The attribute domain for valid telephone numbers
A 10-digit string
Step 1.4 Determine attribute domains

35. Document Attributes In Data Dictionary
Multi-valued?
Composite?
Derived? How?
Default value?
Constraint?
Key?
Attribute domain
Step 1.3 Identify and associate attributes with entities or relationships

36. Step 1.5 Determine Candidate, Primary, and Alternate Key Attributes
Identifying candidate key(s) for an entity and then selecting one to be the primary key.
Primary keys can never be null.
Remaining candidate keys are called alternate keys.
Document candidate, primary, and alternate keys
ERD
Step 1.5 Determine Candidate, Primary, and Alternate Key Attributes

37. StayHome ERD and Primary Keys
Step 1.5 Determine Candidate, Primary, and Alternate Key Attributes

38. Document Candidate, Primary, and Alternate Keys in Data Dictionary
Multi-valued?
Composite?
Derived? How?
Default value?
Constraint?
Step 1.5 Determine Candidate, Primary, and Alternate Key Attributes

39. Step 1.6 Check Model Supports User Transactions
The objective of this step:
Check the ER model to ensure that the model supports the required transactions.
Using the ER model and data dictionary to perform the transactions manually.
Two possible approaches:
(1) Describing the transaction
(2) Using transaction pathways
Step 1.8 Check Model Supports User Transactions

40. Describing the Transaction
Check that all the information (entities, relationships, and their attributes) required by each transaction is provided by the model.
Example:
Transaction : List the name of each manager at each branch, ordered by branch number
The name of each manager is held in the Staff entity
Branch details are held in the Branch entity.
We can use the Staff-Manages-Branch relationship to find the name of each manager for each branch.

41. Using Transaction Pathways
Validating a data model against the required transactions involves representing the pathway taken by each transaction directly on the ER diagram.
An example of this approach using data queries is listed in Section 4.4.4
Clearly, the more transactions that exist, the more complex this diagram would become. So, for readability you may need several such diagrams to cover all the transactions.

42. Transaction Requirements For Data Queries
Data Queries (Section on Page 76)
List the details of branches in a given city
List the name, position, and salary of staff at a given branch, ordered by staff name
List the name of each Manager at each branch, ordered by branch number
List the title, category, and availability of all videos at a specified branch, ordered by category.
List the title, category, and availability of all videos at a specified branch for a given actor’s name, ordered by category
List the title, category, and availability of all videos for a given director’s name at a specified branch, ordered by title.
List the details of all videos a specified member currently has on rent
List the details of copies of a given video at a specified branch.
……………
Step 1.8 Check Model Supports User Transactions

43. Using Transaction Pathways…
actor
many videos
many video copies
many branches
Using Transaction Pathways
Step 1.8 Check Model Supports User Transactions

44. Step 1.7 Check Model With Users
Review the ER model with the users to ensure that the model is a ‘true’ representation of the data requirements of an organization (or the part of an organization) to be supported by the database.