ReviewDatabase Application Development

Access DatabaseDevelopment

Theory

Practice

Theory Part

ER-diagram

Referential integrity

Relation normalization

•ER-diagram

Entity typesStrong entity typeWeak entity type

Attributesatomic attributescomposite attributessingle-valued attributesmulti-valued attributes

RelationshipsCardinality constraintsParticipation constraintsIdentifying relationship, recursive relationship

Mapping from ER-diagrams onto relational schemas

1. Create a relation for each strong entity type

2. 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;

ii) 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.Example:

Employee(SSN, …, Dno) Dept(Dno, … )

FK

Relationships Window

ConsultantID is primarykey in Consultant table

Relationship line

ConsultantID is foreignkey in Clients table

Delete Record button

Click + to displayrelated records

You cannot delete a Consultant without first deleting related Clients

fname, minit, lname, ssn, bdate, address, sex, salary, superssn, dno

Dname, dnumber, mgrssn, mgrstartdate

Dnumber, dlocation

Pname, pnumber, plocation, dnum

Essn, pno, hours

Essn, dependentname, sex, bdate, relationship

EMPLOYEE

DEPARTMENT

DEPT _LOCATIONS

WORKS_ON

PROJECT

DEPENDENT

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

Cascade deletion – a strategy to enforce referential integrity

ssn

Employee

Essn Pno

delete

Works-on

delete

cascade – a strategy to enforce referential integrity

Employee

delete

ssn supervisor

null

Employee

delete

ssn supervisor

null

delete

not reasonable

Modify (cascade updating) – a strategy to enforce referential integrity

ssn

Employee

Essn Pno

delete

Essn Pnonull

This violates the entity constraint.

Works-on Works-on

Modify (cascade updating) – a strategy to enforce referentialintegrity

ssn

Employee

delete

This does not violate the entity constraint.

Department

Dno

chairman

Department

null

Dno

chairman

•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 havethe same value for A, then the values for B in these two records must be the same. We illustrate this as:

A BExample: 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 EmpLname123 jdoe@abc.com John Doe456 psmith@abc.com Peter Smith555 alee1@abc.com Alan Lee633 pdoe@abc.com Peter Doe787 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 EmpEmail DeptNum DeptNname

EmpNum EmpEmail DeptNum DeptNname

DeptName is transitively dependent on EmpNum via DeptNumEmpNum DeptName

EmpNum DeptNum

DeptNum 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.

LineNum ProdNum QtyInvNum

InvNum, LineNum ProdNum

InvNum, ProdNum LineNum

Qty{InvNum, LineNum} and {InvNum, ProdNum} are the two candidate keys.

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

LineNum ProdNum QtyInvNum

InvNum, LineNum ProdNum

InvNum, ProdNum LineNum

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

Qty

InvDate

InvDateInvNum

There are two candidate keys.

Qty is the only non-key attribute, and it is dependent on InvNum

InvLine is only in 1NF

Consider this InvLine table (in 1NF):

LineNum ProdNum QtyInvNum

InvDateInvNum

inv_no line_no prod_no prod_desc qty

EmployeeDept

ename ssn bdate address dnumber dname

Third Normal Form

a relation is in 3NF if the relation is in 1NF and all determinants of non-key attributes are candidate keysThat 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.

EmpNum EmpName DeptNum DeptNameDeptNum

student_no course_no instr_no

Instructor teaches one course only.

Student takes a course and has one instructor.

In 3NF, but not in BCNF:

{student_no, course_no} instr_noinstr_no course_no

since we have instr_no course-no, but instr_no is not aCandidate key.

course_no instr_no

student_no instr_no

student_no course_no instr_no

BCNF

{student_no, instr_no} student_no{student_no, instr_no} instr_noinstr_no course_no

Practice Part

Forms

Reports

Queries

Macros

Tables

Pages

Modules

•Tables

- table name- attribute name- attribute data type- attribute properties- key

•Formsdifferent components:

- bound controls- unbound controls- calculated controls- drop-down list box- check box- option group- command buttons

Subforms

Subforms are generated using Wizard

Subsubforms

Subforms are generated using Subform/Subreport button

Switchboard is a special form created using Switchboardmanager

•Reportsseven sections:

- report header- page header- group header- details- group footer- page footer- report footer

•Queriesdifferent kinds of queries:

- select queries- action queries

Make-Table queryDelete-Table queryAppend-Table queryUpdate query

- Crosstab query- total queries

Group byAggregate functions:Count, sum, maximum, minimum, Average

Queries- unmatched queries

Query design grid

SQL statement

Select FirstName, LastName From EmployeesWhere Salary > 40000

Relationshipsa many-to-many relationship is created by generating twoone-to-many relationships.

•macros

•Macro groups