VARDHAMAN COLLEGE OF ENGINEERING Shamshabad , Hyderabad B.Tech. CSE IV Semester (VCE - R11) T P C 3+1* -- 4 (A1511) DATABASE MANAGEMENT SYSTEMS

Transcription

1 1 VARDHAMAN COLLEGE OF ENGINEERING Shamshabad , Hyderabad B.Tech. CSE IV Semester (VCE - R11) T P C 3+1* -- 4 (A1511) DATABASE MANAGEMENT SYSTEMS UNIT - I INTRODUCTION: History of database systems, introduction to database management systems, database system applications, database systems versus file systems, view of data, data models, database languages- DDL & DML commands and examples of basic SQL queries, database users and administrators, transaction management, database system structure, application architectures. DATABASE DESIGN: Introduction to database design and E-R diagrams, entities, attributes and entity sets, relationships and relationship sets, additional features of the E-R model, conceptual design with the E-R model, conceptual design for large enterprises.

2 2 VARDHAMAN COLLEGE OF ENGINEERING Shamshabad , Hyderabad B.Tech. CSE IV Semester (VCE - R11) T P C 3+1* -- 4 (A1511) DATABASE MANAGEMENT SYSTEMS UNIT - II THE RELATIONAL MODEL: Introduction to the relational model, integrity constraints over relations, enforcing integrity constraints, querying relational data, logical database design: E-R to relational, introduction to views, destroying/altering tables and views. RELATIONAL ALGEBRA AND CALCULUS: Preliminaries, relational algebra operators, relational calculus - tuple and domain relational calculus, expressive power of algebra and calculus. SQL: Overview, the form of a basic SQL query, union, intersect and except operators, nested queries, aggregate operators, null values, complex integrity constraints in SQL, triggers and active databases, designing active databases.

3 3 VARDHAMAN COLLEGE OF ENGINEERING Shamshabad , Hyderabad B.Tech. CSE IV Semester (VCE - R11) T P C 3+1* -- 4 (A1511) DATABASE MANAGEMENT SYSTEMS UNIT - III SCHEMA REFINEMENT AND NORMAL FORMS: Introduction to schema refinement, functional dependencies, reasoning about FDs. Normal forms: 1NF, 2NF, 3NF, BCNF, properties of decompositions, normalization, schema refinement in database design, other kinds of dependencies: 4NF, 5NF, DKNF, case studies.

4 4 VARDHAMAN COLLEGE OF ENGINEERING Shamshabad , Hyderabad B.Tech. CSE IV Semester (VCE - R11) T P C 3+1* -- 4 (A1511) DATABASE MANAGEMENT SYSTEMS UNIT - IV TRANSACTIONS MANAGEMENT: Transaction concept, transaction state, implementation of atomicity and durability, concurrent executions, serializability, recoverability, implementation of isolation, transaction definition in SQL, testing for serializability. CONCURRENCY CONTROL AND RECOVERY SYSTEM: Concurrency control - lock based protocols, time-stamp based protocols, validation based protocols, multiple granularity, and deadlock handling. Recovery system - failure classification, storage structure, recovery and atomicity, log-based recovery, shadow paging, recovery with concurrent transactions, buffer management, failure with loss of non-volatile storage, advanced recovery techniques, remote backup systems.

5 5 VARDHAMAN COLLEGE OF ENGINEERING Shamshabad , Hyderabad B.Tech. CSE IV Semester (VCE - R11) T P C 3+1* -- 4 (A1511) DATABASE MANAGEMENT SYSTEMS UNIT - V OVERVIEW OF STORAGE AND INDEXING: Data on external storage, file organizations and indexing, index data structures, comparison of file organizations, indexes and performance tuning. Tree structured indexing - intuition for tree indexes, indexed sequential access method (ISAM), B+ Trees - a dynamic tree structure. IBM DB2 FUNDAMENTALS*: DB2 product family - versions and editions, DB2 database and its objects, DB2 pure XML, backup and recovery, concurrency and its isolation levels, working with SQL, DB2 programming fundamentals - UDF, stored procedures. * This topic is designed in collaboration with IBM India Private Limited.

6 6 VARDHAMAN COLLEGE OF ENGINEERING Shamshabad , Hyderabad B.Tech. CSE IV Semester (VCE - R11) T P C 3+1* -- 4 (A1511) DATABASE MANAGEMENT SYSTEMS TEXT BOOKS: 1. Raghurama Krishnan, Johannes Gehrke (2007), Database Management Systems, 3rd edition, Tata McGraw Hill, New Delhi, India. REFERENCE BOOKS: 1. Elmasri Navate (1994), Fundamentals of Database Systems, Pearson Education, India. 2. Abraham Silberschatz, Henry F. Korth, S. Sudarshan (2005), Database System Concepts, 5th edition, McGraw-Hill, New Delhi, India. 3. Peter Rob, Carlos Coronel (2009), Database Systems Design, Implementation and Management, 7th edition, India.

7 UNIT I (Part-2) 7 Database Design: Introduction to Database Design Entity - Relationship (E-R) Diagrams Additional Features of the E-R Model Conceptual design with the E-R Model Conceptual design for large enterprises

8 Databases Model the Real World 8 Data Model allows us to translate real world things into structures computers can store Many models: Relational, E-R, O-O, Network, Hierarchical, etc. Relational Rows & Columns Keys & Foreign Keys to link Relations Enrolled sid cid grade Carnatic101 C Reggae203 B Topology112 A History105 B Students sid name login age gpa Jones jones@cs Smith smith@eecs Smith smith@math

9 Steps in Database Design 9 Requirements Analysis user needs; what must database do? Conceptual Design high level description (often done with ER model) Logical Design translate ER into DBMS data model Schema Refinement consistency, normalization Physical Design - indexes, disk layout Security Design - who accesses what, and how

10 Conceptual Design 10 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). Can map an ER diagram into a relational schema.

11 Entity - Relationship (E-R) Model Basics 11 A Conceptual Level Data Model Mainly for database design Provides the concepts of entities, relationships and attributes. Models an enterprise as a collection of entities and relationships Entity: a thing or object in the enterprise that is distinguishable from other objects Described by a set of attributes Relationship: an association among several entities

12 The Entity - Relationship Diagram (ERD) 12 Developing a database model based on the E-R diagram involves identifying the entities and the relationships between them. These are usually displayed in an E-R diagram. The ERD or Entity-Relationship Diagram marks a culmination in the process of database design. Once this is done, the database design can proceed with the process of actually creating the tables. ERDs graphically represent the entities, the attributes of an entity, and the relationships that exist between these entities.

13 The Entity - Relationship Diagram (ERD) 13 Case Study: Customer-Orders A customer places an order for several items. The Order- Processing Executive checks for the availability of the items and accordingly proceeds with processing the order. The nouns in the above-mentioned scenario form the entities. Therefore, we can say that Customer, Order, Order-Processing Executive and Item are the entities. The customer would have a Customer Code, a Name and perhaps a Phone No and Address. These comprise the attributes or properties of the entity Customer. Customer places an order is the relationship between the entities customer and order. Similarly, an order consist of Items.

14 The Entity - Relationship Diagram (ERD) 14 Case Study: Customer-Orders In our case study, Customer, Order and Item were entities. These entities along with their attributes are identified and listed, as shown below. Entity Customer Order Item Attributes Customer Code, Customer Name, Address, Phone No Order No, Order Data, Customer Code, Item Code, Qty Ordered Item Code, Item Name, Rate, Quantity On Hand, ReOrder Level Table: Entities and Attributes

15 The Entity - Relationship Diagram (ERD) 15 Case Study: Customer-Orders The Relationships that exist between the entities could be described as follows: A Customer places an Order An Order comprises of several Items Once we have this as an outline, we could proceed with creating an ERD that would look as shown in Figure.

16 The Entity - Relationship Diagram (ERD) 16 Figure: An Entity Relationship Diagram Customer Places Order Customer Name Customer Code Phone No. Address Order No. Order Date Qty Ordered Item Code Customer Code The relationship b/n customer & order is One to Many i.e. one customer can place many orders and an order can contain more than one item

17 The Entity - Relationship Diagram (ERD) 17 Case Study: Customer-Orders The symbols used in ERD are explained below: - Denote an Entity in an ERD - Represents an Attribute of an Entity - Denotes the relationship between Entities

18 The Entity - Relationship Diagram (ERD) 18 Case Study: Customer-Orders A customer could place more than one order, and an order can contain more than one item. In such a case it is said that the relationship between Customer and order is that of one to many, as one Customer can place many orders. On the other hand, the relationship between an Item and its Item Code is that of one to one, as one Item can have only one code. Similarly, the relationship between Order and Item can be considered to be a many to many relationship. In this case, one Order can have many Items, and a particular Item could be a part of several Orders.

19 The Entity - Relationship Diagram (ERD) 19 Relationship Types: One to One (represented in ERD as 1:1) One to Many (represented in ERD as 1:N) Many to One (represented in ERD as N:1) Many to Many (represented in ERD as M:N)

20 Relationship Types One to One Company 1 1 director Employee One to Many Company 1 N director Employee Many to Many Company M director N Employee

21 Entity, Entity Set 21 Entity: Real-world object, distinguishable from other objects. An entity is described using a set of attributes. Entity Set: A collection of similar entities that share the same properties. E.g., all employees, set of all persons, companies. All entities in an entity set have the same set of attributes. (Until we consider hierarchies, anyway!) Each entity set has a key (underlined). Each attribute has a domain. ssn name Employees lot

22 Entity Sets customer and loan 22 customer_id customer_ customer_ customer_ loan_ amount name street city number

23 Relationship, Relationship Set 23 name since dname ssn lot did budget Employees Works_In Departments Relationship: Association among two or more entities. E.g.,1. Attishoo works in Pharmacy department. 2. Hayes depositor A-102 customer entity relationship set account entity relationships can have their own attributes.

24 Relationship, Relationship Set 24 Relationship Set: Collection of similar relationships. An n-ary relationship set R relates n entity sets E 1... E n ; each relationship in R involves entities e 1 E 1,..., e n E n A relationship set is a mathematical relation among n 2 entities, each taken from entity sets {(e1, e2, en) e1 E1, e2 E2,, en En} where (e1, e2,, en) is a relationship Example: (Hayes, A-102) depositor

25 25 Relationship Set borrower

26 Relationship Set 26 An attribute can also be property of a relationship set. For instance, the depositor relationship set between entity sets customer and account may have the attribute access-date

27 Degree of a Relationship Set 27 Refers to number of entity sets that participate in a relationship set. Relationship sets that involve two entity sets are binary (or degree two). Generally, most relationship sets in a database system are binary. Relationship sets may involve more than two entity sets. Example: Suppose employees of a bank may have jobs (responsibilities) at multiple branches, with different jobs at different branches. Then there is a ternary relationship set between entity sets employee, job, and branch Relationships between more than two entity sets are rare. Most relationships are binary.

28 Relationship Set 28 name ssn lot did dname budget since supervisor Employees subordinate Departments Works_In Reports_To Same entity set can participate in different relationship sets, or in different roles in the same set.

29 Binary vs. Ternary Relationships 29 If each policy is owned by just 1 employee: Key constraint on Policies would mean policy can only cover 1 dependent! name ssn lot pname age Employees Bad design name ssn lot Employees Covers Dependents Policies policyid cost pname age Dependents Think through all the constraints in the 2nd diagram! Purchaser Better design Beneficiary Policies policyid cost

30 30 Binary vs. Ternary Relationships (Contd.) Previous example illustrated a case when two binary relationships were better than one ternary relationship. An example in the other direction: a ternary relation Contracts relates entity sets Parts, Departments and Suppliers, and has descriptive attribute qty. No combination of binary relationships is an adequate substitute.

31 31 Binary vs. Ternary Relationships (Contd.) qty Parts Contract Departments Suppliers VS. Parts needs Departments can-supply Suppliers deals-with S can-supply P, D needs P, and D deals-with S does not imply that D has agreed to buy P from S. How do we record qty?

32 32 The Entity - Relationship Diagram (ERD)

33 Attributes 33 An entity is represented by a set of attributes, that is descriptive properties possessed by all members of an entity set. Example: customer = (customer_id, customer_name, customer_street, customer_city ) loan = (loan_number, amount ) Domain the set of permitted values for each attribute Attribute types: Simple and composite attributes. Single-valued and multi-valued attributes Example: multivalued attribute: phone_numbers Derived attributes Can be computed from other attributes Example: age, given date_of_birth

34 34 Composite Attributes

35 E-R Diagrams Rectangles represent entity sets. Diamonds represent relationship sets. Lines link attributes to entity sets and entity sets to relationship sets. Ellipses represent attributes Double ellipses represent multivalued attributes. Dashed ellipses denote derived attributes. Underline indicates primary key attributes

36 E-R Diagram With Composite, Multivalued, and Derived Attributes

37 Relationship Sets with Attributes

38 Mapping Cardinality Constraints 38 Express the number of entities to which another entity can be associated via a relationship set. Most useful in describing binary relationship sets. For a binary relationship set the mapping cardinality must be one of the following types: One to one One to many Many to one Many to many

39 Mapping Cardinalities 39 One to one One to many Note: Some elements in A and B may not be mapped to any elements in the other set

40 Mapping Cardinalities 40 Many to one Many to many Note: Some elements in A and B may not be mapped to any elements in the other set

41 Mapping Cardinalities 41 Relationship Types: One to One (represented in ERD as 1:1) One to Many (represented in ERD as 1:N) Many to One (represented in ERD as N:1) Many to Many (represented in ERD as M:N)

42 Relationship Types 42 One to One Company 1 1 director Employee One to Many Company 1 N director Employee Many to Many Company M director N Employee

43 Cardinality Constraints 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

44 One-To-Many Relationship In the one-to-many relationship a loan is associated with at most one customer via borrower, a customer is associated with several (including 0) loans via borrower

45 Many-To-One Relationships In a many-to-one relationship a loan is associated with several (including 0) customers via borrower, a customer is associated with at most one loan via borrower

46 Many-To-Many Relationship A customer is associated with several (possibly 0) loans via borrower A loan is associated with several (possibly 0) customers via borrower

47 Alternative Notation for Cardinality Limits Cardinality limits can also express participation constraints

48 Keys 48 A super key of an entity set is a set of one or more attributes whose values uniquely determine each entity. A candidate key of an entity set is a minimal super key Customer_id is candidate key of customer account_number is candidate key of account Although several candidate keys may exist, one of the candidate keys is selected to be the primary key.

49 Keys for Relationship Set 49 The combination of primary keys of the participating entity sets forms a super key of a relationship set. (customer_id, account_number) is the super key of depositor NOTE: this means a pair of entity sets can have at most one relationship in a particular relationship set. Example: if we wish to track all access_dates 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 what are the candidate keys Need to consider semantics of relationship set in selecting the primary key in case of more than one candidate key

50 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

51 Participation of an Entity Set in a Relationship Set Total participation (indicated by double line): every entity in the entity set participates in at least one relationship in the relationship set E.g. 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

52 Participation Constraints 52 Does every employee work in a department? If so, this is a participation constraint the participation of Employees in Works_In is said to be total (vs. partial) What if every department has an employee working in it? Basically means at least one ssn name lot since did dname budget Employees Manages Departments Works_In since Means: exactly one

53 E-R Diagram with a Ternary Relationship

54 Cardinality Constraints on Ternary Relationship We allow at most one arrow out of a ternary (or greater degree) relationship to indicate a cardinality constraint E.g. an arrow from works_on to job indicates each employee works on at most one job at any branch. If there is more than one arrow, there are two ways of defining the meaning. E.g a ternary relationship R between A, B and C with arrows to B and C could mean 1. each A entity is associated with a unique entity from B and C or 2. each pair of entities from (A, B) is associated with a unique C entity, and each pair (A, C) is associated with a unique B Each alternative has been used in different formalisms To avoid confusion we outlaw more than one arrow

55 Weak Entities 55 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 ssn lot cost pname age Employees Policy Dependents Weak entities have only a partial key (dashed underline)

56 56 Weak Entities

57 57 Weak Entities

58 Weak Entity Sets 58 An entity set that does not have 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-tomany 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 set s discriminator.

59 Weak Entity Sets (Cont.) 59 We depict a weak entity set by double rectangles. We underline the discriminator of a weak entity set with a dashed line. payment_number discriminator of the payment entity set Primary key for payment (loan_number, payment_number)

60 Weak Entity Sets (Cont.) 60 Note: 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

61 More Weak Entity Set Examples 61 In a university, a course is a strong entity and a course_offering can be modeled as a weak entity The discriminator of course_offering would be semester (including year) and section_number (if there is more than one section) If we model course_offering as a strong entity we would model course_number as an attribute. Then the relationship with course would be implicit in the course_number attribute

62 UNIT I (Part-2) 62 Database Design: Introduction to Database Design Entity - Relationship (E-R) Diagrams Additional Features of the E-R Model Conceptual design with the E-R Model Conceptual design for large enterprises

63 Additional or Extended E-R Features: Specialization 63 Top-down design process; we designate subgroupings within an entity set that are distinctive from other entities in the set. These subgroupings become lower-level entity sets that have attributes or participate in relationships that do not apply to the higher-level entity set. Depicted by a triangle component labeled ISA (E.g. customer is a person). 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.

64 64 Specialization Example

65 Specialization Example

66 ISA (`is a ) Hierarchies ssn name lot 66 Employees hourly_wages hours_worked ISA contractid Hourly_Emps Contract_Emps 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.

67 ISA (`is a ) Hierarchies 67 Overlap constraints: Can Simon be an Hourly_Emps as well as a Contract_Emps entity? (Allowed/disallowed) Covering constraints: Does every Employees entity also have to be an Hourly_Emps or a Contract_Emps entity? (Yes/no) Reasons for using ISA: To add descriptive attributes specific to a subclass. i.e. not appropriate for all entities in the superclass To identify entities that participate in a particular relationship i.e., not all superclass entities participate

68 Extended ER Features: Generalization 68 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.

69 Specialization and Generalization (Cont.) 69 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 superclass - subclass relationship

70 70 Design Constraints on a Specialization/Generalization Constraint on which entities can be members of a given lowerlevel entity set. condition-defined Example: all customers over 65 years are members of senior-citizen entity set; senior-citizen ISA person. user-defined Constraint on whether or not entities may belong to more than one lower-level entity set within a single generalization.

71 71 Disjoint Design Constraints on a Specialization/Generalization an entity can belong to only one lower-level entity set Noted in E-R diagram by writing disjoint next to the ISA triangle Overlapping an entity can belong to more than one lower-level entity set

72 72 Design Constraints on a Specialization/Generalization (cont.) Completeness constraint -- 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 : an entity must belong to one of the lower-level entity sets partial: an entity need not belong to one of the lower-level entity sets

73 Aggregation 73 Consider the ternary relationship works_on, which we saw earlier Suppose we want to record managers for tasks performed by an employee at a branch

74 Aggregation ssn name lot 74 Used to model a relationship involving a relationship set. Allows us to treat a relationship set as an entity set for purposes of participation in (other) relationships. pid started_on Projects Employees Monitors pbudget since Sponsors did until dname Departments 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. budget

75 Aggregation (Cont.) 75 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 can t 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

76 76 E-R Diagram With Aggregation

77 Aggregation 77 Consider the ternary relationship proj_guide Suppose we want to record evaluations of a student by a guide on a project

78 78 Aggregation

79 E-R Design Decisions 79 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 single unit without concern for the details of its internal structure.

80 80 Complete Example for E - R Schema

81 81 Complete Example for E - R Schema

82 82 Complete Example for E - R Schema

83 83 Complete Example for E - R Schema

84 84 E-R Diagram for a Banking Enterprise

85 85 E-R Diagram for a University Enterprise

86 86 E-R Diagram for BANK MANAGEMENT SYSTEM

87 87 E-R Diagram for MOVIE DATABASE

88 88

89 89

90 90

91 91

92 92

93 93

94 94

95 95 Summary of Symbols Used in E-R Notation

96 96 Summary of Symbols (Cont.)

97 UNIT I (Part-2) 97 Database Design: Introduction to Database Design Entity - Relationship (E-R) Diagrams Additional Features of the E-R Model Conceptual design with the E-R Model Conceptual design for large enterprises

98 Conceptual Design Using the ER Model ER modeling can get tricky! 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? Note constraints of the ER Model: A lot of data semantics can (and should) be captured. But some constraints cannot be captured in ER diagrams. We ll refine things in our logical (relational) design

99 Entity vs. Attribute Should address be an attribute of Employees or an entity (related to Employees)? Depends upon how we want to use 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, address must be modeled as an entity (since attribute values are atomic). 99

100 Entity vs. Attribute (Cont.) 100 Works_In2 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. ssn name Employees ssn name lot Employees from lot from to Works_In2 Works_In3 Duration did did dname budget Departments to dname budget Departments

101 101 OK as long as a manager gets a separate discretionary budget (dbudget) for each dept. What if manager s dbudget covers all managed depts? (can repeat value, but such redundancy is problematic) Entity vs. Relationship name ssn Employees name ssn Employees since dbudget lot did Manages2 lot did dname budget Departments dname budget Departments is_manager managed_by since apptnum Mgr_Appts dbudget

102 Summary of Conceptual Design 102 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. Note: There are many variations on ER model Both graphically and conceptually Basic constructs: entities, relationships, and attributes (of entities and relationships). Some additional constructs: weak entities, ISA hierarchies, and aggregation.

103 UNIT I (Part-2) 103 Database Design: Introduction to Database Design Entity - Relationship (E-R) Diagrams Additional Features of the E-R Model Conceptual design with the E-R Model Conceptual design for large enterprises

104 Conceptual design for large enterprises 104 The process of conceptual design consists of more than just describing small fragments of the application in terms of ER diagrams. For a large enterprise, the design may require the efforts of more than one designer and span data and application code used by a number of user groups. An important aspect of the design process is the methodology used to structure the development of the overall design and to ensure that the design takes into account all user requirements and is consistent.

105 Conceptual design for large enterprises 105 The usual approach is that the requirements of various user groups are considered, any conflicting requirements are somehow resolved, and a single set of global requirements is generated at the end of the requirements analysis phase. An alternative approach is to develop separate conceptual schemas for different user groups and to then integrate these conceptual schemas. To integrate multiple conceptual schemas, we must establish correspondences between entities, relationships, and attributes, and we must resolve numerous kinds of conflicts.

106 END OF UNIT I (Part-2) 106 Database Design: Introduction to Database Design Entity - Relationship (E-R) Diagrams Additional Features of the E-R Model Conceptual design with the E-R Model Conceptual design for large enterprises