Database Design
Database Design Process Requirements analysis What data, what applica;ons, what most frequent opera;ons, Conceptual database design High level descrip;on of the data and the constraint This step can use ER or similar high level models Logical database design Convert database design into a database schema, e.g. rela;onal db schema
Database Design Process (cont.) Schema refinement Analyze the the collec;on of the data for poten;al problems and refine it Physical database design Ensure that the design meets the performance requirements, based on used indexa;on, etc. Security design Iden;fy different user groups with different roles, so that data protec;on is enforced accordingly.
ER Model Basics: ssn name lot En;ty set Employees En#ty: Real- world object dis;nguishable from other objects. An en;ty is described (in DB) using a set of a)ributes. En#ty Set: A collec;on of similar en;;es. E.g., all employees. All en;;es in an en;ty set have the same set of asributes. Each en;ty set has a key that uniquely iden#fies it. Each asribute has a domain. En;ty set can be mapped to a rela;on easily.
ER Model Basics: name Rela;onship set ssn lot ssn name Employees lot since Works_In did dname budget Departments super -visor Employees subor -dinate Reports_To Rela#onship: Associa;on among 2 or more en;;es. E.g., Steve Jobs works in Grocery department. Rela#onship Set: Collec;on of similar rela;onships. Same en;ty set could par;cipate in different rela;onship sets, or in different roles in the same set.
ER Model Basics: rela;onship Set (Contd.) Rela;onship sets can also have descrip#ve a)ributes (e.g., the since asribute of Works_In). For a given en;ty pair we cannot have more than one associated descrip;ve asribute value. E.g.,., an employee- department pair can have one since asribute value. A rela;onship must be uniquely iden;fied by the en;;es taking part. Thus, in transla;ng a rela;onship set to a rela;on, asributes of the rela;on must include: Keys for each par;cipa;ng en;ty set (as foreign keys). This set of asributes (individual keys) forms superkey for the new rela;on. All descrip;ve asributes of the rela;onship.
ER Model Basics: rela;onship Set (Contd.) An instance of a rela;onship set is a set of rela;onships An example instance may have an employee working in none, one or many departments. A rela;onship may have three en;;es involved, in which case, it is called ternary. E.e., Works_In can have a Loca;ons en;ty with possible asributes. taking part as well, where a department may have offices in different cites.
Addi;onal features One would need addi;onal features for the ER diagrams to represent some important proper;es of en;;es and their rela;onships with other en;;es. More readable and precise an ER diagram beser it is! Important features that can be shown on the ER diagrams: Key constraints Par;cipa;on constraint Weak en;ty Class hierarchy concept Aggrega;on concept
Key Constraints Consider Works_In rela;onship : An employee can work in many departments; a dept can have many employees, known as many- to- many. Consider a Manages rela;onship between en;;es Employee and Departments. In contrast, each dept has at most one manager and each employee can manage more than one department, according to the key constraint on Manages. This is one- to- many mapping The Key constraint is represented by an arrow as in the related diagram.
Key Constraints Departments have single manager, employee can manage more than one department! name since dname ssn lot did budget Employees Manages Departments
Types of rela;onship sets 1-to-1 (one-to-one) 1-to Many (one-to-many) Many-to-1 Many-to-Many (Many-to-one)
Par;cipa;on Constraints:Total vs. Par;al If every department has a manager then, this is a par#cipa#on constraint constraint: the par;cipa;on of Departments in Manages is said to be total (vs. par#al). For total par;cipa;on implementa;on in rela;ons, every did value in the corresponding Departments table must appear in a row of the Manages table, with a non- null ssn value, reflec;ng the situa;on that every department has a manager.
Par;cipa;on constraints (cont.) Diagramma;c representa;on of key constraint and total par;cipa;on ssn name lot since did dname budget Employees Manages Departments
Par;cipa;on Constraints (cont.) Assume the case where each employee works in at least one department and that each department has at least one employee. The example ER diagram shows Manages and Works_In in the same diagram, with correct proper;es. ssn name lot since did dname budget Employees Manages Departments Works_In since
Par;cipa;on Constraints (cont.) Ensure total par;cipa;on in the corresponding rela;onship tables is a problem! We have to guarantee that every did value in Departments appears in a tuple of Works_In at least once or possibly more
The (min,max) notation (0,1) (1,1) (1,1) (1,N) Chapter 3-16
Weak En;;es Some en;;es do not have to have a key. It is possible that some en;;es are dependent on other en;;es. That is their existence depends on the others This dependent en;ty is known as weak en#ty. A weak en#ty can be iden;fied uniquely only by considering the primary key of another (owner) en;ty. Owner en;ty set and weak en;ty set must par;cipate in a one- to- many rela;onship set: one owner many weak en;;es Weak en;ty set must have total par;cipa;on in this iden#fying rela;onship set. A weak en;ty always has a par;al key, it can only be uniquely defined if we take its key together with the key of the owner en;ty.
Weak En;;es (cont.) Assume an example of Employee and Dependents en;;es with a Policy rela;onship between tham. Employee is owner en;ty, Dependent is weak en;ty, Policy is the iden:fying rela;onship set: name ssn lot cost pname age Employees Policy Dependents
ISA (`is a ) Hierarchies Some time it is more appropriate to represent entities in an entity set into subclasses, where attributes can be inherited down the hierarchy. As in object oriented programming tools, attributes are inherited. If we declare A ISA B, every A entity is also considered to be a B entity. As an example, consider a Employee entity as a super-class which has two subclasses as hourly and contract entities. In this case, the attributes of Employee should be inherited by the hourly and contract employee entities.
ISA (`is a ) Hierarchies- 2 ssn name lot Employees Subclasses are defined first! hourly_wages hours_worked ISA contractid Hourly_Emps Contract_Emps Overlap constraints: Can Zeynep be an Hourly_Emps as well as a Contract_Emps en;ty? (posibility this is not to be allowed to be overlapped. However if had a sub- class such as Senior employee en##y, that can be have OVERLAP with the sub- class Contract and or Hourly en##es. ) Covering constraints: Does every Employees en;ty also have to be an Hourly_Emps or a Contract_Emps en;ty? (allowed using COVER). In some cases this may be required, in some other cases may not. These two issues need to be represented by the programming tool used to implement such proper;es.
ISA (`is a ) Hierarchies- 3 Reasons for using ISA: To add descrip;ve asributes specific to a subclass. To iden;fy the set of en;;es that par;cipate in a par;cular rela;onship, e.g. only Senior Employees can be allowed to be Managers of Departments.
Transla;ng ISA Hierarchies to Rela;ons General approach: 3 rela;ons: Employees, Hourly_Emps and Contract_Emps. Hourly_Emps: Every employee is recorded in Employees. For hourly emps, extra info recorded in Hourly_Emps (hourly_wages, hours_worked, ssn); must delete Hourly_Emps tuple if referenced Employees tuple is deleted). Queries involving all employees are easy, those involving just Hourly_Emps require a join to get some asributes. Overlap and covering constraints can only be expressed using asser:ons in case of SQL.
Aggregation Building a relationship between a collection of entities and relationships Aggregation allows us to indicate a relationship set participate in another relationship set
Aggregation-1 Suppose: entity set Projects each Projects is sponsored by at least one Departments each Departments that sponsors a Projects might assign employees to monitor sponsorship pid ssn started_on pbudget name Employees since lot did dname budget Intuitively Projects Sponsors Departments Monitors should be a relationship set that associates a Sponsors relation (versus a Projects or Departments) with an Employees entity.
ssn name lot Aggregation-2 Employees Used when we have to model a relationship involving (entity sets and) a relationship set. Monitors until Aggregation allows us to treat a relationship set as an entity set for purposes of participation in (other) relationships. pid started_on since pbudget did Projects Sponsors dname budget Departments
Aggregation vs. Ternary relation ssn name Employees lot Each relationship in an aggregation may have a different descriptive attribute like since and until. Suppose: No need to record until attribute of Monitors Then one can use ternary relationship Sponsors2 pid started_on Projects pbudget since did Sponsors2 But suppose we have constraint that: Each sponsorship (of a project by a department) be monitored by at most one employee? dname Departments Then one can t do it with Sponsors2 Need aggregated relationship Sponsors budget
Aggregation vs. Ternary relation (Contd.) ssn name Employees lot Monitors until Monitors is a distinct relationship, with a descriptive attribute (until). Also, can say that each sponsorship is monitored by at most one employee. pid started_on since pbudget did Projects Sponsors dname Departments budget
Conceptual Design Using the ER Model Design choices: Should a concept be modeled as an en;ty or an asribute? Should a concept be modeled as an en;ty or a rela;onship? Iden;fying rela;onships: Binary or ternary? Aggrega;on? Constraints in the ER Model: A lot of data seman;cs can (and should) be captured. But some constraints cannot be captured in ER diagrams. Need for further refinement of the schema: Rela;onal schema obtained from ER diagram is a good first step. But ER design is subjec;ve & can t express certain constraints; so this rela#onal schema may need refinement.
En;ty vs. ASribute Should address be an asribute of Employees or an en;ty (connected to Employees by a rela;onship)? Depending upon the purpose of address informa;on and the seman;cs of the data: If we have several addresses per employee, address must be an en;ty (since asributes cannot be set- valued). If the structure (city, street, etc.) is important, e.g., we want to retrieve employees in a given city, address must be modeled as an en;ty (since asribute values are atomic).
En;ty vs. ASribute (Contd.) According to the conceptual ER model, Works_In2 does not allow an employee to work in a department for two or more periods. ssn name lot from to did dname budget Employees Works_In2 Departments But we want several values of the descriptive attributes for each instance of this relationship.
En;ty vs. ASribute (Contd.) In this case, use Dura;on en;ty to allow more than one dura;on per rela;onship ssn name lot did dname budget Employees Works_In3 Departments from Duration to
En;ty vs. Rela;onship Following ER diagram OK if a manager gets a separate discre;onary budget for each dept. name since dbudget dname ssn lot did budget Employees Manages2 Departments
En;ty vs. Rela;onship What if a manager gets a discre;onary budget which is the sum that covers all depts managed by that employee? Then the previous ER diagram will cause Redundancy of dbudget, where the same value is stored for each dept managed by the same manager. Misleading as it suggests dbudget ;ed to managed dept rather than employee. Instead a separate en;ty Mgr_Appts can be used with apptnum as key. This way the redundancy is eliminated!
En;ty vs. Rela;onship ssn name lot did dname budget Employees Manages3 Departments apptnum Mgr_Appts since dbudget
Binary vs. Ternary Rela;onships If each policy is owned by just 1 employee: Key constraint on Policies would mean policy can only cover 1 dependent! Every policy must be owned by some employee Dependents is a weak en;ty set Thus, this can be represented as follows: This ternary rela;onship is a poor or inappropriate design! ssn name lot pname age Employees Covers Dependents Policies policyid cost
Binary vs. Ternary Rela;onships(cont.) Are statement of the same applica;on with more clarity: A policy cannot be owned by more than one employee, every policy must be owned by some employee (total par;cipa;on) and Every policy must cover at least one dependent, dependent is a weak en;ty set. Use a Beneficiary rela;onship which is an iden;fying rela;onship for the weak en;ty Dependents, ie. where each dependent will have one policy only
Binary vs. Ternary Rela;onships (cont.) ssn name lot Employees pname age Dependents Purchaser Better design Policies Beneficiary With two binary relationships policyid cost
Binary vs. Ternary Rela;onships (Cont.) The key constraints allow us to combine Purchaser with Policies and Beneficiary with Dependents. Par;cipa;on constraints lead to NOT NULL constraints. This example illustrated a case when 2 binary rela;onships were beser than a ternary rela;onship. It is also possible that ternary rela;onship is more suitable than binary, in some cases:
Summary of Conceptual Design Conceptual design follows requirements analysis, Yields a high- level descrip;on of data to be stored ER model popular for conceptual design Constructs are expressive, close to the way people think about their applica;ons. Basic constructs: en##es, rela#onships, and a)ributes (of en;;es and rela;onships). Some addi;onal constructs: weak en##es, ISA hierarchies, and aggrega#on. Note: There are many varia;ons on ER model.
Summary of ER (Contd.) Several kinds of integrity constraints can be expressed in the ER model: key constraints, par#cipa#on constraints, and overlap/covering constraints for ISA hierarchies. Some foreign key constraints are also implicit in the defini;on of a rela;onship set. Some of these constraints can be expressed in SQL. Some constraints (notably, func#onal dependencies) cannot be expressed in the ER model. Constraints play an important role in determining the best database design for an enterprise.
Summary of ER (Contd.) ER design is subjec#ve. There are omen many ways to model a given scenario! Analyzing alterna;ves can be tricky, especially for a large enterprise. Common choices include: En;ty vs. asribute, en;ty vs. rela;onship, binary or n- ary rela;onship, whether or not to use ISA hierarchies, and whether or not to use aggrega;on. Ensuring good database design: resul;ng rela;onal schema should be analyzed and refined further. FD informa;on and normaliza;on techniques are especially useful.
Rela;onship Set The current value of an en;ty set is the set of en;;es that belong to it. Example: the set of all books in our database. The value of a rela;onship is a set of lists of currently related en;;es, one from each of the related en;ty sets.
Some of the Automated Database Design Tools COMPANY TOOL FUNCTIONALITY Embarcadero Technologies ER Studio Database Modeling in ER and IDEF1X Oracle DB Artisan Developer 2000 and Designer 2000 Database administration and space and security management Database modeling, application development Popkin Software System Architect 2001 Data modeling, object modeling, process modeling, structured analysis/design Platinum Technology Platinum Enterprice Modeling Suite: Erwin, BPWin, Paradigm Plus Data, process, and business component modeling Persistence Inc. Pwertier Mapping from O-O to relational model Rational Rational Rose Modeling in UML and application generation in C++ and JAVA Rogue Ware RW Metro Mapping from O-O to relational model Resolution Ltd. Xcase Conceptual modeling up to code maintenance Sybase Enterprise Application Suite Data modeling, business logic modeling Visio Visio Enterprise Data modeling, design and reengineering Visual Basic and Visual C++
Examples A University database contains information about professors (identified by social security number, or SSN) and courses (identified by courseid). Professors teach courses. Each of the following situations concerns the Teaches relationship set. For each situation, draw an ER diagram that describes it (assuming that no further constraints hold).
Examples (cont ) 1. Professors can teach the same course in several semesters, and each offering must be recorded. 2. Professors can teach the same course in several semesters, and only the most recent such offering needs to be recorded. (Assume this condition applies to all subsequent questions.) 3. Every professor must teach some course 4. Every professor teaches exactly one course (no more, no less). 5. Every professor teaches exactly one course (no more no less), and every course must be taught by some professor. 6. Now assume that certain courses can be taught by a team of professors jointly, but it is possible that no one professor in a team can teach the course. Model this situation introducing additional entity sets and relationship sets if necessary.
Example (cont ) 1) Professors can teach the same course in several semesters, and each offering must be recorded.
Example (cont ) 2) Professors can teach the same course in several semesters, and only the most recent such offering needs to be recorded. (Assume this condition applies to all subsequent questions.)
Example (cont ) 3) Every professor must teach some course
Example (cont ) 4) Every professor teaches exactly one course (no more, no less).
Example (cont ) 5) Every professor teaches exactly one course (no more no less), and every course must be taught by some professor.
Example (cont ) 6) Now assume that certain courses can be taught by a team of professors jointly, but no one professor in a team can teach the course alone. Model this situation introducing additional entity sets and relationship sets if necessary.
Example A company database needs to store information about employees (identified by ssn, with salary and phone as attributes); departments (identified by dno, with dname and budget as attributes); and children of employees (with name and age as attributes). Employees work in departments; each department must be managed by an employee; a child must be identified uniquely by name when the parent (who is an employee; assume that only one parent works for the company) is known. We are not interested in information about a child once the parent leaves the company.
ER DIAGRAM FOR A BANK DATABASE The Benjamin/Cummings Publishing Company, Inc. 1994, Elmasri/Navathe, Fundamentals of Database Systems, Second Edition