540 likes | 661 Views
Review Applications of Database Systems. Theory. Applications of Database Systems. Practice. ER-diagram. Referential integrity. Theory Part. Relation normalization. ER-diagram. Entity types Strong entity type Weak entity type Attributes atomic attributes composite attributes
E N D
ReviewApplications of Database Systems Theory Applications of Database Systems Practice
ER-diagram Referential integrity Theory Part Relation normalization
ER-diagram Entity types Strong entity type Weak entity type Attributes atomic attributes composite attributes single-valued attributes multi-valued attributes Relationships Cardinality constraints Participation constraints Identifying relationship, recursive relationship
Mapping from ER-diagrams onto relational schemas • Create a relation for each strong entity type • Create a relation for each weak entity type • 3. For each binary 1:1 relationship choose an entity and include the • other’s PK in it as an FK • 4. For each binary 1:n relationship, choose the n-side entity and include • an FK with respect to the other entity. • 5. For each binary M:N relationship, create a relation for the relationship • 6. For each multi-valued attribute create a new relation • 7. For each n-ary relationship, create a relation for the relationship
Referential Integrity • (i) Consider two relation schemas R1 and R2; • The attributes in FK (foreign key) in R1 have the same domain(s) as the primary key attributes PK (primary key) in R2; the attributes FK are said to reference or refer to the relation R2. • iii) A value of FK in a tuple (record) t1 of the current state r(R1) either occurs as a value of PK for some tuple t2 in the current state r(R2) or is null. In the former case, we have t1[FK] = t2[PK], and we say that the tuple t1 references or refers to the tuple t2. FK Example: Employee(SSN, …, Dno) Dept(Dno, … )
Relationships Window ConsultantID is primary key in Consultant table Relationship line ConsultantID is foreign key in Clients table
Delete Record button Click + to display related records You cannot delete a Consultant without first deleting related Clients
EMPLOYEE fname, minit, lname, ssn, bdate, address, sex, salary, superssn, dno DEPARTMENT Dname, dnumber, mgrssn, mgrstartdate Dnumber, dlocation PROJECT DEPT _LOCATIONS Pname, pnumber, plocation, dnum WORKS_ON Essn, pno, hours DEPENDENT Essn, dependentname, sex, bdate, relationship
Updating and constraints • delete • Delete the WORK_ON tuple with Essn = ‘999887777’ and pno = 10. • When deleting, the referential constraint will be checked. • - The following deletion is not acceptable: • Delete the EMPLOYEE tuple with ssn = ‘999887777’ • - reject, cascade, modify
... ssn 123456789 ... delete delete Essn Pno 123456789 5 ... ... Cascade deletion – a strategy to enforce referential integrity Employee Works-on
Employee delete delete delete ... ... ... ... ssn ssn supervisor supervisor 234589710 234589710 123456789 123456789 ... ... ... ... null null 234589710 234589710 cascade – a strategy to enforce referential integrity Employee not reasonable
Modify (cascade updating) – a strategy to enforce referential integrity ... ssn Employee 123456789 ... delete Works-on Works-on Essn Pno Essn Pno 5 null 123456789 5 ... ... ... ... This violates the entity constraint.
... ssn 123456789 ... Department Department ... ... Dno chairman Dno chairman null 5 123456789 5 ... ... Modify (cascade updating) – a strategy to enforce referential integrity Employee delete This does not violate the entity constraint.
Normalization • We discuss four normal forms: first, second, third, and Boyce-Codd normal forms • 1NF, 2NF, 3NF, and BCNF • Normalization is a process that “improves” a database design by generating relations that are of higher normal forms. • The objective of normalization: • “to create relations where every dependency is on the key, the whole key, and nothing but the key”.
Functional Dependencies • We say an attribute, B, has a functional dependency on another attribute, A, if for any two records, which have • the same value for A, then the values for B in these two records must be the same. We illustrate this as: • A B • Example: Suppose we keep track of employee email addresses, and we only track one email address for each employee . Suppose each employee is identified by their unique employee number. We say there is a functional dependency of email address on employee number: • employee number email address
EmpNum EmpEmail EmpFname EmpLname 123 jdoe@abc.com John Doe 456 psmith@abc.com Peter Smith 555 alee1@abc.com Alan Lee 633 pdoe@abc.com Peter Doe 787 alee2@abc.com Alan Lee If EmpNum is the PK then the FDs: EmpNum EmpEmail EmpNum EmpFname EmpNum EmpLname must exist.
Transitive dependency Consider attributes A, B, and C, and where A B and B C. Functional dependencies are transitive, which means that we also have the functional dependency A C We say that C is transitively dependent on A through B.
EmpNum DeptNum EmpNum EmpEmail DeptNum DeptNname DeptNum DeptName EmpNum EmpEmail DeptNum DeptNname • DeptName is transitively dependent on EmpNum via DeptNum • EmpNum DeptName
A partial dependency exists when an attribute B is functionally dependent on an attribute A, and A is a component of a multipart candidate key. InvNum LineNum Qty InvDate Candidate keys: {InvNum, LineNum} InvDate is partially dependent on {InvNum, LineNum} as InvNum is a determinant of InvDate and InvNum is part of a candidate key
First Normal Form We say a relation is in 1NF if all values stored in the relation are single-valued and atomic. 1NF places restrictions on the structure of relations. Values must be simple.
Boyce-Codd Normal Form • BCNF is defined very simply: • a relation is in BCNF if it is in 1NF and if every determinant is a candidate key. InvNum LineNum ProdNum Qty InvNum, LineNum ProdNum {InvNum, LineNum} and {InvNum, ProdNum} are the two candidate keys. Qty InvNum, ProdNum LineNum
Second Normal Form • A relation is in 2NF if it is in 1NF, and every non-key attribute is fully dependent on each candidate key. • 2NF (and 3NF) both involve the concepts of key and non-key attributes. • A key attribute is any attribute that is part of a key; any attribute that is not a key attribute, is a non-key attribute. • Relations that are not in BCNF have data redundancies • A relation in 2NF will not have any partial dependencies
Consider this InvLine table (in 1NF): InvNum LineNum ProdNum Qty InvDate InvNum, LineNum ProdNum There are two candidate keys. Qty InvNum, ProdNum LineNum Qty is the only non-key attribute, and it is dependent on InvNum InvNum InvDate Since there is a determinant that is not a candidate key, InvLine is not BCNF InvLine is not 2NF since there is a partial dependency of InvDate on InvNum InvLine is only in 1NF
EmployeeDept ename ssn bdate address dnumber dname inv_no line_no prod_no prod_desc qty InvNum LineNum ProdNum Qty InvNum InvDate
Third Normal Form a relation is in 3NF if the relation is in 1NF and all determinants of non-key attributes are candidate keys That is, for any functional dependency: X Y, where Y is a non-key attribute (or a set of non-key attributes), X is a candidate key. this definition of 3NF differs from BCNF only in the specification of non-key attributes - 3NF is weaker than BCNF. (BCNF requires all determinants to be candidate keys.) A relation in 3NF will not have any transitive dependencies
EmpNum EmpName DeptNum DeptName We correct the situation by decomposing the original relation into two 3NF relations. Note the decomposition is lossless. DeptNum DeptName EmpNum EmpName DeptNum
In 3NF, but not in BCNF: Instructor teaches one course only. student_no course_no instr_no Student takes a course and has one instructor. {student_no, course_no} instr_no instr_no course_no since we have instr_no course-no, but instr_no is not a Candidate key.
student_no course_no instr_no BCNF student_no instr_no course_no instr_no {student_no, instr_no} student_no {student_no, instr_no} instr_no instr_no course_no
Tables Forms Reports Practice Part Queries Macros VBA modules
Tables • - table name • - attribute name • - attribute data type • - attribute properties • - key
Forms • different components: • - bound controls • - unbound controls • - calculated controls • - drop-down list box (combo box) • - check box • - option group • - command buttons
Switchboard is a special form created using Switchboard manager (not covered)
Reports • seven sections: • - report header • - page header • - group header • - details • - group footer • - page footer • - report footer
Queries • different kinds of queries: • - select queries • - action queries • Make-Table query, Delete-Table query • Append-Table query, Update query • parameter query, unmatched query, find-duplicates query • - Crosstab query • - total queries • Group by • Aggregate functions: • Count, sum, maximum, minimum, Average
Queries - unmatched queries
SQL statement Select FirstName, LastName From Employees Where Salary > 40000
Relationships a many-to-many relationship is created by generating two one-to-many relationships.