Review Applications of Database Systems

Slides:



Advertisements
Similar presentations
Defined by Edgar Codd in 1970 Defined by Edgar Codd in 1970 Considered ingenious but impractical Considered ingenious but impractical Conceptually simple.
Advertisements

Relational Database. Relational database: a set of relations Relation: made up of 2 parts: − Schema : specifies the name of relations, plus name and type.
OUTLINE OF THE LECTURE PART I GOAL: Understand the Data Definition Statements in Fig 4.1 Step1: Columns of the Tables and Data types. Step2: Single column.
Overview Begin 6:00 Quiz15 mins6:15 Review Table Terms25 mins6:40 Short Break10 mins6:50 SQL: Creating Tables60 mins7:50 Break10 mins8:00 Lab – Creating.
Review Applications of Database Systems Applications of Database Systems Theory Practice.
Exploring Microsoft Access 2003 Chapter 4 Proficiency: Relational Databases, External Data, Charts, Pivot, and the Switchboard.
Normalization Normalization We discuss four normal forms: first, second, third, and Boyce-Codd normal forms 1NF, 2NF, 3NF, and BCNF Normalization.
Review Database Application Development Access Database Development ER-diagram Forms Reports Queries.
1 Chapter 2 Reviewing Tables and Queries. 2 Chapter Objectives Identify the steps required to develop an Access application Specify the characteristics.
NORMALIZATION N. HARIKA (CSC).
11 Chapter 10 Customizing a Database with Macros and Visual Basic for Applications Exploring Microsoft Office Access 2007.
Review: Application of Database Systems
Instructor: Churee Techawut Basic Concepts of Relational Database Chapter 5 CS (204)321 Database System I.
Designing a Database (Part I) -Identify all fields needed to produce the required information -Group related fields into tables -Determine Each Table’s.
CS 405G: Introduction to Database Systems 18. Normal Forms and Normalization.
SQL Structured Query Language Programming Course.
Using Microsoft Access 56:150 Information System Design.
Riyadh Philanthropic Society For Science Prince Sultan College For Woman Dept. of Computer & Information Sciences CS 340 Introduction to Database Systems.
Logical Design database design. Dr. Mohamed Osman Hegaz2 Conceptual Database Designing –Provides concepts that are close to the way many users perceive.
Normalization Sept. 2012ACS-3902 Yangjun Chen1 Outline: Normalization Chapter 14 – 3rd ed. (Chap. 10 – 4 th, 5 th ed.; Chap. 6, 6 th ed.) Redundant information.
Introduction to a Database Defining a database Database window in Access The six items in window: Tables, Queries Forms, Reports, Macros, Modules.
Review Database Application Development Access Database Development Theory Practice.
Logical Database Design and the Relational Model.
Mapping ER Diagrams to Tables
Database Design Theory CS405G: Introduction to Database Systems Jinze Liu 3/15/20161.
Constraints and Views Chap. 3-5 continued (7 th ed. 5-7)
COP 6726: New Directions in Database Systems
The SQL Database Grammar
Functional Dependency and Normalization
Introduction to the database systems (1)
RELATION.
Chapter 5: Logical Database Design and the Relational Model
Database Design The Relational Model Text Ch5
Quiz Questions Q.1 An entity set that does not have sufficient attributes to form a primary key is a (A) strong entity set. (B) weak entity set. (C) simple.
CIS 155 Table Relationship
Relational Database Design by ER- and EER-to-Relational Mapping
Relational Database Design by ER- and EERR-to-Relational Mapping
Chapter (9) ER and EER-to-Relational Mapping, and other Relational Languages Objectives How a relational database schema can be created from a conceptual.
Chapter (9) ER and EER-to-Relational Mapping, and other Relational Languages Objectives How a relational database schema can be created from a conceptual.
376a. Database Design Dept. of Computer Science Vassar College
Translation of ER-diagram into Relational Schema
Mapping ER Diagrams to Tables
Outline: Relational Data Model
Relational Database.
Company Requirements.
Normalization There is a sequence to normal forms:
CS4222 Principles of Database System
Foreign key (FK) is defined as follows:
Review: ACCESS Database Systems
Relational Database Design by ER- and EER-to-Relational Mapping
Normalization Normalization
Outline: Normalization
Answer:  Select queries Parameter queries Cross Tab queries
Relational Database Design by ER- and EER-to-Relational Mapping
Foreign key (FK) is defined as follows:
Review: Application of Database Systems
Normalization February 28, 2019 DB:Normalization.
Relational Database Design
Database Design: Relational Model
1. Explain the following concepts: (a) superkey (b) key
1.(5) Describe the working process with a database system.
ISC321 Database Systems I Chapter 4: SQL: Data definition, Constraints, and Basic Queries and Updates Fall 2015 Dr. Abdullah Almutairi.
Mapping an ERD to a Relational Database
Database Design Theory CS405G: Introduction to Database Systems
1. Explain the following concepts of the ER data model:
Chapter (7) ER-to-Relational Mapping, and other Relational Languages
Mapping an ERD to a Relational Database
Chapter 2 Design Table and Form.
Database Normalization
Chapter 2 Design Table and Form.
Presentation transcript:

Review Applications of Database Systems Theory Applications of Database Systems Practice

ER-diagram Relational databases: Theory Part Referential integrity 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. Example: FK Employee(SSN, …, Dno) Dept(Dno, … )

Relationships Window ConsultantID is primary key in Consultant table Relationship line ConsultantID is foreign key in Clients table

You cannot delete a Consultant without first deleting related Clients Delete Record button Click + to display related 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 Employee 123456789 ssn ... delete Works-on Essn Pno 123456789 5 ... delete

cascade – a strategy to enforce referential integrity Employee delete ssn supervisor ... ... 123456789 234589710 null Employee ssn supervisor ... ... 123456789 234589710 null not reasonable delete delete

This violates the entity constraint. Works-on Modify (cascade updating) – a strategy to enforce referential integrity 123456789 ssn ... Employee Essn Pno 5 delete null This violates the entity constraint. Works-on

Modify (cascade updating) – a strategy to enforce referential integrity Employee 123456789 ssn ... delete Department 123456789 Dno ... 5 chairman Department null Dno ... 5 chairman 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

If EmpNum is the PK then the FDs: EmpNum  EmpEmail EmpNum  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

InvNum LineNum ProdNum Qty InvNum InvDate 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 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.

{student_no, course_no}  instr_no instr_no  course_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_no instr_no  course_no since we have instr_no  course-no, but instr_no is not a Candidate key.

course_no instr_no student_no BCNF {student_no, instr_no}  student_no {student_no, instr_no}  instr_no instr_no  course_no

Tables Forms Reports Practice Part Queries Macros not covered VBA modules

Tables - table name - attribute name - attribute data type - attribute properties - Primary key - Foreign key

Data Types of Fields Attachment    Files, such as digital photos. Multiple files can be attached per record. This data type is not available in earlier versions of Access. AutoNumber    Numbers that are automatically generated for each record. Currency    Monetary values. Date/Time    Dates and times. Hyperlink    Hyperlinks, such as URL addresses. Memo    Long blocks of text and text that use text formatting. A typical use of a Memo field would be a detailed product description. Number    Numeric values, such as distances. Note that there is a separate data type for currency. OLE Object    OLE objects (OLE object: An object supporting the OLE protocol for object linking and embedding. Text    Short, alphanumeric values, such as a last name or a street address. Yes/No    Boolean values.

Properties Field size- Adjusts the size of the text field Format- changes the way field is displayed. Does not effect the value. Input Mask- facilitates data entry Caption- Label used for the field Default Value- the automatically entered value Validation Rule- Rejects records that do not conform to rules entered. Validation Text- Error returned when validation rule is broken. Required- Forces user to enter in value if selected. Allow Zero Length- Allows text length of 0. Indexed- increases efficiency of search on the field

Examples for Format property Format property for Number data type: #,###.##;(#,###.##)[Red];0,000.00;“Undefined” format for positive number format for 0 format for null-value format for negative number 6,789.77

Examples for Input Mask property Input mask for Text data type: !\(999") "000\-0000;0;_ e.g. (204) 888-1234 >!“FJ”-AA\-00000 e.g. FJ-EA-12048 Input mask for Time data type 99:00:00\ >LL;0;_ e.g. 05:56:00 PM

Forms different components: - bound controls - unbound controls - calculated controls - drop-down list box (combo 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 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

Query design grid

SQL statement Select FirstName, LastName From Employees Where Salary > 40000

Structured Query Language SELECT Orders.CustomerID, Orders.EmployeeID, Orders.OrderDate, Orders.Freight FROM Orders WHERE (((Orders.OrderDate)>#3/25/2010#)) OR (((Orders.EmployeeID)<7));

Structured Query Language SELECT Orders.CustomerID, Orders.EmployeeID, Orders.OrderDate, Orders.Freight, [Order Details].Quantity FROM Orders INNER JOIN [Order Details] ON Orders.OrderID = [Order Details].OrderID WHERE (((Orders.OrderDate)>#3/25/2010#) AND (([Order Details].Quantity)>7)) OR (((Orders.EmployeeID)<7));

Relationships a many-to-many relationship is created by generating two one-to-many relationships.

Macros

Macro groups

VBA modules

Private Sub cmdHistoryForm_Click() 'Display the form DoCmd.OpenForm("Employee"), , , , acFormEdit End Sub Private Sub cmdEmployeeForm_Click() DoCmd.OpenForm("History"), , , , acReadOnly Private Sub cmdExit_Click() 'Exit the application intResponse = MsgBox("Do you want to exit the Compensation" & _ "application?", vbYesNo + vbCritical, "Exit Application?") If intResponse = vbYes Then Application.Quit acQuitPrompt End If

Private Sub cmdSummaryReport_Click() 'This procedure defines an SQL query as the record source 'for the "Retirement Summary" report; the SQL statement 'returns all records 'Assign the report name to the strObjectName variable strObjectName = "Retirement Summary" 'Declare a variable to store the SQL statement, define the 'SQL string strSQL = "SELECT Employee.LastName, Employee.FirstName, " & _ "Office.Region, Contribution.PayDate," & _ "Contribution.[401KEmployee], " & _ "Contribution.[401KMatch], Contribution.[401KTotal], " & _ "FROM (Office INNER JOIN Employee ON Office.[OfficeNumber] = " & _ "Employee.[OfficeLocation])" & _ "INNER JOIN Contribution ON Employee.[SSN] = Contribution.[SSN];"