ADBMS Lectures 1-5

What is a Database?
A collection of data or information about realworld entities such as objects or events. A collection of related records held over a period of time in a computer-readable form. A shared, integrated, computer structure that stores a collection of Data, that is raw facts of interest to the user.
Monday, September 03, 2012
Advanced DBMS
Applications of Databases
the preferred method of storage for large multi-user applications, where coordination between many users is needed information systems. many electronic mail programs and personal organizers are based on standard database technology. Software database drivers are available for most database platforms so that application software can use a common Application Programming Interface to retrieve the information stored in a database.
Advanced DBMS
What is a DBMS?
A computer software designed for the purpose of managing databases. A software program that manages the storage of and access to data in databases. is a complex set of software programs that controls the organization, storage, management, and retrieval of data in a database
Monday, September 03, 2012 Advanced DBMS 3
Role/Advantages of DBMS
Improved data sharing Better data integration Minimized data inconsistency Improved data access Improved decision making Increase end-user productivity
Advanced DBMS
Typical DBMSs
Apache Derby (Sun Java DB) BerkeleyDB dBase IBM DB2 Informix Ingres Microsoft Access Microsoft SQL Server (derived from Sybase) MySQL Oracle Database Paradox (database) PostgreSQL Sybase Visual FoxPro
Advanced DBMS 5
Components of a DBMS
Modeling language
defines the schema of each database hosted in the DBMS, according to the DBMS data model.
Data structure (fields, records, files and objects)

optimized to deal with very large amounts of data stored on a permanent data storage device
Advanced DBMS
Components of a DBMS
Database query language
allow users to interactively interrogate the database, analyze its data and update it according to the user privileges on data
Transaction mechanism
would guarantee the ACID properties, in order to ensure data integrity, despite concurrent user access and faults
Database Management System

found at the heart of most database applications DBMS accepts requests for data from the application program and instructs the OS to transfer the appropriate data When a DBMS is used, information systems can be changed much more easily as the organization's information requirements change
Database Management System cont.

Database servers are specially designed computers that hold the actual databases and run only the DBMS and related software. Database servers are usually multiprocessor computers, with RAID disk arrays used for stable storage.
Advanced DBMS
Database System Environment
Advanced DBMS
10
DBMS Architecture : 3 Schema

END USERS External Level logical data independence CONCEPTUAL SCHEMA Conceptual Level physical data independence INTERNAL SCHEMA Internal Level Objective: STORED DATABASE To provide data independence
Advanced DBMS
11
DBMS Architecture: 3 Schema

External Level
Users view of the database
Conceptual Level
The community view of the database Describes what is stored in the DB & the relationships among the data
Internal Level
The physical representation of the database in the computer Describes how the data is stored in the DB
Data Independence
Upper levels are unaffected by changes to lower levels Logical Data Independence
Being able to make changes on the conceptual schema without any on the external schema.
Physical Data Independence

Being able to make changes on the internal schema without any on the conceptual or external schemas
Classification/Types of DBMSs
Accdg. to Data model
Hierarchical, network, relational
Accdg. to # of users
Single-user, multi-user
Accdg. to # of sites
Centralized, distributed
Accdg. to purpose
General, special purpose
Database Design
Refers to the activities that focus on the design of the database structure that will be used to store and manage end-user data What is a good database?
Meets all the requirements Must be designed carefully A well-designed database facilitates data management and generates accurate and valuable information.
Data Model
An abstraction of a more complex real-world object or event Help you understand the complexities of realworld environment Represents data structures and their characteristics, relations, constraints, and transformations Facilitates interaction among the designer, the applications programmer, and the end-user.
Data Models
Defines a method for data organization It specifies relationships and integrity rules in databases DBMSs can be based on a data model
Hierarchical Network Relational
Advanced DBMS
17
Hierarchical Model
data is organized into a tree-like structure Every entity has one to two immediate neighbors superior or subordinate. Restrictions:
Branches can only diverge & are not allowed to converge.
A child element can be related to only one parent.
Prevents any entity from being related to any entity more than one level up the hierarchy.
Hierarchical Model: An Example

Company
Automobile
Aerospace
Sales
MIS
Marketing
Research
HR
MIS
Ann Lane
Joe Smith
Bob Lee
Laura Kline
Advanced DBMS
19
Network Model
Derived from the hierarchical model Basic structure of superior and subordinate retained Difference:
Allows child entity to have more than one parent Allows a child to be connected directly to a grandparent element
Advanced DBMS
20
Network Model: An Example

Company
Automobile
Aerospace
Sales
MIS
Marketing
Research
HR
MIS
Ann Lane
Joe Smith
Bob Lee
Laura Kline
Advanced DBMS
21
Relational Model
Rooted in 2 branches of mathematics:
Set theory properties of sets Predicate calculus mathematical proposition
permits the database designer to create a consistent, logical representation of information All data about entities are contained in tables Any table can be reference other tables through the use of keys & relationships
Relational Data Model

COMP 208 Database Management System 1
Relational Database
originally defined and coined by E.F. Codd a database that conforms to the relational model, and refers to a database's data and schema (the database's structure of how that data is arranged). a set of relations or a database built in an RDBMS (Relational DBMS) a relational database is a collection of relations (frequently called tables)
Relational DBMS
a system that manages data using the relational model the term "RDBMS" is inaccurately used as a generic label for the relational database concept examples: MySQL, PostgreSQL, Oracle, Microsoft SQL Server, Ingres etc.
Advanced DBMS
25
Components of Relational Database

Relations/tables Keys Relationships
Advanced DBMS
26
Relation
a set of tuples (record) that all have the same attributes
Attribute property of an entity/relationship
is usually represented by a table, which is data organized in rows & columns all of the data stored in a column should be in the same domain
Domain-set of possible values for a given attribute
Relation: An Example
SSN LastName FirstName Address Ola Tove Kari Timoteivn 10 Borgvn 23 Storgt 20 City Sandnes Sandnes Stavanger 123456 Hansen 789012 Svendson 345678 Pettersen
Advanced DBMS
28
Keys
a kind of constraint which requires that the object, or critical information about the object, isn't duplicated A set of one or more attribute
Candidate key-all attributes with unique value Primary key-chosen key Simple key-only one attribute Composite key-made up of two or more attributes Foreign key-an attribute used to reference a primary key in a another table/relation
Key: An Example
Key: primary key
SSN LastName FirstName Address City
123456 Hansen
789012 Svendson 345678 Pettersen
Ola
Tove Kari
Timoteivn 10
Borgvn 23 Storgt 20
Sandnes
Sandnes Stavanger
Advanced DBMS
30
Relationships
An association of entities where the association includes one entity from each participating entity type Example:
borrower employee product
Borrows/returns
material department
belongs/employs
sold/bought
customer
Advanced DBMS
31
Entity-Relationship Data Model:

A conceptual data model
MITF 202 Advanced Database Systems Mr. Alvin R. Malicdem Professor
ADBS
32
The Conceptual Data Model

A set of concepts that describe the structure of the database and the associated retrieval and update transactions on the database The aim is to describe the information used by an organization in a way which is not governed by implementation-level issues and details.
ADBS
33
The Entity-Relationship Data Model

A high-level conceptual data model developed by Peter Chen (1976) to facilitate database design Support users perception of data, and to conceal the more technical aspects associated with database design It is independent of the particular DBMS and hardware platform that is used to implement the database
Monday, September 03, 2012 ADBS 34
The Entity-Relationship Data Model

A common method of analysis involves identifying:
the ENTITIES (persons, places, things etc.) which the organization has to deal with objects/events. the ATTRIBUTES - the items of information which characterize and describe these entities. the RELATIONSHIPS between entities which exist and must be taken into account when processing information.
Entities
The basic object of the real world Defined by a set of attributes (properties) Uniquely identified by a primary key Classified with similar entities under one set Considered an instance of a given entity type Tangible or intangible
ADBS
36
Entities: An Example
Entity Type: Employee
Attributes
SSN
LastName
FirstName Address
City
123456 Hansen
789012 Svendson 345678 Pettersen
Ola
Tove Kari
Timoteivn 10
Borgvn 23 Storgt 20
Sandnes
Sandnes Stavanger
Tuples/records/entity set
ADBS
37
Entity Types
Weak Entity type
An entity type that is existence-dependent on some other entity type (do not have their own keys) Example: employee dependents
Strong Entity type

An entity type that is not existence-dependent on some other entity type
ADBS
38
Attributes
pieces of information ABOUT entities analysis must of course identify those which are actually relevant to the proposed application give rise to recorded items of data in the database
ADBS
39
Characteristics of an Attribute
attribute name. the domain from which attribute values are taken.
Set of allowable values of an attribute
whether the attribute is part of the entity identifier. whether it is permanent or time-varying. whether it is required or optional for the entity.
Types of Attributes
Simple single component with an independent existence Composite multiple components, each with an independent existence Single-valued holds a single value for a single entity Multi-valued holds multiple value for a single entity Derived attribute value is taken from a related attribute
Examples
Simple & single-valued Ex. gender, civil status
Simple & multi-valued
Ex. Phone #
Composite & singlevalued Composite & multivalued

Ex. name
Ex. address
ADBS
42
Relationships
An association of entities where the association includes one entity from each participating entity type should be named by a word or phrase which explains its function
ADBS
43
Relationships: Examples
borrower employee product
Borrows/returns
material department customer
belongs/employs
sold/bought
relationships
ADBS
44
Degree of a Relationship
The degree indicates the # of associated entities
Unary Relationship
Same entity participates more than one in different roles
Binary Relationship
Two different entities participate in the relationship
Ternary Relationship
Three different entities participate in the relationship
Examples
Unary Relationship Binary Relationship
STAFF
supervises
OWNER
owns
PROPERTY
STAFF
Ternary Relationship
RENTER
Sets up
INTERVIEW
ADBS
46
Mapping Cardinality
Expresses the number of entities to which another entity can be associated via a relationship set The number of participating entities in a relationship
ONE-TO-ONE, e.g. Building - Location, ONE-TO-MANY, e.g. hospital - patient, MANY-TO-MANY, e.g. Author - Book. RECURSIVE, e.g. Manager - Employee.
Entity Participation
A relationship may be required/mandatory or optional for either participant e.g. a piece of property must be owned by a person but not all persons need to own a piece of property.
ADBS
48
Sample Notations
ADBS
49
Simplified Notations for ER Modeling

Entity Type Weak Entity Type Relationship Type Attribute Multi-valued attribute derived attribute one many mandatory optional
ADBS
50
A Complete ER Diagram
deptid deptname
works for empid
DEPARTMENT
name
EMPLOYEE
address
manages
bdate projid works on
PROJECT
projname
hours
ADBS
51
Exercise
FastFlight Airlines is a small air carrier operating in three northeastern states. FastFlight is in the process of computerizing its passenger reservation system. The following data items have been identified: reservation code, flight number, flight date, origin, destination, departure time, arrival time, passenger name, seat number, reservation agent number and reservation agent name. For example, flight number 303, which is scheduled every Tuesday and Thursday, leaves Augusta, Maine, at 9:23am and arrives in Nashua, New Hampshire at 10:17am. You can assume that the FastFlight reservation system will detect automatically whether empty seats are available. Draw the Entity Relationship Diagram for this system.
ADBS
52
Transformation from ER to Relational Model

MITF 202 Advance Database Systems Alvin R. Malicdem Professor
Transformation
Involves the transformation of the ER diagram to a complete database scheme Entity set in the ER model become tables in a relational database The relationships become the source of foreign keys that integrate the resulting table together Based on the mapping cardinalities & entity participation of the relationship
9/3/2012 ADBS
Given
Let:
E1 and E2 be entity sets R be a relationship that associates E1 & E2
ER Diagram:
attrR pkE1 attrE1 attrE2 pkE2
E1
E2
9/3/2012
ADBS
Rule 1
many-to-many regardless of entity participation attrR
pkE1 attrE1
attrE2
pkE2
E1
E1(pkE1,attrE1) E2(pkE2,attrE2) R(pkE1,pkE2,attrR)
9/3/2012
E2
ADBS
Rule 2
One-to-many, mandatory on the many side regardless of entity participation on the 1 attrR side attrE2
pkE1 attrE1
pkE2
E1
E2
E1(pkE1,attrE1,pkE2,attrR) E2(pkE2,attrE2)
ADBS
9/3/2012
Rule 3
One-to-many, optional on the many side regardless of entity participation on the 1 side attrR
pkE1 attrE1 attrE2
pkE2
E1
E1(pkE1,attrE1)
E2(pkE2,attrE2) R(pkE1,pkE2,attrR)
9/3/2012
E2
ADBS
Rule 4
One-to-one, mandatory on both sides
E1
E2
E1(pkE1,attrE1,pkE2,attrR)
E1(pkE1,attrE1) or E2(pkE2,attrE2,pkE1,attrR)
E2(pkE2,attrE2)
9/3/2012
ADBS
Rule 5
One-to-one, mandatory on one side
E1
E2
E1(pkE1,attrE1,pkE2,attrR) E2(pkE2,attrE2)
9/3/2012
ADBS
Rule 6
Optional on both sides
E1
E2
E1(pkE1,attrE1) E2(pkE2,attrE2) R(pkE1,pkE2,attrR)
9/3/2012
ADBS
Weak Entity Rule

E1
E2
E1(pkE1,attrE1,attrR) E2(pkE2,attrE2,pkE1)
9/3/2012
ADBS
Multi-valued Attribute Rule

Transform a multi-valued attribute into a weak entity and follow the weak entity rule Ex:
EMPLOYEE ADDRESS
resides
9/3/2012
ADBS
Transform the ER Diagram into a Relational Schema

deptid deptname
works for empid
DEPARTMENT
name
EMPLOYEE
address
manages
bdate projid works on
PROJECT
projname hours
9/3/2012
ADBS
Two entities at a time

empid name projid
EMPLOYEE
address hours bdate
works on
PROJECT
projname
Apply Rule 1: many-to-many, regardless of entity participation
EMPLOYEE(empid,name,address,bdate) PROJECT(projid,projname) WORKS(empid,projid,hours)

9/3/2012 ADBS
Next
empid name deptid works for
EMPLOYEE
address
DEPARTMENT
deptname
bdate
Apply Rule 2: one-to-many, mandatory on the many side
EMPLOYEE(empid,name,address,bdate,deptid) DEPARTMENT(deptid,deptname)
9/3/2012
ADBS
And the last

empid name deptid
EMPLOYEE
address
manages
DEPARTMENT
deptname
bdate
Apply Rule 5: one-to-one, mandatory on the one side
EMPLOYEE(empid,name,address,bdate) DEPARTMENT(deptid,deptname,empid)
9/3/2012
ADBS
The Complete Relational Schema

EMPLOYEE(empid,name,address,bdate ,deptid) PROJECT(projid,projname)
DEPARTMENT(deptid,deptname,empid)
WORKS(empid,projid,hours)
9/3/2012
ADBS
Transformation & Foreign Key Issues

Referential integrity is a vital consideration in designing a database. Whenever a tuple in a referenced relation is deleted, the cascade rule should only be applied to the referencing tuples if there will be no undue loss of information
9/3/2012
ADBS
One-many: optional on both sides

EMPLOYEE
(empid,ename)
works
PROJECT
(projid,pname,startdate)
(assigndate)
If null values are not allowed in foreign keys:

EMPLOYEE(empid,ename) PROJECT(projid,pname,startdate) WORKS(empid,projid,assigndate)
FK: empid references EMPLOYEE DELETE restrict/cascade* projid references PROJECT DELETE cascade/restrict
9/3/2012
ADBS
Explanation
Due to the optionality of the relationship, the cascade rule is possible without any loss of important data. That is, whenever an employee is deleted from EMPLOYEE or a project is removed from PROJECT, the referencing tuples in WORKS can be deleted as well. NOTE: if the cascade rule is allowed, the restrict rule is also applicable.
9/3/2012 ADBS
One-many: optional on the many side, mandatory on the one side

EMPLOYEE
(empid,ename)
works
PROJECT
(assigndate)
If null values are not allowed in foreign keys:

EMPLOYEE(empid,ename) PROJECT(projid,pname,startdate) WORKS(empid,projid,assigndate)
FK: empid references EMPLOYEE DELETE cascade/restrict
projid references PROJECT DELETE cascade/restrict
9/3/2012
ADBS
Explanation
Cascade* indicates that the cascade rule maybe used as long as the interface for removing an employee incorporates a checking mechanism for determining whether that employee is the only person working for a particular project. Due to the optional participation of EMPLOYEE in the relationship WORKS, the cascade rule is allowed. However, the mandatory participation of PROJECT in the relationship requires that at least one employee working for it.
9/3/2012 ADBS
One-many: mandatory on the many side, optional on the one side

EMPLOYEE
(empid,ename)
works
PROJECT
(assigndate)
Due to mandatory participation of EMPLOYEE and the transformation rule, null values are absolutely not allowed in the foreign key
EMPLOYEE(empid,ename,projid,assignda te)
FK: projid references PROJECT DELETE restrict/cascade
PROJECT(projid,pname,startdate)
9/3/2012 ADBS
Explanation
Despite to the optional participation of PROJECT in relationship WORKS, the deletion of a project must not be cascaded in EMPLOYEE because deletion of any referencing tuples in EMPLOYEE result in loss of employee information. If however, the application really requires that employees are automatically removed when a project is shelved, the cascade rule must then be used.
9/3/2012 ADBS
One-many: mandatory on both sides

EMPLOYEE
(empid,ename)
works
PROJECT
(assigndate)
EMPLOYEE(empid,ename,projid,assigndate)
FK: projid references PROJECT DELETE restrict/cascade
PROJECT(projid,pname,startdate)
Due to the mandatory nature of the participation of PROJECT in the relationship WORKS, the deletion of a tuple in EMPLOYEE might lead to a project not having an employee working for it.
9/3/2012 ADBS
Database Normalization
ADVANCE Database System
a technique for designing relational database tables to minimize duplication of information and, in so doing, to safeguard the database against certain types of logical or structural problems, namely data anomalies.
ADBS
78
Example, when multiple instances of a given piece of information occur in a table, the possibility exists that these instances will not be kept consistent when the data within the table is updated, leading to a loss of data integrity.
ADBS
79
A table that is sufficiently normalized is less vulnerable to problems of this kind, because its structure reflects the basic assumptions for when multiple instances of the same information should be represented by a single instance only.
ADBS
80
Why do we need to normalize?

To avoid anomalies
ADBS
81
Why do we need to normalize?

Higher degrees of normalization typically involve more tables and create the need for a larger number of joins, which can reduce performance. Accordingly, more highly normalized tables are typically used in database applications involving many isolated transactions (e.g. an Automated teller machine), while less normalized tables tend to be used in database applications that do not need to map complex relationships between data entities and data attributes (e.g. a reporting application, or a full-text search application).
ADBS
82
Normal Forms
1NF,2NF,3NF,BCNF,4NF,5NF Database theory describes a table's degree of normalization in terms of normal forms of successively higher degrees of strictness. A table in third normal form (3NF), for example, is consequently in second normal form (2NF) as well; but the reverse is not always the case.
Anomalies: Problems addressed by Normalization
If the proper normal forms aren't followed, various undesirable side effects can occur in a database These side effects are commonly referred to as anomalies.
Insertion Anomalies Deletion Anomalies Update Anomalies
Insertion Anomaly
This occurs when you cant add row into a table
Until the new faculty member is assigned to teach at least one course, his details cannot be recorded.
Deletion Anomaly
This occurs when you cant delete row into a table, when the row you want to delete contains a important piece of information, or when the row you delete is the last one in the table that contains this piece of information.
ADBS
86
Deletion Anomaly
All information about Dr. Giddens is lost when he temporarily ceases to be assigned to any courses.
ADBS
87
Update Anomaly
These occur when there is unnecessary redundancy in the data.
Employee 519 is shown as having different addresses on different records.
ADBS
88
First Normal Form (1NF)

Any table that has only one value per cell, or row/column intersection, is in 1NF.
Columns contain only scalar values, not arrays There can be only one value per column-row position (field) in a table.
ADBS
89
Violation of 1NF (not normalized)

First Name Last Name Course Code John Dela Cruz CS1, CS22, IS101, Math3a Title Intro to Computer Concepts, Computer Graphics, Mgmt Info System, College Algebra Programming 2, Data Structures, College Algebra, Statistics, Quality Assurance Intro to Computer Concepts, College Algebra, Comm. Arts 2
90
Peter
Domingo
CS2, CS3, Math3a, Math6, IS102 CS1,Math3a, Engl2
Kaye
Abad
ADBS
A table in the 1NF

FirstName LastName CourseCode Ttile
John
John John John
Dela Cruz
Dela Cruz Dela Cruz Dela Cruz
CS1
CS22 IS101 Math3a
Intro to Computer Concepts

Computer Graphics Mgmt Info System College Algebra
Peter
Peter Peter Peter
Domingo
Domingo Domingo Domingo
CS2
CS3 Math3a Math6
Programming 2
Data Structures College Algebra Statistics
Peter
Kaye Kaye Kaye
Domingo
Abad Abad Abad
IS102
CS1 Math3a Engl2
ADBS
Quality Assurance
Intro to Computer Concepts College Algebra Comm Arts 2
91
Second Normal Form (2NF)

It is in the 1NF Every column that is not a part of the primary key is functionally dependent on the entire primary key.
ADBS
92
Functional Dependency
Attribute B is functionally dependent on attribute A if, for each value of attribute A, there is exactly one value of attribute B. Example, Employee Address is functionally dependent on Employee ID, because a particular Employee ID value corresponds to one and only one Employee Address value.
Employee Address Employee ID
ADBS Monday, September 03, 2012 93
Second Normal Form (2NF)

Test whether a table is in the 2NF, we ask:
What is the key to this relation? If the key is concatenated or composite (more than one column or attribute), we further ask: Are there any non-key columns that depends on only part of the key
ADBS
94
Violation of the 2NF

PatientID RelativeID Relationship Patient_Telephone
2490974 2490974 2490974
GGP001 GGP002 GGP003
Father Guardian Mother
123-1342 123-1342 123-1342
0803484 0803484 9857092
PDE001 PDE002 AGE001
Brother Uncle Sister
789-3421 789-3421 421-5986
Patient_Telephone is not functionally dependent on the entire primay key (PatientID+RelativeID). The Patient_Telephone column is fully dependent on PatientID alone.
ADBS
95
Normalized 2NF
PatientID RelativeID Relationship 2490974 2490974 2490974 0803484 0803484 9857092 GGP001 GGP002 GGP003 PDE001 PDE002 AGE001 Father Guardian Mother Brother Uncle Sister PatientID Patient_Telephone 2490974 0803484 9857092 123-1342 789-3421 421-5986
ADBS
96
Third Normal Form (3NF)

It is in the 2NF All of its columns that are not part of the primary key are mutually dependent The 3NF is concerned with the removal of transitive dependencies in tables. There exist transitive dependency when a column is dependent on a column not the primary key.
Transitive Dependency
A transitive dependency is an indirect functional dependency, one in which XZ only by virtue of XY and YZ. Example:
Column1 is directly dependent on the primary key column; another column, say Column2, is indirectly dependent on the primary key column because of its dependency on Column1. The dependency of Column2 to the primary key is by virtue of its dependency on Column1.
Violation of 3NF
EmployeeID First_Name Last_Name Department Dept_Address
8934 Anna 3049 Clarence 4589 Elliot
Burgin Dillon Freeman
Research Research Research
2 Ferman St. 2 Ferman St. 2 Ferman St.
7623 Gail
6103 Keith 4503 Michael
Healy
Jordan Landon
MIS
MIS HR
3 Gauss Lane
3 Gauss Lane 6 Wiles Place
This table violates the 3NF because Dept_Address depends on Department, which is not part of the primary key.
ADBS
99
Normalized 3NF
EmployeeID First_Name Last_Name Department
8934 Anna
3049 Clarence 4589 Elliot 7623 Gail 6103 Keith 4503 Michael
Department
Burgin
Dillon Freeman Healy Jordan Landon
Research
Research Research MIS MIS HR
Dept_Address
Research
MIS HR
2 Ferman St.
3 Gauss Lane 6 Wiles Place
ADBS 100
Boyce-Codd Normal Form (BCNF)

An extension of 3NF for the special case where:
There are at least 2 candidate keys in the table All the candidate keys are composite keys There is an overlapping column in the candidate keys.
A table to be in BCNF, it must be

3NF All of its columns in all its candidate keys must be functionally independent.
ADBS
101
Violation of the BCNF

EmployeeID Extension Month Overtime_Hours
8934
8934 8934
9089 January
9089 February 9089 March
2
1.5 2
7623
7623 7623
8607 January
0
3 3
4503
4503 4503
3869 January
ADBS
2
8 0
102
Fourth Normal Form (4NF)

It is in the 3NF There is only one multi-valued dependency per table.
A multi-valued dependency is a constraint according to which the presence of certain rows in a table implies the presence of certain other rows
Multi-valued dependency occurs when there is many-to-many relationship between two columns in a table.
Violation of the 4NF

AuthorID
Smith023 Smith023
BookTitle
Monkeys are from Asteriod How to Exercise
Editor
Lisa Catherine
Smith023
Williams153 Williams153 Johnson823 Johnson823
How to Exercise
Monkeys are from Asteriod AP Programming Dogs are from Hale-Bopp Monkeys are from Asteriod
John
John Elaine Lisa Silvia
There is no functional dependency between the BookTitle and Editor columns.


ADBMS Lectures 1-5

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

ADBMS Lectures 1-5

Enviado por

Direitos autorais:

Formatos disponíveis

What is a Database?

Monday, September 03, 2012

Monday, September 03, 2012

Monday, September 03, 2012

Monday, September 03, 2012

Data structure (fields, records, files and objects)

Monday, September 03, 2012

Database Management System

Database Management System cont.

Monday, September 03, 2012

Database System Environment

Monday, September 03, 2012

DBMS Architecture : 3 Schema

Monday, September 03, 2012

DBMS Architecture: 3 Schema

Physical Data Independence

Monday, September 03, 2012

Hierarchical Model: An Example

Monday, September 03, 2012

Monday, September 03, 2012

Network Model: An Example

Monday, September 03, 2012

Relational Data Model

Monday, September 03, 2012

Components of Relational Database

Monday, September 03, 2012

Monday, September 03, 2012

Monday, September 03, 2012

Entity-Relationship Data Model:

MITF 202 Advanced Database Systems Mr. Alvin R. Malicdem Professor

Monday, September 03, 2012

The Conceptual Data Model

Monday, September 03, 2012

The Entity-Relationship Data Model

The Entity-Relationship Data Model

Monday, September 03, 2012

Monday, September 03, 2012

Strong Entity type

Monday, September 03, 2012

Monday, September 03, 2012

Simple & multi-valued

Composite & singlevalued Composite & multivalued

Monday, September 03, 2012

material department customer

Monday, September 03, 2012

Monday, September 03, 2012

Monday, September 03, 2012

Monday, September 03, 2012

Simplified Notations for ER Modeling

Monday, September 03, 2012

bdate projid works on

Monday, September 03, 2012

Monday, September 03, 2012

Transformation from ER to Relational Model

E1(pkE1,attrE1) E2(pkE2,attrE2) R(pkE1,pkE2,attrR)

Weak Entity Rule

Multi-valued Attribute Rule

Transform the ER Diagram into a Relational Schema

bdate projid works on

Two entities at a time

Apply Rule 1: many-to-many, regardless of entity participation

EMPLOYEE(empid,name,address,bdate) PROJECT(projid,projname) WORKS(empid,projid,hours)

Apply Rule 2: one-to-many, mandatory on the many side