1. Conceptual Design (CB 16) CPSC 356 Database Ellen Walker Hiram College (Includes figures from Database Systems by Connolly & Begg, © Addison Wesley 2002) )

2. Levels of Database Design Conceptual database design –Identify important entities, relationships, and attributes Logical database design –Translate concepts to logical structure (relations) Physical database design –Determine how logical structure is physically implemented in the target DBMS

3. Critical Success Factors Work interactively with the user as much as possible Follow a structured methodology (process) Be data-driven Incorporate structural and integrity constraints Use diagrams (e.g. ER) Build a data dictionary Be willing to repeat steps!

4. Conceptual Design Steps Identify entity types Identify relationship types Identify and associate attributes for entities & relationships Determine attribute domains Determine key attributes (especially PK) Check for redundancy Validate against transactions Review with user

5. Identifying Entity Types Generally nouns and noun phrases in user specification “Major” nouns -- if it qualifies another noun, it might be an attribute But, attributes can’t have attributes (!) Realize, initial decisions might have to be changed

6. Entities for Dream Home DreamHome has branch offices in cities throughout the UK. Each office is allocated members of staff, including a Manager… Each branch office offers a range of properties for rent. … the management of a property is assigned to a member of staff whenever it is rented out …

7. Entities for Dream Home (cont’d) The details of property owners are also stored … The data stored for private owners includes owner number, name, address, telephone number, email and password. DreamHome refers to members of the public interested in renting as clients. … When a property is rented out, a lease is drawn up between the client and the property…

8. Find the Entities in this 2004 Project: This database will be a campus-wide inventory of all plants on campus that would include information like GPS coordinates, growing hints, and uses. We also want to list all the gardens and their contents. We would also like to keep track of our members and useful things about them with respect to gardens.

9. Data Dictionary Collects all information about each entity, e.g. –Entity name –Description –Aliases (other names) –Occurrence Data dictionary serves as a blueprint, also helps identify duplication (synonyms)

10. Identifying Relationships Look for verbs or verbal expressions in the specfication Relationships must be between entities Most relationships are binary Consider implicit relationships –Check all pairs of entities ? –Missing relationships will show up in validation Add relationships and multiplicity constraints to data dictionary

11. Relationships for Dream Home DreamHome has branch offices in cities throughout the UK. Each office is allocated members of staff, including a Manager… Each branch office offers a range of properties for rent. … the management of a property is assigned to a member of staff whenever it is rented out …

12. Relationships for Dream Home (cont’d) The details of property owners are also stored … The data stored for private owners includes owner number, name, address, telephone number, email and password. DreamHome refers to members of the public interested in renting as clients. … When a property is rented out, a lease is drawn up between the client and the property…

13. Data Dictionary Excerpt (Entities & Relationships) Entity NameDescriptionAliasesOccurrences StaffDescribes anyone employed by DreamHome EmployeeEach member of staff works at one branch PropertyForRentA property that can be (or is) rented PropertyEach property has one owner and is available at one branch,where the property is managed by one member of staff. It can be viewed by many clients and rented by one client at a time. Connelly & Begg Figure 6.1

14. Relationships in the 2004 Project? This database will be a campus-wide inventory of all plants on campus that would include information like GPS coordinates, growing hints, and uses. We also want to list all the gardens and their contents. We would also like to keep track of our members and useful things about them with respect to gardens.

15. Attributes “What do we need to know / store about X?” –X is an entity or relationship Simple vs. composite attributes –Based on client’s needs –Can change later if needed –If composite, note the parts e.g. addressStreet, addressCity, addressZip Derived(computed) attributes –E.g. age derived from birthdate & current year

16. Attribute Example The details of property owners are also stored … The data stored for private owners includes owner number, name, address, telephone number, email and password.

17. Modifying Entities (Relationships vs. Attributes) An entity cannot be an attribute of another entity - use a relationship instead Multi-valued attributes are better expressed as relationships (e.g. phone #) –If you don’t do it now, that’s OK because it will be fixed later.

18. Documenting Attributes Name and description Data type and length (domain) Aliases Simple attributes, if composite How to compute, if derived Default value, if any

19. Attributes in Data Dictionary AttributeDescriptionData Type Null OK? Multi- valued? staffNoUnique id for staff member IntegerNo nameComposite; consists of fname, lname) fnameFirst name15 chars (variable) YesNo LnameLast name30 chars (variable) No positionJob title10 chars (variable) No DOBDate of birthDateYesNo

20. Attributes in 2004 Project? This database will be a campus-wide inventory of all plants on campus that would include information like GPS coordinates, growing hints, and uses. We also want to list all the gardens and their contents. We would also like to keep track of our members and useful things about them with respect to gardens.

21. Key Determination Candidate keys are smallest sets of attributes that uniquely define an entity Primary key is a chosen candidate key Choose so that: –Minimal number of attributes –Values least likely to change –Smallest (e.g. fewest characters, smallest max value) –Easiest for user (search by…)

22. Which are Candidate Keys for Staff? Why (Not)? Fname? Lname? Fname, Lname? Lname, DOB? Fname, Lname, DOB? StaffNo? StaffNo, Lname?

23. Documentation Document keys in data dictionary Note weak entities (no key)

24. ER Diagram contains… Entities (box – above line) Attributes (box – below line) Relationship (connecting line with arrow) –Cardinalities (x..y at each end of line) –Relationship attributes (box with empty top, dotted line to relationship line)

25. DreamHome ER Diagram Figure 16.5

26. Check for Redundancy Redundancy in a database is bad –Cost of multiple-entry –Risk of inconsistency Recheck 1:1 relationships –Should entities be merged? Remove redundant relationships –If you can get from entity X to entity Y through 2 or more paths, consider whether relationships can be eliminated (direct vs. indirect) –Not all cycles should be eliminated, depending on meaning of the relationship [Document decisions]

27. Consider Transactions A transaction is something the user wants to do with the database (e.g. print a student schedule) –Can the transaction be carried out using only the information in the ER diagram? –If so, you should be able to follow a path (of relationships) in the ER diagram to collect the data. (See p. 457)

28. Use Cases and Transactions Each use case describes a transaction Evaluate the model for each use case –Is there a missing path (relationship) to get the needed data? If so, consider what entities, relationships and/or attributes need to be added. –Are there portions of the diagram that are never used? If so, consider removing those entities, relationships, and/or attributes from the database.

29. Review Results with User User should “sign off” that the model accurately reflects their understanding… Do not expect the user to understand the ER diagram directly, without significant explanation from you Review the data dictionary with the user to ensure you’ve got correct entities