DBMSit

Database Management Systems DATABASE MANAGEMENT SYSTEMS

2 MARKS - LECTURE NOTES Q BANKDEPARTMENTOF

INFORMATION TECHNOLOGY

CODE :

UIT 6087

SEMETER : VI YEAR : 2010

Prepared by R. Saravanan Sr. Lect, IT

1 |Page

Department of Information Technology

Database Management Systems

UNIT

I

Introduction to Database Systems: Overview Data Models Database System Architecture History of Database Systems. Entity-Relationship Model: Basic Concepts Constraints Keys Design Issues Entity Relationship Diagram Weak Entity Sets Extended E-R Features Design of an E-R Database Schema Reduction of E-R Schema to Tables The Unified Modeling Language UML.

UNIT II Relational Model: Structure of Relational Databases Relational Algebra Extended Relational Algebra Operations Modification of Database Views Tuple Relational Calculus Domain Relational Calculus. SQL: Background Basic Structure Set Operations Aggregate Functions Null Values Nested Subqueries Views Complex Queries Modification of the database Joined Relations Data-Definition Language Embedded SQL Dynamic SQL Other SQL Features. Other Relational Languages: Query-by-Example Datalog User Interfaces and Tools

UNIT III Integrity and Security: Domain Constraints Referential Integrity Assertions Triggers Security and Authorization Authorization in SQL Encryption and Authentication. Relational-Database Design: First Normal Form Pitfalls in Relational-Database Design Functional Dependencies Decomposition Desirable Properties of Decomposition Boyce-Codd Normal Form Third Normal Form Fourth Normal Form More Normal Forms Overall Database Design Process.

UNIT IV Storage and File Structures: Overview of Physical Storage Media Magnetic Disks RAID Tertiary Storage Storage Access File Organization Organization of Records in Files Data-Dictionary Storage. Indexing and Hashing: Basic Concepts Ordered Indices B+-Tree Index Files B-Tree Index Files Static Hashing Dynamic Hashing Comparison of Ordered Indexing and Hashing Index Definition in SQL Multiple-Key Access

2 |Page


Database Management SystemsUNIT V Transactions: Transaction concept Transaction State Implementation of Atomicity and Durability Concurrent Executions Serializability Recoverability Implementation of Isolation Transaction Definition in SQL Testing for Serializability Concurrence Control: Lock-Based Protocols Timestamp-Based Protocols Validation-Based Protocols Multiple Granularity Multiversion Schemens Deadlock Handling Insert and Delete Operations Weak Levels of Consistency Concurrency of Index Structures. Recovery System: Failure Classification Storage Structure Recovery and Atomicity Log-Based Recovery Shadow Paging Recovery with Concurrent Transactions Buffer Management Failure with Loss of Nonvolatile Storage Advance Recovery Techniques Remote Backup Systems

TEXT BOOK Silberschatz, Korth, Sudarshan, Database System Concepts, 4th Edition McGraw-Hill Higher Education, International Edition 2002. Chapters: 1 to 7, 11, 12, 15 to 17. REFERENCE BOOKS Fred R McFadden, Jeffery A Hoffer, Mary B. Prescott, Moden Database Management:, Fifth Edition, Addison Wesley, 2000. Elmasri, Navathe, Fundamentals of database Systems, Third Edition, Addison Wesley, 2000. Jefrey D.Ulman, Jenifer Widom, A First Course in Database Systems:, Pearson Education Asia, 2001. Bipin C Desai, An Introduction Publications Pvt Limited, 2001. to Database Systems, Galgotia

3 |Page


Database Management SystemsUNIT - I Unit-I2 mark Q & A: 1. What is DBMS and whats the goal of it? DBMS is a collection of interrelated data and a set of programs to access that data. The goal is to provide the environment that is both convenient and efficient to use in retrieving and storing data base information. 2. What 3. What are the advantages of DBMS? Centralized Control Data Independence allows dynamic change and growth potential. Data Duplication is eliminated with control Redundancy. Data Quality is enhanced. Controlling redundancy Restricting unauthorized access Providing multiple user interfaces Enforcing integrity constraints. Providing back up and recovery are the Disadvantages of DBMS? Cost of software, hardware and migration is high. Complexity of Backup Problem associated with centralization.

4. List any eight applications of DBMS. Banking Airlines Universities Credit card transactions Tele communication Finance Sales Manufacturing Human resources 5. What are the disadvantages of File Systems? Data Redundancy and Inconsistency. Difficulty in accessing data. Data Isolation Integrity problems Security Problems Concurrent access anomalies 6. Give the levels of data abstraction? a. Physical level b. Logical level c. View level 4 |Page Department of Information Technology


7. Define the terms a. Physical schema b. Logical schema. Physical schema: The physical schema describes the database are design at the physical level, which is the lowest level of abstraction describing how the data are actually stored. Logical schema: The logical schema describes the database design at the logical level, which describes what data are stored in the database and what relationship exists among the data. 8. What is conceptual schema? The schemas at the view level are called subschemas that describe different views of the database. 9. Define data model? A data model is a collection of conceptual tools for describing data, data relationships, data semantics and consistency constraints. 10. What is storage manager? A storage manager is a program module th at pr ovides the interface between the low level data stored in a database and the application programs and queries submitted to the system. 11. What are the co mponents of storage manager? The storage manager components include a) Authorization and integrity manager b) Transaction manager c) File manager d) Buffer manager 12. What is the purpose of storage manager? The storage manager is responsible for the following a) Interaction with the file manager b) Translation of DML commands in to low level file system commands c) Storing, retrieving and updating data in the database 13. List the data structures implemented by the storage manager The storage manager implements the following data structure a) Data files b) Data dictionary c) Indices 14. What is a data dictionary? A data dictionary is a data structure which stores meta data about the structure of the database ie. the schema of the database. 15. What is an entity relationship model? The entity relationship model is a collection of basic objects called 5 |Page Department of Information Technology

Database Management Systemsentities and relationship among those objects. An entity is a thing or object in the real world that is distinguishable from other objects. 16. What are attributes? Give examples. An entity is represented by a set of attributes. Attributes are descriptive properties possessed by each member of an entity set. Example: possible attributes of customer entity are customer name, customer id, customer street, customer city. 17. What is relationship? Give examples A relationship is an association among sev eral entities. Example: A depositor relationship associates a customer with each account that he/she has. 18. Define Entity, Entity Set, and extensions of entity set. Give one example for each. Entity object or thing in the real world. Egs., each person, book, etc. Entity set set of entities of the same entity that share the same properties or attributes. Eg., Customer, loan, account, etc Extensions of entity set individual entities that constitute a set. Eg., individual bank customers 19.Define and give examples to illustrate the four types of attributes in database. Simple and Composite attribute o Simple (address) o Composite (street, city, district) Single-valued and multi-valued attribute o Single-valued (roll no) o Multi-valued (colors = {R,B,G}) Null attribute o No values for attribute Derived attribute o Age derived from Birth date 20. Define the terms i) Entity type & ii) Entity set Entity type: An entity type defines a collection of entities that have the same attributes. Entity set: The set of all entities of the same type is termed as an entity set. 21. What is meant by the degree of relationship set? The degree of relationship type is the number of participating entity types. 22. Define the terms i) Key attribute ii) Value set Key attribute: An entity type usually has an attribute whose values 6 |Page Department of Information Technology

Database Management Systemsare distinct from each individual entity in the collection. Such an attribute is called a key attribute. Value set: Each simple attribute of an entity type is associated with a value set that specifies the set of values that may be assigned to that attribute for each individual entity. 23. Define relationship and participation. o Relationship is an association among several entities. o Association between entity sets is referred as participation. 24. Define mapping cardinality or cardinality ratio. Mapping cardinality or cardinality ratio is the way to express the number of entities to which another entity can be associated through a relationship set. These are most useful in describing binary relationship sets. 25. Explain the four types of mapping cardinality with example. For a binary relationship set R between entity sets A and B, the mapping cardinality must be one of the following: (Draw the diagrams also) 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. Eg., Roll no entity in Student info entity set and marks details entity set. One-to-many An entity in A is associated with any number of entities in B. But an entity in B is associated with at most one entity in A. Eg., one customer with many loans. Many-to-one An entity in A is associated with at most one entity in B. But an entity in B can be associated with any number of entities in A. Eg., street and city associated to a single person. Many-to-many An entity in A is associated with any number of entities in B. But an entity in B can be associated with any number of entities in A. Eg., same loan by several business partners. 26. Differentiate total participation and partial participation. (i.e., write Definition and Example with illustration) Total participation of an entity set, E in relationship, R is total if every entity in E participates in at least one relationship in R. Eg., loan entity set. Partial if only some entities in E participate in R. Eg., payment weak entity set.

7 |Page


Database Management Systems27. Define E-R diagram. Overall structure of a database can be expressed graphically by E-R diagram for simplicity and clarity. 28. Define weak Entity set. Give an example and explain why it is weak entity set. Entity set with no sufficient attributes to form a primary key. Payment entity set is weak since duplication exists 29. Define discriminator or partial key of a weak entity set. Give example. Set of attributes that allow distinction to be made among all those entities in the entity set that depend on one particular strong entity. Eg., payment_no in payment entity set. It is also called as partial key. 30. Explain Referential Integrity. Referential Integrity means relationship between tables. Foreign keys are used. Foreign key is the column whose values are derived from the Primary key of the same or some other table. Format for creating a foreign key is given below. Syntax: create table (columnname data type (size) constraint constraint_name references parent table name); 31. Define Instances and schemas. Instances: The collection of information stored in the database at a particular moment is called the instance of the database. Schemas: The overall design of the database is called the schema of the database. 32. Define and explain the two types of Data Independence. Two types of data independence are Physical data independence: The ability to modify the physical schema without causing application programs to be rewritten in the higher levels. Modifications in physical level occur occasionally whenever there is a need to improve performance. Logical data independence: The ability to modify the logical schema without causing application programs to be rewritten in the higher level (external level). Modifications in physical level occur frequently more than that in physical level, whenever there is an alteration in the logical structure of the database. 33. Define transaction. A transaction is a collection of operations that performs a single logical function in a database application. Each transaction is a unit of both atomicity and consistency. Properties of transaction are atomicity, consistency, isolation, and durability.

34. Define the type types of DML. 8 |Page Department of Information Technology

Database Management SystemsTwo types: Procedural DML: It requires a user to specify what data are needed and how to get those data. Non-Procedural DML: It requires a user to specify what data are needed without specifying how to get those data. 35. List out the functions of DBA. Schema definition Storage structure and access-method definition Schema and physical modification Granting of authorization for data access Integrity constraint specification 36. What is the need for DBA? The need of DBA is to have central control of both the data and the programs that access those data. The person who has such central control over the system is called the DataBase Administrator. 37. Define weak and strong entity sets? Weak entity set Entity set that do not have key attribute of their own are called weak entity sets. Strong entity set Entity set that has a primary key is termed a strong entity set. 38. What does the cardinality ratio specify? Mapping cardinalities or cardinality ratios express the number of entities to which another entity can be associated. Mapping cardinalities must be one of the following: One to one One to many Many to one Many to many 39. Explain the two types of participation constraint. Total The participation of an entity set E in a relationship set R is said to be total if every entity in E participates in at least one relationship in R. Partial if only some entities in E participate in relationships in R, the participation of entity set E in relationship R is said to be partial. 40. Explain DML pre-compiler. DML precompiler converts DML statements embedded in an application program to normal procedure calls in the host language. The precompiler must interact with the DML compiler to generate the appropriate code 9 |Page Department of Information Technology

Database Management Systems41. Define file manager and buffer manager. File manager: File manager manages the allocation of space on disk storage and the data structures used to represent information stored on disk. Buffer manager: Buffer manager is responsible for fetching data from the disk storage into the main memory, and deciding what data to cache in memory. 42. Define Data Dictionary. DDL statements are compiled into a set of tables that is stored in a special file called data dictionary. Data dictionary contains the meta-data, which in turn is data about the data.

Lecture notes: 10 | P a g e Department of Information Technology

Database Management SystemsDATABASE MANAGEMENT SYSTEMS DBMS contains information about a particular enterprise Collection of interrelated data. Set of programs to access the data. An environment that is both convenient and efficient to use.

In other way A very large, integrated collection of data. Models real-world enterprise. Entities (e.g., students, courses) Relationships (e.g., Madan is taking Computer) Goal A Database Management System (DBMS) is a software package that is designed to store and manage databases. Database Applications Banking: all transactions Airlines: reservations, schedules Universities: registration, grades Sales: customers, products, purchases Online retailers: order tracking, customized recommendations Manufacturing: production, inventory, orders, supply chain Human resources: employee records, salaries, tax deductions Databases touch all aspects of our lives

Purpose of Database Systems In the early days, database applications were built directly on top of file systems Drawbacks of using file systems Data redundancy and inconsistency Multiple file formats, duplication of information in different files. Difficulty in accessing data Need to write a new program to carry out each new task Data isolation - multiple files and formats Integrity problems Integrity constraints (e.g. account balance > 0) become buried in program code rather than being stated explicitly Hard to add new constraints or change existing ones Department of Information Technology

11 | P a g e


Atomicity of updates Failures may leave database in an inconsistent state with partial updates carried out Example: Transfer of funds from one account to another should either complete or not happen at all Program to transfer Rs.200 from A to B acc. System failure occurs then rs. 200 is removed from A but not credited to B Concurrent access by multiple users Concurrent accessed needed for performance Uncontrolled concurrent accesses can lead to inconsistencies Example: Two people reading a balance and updating it at the same time Security problems o Hard to provide user access to some, but not all, data

Database systems offer solutions to all the above problems

Files vs DBMS Application must stage large datasets between main memory and secondary storage o (e.g., buffering, page-oriented access, 32-bit addressing, etc.) Special code for different queries Must protect data from inconsistency due to multiple concurrent users Crash recovery Security and access control

Why Use a DBMS? Data independence and efficient access. Reduced application development time. Data integrity and security. Uniform data administration. Concurrent access, recovery from crashes

Why Study Databases? Shift from computation to information o at the low end: scramble to webspace o at the high end: scientific applications Datasets increasing in diversity and volume. 12 | P a g e Department of Information Technology

Database Management Systemso Digital libraries, interactive video, Human DBMS encompasses most of CS o OS, languages, theory, AI, multimedia, logic

VIEW OF DATA A major purpose of a database system is to provide users with an abstract view of the data. That is, the system hides certain details of how the data are stored and maintained. Data Abstraction The need for efficiency has led designed to use complex data Structures to represent data in the database. Developers hide the complexity from users through several levels of abstraction Physical level Lowest level of abstraction Describes how the data are Actually stored. Describes complex low-level data structures in detail.

Logical level The next higher level of abstraction describes what data are stored in the database, and what relationships exist among those data. The logical level thus describes the entire database in terms of a small number of relatively simple structures. View of level The highest level of abstraction describes only part of the entire database. Even though the logical level uses simpler structures, complexity remains because of the variety of information stored in a large database.

13 | P a g e



Fig 1.1 The Three levels of Data Abstraction Instances and Schema The collection of information stored in the database at a particular moment is called instance of the database. The overall design of the database is called the database schema. Database systems have several schemas, partitioned according to the levels of abstraction. The physical schema describes the database design at the physical level, The logical schema describes the database design at the logical level. A database may also have several schemas at the view level, sometimes called subschema, that describe different views of the database. The logical schema is by far the most important, in terms of its effect on application programs, since programmers construct applications by using the logical schema. The physical schema is hidden beneath the logical schema, and can usually be changed easily without affecting application programs.

14 | P a g e


Database Management SystemsApplications programs are said to exhibit physical data independence if they do not depend on the physical schema, and thus need not be rewritten if the physical schema changes. DATA MODELS A data model is a collection of concepts for describing data. A schema is a description of a particular collection of data, using the given data model. The relational model of data is the most widely used model today. Main concept: relation, basically a table with rows and columns. Every relation has a schema, which describes the columns, or fields.

Underlying the structure of a database is the data model a collection of conceptual tools for describing data, data relationships, data semantics, and consistency constraints. It can be categorized into two models they are The entity-relationship model and The relational model Both provide a way to describe the design of a database at the logical level. Entity-Relationship Model The entity-relationship (E-R) data model is based on a perception of a real world that consists of a collection of basic objects, called entities, and of relationships among these objects. For eg., each person is an entity; and bank accounts can be considered as entities: Entities are described in a database by a set of attributes. For eg., the attributes acc_no and bal may describe one particular account in a bank and they form attributes of the account entity set. Similarly, attributes cust_name, cust_street address and cust_id may describe a customer entity. An extra attribute cust_id is used to uniquely identify customers (since it may be possible to have two customers with the same name, street address and city). A relationship is an association among several entities. For eg., a depositor relationship associates a customer with each account that she has. The set of all entities of the same type and the set of all relationships of the same type are termed an entity set and relationship set, respectively. The overall logical structure (schema) of a database can be expressed graphically by an E-R diagram, which is built up from the following components:

15 | P a g e


Database Management Systems Rectangles - which represent entity sets Ellipses - which represent attributes Diamonds - which represent relationships among entity sets Lines, which link attribute to entity sets and entity sets to relationships.

Fig 1.2 An example E-R diagram

Relational Model The relational model uses a collection if tables to represent both data and the relationships among those data. Each table has multiple columns, and each column has a unique name. The relational data model is the most widely used data model, and a vast majority of current database systems are based on the relational model. The relational model is at a lower level of abstraction than the E-R model. Database designs are often carried out in the E-R model, and then translated to the relational model. For eg., it is easy to see customer and account correspond to the entity sets of the same name, while the table depositor corresponds to the relationship set depositor.

16 | P a g e



Other Data Models The object-oriented data model is another data model that has seen increasing attention. The object-oriented model can be seen as extending the E-R model with notions of encapsulation, methods and object identity. The object-relational data model combines features of the objectoriented data model and relational data model. Semistructured data models permit the specification of data where individual data items of the same type may have different sets of attributes. The extensible markup language (XML) is widely used to represent semistructured data. Two other data models are Network model and Hierarchical data model, Preceded the relational data model. These models were tied closely to the underlying implementation, and complicated the task of modeling data.

Database Languages Database System provides a DDL (Data Definition Language) to specify the database schema and 17 | P a g e Department of Information Technology

Database Management SystemsDML (Data Manipulation Language) to express the database queries and updates Data dictionary/ Data Directory Contains Metadata i.e data about data Eg: schema of a table The system consults the data dictionary before reading or modifying the actual data. DML Retrieval Insertion Deletion Modification Database Users There are different types of user that play different roles in a database environment. Following is a brief description of these users: Application Programmers Application programmer is the person who is responsible for implementing the required functionality of database for the end user. Application programmer works according to the specification provided by the system analyst. End Users End users are those persons who interact with the application directly. They are responsible to insert, delete and update data in the database. They get information from the system as and when required. Different types of end users are as follows: Naive Users: Naive users are those users who do not have any technical knowledge about the DBMS. They use the database through application programs by using simple user interface. They perform all operations by using simple commands provided in the user interface. Example: The data entry operator in an office is responsible for entering records in the database. He performs this task by using menus and buttons etc. He does not know anything about database or DBMS. He interacts with the database through the application program. Sophisticated Users: Sophisticated users are the users who are familiar with the structure of database and facilities of DBMS. Such users can use a query language such as SQL to perform the required operations on databases. Some sophisticated users can also write application programs. Database Administrator 18 | P a g e Department of Information Technology

Database Management SystemsDatabase administrator is responsible for, managing the whole database system. The one who designs creates and maintains the database. And also manages the users who can access this database, and controls integrity issues. And monitors the performance of the system and makes changes in the system as and when required.

19 | P a g e


Database Management SystemsDATABASE SYSTEM STRUCTURE

20 | P a g e



A database system is partitioned into modules that deal with each of the responsibilities of the overall system. The functional components of a database system can be broadly divided into The storage manager and The query processor components. The storage manager is important because databases typically require a large amount of storage space. For eg.,Corporate databases are too large. So the main memory of computer cannot store that much of information, the information is stored on disks. Data are moved between disk storage and main memory as needed and also speed of retrieval is slow. The database systems structure the data as to minimize the need to move data between disk and main memory. The query processor is important because it helps the database system simplify and facilitate access to data. High-level views help to achieve this goal. The job of the database system is to translate updates and queries written in a nonprocedural language, at the logical level, into an efficient sequence of operations at the physical level.

Storage Manager Storage manager is a program module that provides the interface between the low-level data stored in the database and the application programs and queries submitted to the system. The storage manager is responsible to the following tasks: interaction with the file manager efficient storing, retrieving and updating of data The storage manager components include: Authorization and integrity manager, which tests for the satisfaction of integrity constraints and checks authority to access the data. Transaction manager, which ensures that the database remains in a consistent state despite system failures and that concurrent transaction execution proceed without conflicting. File Manager, which manages the allocation of space on disk storage and the data structures used to represent information stored on disk. Buffer manager, which is responsible for fetching data from disk storage into main memory, and deciding what data to cache in main memory. It is used to handle data sizes that are much larger than the size of main memory. 21 | P a g e Department of Information Technology


The storage manager implements several data structures as part of the physical system implementation. Data files, which store the database itself. Data Dictionary, which stores metadata about the structure of the database, in particular the schema of the database. Indices, which provide fast access to data items that hold particular values. Query Processor The query processor includes: DDL interpreter, which interprets DDL statements and records the definitions in the data dictionary. DML complier, which translates DML statements in a query language. A query can usually be translated into any of a number of alternatives evaluation plans that all give the same result. The DML complier also performs query optimization, that is, it picks the lowest cost evaluation plan from among the alternatives. Query evaluation engine, which instructions generated by the DML compiler. HISTORY OF DATABASE SYSTEMS In twentieth century the Punch Cards were introduced, invented by Hollerith. These punch cards were later widely used as entering data into computers. 1950s and early 1960s Magnetic tapes were developed for data storage. Data processing tasks such as payroll were automated, with data stored on tapes. Tapes could be read only sequentially and data sizes were much larger than main memory, thus data processing programs were forced to process data in a particular order, by reading and merging data from tapes and card checks. Late 1960s and 1970s Widespread use of hard disks allowed direct access to data. With disks, network and hierarchical databases could be created that allowed data structures such as lists and trees to be stored on disk. 22 | P a g e Department of Information Technology executes low-level


In 1970 the relational model and non-procedural ways of querying data in the relational model, and relational databases were born. The Relational model is hiding the implementations details completely from the programmer. 1980s Relational databases could not match the performance of existing network and hierarchical databases. That changed with System R, are fully functional System R prototype led to IBMs first relational database product, SQL/DS. Initial commercial relational databases systems, such as IBM DB2, Oracle, Ingres and DEC Rdb fro efficient processing of declarative queries. The 1980s also saw much research on parallel and distributed databases, as well as on object-oriented databases.

Early 1990s:The SQL language for decision support applications, which are very intensive. Decision support and querying re-emerged as a major application area for databases. Tools for analyzing large amounts of data saw large growths in usage. Many databases vendors introduced parallel database products in this period.

Late 1990s: The major event was the explosive growth of the World Wide Web. Databases were deployed much more extensively than ever before. Database Systems had to support very high transaction processing rates and high reliability. Database system also had to support Web interfaces to data. Entity Relationship Model It is a high level conceptual data model that describes the structure of db in terms of entities, relationship among entities & constraints on them. Basic Concepts of E-R Model: - Entity - Entity Set - Attributes - Relationship - Relationship set - Identifying Relationship 23 | P a g e Department of Information Technology


Entity -It is an object that exists in the real world. Example: - Person, Employee, Car, Home etc.. Object with conceptual Existence - Account, loan, job etc Entity Set - A set of entities of the same type. Attributes - A set of properties that describe an entity. Types of Attributes Simple (or) atomic vs. Composite - An attribute which cant be sub divided. (Eg.Age) - An attribute which can be divided into sub parts is called as composite attribute. e.g. Address- Apartment no. - Street - Place - City - District Single Valued vs. Multivalued An attribute having only one value (e.g.. Age,eid,sno) An attribute having multiple values (e.g.. Deptlocat- A dept can be located in several places) Stored Vs Derived Stored attribute is one that has some value where as derived attribute is a one where its value is derived from stored attribute. E.g. SA-DOB DA- Age derived from DOB. Key Attribute An attribute which is used to uniquely identify records. E.g.. eid, sno, dno

24 | P a g e


Database Management SystemsRelationship It is an association among several entities. It specifies what type of relationship exists between entities.

Relationship set: It is a set of relationships of the same type.

Weak Entity Set: No key attributes. Constraints Two of the most important constraints are a. Mapping Constraints b. Participation constraints Participation constraints

25 | P a g e


Database Management Systemsa. Mapping Cardinalities: Express the no.of entities to which another entity can be associated via a relationship set Types One-to-One An entity in set A is associated with at most one entity in set B and vice versa.

One-to-many An entity in set A is associated with zero or more no. of entities in set B and an entity in B is associated with at most one entity in A.

26 | P a g e



Many-to-One One or more no. of entities in set A is associated with at most one entity in B. An entity in B can be associated with any no. of entities in A.

Many-to-Many One or more no. of entities in set A is associated with one or more no. of entities in set B.

27 | P a g e


Database Management Systemsb. Participation Constraints: Total Participation The participation of an entity set E in a relationship set R is said to be total if every entity in E participates in atleast one relationship in R. Partial Participation: The participation of an entity set E in a relationship set R is said to be partial if only a few of the entities in E participated in relationship in R.

Keys It is used to uniquely identify entities within a given entityset or a relationship set. Keys in Entity set: Primary Key: It is a key used to uniquely identify an entity in the entity set. E,g eno,rno,dno etc Super Key: It is a set of one or more attributes that allow us to uniquely identify an entity in the entity set. Among them one must be a primary key attribute. E.G.. Eid (primary key) and ename together can be identify an entity in entity set.

28 | P a g e


Database Management SystemsCandidate key: They are minimal super keys for which no proper subset is a superkey. E.g.. Ename and eaddr can be sufficient to identify an employee in employee set. {eid} and {ename,eaddr} Candidate keys FOREIGN Keys An attribute which makes a reference to an attribute of another entity type is called foreign key

Domain A range of values can be defined for an attribute and is called as Domain of that attribute. E.g.. Age attribute A Domain (A)= {1,2,.100}

29 | P a g e


Database Management SystemsKEYS: A key allows us to identify a set of attributes that suffice to distinguish entities form each other. Keys also help uniquely identify relationships and thus distinguish relationships from each other. Keys for Entity sets: A super key of an entity set is asset of one or more attributes whose values uniquely determine each entity. A candidate key of an entity set is a minimal super key. Example: Customer-id is a candidate key of customer. Account-number is a candidate key of account. Although several candidate keys may exist, one of the candidate keys is selected to be the primary key. Keys for Relationship sets: The combination of primary keys of the participation entity sets forms a super key of a relationship set. (customer-id, account-number) is the super key of depositor. If we wish to track all access-date to each account by each customer, we cannot assume a relationship for each access. We can use a multivalued attribute though. Must consider the mapping cardinality of the relationship set when deciding that what the candidate keys are. Need to consider semantics of relationship set in selecting the primary key in case of more than one candidate key. Participation Constraints: The participation of an entity set E in a relationship set R is said to be total if every entity in E participates in at least one relationship in R. If only some entities in E participate in relationships in R, the participation of entity set E in relationship R is said to be partial. ENTITY-RALATIONSHIP DIAGRAMS (E-R DIAGRAMS)

An E-R Diagram can express the overall logical structure of a database graphically.

30 | P a g e


Database Management SystemsComponents of E-R Diagrams and their notations:

31 | P a g e


Database Management SystemsAlternative E-R notations

E-R diagrams corresponding to customers and loans

Consider the above E-R diagram, which consists of two entity sets, customer and loan, related through a binary relationship set borrower. The attributes associated with customer are customer_id, customer_name, customer_street, customer_city. The attributes associated with loan are loan_number and amount. In the above figure, attributes of an entity set that are members of the primary key are underlined. From the above diagram, we see that the relationship set borrower is many-to-many.

MAPPING CARDINALITIES: 32 | P a g e Department of Information Technology

Database Management Systems We express cardinality constraints by drawing either a directed line(),signifying one, or an undirected line(--), signifying many, between the relationship set and the entity set. One-to-one relationship: A customer is associated with at most one loan via the relationship borrower. A loan is associated with at most one customer via borrower. If the relationship set borrower is one-to-one, then both lines from borrower would have arrows: one pointing to the loan entity set and one pointing to the customer entity set.

One-to-Many relationship: In the one-to-many relationship a loan is associated with at most one customer via borrower, customer is associated with several loan is borrower. If the relationship set borrower were one-to-many, from customer to loan, then the line from borrower to customer would be directed, with an arrow pointing to the customer entity set.

Many-to-One relationships: In a many-to-one relationship a loan is associated with several customers via borrower; a customer is associated with at most one loan via borrower.

33 | P a g e


Database Management Systems If the relationship set borrower were many-to-one from customer to loan, then the line from borrower to loan would have an arrow pointing to the loan entity set.

Many-to-many Relationship: A customer is associated with several (possibly 0) loans via borrower A loan is associated with several (possibly 0) customers.

E-R Diagram with an attribute attached to a relationship set. If a relationship set has also some attributes associated with it, then we link these attributes to that relationship set. For example, in the below diagram, we have the access_date descriptive attribute attached to the relationship set depositor to specify the most recent date on which a customer accessed that account.

34 | P a g e



E-R Diagram with composite, multi-valued, and derived attributes: The below diagram shows that how composite attributes can be represented in the E-R notation. A composite attribute name, with component attributes first_name, middle_initial and last_name replaces the simple attribute customer_name of customer. Also, the component attribute address, whose component attributes are street, city, state, zip code replaces the attributes customer_street, customer_city of customer. The attribute street is itself a composite attribute whose component attributes are street_number, street name, and apartment_number. It also shows that a multivalued attribute phone_number, depicted by a double ellipse, and a derived attribute age, depicted by a dashed ellipse.

Roles: Entity sets of a relationship need not be distinct. The labels manager and worker are called roles; they specify how employee entities interact via the works-for relationship set. Roles are indicated in E-R diagrams by labeling the lines that connect diamonds to rectangles. Role labels are optional, and are used to clarify semantics of the relationship. 35 | P a g e Department of Information Technology

Database Management SystemsE-R Diagram with role indicators

PARTICIPATION CONSTRAINTS: Participation of an entity set in a relationship set: o Total participation o Partial participation Total participation (Indicated by double one): Every entity in the entity set participates in at least one relationship in the relationship set. Example: participation of loan in borrower is total. Every loan must have a customer associated to it via borrower. Partial participation: Some entities may not participate in any relationship in the relationship set. Example: participation of customer in borrower is partial. E-R Diagram With A Ternary Relationship: Ternary relationship consists of the three entity sets employee, job, and branch, related through the relationship set works_on. We can specify some types of many-to-one relationships in the case of nonbinary relationship sets.

Cardinalities Limits On Relationship Sets:

36 | P a g e


Database Management Systems The edge between loan and borrower has a cardinality constraint of 1..1, meaning the minimum and the maximum cardinality are both 1. The limit 0...* on the edge from customer to borrower indicates that a customer can have zero or more loans.

WEAK ENTITY SETS: An entity set may not have sufficient attributes to form a primary key is referred to as a weak entity set. The existence of a weak entity set depends on the existence of a identifying entity set. It must relate to the identifying entity set via a total, one-to-many relationship set from the identifying to the weak entity set Identifying relationship depicted using a double diamond The discriminator (or partial key) of a weak entity set is the set of attributes that distinguishes among all the entities of a weak entity set. The primary key of a weak entity set is formed by the primary key of the strong entity set on which the weak entity set is existence dependent, plus the weak entity sets discriminator. We depict a weak entity set by double rectangles. We underline the discriminator of a weak entity set with a dashed line. Example: payment-number discriminator of the payment entity set Primary key for payment (loan-number, payment-number)

37 | P a g e


Database Management SystemsE-R Diagram with a weak entity sets The primary key of the strong entity set is not explicitly stored with the weak entity set, since it is implicit in the identifying relationship. If loan-number were explicitly stored, payment could be made a strong entity, but then the relationship between payment and loan would be duplicated by an implicit relationship defined by the attribute loan-number common to payment and loan. ENTITY-RELATIONSHIP DESIGN ISSUES: Use of entity sets vs. attributes: Choice mainly depends on the structure of the enterprise being modeled, and on the semantics associated with the attribute in question. Use of entity sets vs. relationship sets: Possible guideline is to designate a relationship set to describe an action that occurs between entities Binary versus n-ary relationship sets: Although it is possible to replace any non binary (n-ary, for n>2) relationship set by a number of distinct binary relationship sets, a n-ary relationship set shows more clearly that several entities participate in a single relationship. Some relationships that appear to be non-binary may be better represented using binary relationships E.g. A ternary relationship parents, relating a child to his/her father and mother, is best replaced by two binary relationships, father and mother . Using two binary relationships allows partial information (e.g. only mother being know) But there are some relationships that are naturally non-binary E.g. works-on In general, any non-binary relationship can be represented using binary relationships by creating an artificial entity set. o Replace R between entity sets A, B and C by an entity set E, and three relationship sets: 1. RA, relating E and A 2. RB, relating E and B 3. RC, relating E and C o Create a special identifying attribute for E o Add any attributes of R to E o For each relationship (ai , bi , ci) in R, create 1. a new entity ei in the entity set E 2. add (ei , ai ) to RA 3. add (ei , bi ) to RB 4. add (ei , ci ) to RC 38 | P a g e Department of Information Technology


Ternary relationship vs. three binary relationships. Also need to translate constraints o Translating all constraints may not be possible o There may be instances in the translated schema that cannot correspond to any instance of R o Exercise: add constraints to the relationships RA, RB and RC to ensure that a newly created entity corresponds to exactly one entity in each of entity sets A, B and C o We can avoid creating an identifying attribute by making E a weak entity set (described shortly) identified by the three relationship sets Placement of relationship attributes: The cardinality ratio of a relationship can affect the placement of relationship attributes. Thus, attributes of one-to-one or one-to-many relationship set can be associated with one of the participating entity sets, rather than with the relationship set. Example: Can make access-date an attribute of account, instead of a relationship attribute, if each account can have only one customer i.e., the relationship from account to customer is many to one, or equivalently, customer to account is one to many

Access-date as attribute of the account entity set.

39 | P a g e


Database Management SystemsEXTENDED E-R FEATURES: Certain extensions of E-R Model are, Specialization Generalization Attribute Inheritance Constraints on Generalizations Aggregation

Specialization: Top-down design process; we designate sub groupings within an entity set that are distinctive from other entities in the set. These sub groupings become lower-level entity sets that have attributes or participate in relationships that do not apply to the higher-level entity set. Example: A person may be classified as, o Customer o Employee It depicted by a triangle component labeled ISA (E.g. customer is a person). We can apply specialization repeatedly to refine a design scheme. Employees may be further classified as, o o o Officer Teller Secretary

Each of these employee types is described by a set of attributes that includes all the attributes of entity set employee plus additional attributes. Example: officer entities -- office_number teller entity station_number,hours_worked secretary --hours_worked(it may be participate in a relationship secretary_for) The ISA relationship may also be referred to as a super class-subclass relationship. Higher and lower level entity sets are depicted as regular entity sets- i.e. as rectangles containing the name of the entity sets. Generalization: A bottom-up design process combine a number of entity sets that share the same features into a higher-level entity set. Specialization and generalization are simple inversions of each other; they are represented in an E-R diagram in the same way. The terms specialization and generalization are used interchangeably.

40 | P a g e


Database Management Systems Can have multiple specializations of an entity set based on different features. E.g. permanent-employee vs. temporary-employee, in addition to officer vs. secretary vs. teller Each particular employee would be a member of one of permanent-employee or temporary-employee, and also a member of one of officer, secretary, or teller. The ISA relationship also referred to as super class subclass relationship

Specialization and Generalization Attribute inheritance: The crucial property of the higher and lower level entities created by specialization and generalization is attribute inheritance. A lower-level entity set inherits all the attributes and relationship participation of the higher-level entity set to which it is linked. Example: The officer, teller, and secretary entity sets can participate in the works_for relationship set, since the super class employee participates in the works_for relationship. The attributes of the higher-level entity sets are said to be inherited by the lower-level entity sets. Example: customer and employee entity inherit the attributes of person. 41 | P a g e Department of Information Technology

Database Management Systems If an entity set is a lower-level entity set in one ISA relationship, then it is called as single inheritance. If an entity set is a lower-level entity set in more than one ISA relationship, then the entity set has multiple inheritance and the resulting structure is said to be a lattice. Constraints on Generalizations: Constraint on which entities can be members of a given lower-level entity set. Such memebership may be one of the following: Condition-defined: In condition-defined lower level entity sets, membership is evaluated on the basis of whether or not an entity satisfies an explicit condition or predicate. o E.g. all customers over 65 years are members of seniorcitizen entity set; senior-citizen ISA person. User-defined: o o User defined lower level entity sets are not constrained by a membership condition; rather, the database user assigns entities to a given entity set.

Constraint on whether or not entities may belong to more than one lowerlevel entity set within a single generalization. Disjoint The lower-level entity set may be one of the following:

o An entity can belong to only one lower-level entity set o Noted in E-R diagram by writing disjoint next to the ISA triangle. Overlapping o An entity can belong to more than one lower-level entity set Completeness constraints o o o It specifies whether or not an entity in the higher-level entity set must belong to at least one of the lower-level entity sets within a generalization. Total generalization or specialization: an entity must belong to one of the lower-level entity sets. Partial generalization or specialization: an entity need not belong to one of the lower-level entity sets.

Aggregation o Consider the ternary relationship works-on, which we saw earlier Department of Information Technology

42 | P a g e

Database Management Systemso Suppose we want to record managers for tasks performed by an employee at a branch.

E-R diagram with aggregation

Relationship sets works-on and manages represent overlapping information Every manages relationship corresponds to a works-on relationship However, some works-on relationships may not correspond to any manages relationships So we cant discard the works-on relationship Eliminate this redundancy via aggregation Treat relationship as an abstract entity Allows relationships between relationships Abstraction of relationship into new entity Without introducing redundancy, the following diagram represents: An employee works on a particular job at a particular branch An employee, branch, job combination may have an associated manager REDUCTION OF AN E-R SCHEMA TO TABLES

Primary keys allow entity sets and relationship sets to be expressed uniformly as tables which represent the contents of the database.

43 | P a g e


Database Management Systems A database which conforms to an E-R diagram can be represented by a collection of tables. For each entity set and relationship set there is a unique table which is assigned the name of the corresponding entity set or relationship set. Each table has a number of columns (generally corresponding to attributes), which have unique names. Converting an E-R diagram to a table format is the basis for deriving a relational database design from an E-R diagram. Representing Entity Sets as Tables A strong entity set reduces to a table with the same attributes.

Composite and Multivalued Attributes

Composite attributes are flattened out by creating a separate attribute for each component attribute E.g. given entity set customer with composite attribute name with component attributes first-name and last-name the table corresponding to the entity set has two attributes name.first-name and name.lastname A multivalued attribute M of an entity E is represented by a separate table EM Table EM has attributes corresponding to the primary key of E and an attribute corresponding to multivalued attribute M E.g. Multivalued attribute dependent-names of employee is represented by a table employee-dependent-names( employee-id, dname) Each value of the multivalued attribute maps to a separate row of the table EM E.g., an employee entity with primary key John and dependents Johnson and Johndotir maps to two rows: 44 | P a g e Department of Information Technology

Database Management Systems (John, Johnson) and (John, Johndotir)

45 | P a g e


Database Management SystemsRepresenting Weak Entity Sets A weak entity set becomes a table that includes a column for the primary key of the identifying strong entity set.

Representing Relationship Sets as Tables A many-to-many relationship set is represented as a table with columns for the primary keys of the two participating entity sets, and any descriptive attributes of the relationship set. E.g.: table for relationship set borrower

46 | P a g e


Database Management SystemsRedundancy of Tables Many-to-one and one-to-many relationship sets that are total on the many-side can be represented by adding an extra attribute to the many side, containing the primary key of the one side . E.g.: Instead of creating a table for relationship account-branch, add an attribute branch to the entity set account For one-to-one relationship sets, either side can be chosen to act as the many side i.e., extra attribute can be added to either of the tables corresponding to the two entity sets. If participation is partial on the many side, replacing a table by an extra attribute in the relation corresponding to the many side could result in null values. The table corresponding to a relationship set linking a weak entity set to its identifying strong entity set is redundant. E.g. The payment table already contains the information that would appear in the loan-payment table (i.e., the columns loan-number and payment-number).

Representing Specialization as Tables Method 1: Form a table for the higher level entity Form a table for each lower level entity set, include primary key of higher level entity set and local attributes Table table attributes Person name, street, city Customer name, credit-rating employee name, salary Drawback: getting information about, e.g., employee requires accessing two tables o o Method 2: Form a table for each entity set with all local and inherited attributes Table Person 47 | P a g e table attributes name, street, city Department of Information Technology

Database Management Systemscustomer name, street, city, credit-rating employee name, street, city, salary If specialization is total, no need to create table for generalized entity (person) Drawback: street and city may be stored redundantly for persons who are both customers and employees Relations Corresponding to Aggregation To represent aggregation, create a table containing primary key of the aggregated relationship, the primary key of the associated entity set Any descriptive attributes E.g. to represent aggregation manages between relationship works-on and entity set manager, o create a table manages(employee-id, branch-name, title, manager-name) Table works-on is redundant provided we are willing to store null values for attribute manager-name in table manages

DESIGN OF AN E-R DATABASE SCHEMA: E-R Design Alternatives: The use of an attribute or entity set to represent an object. Whether a real-world concept is best expressed by an entity set or a relationship set. The use of a ternary relationship versus a pair of binary relationships. The use of a strong or weak entity set. The use of specialization/generalization contributes to modularity in the design. The use of aggregation can treat the aggregate entity set as a 48 | P a g e Department of Information Technology

Database Management Systems Single unit without concern for the details of its internal structure. For example, we consider the database design for banking enterprise. We apply the two initial database-design phases, namely Gathering of data requirements Design of the conceptual schema Ultimately, the design of the E-R design process is a relational database schema. Data requirements for the bank database: The initial specification of user requirements may be based on interviews with the database users and on the designers own analysis of the enterprise. The major characteristics of the banking enterprise: The bank is organized into branches. Each branch is located in a particular city is identified by a unique name. Bank customers are identified by their customer_id values. Bank employees are identified by their employee_id values. The bank offers two types of accounts-savings and checking accounts. A loan originates at a particular branch and can be held by one of more customers. A loan is identified by a unique loan number. Entity sets for the Bank Enterprise: Branch={branch_name, branch_city, assets} Customer={customer_id, customer_name, customer_street, customer_city} o Additional attribute:banker_name. Employee={employee_id, employee_name, telephone_number, salary, manager} Additional attributes: o Dependent_namemultivalued attribute. o Start_datebase attribute. o Employment_lengthderived attribute. Two account entities: account={account_number, balance} o Saving _account={interest_rate} o Checking_account={overdraft_amount} Loan={loan_number, amount, originating_branch} Loan_payment={payment_number, payment_date, payment_number} Relationship sets for the Bank Database: Borrowermany-to-many relationship between customer and loan. 49 | P a g e Department of Information Technology

Database Management Systems Loan_branchmany-to-one relationship between loan and branch. It replaces by the attribute originating_branch of the entity set loan. Loan_paymentone-to-many relationship between loan and payment. Depositormany-to-may relationship between customer and account with an attribute access_date. Cust_bankermany-to-one relationship between customer and the bank employee with an attribute type. It replaces by the attribute banket_name of the entity set customer. Works_forrelationship set between employee entities with role indicators manager and worker. It replaces by the manager attribute of employee. E-R diagram for Bank Enterprise:

50 | P a g e



The above diagram includes the entity sets, relationship sets, and mapping cardinalities arrived at through the design processes. The attributes of the entity set are shown in one occurrence of the entity and all other occurrence of the entity is shown without any attributes.

51 | P a g e



Unified Modeling Language (UML) Overview What is UML? The Unified Modeling Language (UML) is the successor of the wave of object-oriented analysis and design methods that appeared in the late 80's and early 90's. It most directly unifies the methods of Booch, Rumbaugh (OMT) and Jacobson ("the three amigos"). The UML is called a modelling language, not a method. A method consists of a modelling language (mainly graphical notation) used to express designs and a process (i.e. inception, elaboration, construction and transition) which defines the steps in doing a design.

Use Cases and Use Case Diagrams Class Diagrams Interaction Diagrams o Sequence Diagrams o Collaboration Diagrams State Diagram

Use Cases and Use Case Diagrams Use Cases A Use Case is a narrative document that describes the sequence of events of a user (actor) using a system to complete a process. It is built to represent understanding of the user's requirements regarding a certain process/function that the system will be used for. Components of a Use Case The essential components of a Use Case are:

NAME - starts with a verb to emphasise that it is a process ACTOR - is a role that a user plays in respect to the system. Actors are generally shown when they are the ones who need the use case.

TYPE Primary - represents major common processes Secondary - represents minor or rare processes Optional - processes that may not be implemented in the system depending upon resources DESCRIPTION - short and essentialo o o

52 | P a g e


Database Management SystemsUse Case Level of Detail A use case narrative can have different levels of detail from abstract to concrete:

High-level - terse description of the activities without going into details of how activities are performed. Only use the essential components in the narrative. Expanded - shows more detail than a high-level one, details the sequence of events in the process o generally done in a conversational style o shows alternative courses o shows the initiator of the use case Real - details concretely the process in terms of its real current design, input and output technologies

Use Case Example The following is a possible expanded Use Case narrative: Borrow books Actors: student (initiator), librarian Purpose: This use case is to enable a student to borrow a book Overview: A student goes to library and borrows books. The student brings a few books to the counter. The librarian asks the student id. The student shows the student id and the book that he/she wishes to borrow. The librarian scans the student id and the book through the bar code scanner. Type: Primary and Abstract Cross-References: None Typical Course of Events: Actor Actions 1. A student brings a few books to the counter. System Responses

2. The library scans the student Id.

3. The system checks the fine status whether excess over $20.

4. The library scans the books' bar code.

53 | P a g e


Database Management Systems5. The system checks the borrowing limit of the books whether has been reached. 6. The system approves the loan for the borrower. 7. print out the statement of due date for the books. Alternative Courses: Line 3: The librarian tells the student to pay the fine. Use case cannceled. Line 5: The system notifies the librarian that the limit borrowing amount of book is over. Use case cancelled.

Identifying Use Cases There are two ways to identify Use Cases:

Using the actors o identify the actors related to a system or organisation o for each actor, identify the processes it initiates or participates in Using events o identify the external events that a system must respond to o relate the events to actors and use cases

Relationship between Use Cases Association relationship A Use Case diagram illlustrates a set of use cases for a system, i.e. the actors and the relationships between the actors and use cases. Each use case diagram is for a particular subject area.

Include relationship An include relationship connects a base use case (i.e. borrow books) to an inclusion use case (i.e. check Fine). An include relationship specifies how behaviour in the inclusion use case is used by the base use case.

54 | P a g e



The include relationship adds additional functionality not specified in the base use case. Extend relationship An extend relationship specifies how the functionality of one use case can be inserted into the functionality of another use case. The base use case implicitly incorporates the behaviour of another use case at a location specified indirectly by the extending use case. The extend relationships are important because they show optional functionality or system behavior.

Notice the extend relationship between Request a book and Search. The extend relationship is significant because it shows optional functionality. If the student desires, he/she can search the book through the system. However, the student may only Request a book through the system without searching the book if the student knows the call number.

Generalisation relationship

55 | P a g e


Database Management SystemsA generalisation relationship means that a child use case inherits the behaviour and meaning of the parent use case. The child may add or override the behaviour of the parent.

Class Diagrams A Class diagram (Business Class Diagram) describes the attributes and behaviours of the objects and the relationships between them. The initial use is to provide a conceptual model of the systems. Class diagrams are used from the analysis stage to the design stage of a system, hence there are three perspectives of class diagrams:

Conceptual o used in the initial analysis (not a model of software design) o shows real world concepts o better to overspecify than underspecify it Specification o does describe software o describes the interface of a software, not the implementation o types rather than classes Implementation o describes the actual software in the system o classes

Components of a Class Diagram There are two kinds of relationships between classes: 1. Generalisations (subtyping) 2. Associations

56 | P a g e



Generalisation at the implementation perspective is associated with inheritance. The subclass inherits all the non-private methods and attributes of the superclass and may override inherited methods. Each association has two association ends. Each end is attached to one of the classes in the association. An end can be explicitly named with a label. This label is called a role name. An association end also has multiplicity, which is an indication of how many objects may participate in the given relationship.

A class has attributes and operations/methods. The format of an attribute is: accessSpecifier attributeName: DataTypeName [=defaultValue] [{choice1, choice2, choice3}] The format of a method is:

57 | P a g e


Database Management SystemsaccessSpecifier methodName([parameterName: parameterDataType [=defaultValue],....]): returnDataType Note: The notation [] represents optional arguments

The following are the additional model elements covered in a class diagram: Model Element Abstract classes and methods Interfaces UML Notation {abstract} - in

Access specifiers: public, private, +, -, # ( , , protected Rational Rose) Initial values static attributes or methods limited number of valid options for a variable

= sign, e.g. gstRate = 0.1 underlined {option1, option2, option3}

58 | P a g e


Database Management SystemsExample of Class Diagram The following is a typical class diagram.

Q-BANK 59 | P a g e Department of Information Technology

Database Management Systems1.a)Sketch the architecture of DBMS. (7)- nov 2008 b)With an example explain the entity relationship model. (8)-nov 2008 2.a)What are the features of a database administrator Explain. (7)-nov 2008 b)Explain E-R diagram with a suitable example. (8)-nov 2008 3)Outline architecture of a database system. (15)-nov2007 4)Define concept of specialization and generalization. And explain the constraints on Generalizations. (15)-nov2007 5)Explain the basic concepts of Entity-Relatioship model (15)-april 2008 6)Explain the design of an E-R database schema. (15)-april 2008 7.a)Define and Explain the term database and database management system with example. (7)-may 2007 b)Compare and contrast the conventional file system with DBMS. (8)-april 2008 8)What is data model?Compare and contrast three popular data models with example. (15)-april 2008 9.a)What are the various disadvantages of storing organizational information in a file-processing system? (8)-april 2009 b)Describe the various data models of database. (7)-april 2009 10)Discuss some of the extended features of Entity-Relationship diagram. (15)april 2009 11)Explain the various possible associations between entities with suitable examples. What is E-R diagram?Explain with an example. (15)-may 2007 12)Draw an E-R diagram for a hospital with a set of patients and a set of doctors.Associate with each patient a log of the various tests and examinations conducted. (15)-may 2007 13) Explain the distinctions among the super key, candidate key and primary key (7)-May2007

60 | P a g e


Database Management SystemsUNIT - II2Mark Q & A 1. Give the syntax for creating the table with composite primary key. Multicolumn primary key is called composite primary key. Syntax: create table (columnname1 data type (size), columnname2 data type (size), constraint name primary key (columnname1, columnname2)); 2. Write a query to display loan number, branch name where loan amount is between 500 and 1000 using comparison operators. Query: select loan no, branch name from loan where amount>=500 and amount set of all acc_nos D2 -> set of all branch_names D3 -> set of all balances And the relation account is a subset of D1 X D2 X D3 20. Define super key and give example to illustrate the super key. Set of one or more attributes taken collectively, allowing to identify uniquely an entity in the entity set. Eg1. {SSN} and {SSN, Cust_name} of customer table are super keys. Eg2. {Branch_name} and {Branch_name, Branch_city} of Branch table are super keys. 21. Define candidate key and give example to illustrate the candidate key. Super keys with no proper subset are called the candidate keys. Otherwise it is called minimal super key. Candidate key is nothing but the primary key used in SQL. Eg1. {SSN} is the candidate key for the super keys {SSN} and {SSN, Cust_name} of customer table. Eg2. {Branch_name} is the candidate key for the super keys {Branch_name} and {Branch_name, Branch_city} of Branch table. 22. List out the six fundamental operators and 4 additional operators in relational algebra. Six Fundamental operators: Selection ( ) Projection ( ) Union ( ) Set Difference (-) Cartesian Product (X) Rename ( ) Four Additional operators: Set Intersection ( ) Natural Join (*) Division (%) Assignment ( ) 23. Which operators are called as unary operators and explain why they are called so. Unary operators: Selection () Projection () Rename () These operators are called as unary operators because they operate on only one relation. 24. Which operators are called as binary operators and explain why they are called so. 63 | P a g e Department of Information Technology

Database Management SystemsBinary operators: Union () Set Difference (-) Cartesian Product (X) These operators are called as binary operators because they operate on pairs of relations. 25. Write a relational algebra expression to find those tuples pertaining to loans of more than 1200 made by the Perryridge branch. Relational algebra expression: branch_name = perryridge amount >1200 (loan). 26. Explain the use of set difference operator and give an example to illustrate the same. Use of set difference operator: Allows finding tuples that are in one relation but are not in another relation. Example: Find all customers of the bank who have an account but not a loan. Relational Algebra Expression: Cust_name (depositor) - cust_name (borrower) 27. Explain the two conditions needed for the set difference operation (union operation) to be valid. Two conditions are Relations, r and s must be of the same arity ie., they must have same number of attributes. Domains of the ith attribute of r and the ith attribute of s must be same for all i. 28. Explain with one example why the additional operators are separated from the fundamental operators? Additional operators are used instead of fundamental operators to reduce the complexity of long relational algebra expressions. Eg. r s = r ( r s ) Intersection can be used for repeated set difference operations. 29. Define and give the general format used for generalized projection. Give one example expression to illustrate the same. Generalized projection extends the projection operation by allowing arithmetic functions to be used in the projection list. General format used for Generalized projection is F1 F2 Fn(E) where E is the relational algebra expression. F1 F2 Fn are the arithmetic expressions involving constants and attributes in the schema of E. Special case these can be simply an attribute or a constant. Example expression for illustration: acc_no, branch_name, balance + 100 (account) 64 | P a g e Department of Information Technology

Database Management Systems30. What is the use of outer join and list out the three types of outer join with the notations used in relational algebra? Natural join combines only the common columns. So some information will be lost, if it has no common column. So outer join is used. It avoids this loss of information. Three types of outer join: Left outer join Right outer join Full outer join 31. Write a relational algebraic expression to delete all accounts at branches located in Brooklyn. r1 branch_city = Brooklyn (account branch) r2 branch_name, acc_no, balance (r1) account account r2 where r1 and r2 are temporary relations. 32. Write a relational algebraic expression to insert the information about Smith with his new account number A-157 taken at the Perryridge branch with Rs.1200. Relational algebraic expression for insertion: account account {(A-157, Perryridge, 1200)} depositor depositor {(Smith, A-157)} 33. Define materialized views and explain the use of such views. Definitions: Certain database systems allow view relations to be stored, but they make sure that if the actual relations used in the view definition change then the view is kept up to date. Such views are called materialized views.The process of keeping views up to date is called view maintenance. Use of materialized views: If the views are used frequently then materialized views are used. But benefits of materialization must be weighed against the storage cost and the added overhead of updates. 34. Differentiate assertions and triggers. (i.e., write definitions) An assertion is a predicate expressing a condition that we wish the database to satisfy always. A Trigger is a statement that is executed automatically by the system as a side effect of a modification to the database. 35. List out the two requirements of triggers in database. Specify the conditions under which the trigger is to be executed. Specify the actions to be taken when the trigger executes. 36. What is a PROJECT operation? The project operation is a unar y operation that returns its argument relation with certain attributes left out. Projection is denoted by pie ( pp p p ). 65 | P a g e Department of Information Technology

Database Management Systems37. Write short notes on tuple relational calculus. The tuple relational calculation is anon procedural quer y language. It describes the desired information with out giving a specific procedure for obtaining that information. A query or expression can be expressed in tuple relational calculus as {t | P (t)} which means the set of all tuplest such that predicate P is true fort. 38. Write short notes on domain relational calculus The domain relational calculus uses domain variables that take on values from an attribute domain rather than values for entire tuple. 39. Define query language? A query is a statement requestin g the retrieval of information. The portion of DML that involves information retrieval is called a query language. 40. Write short notes on Schema diagram. A database schema along with primary key and foreign key dependencies can be depicted pictorially b y schema diagram. Each relation appears as a box with attributes listed inside it and the relation name above it. 41. What is foreign key? A relation schema r1 derived from an ER schema may include among its attributes the primary key of another relation schema r2.this attribute is called a foreign key from r1 referencing r2.

Lecture notes: Relational Model 66 | P a g e Department of Information Technology


Why Study the Relational Model? Most widely used model. o Vendors: IBM, Informix, Microsoft, Oracle, Sybase, etc. Legacy systems in older models o E.G., IBMs IMS Recent competitor: object-oriented model o ObjectStore, Versant, Ontos o A synthesis emerging: object-relational model Informix Universal Server, UniSQL, O2, Oracle, DB2

Definitions Relational database: a set of relations Relation: made up of 2 parts o Instance: a table, with rows and columns. #Rows = cardinality, #fields = degree o Scheme: specifies name of relation, plus name and type of each column. Example: Students(sid: string, name: string, login: string, age: integer, gpa: real) Example Instance Sid 53666 53688 53650 of Students Relation name login Jones jones@cs Smith smith@eecs Smith smith@math

age 18 18 19

gpa 3.4 3.2 3.8

Cardinality = 3, degree = 5, all rows distinct Relational database: The relational database consists of collection of tables, each of which is assigned a unique name. A row in a table represents a relationship among a set of values. Informally, a table is an entity set, and a row is an entity.

Basic structure and terminology in it: Example of relation: 67 | P a g e Department of Information Technology


Attribute: Each attribute of a relation has a name. The set of allowed values for each attribute is called the domain of the attribute. Attribute values are (normally) required to be atomic; that is, indivisible E.g. the value of an attribute can be an account number, but cannot be a set of account numbers. Domain is said to be atomic if all its members are atomic. The special value null is a member of every domain. The null value causes complications in the definition of many operations.

Database schema: Relation schema: Formally, given domains D1, D2, . Dn a relation r is a subset of D1 x D2 x x Dn Thus, a relation is a set of n-tuples (a1, a2, , an) where each ai Di Schema of a relation consists of attribute definitions name type/domain integrity constraints.

Relation Instance: The current values (relation instance) of a relation are specified by a table An element t of r is a tuple, represented by a row in a table Order of tuples is irrelevant (tuples may be stored in an arbitrary order)

68 | P a g e


Database Management Systemsattributes customer_nam customer_stre customer_cit Jones e Main et Harrison y Smith Curry Lindsay North North custome Park Rr Rye Rye Pittsfield (or columns) tuples (or rows)

Database: A database consists of multiple relations.Information about an enterprise is broken up into parts, with each relation storing one part of the information E.g. account: information about accounts depositor: which customer owns which account customer: information about customers

The Customer Relation:

The Depositor Relation: 69 | P a g e Department of Information Technology


Why Split Information Across Relations? Storing all information as a single relation such as bank (account_number, balance, customer_name, ..) results in repetition of information e.g., if two customers own an account (What gets repeated?) the need for null values. e.g., to represent a customer without an account

Keys: K R K is a super key of R if values for K are sufficient to identify a unique tuple of each possible relation r(R) By possible r we mean a relation r that could exist in the enterprise we are modeling.

Example:

customer_street} and {customer_name} are both super keys of Customer, if no two customers can possibly have the same name.In real life, an attribute such as customer_id would be used instead of customer_name to uniquely identify customers, but we omit it to keep our examples small, and instead assume customer names are unique.

{customer_name,

Types of keys: 1) K is a candidate key if K is minimal 70 | P a g e Department of Information Technology

Database Management SystemsExample: {customer_name} is a candidate key for since it is a super key and no subset of it is a super key. Customer,

2) Primary key: a candidate key chosen as the principal means of identifying tuples within a relation Should choose an attribute whose value never, or very rarely, changes. E.g. email address is unique, but may change

3) Foreign Keys: A relation schema may have an attribute that corresponds to the primary key of another relation. The attribute is called a foreign key. E.g. customer_name and account_number attributes of depositor are foreign keys to customer and account respectively. Only values occurring in the primary key attribute of the referenced relation may occur in the foreign key attribute of the referencing relation.

Relation Algebra The relational algebra is a procedural query language. It consists of a set of operations that take one or two relations as input and produce a new relation as their result. The operations can be divided into, Basic operations: Select, Project, Union, rename, set difference and Cartesian product Additional operations: Set intersections, natural join, division and assignment. Extended operations: Aggregate operations and outer join The fundamental operations: 1. 2. 3. 4. 5. 6. Select Project Union Set difference Cartesian product and Rename.

71 | P a g e


Database Management SystemsExample Consider simple Relation r A a a b B a b b C 1 5 1 2 2 3 D 7 7 3 1 0 D 7 1 0

b b A=B ^ D > 5 (r)

A B C a a 1 b b 2 3

Selection Operation Notation: p(r) p is called the selection predicate Defined as: p(r) = {t | t r and p(t)} Where p is a formula in propositional calculus consisting of terms connected by : (and), (or), (not) Each term is one of: op or where op is one of: Select It selects tuples that satisfy a given predicate, To denote selection.

(Sigma) is used.

Syntax condition(tablename) Example sal>1000(emp) It selects tuples whose employee sal is > 1000 Project Operation 72 | P a g e Department of Information Technology


It selects attributes from the relation. Symbol for project Syntax

Example

(Table eid,sal(employee)

Combining Select & Project Operation

eid,sal

(

Sal>1000

(employee)

)

Selects tuples where sal>1000 & from them only eid and salary attributes are selected. Union Operation

Consider a query to find the names of all bank customers who have either an account or a loan or both. Note that the customer relation does not contain the information, since a customer does not need to have either an account or a loan at the bank. 1. We know how to find the names of all customers with a loan in the bank: customer-name (borrower)

2. We also know how to find the names of all customers with an account in the bank:

73 | P a g e


Database Management Systemscustomer-name (depositor)

The binary operation union, denoted, as in set theory, by U. So the expression needed is

customer-name (borrower) U customer-name (depositor)

Therefore, for a union operation r U s to be valid, we require that two conditions hold:

1. The relations r and s must be of the same arity. That is, they must have the same number of attributes.

2. The domains of the ith attribute of r and the ith attribute of s must be the same, for all i. The Set Difference Operation:

1. The set-difference operation, denoted by , allows us to find tuples that are in one relation but are not in another. 2. The expression(r s) produces a relation containing those tuples in r but not in s. 3. We can find all customers of the bank who have an account but not a loan by writing customer-name (depositor) customer-name (borrower)

The Cartesian-Product Operation

1. The Cartesian-product operation, denoted by a cross (), allows us to combine information from any two relations. 2.We write the Cartesian product of relations r1 and r2 as (r1 r2). 3.Suppose that we want to find the names of all customers who have a loan at the Perryridge branch. We need the information in both the loan relation and the borrower relation to do so. 74 | P a g e Department of Information Technology

Database Management Systems4. If we write branch-name =Perryridge (borrower loan)

However, the customer-name column may contain customers

5. Finally, since we want only customer-name, we do a projection customer-name (borrower .loan-number =loan.loan-number (branch-name =Perryridge (borrower loan)))

The Rename Operation:

1. Unlike relations in the database, the results of relational-algebra expressions do not have a name that we can use to refer to them. 2. It is useful to be able to give them names; the rename operator, denoted by the lowercase Greek letter rho (). Consider the query:

Find the names of all customers who live on the same street and in the same city as Smith. We can obtain Smiths street and city by writing

customer-street, customer-city (customer-name = Smith (customer))

However, in order to find other customers with this street and city, we must reference the customer relation a second time.In the following query, we use the rename operation on the preceding expression to give its result the name smithaddr, and to rename its attributes to street and city, instead of customer-street and customer-city:

customer.customer-name (customer.customer-street=smith-addr.street 75 | P a g e Department of Information Technology

Database Management SystemsCustomer.customer-city=smith-addr.city (custom

Date post:	27-Nov-2014
Category:	Documents
Upload:	nandini-sakthivel
View:	119 times
Download:	1 times

DBMSit

Documents