1. Database Design, Application Development, and Administration, 5 th Edition Copyright © 2011 by Michael V. Mannino All rights reserved. Chapter 6 Developing Data Models for Business Databases

2. Slide 2Chapter 6: Developing Data Models for Business Databases Outline  Guidelines for analyzing business information needs  Transformations for generating alternative designs  Finalizing an ERD  Schema Conversion

3. Slide 3Chapter 6: Developing Data Models for Business Databases Characteristics of Business Data Modeling Problems  Poorly defined  Conflicting statements  Wide scope  Missing details  Many stakeholders  Requirements in many formats  Add structure  Eliminate irrelevant details  Add missing details  Narrow scope

4. Slide 4Chapter 6: Developing Data Models for Business Databases Goals of Narrative Problem Analysis  Consistency with narrative  No contradictions of explicit narrative statements  Identify shortcomings  Ambiguous statements  Missing details  Simplicity preference  Choose simpler designs especially in initial design  Add refinements and additional details later

5. Slide 5Chapter 6: Developing Data Models for Business Databases Steps of Narrative Problem Analysis  Identify entity types and attributes  Determine primary keys  Add relationships  Determine connections  Determine relationship cardinalities  Simplify relationships

6. Slide 6Chapter 6: Developing Data Models for Business Databases Determine Entity Types and Attributes  For entity types, find nouns that represent groups of people, places, things, and events  For attributes, look for properties that provide details about the entity types  Simplicity principal: consider as an attribute unless other details

7. Slide 7Chapter 6: Developing Data Models for Business Databases Determine Primary Keys  Stable: never change after assigned  Single purpose: no other purpose  Good choices: automatically generated values  Compromise choice for industry practices  Identify other unique attributes

8. Slide 8Chapter 6: Developing Data Models for Business Databases Government Identifiers  Widely used for tax returns and government benefits  Avoid for primary keys  Privacy concerns  Prohibited by organization policies  Sometimes violate single-purpose tenet  May need to store as an attribute for government compliance

9. Slide 9Chapter 6: Developing Data Models for Business Databases Entity Identification Example

10. Slide 10Chapter 6: Developing Data Models for Business Databases Identify Relationships  Identify relationships connecting previously identified entity types  Relationship references involve associations among nouns representing entity types  Sentences that involve an entity type having another entity type as a property  Sentences that involve an entity type having a collection of another entity type

11. Slide 11Chapter 6: Developing Data Models for Business Databases Relationship Identification Example

12. Slide 12Chapter 6: Developing Data Models for Business Databases Relationship Simplification  Problem statement requires direct or indirect connections  Hub entity types to simplify  Connect other entity types  Sometimes associated with important documents  Reduce number of direct connections

13. Slide 13Chapter 6: Developing Data Models for Business Databases Diagram Refinements  Construct initial ERD  Revise many times  Generate feasible alternatives and evaluate according to requirements  Gather additional requirements if needed  Use transformations to suggest feasible alternatives

14. Slide 14Chapter 6: Developing Data Models for Business Databases Attribute Expansion Transformation

15. Slide 15Chapter 6: Developing Data Models for Business Databases Compound Attribute Transformation

16. Slide 16Chapter 6: Developing Data Models for Business Databases Entity Type Expansion Transformation

17. Slide 17Chapter 6: Developing Data Models for Business Databases Entity Type Expansion Transformation II

18. Slide 18Chapter 6: Developing Data Models for Business Databases Weak to Strong Entity Transformation

19. Slide 19Chapter 6: Developing Data Models for Business Databases Attribute History Transformation

20. Slide 20Chapter 6: Developing Data Models for Business Databases 1-M Relationship History Transformation

21. Slide 21Chapter 6: Developing Data Models for Business Databases M-N Relationship History Transformation (I)

22. Slide 22Chapter 6: Developing Data Models for Business Databases M-N Relationship History Transformation (II)

23. Slide 23Chapter 6: Developing Data Models for Business Databases Limited History Transformation

24. Slide 24Chapter 6: Developing Data Models for Business Databases Generalization Hierarchy Transformation I

25. Slide 25Chapter 6: Developing Data Models for Business Databases Generalization Hierarchy Transformation II

26. Slide 26Chapter 6: Developing Data Models for Business Databases Summary of Transformations  Attribute expansion  Compound attribute split  Entity type expansion  Weak entity to strong entity  Add history: attributes, 1-M relationships, and M-N relationships  Generalization hierarchy addition

27. Slide 27Chapter 6: Developing Data Models for Business Databases Documenting an ERD  Important for resolving questions and communicating a design  Identify inconsistency and incompleteness in a specification  Identify situations when more than one feasible alternative exists  Do not repeat the details of the ERD  Incorporate documentation into the ERD

28. Slide 28Chapter 6: Developing Data Models for Business Databases Documentation with the ER Assistant  Attribute comments  Entity type comments  Relationship comments  Design justifications  Diagram notes

29. Slide 29Chapter 6: Developing Data Models for Business Databases Common Design Errors  Misplaced relationships: wrong entity types connected  Incorrect cardinalities: typically using a 1-M relationship instead of a M-N relationship  Missing relationships: entity types should be connected directly  Overuse of specialized modeling constructs:  Generalization hierarchies,  Identification dependency,  Self-referencing relationships,  M-way associative entity types  Redundant relationships: derived from other relationships

30. Slide 30Chapter 6: Developing Data Models for Business Databases Resolving Design Errors  Misplaced relationships: use entity type clusters to reduce connections  Incorrect cardinalities:  Incomplete requirements  Reversed cardinalities  Missing relationships: examine implications of requirements  Overuse of specialized modeling tools: only use when usage criteria are met  Redundant relationships: examine relationship cycles for derived relationships

31. Slide 31Chapter 6: Developing Data Models for Business Databases Example Entity Type Cluster

32. Slide 32Chapter 6: Developing Data Models for Business Databases Summary of Data Modeling Guidelines  Use notation precisely  Strive for simplicity  ERD connections  Avoid over connecting the ERD  Identify hub(s) of the ERD  Use specialized patterns carefully  Justify important design decisions

33. Slide 33Chapter 6: Developing Data Models for Business Databases Summary of Basic Conversion Rules  Each entity type becomes a table.  Each 1-M relationship becomes a foreign key in the table corresponding to the child entity type (the entity type near the crow’s foot symbol).  Each M-N relationship becomes an associative table with a combined primary key.  Each identifying relationship adds a column to a primary key.

34. Slide 34Chapter 6: Developing Data Models for Business Databases Application of Basic Rules (I) CREATE TABLE Course (… PRIMARY KEY (CourseNo) ) CREATE TABLE Offering (… PRIMARY KEY OfferNo, FOREIGN KEY (CourseNo) REFERENCES Course )

35. Slide 35Chapter 6: Developing Data Models for Business Databases Application of Basic Rules (II) CREATE TABLE Enrollment (… PRIMARY KEY (StdNo, OfferNo), FOREIGN KEY (StdNo) REFERENCES Student, FOREIGN KEY OfferNo REFERENCES Offering )

36. Slide 36Chapter 6: Developing Data Models for Business Databases Application of Basic Rules (III) Same conversion result as the previous slide Different application of rules

37. Slide 37Chapter 6: Developing Data Models for Business Databases Application of Basic Rules (IV) CREATE TABLE Faculty (… FOREIGN KEY (FacSupervisor) REFERENCES Faculty) CREATE TABLE Course (… PRIMARY KEY CourseNo) CREATE TABLE Prereq_To (PreReqCNo …, DepdendCNo … PRIMARY KEY (PrereqCNo …, DependCNo …, FOREIGN KEY (PrereqCNo) REFERENCES Course, FOREIGN KEY (DependCNo) REFERENCES Course )

38. Slide 38Chapter 6: Developing Data Models for Business Databases Generalization Hierarchy Rule  Mimic generalization hierarchy as much as possible  Each subtype table contains specific columns plus the primary key of its parent table.  Foreign key constraints for subtype tables  CASCADE DELETE option for referenced rows  Reduce need for null values  Need joins and outer joins to combine tables

39. Slide 39Chapter 6: Developing Data Models for Business Databases Generalization Hierarchy Example Employee table: EmpNo (PK) SalaryEmp table: EmpNo (PK), EmpNo (FK) HourlyEmp table: EmpNo (PK), EmpNo (FK)

40. Slide 40Chapter 6: Developing Data Models for Business Databases Optional 1-M Rule  Separate table for each optional 1-M relationship  Avoids null values  Requires an extra table and join operation  Controversial: in most cases 1-M rule is preferred

41. Slide 41Chapter 6: Developing Data Models for Business Databases Optional 1-M Example CREATE TABLE Teaches (… PRIMARY KEY (OfferNo), FOREIGN KEY(OfferNo) REFERENCES Offering, FOREIGN KEY(FacNo) REFERENCES Faculty )

42. Slide 42Chapter 6: Developing Data Models for Business Databases 1-1 Relationships CREATE TABLE Office (… PRIMARY KEY (OfficeNo), FOREIGN KEY(EmpNo) REFERENCES Employee, UNIQUE (EmpNo) )

43. Slide 43Chapter 6: Developing Data Models for Business Databases Conversion in Aqua Data Studio Conversion close match to ERD One table per entity type

44. Slide 44Chapter 6: Developing Data Models for Business Databases Summary  Data modeling is an important skill  Use notation precisely  Preference for simpler designs  Consider alternative designs  Review design for common errors  Work many problems