COURSE CODE: CIT 844 COURSE TITLE: ADVANCED DATABASE MANAGEMENT SYSTEM

Transcription

1 NATIONAL OPEN UNIVERSITY OF NIGERIA COURSE CODE: CIT 844 COURSE TITLE: ADVANCED DATABASE MANAGEMENT SYSTEM

2 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM COURSE GIUDE ADVANCED DATABASE MANAGEMENT SYSTEM Course Developer/Writer Dr. Olusegun Folorunso Department of Computer Science University of Agriculture Abeokuta Programme Leader Prof. Afolabi Adebanjo National Open University of Nigeria Course Coordinator National Open University of Nigeria Page ii

3 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM NATIONAL OPEN UNIVERSITY OF NIGERIA CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM National Open University of Nigeria Headquarters 14/16 Ahmadu Bello Way Victoria Island Lagos Abuja Office No. 5 Dar es Salaam Street Off Aminu Kano Crescent Wuse II, Abuja Nigeria centralinfo@nou.edu.ng URL: Published by National Open University of Nigeria Printed ISBN: XXX-XXX-XXX-X All Rights Reserved Page iii

4 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM CONTENTS PAGE Introduction... v What you will Learn in this Course. v Course Aims. vi Course Objectives. vi Working through this Course... vi Course Materials... vi Online Materials... vii Study Units... vii Equipments.. viii Assessment.. ix Tutor-Marked Assignment... ix Course Overview.... x How to Get the Most from this Course... x Summary.. xi Page iv

5 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM Introduction The course, Advanced Database Management System, is a core course for students studying towards acquiring the Master of Science in Information Technology. In this course we will study about the Database Management System as a key role in Information Management. Various principles of database management system (DBMS) as well as its advanced features are discussed in this course. This course also considers distributed databases and emerging trends in database system. The overall aim of this course is to introduce you to various ways of designing and implementing database systems, features and distributed databases. In structuring this course, we commence with the basic design and implementation of relational databases. There are four modules in this course, each module consists of units of topics that you are expected to complete in 2 hours. The four modules and their units are listed below. What You Will Learn in this Course The overall aims and objectives of this course provide guidance on what you should be achieving in the course of your studies. Each unit also has its own unit objectives which state specifically what you should be achieving in the corresponding unit. To evaluate your progress continuously, you are expected to refer to the overall course aims and objectives as well as the corresponding unit objectives upon the completion of each. Page v

6 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM Course Aims The overall aims and objectives of this course will help you to: 1. Develop your knowledge and understanding of the underlying principles of Relational Database Management System 2. Build up your capacity to learn DBMS advanced features 3. Develop your competence in enhancing database models using distributed databases 4. Build up your capacity to implement and maintain an efficient database system using emerging trends. Course Objectives Upon completion of the course, you should be able to: 1. Describe the basic concepts of Relational Database Design 2. Explain Database implementation and tools 3. Describe SQL and Database System catalog. 4. Describe the process of DB Query processing and evaluation. 5. Discuss the concepts of transaction management. 6. Explain the Database Security and Authorization. 7. Describe the design of Distributed Databases. 8. Know how to design with DB and XML. 9. Describe the basic concept of Data warehousing and Data mining 10. Discuss the emerging Database Models Technologies and Applications Working through this Course We designed this course in a systematic way, so you need to work through it from Module one, Unit 1 through to Module four, Unit 3. This will enable you appreciate the course better. Course Materials Basically, we made use of textbooks and online materials. You are expected to I, search for more literature and web references for further understanding. Each unit has references and web references that were used to develop them. Page vi

7 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM Online Materials Feel free to refer to the web sites provided for all the online reference materials required in this course. The website is designed to integrate with the print-based course materials. The structure follows the structure of the units and all the reading and activity numbers are the same in both media. Study Units Course Guide Module 1: Database Design and Implemental Unit 1: Relational Database Design Unit 2: Database Implementation & Tools Unit 3: Advance SQL Unit 4: Database System Catalog Module 2: DBMS Advance Features Unit 1: Query Processing & Evaluation Unit 2: Transaction Management and Recovery Unit 3: Database Security & Authorization Module 3: Distributed Databases Unit 1: Enhanced Database Models Unit 2: Object Oriented Database Unit 3: Database and XML Unit 4: Introduction To Data Warehousing Unit 5: Introduction to Data Mining Module 4: Emerging Trends and Example of DBMS Architecture Unit 1: Emerging Database Models Page vii

8 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM Unit 2: Technologies and Applications Unit 3 PostgreSQL & Oracle Module one describes Database Design and Implementation. Module Two explains the DBMS advanced features. Module Three discusses the Distributed Database. Module Four discusses Emerging trends in DBMS including technologies and applications. Equipment In order to get the most from this course, it is essential that you make use of a computer system which has internet access. Recommended System Specifications: Processor 2.0 GHZ Intel compatible processor 1GB RAM 80 GB hard drive with 5 GB free disk CD-RW drive. 3.5" Floppy Disk Drive TCP/IP (installed) Operating System Windows XP Professional (Service Pack 2) Microsoft office 2007 Norton Antivirus Monitor* 19-inch 1024 X 768 Resolution 16-bit high color *Non Standard resolutions (for example, some laptops) are not supported. DBMS Tools ORACLE PostgreSQL Hardware Open Serial Port (for scanner) 120W Speakers Mouse + pad Page viii

9 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM Windows keyboard Laser printer Hardware is constantly changing and improving, causing older technology to become obsolete. An investment in newer, more efficient technology will more than pay for itself in improved performance results. If your system does not meet the recommended specifications, you may experience considerably slower processing when working in the application. Systems that exceed the recommended specifications will provide better handling of database files and faster processing time, thereby significantly increasing your productivity. Assessment The course, Advanced Database Management Systems entails attending a two-hour final examination which contributes 50% to your final grading. The final examination covers materials from all parts of the course with a style similar to the Tutor- marked assignments. The examination aims at testing your ability to apply the knowledge you have learned throughout the course, rather than your ability to memorize the materials. In preparing for the examination, it is essential that you receive the activities and Tutor-marked assignments you have completed in each unit. The other 50% will account for all the TMA s at the end of each unit. Tutor-Marked Assignment About 20 hours of tutorials will be provided in support of this course. You will be notified of the dates, time and location for these tutorials, together with the name and phone number of your tutor as soon as you are allotted a tutorial group. Your tutor will mark and comment on your assignments, keep a close watch on your progress and on any difficulties you might encounter and provide assistance to you during the course. You must mail your TMAs to your tutor well before the due date (at least two working days are required). They will be marked by your tutor and returned to you as soon as possible. Do not hesitate to contact your tutor by phone, if you need help. Page ix

10 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM The following might be circumstances in which you would find help necessary. You can also contact your tutor if: you do not understand any part of the study units or the assigned readings you have difficulty with the TMAs you have a question or problem with your tutor s comments on an assignment or with the grading of an assignment You should try your best to attend tutorials, since it is the only opportunity to have an interaction with your tutor and to ask questions which are answered instantly. You can raise any problem encountered in the course of your study. To gain maximum benefit from the course tutorials, you are advised to prepare a list of questions before attending the tutorial. You will learn a lot from participating in discussions actively. Course Overview This section proposes the number of weeks that you are expected to spend on the three modules comprising of 30 units and the assignments that follow each of the unit. We recommend that each unit with its associated TMA is completed in one week, bringing your study period to a maximum of 30 weeks. How to Get the Most from this Course In order for you to learn various concepts in this course, it is essential to practice. Independent activities and case activities which are based on a particular scenario are presented in the units. The activities include open questions to promote discussion on the relevant topics, questions with standard answers and program demonstrations on the concepts. You may try to delve into each unit adopting the following steps: 1. Read the study unit 2. Read the textbook, printed or online references 3. Perform the activities 4. Participate in group discussions 5. Complete the tutor-marked assignments 6. Participate in online discussions This course makes intensive use of materials on the world-wide web. Page x

11 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM Specific web address will be given for your reference. There are also optional readings in the units. You may wish to read these to extend your knowledge beyond the required materials. They will not be assessed. Summary The course, Advanced Database Management Systems is intended to develop your understanding of the basic concepts of database systems, thus enabling you acquire skills in designing and implementing Database Management Systems. This course also provides you with practical knowledge and hands-on experience in implementing and maintaining a system. We hope that you will find the course enlightening and that you will find it both interesting and useful. In the longer term, we hope you will get acquainted with the National Open University of Nigeria and we wish you every success in your future. Page xi

12 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM ADVANCED DATABASE MANAGEMENT SYSTEM MAIN COURSE Course Developer/Writer Dr. Olusegun Folorunso Department of Computer Science University of Agriculture Abeokuta Programme Leader Prof. Afolabi Adebanjo National Open University of Nigeria Course Coordinator National Open University of Nigeria NATIONAL OPEN UNIVERSITY OF NIGERIA Page xii

13 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM National Open University of Nigeria Headquarters 14/16 Ahmadu Bello Way Victoria Island Lagos Abuja Office No. 5 Dar es Salaam Street Off Aminu Kano Crescent Wuse II, Abuja Nigeria centralinfo@nou.edu.ng URL: Published by National Open University of Nigeria Printed ISBN: XXX-XXX-XXX-X All Rights Reserved Page xiii

14 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM CONTENTS PAGE MODULE 1: Database Design and Implementation Unit 1: Relational Database Design. 1.0 Introduction Objectives What is Relational Database? Relational Database Model Concept Relational Constraints and Relational Database Schemas Update operations and Dealing with Constraint Violations Relational Database Design The Entity Relational (ER) model An Illustration of a Company Database Application Entity Types, Entity Set, Attributes and keys Entity Types, Entity Set, Key and Value Set Pitfalls in a Relational Database Design Normalization Conclusion Summary Tutor Marked Assignment Further Reading. 59 Page xiv

15 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM Unit 2: Database Implementation 2.0. Introduction Objectives Conceptual Design Information Sources and Users E-R Model Verification Logical Design Physical Design Implementation Database Creation Database Loading and Conversion System Procedures Testing and Evaluation Performance Measures Security Measures Operations Conclusion Summary Tutor Marked Assignment Further Readings 79 Unit 3: Advanced SQL Introduction Objectives.. 80 Page xv

16 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM 3.2. What is SQL? Using SQL on a Relational Database SQL Statements Conclusion Summary Tutor Marked Assignment (TMA) Further Reading 109 Unit 4: Database System Catalogue 4.0. Introduction Objectives What is Database System Catalogue? Conclusion Summary Tutor Marked Assignment (TMA) Further Readings Module 2: Advanced Features and DBMS Unit 1: Query Processing & Evaluation 1.0. Introduction Objectives Query Interpretation Equivalence of Expressions Selection Operation 113 Page xvi

17 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM Natural Join Operations Projection Operations Estimation of Query-Processing Costs Estimation Of Costs of Access Using Indices Join Strategies Simple Iteration Block-Oriented Iteration Merge-Join Use of an Index Three-Way Join Structure of Query Optimizer Conclusion Summary Tutor-Marked Assignment (TMA) Further Readings Unit 2: Transaction Management & Recovery 2.0. Introduction Objectives What is a Transaction? Transaction Properties Transaction Management with SQL The Transaction Log Types of Transaction Log Records Page xvii

18 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM 2.3. Concurrency Control Concurrency control with Locking Methods Types of Locks Two-Phase Locking to Ensure Serializablility Deadlocks Concurrency Control with Time Stamping Methods Concurrency Control with Optimistic Methods Optimistic Concurrency Control phases Database Recovery Management Conclusion Summary Tutor-Marked Assignment (TMA) Further Readings Unit 3: Database Security &Authorization 3.0. Introduction Objectives Security and Integrity Violations Authorization & Views Integrity Constraints Encryption Statistical Databases Conclusion Summary Tutor-Marked Assignment (TMA). 149 Page xviii

19 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM Further Readings. 149 Module 3: Distributed Databases Unit 1: Enhanced Database Model 1.0. Introduction Objectives Distributed Databases Structure of Distributed Databases Trade-offs in Distributing the database Advantages of Data Distribution Disadvantages of Data Distribution Design of Distributed Databases Data Replication Data Fragmentation Data Replication and Fragmentation Transparently and Autonomy Naming and local Autonomy Replication and Fragmentation Transparency Location Transparency Complete Naming Scheme Transparency and Update to Replicated Data Distributed Query Processing Replication and Fragmentation 163 Page xix

20 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM Simple Join Processing Join Strategies Semijoin Strategies Recovery in Distributed Systems System Structure Robustness Commit Protocols Concurrency Control Locking Protocols Time Stamping Deadlock Handling Centralized Approach Fully Distributed Approach Coordinator Selection Backup Coordinators Election Algorithms Conclusion Summary TMA Further readings. 183 Unit 2: Object Orientated Database 2.0. Introduction Objectives Features of an Object-Orientated DBMS. 184 Page xx

21 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM 2.3. Object-Oriented Database Design How OO Concept has Influenced the Relational Model Conclusion Summary TMA Further Readings 190 Unit 3: Database and XML 3.0 Introduction Objectives Define the Purpose of XML XML Trees XML Syntax Rules XML Elements XML Naming Rules XML Attributes Conclusion Summary TMA Further Reading Unit 4: Introduction to Data Warehousing 4.0 Introduction Page xxi

22 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM 4.1 Objective What is Data Warehousing? Data Warehouse Architectures Data Warehouse Architecture (Basic) Data Warehouse Architecture (With a Staging Area) Data Warehouse Architecture (With a Staging Area and Data Mart) Logical Versus Physical Design in Data Warehouse Data Warehousing Schema Data Warehousing Objects Fact Tables Dimension Tables Summary Conclusion TMA Further Readings 220 Unit 5: Introduction to Data Mining 5.0. Introduction Objectives Data Mining Uses Data Mining Functions Data Mining Technologies Summary. 225 Page xxii

23 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM 5.6. Conclusion TMA Further Readings. 226 Module 4: Emerging Trends and Examples of DBMS Architecture Unit 1: Emerging Database Models 1.0. Introduction Objectives Limitations of Conventional Databases What is Multimedia Database? Temporal Databases: Modelling Temporal data: Temporal SQL Introduction Temporal Data Semantics Temporal Data Models and Query Languages Temporal DBMS Implementation Query Processing Implementing Algebraic Operators Indexing Temporal Data Outlook Conclusion Summary Tutor Marked Assignment Further Reading. 242 Page xxiii

24 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM Unit 2: The Major Application Domains 2.0 Introduction Objectives Database on the World Wide Web GIS Application Specific GIS Data Operations An Example of A GIS: Arc-Info GENOME Data Management Biological Sciences and Genetics Characteristics of Biological Data The Human GENOME Project and Existing Biological Databases Digital Libraries Conclusion Summary Further Reading. 252 Unit 3 PostgreSQL 3.0 Introdection Objectives What is PostgreSQL PostgreSQL and other DBMS s Open Source Software Conclusion Summary. 259 Page xxiv

25 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM 3.7 Tutor Marked Assignment Further Reading MODULE 1: DATABASE DESIGN & IMPLEMENTATION UNIT 1: RELATIONAL DATABASE DESIGN 1.0 INTRODUCTION This unit discusses extensively on relational data model. The model was first introduced by Ted Codd of IBM research in 1970 in a classic paper, and attracted immediate attention due to its simplicity and mathematical foundations. The model uses the concept of mathematical relation, which looks somewhat like a table of values, as its basic building blocks, and has its theoretical basics in set theory and first order predicate logic. In this unit, we will discuss the basic characteristics for the relational model and its normalization processes. The model has been implemented in a large number of commercial systems over the last years. 1.1 OBJECTIVES. To understand the relational database model. To understand the concepts of normalization in database design 1.2 WHAT IS RELATIONAL DATABASE? A relational database is a database that groups data using common attributes found in the data set. The resulting "clumps" of organized data are much easier for people to understand. For example, a data set containing all the real estate transactions in a town can be grouped by the year the transaction occurred; or it can be grouped by the sale price of the transaction; or it can be grouped by the buyer's last name; and so on. Such a grouping uses the relational model (a technical term for this is schema). Hence such a database is called a "relational database. The software used to do this grouping is called a relational database management system. The term "relational database" often refers to this type of software. Relational databases are currently the predominant choice in storing financial records, manufacturing and logistical information, personnel data and much more Relational Database Model Concept. Page xxv

26 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM The relational model represents the database as a collection of relations. Informally, each relation resembles a table of values or, to some extent a flat file of record. For example, the university database of files that was shown earlier is considered to be in the relational model. However, there are important differences between relations and files, as we shall soon see. When a relation is thought of as a table of values, each row in the table represents a collection of related data values. In the relational model, each row in the table represents a fact that typically corresponds to a real world entity or relationship. The table name and column names are used to help in interpreting the meaning of the row which represents facts about a particular student entity. The column names Name, Student, Number, Class, Major specify how to interpret the data values in each row, based on the column each value is in. All values in a column are of the same data type. In the formal relational model terminology, a row is called a tuple, a column header is called an attribute, and the table is called a relation. The data type describing the types of values that can appear in each column is called a domain. We now define these terms domain, tuple, attribute, and relation more precisely. Page xxvi Domains, Attributes, Tuples, & Relations A domain D is a set of atomic values. By atomic we mean that each value in the domain is indivisible as far as the relational model is concerned. A common method of specifying a domain is to specify a data type from which the data values forming the domain are drawn. It is also useful to specify a name for the domain, to help in interpreting its values. Some examples of domains follow: GSM phone numbers: The set of 11 digit numbers valid in the Nigeria. E.g Local phone numbers: The set of 6 digit phone numbers valid within a particular area code in Nigeria. E.g Names: The set of names of persons. Grade point averages: Possible values of computed grade point averages; each must be a real (floating point) number between 0 and 5 Employee ages: Possible ages of employees of a company, each must be a value between 18 and 65 years old Academic department names: The set of academic department names, such a computer science, economics and physics, in a university.

27 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM Academic department codes: The set of academic department codes, such as CSC, ECON, and PHYS, in a university. The preceding are called logical definitions of domains. A data type of format is also specified on each domain. For example, the data type for the domain GSM phone numbers can be declared as a character string of the form (dddd)dddd ddd, e.g where each d is a data type. For Employee ages, the data type is an integer number between 18 and 65, for Academic department names, the data type is the set of all character strings that represent valid department names. A domain is thus given a name, data type, and format. Additional information for interpreting the values of a domain can also be given. For example, a numeric domain such as person weights should have the units of measurement kilograms. A relations schema, denoted by, is made up of a relation name R and a list of attributes. Each attributes is the name of a role played by some domain in the relation schema. is called the domain of, and is denoted by. A relation schema is used to describe a relation is called the name of this relations. The degree of a relation is the number of attributes of its relation schema. An example of a relation schema for a relation of degree 7, which describes university students, is the following: Table 1.0 The attributes and tuples of a relation STUDENT Page xxvii

28 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM STUDENT (Name, SSN, HomePhone, Address, OfficePhone, Age, GPA) Attributes Relation Name Student Name Ssn Home phone Address Office Phone Age Gpa Olumide Enoch , Kings way Rd. null Adamson Femi , Allen Avenue null Tuples Yisa Ojo null 34,Obantoko Road Charles Olumo Grammar School Johnson Paul , Paul Job Road null For this relation schema, STUDENT is the name of the relation, which has seven attributes. We can specify the following previously defined domains for some of the attributes of the STUDENT relations: Page xxviii

29 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM A relation or relation state of the relation schema also denoted by, is a set of n tuples. Each n tuple t is an ordered list of n values, where each value, is an element of or is a special null value. The value in tuple t, which correspondence to the attribute is referred to as. The terms relation intension for the schema and relation extension for a relation state are also commonly used. Table 1.0 shows an example of a STUDENT relation, which corresponds to the STUDENT schema specified above. Each tuple in the relation represents a particular student entity. We display the relation as a table, where each tuple is shown as a row and each attribute corresponds to a column header indicating a role or interpretation of the values in that column. Null values represent attributes whose values are unknown or do not exist for some individual STUDENT tuples. Page xxix

30 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM The above definitions of a relation can be restated as follows. A relation is a mathematical relation of degree n on the domains, which is a subset of the Cartesian product of the domains that define : The Cartesian product specifies all possible combinations of values from the underlying domains. Hence, if we denote the number of values or cardinality of a domain D by D, and assume that all domains are finite, the total number of tuples in the Cartesian product is: Characteristics Of Relations The earlier definition of relations implies certain characteristic that makes a relation different from a file or a table. We now discuss some of these characters. Ordering of Tuples in a Relation: A relation is defined as a set of tuples. Mathematically, elements of a set have no order among them; hence tuples in a relation do not have any particular order. However in a file, records are graphically stored on disk so there always is an order among the records. This ordering indicates first, second, and last records in the file. Similarly, when we display a relation as a table, the rows are displayed in a certain order. Page xxx

31 CIT 844 ADVANCED DATABASE MANAGEMENT SYSTEM Tuple ordering is no part of a relation definition, because a relation attempts to represent facts at a logical or abstract level. Many logical orders can be specified on a relation, for example, tuples in this STUDENT relation in Table 1.0 could be logically ordered by values of Name, SSN, Age, or some other attribute. The definition of a relation does not specify any order, there is no preference for one logical ordering over another. Hence, the relation displayed in Table 1.1 is considered identical to the one shown in Table 1.0. When a relation is implemented as a file, a physical ordering may be specified on the records of the file. Ordering of values within a tuple, and an alternative definition of a relation: According to the preceding definition of a relation, an n tuple is an ordered list of n values, so the ordering of values in a tuple and hence of attributes in a relation schema. An alternative definition of relation can be given, making the ordering of value in a tuple unnecessary. In this definition, a relation schema R = (A 1,A 2,..., A n ) is a set of attributes and relation is a finite set of mappings r = [t 1,t 2,,t m ], where each tuple is a mapping from R to D, and D is the union of attribute domains; that is,. Table 1.1. The relation STUDENT from Table 1.0, with a different order of tuples. Student Name Ssn Home phone Address Office Phone Age Gpa Olumide Enoch , Kings way Rd. Null Adamson Femi , Allen Avenue null Tuples Yisa Ojo Null 34,Obantoko Road Charles Olumo , Grammar School Johnson Paul , Paul Job Road null In this definition, t(a 1 ) must be in dom(a 1 ) for called a tuple. for each mapping t in r. Each mapping is t=<(name; Yisa Ojo), (SSN, ), (HomePhone, null), (Address, 34 Obantoko Road). (Office Phone, ), (GPA, 2.89), (HomePhone, null) > ), (GPA, 2.89), (HomePhone; null)> Page xxxi Figure 1.0 Two identical tuples when order of attributes and values in not part of the definition of relation.

32 According to this definition, a tuple can be considered as a set of (<attribute>, <value>) pairs, where each pair gives the value of the mapping form an attributes A 1 to a value v 1 from dom(a 1 ). The ordering of attributes is not important, because the attribute name appear with its value. By this definition, the two tuples shown in figure 1.0 are identical. This makes sense at an abstract or logical level, since they are really in no reason to prefer having one attribute value appear before another in a tuple. When a relation is sense at an abstracts are physically ordered as fields within a records. We will use the first definition of relation, where the attributes and the values within tuples are ordered, because it simplifies much of the notation. However, the alternative definition given here is more general. Values in the Tuples: Each value in a tuple is an atomic value; that is, it is not divisible into components within the framework of the basic relational model. Hence, composite and multi valued attributes are not allowed. Much of the theory behind the relational model was developed with this assumption in mind, which is called the first normal form assumption. Multi valued attributes must be represented by separate relations, and composite attributes are represented only by their simple component attributes. Recent research in the relational model attempt to remove these restrictions by using the concepts of no first normal form or nested relations. Interpretation of a Relation: The relation schema can be interpreted as a declaration or a type of assertion. For example, the schema of the STUDENT relation of Table 1.0 asserts that, in general, student entity has a Name, SSN, Home phone, Address, Office phone, Age, and GPA. Each tuple in the relation can then be interpreted as a fact or a particular instance of the assertion. For example, the first tuple in Table 1.0 asserts the fact that there is a STUDENT whose name is Olutunde Enoch, SSN is , Age in 19 and so on. Notice that some relations may represent facts about entities, whereas other relations may represent fact about relationship. For example, a relation schema MAJORS (Student SSN, Department Code) asserts that students major in academic department, a tuple in this relation relates a student to his or her major department. Hence, the relational model represents fact about both entities and relationship uniformly as relations Relational Constraints And Relational Database Schemas In this unit, we discuss the various restrictions on data that can be specified on relational database schema in the form of constraints. These include domain constraints, key strains, called data dependencies (which include functional dependencies and multi valued dependencies), are used mainly for database design by normalization. Page xxxii

33 Domain constraints Domain constraints specify that the value of each attribute A must be an atomic value from the domain dom(a). We have already discussed the ways in which domains can be specified above. The data types associated with domains typically include standard numeric data type for integers (such as short integer, long inter) and real number (float and double precision float). Character, fixed length strings, and variable length strings are also available, as are date, time, timestamp, and money data types. A sub range of values from a data type or an enumerated data type may describe other possible domains where all possible values are explicitly listed. Key constraints and constraints on null A relation is defined as a set of tuples. By definition, all elements of a set are distinct, hence, all tuples in relation must also be distinct. This means that no two tuples can have the same combination of values for all their attributes. Usually, there are other subsets of attributes of a relation schema R with the property that no two tuples in any relation state r of R should have the same combination of values for these attributes. Suppose that we denote one such subset of attributes by SK; then for any two distinct tuples t 1 and t 2 in a relation sate r or R, we have the constraint that t 1 [SK] 1 t 2 [SK]. Any such set attributes SK is called a superkey of the relation schema R. A superkey SK specifies a uniqueness constraint that no two distinct tuples in a state r of R can have the same value for SK. Every relation has at least one default superkey the set of all its attributes. A superkey can have redundant attributes, however, so a more useful concept is that of a key, which has no redundancy. A key K of a relation schema R is a superkey of R with the additional property that removing any attribute A from K leaves a set of attributes K that is not a superkey of R. Hence, a key is a minimal superkey that is, a superkey from which we cannot remove any attributes and still have the uniqueness constraint hold. For example, consider the STUDENT relation of Table 1.0 the attribute set (SSN) is a key of STUDENT because no two student tuples can have the same value for SSN. Any set of attributes that include SSN for example, (SSN, Name, Age) is a superkey. However, the superkey (SS, Name, Age) is not a key for STUDENT, because removing Name or Age of both from the set still leaves us with a superkey. The value of key attribute can be used to identify uniquely each tuples in the relation. For example, the SSN value identifies uniquely the tuples corresponding to Benjamin Page xxxiii

34 Bayer in the STUDENT relation. Notice that a set of attributes constituting a key is a property of the relation schema; it is a constraint that should hold on every relation state of the schema. A key is determined from the meaning of the attributes, and the property is time invariant; it must continue to hold when we insert new tuples in the relation. For example, we cannot and should not designate the Name attribute of the student relation in Table 1.0 as a key, because there is no guarantee that two student with identical names will never exist. In general, a relation schema may have more than one key. In this case, each of the keys is called a candidate key. For example, the CAR relation in Table 1.2 has candidate keys: License Number and Engine Serial Number. It is common to designate the candidate key as the primary key of the relation. This is the key whose value is used to identify tuples in the relation. We use the convention that the attributes that form the primary key of a relation schema are underlined, as shown in Table 1.2. Notice that, when a relation schema has several candidate key, the choice of one to become primary key is arbitrary; however, it is usually better to choose a primary key with a single attribute or a small number of attributes. Another constraint on attributes specifies whether null values are or are not permitted. For example, if every student tuple must have a valid non null value for the Name attribute, then Name of student is constrained to be NOT null. Table 1.2 The CAR relation wish two candidate key: license Number and Engine Serial number. CAR License Number Engine Serial Number Make Model Year AB 419 KJA A69352 BMW 800 series 96 XA 893 AKM B43696 Bluebird Datsun 99 AAB383 WDE X83554 Datsun Toyota 95 LA 245 YYY C43742 Golf Volkswagen 93 DE382 MNA Y82935 Mercedes 190 D 98 FE 107 EKY U Toyota Toyota 98 Relational Databases And Relational Database Schemas So far, we have discussed single relations and single relation schemas. A relational database usually contains may relations, with tuples relations that are related in various ways. In these units we define a relational database and a relational database schema is a set of relation schema database state DB of and a set of integrity constraints IC. A relational Page xxxiv

35 a set of relation states such that each is a state of and such that the relation states satisfy the integrity constraints specified in IC. Figure 1.1 shows a relational database schema EMPLOYEE DEPARTMENT DEPT LOCATIONS FNAME MINIT LNAME SSN BDATE ADDRESS SEX SALARY SUP DNO DNAME DNUMBER MGRSSN MGRSTARTDATE DNUMBER DLOCATION PROJECT WORK ON DEPENDENT PNAME PNUMBER PLOCATION DNUM ESSN PNO HOURS ESSN DEPENDENT NAME SEX BDATE RELATIONSHIP Figure 1.1. Schema diagram for the company relational database schema; the primary keys are underlined Update Operations And Dealing With Constraint Violations The operations of the relational model can be categorized into retrievals and updates. The relational algebra operations, which can be use to specify retrievals, are discussed in details in a later unit. In this unit, we concentrate on the update operations. There are three basic update operations on relations (1) insert, (2) delete and (3) modify. Insert is used to insert a new tuple or tuples in relation: Delete is used to delete tuple; and Update (or modify) is used to change the values of some attribute in existing tuple. Whenever update operations are applied, the integrity constraints specified on the relational database schema should not be violated. In this unit we discuss the type of constraints that may be violated by each update operation and the types of actions that may be taken if an update does cause a violation. THE INSERT OPERATION The insert operation provides a list of attribute values for a new tuple that is to be inserted into a relation R. Insertion can violate any of the four types of constraints discussed in the previous Page xxxv

36 unit. Domain constraints can be violated if an attribute value is given that does not appear in the corresponding domain. Key constraints can be violating if a key value in the new tuple t already exists in another tuple in the relation. Entity integrity can be violated if the primary key of the new tuple t is null. Referential integrity can be violated if the value of any foreign key in t refers to a tuple that does not exists in the referenced relation. Here are some example to illustrate this discussion. 1. Insert < Cecilia, F, Komolafe, null, , 6357 Adetutu, Lane, Abeokuta, OG, F 28000, null 4> into EMPLOYEE. This insertion violates the entity integrity constraint (null for the primary key SSN), so it is rejected. 2. Insert < Alice, J, Zachariah, , , 6357 Adetutu Lane, Abeokuta OG, F,28000, , 4> into EMPLOYEE. This insertion violates the key constraint because another tuple with the same SSN value already exists in the EMPLOYEE relation, and so it is rejected. 3. Insert < Folorunso, O, Olusegun, , Obasanjo Aremu OG, F,28000, , 7 > into EMPLOYEE. This insertion violates the referential integrity constraint specified on KNO because no DEPARTMENT tuples exists with DNUMBERS = Insert < Folorunso, O, Olusegun, , , 6357 Obasanjo Lane, Aremu, OG, F, 28000, null 4 > into EMPLOYEE. This insertion satisfies all constraints, so it is acceptable. If an insertion violates one or more constraints, the default option is to reject the insertion. In this case, it would be useful if the DBMS could explain to the user why the insertion was rejected. Another option is to attempt to correct the reason for rejecting the insertion, but this is typically not used for violations caused by insert; rather, it is used more often in correcting violations for Delete and Update. The following examples illustrate how this option may be used for insert violations. In operation 1 above, the DBMS could ask the user to provide a value for SSN and could accept the insertion if a valid SSN value was provided. In operation 3, the DBMS could either, ask the user change the value of DNO to some valid values (or set it to null), or it could ask the user to insert a DEPARTMENT tuple with DNUMBER =7 and could accept the insertion only after such an operation was accepted. Notice that in the latter case the insertion can cascade back to the EMPLOYEE relation if the user attempt to insert a tuple for department 7 with a value off MGRSS that does not exist in the EMPLOYEE relation. THE DELETE OPERATION The Delete operation can violate only referential integrity; If the foreign keys reference the tuple being deleted from other tuples in the database. To specify deletion, a condition on the attributes of the relation select the tuples (or tuples) to be deleted. Here are some examples. 1. Delete the WORKS ON tuples with ESS = and KPNO = 10. This deletion is acceptable. 2. Delete the employee tuple with SSN = This deletion is not acceptable, because tuples in works on refer to this tuple. Hence, if the tuple is deleted, referential integrity violation will result. Page xxxvi

37 3. Delete the employee tuple with SSN = This deletion will result in even worse referential integrity violations, because the tuple involved is referenced by tuples from the employee, department, works on, and department relations. Three options are available if a deletion operation causes a violation,. The first option is to reject the deletion. The second opting is to attempt to cascade ( or propagate) the deletion by deleting tuples that reference the tuple that is being deleted. For example in operation 2, the DBMS could automatically delete the offending tuples form works on with ESSN= A third option is a to modify the referencing attribute that cause the valid tuple. Notice that, if a referencing attribute that cause a violation is part of the primary key, it cannot be set to null otherwise, it would violate entity integrity. Combinations of these three options are also possible. For example, to avoid having operation 3 cause a violation, DBMS may automatically delete all tuples from works on and department with ESSN= Tuples in employee with super SSN = and changed to other valid values or to null. Although it may makes sense to delete automatically the works on and department tuples that refer to an employee tuples, it may not make sense to delete other employee tuples or a department tuple. In general, when a referential integrity constraint is specified, the DBMS should allow the user to specify which of the three options applies in case of a violation of the constraint. THE UPDATE OPERATION The update operation is used to change the values of one or more attributes in a tuple (or tuples) of some relation r. It is necessary to specify a condition on the attribute of the relation to select the tuple (or tuples) to be modified. Here are some examples. 1. Update the salary of the Employee tuple with SSN to Acceptable 2. Update the DNO of the employee tuple with SSN = to 1 Acceptable. 3. Update the DNO of the employee tuple with SSN = to 7 Unacceptable, because it violates referential integrity. 4. Update the SSN of the employee tuple with SSN = to Unacceptable, because it violates primary key and referential integrity constraints. Updating an attribute that is neither a primary key nor a foreign key usually cause no problems. The DBMS need only check to confirm that the new values as of the correct data type and domain. Modifying a primary key value is similar to deleting one tuple and the issues discussed earlier under both insert and delete comes into play. If a foreign key attribute is modified, the Page xxxvii

38 DBMS must make sure that the new value refers to an existing tuple in the referenced relation (or is null) Basic Relational Algebra Operations In addition to defining the database structure and constraints, a data model must include a set of operations to manipulate the data. A basic set of relational model operations constitutes the relational algebra. These operations enable the user to specify basic retrieval requests. The result of a retrieval is a new relation, which may have been formed from one or more relations. The algebra operations thus produce new relations, which can be further manipulated using operations of the same algebra. A sequence of relational algebra operations forms a relation algebra expression, whose result will also be a relation. The relational algebra operations are usually divided into two groups. One group includes set operations from mathematical set theory, these are applicable because each relation is defined to be a set of tuples. Set operations include UNION, INTERSECTION, SET DIFFERENCE, and CARTESIAN PRODUCT. The other group consists of operations developed specifically for relational database; these include select, project, and join among others. The select and project operations are discussed first, because they are the simplest, then we discuss set operations. Finally, we discuss join and other complex operations. The relational database shown in Table 1.3 is used for our examples. Some common database requests cannot be performed with the basic relational algebra operations, so additional operations are needed to express these requests. Some of these additional operations are described later. THE SELECT OPERATIONS The select operation is used to select a subset of the tuple from a relation that satisfy a selection condition. One can consider the select operation to be a filter that keeps only those tuples that satisfy a qualifying condition. For example, to select the employee tuples whose departments is 4, or those whose salary is greater than N30,000, we can individually specify each of these two conditions with a select operation as follows: In general, the SELECT operation is denoted by Where the symbol Page xxxviii

39 (sigma) is used to denote the SELECT operator, and the selection condition is a Boolean expression specified on the attributes of relation. Notice that is generally a relational algebra expression whose result is a relation; the simplest expression is just the name of database relation. The relation resulting from the select operations has the same attributes as. The Boolean expression specified in <selection condition> is made up of number of clauses of the form <attribute name> <comparison op><constant value> or <attribute name><comparison op><attribute name> where <attribute name> is the name of an attribute of is normally one of the operators {=<,>,e, and <constant value> is a constant value from the attribute domain. Clauses can be arbitrarily connected by the Boolean operators AND OR and NOT or form a general selection. For example, to select the tuples for all employees who either work in department 4 and make over N25,000 per year, or work in department 5 and make over N30,0000 we can specify the following select operation: Table 1.3 Result of select and project operations. (a) FNAME MINT LNAME SSN BDATE ADD SEX SAL SUPERSSN DNO Akin G Adeosun Ayo T Adeluola Daniel O Olayinka Fontren, Housing OG 291,Itoko, Abeokuta 34,Offmobil Road F M M (b) LNAME FNAME SALARY Adeosun Akin Page xxxix