Modelling Methodologies Chapter 16, 17, 18

Modeling Methodologies2 Database Design Physical DB design Logical DB design Conceptual DB design Hardware dependent Software dependent Hardware independent Software dependent Hardware independent Software independent

Modeling Methodologies3 3 Success Factors in Database Design Work interactively with users as much as possible. Follow a structured methodology throughout the data modelling process. Employ a data-driven approach. Incorporate structural and integrity considerations into the data models. Combine conceptualization, normalization, and transaction validation techniques into the data modelling methodology. Use diagrams to represent as much of the data models as possible. Build a data dictionary to supplement the data model diagrams. Be willing to repeat steps.

Modeling Methodologies4 4 Design Methodology Overview Step 1 Build conceptual data model. Step 2 Build and validate logical data model. Step 3 Translate logical data model for target DBMS. Step 4 Design file organizations and indexes. Step 5 Design user views. Step 6 Design security mechanisms. Step 7 Consider the introduction of controlled redundancy. Step 8 Monitor and tune the operational system. Conceptual DB design Logical DB design Physical DB design

Modeling Methodologies5 Database Design Physical DB design Logical DB design Conceptual DB design Hardware dependent Software dependent Hardware independent Software dependent Hardware independent Software independent

Modeling Methodologies6 Step 1 Build Conceptual Data Model for Each View Objective: To build a conceptual data model of an enterprise for each specific view. Step 1.1 Identify entity types Objective: To identify the main entity types that are required by the view; Document entity types in data dictionary. Entity Name Description Aliases Occurrence Staff General term describing all staff Employee Each member of staff works at one particular branch employed by DearmHome Each property has a single owner & is available at PropertyForRent General term describing all Property one specific branch, where the property is managed property for rent by 1 member of staff. A property is viewed by many clients and rented by a single client at a time Data Dictionary for Staff View Showing Description of Entities

Modeling Methodologies7 Step 1 Build Conceptual Data Model for Each View Step 1.2 Identify relationship types Objective: To identify the important relationships that exist between the entity types that have been identified.

Modeling Methodologies8 ERD for Staff View of DreamHome

Modeling Methodologies9 Step 1 Build Conceptual Data Model for Each View Entity Name Multiplicity Relationship Entity Name Multiplicity Staff 0..1 Manages PropertyForRent Supervises Staff PropertyForRent 1..1 AssociatedWith Lease 0..* Data Dictionary for Staff View Showing Description of Relationships

Modeling Methodologies10 Step 1 Build Conceptual Data Model for Each View Step 1.3 Identify and associate attributes with entity or relationship types Objective: To identify and associate attributes with the appropriate entity or relationship types and document the details of each attribute. Step 1.4 Determine attribute domains Objective: To determine domains for the attributes in the data model and document the details of each domain.

Modeling Methodologies11 Step 1 Build Conceptual Data Model for Each View Entity Attribute Description Data Length Nulls Multi- Default Range PK CK Name Type Valued Value Staff StaffNo Uniquely identifies a staff member varchar 5 No No Y Y name FName First name of Staff varchar 15 No No Lname Last name of Staff varchar 15 No No position Job title of member of staff varchar 10 No No sex Gender of member of staff character 1 Yes No M F, M DOB Date of Birth of member of staff Date Yes No Data Dictionary for Staff View Showing Description of Attributes

Modeling Methodologies12 Step 1 Build Conceptual Data Model for Each View Step 1.5 Determine candidate and primary key attributes Objective: To identify the candidate key(s) for each entity and if there is more than one candidate key, to choose one to be the primary key.

Modeling Methodologies13 ERD for Staff View of DreamHome with PK

Modeling Methodologies14 Step 1 Build Conceptual Data Model for Each View Step 1.6 Consider use of enhanced modeling concepts Objective: To consider the use of enhanced modeling concepts, such as specialization / generalization, aggregation, and composition.

Modeling Methodologies15 ERD for Staff View of DreamHome with specialization / generalization

Modeling Methodologies16 Step 1 Build Conceptual Data Model for Each View Step 1.7 Check model for redundancy Objective: To check for the presence of any redundancy in the model. 1. Re-examine 1:1 relationships. 2. Remove redundant relationships. Step 1.8 Validate conceptual model against user transactions Objective: To ensure that the conceptual model supports the transactions required by the view. Describe the transaction. Use transaction pathways: diagrammatically represent the pathway taken by each transaction on the ERD.

Modeling Methodologies17 Using transaction’s Pathways

Modeling Methodologies18 Step 1 Build Conceptual Data Model for Each View Step1.9 Review conceptual data model with user Objective: To review the conceptual data model with the user to ensure that the model is a ‘true’ representation of the user’s view of the enterprise.

Modeling Methodologies19 Database Design Physical DB design Logical DB design Conceptual DB design Hardware dependent Software dependent Hardware independent Software dependent Hardware independent Software independent

Modeling Methodologies20 Logical DB Design Objectives Map the conceptual model into relations. Validate these relations using the technique of normalization. Validate a logical data model to ensure it supports required user transactions. Merge local logical data models based on specific views into a global logical data model of the enterprise. Ensure that resultant global model is a true and accurate representation of enterprise.

Modeling Methodologies21 Step 2 Build and Validate Logical Data Model Step 2.1 Derive relations for logical data model Step 2.2 Validate relations using normalization Step 2.3 Validate relations against user transactions Step 2.4 Define integrity constraints Step 2.5 Review logical data model with user Step 2.6 Merge logical data models into global model (optional step) Step Merge local logical data models into global model Step Validate global logical data model Step Review global logical data model with users Step 2.7 Check for future growth

Modeling Methodologies22 Step 2 Build and Validate Logical Data Model Step 2.1 Derive relations for logical data model Objective: To create relations for the logical data model to represent the entities, relationships, and attributes that have been identified. (Covered before in this course) Step 2.2 Validate relations using normalization Objective: To validate the relations in the logical data model using normalization. Step 2.3 Validate relations against user transactions Objective: To ensure that the relations in the logical data model support the required transactions.

Modeling Methodologies23 Step 2.4Define integrity constraints Step 2.4 Define integrity constraints Step 2.4 Define integrity constraints Integrity constraints protects DB from being inconsistent. Types of integrity constraints: Required data. Attribute domain constraints. Multiplicity. Entity integrity. Referential integrity. General constraints.

Modeling Methodologies24 Referential Integrity Constraints for Relations

Modeling Methodologies25 Step 2.5 Review logical data model with user Objective: To review the logical data model with the users to ensure that they consider the model to be a true representation of the data requirements of the enterprise.

Modeling Methodologies26 Step 2.6 Merge logical data models into global model (optional step) To merge logical data models into a single global logical data model that represents the enterprise. Step Merge local logical data models into global model Step Validate global logical data model Step Review global logical data model with users

Modeling Methodologies27 Step Merge logical data models into global model (optional step) 1. Review the names & contents of entities/relations and their CK. 2. Review the names & contents of relationships/FK. 3. Merge entities/relations from the local data models. 4. Include (without merging) entities/relations unique to each local data model. 5. Merge relationships/FK from the local data models. 6. Include (without merging) relationships/FKs unique to each local data model. 7. Check the missing entities/relations and relationships/FKs. 8. Check FKs. 9. Check integrity constraints. 10. Draw the global ER/relation diagram. 11. Update the documentation.

Modeling Methodologies28 1. Review the names & contents of entities/relations and their CK Branch View Entity Type CK Branch BranchNo PostCode Telephone TelNo Staff StaffNo Manager StaffNo PrivateOwner OwnerNo BusinessOwner Bname telNo Client ClientNo PropertyForRent Propertyno Lease LeaseNo PropertyNo RentStart ClientNo, RentStart Staff View Entity Type CK Staff StaffNo PrivateOwner OwnerNo BusinessOwner Bname telNo OwnerNo Client ClientNo PropertyForRent Propertyno Viewing ClientNo, PropertyNo

Modeling Methodologies29 2. Review the names & contents of relationships/FK Branch View FK Relationship mgrStaffNo -> Manager(StaffNo) Manages branchN -> Branch(branchNo) supervisorStaffNo -> Staff(staffNo) Supervisor branchNo -> Branch(branchNo) StaffNo -> Staff(StaffNo) OwnerNo -> PrivateOwner(ownerNo) Owns OwnerNo -> Owns BusinessOwner(ownerNo) StaffNo -> Staff(StaffNo) Oversees BranchNo -> Branch(BranchNo) Offers Staff View FK Relationship Relation Branch Telephone Staff Manager PrivateOwner BusinessOwner Client PropertyForRent Viewing supervisorStaffNo -> Staff(staffNo) Supervisor StaffNo -> Staff(StaffNo) Registers OwnerNo -> PrivateOwner(ownerNo) POwns OwnerNo -> BOwns BusinessOwner(ownerNo) StaffNo -> Staff(StaffNo) Manages

Modeling Methodologies30 3. Merge entities/relations from the local data models Merge entities/relations with the same name & the same PK. Branch ViewStaff View PRIVATE OWNER(Ono, name, address) PRIVATE OWNER(Ono, fname, lname, address) Global View PRIVATE OWNER(Ono, fname, lname, address)

Modeling Methodologies31 3. Merge entities/relations from the local data models Merge entities/relations with the same name but different PK. Branch ViewStaff View BOWNER(bName, bType, address,telNO) BOWNER(Ono, bName, bType, address,telNo) AK telNo AK bName, telNo Global View BOWNER(Ono, bName, bType, address) AK bName, telNo

Modeling Methodologies32 Step Step Validate global logical data model Objective: To validate the relations created from the global logical data model using the technique of normalization and to ensure they support the required transactions, if necessary.

Modeling Methodologies33 Step Step Review global logical data model with users Objective: To review the global logical data model with the users to ensure that they consider the model to be a true representation of the data requirements of an enterprise.

34 Relations for the Branch user views of DreamHome Pearson Education © 2009

35 Relations that represent the global logical data model for DreamHome Pearson Education © 2009

36 Global relation diagram for DreamHome Pearson Education © 2009

37 Step 2.7 Check for future growth Objective: To determine whether there are any significant changes likely in the foreseeable future and to assess whether the global logical data model can accommodate these changes. Pearson Education © 2009

Modeling Methodologies38 Database Design Physical DB design Logical DB design Conceptual DB design Hardware dependent Software dependent Hardware independent Software dependent Hardware independent Software independent

Modeling Methodologies39 Comparison of Logical and Physical Database Design Logical database design is concerned with the what, Physical database design is concerned with the how. Process of producing a description of the implementation of the database on secondary storage; it describes the base relations, file organizations, and indexes used to achieve efficient access to the data, and any associated integrity constraints and security measures. Physical DB Design

Modeling Methodologies40 Overview of Physical Database Design Methodology Step 3 Translate logical data model for target DBMS Step 3.1 Design base relations Step 3.2 Design representation of derived data Step 3.3 Design general constraints Step 4 Design physical representation Step 4.1 Analyze transactions Step 4.2 Choose file organizations Step 4.3 Choose indexes Step 4.4 Estimate disk space requirements Step 5 Design user views Step 6 Design security mechanisms Step 7 Consider the introduction of controlled redundancy Step 8 Monitor and tune the operational system

Modeling Methodologies41 Step 3 Translate Logical Data Model for Target DBMS Objective: To produce a relational database schema that can be implemented in the target DBMS from the global logical data model. Need to know functionality of target DBMS such as how to create base relations and whether the system supports the definition of: PKs, FKs, and AKs; required data (NOT NULL); domains; relational integrity constraints; enterprise constraints.

Modeling Methodologies42 Step 3.1 Design Base Relations Objective: To decide how to represent base relations identified in logical model. - For each relation, need to define: the name of the relation; a list of simple attributes in brackets; the PK and, where appropriate, AKs and FKs. referential integrity constraints for any FKs identified. - For each attribute, need to define: its domain, consisting of a data type, length, and any constraints on the domain; an optional default value for the attribute; whether the attribute can hold nulls. whether it is derived, and if so, how it should be computed.

Modeling Methodologies43 PropertyForRent Relation

Modeling Methodologies44 Step 3.2 Design Representation of Derived Data Objective: To decide how to represent any derived data present in the global logical data model in the target DBMS. Derived attribute can be stored in database or calculated every time it is needed. Option selected is based on: additional cost to store the derived data and keep it consistent with operational data from which it is derived; cost to calculate it each time it is required.

45 PropertyforRent Relation and Staff Relation with Derived Attribute noOfProperties Pearson Education © 2009

Modeling Methodologies46 Step 3.3 Design Enterprise Constraints Objective: To design the general constraints for the target DBMS. Some DBMS provide more facilities than others for defining enterprise constraints. Example: CONSTRAINT StaffNotHandlingTooMuch CHECK (NOT EXISTS (SELECT staffNo FROM PropertyForRent GROUP BY staffNo HAVING COUNT(*) > 100))