1. April 20022/CS/3X1 Database Design Design method John Wordsworth Department of Computer Science The University of Reading J.B.Wordsworth@rdg.ac.uk Room 129, Ext 6544

2. April 20022/CS/3X2 Lecture objectives To provide an overview of the design process To explain the terms conceptual design, logical design and physical design as applied to database

3. April 20022/CS/3X3 Overview of the design process Step 1: Conceptual database design –Understand what’s there; for the moment don’t worry about database theory or the technology Steps 2 and 3: Logical database design –Transform the conceptual design into one that is theoretically sound Step 4 to 9: Physical database design –Transform the logical design into one that works with the chosen technology

4. April 20022/CS/3X4 Step 1: Conceptual database design 1.1Identify entity types. 1.2Identify relationship types. 1.3Identify and associate attributes with entity types. 1.4Determine attribute domains. 1.5Determine candidate keys and primary keys. 1.6 Consider use of enhanced modelling concepts. 1.7 Check model for redundancy. 1.8Validate local conceptual model against user transactions. 1.9 Review conceptual data model with users.

5. April 20022/CS/3X5 Steps 2 and 3: Logical database design Step 2:Build and validate logical data models for each view.

6. April 20022/CS/3X6 Step 2.1 Remove features not compatible with the relational model (1) Remove many-many binary relationships. (2) Remove many-many recursive relationships. (3) Remove complex relationships. (4) Remove multivalued attributes.

7. April 20022/CS/3X7 Step 2.2 Derive relations for logical data model (1) Strong entity types. (2) Weak entity types. (3) One-many binary relationship types. (4) One-one binary relationship types. (5) One-one recursive relationships (6) Super/subclass relationship types. (7) Many-many binary relationship types. (8) Complex relationship types. (9) Multivalued attributes

8. April 20022/CS/3X8 Step 2.3 Validate by normalisation First normal form removes repeating groups. Second normal form removes partial dependencies on the primary key. Third normal form removes transitive dependencies. Boyce-Codd normal form removes remaining anomalies from functional dependencies.

9. April 20022/CS/3X9 Validation of local LDM Step 2.4Validate relations against user transactions Step 2.5Define integrity constraints –Required data –Attribute domain constraints –Entity integrity –Referential integrity –Enterprise constraints (= business rules) Step 2.6Review local logical data model with user

10. April 20022/CS/3X10 Referential integrity (1) Insert a tuple into a child relation. (2) Delete tuple from child relation. (3) Update foreign key of child tuple. (4) Insert tuple into parent relation. (5) Delete tuple from parent relation –No action –Cascade –Set null –Set default –No check (6) Update primary key of parent relations

11. April 20022/CS/3X11 Step 3.1 Merge local LDMs in to Global LDM (1)Review names and contents of entities (relations) and their candidate keys. (2)Review names and contents of relationships and foreign keys. (3)Merge entities from local models. (4)Include entities unique to each local model. (5)Merge relationships from local models. (6)Include relationships unique to each local model. (7)Check for missing entities and relationships. (8)Check foreign keys. (9)Check integrity constraints. (10)Draw the global E-R diagram. (11)Update the documentation.

12. April 20022/CS/3X12 Rest of step 3 3.2Validate global logical data model 3.3Check for future growth 3.4Review global logical data model with users.

13. April 20022/CS/3X13 Steps 4 to 9 Physical database design Step 4: Translate global LDM for target DBMS Step 5: Design physical representation Step 6: Design user views Step 7: Design security mechanisms Step 8: Consider introducing controlled redundancy Step 9: Monitor and tune the operational system.

14. April 20022/CS/3X14 Step 4: Translate LDM for target DBMS Step 4.1Design base relations Step 4.2Design representation of derived data. Step 4.3 Design the enterprise constraints for target DBMS

15. April 20022/CS/3X15 Step 5: Design physical representation (1) Step 5.1Analyze transactions –frequency of transaction –what relations and attributes are accessed –what is the type of access (query, insert, update, delete) Note: if an attribute is updated, take care if it is to be included in a secondary index) –care with attributes used in predicates (WHERE), and the type of predicates (possible candidate for access structures (indexes)) –care with attributes used in joins (candidates for access structures) –time constraints

16. April 20022/CS/3X16 Design physical representation: 2 Step 5.2Choose file organizations –DMBS may or may not give you authority in this matter Step 5.3Choose secondary indexes –DBMS should give you authority here Step 5.4Estimate disk space requirements

17. April 20022/CS/3X17 Security and tuning Step 6: Design user views Step 7: Design security mechanisms –Step 6.1Design user views –Step 6.2Design access rules Step 8: Consider the introduction of controlled redundancy Step 9: Monitor and tune the operational system

18. April 20022/CS/3X18 Key points Conceptual design creates a number of entity-relationship models of the data. Logical design merges the conceptual models, and creates a relational model. Physical design organises the data on physical hardware devices.