1. Database Management Systems & Programming Faculty of Information & Media Studies Summer 2000 LIS 558 - Week 4 Entity Relationship Modeling II

2. Class Outline n Entity-Relationship Modeling Continued n E-R Modeling Exercises n E-R Model Transformation n BREAK n E-R Model Transformation Exercises n Common database data types n Guidelines for designing tables n Common database design flaws

3. Weak Entities n An entity that is existence dependent on another entity (mandatory participation) and n Has a primary key that is partially or totally derived from the parent entity of the relationship n In ERD depict weak entity using double lines EMPLOYEE EmployeeID,... EmployeeIDDependentID,... EmployeeID, DependentID,... COURSE SECTION CourseID,... CourseIDSectionID,... CourseID, SectionID,... contains has a DEPENDENT

4. Illustration of the Weak Relationship Between DEPENDENT and EMPLOYEE

5. IS-A Supertypes-Subtypes n A subtype entity is an entity that contains a set of optional attributes of the supertype entity and inherits its attributes and its relationships from the supertype entity n If the supertype entity is related to mutually exclusive subtype entities (can belong to only one subtype), indicate with 1; if subtypes are overlapping (can belong to more than one), use m subtype supertype CLIENT INDIVIDUALCORPORATE The same identifier (e.g., ClientID) is used for the supertype as well as subtype. CONTRACT PRODUCTSSERVICES 1m

6. Steps to E-R Modeling 1. Identify entities 2. Identify relationships 3. Determine relationship type 4. Determine level of participation 5. Assign an identifier for each entity 6. Draw completed E-R diagram 7. Deduce a set of preliminary skeleton tables along with a proposed primary key for each table (using cases provided) 8. Develop a list of all attributes of interest (not already listed and systematically assign each to a table in such a way to achieve a 3NF design (i.e., no repeating groups, no partial dependencies, and no transitive dependencies)

7. Entities for the Tiny College Database n SCHOOL n DEPARMENT n EMPLOYEE n PROFESSOR n COURSE n CLASS n ENROLL (Bridge between STUDENT and CLASS) n STUDENT Developing an E-R Diagram

8. n Tiny College Database Each school is composed of several departments.Each school is composed of several departments. The smallest number of departments operated by a school is one, and the largest number of departments is indeterminate (N).The smallest number of departments operated by a school is one, and the largest number of departments is indeterminate (N). Each department belongs to only a single school.Each department belongs to only a single school.

9. n Tiny College Database Each department offers several courses.Each department offers several courses. Developing an E-R Diagram

10. n Tiny College Database A department may offer several sections (classes) of the same course.A department may offer several sections (classes) of the same course. A 1:M relationship exists between COURSE and CLASS.A 1:M relationship exists between COURSE and CLASS. CLASS is optional to COURSECLASS is optional to COURSE Developing an E-R Diagram

11. n Tiny College Database Each department has many professors assigned to it.Each department has many professors assigned to it. One of those professors chairs the department. Only one of the professors can chair the department.One of those professors chairs the department. Only one of the professors can chair the department. DEPARTMENT is optional to PROFESSOR in the “chairs” relationship.DEPARTMENT is optional to PROFESSOR in the “chairs” relationship. Developing an E-R Diagram

12. n Tiny College Database Each professor may teach up to four classes, each one a section of a course.Each professor may teach up to four classes, each one a section of a course. A professor may also be on a research contract and teach no classes.A professor may also be on a research contract and teach no classes. Developing an E-R Diagram

13. n Tiny College Database A student may enroll in several classes, but (s)he takes each class only once during any given enrollment period.A student may enroll in several classes, but (s)he takes each class only once during any given enrollment period. Each student may enroll in up to six classes and each class may have up to 35 students in it.Each student may enroll in up to six classes and each class may have up to 35 students in it. STUDENT is optional to CLASS.STUDENT is optional to CLASS. Developing an E-R Diagram

14. n Tiny College Database Each department has several students whose major is offered by that department.Each department has several students whose major is offered by that department. Each student has only a single major and associated with a single department.Each student has only a single major and associated with a single department. Developing an E-R Diagram

15. n Tiny College Database Each student has an advisor in his or her department; each advisor counsels several students.Each student has an advisor in his or her department; each advisor counsels several students. An advisor is also a professor, but not all professors advise students.An advisor is also a professor, but not all professors advise students. Developing an E-R Diagram

16. Components of the E-R Model

18. Exercise Problem Rob 2.1-7

19. Exercise Problem - Rob 2.1-7  An EMPLOYEE has only one JOB_CODE, but a JOB_CODE can be held by many EMPLOYEEs.  An EMPLOYEE can have many BENEFITs, and any BENEFIT can be assigned to many EMPLOYEEs.

20. Exercise Problem - Rob 2.1-7

21. E-R Modeling I Exercises (distributed last week) Complete solutions on course website

22. 1. Use the following business rules to write all appropriate connectivities and cardinalities in an E-R diagram:  A department employs many employees, but each employee is employed by one department, although some employees, known as "rovers", are not assigned to any department;  A division operates many departments, but each department is operated by one division;  An employee may be assigned to many projects and a project may have many employees assigned to it;  A project must have at least one employee assigned to it;  One of the employees manages each department;  One of the employees runs each division. E-R Modeling I - #1

23. Solution to Q1

24. 2. The Hudson Engineering Group (HEG) has contacted you to create a conceptual model whose application will meet the expected database requirements for its training program. The HEG administrator gives you the following description of the training group's operating environment: The HEG has twelve instructors and can handle up to thirty trainees per class. HEG offers five "advanced technology" courses, each of which may generate several classes. If a class has fewer than ten trainees in it, it will be canceled. It is, therefore, possible for a course not to generate any classes during a session. Each class is taught by one instructor. Each instructor may teach up to two classes or may be assigned to do research. Each trainee may take up to two classes per session. Given this information, do the following: - Describe the relationships between the entities in terms of connectivity, cardinality, and existence dependence. - Draw the E-R diagram for HEG. E-R Modeling I - #2

25. Solution to Q2

26. E-R Modeling II Exercises (distributed last week) Complete solutions on course website

27. 1. Given the following business rules, create the E-R diagram, incorporating each of the specified relationships: - A company operates four departments; - Each department in part (a) employs employees; - Each of the employees in part b may or may not have one or more dependents; - Each employee in part (c) may or may not have an employment history. Modeling II E-R Modeling II - #1

28. Solution to Q1

29. 4. A large hospital has just hired you to design a technical help desk database application. The hospital has just standardized their complement of network PCs by acquiring 500 Pentium III 400 MHz workstations. Each workstation has an appropriate range of applications software already loaded. The purpose of the helpdesk database is to track the problems that arise (hardware and software), the users who report them, and the person assigned to resolve the problem. The development of this helpdesk and the associated database was proposed to reduce response time, reduce paperwork, centralize problem resolution, and ensure appropriate follow-up. Provide a conceptual design for this database application by creating an entity-relationship diagram. Modeling II E-R Modeling II - #4

30. Solution to Q4 USER HARDWARE PROBLEM RESOLVER SOFTWARE assigned to reports is a 1 M M 1 1 UserID,... ProbID,… ResolverID,... ProbID... ProbID,... (0,N) (1,1) (0,N) (0,1)

31. 5. Design a database that tracks employee’s skills. Additionally, track various projects and the skills that are required to perform each project. Finally, the project must be appropriately assigned. Include also the employee’s supervisor, dependents, work history and employee benefits. Modeling II E-R Modeling II - #5

32. Solution to Q5 employee acquiresassigned project skill requires supervises M N M N M 1 M N parent of * has * given benefits 1 M 1 M M N dependents work history

33. Steps to E-R ModelTransformation 1. Identify entities 2. Identify relationships 3. Determine relationship type 4. Determine level of participation 5. Assign an identifier for each entity 6. Draw completed E-R diagram 7. Deduce a set of preliminary skeleton tables along with a proposed primary key for each table (using cases provided) 8. Develop a list of all attributes of interest (not already listed and systematically assign each to a table in such a way to achieve a 3NF design (i.e., no repeating groups, no partial dependencies, and no transitive dependencies)

34. n Converting an E-R Model into a Database Structure A painter might paint many paintings. The cardinality is (1,N) in the relationship between PAINTER and PAINTING.A painter might paint many paintings. The cardinality is (1,N) in the relationship between PAINTER and PAINTING. Each painting is painted by one (and only one) painter.Each painting is painted by one (and only one) painter. A painting might (or might not) be exhibited in a gallery; i.e., the GALLERY is optional to PAINTING.A painting might (or might not) be exhibited in a gallery; i.e., the GALLERY is optional to PAINTING. Developing an E-R Diagram

36. n Summary of Table Structures and Special Requirements for the ARTIST database PAINTER(PRT_NUM, PRT_LASTNAME, PRT_FIRSTNAME, PRT_INITIAL, PTR_AREACODE, PRT_PHONE) GALLERY(GAL_NUM, GAL_OWNER, GAL_AREACODE, GAL_PHONE, GAL_RATE) PAINTING(PNTG_NUM, PNTG_TITLE, PNTG_PRICE, PTR_NUM, GAL_NUM) Developing an E-R Diagram

37. A Data Dictionary for the ARTIST Database

38. n General Rules Governing Relationships among Tables 1. All primary keys must be defined as NOT NULL. 2.Define all foreign keys to conform to the following requirements for binary relationships. –1:M Relationship –Weak Entity –M:N Relationship –1:1 Relationship Developing an E-R Diagram

39. n 1:M Relationships Create the foreign key by putting the primary key of the “one” (parent) in the table of the “many” (dependent).Create the foreign key by putting the primary key of the “one” (parent) in the table of the “many” (dependent). Foreign Key Rules:Foreign Key Rules: Developing an E-R Diagram

40. n Weak Entity Put the key of the parent table (strong entity) in the weak entity.Put the key of the parent table (strong entity) in the weak entity. The weak entity relationship conforms to the same rules as the 1:M relationship, except foreign key restrictions:The weak entity relationship conforms to the same rules as the 1:M relationship, except foreign key restrictions: NOT NULL ON DELETE CASCADE ON UPDATE CASCADE n M:N Relationship Convert the M:N relationship to a composite (bridge) entity consisting of (at least) the parent tables’ primary keys.Convert the M:N relationship to a composite (bridge) entity consisting of (at least) the parent tables’ primary keys. Developing an E-R Diagram

41. n 1:1 Relationships If both entities are in mandatory participation in the relationship and they do not participate in other relationships, it is most likely that the two entities should be part of the same entity.If both entities are in mandatory participation in the relationship and they do not participate in other relationships, it is most likely that the two entities should be part of the same entity. Developing an E-R Diagram

42. n Case 1: M:N, Both Sides MANDATORY Developing an E-R Diagram

43. n Case 2: M:N, Both Sides OPTIONAL Developing an E-R Diagram

44. n Case 3: M:N, One Side OPTIONAL Developing an E-R Diagram

45. n Cases 1-3: M:N Developing an E-R Diagram PATIENT (PATIENT_ID, PATIENT_LNAME, PATIENT_PHYSICIAN,...) DRUG (DRUG_ID, DRUG_NAME, DRUG_MANUFACTURER,...) PRESCRIBE(PATIENT_ID, DRUG_ID, DOSAGE, DATE…) PATIENTDRUG prescribedMN NOTE: The relationship may have its own attributes.

46. Example of decomposing entities with a binary M:N relationship Students:Classes have an M:N relationship, therefore, decompose to three tables. bridge table

47. n Case 4: 1:M, Both Sides MANDATORY Developing an E-R Diagram EMPLOYEE (EMP_ID, EMP_DEPT, …) PRODUCT (PROD_ID, PROD_NAME, PROD_%FIBRE, EMP_ID... ) EMPLOYEEPRODUCT checks 1M

48. n Case 5: 1:M, Both Sides OPTIONAL Developing an E-R Diagram PHYSIOTHERAPIST (PT_ID, PT_LNAME,...) CLIENT (CLIENT_ID, CLIENT_LNAME, CLIENT_OHIP#, …PT_ID) PHYSIOTHERAPISTCLIENTS has 1 M

49. n Case 6: 1:M, Many Side OPTIONAL, One Side MANDATORY Developing an E-R Diagram MACHINE (MACH_ID, MACH_NAME, MACH_DEPT,...) PART (PART_ID, PART_NAME, PART_CATEGORY, …, MACH_ID) MACHINEPARTS contains 1M

50. n Case 7: 1:M, One Side OPTIONAL, One Side MANDATORY Developing an E-R Diagram BAND (BAND_ID, BAND_NAME, MUSIC_TYPE...) MUSICIAN (MUSICIAN_ID, MUSICIAN_INSTRUMENT, … BAND_ID) BANDMUSICIAN accepts 1M

51. n Case 8: 1:1, Both Sides MANDATORY Developing an E-R Diagram

52. n Case 8: 1:1, Both Sides MANDATORY Developing an E-R Diagram EMPLOYEEJOB-DESCRIPTION has a 11 EMPLOYEE (EMP_NUM, EMP_LNAME,…, JOB_DESC) PLUMBERBUILDING assigned 11 PLUMBER (PLUMBER_ID, PLUMBER_LNAME,…BUILDING_ID) BUILDING (BUILDING_ID, BUILDING_ADDRESS,...)

53. n Case 9: 1:1, Both Sides OPTIONAL Developing an E-R Diagram EXERCISER EXERCISER (EXERCISER_ID, EXERCISER_LNAME, …TRAINER_ID) TRAINER (TRAINER_ID, TRAINER_LNAME,...) TRAINER has 11

54. n Case 10: 1:1, One Side OPTIONAL, One Side MANDATORY Developing an E-R Diagram EMPLOYEE (EMP_ID, EMP_LNAME, EMP_PHONE,…) AUTO (LIC_NUM, SERIAL_NUM, MAKE, MODEL,, …, EMP_ID) EMPLOYEEAUTO has 11

55. n Case 11: Weak Entity (Foreign key located in weak entity) Developing an E-R Diagram

56. Case 11. Decomposing Weak Entities n When the relationship type of a binary relationship is 1:M between an entity and its weak entity, two tables are required: one for each entity, with the entity key from each entity serving as the primary key for the corresponding table. n Additionally, the entity that has a dependency on the existence of another entity has a primary key that is partially or totally derived from the parent entity of the relationship. n Weak entities must be deleted when the strong entity is deleted. HOSPITAL (HOSP_ID, HOSP_NAME, HOSP_ADDRESS,...) UNIT (HOSP_ID, UNIT_NAME, HEAD_NURSE,...) HOSPITAL 1M contains UNIT

57. n Case 12: Multivalued Attributes Developing an E-R Diagram

58. Entity CLIENT contains ClientNumberClientNameAddressAmountDueSocialInsuranceNumberTaxIdentificationNumberContactPersonPhone Problem: Too many NULL values Solution: Separate into CLIENT entity plus several subtypes Decomposing an IS-A Relationship CLIENT INDIVIDUAL CLIENT CORPORATE CLIENT 1

59. n Create a table for the parent entity and for each of the child entities or subtypes n Move the associated attributes from the parent entity into the child table to which they correspond n From the parent entity take the entity key and add it as the primary key to the corresponding table for each child entity n In the event a table corresponding to a child entity already has a primary key then simply add the entity key from the parent entity as an attribute of the table corresponding to the child entity CLIENT (CLIENT_ID, AMOUNT_DUE, …) INDIVIDUAL_CLIENT (CLIENT_ID, SIN#, …) CORPORATE_CLIENT(CLIENT_ID, GST#, …) CLIENT INDIVIDUAL CLIENT CORPORATE CLIENT 1

60. Transforming Recursive Relationships 1:1 - create a foreign key field (duplicate values not allowed) that contains the domain of primary key 1:M - create a foreign key field (duplicate values allowed) that contains the domain of primary key

61. Transforming M:N Recursive Relationships M:N - create a second relation that contains two foreign keys: one for each side of the relationship

62. Decomposing Ternary relationships n When a relationship is three-way (ternary) four preliminary tables are required: one for each entity, with the entity key from each entity serving as the primary key for the corresponding table, and one for the relationship. n The table corresponding to the relationship will have among its attributes the entity keys from each entity n Similarly, when a relationship is N-way, N+1 preliminary tables are required.

63. Library Database Example PUBLISHER AUTHORBOOK writes publishes M 1 NM PUBLISHER (Pub_ID, ___, ___, ___, ___, …) BOOK (ISBN, Pub_ID, ___, ___, ___, ___, …) AUTHOR (Author_ID, ___, ___, ___, ___, …) WRITES(ISBN, Author_ID, ___, ___, ___, ___, …) Case 6 Case 2

64. University Example STUDENT (StudID, ___, ___, FacID, …) COURSE (CourseID, ___, ___, ___, …) FACULTY (FacID, ___, ___, ___, ___, …) Case 2 TEACH (FacID, CourseID,…) ENROLL (StudID, CourseID, ___,...) Case 2 Case 6 MN FACULTY COURSE advise s 1 MM N taught by STUDENT takes

65. E-R Modeling & Transformation Exercise

66. Create an E-R model and define its table structures for the following requirements. - An INVOICE is written by a SALESREP. Each sales representative can write many invoices, but each invoice is written by a single sales representative. - The INVOICE is written for a single CUSTOMER. However, each customer may have many invoices. - An INVOICE may include many detail lines (LINE) which describe the products bought by the customer. - The product information is stored in a PRODUCT entity. - The product's vendor information is found in a VENDOR entity. E-R Modeling & Transformation Exercise

68. Keep in mind that the preceding E-R diagram reflects a set of business rules that may easily be modified For example, if customers are supplied via a commercial customer list, many of the customers on that list will not (yet!) have bought anything, so INVOICE would be optional to CUSTOMER We are assuming here that a product can be supplied by many vendors and that each vendor can supply many products. The PRODUCT may be optional to VENDOR if the vendor list includes potential vendors from which you have not (yet) ordered anything. Some products may never sell, so LINE is optional to PRODUCT... because an unsold product will never appear in an invoice line. LINE may be shown as weak to INVOICE, because it borrows the invoice number as part of its primary key and it is existence- dependent on INVOICE The design depends on the exact nature of the business rules. E-R Modeling & Transformation Exercise

70. CUSTOMER (CustomerID, …) INVOICE (InvoiceID, CustomerID, SalesRepID,…) LINE (InvoiceID, LineID, ProdID,…) PRODUCT (ProductID, …) SALESREP (SalesRepID, …) VENDOR (VendorID,…) SHIP (ShipID, ProductID, VendorID,…)

71. Further E-R Transformation Exercises

72. ER Modeling I handout - Q1 DIVISION (DivisionID,…ManagerID) DEPARTMENT (DeptID,…DivisionID) EMPLOYEE (EmpID, …DeptID) PROJECT (ProjectID,…) EMPLOYEE_PROJECT (EmpID, ProjectID,…) not null null allowed

73. ER Modeling I - Q2 INSTRUCTOR (InstructorID, HighestDegree, …) COURSE (CourseID, ClassTitle, …) CLASS (ClassID, CourseID, InstructorID, Term…) TRAINEE (TraineeID, …) ENROLL (TraineeID, ClassID, Term…)* All foreign keys not null. * Optionally, create an EnrollmentID attribute to use as primary key.

74. ER Modeling I - Q3 CUSTOMER (CustomerID, …) INVOICE (InvoiceID, CustomerID, SalesRepID,…) LINE (InvoiceID, LineID, ProdID,…) PRODUCT (ProductID, …) SALESREP (SalesRepID, …) VENDOR (VendorID,…) SHIP (ShipID, ProductID, VendorID,…) All foreign keys not null

75. ER Modeling I - Q4 AGENT (AgentID, LName, Region…) CLIENT (ClientID, LName,…) MUSICIAN (MusicianID, AgentID, Name, DaysAvailable,…) EVENT (EventID, ClientID, MusicianID, Date, Time, Location…) INSTRUMENT (InsturmentID, …) MUSICIAN_INSTRUMENT (MusicianID, InstrumentID, YearsExperience…) All foreign keys not null.

76. ER Modeling I - Q5 CITY (CityID, …) TEAM (TeamID, CoachID, CityID, …) PLAYER (PlayerID, TeamID,…) COACH (CoachID, TeamID,…) GAME (GameID, HomeTeamID, VisitorTeamID,…) All foreign keys not null.

77. ER Modeling II - Q1 COMPANY (CompanyID, …) DEPARTMENT (DepartmentID, CompanyID…) EMPLOYEE (EmployeeID, DepartmentID, …) DEPENDENT (EmployeeID, DependentID, …) EMPLOYEE_HISTORY (EmployeeID, HistoryID, …) All foreign keys are not null

78. ER Modeling II - Q2 MEMBER (MemberID, …) WORKOUT (WorkoutID, MemberID, Date…) EXERCISE (ExerciseID…) WORKOUT_EXERCISE (WorkoutID, ExerciseID, NumberSets, NumberReps,…)

79. ER Modeling II - Q3 EMPLOYEE (EmployeeID, Name…PositionID) PART_TIME_EMPLOYEE (EmployeeID, HourlyRate…) FULL_TIME_EMPLOYEE (EmployeeID, Salary, OfficeRoom, …) POSITION (PositionID, Title, Job_Description…) All foreign keys not null.

80. ER Modeling II - Q4 USER (UserID, Name, Department,…) PROBLEM (ProblemID, TimeSpent, UserID, ResolverID,…) HARDWARE (ProblemID, Description, Solution…) SOFTWARE (ProblemID, SoftwareVersion, …) RESOLVER (ResolverID, Name, Phone, Level, …) All foreign keys not null.

81. ER Modeling II - Q5 EMPLOYEES (EmployeeID, SupervisorID, …) SKILLS (SkillID, SkillName, …) EMPLOYEE_SKILL (EmployeeID, SkillID, DateAcquired, Certification,…) PROJECTS (ProjectID, ProjectName, ManagerID, StartDate…) EMPLOYEE_PROJECT (EmployeeID, ProjectID, Role…) PROJECT_SKILL (ProjectID, SkillID, SkillLevelRequired, NumberStaff,…)* DEPENDENTS (EmployeeID, DependentID, DateOfBirth…) WORK_HISTORY(EmployeeID, HistoryID,…) BENEFITS (BenefitID, BenefitType, Company, Contact,…) EMPLOYEE_BENEFIT (EmployeeID, BenefitID,…) All foreign keys are not null. * Optionally, create a ProjectSkill_ID attribute to use as primary key.

82. ER Modeling II - Q6 ORCHARD (OrchardID, Location, …) SPECIES (SpeciesID, Name, OrchardID…) DISEASE (DiseaseID, Symptoms, Treatment,…) SPECIES_DISEASE (SpeciesDiseaseID, SpeciesID, DiseaseID, Date,…)* CUSTOMER (CustomerID, …) ORDER (OrderID, CustomerID, …) ORDERDETAILS (OrderID, DetailID, SpeciesID,…) All foreign keys not null. * Optionally, use the combination of SpeciesID, DiseaseID and Date as primary key and remove SpeciesDiseaseID entirely.

83. Characteristics of Fields n Each field within a table must have a unique name (avoid spaces and special characters). n Data within a field must be of the same data type. The following are common data types: character (text or string)character (text or string) memo (large character field)memo (large character field) integer (whole numbers for calculations)integer (whole numbers for calculations) number (values with decimals for calculations)number (values with decimals for calculations) currency (formatted number)currency (formatted number) logical or Boolean (true/false; 0,-1; yes/no)logical or Boolean (true/false; 0,-1; yes/no) date/ time (use computer’s internal calendar/clock)date/ time (use computer’s internal calendar/clock) graphic (picture)graphic (picture)

84. Guidelines for Ideal Table Design n Each table should represents a single theme or subject or entity or transaction n Tables should include primary keys that uniquely identify each record of each table n Avoid the use of smart keys that attempt to embed meaning into primary keys (keys should be meaningless) n A primary key should be a unique, random or sequential collection of alphabetic, numeric or alphanumeric characters n The domain of primary keys should be large enough to accommodate the identification of unique rows for the entire potential universe of records n Use the suffix ID in constructing primary keys to ensure they are readily identifiable n Tables should not contain any of the following: multipart fields, multivalued fields, calculated or derived fields or unnecessary duplicate fields n There should be a minimum amount of redundant data

85. Common Errors in Database Design n Flat file database n Too much data n Compound fields n Missing keys n Bad keys n Missing relationships n Unnecessary relationships n Incorrect relationships n Duplicate field names n Cryptic field or table names n Referential integrity n Database Security n Missing or incorrect business rules n Missing or incorrect constraints John Paul Ashenfelter, “Common Database Mistakes”, May 26, 1999, (Oct 10, 1999).

86. The Well-Structured Database n E-R modeling is top-down method of designing n Transforming an E-R model does not guarantee the best design (e.g., E-R model could be way off) n Best to transform E-R model and then check the design according to the Cases of normalization n Normalization is bottom-up method of designing a database n Use both approaches to develop a well- structured database

87. The Challenge of Database Design: Conflicting Goals n Conflicting Goals Design standards (design elegance)Design standards (design elegance) Processing speedProcessing speed Information requirementsInformation requirements n Design Considerations Logical requirements and design conventionsLogical requirements and design conventions End user requirements; e.g., performance, security, shared access, data integrityEnd user requirements; e.g., performance, security, shared access, data integrity Processing requirementsProcessing requirements Operational requirementsOperational requirements DocumentationDocumentation