1. DATABASE LOGICAL DESIGN - I Chandra S. Amaravadi 1

2. 2 WHAT IS DESIGN? Database design involves what?

3. 3 DESIGN OBJECTIVES The objective of database design is to develop a set of well structured tables so that: Data is in the most efficient form No uncontrolled redundancies User needs satisfied Database can be easily implemented The output of design are a set of well structured/normalized tables.

4. ILL STRUCTURED TABLES EMPLOYEE 4 eidnametitledt. promoted 2356ArmstrongAnalyst4/14/09 3286NickersonSr. Analyst5/1/11; 2/5/12 EXAMPLE OF Ill structured tables are problematic. why?

5. DESIGN CONCEPTS ANOMALY: Insertion Deletion Update An inconsistency in the database that results from either adding records, deleting them or updating them. Three types of anomalies: 5

6. DESIGN CONCEPTS.. INSERTION ANOMALY: An insertion anomaly occurs if when trying to add a record, it cannot be added without additional information or it may need to be added in multiple places instead of in one location. DELETION ANOMALY: A deletion anomaly occurs, if when we try to delete a record, we have to perform the deletion a number of times, or if we lose information we did not intend to lose. 6

7. DESIGN CONCEPTS.. UPDATE ANOMALY/MODIFICATION ANOMALY: An update anomaly occurs, if when we try to update a record, instead of making the update in one location, we need to update in multiple locations. Are anomalies common in the file processing approach? 7

8. EMPLOYEES ILLUSTRATION OF ANOMALIES 8 empIDname dept. salarycoursedt completed 100 Jeff Simpson Mktg.48KSPSS 6/19/14 100 Jeff Simpson Mktg.48KSurvey6/19/13 140 Alan Beeton Acctg.52KTax Acct12/08/12 110 Chris Lucero IS43KSPSS1/22/13 110 Chris Lucero IS43KC++ 4/22/14 190 Lorenzo Davis Fin.55K 150 Susan Martin Mktg. 42KSPSS 6/19/13 150 Susan Martin Mktg. 42KJava 8/12/14

9. ANOMALIES.. 1. Insert Tom White, ID 130, Finance, 60K 2. Delete Employee with ID 140 3. Employee with ID 100 gets a 10% salary increase 9

10. 10 WELL STRUCTURED TABLE 10 no repeating groups redundancies minimized anomalies minimized all attributes dependent on pkey full functional dependency A Well structured table may be defined in a number of ways:

11. METHODS OF DESIGN ER diagrams (using thumb rules) Normalization theory FD approach brute force 11 Design can be carried out with:

12. DESIGN FROM ER CHARTS, USING THUMB RULES 12

13. 3. In the case of M:N, put each eclass into a separate table; put the relationship itself into a third table with Pkey consisting of Pkeys from the M and N sides. In the case of 1:M, put each eclass into separate tables; Include the Pkey from the one side as a foreign key on the M side. 2. In the case of 1:1, put each eclass into a separate table, with a cross-reference key in either. 1. DESIGN FROM ER: 13 Following are the rules for converting an ER diagram into a design

14. PRODUCT WARRANTY HAS DESIGN FROM ER.. Prod#Descr War#Eff_Dt Warranty War# Eff_dt ??? Products Prod# Descr ??? 14 In the case of 1:1, put each eclass into a separate table and ____________________.

15. DESIGN FROM ER.. CUSTOMER ORDERS Places Cust#Name PRODUCTSAre for Customer Cust# Name Orders Ord# Ord_dt ???? Ord#Ord_dt 15 In the case of 1:M, put each eclass into a separate table and ___________.

16. ORDERS PRODUCTSAre for DESIGN FROM ER.. Ord#Ord_dtProd#Descr. Orders ord# ord_dt Products prod# descr Orders for Products ??? ???? qty Qty 16 In the case of M:N, put each _____ into a separate table and place the ___________ into a separate table with keys from ___ side and __ side

17. DISCUSSION DEVELOP DESIGNS FOR THE FOLLOWING SITUATIONS CAR DRIVER assigned EMPLOYEES PROJECT has COMPANY SUPPLIER supplies car#model SS#nameproj#mgr SS# title s#location. name addr. 17

18. THREE WAY AND HIGHER EMPLOYEES DEPT HAS emp#ti d#name 18 How can we do design with degree >= 3? PROJECTS proj# cost

19. DESIGN WITH NORMALIZATION 19

20. DESIGN USING NORMALIZATION Use normalization theory if: Data relationships complex No planning/ER done Maintenance Alternative to ER approach 20 Normalization: The process of designing well-structured tables.

21. DESIGN CONCEPTS FUNCTIONAL DEPENDENCIES 21

22. DESIGN CONCEPTS.. A relationship between two or more attributes such that if we know one attribute we can uniquely determine other attributes. Functional dependency: a --> b, c.. ; “a determines b, c..”, ; “b,c.. are dependent on a” 22 FD test: For each value of a there is one and only one value of b.

23. DESIGN CONCEPTS.. Functional dependency (FD): relationship between attributes (L -> R unless specified) a  b, c, d is referred to as a functional dependency diagram Each value of a is associated with one value of b; one c… For a given value of “b” (or “c”..) there can be many values of “a” 23 a b : a determines b, b is dependent on a a b : a does not determine b, no relationship (normally omitted) a b : there are multiple values of b for each a.

24. 24 FD DIAGRAM EXAMPLES pp# name of issuing country flt# name of captain student id GPA player id team name pp# visa#’s GPA student id City name Hotel id price descr. gpa descr. Please note that FD is valid only in the first group; second group indicates need for additional keys (may result in partial functional dependencies)

25. FULL FD RULE relational Database Rule (Full functional dependency): All attributes must be fully dependent on the primary key ab c 25 Then they can be placed in a table with ____ as pkey.

26. FD WHEN DATA IS GIVEN ename --> phone#? phone# --> ename? ename  title? employee  dependents? EMPLOYEES 26 enamephone#titledependents Casey621-2876EngineerTracy, Tom Hugh621-3875ManagerNull Chris621-4534SecretaryAnn, Angie Franklin621-2876EngineerPat When data is given, perform FD test:

27. 27 abc a1b1c1 a1b1c2 a2b2c3 FD WHEN DATA IS GIVEN.. a --> b? a  c? b  c?

28. FD WHEN DATA IS NOT GIVEN A flight (flt#) arrives or departs at one gate (gate#) A flight (flt#) can have one captain (captain name) A flight (flt#) can have one or more co-pilots (co-pilot name) A flight (flt#) can go to multiple destinations (dest. name) A flight (flt#) uses one or more altitudes (alt) A flight (flt#) has one or more attendants (attdt_name) A flight (flt#) has many crew members (cr_name) A flight (flt#) lands at one or more airports (a_code) When data is not given, make case by case assumptions and perform FD test. (Assumptions already given here): Note: FDs are split into pairs here for explanatory purposes 28

29. 29 FD WHEN DATA IS NOT GIVEN.. l Cust places multiple orders l A flight has multiple pilots, but a single captain. l Each pet has a single owner l Each actor has an agent and one current project he/she is working on l relationship between ss# and user name for an online store? l User name, ss#, web site, company name, cust. credit card# When data is not given, make case by case assumptions and perform FD test. (Assumptions already given here):

30. Examples of FDs: SS# ---> Name, age, sex etc. Distance,Class --> Airfare. ISBN# --> Book title, price etc. DETERMINANTS & CANDIDATE KEYS The LHS of the FD is called a determinant, and is a candidate key. A candidate key is a key that can be used a pkey (usually LHS) Suppose a  b c -> b 30 What are the determinants? candidate keys? design?

31. THE FD APPROACH Suppose we have A --> B, C, D What will normalization yield? What is the foreign key here? 31

32. FUNCTIONAL DEPENDENCY RULES 1. Reflexive rule x -- > x e.g. ISBN# --> ISBN# 2. Union rule If x -> y and x --> z then x--> yz e.g. ISBN# --> title and ISBN# --> price then ISBN# --> title, price 32 3. Transitivity rule If x--> y and y --> z then x--> z e.g. if VIN --> Model and Model --> Engine size then VIN --> Engine size;

33. FUNCTIONAL DEPENDENCY RULES.. 4. Substitution rule If x -> y and yz --> w then xz --> w e.g. if model --> processor and processor, buswidth --> speed then model, buswidth --> speed 33 equip#, p#  equip#, p# What rule is this? p#  descr P#  price => p#  descr, price What rule is this?

34. 34 If part#  descr serial#  part# Then serial#  descr What rule is this? FUNCTIONAL DEPENDENCY RULES.. a -> b and b  c then a  c What rule is this? a -> b and a  c then a  ??? What rule is this?

35. FUNCTIONAL DEPENDENCY RULES.. Suppose the following FDs hold, a e  b, c, d f  a Then what is the primary key of the table b, c, d, e, f? 35

36. FUNCTIONAL DEPENDENCY DIAGRAMS DRAWING FD DIAGRAMS List all attributes (horizontally) placing candidate key leftmost Take each attribute (after candidate key) and find out its determinant if data is given, do the FD test with the data. if no data is given, make assumptions on a case by case basis. For each value of an attr, how many of the other attr. are there? If FD exists, draw single arrow if no FD do not draw the relationship if there are multiple values for each a, then draw a double arrow 36 The first step in design using FD approach is to draw an FD diagram:

37. NORMALIZATION PROCESS Identify and diagram the functional dependencies Group functional dependencies according to their determinants Place each set of FDs (along with determinants) in a separate table. Use determinants as the pkeys. Add appropriate foreign keys based on the application. THE FUNCTIONAL DEPENDENCY APPROACH 37

38. 38 F.D. diagram: bid  location, mgr_nm, # of emp., mgr_join_dt. AN EXAMPLE OF FD APPROACH Draw FD between a bank id (bid), location, manager (mgr_nm), # of employees and Manager join date (mgr_join_dt) Group FDs according to common determinants: bid  location, mgr_nm, # of emp. mgr_nm  mgr_join_dt Develop design using notation below: Bank(bid, location, mgr_nm, #of emp) Manager(mgr_nm, mgr_join_dt) Check for cross reference keys

39. FOR DISCUSSION ord#: Unique identifier for order (an order can be for many parts) ord dt: date of order p#: unique number for parts qty: # of a certain part that is ordered c# : container for finished parts (one container per part) #fin: # of finished parts die#: Die used to manufacture parts (one die per part) shelf#: the shelf where the die is located 39 Draw an FD diagram and develop a design for the following situation: Strauble-Dytisa

40. REVIEW OF CONCEPTS Basic ConceptsDescription Ill structured table that is poorly designed; or has redundancies or more than one value at row- column intersection Well structured Table that is well designed; has no redundancies and atomic values at row- column intersection Anomaly An inconsistency during a database activity insert, delete or update Insertion anomaly An insertion anomaly occurs if when trying to add a record, it cannot be added without additional information or it may need to be added in multiple places instead of in one location. Deletion anomaly A deletion anomaly occurs, if when we try to delete a record, we have to perform the deletion a number of times, or if we lose information we did not intend to lose. Update anomaly An update anomaly occurs when making an update to a table, we have to update the same data in multiple places. Primary key An attribute whose value is unique within an entity class (table) e.g. SS#, Part# etc.

41. 41 REVIEW OF CONCEPTS Basic ConceptsDescription Functional dependency A relationship between two or more attributes such that if we know a, we can uniquely determine b Fd test For each value of a there is one and only one b Full FD All attributes are fully functionally dependent on pkey Determinant LHS of a Functional Dependency (taken as candidate key) Candidate key A key that can serve as the primary key Foreign key/ Cross-reference key A key that serves as reference between two tables

42. 42