UNIT II

Syllabus Other Relational Languages The tuple Relational Calculus The Domain Relational Calculus Query-by-Example Datalog Database Design and the E-R Model Overview of the Design Process The Entity-Relationship Model Constraints Entity-Relationship Diagrams Entity-Relationship Design Issues Weak Entity Sets Extended E-R Features Database Design for Banking Enterprise Reduction to Relational Schemas Other Aspects of Database Design The Unified Modeling Language Relational Database Design Features of Good Relational Designs Atomic Domains and First Normal Forms Decomposition Using Functional Dependencies Functional-Dependency Theory Decomposition Using Functional Dependencies Decomposition Using Multivalued Dependencies More Normal Forms Database-Design Process Modeling Temporal Data

OTHER RELATIONAL LANGUAGES

Query Languages A query language is a language in which a user requests information from the database. These languages are usually on a level higher than that of a standard programming language. Query languages can be categorized as either procedural or nonprocedural. procedural language: The user instructs the system to perform a sequence of operations on the database to compute the desired result. Relational algebra is procedural language. Nonprocedural language:The user describes the desired information without giving a specific procedure for obtaining that information. The tuple relational calculus and domain relational calculus are nonprocedural. The Tuple Relational Calculus The tuple relational calculus, by contrast, is a nonprocedural query language. It describes the desired information without giving a specific procedure for obtaining that information. A query in the tuple relational calculus is expressed as {t | P(t)} that is, it is the set of all tuples t such that predicate P is true for t. Following our earlier notation, we use t[A] to denote the value of tuple t on attribute A, and we use t r to denote that tuple t is in relation r.

Definition-1: Tuple variable associated with a relation( called the range relation) takes tuples from the range relation as its values t: tuple variable over relation rwith scheme R(A,B,C )t.A stands for value of column A etc TRC Query basic form:{ t1.Ai1, t2.Ai2,tm.Aim| } predicate calculus expression involving tuple variables t1, t2,, tm, tm+1,,ts-specifies the condition to be satisfied[3]

Definition-2 The tuple relational calculus is based on specifying a number of tuple variables. Each tuple variable usually ranges over a particular database relation, meaning that the variable may take as its value any individual tuple from that relation[2] Example Queries Example 1: Find the branch-name, loan-number, and amount for loans of over $1200 Answer {t | t loan ^ t[amount] > 1200}

Suppose that we want only the loan-number attribute, rather than all attributes of the loan relation. Example 2: Find the loan number for each loan of an amount greater than $1200 Answer Example 3: Find the names of all customers who have a loan from the Perryridge branch. Answer {t | s borrower (t[customer-name] = s[customer-name] ^ u loan (u[loan-number] = s[loan-number ] ^ u[branch-name] = Perryridge))} {t | s loan (t[loan-number] = s[loan-number] ^ s[amount] > 1200)}

Example 4: Find all customers who have a loan, an account, or both at the bank Answer: we shall need two there exists clauses, connected by or (): {t | s borrower (t[customer-name] = s[customer-name]) ^ u depositor (t[customer-name] = u[customer-name])} This expression gives us the set of all customer-name tuples for which at least one of the following holds: The customer-name appears in some tuple of the borrower relation as a borrower from the bank. The customer-name appears in some tuple of the depositor relation as a depositor of the bank. Example 5: Find all customers who have both an account and a loan at the bank Answer {t | s borrower (t[customer-name] = s[customer-name]) ^ u depositor (t[customer-name] =u[customer-name])} Example 6: Find all customers who have an account at the bank but do not have a loan from the bank Answer {t | ^ u depositor (t[customer-name] = u[customer-name]) s borrower (t[customer-name] = s[customer-name])}

Example 7

Find all customers who have an account at all branches located in Brooklyn. Answer To write this query in the tuple relational calculus, we introduce the for all construct, denoted by . The notation t r (Q(t)) means Q is true for all tuples t in relation r. We write the expression for our query as follows: {t | r customer (r[customer-name] = t[customer-name]) ( u branch (u[branch-city] = Brooklyn s depositor (t[customer-name] = s[customer-name] w account (w[account-number] = s[account-number ] w[branch-name] = u[branch-name]))))} Formal Notations A tuple-relational-calculus formula is built up out of atoms. An atom has one of the following forms: s r, where s is a tuple variable and r is a relation (we do not allow use of the operator) s[x] u[y], where s and u are tuple variables, x is an attribute on which s is defined, y is an attribute on which u is defined, and is a comparison operator (<, , =, _=, >, ); we require that attributes x and y have domains whose members can be compared by s[x] c, where s is a tuple variable, x is an attribute on which s is defined, is a comparison operator, and c is a constant in the domain of attribute x We build up formulae from atoms by using the following rules: s An atom is a formula. If P1 is a formula, then so are P1 and (P1). If P1 and P2 are formulae, then so are P1 P2, P1 P2, and P1 P2. If P1(s) is a formula containing a free tuple variable s, and r is a relation, then r (P1(s)) are also formulae.

s r (P1(s)) and

As we could for the relational algebra, we can write equivalent expressions that are not identical in appearance. In the tuple relational calculus, these equivalences include the following three rules: 1. P1 P2 is equivalent to ((P1) (P2)). 2. t r (P1(t)) is equivalent to t r (P1(t)). 3. P1 P2 is equivalent to (P1) P2.

The Domain Relational Calculus uses domain variables that take on values from an attributes domain, rather than values for an entire tuple. The domain relational calculus, however, is closely related to the tuple relational calculus. Domain relational calculus serves as the theoretical basis of the widely used QBE language, just as relational algebra serves as the basis for the SQL language. An expression in the domain relational calculus is of the form {< x1, x2, . . . , xn > | P(x1, x2, . . . , xn)} where x1, x2, . . . , xn represent domain variables. P represents a formula composed of atoms, as was the case in the tuple relational calculus. An atom in the domain relational calculus has one of the following forms: < x1, x2, . . . , xn > r, where r is a relation on n attributes and x1, x2, . . . , xn are domain variables or domain constants. x y, where x and y are domain variables and is a comparison operator (<, , =, _=, >, ). We require that attributes x and y have domains that can be compared by .

 x c, where x is a domain variable, is a comparison operator, and c is a constant in the domain of the attribute for which x is a domain variable. We build up formulae from atoms by using the following rules: An atom is a formula. If P1 is a formula, then so are P1 and (P1). If P1 and P2 are formulae, then so are P1 P2, P1 P2, and P1 P2. If P1(x) is a formula in x, where x is a domain variable, then x (P1(x)) and x (P1(x)) are also formulae. As a notational shorthand, we write a, b, c (P(a, b, c)) for a ( b ( c (P(a, b, c)))) Example Queries Example 1: Find the loan number, branch name, and amount for loans of over $1200: Answer Example 2: Find all loan numbers for loans with an amount greater than $1200: Answer Example 3 Find the names of all customers who have a loan from the Perryridge branch and find the loan amount Answer Example 4 Find the names of all customers who have a loan, an account, or both at the Perryridge branch: Answer ^ ^ ^ {< c > | l (< c, l > borrower b, a (< l, b, a > loan b = Perryridge)) a (< c,a > depositor b, n (< a, b, n > account b = Perryridge))} {< c,a > | l (< c, l > borrower ^ b (< l, b, a > loan ^ b = Perryridge))} {< l > | b, a (< l, b, a > loan ^ a > 1200)} {< l, b, a > | < l, b, a > loan ^ a > 1200}

Example 5 Find the names of all customers who have an account at all the branches located in Brooklyn Answer {< c > | n (< c,n > customer) ^ x, y, z (< x, y, z > branch ^ y = Brooklyn ^ a, b (< a, x, b > account< c,a > depositor))}

Query-by-Example QBE is a graphical language, where queries look like tables. Query-by-Example (QBE) is the name of both a data-manipulation language and an early database system that included this language. The QBE database system was developed at IBMs T. J. Watson Research Center in the early 1970s. The QBE data manipulation language was later used in IBMs Query Management Facility (QMF). Today, many database systems for personal computers support variants of QBE language. In this section, we consider only the data-manipulation language. It has two distinctive features: 1. Unlike most query languages and programming languages, QBE has a twodimensional syntax: Queries look like tables. A query in a one-dimensional dimensional language requires two dimensions for its expression. (There is a one-dimensional version of QBE, but we shall not consider it in our discussion).

2. QBE queries are expressed by example. Instead of giving a procedure for obtaining the desired answer, the user gives an example of what is desired. The system generalizes this example to compute the answer to the query. We express queries in QBE by skeleton tables

QBE skeleton tables for the bank example. QUERIES ON SINGLE RELATIONS EXAMPLE 1 Find all loan numbers at the Perryridge branch

EXAMPLE 2 Find the loan numbers of all loans with a loan amount of more than $700

EXAMPLE 3 Find the names of all branches that are not located in Brooklyn

EXAMPLE 4

Find the loan numbers of all loans made jointly to Smith and Jones

Queries on Several Relations Find the names of all customers who have a loan from the Perryridge branch

Find the names of all customers who have both an account and a loan at the bank

Find the names of all customers who have an account at the bank, but who do not have a loan from the bank

The Condition Box Find the loan numbers of all loans made to Smith, to Jones (or to both jointly)

Find all account numbers with a balance between $1300 and $1500

Find all branches that have assets greater than those of at least one branch located in Brooklyn

The Result Relation The queries that we have written thus far have one characteristic in common: The results to be displayed appear in a single relation schema. If the result of a query includes attributes from several relation schemas, we need a mechanism to display the desired result in a single table. For this purpose, we can declare a temporary result relation that includes all the attributes of the result of the query. We print the desired result by including the command P. in only the result skeleton table. EXAMPLE Find the customer-name, account-number, and balance for all accounts at the Perryridge branch

Ordering of the Display of Tuples List in ascending alphabetic order all customers who have an account at the bank

List all account numbers at the Perryridge branch in ascending alphabetic order with their respective account balances in descending order

Aggregate Operations QBE includes the aggregate operators AVG, MAX, MIN, SUM, and CNT. We must postfix these operators with ALL. to create a multiset on which the aggregate operation is evaluated. The ALL. operator ensures that duplicates are not eliminated. Find the total balance of all the accounts maintained at the Perryridge branch

Find the total number of customers who have an account at the bank

Modification of the Database Deletion Deletion of tuples from a relation is expressed in much the same way as a query. The major difference is the use of D. in place of P. QBE (unlike SQL), lets us delete whole tuples, as well as values in selected columns. When we delete information in only some of the columns, null values, specified by , are inserted. We note that a D. command operates on only one relation. If we want to delete tuples from several relations, we must use one D. operator for each relation. Delete customer Smith.

Delete the branch-city value of the branch whose name is Perryridge.

Delete all loans with a loan amount between $1300 and $1500.

Insertion To insert data into a relation, we either specify a tuple to be inserted or write a query whose result is a set of tuples to be inserted. We do the insertion by placing the I. operator in the query expression. Obviously, the attribute values for inserted tuples must be members of the attributes domain. Examples Insert the fact that account A-9732 at the Perryridge branch has a balance of $700

Consider the situation where we want to provide as a gift, for all loan customers of the Perryridge branch, a new $200 savings account for every loan account that they have, with the loan number serving as the account number for the savings account

Updates There are situations in which we wish to change one value in a tuple without changing all values in the tuple. For this purpose, we use the U. operator. As we could for insert and delete, we can choose the tuples to be updated by using a query. QBE, however, does not allow users to update the primary key fields. Examples update the asset value of the of the Perryridge branch to $10,000,000

QBE in Microsoft Access

Queries involving group by and aggregation can be created in Access as shown below

Datalog Datalog is a nonprocedural query language based on the logic-programming language Prolog A Datalog program consists of a set of rules. Before presenting a formal definition of Datalog rules and their formal meaning, we consider examples. Consider a Datalog rule to define a view relation v1 containing account numbers and balances for accounts at the Perryridge branch with a balance of over $700: v1(A, B) :account(A, Perryridge, B),B > 700 To retrieve the balance of account number A-217 in the view relation v1, we can write the following query: ? v1(A-217, B) The answer to the query is

(A-217, 750)

Exercise problems-1 I. Using the following schemas, give the expressions in TRC, DRC ,QBE,DATALOG and SQL Example Relational Scheme student (rollNo, name, degree, year, sex, deptNo, advisor) department (deptId, name, hod, phone) professor (empId, name, sex, startYear, deptNo, phone) course (courseId, cname, credits, deptNo) enrollment (rollNo, courseId, sem, year, grade) teaching (empId, courseId, sem, year, classRoom) preRequisite(preReqCourse, courseID) 1) Determine the departments that do not have any girl students 2) Obtain the names of courses enrolled by student named Mahesh 3) Get the names of students who have scored Sin all subjects they have enrolled. Assume that every student is enrolled in at least one course. 4) Get the names of students who have taken at least one course taught by their advisor 5) Display the departments whose HODs are teaching at least one course in the current semester 6)Determine the students who are enrolled for every course taught by Prof Ramanujam. Assume that ProfRamanujamteaches at least one course.

II. Using the following schemas, give the expressions in TRC, DRC ,QBE,DATALOG and SQL

Branch schema (branch name, branch city, assets) Customer schema (customer name, customer street, customer city) Loan schema (branch name, loan number, amount) Borrower schema (customer name, Loan number) Account schema (branch name, account number, balance) Depositor schema (Customer name, account number) a) Find the names of all customers whose street address include substring Main b) Find average balance for each customer who lives in Harrison and having at least three accounts? c) Find all customer who have a loan at bank whose names are neither smith nor jones? d) Dispaly customernames in alphabetical order who have a loan at the perryridge branch? e) Find all customers having loan, account or both at a bank? f) Find all customers who have account but not loan at bank? Give an expression in the relational algebra to express each of the following queries: III. Using the following schemas, give the expressions in TRC, DRC ,QBE,DATALOG and SQL employee (person-name, street, city) works (person-name, company-name, salary) company (company-name, city)

manages (person-name, manager-name) a. Find the names of all employees who work for First Bank Corporation. b. Find the names and cities of residence of all employees who work for First Bank Corporation. c. Find the names, street address, and cities of residence of all employees who work for First Bank Corporation and earn more than $10,000 per annum. d. Find the names of all employees in this database who live in the same city as the company for which they work. e. Find the names of all employees who live in the same city and on the same street as do their managers. f. Find the names of all employees in this database who do not work for First Bank Corporation. g. Find the names of all employees who earn more than every employee of Small Bank Corporation. h. Assume the companies may be located in several cities. Find all companies located in every city in which Small Bank Corporation is located. IV Let the following relation schemas be given: R = (A,B,C) S = (D,E, F) Let relations r(R) and s(S) be given. Give an expression in the tuple relational calculus that is equivalent to each of the following: a. A(r) b. B =17 (r) c. r xs d. A,F (C =D(r x s)) V Let R = (A, B, C), and let r1 and r2 both be relations on schema R. Give an expression in the domain relational calculus that is equivalent to each of the following: a. A(r1) b. B =17 (r1) c. r1 r2 d. r1 r2 e. r1 r2 f. A,B(r1) B,C(r2)

DATABASE DESIGN AND THE E-R MODEL The entity-relationship (E-R) data model perceives the real world as consisting of basic objects, called entities, and relationships among these objects. The E-R data model employs three basic notions: entity sets, relationship sets, and attributes. 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 set is a set of entities of the same type that share the same properties. Example: set of all persons, companies, trees, holidays A relationship is an association among several entities Example: 44553 (Peltier) advisor 22222 (Einstein) student entity relationship set instructor entity A relationship set is a mathematical relation among n 2 entities, each taken from entity sets {(e1, e2, en) | e1 E1, e2 E2, , en En} where (e1, e2, , en) is a relationship

Example: (44553,22222) advisor An entity is a thing or object in the real world that is distinguishable from all other objects. For example, each person in an enterprise is an entity. An entity has a set of properties, and the values for some set of properties may uniquely identify an entity. Attributes The set of possible values for an attribute is called the domain of the attribute Example: The domain of attribute marital status is just the four values: single, married, divorced, widowed The domain of the attribute month is the twelve values ranging from January to December Key attribute: The attribute (or combination of attributes) that is unique for every entity instance E.g the account number of an account, the employee id of an employee etc. composite key: If the key consists of two or more attributes in combination, it is called a composite key Simple and composite attributes The attributes have been simple; that is, they are not divided into subparts. Composite attributes, on the other hand, can be divided into subparts (that is, other attributes) Example Attribute name could be structured as a composite attribute consisting of first-name, middle-initial, and last-name. . Short definition Simple attribute: cannot be divided into simpler components E.g age of an employee Composite attribute: can be split into components E.g Date of joining of the employee. Can be split into day, month and year Single-valued and multivalued attributes: The attributes in our examples all have a single value for a particular entity. For instance, the loan-number attribute for a specific loan entity refers to only one loan number. Such attributes are said to be single valued. There may be instances where an attribute has a set of values for a specific entity. Consider an employee entity set with the attribute phone-number. An employee may have zero, one, or several phone numbers, and different employees may have different numbers of phones. This type of attribute is said to be multivalued. Short definition Single valued : can take on only a single value for each entity instance E.g. age of employee. There can be only one value for this Multi-valued: can take many values E.g. skill set of employee Derived attribute. The value for this type of attribute can be derived from the values of other related attributes or entities Example we can calculate age from date-of-birth and the current date. Thus, age is a derived attribute

Short definition Stored Attribute: Attribute that need to be stored permanently. E.g. name of an employee Derived Attribute: Attribute that can be calculated based on other attributes E.g. : years of service of employee can be calculated from date of oining and current date Weak Entity Types

Entity types that do not have key attributes of their own are called weak entity types.

In contrast, regular entity types that do have a key attribute are sometimes called strong entity types. Entities belonging to a weak entity type are identified by being related to specific entities from another entity type in combination with some of their attribute values. We call this other entity type the identifying or owner entity type and we call the relationship type that relates a weak entity type to its owner the identifying relationship of the weak entity type. A weak entity type always has a total participation constraint (existence dependency) with respect to its identifying relationship, because a weak entity cannot be identified without an owner entity. A weak entity type normally has a partial key, which is the set of attributes that can uniquely identify weak entities that are related to the same owner entity

Weak entity: Entity that depends on other entity for its existence and doesnt have key attribute of its own E.g. : spouse of employee Relationship Sets A relationship is an association among several entities. A relationship set is a set of relationships of the same type. Relationship type A relationship type R among n entity types , , . . ., defines a set of associationsor a relationship setamong entities from these types. As for entity types and entity sets, a relationship type and its corresponding relationship set are customarily referred to by the same name R. A relationship type between two entity types defines the set of all associations between these entity types Each instance of the relationship between members of these entity types is called a relationship instance Degree of a Relationship Type The degree of a relationship type is the number of participating entity types. A relationship type of degree two is called binary, and one of degree three is called ternary. Role Names and Recursive Relationships Each entity type that participates in a relationship type plays a particular role in the relationship. The role name signifies the role that a participating entity from the entity type plays in each relationship instance, and helps to explain what the relationship means. However, in some cases the same entity type participates more than once in a relationship type in different roles. In such cases the role name becomes essential for distinguishing the meaning of each participation. Such relationship types are called recursive relationships Constraints Mapping Cardinalities Mapping cardinalities, or cardinality ratios, express the number of entities to which another entity can be associated via a relationship set. Mapping cardinalities are most useful in describing binary relationship sets, although they can contribute to the description of relationship sets that involve more than two entity sets. In this section, we shall concentrate on only binary relationship sets. For a binary relationship set R between entity sets A and B, the mapping cardinality must be one of the following: One to one. An entity in A is associated with at most one entity in B, and an entity in B is associated with at most one entity in A. One to many. An entity in A is associated with any number (zero or more) of entities in B. An entity in B, however, can be associated with at most one entity in A. Many to one. An entity in A is associated with at most one entity in B. An entity in B, however, can be associated with any number (zero or more) of entities in A.

 Many to many. An entity in A is associated with any number (zero or more) ofentities in B, and an entity in B is associated with any number (zero or more)of entities in A

a)one to one b)one to many

a)many to one b)many to many 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

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

In a many-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 several (including 0) instructors via advisor

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

Participation Constraints and Existence Dependencies The participation constraint specifies whether the existence of an entity depends on its being related to another entity via the relationship type. There are two types of participation constraints Total Partial

Total participation is displayed as a double line connecting the participating entity type to the relationship, whereas partial participation is represented by a single line Total : Every entity instance must be connected through the relationship to another instance of the other participating entity types Partial: All instances need not participate E.g Employee Head-of Department Employee: partial Department: total Attributes of Relationship Types Relationship types can also have attributes, similar to those of entity types. For example, to record the number of hours per week that an employee works on a particular project, we can include an attribute Hours for the WORKS_ON relationship type

ER modeling Notations Entity Employee Usually a noun in singular Represented by a rectangle with a label First letter in capitals

Employee
Attributes

Key attribute

_________ _______
Multivalued attribute

Composite attribute

Relationship

Identifying relationship

A banking scenario Banks have customers. Customers are identified by name, custid, phone number and address. Customers can have one or more accounts Accounts are identified by an account number, account type (savings, current) and a balance. Customers can avail loans. Loans are identified by loan id, loan type (car, home, personal) and an amount. Banks are identified by a name, code and the address of the main office. Banks have branches. Branches are identified by a branch number, branch name and an address. Accounts and loans are related to the banks branches. Create an ER diagram for a database to represent this application

Solution Step 1: Identify the entities Bank Branch Customer Account Loan Solution Step 2: Identify attributes of entities Bank Branch Customer

Name Branch# Name Code Branch name Custid Address Address Phone Address Account Loan Account number Loan id Account type Loan type Balance Amount Solution Step 3: Identify relationships between entities Bank has Branch Branch maintains accounts Branch offers loans Account is held by customer Loan is availed by customer

Solution Step 4: Analyze cardinality of relationships Bank has Branch : A bank has many branches->1:N Branch maintains accounts: One branch maintains many accounts-> 1:N Branch offers loans : One branch offers many loans -> 1:N Account is held by customer -> M:N Loan is availed by customer ->M:N Solution Step 5: Identify weak entities if any Branch: Depends on strong entity Bank Solution Step 6: Identify participation types Bank has Branch -> both total Branch maintains accounts-> Branch :partial Account: Total Branch offers loans -> Branch: partial Loan: Total Account is held by customer-> both Total Loan is availed by customer-> Loan : Total Customer: Partial

Represented diagrammatically

Exercise problems-2 Database Application The COMPANY database keeps track of a companys employees, departments, and projects. Suppose that, after the requirements collection and analysis phase, the database designers stated the following description of the "miniworld"the part of the company to be represented in the database:

1. The company is organized into departments. Each department has a unique name, a unique number, and a particular employee who manages the department. We keep track of the start date when that employee began managing the department. A department may have several locations. 2. A department controls a number of projects, each of which has a unique name, a unique number, and a single location. 3. We store each employees name, social security number (Note 1), address, salary, sex, and birth date. An employee is assigned to one department but may work on several projects, which are not necessarily controlled by the same department. We keep track of the number of hours per week that an employee works on each project. We also keep track of the direct supervisor of each employee. 4. We want to keep track of the dependents of each employee for insurance purposes. We keep each dependents first name, sex, birth date, and relationship to the employee.

ER-to-Relational Mapping Algorithm Step Step Step Step Step Step Step 1: 2: 3: 4: 5: 6: 7: Mapping Mapping Mapping Mapping Mapping Mapping Mapping of of of of of of of Regular Entity Types Weak Entity Types Binary 1:1 Relation Types Binary 1:N Relationship Types. Binary M:N Relationship Types. Multivalued attributes. N-ary Relationship Types.

Mapping EER Model Constructs to Relations Step 8: Options for Mapping Specialization or Generalization. Step 9: Mapping of Union Types (Categories).

ER-to-Relational Mapping Algorithm Step 1: Mapping of Regular Entity Types. For each regular (strong) entity type E in the ER schema, create a relation R that includes all the simple attributes of E. Choose one of the key attributes of E as the primary key for R. If the chosen key of E is composite, the set of simple attributes that form it will together form the primary key of R. Example: We create the relations EMPLOYEE, DEPARTMENT, and PROJECT in the relational schema corresponding to the regular entities in the ER diagram. SSN, DNUMBER, and PNUMBER are the primary keys for the relations EMPLOYEE, DEPARTMENT, and PROJECT as shown. Step 2: Mapping of Weak Entity Types For each weak entity type W in the ER schema with owner entity type E, create a relation R and include all simple attributes (or simple components of composite attributes) of W as attributes of R. In addition, include as foreign key attributes of R the primary key attribute(s) of the relation(s) that correspond to the owner entity type(s). The primary key of R is the combination of the primary key(s) of the owner(s) and the partial key of the weak entity type W, if any.

Example: Create the relation DEPENDENT in this step to correspond to the weak entity type DEPENDENT. Include the primary key SSN of the EMPLOYEE relation as a foreign key attribute of DEPENDENT (renamed to ESSN). The primary key of the DEPENDENT relation is the combination {ESSN, DEPENDENT_NAME} because DEPENDENT_NAME is the partial key of DEPENDENT.

Step 3: Mapping of Binary 1:1 Relation Types For each binary 1:1 relationship type R in the ER schema, identify the relations S and T that correspond to the entity types participating in R. There are three possible approaches: (1) Foreign Key approach: Choose the relations with total participation in R say S-- and include Ts primary key in S. Example: 1:1 relation MANAGES is mapped by choosing the participating entity type DEPARTMENT to serve in the role of S, because its participation in the MANAGES relationship type is total. (2) Merged relation option: An alternate mapping of a 1:1 relationship type is possible by merging the two entity types and the relationship into a single relation. This may be appropriate when both participations are total. (3) Cross-reference or relationship relation option: The third alternative is to set up a third relation W(T.primarykey, S.primaryKey) for the purpose of cross-referencing the primary keys of the two relations S and T representing the entity types.

Step 4: Mapping of Binary 1:N Relationship Types. For each regular binary 1:N relationship type R, identify the relation S that represent the participating entity type at the N-side of the relationship type. Include as foreign key in S the primary key of the relation T that represents the other entity type participating in R. Include any simple attributes of the 1:N relation type as attributes of S.

Example: 1:N relationship types WORKS_FOR, CONTROLS, and SUPERVISION in the figure. For WORKS_FOR we include the primary key DNUMBER of the DEPARTMENT relation as foreign key in the EMPLOYEE relation and call it DNO. Step 5: Mapping of Binary M:N Relationship Types. For each regular binary M:N relationship type R, create a new relation S to represent R. Include as foreign key attributes in S the primary keys of the relations that represent the participating entity types; their combination will form the primary key of S. Also include any simple attributes of the M:N relationship type (or simple components of composite attributes) as attributes of S Example: The M:N relationship type WORKS_ON from the ER diagram is mapped by creating a relation WORKS_ON in the relational database schema. The primary keys of the PROJECT and EMPLOYEE relations are included as foreign keys in WORKS_ON and renamed PNO and ESSN, respectively. Attribute HOURS in WORKS_ON represents the HOURS attribute of the relation type. The primary key of the WORKS_ON relation is the combination of the foreign key attributes {ESSN, PNO}. Step 6: Mapping of Multivalued attributes. For each multivalued attribute A, create a new relation R. This relation R will include an attribute corresponding to A, plus the primary key attribute K-as a foreign key in R-of the relation that represents the entity type that has A as an attribute. The primary key of R is the combination of A and K. If the multivalued attribute is composite, we include its simple components. Example: The relation DEPT_LOCATIONS is created. The attribute DLOCATION represents the multivalued attribute LOCATIONS of DEPARTMENT, while DNUMBER-as foreign keyrepresents the primary key of the DEPARTMENT relation. The primary key of R is the combination of {DNUMBER, DLOCATION}. Step 7: Mapping of N-ary Relationship Types. For each n-ary relationship type R, where n>2, create a new relationship S to represent R. Include as foreign key attributes in S the primary keys of the relations that represent the participating entity types. Also include any simple attributes of the n-ary relationship type (or simple components of composite attributes) as attributes of S. Example: The relationship type SUPPY in the ER on the next slide. This can be mapped to the relation SUPPLY shown in the relational schema, whose primary key is the combination of the three foreign keys {SNAME, PARTNO, PROJNAME} Summary of Mapping constructs and constraints Table 7.1 Correspondence between ER and Relational Models ER Model Entity type 1:1 or 1:N relationship type M:N relationship type Relational Model Entity relation Foreign key (or relationship relation) Relationship relation and two foreign keys

n-ary relationship type Simple attribute Composite attribute Multivalued attribute Value set Key attribute

Relationship relation and n foreign keys Attribute Set of simple component attributes Relation and foreign key Domain Primary (or secondary) key

Mapping EER Model Constructs to Relations Step8: Options for Mapping Specialization or Generalization. Convert each specialization with m subclasses {S1, S2,.,Sm} and generalized superclass C, where the attributes of C are {k,a1,an} and k is the (primary) key, into relational schemas using one of the four following options: Option 8A: Multiple relations-Superclass and subclasses Option 8B: Multiple relations-Subclass relations only Option 8C: Single relation with one type attribute Option 8D: Single relation with multiple type attributes Option 8A: Multiple relations-Superclass and subclasses Create a relation L for C as L{k,a1,an}, and PK(L) = k. Create a relation Li for each subclass Si, 1 < i < m, Li{k, si1,,siik}, where si1,,siik are the local attributes of Si, and PK(Li)=k. This option works for any specialization (total or partial, disjoint of over-lapping). Option 8B: Multiple relations-Subclass relations only Create a relation Li for each subclass Si, 1 < i < m, with the attributes Attr(Li) = {attributes of Si} U {k,a1,an} and PK(Li) = k. This option only works for a specialization whose subclasses are total (every entity in the superclass must belong to (at least) one of the subclasses).

EER diagram notation for an attribute-defined specialization on JobType. Options for mapping specialization or generalization. (a) Mapping the EER schema in Figure 4.4 using option 8A.

FIGURE 4.3 Generalization. (b) Generalizing CAR and TRUCK into the superclass VEHICLE.

FIGURE 7.4 Options for mapping specialization or generalization. (b) Mapping the EER schema in Figure 4.3b using option 8B.

Mapping EER Model Constructs to Relations (cont) Option 8C: Single relation with one type attribute. Create a single relation L with attributes Attrs(L) = {k,a1,an} U {attributes of S1} UU {attributes of Sm} U {t} and PK(L) = k. The attribute t is called a type (or discriminating) attribute that indicates the subclass to which each tuple belongs Option 8D: Single relation with multiple type attributes. Create a single relation schema L with attributes Attrs(L) = {k,a1,an} U {attributes of S1} UU {attributes of Sm} U {t1, t2,,tm} and PK(L) = k. Each ti, 1 < I < m, is a Boolean type attribute indicating whether a tuple belongs to the subclass Si. FIGURE 4.4 EER diagram notation for an attribute-defined specialization on JobType.

FIGURE 7.4 Options for mapping specialization or generalization. (c) Mapping the EER schema in Figure 4.4 using option 8C.

FIGURE 4.5 EER diagram notation for an overlapping (nondisjoint) specialization.

FIGURE 7.4 Options for mapping specialization or generalization. (d) Mapping Figure 4.5 using option 8D with Boolean type fields Mflag and Pflag

Mapping of Shared Subclasses (Multiple Inheritance)

A shared subclass, such as STUDENT_ASSISTANT, is a subclass of several classes, indicating multiple inheritance. These classes must all have the same key attribute; otherwise, the shared subclass would be modeled as a category. We can apply any of the options discussed in Step 8 to a shared subclass, subject to the restriction discussed in Step 8 of the mapping algorithm. Below both 8C and 8D are used for the shared class STUDENT_ASSISTANT FIGURE 4.7 A specialization lattice with multiple inheritance for a UNIVERSITY database.

FIGURE 7.5 Mapping the EER specialization lattice in Figure 4.6 using multiple options.

Step 9: Mapping of Union Types (Categories). For mapping a category whose defining superclass have different keys, it is customary to specify a new key attribute, called a surrogate key, when creating a relation to correspond to the category. In the example below we can create a relation OWNER to correspond to the OWNER category and include any attributes of the category in this relation. The primary key of the OWNER relation is the surrogate key, which we called OwnerId.

FIGURE 4.8 Two categories (union types): OWNER and REGISTERED_VEHICLE.

FIGURE 7.6 Mapping the EER categories (union types) in Figure 4.7 to relations.

Mapping Exercise

Normalization A well structured table Well-structured table - contains minimal redundancy and allows users to insert, modify, and delete the rows without errors or inconsistencies. The possible anomalies could be Insertion Anomalies Deletion Anomalies Modification Anomalies An Example table: Project# Project_name Member# MemberName MemberAddress

Insertion Anomalies Experienced when we attempt to store a value for one field but cannot do so because the value of another field is unknown e.g., cannot add a new employee information until he /she is assigned a project Deletion Anomalies Experienced when value of a field is unexpectedly removed when value for another field is deleted e.g., cannot delete the project detail (project could be dropped) of the employee without deleting the only copy of the employee information Modification Anomalies Experienced when changes to multiple records of a table are needed to update a single value of a field e.g., for changing an employees address, it has to be changed in every row corresponding

to the project he/she would be a member of Normalization The formal process that can be followed to achieve a good database design Also used to check that an existing design is of good quality The different stages of normalization are known as normal forms Functional dependency An attribute Y of a relation schema R is functionally dependent on another attribute X of R if the value of the attribute X uniquely determines the value of the attribute Y x -> y We say here x determines y or y is functionally dependent on x XY does not imply that YX If the value of an attribute Marks is known then the value of an attribute Grade is determined since MarksGrade Types of functional dependencies: Full dependency Partial dependency Transitive dependency Full dependencies An attribute B of a relation R is fully functionally dependent on attribute A of R if it is functionally dependent on A & not functionally dependent on any proper subset of A. Report( S#,C#,Title,Lname,Room#,Marks) S#, C# marks

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. Update Anomalies Relations that have redundant data may have problems called update anomalies, which are classified as , Insertion anomalies Deletion anomalies Modification anomalies 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 SL21 SG37 SG14 SA9 sName position Manager Assistant Supervisor Assistant 30000 12000 18000 9000 salary branchNo B005 B003 B003 B007 bAddress

John White Ann Beech David Ford Mary Howe

22 Deer Rd, London 163 Main St,Glasgow 163 Main St,Glasgow 16 Argyll St, Aberdeen

SG5 SL41

Susan Brand Julie Lee

Manager Assistant

24000 B003 9000 B005

163 Main St,Glasgow 22 Deer Rd, London

Figure 1 StraffBranch relation Example of Update Anomalies (2) Staff staffNo SL21 SG37 SG14 SA9 SG5 SL41 Branch branceNo B005 B007 B003 bAddress sName position Manager Assistant Supervisor Assistant Manager Assistant 30000 12000 18000 9000 24000 9000 sal ar y B005 B003 B003 B007 B003 B005 branceNo

John White Ann Beech David Ford Mary Howe Susan Brand Julie Lee

22 Deer Rd, London 16 Argyll St, Aberdeen 163 Main St,Glasgow

Figure 2 Straff and Branch relations 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.) B is functionally dependent on A

Determinant Refers to the attribute or group of attributes on the left-hand side of the arrow of a functional dependency Trival functional dependency means that the right-hand side is a subset ( not necessarily a proper subset) of the left- hand 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 dependencies because they represent integrity constraints for the relation.

Normaliz ation Normalization is a structured method of decomposing the entire logical view into a succinct set of tables (files); producing a database without anomalies; with reduced data redundancy, proper relationships, and proper assignment of all key fields. Normalization is accomplished by analyzing the interdependencies among individual attributes

associated with those tables and taking subset of columns of larger tables to form smaller ones. The objectives of normalization of database are: 1. To eliminate anomalies that is caused by redundancy. 3 types of anomalies : 1. Update anomalies : If one copy of a repeated data is updated, an inconsistency is created unless all copies are similarly updated. 2. Insertion anomalies : It may not be possible to store some information unless some other information is stored as well. 3. Deletion anomalies : It may not be possible to delete some information without losing some other information as well. 2. To reduce the need to restructure the database as new types of data are introduced, and thus prolong the life of applications and the database design. relation model more

3. To make the informative to users;

Roberts' Rules of Database Design Rule 1 : Each table should deal with exactly one type of entity. Rule 2 : Each fact should be represented exactly once in the database. Rule 3 : Each row should go into one and only one table. Rule 4 : The database design must be insensitive to cardinality

Example #1: EMP ( EMPNO, ENAME, DEPTNO, DNAME) DEPT (DEPTNO, DNAME, DLOC) The above relation violates the following Roberts' rules : Rule 1. The EMP table describes employee as well as department Rule 2. In the EMP table, if we have the same DEPTNO in multiple rows, DNAME will be represented multiple times. Rule 3. DEPTNO and DNAME reside in the EMP tables as well as the DEPT table.

Example #2: EMP (ENAME, DEGREE1, DEGREE2, DEGREE3) This schema violates the following Robert's rule : Rule 4. The design assumes every employee has a maximum of 3 degrees. If an employee has 4 degrees, then the database needs to be restructured by adding DEGREE4 in the EMP table. Rule 4 deals with an aspect of data independence. It can be stated informally as: "Grow down, not across"

Keys: Candidate key: a set of attributes Ai, Aj,Ak that is a candidate key has two (time-invariant) properties: 1. Uniqueness no two tuples have the same value for the candidate key 2. Minimality if any Ai is discarded from the candidate key, then the uniqueness property is lost. It is the smallest set of attributes that identifies a row. A table can have a lot of candidate keys. Every column could be a candidate key. Primary key: one of the candidate key that we select to be a primary key, others are called alternate keys. Another definition a candidate key selected to be the identifier of rows. Informal definition : the primary key identifies each entity, other values describe the entity.

Example of candidate keys for an employee table: - SSN This is selected as the primary key

- Badge # - Employee ID According to Codd, no parts of a candidate key can be null (unknown value) although this does not hold as a rule in that it has not been proved to be used as a concrete rule. Non-key Attribute: attribute that does not participate in the primary key of the relation (here, assuming only one candidate key)

Example: X Y 1 A 2 B 3 C 4 A 5 B 6 C 3 C 2 B 1 A

Y?

Is there one and only one Y value for each X? Yes Y X?

Is there one and only one X value for each Y? No, when Y=A, X={1, 4} Note: FD as a semantic notion, enforceable by data dictionary entries FD a constraint on intensional data, not extensional extentional data - data that is present intentional data - data that is allowed to be present In other words, functional dependencies can not be determined just by looking at the data in the table. We have to consider data that is allowed to be present.

Full Functional Dependence R.X FFD R.Y

Attribute Y is fully functionally dependent on attribute X of relation R if it is functionally dependent on X and not functionally dependent on any proper subset of X. Example: GRADE (STUDNO, GENDER, CLASSNO, STUDGRADE) Is STUDGRADE FFD (STUDNO, CLASSNO) ?

Yes. Since STUDGRADE depends on both STUDNO and CLASSNO, STUDGRAFE is fully functionally dependent on both of them. Is STUDGRADE FFD (STUDNO, GENDER, CLASSNO) ? No. Since STUDGRADE only depends on STUDNO and CLASSNO, which is a subset of STUDNO, GENDER, CLASSNO.

Transitive dependency In a table / relation R(A, B, C), suppose R.A then we can deduce that R.A dependent on R.A under relation R. Example: SUPPLIER SCITY CITYTAX Toledo S2 Chicago S3 Toledo S4 Atlanta S5 Atlanta S6Atlanta A r e l a t i o n i s i n 1 N F i f a R.B and R.B R.C, but not R.B R.C. We say that R.C is transitively R.A,

S1

In the above relation, SUPPLIER SCITY. SCITY CITYTAX. By default, SUPPLIER CITYTAX. In this situation, we say CITYTAX is transitively dependent on SUPPLIER.

Steps in Database Design There are two major steps in database design: Logical Database Design: Choose a set of tables that odel the problem of interest. Physical Database Design: Design the physical structures used to represent the logical design. This step may include denormalization, choosing indexes, and other measures. Normal Forms 1NF

ll underlying domains contain atomic values only (no restrictions at all of functional dependencies) Informal definition : a relation is in 1NF if at every column, there exists one value, never a set of values. Example of a relation that is not in 1NF :

10 % 5% 10 % 7.5 % 7.5 % 7.5 %

SNAME

MAJOR

Anne Smith Tommy Lee Bob Johnson To solve it, we need to create another row

SNAME MAJOR Anne Smith Tommy Lee Tommy Lee Bob Johnson CS CS EE CE

2NF A relation is in 2NF iff it is in 1NF and every non-key attribute is fully FD on the primary key (i.e., 2NF allows transitive dependencies, but requires dependency on a single, minimal primary key) In simple language, the 2NF is violated when there is a non-key attribute that is a fact (directly or transitively) about subset of the primary key. Example: INVENTORY (PART, WAREHOUSE, QTY, WAREHOUSE_ADDR) Question: is the INVENTORY table is in 2NF ? Answer: No. It is not in 2NF because WAREHOUSE_ADDR is a fact about WAREHOUSE and not about both PART and WAREHOUSE, which is the primary key. To normalize this relation, we need to break the table into 2. PART (PART, WAREHOUSE, QTY) WAREHOUSE (WAREHOUSE, WAREHOUSE_ADDR)

3NF A relation is in 3NF if it is in 2NF and every non-key attribute is non-transitively dependent on the primary key (note that in the case of multiple candidate keys, their dependencies are not specified). In simple language, the 3NF is violated when a non-key attribute is not directly dependent on the primary key. Example: DEPT (DEPTNO, DNAME, LOC, LOCTAX) Question: Is the DEPT relation in 2NF ? Answer: Yes. It is in 2NF because every non-key attribute is a fact about the primary key. DNAME is a fact about DEPTNO (direct dependence) LOC is a fact about DEPTNO (direct dependence) LOCTAX is a fact about DEPTNO (transitive dependence through LOC)

Question : Is the DEPT relation in 3NF ? Answer: No. It is not.

The DEPT table is not in 3NF because LOCTAX transitively dependent on DEPTNO. To satisfy 3NF, we decompose the table into two tables. DEPT (DEPTNO, DNAME, LOC) TAX (LOC, LOCTAX)

Question: The original DEPT table also violates which of the Roberts rules ? Answer: Rule 1 It has 2 entity types department and tax. Rule 2 Tax rate is represented multiple times. When we have LOC, we also have LOCTAX.

Anomalies Progression of anomalies of 1NF, 2NF and their cure in 3NF, duly noted and discussed. BCNF (Boyce-Codd Normal Form) The original definition of 3NF had these problems : Did not deal with cases of multiple candidate keys Did not deal with composite candidate keys Did not deal with overlapping candidate keys BCNF eliminates those problems. In some case where none of these condition is present, then it reduces the design to 3NF. Terminology Functional Determinant : Any attribute on which another attribute is fully functionally dependent.

A relation is said to be in BCNF iff every determinant is a candidate key. Example #1: SUPPLIER (SUPPLIER#, SNAME, STATUS, CITY)

Where SUPPLIER# and SNAME are both candidate keys, and STATUS and CITY are mutually independent. SSP (SUPPLIER#, SNAME, PART#, QTY) Where candidate keys are (SUPPLIER#, PART#) and (SNAME, PART#). The relation is not in BCNF because the relation contains two determinants, S# and SNAME, that are not candidate keys for the relation (they are determinants because each of them determines the other). In other words, we know the fact that: SUPPLIER# is the determinant for SNAME SNAME is the determinant for SUPPLIE# (SUPPLIER#, PART#) or (SNAME, PART#) is the determinant for QTY However, SUPPLIER# and SNAME themselves are not candidate keys. Note that SSP is in 3NF by the old definition (because 3NF does not require an attribute that is part of an alternate key to be FFD on the primary key). Although it is in 3NF, it has some of the update anomalies of 1NF and 2NF! For this example, break the table into two projections. SS (SUPPLIER#, SNAME) and SP (SUPPLIER#, PART#, QTY) Or SS (SUPPLIER#, SNAME) and SP (SNAME, PART#, QTY) In this case, all are in BCNF. Which is the better choice ? (depends on usage) Note: Usually a schema/table is in 3NF but is NOT in BCNF if it contains overlapping composite candidate keys.

4NF Terminology Multi-valued Dependency (MVD) A given relation R with attributes A, B, and C, the multi-valued dependence (MVD) R.A R.B

holds in R iff the set of B-values matching a given (A-value, C-value) pair in R depends only on the A-value and is dependent of the C-value. A, B, and C may be composite. Example: An employee can have one salary - this is a single-

valued fact. An employee can have many cars - this is a multi-valued fact.

A relation R is in 4NF iff whenever there exists an MVD in R, other than the MVD, there is only key data in tuples of R. In other words, an MVD is not allowed in the same relation with FDs. Informal definition: A relation is in 4NF iff it is in 3NF and contains at most one MVD. The Fourth Normal Form deals with multi-valued facts. Under Fourth Normal Form, a record type should not contain two or more independent multi-valued facts about an entity. Independence means that the facts should have no direct connection between themselves. Pairing these facts together should convey no information.

Example #1: EMP(EMPLOYEE, SKILL, LANGUAGE) In this example, an employee can have several skills and several languages. It can be seen that there are two many-to-many relationships, one between EMPLOYEE and SKILLS, and the other between EMPLOYEE and LANGUAGE. SKILLS and LANGUAGE are independent of each other in that there is no direction connection between them. No information is being conveyed when SKILLS and LANGUAGE are put together. Therefore, this relation is not in 4NF. To normalize this record, it needs to be divided into two records: EMP1(EMPLOYEE, SKILL) EMP2(EMPLOYEE, LANGUAGE) Example #2: COURSE 227 227 227 227 TEACHER Narah ari A Narah ari B Robert s C Robert s D BOOK

Constraint: there is only one course allowed in a table. The above relation is in 4NF because there is only one MVD in the table: (COURSE, TEACHER) Example #3: COURSE 227 227 227 227 227 227 227 227 EVENING Mon Mon Tue Tue Fri Fri Sat Sat TEACHER Na rah ari A Na rah ari B Na rah ari A Na rah ari B Ro ber ts C Ro ber ts D Ro ber ts C Ro ber ts D Constraint: there is only one course allowed in a table. The above relation is not in 4NF because there are two MVDs in the table: 1. (COURSE, TEACHER) 2. (COURSE, TEACHER) EVENING BOOK

5NF A relation is said to be in 5NF iff it cannot be expressed as a join of projections that

have distinct keys Example #1: NAME Joe Joe Joe Helen Helen STORE Ajax Giant Kmart Ajax Giant PRODUCTLINE S h o e s S h o e s S h o e s C l o t h e s C l o t h e s Constraint: A sales person can only sell one product line. The above relation can be decomposed into 3 tables and still give us the same information when we perform a join between them. NAME STOR E Joe Joe Helen A j a x G i a n t K m a r t

Helen Helen

Ajax Giant

NAME PRODUCTLINE Joe Helen Shoes Clothes

STORE PRODUCTLINE Ajax Ajax Giant Giant Kmart S h o e s C l o t h e s S h o e s C l o t h e s S h o e s Now, suppose a sales person can sell more than one product lines. NAME STORE PRODUCTLINE S h o e s S

Example #2:

Joe Joe Joe Helen Helen Helen

Ajax Giant Kmart Ajax Giant Kmart

h o e s S h o e s C l o t h e s C l o t h e s S h o e s

The above relation is in 5NF because it can not be decomposed and still give us the same information when we perform a join between the decompositions. Note: Be care of that smaller table with same key is excluded. If any decomposition is of same key, then the table is in 5NF like: Emp (Emp_No, Ename, Job, Salary, Dept_No) it can be decomposed into several tables but all have same key "Emp_No", so it's in 5NF. Codds 12 Rules 1. All information is represented by values in tables 2. Every data items can be accessed based on table name, primary key value and column name 3. Null values are supported for representing missing information and inapplicable information in a systematic way, independent of data type 4. The database descriptions represented in the same way as ordinary data, that can be interrogated in the same way as otherdata 5. There must be some language, expressible as character strings, that supports all of the following functions: Data definition View definition Data manipulati on Integrity constraints Authorizati on Transactio n boundaries 6. All views that are theoretically updateable by the system 7. The capability of handling a base relation or a derived relation as a single operand applies not only to the retrieval of data but also to the insertion, update, and deletion of data 8. Application program and terminal activities remain logically unimpacted whenever any changes are made in either storage representations or access methods

9. Application programs and terminal activities remain logically unimpacted when informationpreserving changes of any kind that theoretically permit unimpairment are made to the base table 10. Integrity constraints specific to a particular relational database must be definable in the relational data language and storable in the catalog 11. A relational database has distribution independence 12. If the relational system has a low-level language, that low level cannot be used to subvert or bypass the integrity rules and constraints expressed in the higher level relational language

14 of 14 1/28/2008 7:35 PM