Conceptual Database Design (ER modeling) Chapter Four

Transcription

1 Conceptual Database Design (ER modeling) Chapter Four

2 Agenda (Chapter four) Overview-database design Conceptual Design (E-R Modeling) Structural Constraints EER- Generalization and Specialization Reducing E-R Model to Table (logical Design) Logical Database Design Process of Normalization

3 Objective Learn skills and methods of Modeling organizational data using Entity relationship diagram Implementing the rules of relational data model through the process of normalization

4 Overview-database design Database design is the process of coming up with different kinds of specification for the data to be stored in the database The database design part is one of the middle phases we have in information systems development where the system uses a database approach.

5 Cont Design is the part on which we would be engaged to describe how the data should be perceived at different levels and finally how it is going to be stored in a computer system

6 Cont Information System development with Database application consists of several tasks which include: Planning of Information systems Design Requirements Analysis, Database Design (Conceptual, Logical and Physical Design) Interface, program etc designs are also there Implementation Operation and Support

7 Cont From these different phases, the prime interest of this courses will be the Database Design part which is again sub divided into other three sub-phases. These sub-phases are: Conceptual Design Logical Design, and Physical Design

8 Cont In general, one has to go back and forth between these tasks to refine a database design, and decisions in one task can influence the choices in another task. In developing a good design, one should answer such questions as: What are the relevant Entities for the Organization What are the important features of each Entity What are the important Relationships What are the important queries from the user What are the other requirements of the Organization and the Users

9 Conceptual Database Design Conceptual design revolves around discovering and analyzing organizational and user data requirements The important activities are to identify Entities Attributes Relationships Constraints And based on these components develop the ER model using ER diagram components

10 Cont Designing conceptual model for the database is not a one linear process but an iterative activity where the design is refined again and again. Important steps then could be 1. Identification of components i. Entities ii. Attributes iii. Relationship iv. Constraints 2. Use of notations to model 3. Draw, Review, Refine and Validate

11 Cont Before working on the conceptual design of the database, one has to know and answer the following basic questions What are the entities and relationships in the enterprise? What information about these entities and relationships should we store in the database? What are the integrity constraints that hold? Constraints on each data with respect to update, retrieval and store Represent this information pictorially in ER diagrams, then map ER diagram into a relational schema.

12 Modeling tools Be professional- use the right tool symbols are languages There are many ER diagramming tools Rational Rose Microsoft Visio Oracle Designer Power Designer

13 E-R Model Constructs (recall) Entities: Entity instance person, place, object, event, concept (often corresponds to a row in a table) Entity Type collection of entities (often corresponds to a table) Relationships: Relationship instance link between entities (corresponds to primary key-foreign key equivalencies in related tables) Relationship type category of relationship link between entity types Attribute property or characteristic of an entity or relationship type (often corresponds to a field in a table)

14 How to Find Components of ER To identify the entities, attributes, relationships, and constraints on the data, there are different set of methods used during the analysis phase. These include information gathered through Interviewing end users individually and in a group Questionnaire survey Direct observation Examining different documents Generally understand the business rules

15 Constructs Identification-ERD Entity; Attribute; Relationship

16 Detailed Steps in Creating an ERD Here are the steps you may follow to create an entityrelationship diagram. 1. Identify Entities: These are typically the nouns and noun-phrases in the descriptive data produced in your analysis. Do not include entities that are irrelevant to your domain. 2. Find Relationships: Discover the semantic relationships between entities. These are usually the verbs that connect the nouns. Not all relationships are this blatant, you may have to discover some on your own. The easiest way to see all possible relationships is to build a table with the entities across the columns and down the rows, and fill in those cells where a relationship exists between entities.

17 Cont 3. Draw Rough ERD Draw the entities and relationships that you have discovered. 4. Fill in Cardinality Determine the cardinality of the relationships. You may want to decide on cardinality when you are creating a relationship table. 5. Define Primary Keys Identify attribute(s) that uniquely identify each occurrence of that entity. 6. Draw Key-Based ERD Now add them (the primary key attributes) to your ERD. Revise your diagram to eliminate many-to-many relationships, and tag all foreign keys.

18 Cont 7. Identify Attributes Identify all entity characteristics relevant to the domain being analyzed. 8. Map Attributes Determine to which entity each characteristic belongs. Do not duplicate attributes across entities. 9. Draw fully attributed ERD Now add these attributes. The diagram may need to be modified to accommodate necessary new entities. 10. Check Results Is the diagram a consistent and complete representation of the domain.

19 Cont In this all tasks Keep in mind Business rule Business functions are expressed in terms of business rules

20 Example business function-to-data matching matrix

21 Sample E-R Diagram- what it looks like

22 What Should an Entity Be? SHOULD BE: An object that will have many instances in the database An object that will be composed of multiple attributes An object that we are trying to model SHOULD NOT BE: A user of the database system (the one who only uses the system and his/her information is not important for the process) Sometimes user data might also be important to capture. For instance, in a financial system, it is important to register the employee who prepared the payment or approved a transaction issue of accountability) An output of the database system (e.g., a report, display)

23 Example of inappropriate entities System user Inappropriate entities System output Appropriate entities

24 Attributes Attribute property or characteristic of an entity or relationship type Classifications of attributes: 1. Required versus Optional Attributes 2. Simple versus Composite Attribute 3. Single-Valued versus Multivalued Attribute 4. Stored versus Derived Attributes 5. Entity Identifier Attributes

25 Identifiers (Keys) Identifier (Key) An attribute (or combination of attributes) that uniquely identifies individual instances of an entity type Simple versus Composite Identifier Candidate Key an attribute that could be a key satisfies the requirements for being an identifier Will not be null

26 Notation, Notation, Notation, Notation, Notation, Notation A composite attribute An attribute broken into component parts Entity with multivalued attribute (Skill) and derived attribute (Years_Employed) Multivalued an employee can have more than one skill Derived from date employed and current date

27 Simple and composite identifier attributes The identifier is boldfaced and underlined

28 More on Relationships Relationship Types vs. Relationship Instances The relationship type is modeled as lines between entity types the instance is between specific entity instances Relationships can have attributes These describe features pertaining to the association between the entities in the relationship Associative Entity combination of relationship and entity

29 Relationship types and instances a) Relationship type b) Relationship instances

30 Degree of relationships One entity related to another of the same entity type Entities of two different types related to each other Entities of three different types related to each other

31 Examples of relationships of different degrees a) Unary relationships

32 Examples of relationships of different degrees (cont.) b) Binary relationships

33 Examples of relationships of different degrees (cont.) c) Ternary relationship Note: a relationship can have attributes of its own

34 Structural Constraints (Cardinality Constraints) Cardinality Constraints - the number of instances of one entity that can or must be associated with each instance of another entity Minimum Cardinality If zero, then optional If one or more, then mandatory Maximum Cardinality The maximum number of tuples taking part in the relationship

35 Cont One-to-One Each entity in the relationship will have exactly one related entity E.g.: Relationship Manages between EMPLOYEE and BRANCH The multiplicity of the relationship is: One branch can only have one manager One employee could manage either one or no branches Employee Manages Branch

36 Cont One-to-Many An entity on one side of the relationship can have many related entities, but an entity on the other side will have a maximum of one related entity E.g.: Relationship Leads between EMPLOYEE and PROJECT The multiplicity of the relationship One employee may Lead no, one or more project(s) One project is Lead by one staff Employee * Leads Project

37 Cont Many-to-Many Entities on both sides of the relationship can have many related entities on the other side E.g.: Relationship Teaches between INSTRUCTOR and COURSE The multiplicity of the relationship One Instructor Teaches one or more Course(s) One Course Thought by no, one or more Instructor(s) Instructor 0..* 1..* Teaches Course

38 Examples of cardinality constraints a) Mandatory cardinalities A patient history is recorded for one and only one patient A patient must have recorded at least one history, and can have many

39 Examples of cardinality constraints (cont.) b) One optional, one mandatory A project must be assigned to at least one employee, and may be assigned to many An employee can be assigned to any number of projects, or may not be assigned to any at all

40 Examples of cardinality constraints (cont.) a) Optional cardinalities A person is married to at most one other person, or may not be married at all

41 Examples of multiple relationships Employees and departments Entities can be related to one another in more than one way

42 Multivalued attributes can be represented as relationships and entity simple composite

43 Identifying relationship Strong entity Weak entity

44 Associative Entities An Entity which has attributes A relationship links entities together When should a relationship with attributes instead be an associative entity? All relationships for the associative entity should have many cardinality The associative entity could have meaning independent of the other entities The associative entity preferably has a unique identifier, and should also have other attributes The associative entity may participate in other relationships other than the entities of the associated relationship Ternary relationships should be converted to associative entities

45 Example What if we want to keep the date the employee completed the course

46 A binary relationship with an attribute Here, the date completed attribute pertains specifically to the employee s completion of a course it is an attribute of the relationship

47 An associative entity (CERTIFICATE) Associative entity is like a relationship with an attribute, but it is also considered to be an entity in its own right. Note that the many-to-many cardinality between entities will be replaced by two one-to-many relationships with the associative entity.

48 An associative entity bill of materials structure This could just be a relationship with attributes it s a judgment call

49 Ternary relationship as an associative entity

50 Notation Standards ER Diagramming

51 Cont Related diagramming convention techniques: Peter Chen notation Crow s Foot Notation Bachman notation EXPRESS IDEF1X[4] Martin notation UML class diagrams

52 Basic E-R notation Entity symbols Attribute symbols A special entity that is also a relationship Relationship degrees specify number of entity types involved Relationship symbols Relationship cardinalities specify how many of each entity type is allowed

53 Symbols

54 Example-1 On ER

55 Cont. The University of Toronto has several departments. Each department is managed by a chair, and has at least one professor working for it. Professors must be assigned to one, but possibly more departments. At least one professor teaches each course, but a professor may be on sabbatical and not teach any course. Each course may be taught more than once by different professors. We know of the department name, the professor name, the professor employee id, the course names, the course schedule, the term/year that the course is taught, the departments the professor is assigned to, the department that offers the course.

56 Cont. The University of Toronto has several departments. Each department is managed by a chair, and has at least one professor working for it. Professors must be assigned to one, but possibly more departments. At least one professor teaches each course, but a professor may be on sabbatical and not teach any course. Each course may be taught more than once by different professors. We know of the department name, the professor name, the professor employee id, the course names, the course schedule, the term/year that the course is taught, the departments the professor is assigned to, the department that offers the course.

57 Solution Identify Entities These are typically the nouns and noun-phrases in the descriptive data produced in your analysis. Do not include entities that are irrelevant to your domain. The entity candidates are departments, chair, professor, course, and course section. Since there is only one instance of the University of Toronto, we exclude it from our consideration.

58 Finding Relationships

59 Draw Rough ERD Draw the entities and relationships that you have discovered. PK Department Managed By PK Chair Offers Assigned Is a Course Professor PK Teaches PK

60 Fill in Cardinality: Determine the cardinality of the relationships. You may want to decide on cardinality when you are creating a relationship table. PK Department Managed By PK Chair Offers Assigned Is a Course Professor PK Teaches PK

61 Cont Define Primary Keys Identify attribute(s) that uniquely identify each occurrence of that entity.

62 Draw Key-Based ERD Now add them (the primary key attributes) to your ERD. Revise your diagram to eliminate many-to-many relationships, and tag all foreign keys PK Department DeptID Managed By PK EmpID Chair Offers Assigned Is a Course Professor PK CourseNo Teaches PK EmpID

63 Cont Identify Attributes Identify all entity characteristics relevant to the domain being analyzed. Excluding those keys already identified: Schedule, Term, Professor name, Department Chair (which is an employee ID, a foreign key to Professor) Map Attributes Determine to which entity each characteristic belongs. Do not duplicate attributes across entities. If necessary, contain them in a new, related, entity. Schedule -- Prof-Course, Term -- Prof-Course, Chair Department Draw fully attributed ERD Now add these attributes The diagram may need to be modified to accommodate necessary new entities.

64 Department Chair PK DeptID DeptName Managed By PK EmpID attribute name EstablishmentYear attribute name Location Is a Offers Assigned Professor Course PK EmpID PK CourseNo FullName CourseTitle Teaches Specialization CreditHr HireDate Finally: Review, Modify and Validate

65 Example 2 A company has several departments. Each department has a supervisor and at least one employee. Employees must be assigned to at least one, but possibly more departments. At least one employee is assigned to a project, but an employee may be on vacation and not assigned to any projects. The important data fields are the names of the departments, projects, supervisors and employees, as well as the supervisor and employee number and a unique project number. Draw an ER Diagram for the above Case

66 Conceptual Database Design (EER modeling)

67 77 Cont Enhanced E-R (EER) Models Object-oriented extensions to E-R model EER is important when: Some tuples have special attribute to be described with a relationship between two entities is partial EER Concepts Generalization.Superclass/Supertype Specialization Subclass/Subtype Attribute Inheritance Subtype entities inherit values of all attributes of the super-type An instance of a subtype is also an instance of the super-type Constraints on specialization and generalization

68 78 Supertypes and Subtypes Subclass/Subtype An entity type whose tuples have attributes that distinguish its members from tuples of the generalized or Superclass entities. Subclasses can be either mutually exclusive (disjoint) or overlapping (inclusive). A single subclass may inherit attributes from two distinct superclasses. A mutually exclusive category/subclass is when an entity instance can be in only one of the subclasses. E.g.: An EMPLOYEE can either be SALARIED or PART-TIMER but not both. An overlapping category/subclass is when an entity instance may be in two or more subclasses. E.g.: A PERSON who works for a university can be both EMPLOYEE and a STUDENT at the same time.

69 Supertypes and Subtypes Superclass /Supertype An entity type whose tuples share common attributes. Attributes that are shared by all entity occurrences (including the identifier) are associated with the supertype. Is the generalized entity 79

70 Relationship of Superclass and Subclass An instance ca not only be a member of a subclass. i.e. Every instance of a subclass is also an instance in the Superclass. A member of a subclass is represented as a distinct database object, a distinct record that is related via foreign key attribute to its super-class. The relationship between a subclass and a Superclass is an IS A or IS PART OF type. Subclass IS PART OF Superclass Manager IS AN Employee 80

71 Notation All subclasses or specialized entity sets should be connected with the superclass using a line to a circle where there is a subset symbol indicating the direction of subclass/superclass relationship. 81

72 Basic notation for supertype/subtype notation a) EER notation 82

73 Cont Attribute Inheritance An entity that is a member of a subclass inherits all the attributes of the entity as a member of the superclass. The entity also inherits all the relationships in which the superclass participates. An entity may have more than one subclass categories. All subclasses of a superclass share a common unique identifier attribute (primary key). i.e. 83

74 Consider the EMPLOYEE supertype entity shown above. This entity can have several different subtype entities (for example: HOURLY and SALARIED), each with distinct properties not shared by other subtypes. But whether the employee is HOURLY or SALARIED, same attributes (EmployeeId, Name, and DateHired) are shared. The Supertype EMPLOYEE stores all properties that subclasses have in common. And HOURLY employees have the 84 unique attribute Wage (hourly wage rate), while SALARIED employees have two unique attributes, Pension and Salary.

75 Generalization and Specialization Generalization: The process of defining a more general entity type from a set of more specialized entity types. BOTTOM-UP Specialization: The process of defining one or more subtypes of the supertype and forming supertype/subtype relationships. TOP-DOWN 85

76 Example of generalization a) Three entity types: CAR, TRUCK, and MOTORCYCLE All these types of vehicles have common attributes 86

77 Example of generalization (cont.) b) Generalization to VEHICLE supertype So we put the shared attributes in a supertype 87 Note: no subtype for motorcycle, since it has no unique attributes

78 Example of specialization a) Entity type PART Only applies to manufactured parts Applies only to purchased parts 88

79 Example of specialization (cont.) b) Specialization to MANUFACTURED PART and PURCHASED PART Created 2 subtypes SupplierID Unite_Price 89

80 Example of specialization (cont.) b) Specialization to MANUFACTURED PART and PURCHASED PART Created 2 subtypes 90 Note: multivalued attribute was replaced by an associative entity relationship to another entity

81 Example of specialization (cont.) Relationship without Enhanced ER Model 91

82 Constraints in Supertype Completeness Constraints: Whether an instance of a supertype must also be a member of at least one subtype Total Specialization Rule: Yes (double line) Partial Specialization Rule: No (single line) 92

83 Constraints in Supertype The Total Specialization Rule specifies that an entity occurrence should at least be a member of one of the subclasses. E.g.: If we have EXTENTION and REGULAR as subclasses of a superclass STUDENT, then it is mandatory that each student to be either EXTENTION or REGULAR student. Thus the participation of instances of STUDENT in EXTENTION and REGULAR subclasses will be total. 93

84 Examples of completeness constraints a) Total specialization rule A patient must be either an outpatient or a resident patient 94

85 Constraints in Supertype The Partial Specialization Rule specifies that it is not necessary for all entity occurrences in the superclass to be a member of one of the subclasses. Here we have an optional participation on the specialization. E.g.: If we have MANAGER and SECRETARY as subclasses of a superclass EMPLOYEE, then it is not the case that all employees are either manager or secretary. Thus the participation of instances of employee in MANAGER and SECRETARY subclasses will be partial. 95

86 Examples of completeness constraints (cont.) b) Partial specialization rule A vehicle could be a car, a truck, or neither 96

87 97 Constraints in Supertype Disjointness Constraints: Whether an instance of a supertype may simultaneously be a member of two (or more) subtypes Disjoint Rule: An instance of the supertype can be only ONE of the subtypes Eg: an EMPLOYEE can either be SALARIED or PART-TIMER, but not the both at the same time. Overlap Rule: An instance of the supertype could be more than one of the subtypes Eg: EMPLOYEE working at the university can be both a STUDENT and an EMPLOYEE at the same time. This is diagrammed by placing either the letter "d" for disjoint or "o" for overlapping inside the circle on the Generalization Hierarchy portion of the E-R diagram.

88 Examples of disjointness constraints a) Disjoint rule A patient can either be outpatient or resident, but not both 98

89 Examples of disjointness constraints (cont.) b) Overlap rule A part may be both purchased and manufactured 99

90 Constraints in Supertype The two types of constraints on generalization and specialization (Disjointness and Completeness constraints) are not dependent on one another. That is, being disjoint will not favour whether the tuples in the superclass should have Total or Partial participation for that specific specialization. From the two types of constraints we can have four possible constraints Disjoint AND Total Disjoint AND Partial Overlapping AND Total Overlapping AND Partial 100

91 Constraints in Supertype/ Subtype Discriminators Subtype Discriminator: An attribute of the supertype whose values determine the target subtype(s) Disjoint a simple attribute with alternative values to indicate the possible subtypes Overlapping a composite attribute whose subparts pertain to different subtypes. Each subpart contains a boolean value to indicate whether or not the instance belongs to the associated subtype 101

92 Introducing a subtype discriminator (disjoint rule) A simple attribute with different possible values indicating the subtype 102

93 Subtype discriminator (overlap rule) A composite attribute with sub-attributes indicating yes or no to determine whether it is of each subtype 103

94 104 Example of supertype/subtype hierarchy

95 ERD-to- Relation (logical database design)

96 Cont Why ER is very high level closer to end users understanding Not directly possible to implement Needs transformation to fit to all business rules required

97 Cont How The first step is converting the conceptual design to a form suitable for relational logical model, which is in a form of tables- mapping The next is Normalization (applying the rules in relational data model)- Chapter 5

98 ER Diagrams into Relations Mapping Regular Entities to Relations/Tables Every Entity will be a Tables 1. Simple attributes: E-R attributes map directly onto the relation 2. Composite attributes: Use only their simple, component attributes 3. Multivalued Attribute Becomes a separate relation with a foreign key taken from the superior entity

99 Mapping a regular entity (a) CUSTOMER entity type with simple attributes (b) CUSTOMER relation

100 (a) CUSTOMER entity type with composite attribute Mapping a composite attribute (b) CUSTOMER relation with address detail

101 Mapping an entity with a multivalued attribute (a) Multivalued attribute becomes a separate relation with foreign key (b) One to many relationship between original entity and new relation

102 ER Diagrams into Relations Mapping Weak Entities Becomes a separate relation with a foreign key taken from the superior/strong entity Primary key composed of: Partial identifier of weak entity and/or Primary key of identifying relation (strong entity)

103 Example of mapping a weak entity a) Weak entity DEPENDENT

104 Example of mapping a weak entity (cont.) b) Relations resulting from weak entity NOTE: the domain constraint for the foreign key should NOT allow null value if DEPENDENT is a weak entity Foreign key Composite primary key

105 Mapping Relationships The cardinality will be the basis for mapping relationship One-to-One: Primary key of one of the side can be taken into the other as a foreign key. Recommendation: Primary key on the optional side becomes a foreign key on the mandatory side One-to-Many: Primary key on the one side becomes a foreign key on the many side Many-to-Many: Create a new relation with the primary keys of the two entities becomes the foreign key in the new table. The foreign keys will as well be part of the primary key in the new table.

106 Example of mapping a 1:M relationship a) Relationship between customers and orders Note the mandatory one b) Mapping the relationship Foreign key Again, no null value in the foreign key this is because of the mandatory minimum cardinality

107 Example of mapping an M:N relationship a) Many to Many relationship (M:N) The Completes relationship will need to become a separate relation

108 Example of mapping an M:N relationship (cont.) b) Three resulting relations Composite primary key Foreign key Foreign key New intersection relation

109 Example of mapping a binary 1:1 relationship a) One to one relationship (1:1) Often in 1:1 relationships, one direction is optional.

110 Example of mapping a binary 1:1 relationship (cont.) b) Resulting relations Foreign key goes in the relation on the optional side, Matching the primary key on the mandatory side

111 Example of mapping an associative entity a) An associative entity

112 Example of mapping an associative entity (cont.) b) Three resulting relations Composite primary key formed from the two foreign keys

113 Example of mapping an associative entity with an identifier a) SHIPMENT associative entity

114 Example of mapping an associative entity with an identifier (cont.) b) Three resulting relations Primary key differs from foreign keys

115 ER Diagrams into Relations Mapping Unary Relationships One-to-One: Recursive foreign key in the same relation One-to-Many: Recursive foreign key in the same relation Many-to-Many: Create a new relation and the primary key of the entity will be taken as a foreign key twice playing both roles in the recursive relationship. (N.B: make sure that the two foreign key names are different from one another even though they refer to same primary key value in the main table)

116 Mapping a unary 1:N relationship (a) EMPLOYEE entity with unary relationship (b) EMPLOYEE relation with recursive foreign key

117 Mapping a unary M:N relationship (a) Bill-of-materials relationships (M:N) (b) ITEM and COMPONENT relations

118 ER Diagrams into Relations Mapping Ternary (and n-ary) Relationships Create a new relation an post the primary key of all participating entities into the new table. Include if there are any attributes that would be meaningful only if the relationship takes place.

119 Mapping a ternary relationship a) PATIENT TREATMENT Ternary relationship with associative entity

120 Mapping a ternary relationship (cont.) b) Mapping the ternary relationship PATIENT TREATMENT Remember that the primary key MUST be unique This is why treatment date and time are included in the composite primary key But this makes a very cumbersome key It would be better to create a surrogate key like Treatment#

121 EER Diagrams into Relations Mapping Supertype/Subtype Relationships A separate relation for supertype and for each subtype Supertype attributes (including the subtype discriminator) go into supertype relation Subtype attributes go into each subtype; primary key of supertype relation also becomes primary key of subtype relation

122 Supertype/subtype relationships

123 Mapping Supertype/subtype relationships to relations These are implemented as one-to-one relationships

124 Example

125 Example Department Run_By Works_for Employee assigned Project

126 Solution Convert the ERD into Relation The simple process is 1. Create a table/relation for each entity from the ERD. 2. The entity attributes become the attributes/columns for the table/relation. 3. Potentially, include some foreign keys to represent relationships shown in the ERD.

127 Cont Create a table for each ERD entity There are 6 entities in the above Figure so there are six tables with the same names: Department, Supervisor, EmployeeDepartment, Employee, EmployeeProject, Project.

128 Cont Entity attributes become table attributes DEPARTMENT( DepartmentName ) SUPERVISOR( SupervisorNumber, SupervisorName ) EMPLOYEEDEPARTMENT( DepartmentName, EmployeeNumber ) EMPLOYEE( EmployeeNumber, EmployeeName ) EMPLOYEEPROJECT( EmployeeNumber, ProjectNumber ) PROJECT( ProjectNumber )

129 Cont Include some foreign keys to represent relationships Let's list the relationships and take each in turn Run By Can be represented by adding SupervisorNumber to the Department table DEPARTMENT( DepartmentName, SupervisorNumber ) Is assigned (employee-department) Is already represented in the EmployeeDepartment table

130 Cont Involves Also represented in the EmployeeDepartment table Works on Represented in the EmployeeProject table Is assigned (employ-project) Also represented by the EmployeeProject table.

131 Cont This means no other foreign keys are really needed. This leaves the Project table with only a primary key. But The primary key is meant to uniquely identify instances of an entity. The only data being stored in this table is the primary key, it has nothing to identify. The choices are Remove the table. It's not needed if it only has the primary key. Add more attributes to the table. So the Project table becomes PROJECT(ProjectNo, ProjectName, Budget, EndDate )

132 Cont Add more required attributes to other table EMPLOYEEDEPARTMENT ( DepartmentName, EmployeeNumber, StartDate ) EMPLOYEEPROJECT ( EmployeeNumber, ProjectNumber, StartDate ) Normally, this sort of process would not be required.

133 CLIENT ClientID ClientName PostalAddress (Street, Suburb, State, PostCode) Phone {(PhoneType, PhoneNbr)} ClientType requests PROJECT ProjectID Description EstimatedPrice EstimatedStartDate EstimatedFinishDate ActualStartDate ActualFinishDate CurrentStatus [ActualDuration] managed by STAFF StaffID StaffName Mobile JobTitle involves Exercise pre-req TASK TaskID Description EstimatedHours ActualStartDate ActualFinishDate CurrentStatus [ActualDuration] incurs submits TIMESHEET TimesheetID WorkDate WorkDescription HoursWorked Billable

134 Next on: Process of Normalization

135 Objectives Recalling Relational concepts Understand different anomalies and functional dependency concepts Use normalization to convert anomalous tables to wellstructured relations Why normalise What is normalisation Identify three problems solved by normalisation Example of how to normalise 145

136 Relation Definition: A relation is a named, two-dimensional table of data Table consists of rows (records) and columns (attribute or field) Requirements for a table to qualify as a relation: It must have a unique name Every attribute value must be atomic (not multivalued, not composite) Every row must be unique (can t have two rows with exactly the same values for all their fields) Attributes (columns) in tables must have unique names The order of the columns and rows must be irrelevant NOTE: all relations are in 1 st Normal form 146

137 Why normalize Data design aims to identify data stored in a system Almost certainly stored in a relational database Normalization intended to Eliminate redundancy Organize data efficiently Reduce the potential for anomalies 147

138 What is normalization Decompose a relation into a set of smaller relations A relation is in a specific normal form (NF) if it Satisfies requirements of all previous NFs Satisfies requirements of the current NF We concentrate on the first three NFs Data/Database normalization is a series of steps followed to obtain a database design that allows for consistent storage and efficient access of data in a relational database. 148

139 Cont Formal definition NORMALIZATION is the process of identifying the logical associations between data items and designing a database that will represent such associations but without suffering the update anomalies which are; Insertion Anomalies Deletion Anomalies Modification Anomalies Reading Assignment: Read and Understand the three kinds of anomalies 149

140 Cont All the normalization rules will eventually remove the update anomalies that may exist during data manipulation after the implementation Normalization may reduce system performance since data will be cross referenced from many tables created due to splitting. Denormalisation Doesn't always make sense for a table to be normalised Some applications work better with denormalised data Usually those that rely on lots of read only operations 150

141 151 Well-Structured Relations A relation that contains minimal data redundancy and allows users to insert, delete, and update rows without causing data inconsistencies As said before the goal is to avoid anomalies Insertion Anomaly adding new rows forces user to create duplicate data Deletion Anomaly deleting rows may cause a loss of data that would be needed for other future rows Modification Anomaly changing data in a row forces changes to other rows because of duplication General rule of thumb: A table should not pertain to more than one entity type (to have a well structured relation)

142 Example 2 What is the PK for this table? 152

143 Anomalies in this Table Insertion can t enter a new employee without having the employee take a class Deletion if we remove employee 140, we lose information about the existence of a Tax Acc class Modification giving a salary increase to employee 100 forces us to update multiple records Why do these anomalies exist? Because there are multiple objects (entity types) in this one relation. This results in data duplication and an unnecessary dependency between the real world objects 153

144 Functional Dependencies and Keys The mechanism to avoid the update anomalies and do normalization is to analyze relationship between data values/attributes of a relation Functional Dependency: The value of one attribute (the determinant) determines the value of another attribute Candidate Key: A unique identifier. One of the candidate keys will become the primary key Each non-key field is functionally dependent on the candidate key/primary key 154

145 Data Dependency FDs are derived from the real-world constraints on the attributes The essence of this idea is that if the existence of something, call it A, implies that B must exist and have a certain value, then we say: "B is functionally dependent on A." 155 We also often express this idea by saying that "A determines B," or "B is a function of A," or "A functionally governs B."

146 Data Dependency Often, the notions of functionality and functional dependency are expressed briefly by the statement, "If A, then B." It is important to note that the value B must be unique for a given value of A, i.e., any given value of A must imply just one and only one value of B, in order for the relationship to qualify for the name "function." (However, this does not necessarily prevent different values of A from implying the same value of B.) 156

147 Data Dependency X Y holds whenever two tuples have the same value for X, they must have the same value for Y Notation: A B which is read as; B is functionally dependent on A or A functionally determines B In general, functional dependency is a relationship among attributes. Who will tell us this FD? How do we know? Most of the time we need sample data 157

148 Data Dependency Partial Dependency If an attribute which is not a member of the primary key is dependent on some part of the primary key (if we have composite primary key) then that attribute is partially functionally dependent on the primary key. Let {A,B} be the Primary Key and C is non key attribute. Then if {A,B} C and B C or A C Then C is partially functionally dependent on {A,B} 158

149 Data Dependency Full Dependency If an attribute which is not a member of the primary key is not dependent on some part of the primary key but the whole key (if we have composite primary key) then that attribute is fully functionally dependent on the primary key. Let {A,B} is the Primary Key and C is non key attribute Then if {A,B} C and B C and A C does not hold Then C Fully functionally dependent on {A,B} 159

150 Data Dependency Transitive Dependency In mathematics and logic, a transitive relationship is a relationship of the following form: "If A implies B, and if also B implies C, then A implies C." Example: If Mr X is a Human, and if every Human is an Animal, then Mr X must be an Animal. Generalized description of transitive dependency is that: If A functionally governs B, AND If B functionally governs C THEN A functionally governs C Provided that neither C nor B determines A i.e. (B A and C A) In the normal notation: {(A B) AND (B C)} ==> A C provided that B A and C A 160

151 Steps of Normalization We have various levels or steps in normalization called Normal Forms. The level of complexity, strength of the rule and decomposition increases as we move from one lower level Normal Form to the higher. A table in a relational database is said to be in a certain normal form if it satisfies certain constraints. Normal form below(next) represents a stronger condition than the previous one 161

152 162 Steps in normalization- Pictorial representation

153 First Normal Form (1NF) Requires that all column values in a table are atomic (e.g., a number is an atomic value, while a list or a set is not). Solution Moving this repeating groups to a new row by repeating the common attributes. If so then Find the key with which you can find all data Thus No multivalued attributes Every attribute value is atomic For example Fig is not in 1 st Normal Form (multivalued attributes) it is not a relation While Fig is in 1 st Normal form Remark All relations are in 1 st Normal Form 163

154 Cont Formal Definition: a table (relation) is in 1NF If There are no duplicated rows in the table. Unique identifier Each cell is single-valued (i.e., there are no repeating groups). Entries in a column (attribute, field) are of the same kind. 164

155 165 Example for First Normal form (1NF )

156 FIRST NORMAL FORM (1NF) Remove all repeating groups. Distribute the multi-valued attributes into different rows and identify a unique identifier for the relation so that is can be said is a relation in relational database. 166

157 Example 2: Table with multivalued attributes, not in 1 st normal form Note: this is NOT a relation 167

158 Table with no multivalued attributes and unique rows, in 1 st normal form Note: this is relation, but not a well-structured one 168

159 Second Normal form 2NF No partial dependency of a non key attribute on part of the primary key. This will result in a set of relations with a level of Second Normal Form. Any table that is in 1NF and has a single-attribute (i.e., a non-composite) key is automatically also in 2NF. 169

160 Cont Formal Definition: a table (relation) is in 2NF If It is in 1NF and If all non-key attributes are dependent on the entire primary key. i.e. no partial dependency. 170

161 Example 1: for 2NF EMP_PROJ EmpID EmpName ProjNo ProjName ProjLoc ProjFund PrrojMangID Incentive EMP_PROJ rearranged EmpID ProjNo EmpName ProjName ProjLoc ProjFund ProjMangID Incentive Business rule: Whenever an employee participates in a project, he/she will be entitled for an incentive. This schema is in its 1NF since we don t have any repeating groups or attributes with multi-valued property. 171

162 Cont To convert it to a 2NF we need to remove all partial dependencies of non key attributes on part of the primary key. {EmpID, ProjNo} EmpName, ProjName, ProjLoc, ProjFund, ProjMangID, Incentive But in addition to this we have the following dependencies FD1: {EmpID} EmpName FD2: {ProjNo} ProjName, ProjLoc, ProjFund, ProjMangID FD3: {EmpID, ProjNo} Incentive 172

163 Cont As we can see, some non key attributes are partially dependent on some part of the primary key. This can be witnessed by analyzing the first two functional dependencies (FD1 and FD2). Thus, each Functional Dependencies, with their dependent attributes should be moved to a new relation where the Determinant will be the Primary Key for each. 173

164 174 Cont

165 Example 2: Functional dependency diagram for INVOICE Order_ID Order_Date, Customer_ID, Customer_Name, Customer_Address Customer_ID Customer_Name, Customer_Address Product_ID Product_Description, Product_Finish, Unit_Price Order_ID, Product_ID Order_Quantity 175 Therefore, NOT in 2 nd Normal Form

166 Removing partial dependencies Getting it into Second Normal Form Partial dependencies are removed, but there are still transitive dependencies 176

167 Third Normal Form (3NF ) Eliminate Columns Dependent on another non-primary Key - If attributes do not contribute to a description of the key, remove them to a separate table. This level avoids update and delete anomalies. Formal Definition: a Table (Relation) is in 3NF If It is in 2NF and There are no transitive dependencies between a primary key and non-primary key attributes. 177

168 Cont 2NF PLUS no transitive dependencies (functional dependencies on non-primary-key attributes) Note: This is called transitive, because the primary key is a determinant for another attribute, which in turn is a determinant for a third Solution: Non-key determinant with transitive dependencies go into a new table; non-key determinant becomes primary key in the new table and stays as foreign key in the old table 178

169 Removing transitive dependencies Getting it into Third Normal Form Transitive dependencies are removed 179

170 2 nd Example for (3NF) Assumption: Students of same batch (same year) live in one building or dormitory Student StudID Stud_F_Name Stud_L_Name Dept Year Dormitary 125/97 Abebe Mekuria Info Sc /95 Lemma Alemu Geog /95 Chane Kebede CompSc /97 Alem Kebede InfoSc /95 Almaz Belay Geog This schema is in its 2NF since the primary key is a single attribute. 180

171 Cont StudID Year ANDYear Dormitary And Year can not determine StudID and Dormitary can not determine StudID Then transitively StudID Dormitary To convert it to a 3NF we need to remove all transitive dependencies of non key attributes on another non-key attribute. The non-primary key attributes, dependent on each other will be moved to another table and linked with the main table using Candidate Key- Foreign Key relationship. 181

172 182 Cont

173 Cont Generally, eventhough there are other four additional levels of Normalization, a table is said to be normalized if it reaches 3NF. A database with all tables in the 3NF is said to be Normalized Database. Reading Assignment Boyce-Codd Normal Form (BCNF) Forth Normal form (4NF) Fifth Normal Form (5NF) Domain-Key Normal Form (DKNF) 183

174 Summary of the Process of Normalization To understand normalisation you need to know these problems 1NF: Repeating groups 2NF: Partial Dependency 3NF: Transitive Dependency and Derived Attributes Normalisation is the process of decomposing relations 184

175 Cont Some important indicators No Repeating or Redunduncy: no repeting fields in the table. The Fields Depend Upon the Key: the table should solely depend on the key. The Whole Key: no partial keybdependency. And Nothing But The Key: no inter data dependency. 185

176 Cont Pitfalls (Limitations) of Normalization Requires data to see the problems May reduce performance of the system Is time consuming, Difficult to design and apply and Prone to human error 186

177 187 End of Chapter Four