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

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

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

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.

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

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

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

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

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

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

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

Document Entities In Data Dictionary Step 1.1 Identify entities

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

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

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

First Draft Of The Relationships ERD Step 1.2 Identify relationships

First Draft Of The ER Diagram Step 1.2 Identify relationships

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

Adding Multiplicity Constraints to the ER Model Step 1.2 Identify relationships

Identify Relationships Document relationships in data dictionary Step 1.2 Identify relationships

Typical questions given to users : Step 1.3 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

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

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

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

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

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

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

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

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

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

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

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

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

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 000-999 The attribute domain for valid telephone numbers A 10-digit string Step 1.4 Determine attribute domains

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

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

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

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

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

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.

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.

Transaction Requirements For Data Queries Data Queries (Section 4.4.4 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

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

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.