Database Management Systems: Concepts, Types, and Examples

1. DBMS SUBMITTED BY :- MADHU MADHAN Lecturer in Computer engg. G.P. MEHAM (ROHTAK)

2. Database management concepts • Database Management Systems (DBMS) • An example of a database (relational) • Database schema (e.g. relational) • Data independence • Architecture of a DBMS • Types of DBMS • Basic DBMS types • Entity relationship model • Retrieving and manipulating data: query processing • Database views • Data integrity

3. DBMS tasks: • Managing large quantity of structured data • Efficient retrieval and modification: query processing and optimization • Sharing data: multiple users use and manipulate data • Controlling the access to data: maintaining the data integrity • An example of a database (relational): • Relations (tables) • Attributes (columns) • Tuples (rows) • Example query: Salesperson='Mary' AND Price>100.

5. Database schema (e.g. relational): • Names and types of attributes • Addresses • Indexing • Statistics • Authorization rules to access data etc. • Data independence: separation of the physical and logical data • Particularly important for distributed systems • The mapping between them is provided by the schema • Architecture of a DBMS - three levels: external, conceptual and internal schema • Types of DBMS • The data structures supported: tables (relational), trees, networks, objects • Type of service provided: high level query language, programming primitives

7. Basic DBMS types • Linear files • Sequence of records with a fixed format usually stored on a single file • Limitation: single file • Example query: Salesperson='Mary' AND Price>100 • Hierarchical structure • Trees of records: one-to-many relationships • Limitations: • Requires duplicating records (e.g. many-to-many relationship) • Problems when updated • Retrieval requires knowing the structure (limited data independence): • traversing the tree from top to bottom using a procedural language • Network structure: similar to the hierarchical database with the implementation • of many-to-many relationships • Relational structure • Object-Oriented structure • Objects (collection of data items and procedures) and interactions between them. • Is this really a new paradigm, or a special case of network structure? • Separate implementation vs. implementation on top of a RDBMS

8. Relational structure • Relations, attributes, tuples • Primary key (unique combination of attributes for each tuple) • Foreign keys: relationships between tuples (many-to-many). • Example: SUPPLIES defines relations between ITEM and SUPPLIER tuples. • Advantages: many-to-many relationships, high level declarative query language (e.g. SQL) • SQL example (retrieve all items supplied by a supplier located in Troy): • SELECT ItemName • FROM ITEM, SUPPLIES, SUPPLIER • WHERE SUPPLIER.City = "Troy" AND • SUPPLIER.Supplier# = SUPPLIES.Supplier# AND • SUPPLIES.Item# = ITEM.Item# • Programming language interfaces: including SQL queries in the code

9. Retrieving and manipulating data: query processing • Parsing and validating a query: data dictionary - a relation listing all relations and • relations listing the attributes • Plans for computing the query: list of possible way to execute the query, • estimated cost for each. Example: • SELECT ItemNames, Price • FROM ITEM, SALES • WHERE SALES.Item# = ITEM.Item# AND Salesperson="Mary" • Index: B-tree index, drawbacks - additional space, updating; • indexing not all relations (e.g. the keys only) • Estimating the cost for computing a query: size of the relation, existence/size of the indices. • Example: estimating Attribute=value with a given number of tuples and the size of the index. • Query optimization: finding the best plan (minimizing the computational cost and • the size of the intermediate results), subsets of tuples, projection and join. • Static and dynamic optimization

10. Database views • Creating user defined subsets of the database • Improving the user interface • Example: • CREATE VIEW MarySales(ItemName,Price) • AS SELECT ItemName, Price • FROM ITEM, SALES • WHERE ITEM.Item#=SALES.Item# AND Salesperson="Mary" • Then the query: • SELECT ItemName • FROM MarySales • WHERE Proce>100 • translates to: • SELECT ItemName • FROM ITEM, SALES • WHERE ITEM.Item#=SALES.Item# AND Salesperson="Mary" AND Price>100

11. The Entity-Relationship Model

12. Database Design Process • Requirement collection and analysis • DB requirements and functional requirements • Conceptual DB design using a high-level model • Easier to understand and communicate with others • Logical DB design (data model mapping) • Conceptual schema is transformed from a high-level data model into implementation data model • Physical DB design • Internal data structures and file organizations for DB are specified

13. Overview of Database Design • Conceptual design: (ER Model is used at this stage.) • What are the entities and relationships in the enterprise? • What information about these entities and relationships should we store in the database? • What are the integrity constraints or business rules that hold? • A database `schema’ in the ER Model can be represented pictorially (ER diagrams). • An ER diagram can be mapped into a relational schema.

14. name ssn lot Employees ER Model Basics • Entity: Real-world object distinguishable from other objects. An entity is described (in DB) using a set of attributes. • Entity Set: A collection of similar entities. E.g., all employees. • All entities in an entity set have the same set of attributes. (Until we consider ISA hierarchies, anyway!) • Each entity set has a key. • Each attribute has a domain.

15. name ssn lot Employees ER Model Basics • Key and key attributes: • Key: a unique value for an entity • Key attributes: a group of one or more attributes that uniquely identify an entity in the entity set • Super key, candidate key, and primary key • Super key: a set of attributes that allows to identify and entity uniquely in the entity set • Candidate key: minimal super key • There can be many candidate keys • Primary key: a candidate key chosen by the designer • Denoted by underlining in ER attributes

16. name ER Model Basics (Contd.) ssn lot Employees since name dname • Relationship: Association among two or more entities. e.g., Jack works in Pharmacy department. • Relationship Set: Collection of similar relationships. • An n-ary relationship set R relates n entity sets E1 ... En; each relationship in R involves entities e1 in E1, ..., en in En • Same entity set could participate in different relationship sets, or in different “roles” in same set. super-visor subor-dinate ssn budget lot did Reports_To Works_In Employees Departments

17. since name dname ssn lot Employees Manages Key Constraints did budget • Consider Works_In: An employee can work in many departments; a dept can have many employees. • In contrast, each dept has at most one manager, according to the key constrainton Manages. Departments 1-to-1 1-to Many Many-to-1 Many-to-Many

18. Department Example ER major offers faculty • An ER diagram represents several assertions about the real world. What are they? • When attributes are added, more assertions are made. • How can we ensure they are correct? • A DB is judged correct if it captures ER diagram correctly. Courses teaches Professor advisor enrollment Students

19. Department Exercises major offers faculty • Is double major allowed? • Can a student have more than 1 advisor? • Is joint appointment of faculty possible? • Can two profs share to teach the same course? • Can a professor teach more than one course? • Can a professor stay without affiliated with a department? Courses teaches Professor advisor enrollment Students

20. Participation Constraints • Does every department have a manager? • If so, this is a participation constraint: the participation of Departments in Manages is said to be total (vs. partial). • Every Departments entity must appear in an instance of the Manages relationship. since since name name dname dname ssn did did budget budget lot Departments Employees Manages Works_In since

21. Weak Entities • A weak entity can be identified uniquely only by considering the primary key of another (owner) entity. • Owner entity set and weak entity set must participate in a one-to-many relationship set (one owner, many weak entities). • Weak entity set must have total participation in this identifying relationship set. name cost pname age ssn lot Policy Dependents Employees

22. name ssn lot ISA (`is a’) Hierarchies Employees hours_worked • As in C++, or other PLs, attributes are inherited. • If we declare A ISA B, every A entity is also considered to be a B entity. hourly_wages ISA • Overlap constraints: Can Joe be an Hourly_Emps as well as a Contract_Emps entity? (default: disallowed; A overlaps B) • Covering constraints: Does every Employees entity also have to be an Hourly_Emps or a Contract_Emps entity? (default: no; A AND B COVER C) • Reasons for using ISA: • To add descriptive attributesspecific to a subclass. • To identify entities that participate in a relationship. contractid Contract_Emps Hourly_Emps

23. Employees name ssn lot Aggregation Monitors until • Used when we have to model a relationship involving (entitity sets and) a relationship set. • Aggregation allows us to treat a relationship set as an entity set for purposes of participation in (other) relationships. since started_on dname pid pbudget did budget Sponsors Departments Projects • Aggregation vs. ternary relationship: • Monitors is a distinct relationship, • with a descriptive attribute. • Also, can say that each sponsorship • is monitored by at most one employee.

24. Conceptual Design Using the ER Model • Design choices: • Should a concept be modeled as an entity or an attribute? • Should a concept be modeled as an entity or a relationship? • Identifying relationships: Binary or ternary? Aggregation? • Constraints in the ER Model: • A lot of data semantics can (and should) be captured. • But some constraints cannot be captured in ER diagrams.

25. Entity vs. Attribute • Should addressbe an attribute of Employees or an entity (connected to Employees by a relationship)? • Depends upon the use we want to make of address information, and the semantics of the data: • If we have several addresses per employee, address must be an entity (since attributes cannot be set-valued). • If the structure (city, street, etc.) is important, e.g., we want to retrieve employees in a given city, address must be modeled as an entity (since attribute values are atomic).

26. name dname ssn lot did Employees dname did budget Duration to from Entity vs. Attribute (Contd.) to from budget • Works_In4 does not allow an employee to work in a department for two or more periods. • Similar to the problem of wanting to record several addresses for an employee: We want to record several values of the descriptive attributes for each instance of this relationship. Accomplished by introducing new entity set, Duration. Departments Works_In4 name ssn lot Works_In4 Departments Employees

27. Entity vs. Relationship since dbudget name dname • First ER diagram OK if a manager gets a separate discretionary budget for each dept. • What if a manager gets a discretionary budget that covers all managed depts? • Redundancy: dbudget stored for each dept managed by manager. • Misleading: Suggests dbudget associated with department-mgr combination. ssn lot did budget Departments Employees Manages2 name ssn lot dname since did Employees budget Departments Manages2 ISA This fixes the problem! Managers dbudget

28. Summary of Conceptual Design • Conceptual design follows requirements analysis, • Yields a high-level description of data to be stored • ER model popular for conceptual design • Constructs are expressive, close to the way people think about their applications. • Basic constructs: entities, relationships, and attributes (of entities and relationships). • Some additional constructs: weak entities, ISA hierarchies, and aggregation. • Note: There are many variations on ER model.

29. Summary of ER (Contd.) • Several kinds of integrity constraints can be expressed in the ER model: key constraints, participationconstraints, and overlap/covering constraints for ISA hierarchies. Some foreign key constraints are also implicit in the definition of a relationship set. • Some constraints (notably, functional dependencies) cannot be expressed in the ER model. • Constraints play an important role in determining the best database design for an enterprise.

30. Summary of ER (Contd.) • ER design is subjective. There are often many ways to model a given scenario! Analyzing alternatives can be tricky, especially for a large enterprise. Common choices include: • Entity vs. attribute, entity vs. relationship, binary or n-ary relationship, whether or not to use ISA hierarchies, and whether or not to use aggregation. • Ensuring good database design: resulting relational schema should be analyzed and refined further. FD information and normalization techniques are especially useful.

31. name ssn addr Customer name ssn lot Employees Dept deptid budget Exercise acct# balance CustAcct Account • What can you say about policy of the bank from the ER diagram? • What can you say about the policy of the company? Manages

32. Design Exercise • Design a DB using ER, and sketch the resulting diagram. State any important assumptions you made in reaching the design. Show explicitly whether relationships are 1-1, 1-M, or N-M. • UVA registrar’s office: It maintains data about each class, including the instructor, students, enrollment, time and place of the class meetings. For each student-class pair, a grade is recorded. • Hospital: It maintains all patients visited, including age and address. It also keeps track of the information about billing, visits, data, reason for visit, and treatment.

33. Data integrity • Integrity constraints: semantic conditions on the data • Individual constraints on data items • Uniqueness of the primary keys • Dependencies between relations • Concurrency control • Steps in executing a query • Concurrent users of the database, interfering the execution of one query by another • Transaction: a set of operations that takes the database from one consistent state to another • Solving the concurrency control problem: making transactions atomic operations (one at a time) • Concurrent transactions: serializability theory (two-phase locking), read lock (many), write lock (one). • Serializible transactions: first phase - accumulating locks, second phase - releasing locks. • Deadlocks: deadlock detection algorithms. • Distributed execution problems: • release a lock at one node (all locks accumulated at the other node?) • strict two-phase locking

34. The Transaction Model • Examples of primitives for transactions.

35. The Transaction Model • Transaction to reserve three flights commits • Transaction aborts when third flight is unavailable

36. Distributed Transactions • A nested transaction • A distributed transaction

37. Concurrency Control (1) • General organization of managers for handling transactions.

38. Data integrity • Backup and recovery • The problem of keeping a transaction atomic: successful or failed • What if some of the intermediate steps failed? • Log of database activity: use the log to undo a failed transaction. • More problems: when to write the log, failure of the recovery system executing the log. • Security and access control • Access rules for relations or attributes. Stored in a special relation (part of the data dictionary). • Content-independent and content-dependent access control • Content-dependent control: access to a view only or query modification • (e.g. and-ing a predicate to the WHERE clause) • Discretionary and mandatory access control

39. THANK YOU