Unit I. Introduction to Database. Prepared By: Prof.Sushila Aghav. Ref.Database Concepts by Korth

Transcription

1 Unit I Introduction to Database Prepared By: Prof.Sushila Aghav Ref.Database Concepts by Korth

2 Contents Database Concepts Data Models & Types Relational Database-R Model(Table) ER Modeling Concepts of Normalization MySQL: DDL,DML,DCL,TCL,Select,VIEW,Index,Procedur es and Functions Ref.Database Concepts by Korth

3 Ref. Database Concepts by Korth

4 Ref.Database Concepts by Korth

5 Ref.Database Concepts by Korth

6 Ref.Database Concepts by Korth

7 Ref.Database Concepts by Korth

8 Ref.Database Concepts by Korth

9 Ref.Database Concepts by Korth

10 Ref.Database Concepts by Korth

11 Ref.Database Concepts by Korth

12 Ref.Database Concepts by Korth

13 Legacy Data Model: R Model Ref.Database Concepts by Korth

14 Ref.Database Concepts by Korth

15 Ref.Database Concepts by Korth

16 Ref.Database Concepts by Korth

17 Ref.Database Concepts by Korth

18 Ref.Database Concepts by Korth

19 Ref.Database Concepts by Korth

20 Ref.Database Concepts by Korth

21 Ref.Database Concepts by Korth

22 Ref.Database Concepts by Korth

23 Ref.Database Concepts by Korth

24 Ref.Database Concepts by Korth

25 Ref.Database Concepts by Korth

26 Ref.Database Concepts by Korth

27 Ref.Database Concepts by Korth

28 Ref.Database Concepts by Korth

29 Ref.Database Concepts by Korth

30 Entity-Relationship Model

31 A databasecan be modeled as: a collection of entities, relationship among entities. Modeling An entity is an object that exists and is distinguishable from other objects. Example: specific person, company, event, plant Entities have attributes Example: people have names and addresses An entity setis a set of entities of the same type that share the same properties. Example: set of all persons, companies, trees, holidays

32 Entity Sets instructor and student instructor_id instructor_name student-id student_name

33 Relationship Sets A relationship is an association among several entities Example: (Peltier) advisor (Einstein) student entity relationship set instructor entity A relationship setis a mathematical relation among n 2 entities, each taken from entity sets {(e 1, e 2, e n ) e 1 E 1, e 2 E 2,, e n E n } where (e 1, e 2,, e n ) is a relationship Example: (44553,22222) advisor

34 Relationship Set advisor

35 Relationship Sets (Cont.) An attribute can also be property of a relationship set. For instance, the advisor relationship set between entity sets instructor and student may have the attribute date which tracks when the student started being associated with the advisor

36 Degree of a Relationship Set binary relationship involve two entity sets (or degree two). most relationship sets in a database system are binary. Relationships between more than two entity sets are rare. Most relationships are binary. (More on this later.) Example: studentswork on research projectsunder the guidance of an instructor. relationship proj_guideis a ternary relationship between instructor, student, and project

37 Attributes An entity is represented by a set of attributes, that is descriptive properties possessed by all members of an entity set. Example: instructor = (ID, name, street, city, salary ) course= (course_id, title, credits) Domain the set of permitted values for each attribute Attribute types: Simple and composite attributes. Single-valued and multivalued attributes Example: multivalued attribute: phone_numbers Derived attributes Can be computed from other attributes Example: age, given date_of_birth

38 Composite Attributes

39 Mapping Cardinality Constraints Express the number of entities to which another entity can be associated via a relationship set. Most useful in describing binary relationship sets. For a binary relationship set the mapping cardinality must be one of the following types: One to one One to many Many to one Many to many

40 Mapping Cardinalities One to one One to many Note: Some elements in Aand Bmay not be mapped to any elements in the other set

41 Mapping Cardinalities Many to one Many to many Note: Some elements in A and B may not be mapped to any elements in the other set

42 Keys A super keyof an entity set is a set of one or more attributes whose values uniquely determine each entity. A candidate keyof an entity set is a minimal super key ID is candidate key of instructor course_id is candidate key of course Although several candidate keys may exist, one of the candidate keys is selected to be the primary key.

43 Keys for Relationship Sets The combination of primary keys of the participating entity sets forms a super key of a relationship set. (s_id, i_id) is the super key of advisor NOTE: this means a pair of entity sets can have at most one relationship in a particular relationship set. Example: if we wish to track multiple meeting dates between a student and her advisor, we cannot assume a relationship for each meeting. We can use a multivalued attribute though Must consider the mapping cardinality of the relationship set when deciding what are the candidate keys Need to consider semantics of relationship set in selecting the primary key in case of more than one candidate key

44 Redundant Attributes Suppose we have entity sets instructor, with attributes including dept_name department and a relationship inst_dept relating instructor and department Attribute dept_namein entity instructoris redundant since there is an explicit relationship inst_dept which relates instructors to departments The attribute replicates information present in the relationship, and should be removed from instructor BUT: when converting back to tables, in some cases the attribute gets reintroduced, as we will see.

45 E-R Diagrams Rectangles represent entity sets. Diamonds represent relationship sets. Attributes listed inside entity rectangle Underline indicates primary key attributes

46 Entity With Composite, Multivalued, and Derived Attributes

47 Relationship Sets with Attributes

48 Roles Entity sets of a relationship need not be distinct Each occurrence of an entity set plays a role in the relationship The labels course_id and prereq_id are called roles.

49 Cardinality Constraints We express cardinality constraints by drawing either a directed line ( ), signifying one, or an undirected line ( ), signifying many, between the relationship set and the entity set. One-to-one relationship: A student is associated with at most one instructorvia the relationship advisor A student is associated with at most one department via stud_dept

50 One-to-One Relationship one-to-one relationship between an instructor and a student an instructor is associated with at most one student via advisor and a student is associated with at most one instructor via advisor

51 One-to-Many Relationship one-to-many relationship between an instructor and a student an instructor is associated with several (including 0) students via advisor a student is associated with at most one instructor via advisor,

52 Many-to-One Relationships In a many-to-one relationship between an instructorand a student, an instructor is associated with at most one student via advisor, and a student is associated with several (including 0) instructors via advisor

53 Many-to-Many Relationship An instructor is associated with several (possibly 0) students via advisor A student is associated with several (possibly 0) instructors via advisor

54 Participation of an Entity Set in a Relationship Set Total participation (indicated by double line): every entity in the entity set participates in at least one relationship in the relationship set E.g., participation of section in sec_course is total every sectionmust have an associated course Partial participation: some entities may not participate in any relationship in the relationship set Example: participation of instructor in advisor is partial

55 Alternative Notation for Cardinality Limits Cardinality limits can also express participation constraints

56 E-RDiagram with a Ternary Relationship

57 Cardinality Constraints on Ternary Relationship We allow at most one arrow out of a ternary (or greater degree) relationship to indicate a cardinality constraint E.g., an arrow from proj_guideto instructorindicates each student has at most one guide for a project If there is more than one arrow, there are two ways of defining the meaning. E.g., a ternary relationship R between A,B and C with arrows to B and C could mean 1. each A entity is associated with a unique entity from B and C or 2. each pair of entities from (A, B) is associated with a unique C entity, and each pair (A, C) is associated with a unique B Each alternative has been used in different formalisms To avoid confusion we outlaw more than one arrow

58 How about doing an ER design interactively on the board? Suggest an application to be modeled.

59 Weak Entity Sets An entity set that does not have a primary key is referred to as a weak entity set. The existence of a weak entity set depends on the existence of a identifying entity set It must relate to the identifying entity set via a total, one-to-many relationship set from the identifying to the weak entity set Identifying relationship depicted using a double diamond The discriminator(or partial key)of a weak entity set is the set of attributes that distinguishes among all the entities of a weak entity set. The primary key of a weak entity set is formed by the primary key of the strong entity set on which the weak entity set is existence dependent, plus the weak entity set s discriminator.

60 Weak Entity Sets (Cont.) We underline the discriminator of a weak entity set with a dashed line. We put the identifying relationship of a weak entity in a double diamond. Primary key for section (course_id, sec_id, semester, year)

61 Weak Entity Sets (Cont.) Note: the primary key of the strong entity set is not explicitly stored with the weak entity set, since it is implicit in the identifying relationship. If course_idwere explicitly stored, sectioncould be made a strong entity, but then the relationship between sectionand coursewould be duplicated by an implicit relationship defined by the attribute course_id common to course and section

62 E-R Diagram for a University Enterprise

63 Reduction to Relational Schemas

64 Reduction to Relation Schemas Entity sets and relationship sets can be expressed uniformly as relation schemas that represent the contents of the database. A database which conforms to an E-R diagram can be represented by a collection of schemas. For each entity set and relationship set there is a unique schema that is assigned the name of the corresponding entity set or relationship set. Each schema has a number of columns (generally corresponding to attributes), which have unique names.

65 Representing Entity Sets With Simple Attributes A strong entity set reduces to a schema with the same attributes student(id, name, tot_cred) A weak entity set becomes a table that includes a column for the primary key of the identifying strong entity set section ( course_id, sec_id, sem, year)

66 Representing Relationship Sets A many-to-many relationship set is represented as a schema with attributes for the primary keys of the two participating entity sets, and any descriptive attributes of the relationship set. Example: schema for relationship set advisor advisor = (s_id, i_id)

67 Redundancy of Schemas Many-to-one and one-to-many relationship sets that are total on the manyside can be represented by adding an extra attribute to the many side, containing the primary key of the one side Example: Instead of creating a schema for relationship set inst_dept, add an attribute dept_name to the schema arising from entity set instructor

68 Redundancy of Schemas (Cont.) For one-to-one relationship sets, either side can be chosen to act as the many side That is, extra attribute can be added to either of the tables corresponding to the two entity sets If participation is partialon the many side, replacing a schema by an extra attribute in the schema corresponding to the many side could result in null values The schema corresponding to a relationship set linking a weak entity set to its identifying strong entity set is redundant. Example: The section schema already contains the attributes that would appear in the sec_course schema

69 Composite and Multivalued Attributes Composite attributes are flattened out by creating a separate attribute for each component attribute Example: given entity set instructorwith composite attribute namewith component attributes first_name and last_namethe schema corresponding to the entity set has two attributes name_first_name and name_last_name Prefix omitted if there is no ambiguity Ignoring multivalued attributes, extended instructor schema is instructor(id, first_name, middle_initial, last_name, street_number, street_name, apt_number, city, state, zip_code, date_of_birth)

70 Composite and Multivalued Attributes A multivalued attribute Mof an entity Eis represented by a separate schema EM Schema EMhas attributes corresponding to the primary key of Eand an attribute corresponding to multivalued attribute M Example: Multivalued attribute phone_number of instructoris represented by a schema: inst_phone= ( ID, phone_number) Each value of the multivalued attribute maps to a separate tuple of the relation on schema EM For example, an instructorentity with primary key and phone numbers and maps to two tuples: (22222, ) and (22222, )

71 Multivalued Attributes (Cont.) Special case:entity time_slot has only one attribute other than the primarykey attribute, and that attribute is multivalued Optimization: Don t create the relation corresponding to the entity, just create the one corresponding to the multivalued attribute time_slot(time_slot_id, day, start_time, end_time) Caveat: time_slot attribute of section (from sec_time_slot) cannot be a foreign key due to this optimization

72 Design Issues Use of entity sets vs. attributes Use of phone as an entity allows extra information about phone numbers (plus multiple phone numbers)

73 Design Issues Use of entity sets vs. relationship sets Possible guideline is to designate a relationship set to describe an action that occurs between entities

74 Design Issues Binary versus n-ary relationship sets Although it is possible to replace any nonbinary (n-ary, for n> 2) relationship set by a number of distinct binary relationship sets, a n-ary relationship set shows more clearly that several entities participate in a single relationship. Placement of relationship attributes e.g., attribute date as attribute of advisor or as attribute of student

75 Binary Vs. Non-Binary Relationships Some relationships that appear to be non-binary may be better represented using binary relationships E.g., A ternary relationship parents, relating a child to his/her father and mother, is best replaced by two binary relationships, father and mother Using two binary relationships allows partial information (e.g., only mother being know) But there are some relationships that are naturally non-binary Example: proj_guide

76 Converting Non-Binary Relationships to Binary Form In general, any non-binary relationship can be represented using binary relationships by creating an artificial entity set. Replace R between entity sets A, B and Cby an entity set E, and three relationship sets: 1. R A, relating E and A 2. R B, relating E and B 3. R C, relating E and C Create a special identifying attribute for E Add any attributes of R to E For each relationship (a i, b i, c) i ) in R,create 1. a new entity e i in the entity set E 2. add (e i, a i ) to R A 3. add (e i, b i ) to R B 4. add (e i, c i ) to R C

77 Converting Non-Binary Relationships Also need to translate constraints (Cont.) Translating all constraints may not be possible There may be instances in the translated schema that cannot correspond to any instance of R Exercise: add constraints to the relationships R A, R B and R C to ensure that a newly created entity corresponds to exactly one entity in each of entity sets A, Band C We can avoid creating an identifying attribute by making E a weak entity set (described shortly) identified by the three relationship sets

78 Extended ER Features

79 Extended E-R Features: Specialization Top-down design process; we designate subgroupings within an entity set that are distinctive from other entities in the set. These subgroupings become lower-level entity sets that have attributes or participate in relationships that do not apply to the higher-level entity set. Depicted by a triangle component labeled ISA (E.g., instructor is a person). Attribute inheritance a lower-level entity set inherits all the attributes and relationship participation of the higher-level entity set to which it is linked.

80 Specialization Example

81 Extended ER Features: Generalization A bottom-up design process combine a number of entity sets that share the same features into a higher-level entity set. Specialization and generalization are simple inversions of each other; they are represented in an E-R diagram in the same way. The terms specialization and generalization are used interchangeably.

82 Specialization and Generalization (Cont.) Can have multiple specializations of an entity set based on different features. E.g., permanent_employeevs. temporary_employee, in addition to instructor vs. secretary Each particular employee would be a member of one of permanent_employeeor temporary_employee, and also a member of one of instructor, secretary The ISA relationship also referred to as superclass- subclass relationship

83 Design Constraints on a Specialization/Generalization Constraint on which entities can be members of a given lower-level entity set. condition-defined Example: all customers over 65 years are members of senior-citizen entity set; senior-citizen ISA person. user-defined Constraint on whether or not entities may belong to more than one lower-level entity set within a single generalization. Disjoint an entity can belong to only one lower-level entity set Noted in E-R diagram by having multiple lower-level entity sets link to the same triangle Overlapping an entity can belong to more than one lower-level entity set

84 Design Constraints on a Specialization/Generalization (Cont.) Completeness constraint--specifies whether or not an entity in the higher-level entity set must belong to at least one of the lower-level entity sets within a generalization. total: an entity must belong to one of the lower-level entity sets partial: an entity need not belong to one of the lower-level entity sets

85 Aggregation Consider the ternary relationship proj_guide, which we saw earlier Suppose we want to record evaluations of a student by a guide on a project

86 Aggregation (Cont.) Relationship sets eval_for and proj_guiderepresent overlapping information Every eval_for relationship corresponds to a proj_guide relationship However, some proj_guiderelationships may not correspond to any eval_forrelationships So we can t discard the proj_guide relationship Eliminate this redundancy via aggregation Treat relationship as an abstract entity Allows relationships between relationships Abstraction of relationship into new entity

87 Aggregation (Cont.) Without introducing redundancy, the following diagram represents: A student is guided by a particular instructor on a particular project A student, instructor, project combination may have an associated evaluation

88 Method 1: Representing Specialization via Schemas Form a schema for the higher-level entity Form a schema for each lower-level entity set, include primary key of higher-level entity set and local attributes schema person student employee attributes ID, name, street, city ID, tot_cred ID, salary Drawback: getting information about, an employeerequires accessing two relations, the one corresponding to the low-level schema and the one corresponding to the high-level schema

89 Method 2: Representing Specialization as Schemas (Cont.) Form a schema for each entity set with all local and inherited attributes schema attributes person ID, name, street, city student ID, name, street, city, tot_cred employee ID, name, street, city, salary If specialization is total, the schema for the generalized entity set (person) not required to store information Can be defined as a view relation containing union of specialization relations But explicit schema may still be needed for foreign key constraints Drawback: name, streetand citymay be stored redundantly for people who are both students and employees

90 Schemas Corresponding to Aggregation To represent aggregation, create a schema containing primary key of the aggregated relationship, the primary key of the associated entity set any descriptive attributes

91 Schemas Corresponding to Aggregation (Cont.) For example, to represent aggregation manages between relationship works_on and entity set manager, create a schema eval_for(s_id, project_id, i_id, evaluation_id) Schema proj_guideis redundant provided we are willing to store null values for attribute manager_name in relation on schema manages

92 Normalization The purpose of normailization Data redundancy and Update Anomalies Functional Dependencies The Process of Normalization First Normal Form (1NF) Second Normal Form (2NF) Third Normal Form (3NF)

93 Normalization Ref.Database Concepts by Korth

94 How to break schema Based on Functional Dependency and Rules Normal Forms: 1 NF,2 NF,3 NF,4 NF,5 NF,BCNF Case Study : Book Shop Ref.Database Concepts by Korth

95 The Purpose of Normalization Normalization is a technique for producing a set of relations with desirable properties, given the data requirements of an enterprise. The process of normalization is a formal method that identifies relations based on their primary or candidate keys and the functional dependencies among their attributes.

96 Update Anomalies Relations that have redundant data may have problems called update anomalies, which are classified as, Insertion anomalies Deletion anomalies Modification anomalies

97 Example of Update Anomalies To insert a new staff with branchno B007 into the StaffBranch relation; To delete a tuple that represents the last member of staff located at a branch B007; To change the address of branch B003. StaffBranch staffno sname position salary branchno baddress SL21 John White Manager B Deer Rd, London SG37 Ann Beech Assistant B Main St,Glasgow SG14 David Ford Supervisor B Main St,Glasgow SA9 Mary Howe Assistant 9000 B Argyll St, Aberdeen SG5 Susan Brand Manager B Main St,Glasgow SL41 Julie Lee Assistant 9000 B Deer Rd, London Figure 1 StraffBranch relation

98 Example of Update Anomalies (2) Staff staffno sname position salary branceno SL21 John White Manager B005 SG37 Ann Beech Assistant B003 SG14 David Ford Supervisor B003 SA9 Mary Howe Assistant 9000 B007 SG5 Susan Brand Manager B003 SL41 Julie Lee Assistant 9000 B005 Branch branceno B005 B007 B003 baddress 22 Deer Rd, London 16 Argyll St, Aberdeen 163 Main St,Glasgow Figure 2 Straff and Branch relations

99 Functional Dependencies Functional dependency describes the relationship between attributes in a relation. For example, if A and B are attributes of relation R, and B is functionally dependent on A ( denoted A B), if each value of A is associated with exactly one value of B. ( A and B may each consist of one or more attributes.) A B is functionally dependent on A B Determinant Refers to the attribute or group of attributes on the lefthand side of the arrow of a functional dependency

100 Functional Dependencies (2) Trival functional dependency means that the right-hand side is a subset ( not necessarily a proper subset) of the lefthand side. For example: (See Figure 1) staffno, sname sname staffno, sname staffno They do not provide any additional information about possible integrity constraints on the values held by these attributes. We are normally more interested in nontrivial dependenciesbecause they represent integrity constraints for the relation.

101 Functional Dependencies (3) Main characteristics of functional dependencies in normalization Have a one-to-one relationship between attribute(s) on the leftand right- hand side of a dependency; hold for all time; are nontrivial.

102 Functional Dependencies (4) Identifying the primary key Functional dependency is a property of the meaning or semantics of the attributes in a relation. When a functional dependency is present, the dependency is specified as a constraint between the attributes. An important integrity constraint to consider first is the identification of candidate keys, one of which is selected to be the primary key for the relation using functional dependency.

103 Inference Rules Functional Dependencies (5) A set of all functional dependencies that are implied by a given set of functional dependencies X is called closure of X, written X +. A set of inference rule is needed to compute X + from X. Armstrong s axioms 1. Relfexivity: If B is a subset of A, them A B 2. Augmentation: If A B, and C B then A, C B 3. Transitivity: If A B and B C, then A C 4. Self-determination: A A 5. Decomposition: If A B,C then A B and A C 6. Union: If A B and A C, then A B,C 7. Composition: If A B and C D, then A,C B,

104 Functional Dependencies (6) Minial Sets of Functional Dependencies A set of functional dependencies X is minimalif it satisfies the following condition: Every dependency in X has a single attribute on its right-hand side We cannot replace any dependency A B in X with dependency C B, where C is a proper subset of A, and still have a set of dependencies that is equivalent to X. We cannot remove any dependency from X and still have a set of dependencies that is equivalent to X.

105 Functional Dependencies (7) Example of A Minial Sets of Functional Dependencies A set of functional dependencies for the StaffBranch relation satisfies the three conditions for producing a minimal set. staffno sname staffno position staffno salary staffno branchno staffno baddress branchno baddress branchno, position salary baddress, position salary

106 The Process of Normalization Normalizationis often executed as a series of steps. Each step corresponds to a specific normal form that has known properties. As normalization proceeds, the relations become progressively more restricted in format, and also less vulnerable to update anomalies.

107 Unnormalized form (UNF) A table that contains one or more repeating groups. (1NF) Repeating group = (propertyno, paddress, rentstart, rentfinish, rent, ownerno, oname) ClientNo cname propertyno paddress rentstart rentfinish rent ownerno oname CR76 John kay PG4 PG16 PG4 6 lawrence St,Glasgow 5 Novar Dr, Glasgow 6 lawrence St,Glasgow 1-Jul Aug CO40 1-Sep-02 1-Sep-99 1-Sep Jun CO93 CO40 Tina Murphy Tony Shaw Tina Murphy CR56 Aline Stewart PG36 2 Manor Rd, Glasgow 10-Oct-00 1-Dec CO93 Tony Shaw PG16 5 Novar Dr, Glasgow 1-Nov-02 1-Aug CO93 Tony Shaw Figure 3 ClientRental unnormalized table

108 Definition of 1NF First Normal Formis a relation in which the intersection of each row and column contains one and only one value. There are two approaches to removing repeating groups from unnormalized tables: 1. Removes the repeating groups by entering appropriate data in the empty columns of rows containing the repeating data. 2. Removes the repeating group by placing the repeating data, along with a copy of the original key attribute(s), in a separate relation. A primary key is identified for the new relation.

109 With the first approach, we remove the repeating group (property rented details) by entering the appropriate client data into each row. 1NF ClientRental relation with the first approach The ClientRental relation is defined as follows, ClientRental ( clientno, propertyno, cname, paddress, rentstart, rentfinish, rent, ownerno, oname) ClientNo propertyno cname paddress rentstart rentfinish rent ownerno oname CR76 PG4 John Kay 6 lawrence St,Glasgow 1-Jul Aug CO40 Tina Murphy CR76 PG16 John Kay 5 Novar Dr, Glasgow 1-Sep-02 1-Sep CO93 Tony Shaw CR56 PG4 Aline Stewart 6 lawrence St,Glasgow 1-Sep Jun CO40 Tina Murphy CR56 PG36 Aline Stewart 2 Manor Rd, Glasgow 10-Oct-00 1-Dec CO93 Tony Shaw CR56 PG16 Aline Stewart 5 Novar Dr, Glasgow 1-Nov-02 1-Aug CO93 Tony Shaw Figure 4 1NF ClientRental relation with the first approach

110 Client (clientno, cname) PropertyRentalOwner(clientNo, propertyno, paddress, rentstart, rentfinish, rent, ownerno, oname) 1NF ClientRental relation with the second approach With the second approach, we remove the repeating group (property rented details) by placing the repeating data along with a copy of the original key attribute (clientno) in a separte relation. ClientNo CR76 CR56 cname John Kay Aline Stewart ClientNo propertyno paddress rentstart rentfinish rent ownerno oname CR76 CR76 CR56 CR56 CR56 PG4 PG16 PG4 PG36 PG16 6 lawrence St,Glasgow 5 Novar Dr, Glasgow 6 lawrence St,Glasgow 2 Manor Rd, Glasgow 5 Novar Dr, Glasgow 1-Jul Aug CO40 1-Sep-02 1-Sep CO93 1-Sep Jun CO40 10-Oct-00 1-Dec CO93 1-Nov-02 1-Aug CO93 Tina Murphy Tony Shaw Tina Murphy Tony Shaw Tony Shaw Figure 5 1NF ClientRental relation with the second approach

111 Full functional dependency Full functional dependencyindicates that if A and B are attributes of a relation, B is fully functionally dependent on A if B is functionally dependent on A, but not on any proper subset of A. A functional dependency A B is partially dependentif there is some attributes that can be removed from A and the dependency still holds.

112 Second Normal Form (2NF) Second normal form (2NF)is a relation that is in first normal form and every non-primary-key attribute is fully functionally dependent on the primary key. The normalization of 1NF relations to 2NF involves the removal of partial dependencies. If a partial dependency exists, we remove the function dependent attributes from the relation by placing them in a new relation along with a copy of their determinant.

113 2NF ClientRental relation The ClientRental relation has the following functional dependencies: fd1 clientno, propertyno rentstart, rentfinish (Primary Key) fd2 clientno cname (Partial dependency) fd3 propertyno paddress, rent, ownerno, oname (Partial dependency) fd4 ownerno oname (Transitive Dependency) fd5 clientno, rentstart propertyno, paddress, rentfinish, rent, ownerno, oname (Candidate key) fd6 propertyno, rentstart clientno, cname, rentfinish (Candidate key)

114 Client (clientno, cname) Rental (clientno, propertyno, rentstart, rentfinish) PropertyOwner (propertyno, paddress, rent, ownerno, oname) 2NF ClientRental relation After removing the partial dependencies, the creation of the three new relations called Client, Rental, and PropertyOwner Client ClientNo cname CR76 John Kay CR56 Aline Stewart PropertyOwner Rental ClientNo propertyno rentstart rentfinish CR76 PG4 1-Jul Aug-01 CR76 PG16 1-Sep-02 1-Sep-02 CR56 PG4 1-Sep Jun-00 CR56 PG36 10-Oct-00 1-Dec-01 CR56 PG16 1-Nov-02 1-Aug-03 propertyno paddress rent ownerno oname PG4 6 lawrence St,Glasgow 350 CO40 Tina Murphy PG16 5 Novar Dr, Glasgow 450 CO93 Tony Shaw PG36 2 Manor Rd, Glasgow 370 CO93 Tony Shaw Figure 6 2NF ClientRental relation

115 Third Normal Form (3NF) Transitive dependency A condition where A, B, and C are attributes of a relation such that if A B and B C, then C is transitively dependent on A via B (provided that A is not functionally dependent on B or C). Third normal form (3NF) A relation that is in first and second normal form, and in which no non-primary-key attribute is transitivelydependent on the primary key. The normalization of 2NF relations to 3NF involves the removal of transitive dependencies by placing the attribute(s) in a new relation along with a copy of the determinant.

116 3NF ClientRental relation The functional dependencies for the Client, Rentaland PropertyOwner relations are as follows: Client fd2 clientno cname (Primary Key) Rental fd1 clientno, propertyno rentstart, rentfinish (Primary Key) fd5 clientno, rentstart propertyno, rentfinish (Candidate key) fd6 propertyno, rentstart clientno, rentfinish (Candidate key) PropertyOwner fd3 propertyno paddress, rent, ownerno, oname (Primary Key) fd4 ownerno oname (Transitive Dependency)

117 3NF ClientRental relation The resulting 3NF relations have the forms: Client (clientno, cname) Rental (clientno, propertyno, rentstart, rentfinish) PropertyOwner (propertyno, paddress, rent, ownerno) Owner (ownerno, oname)

118 3NF ClientRental relation Client ClientNo CR76 CR56 cname John Kay Aline Stewart Rental ClientNo propertyno rentstart rentfinish CR76 PG4 1-Jul Aug-01 CR76 PG16 1-Sep-02 1-Sep-02 CR56 PG4 1-Sep Jun-00 CR56 PG36 10-Oct-00 1-Dec-01 CR56 PG16 1-Nov-02 1-Aug-03 PropertyOwner Owner propertyno paddress rent ownerno PG4 6 lawrence St,Glasgow 350 CO40 PG16 5 Novar Dr, Glasgow 450 CO93 PG36 2 Manor Rd, Glasgow 370 CO93 ownerno CO40 CO93 oname Tina Murphy Tony Shaw Figure 7 2NF ClientRental relation

119 Boyce-Codd Normal Form (BCNF) Boyce-Codd normal form (BCNF) A relation is in BCNF, if and only if, every determinant is a candidate key. The difference between 3NF and BCNFis that for a functional dependency A B, 3NF allows this dependency in a relation if B is a primary-key attribute and A is not a candidate key, whereas BCNF insists that for this dependency to remain in a relation, A must be a candidate key.

120 Example of BCNF fd1 clientno, interviewdate interviewtime, staffno, roomno (Primary Key) fd2 staffno, interviewdate, interviewtime clientno (Candidate key) fd3 roomno, interviewdate, interviewtime clientno, staffno (Candidate key) fd4 staffno, interviewdate roomno (not a candidate key) As a consequece the ClientInterview relation may suffer from update anmalies. For example, two tuples have to be updated if the roomno need be changed for staffno SG5 on the 13-May-02. ClientInterview ClientNo interviewdate interviewtime staffno roomno CR76 13-May SG5 G101 CR76 13-May SG5 G101 CR74 13-May SG37 G102 CR56 1-Jul SG5 G102 Figure 8 ClientInterview relation

121 Example of BCNF(2) To transform the ClientInterview relation to BCNF, we must remove the violating functional dependency by creating two new relations called Interview and SatffRoom as shown below, Interview (clientno, interviewdate, interviewtime, staffno) StaffRoom(staffNo, interviewdate, roomno) Interview ClientNo interviewdate interviewtime staffno CR76 13-May SG5 CR76 13-May SG5 CR74 13-May SG37 CR56 1-Jul SG5 StaffRoom staffno interviewdate roomno SG5 13-May-02 G101 SG37 13-May-02 G102 SG5 1-Jul-02 G102 Figure 9 BCNF Interview and StaffRoom relations

122 Fourth Normal Form (4NF) Multi-valued dependency (MVD) represents a dependency between attributes (for example, A, B and C) in a relation, such that for each value of A there is a set of values for B and a set of value for C. However, the set of values for B and C are independent of each other. A multi-valued dependency can be further defined as being trivial or nontrivial.a MVD A > B in relation R is defined as being trivial if B is a subset of A or A U B = R A MVD is defined as being nontrivial if neither of the above two conditions is satisfied.

123 Fourth Normal Form (4NF) Fourth normal form (4NF) A relation that is in Boyce-Codd normal form and contains no nontrivial multi-valued dependencies.

124 Fifth Normal Form (5NF) Fifth normal form (5NF) A relation that has no join dependency. Lossless-join dependency A property of decomposition, which ensures that no spurious tuples are generated when relations are reunited through a natural join operation. Join dependency Describes a type of dependency. For example, for a relation R with subsets of the attributes of R denoted as A, B,, Z, a relation R satisfies a join dependency if, and only if, every legal value of R is equal to the join of its projections on A, B,, Z.

125 MySQL DDL : Create, Alter,Drop,Truncate DML:Insert,update,delect DCL:grant,revoke TCL:commit,rollback Select View : Temporary Table Refer : Ref.Database Concepts by Korth

126 View A database view is known as a virtual table that allows you to query the data in it. Understanding database view and using it correctly are very important A database view allows you to simplify complex queries A database view helps limit data access to specific users. A database view provides extra security layer A database view enables computed columns CREATE VIEW view_name AS SELECT column1, column2... FROM table_name WHERE [condition]; Ref.Database Concepts by Korth

127 Index A database index is a data structure that improves the speed of operations on a table. Indexes can be created using one or more columns, providing the basis for both rapid random scan on table for data retrieval and efficient ordering of access to records. Queries based on Indexed colums gets executed faster. Practically, indexes are also type of tables, which keep primary key or index field and a pointer to each record into the actual table. Index are created for columns with primary keys, unique keys. You can use one or more columns to create an index. For example, we can create an index on tutorials_tbl using tutorial_author. Example of Explicit Unique index creation CREATE UNIQUE INDEX index_name ON table_name( column1, column2,...); Ref.Database Concepts by Korth

128 Reading. DataBaseConcepts by Korth: MySQL:: Ref.Database Concepts by Korth