Chapter 2 ENTITY RELATIONSHIP MODEL

INTRODUCTION Chapter 2 ENTITY RELATIONSHIP MODEL Data model is used to describe data, data relationship and constraints on data. A number of different data models have proposed. They can broadly be classified into two categories: Object-based logical models. Record-based logical models. The object-based model can be defined as a collection of conceptual tools for describing data, data relationships, and data constraints. The record-based model describes the data structures and access techniques of a DBMS. There are various different object-based models. Some of the more popular ones are: The entity-relationship model The binary model The infological model The semantic model Of these, the most widely used one is the Entity-Relationship Model. It has gained acceptance as the ideal data model for database design. This model was introduced by Peter Chen in 1976, and since then it has been reformed by several persons. The entity relationship model (E R Model) is based on a perception of real world that is made up of a collection objects or entities and the relationship among these. Conceptual Model Before going to explaining the entity-relationship model, we will briefly discuss database design. Database design involves designing the conceptual design model of the database. The conceptual model reflects the entities and their relationships, based on the data processing needs of the organization. This can be considered equivalent to the conceptual level. The conceptual model is a communication tool between the various users of the data. It is developed without any concern for physical representation. The conceptual model is used to organize, visualize, plan and communicate ideas. It is independent of the database management system. Before actually implementing the database, the conceptual model is designed. At this stage, requirements of all the users are considered to decide upon the actual data to be stored in the system. This conceptual model is then mapped to the DBMS that is actually to be used. Data analysis is the first step in designing a conceptual model. Data analysis begins with collecting information about the data. This usually involves using a questionnaire or a similar method to obtain a list of data that the organization needs. Existing forms, bills, reports are starting points for data collection. The data analysis involves identifying entities, their attributes, and the relationships between attributes. The E-R Model is a way to form and represent the conceptual model of database design

Basic concepts of E-R Model: An entity relationship diagram is a graphical representation of an organisation's data storage requirements. Entity relationship diagrams are abstractions of the real world which simplify the problem to be solved while retaining its essential features. Entity relationship diagrams are used to: identify the data that must be captured, stored and retrieved in order to support the business activities performed by an organisation identify the data required to derive and report on the performance measures, that an organisation should be monitoring. Entity relationship diagrams have three different components: 1) ENTITIES 2) ATTRIBUTES 3) RELATIONSHIPS Entity : Entities are the people, places, things, events and concepts of interest to an organisation. In short, anything which an organisation needs to store data about. Entity can be concrete like employee, book, project, publisher etc. and can be abstract or a concept for example title, job, company etc. which have no physical existence. Entity set represents collection of things. For example, an EMPLOYEE entity set might represent a collection of all the employees that work for an organisation. Individual members (employees) of the collection are called instance of the EMPLOYEE entity set. Attribute: Properties or characteristics possessed by an entity are called as attributes. Attributes are same for each entity set but their values may differ from each other. For example, EMPLOYEE entity set has attributes name, age, empid and salary but the values of these attributes may be different for each employee in the entity set. Domain :The set of possible values for an attribute is called the domain of the attribute. Some of the examples are: The domain of attribute marital status is just the four values: single, married, divorced, widowed. The domain of the attribute month is the twelve values ranging from January to December. The domain of attribute empid of EMPLOYEE entity set consist of only positive integers. Key attribute :The attribute (or combination of attributes) that is unique for every entity instance e.g the account number of an account, the employee id of an employee etc. Simple Vs composite attribute Simple attribute: An attribute that cannot be divided into simpler components is called simple attribute. E.g age of an employee, pub-id of a book title of a book entity. Composite attribute: An attribute that can be split into components is called composite attrbute. E.g Date of joining of the employee can be split into day, month and year

Single Vs Multi-valued Attribute Single valued : Attributes that can take on only a single value for each entity instance are called single valued attribute. E.g. age of employee, pubid of a publisher Multi-valued: Attributes that can take many values for each entity instance are called multi-valued attributes. E.g. skill set of employee Stored Vs Derived attribute Stored Attribute: Attribute that need to be stored permanently. E.g. name of an employee Derived Attribute: Attribute that can be calculated based on other attributes. E.g. : years of service of employee can be calculated from date of joining and current date Figure 1: Type of attributes Regular Vs. Weak entity type Regular Entity: Entity that has its own key attribute. It is also called independent entity because it does not dependent on any other entity for existence. E.g.: Employee, student, customer, policy holder etc. Weak entity: Entity that depends on other entity for its existence and doesn t have key attribute of its own. It is also called dependent entity because its existence depends on the existence of another entity. E.g. : spouse of employee, the spouse data is identified with the help of the employee id to which it is related. The dependent entity is represented by a double lined rectangle and the identifying relationship by a double lined diamond. the identifying relationship is the one which relates the weak entity with the strong entity on which it depends

Employee Has Dependents Figure 2: Weak Entity Null Values :Null value of an attribute is considered if that attribute does not have a value for a particular entity. A null value is a value that is unavailable, unassigned, unknown, or inapplicable. A null value is not the same as zero or a space, because zero is a number, and a space is a character. For example, in phone_no attribute is having Null value then it means the value may not be applicable. Keys :A key is a single attributer or a combination of attributes whose values uniquely identify each tuple in that relation. In other words, no tow entities in an entity set are allowed to have exactly the same value for all attributes. A key allows us to identify a set of attributes that are suffice to distinguish relationships from each others. Superkey :An attribute, or group of attributes, that is sufficient to distinguish every tuple in the relation from every other one. Each super key is called a candidate key Candidate key :A candidate key is any set of one or more columns whose combined value is unique through out that table. Since a null value is not guaranteed to be unique, no component of a candidate key is allowed to be null. There can be number of candidate keys in a table. Primary key :The primary key of any table is any candidate key of that table which the database designer arbitrarily designates as primary. The primary key may be selected for convenience, comprehension, performance or any other reasons. Every entity must have a primary key. The primary key is an attribute or combination of attributes that uniquely identifies an instance of the entity. In other words, no two instances of an entity may have the same value for the primary key. Sometimes it is useful to use more than one attribute to form a primary key. When a primary key for an entity is made up of more than one attribute the key is called a composite key. The terms composite key is also used to describe primary keys that contain multiple attributes. When dealing with a composite primary key it is important to understand that it is the combination of values for all attributes that must be unique. It is not necessary for each attribute in the key to be unique. For example, the entity ENROLLMENT has a composite primary key comprised of the attributes STUDENT_ID and COURSE_ID. Each instance of ENROLLMENT must contain a unique combination of values for StudentID and CourseID. However, there can be duplications of StudentID or CourseID. So, it is possible for many instances of ENROLLMENT to have the value MIS100 for CourseID, but each of those instances must contain different values for StudentID.

Figure 3: Primary key Alternate key :The alternate keys of any table are simply those candidate keys which are not currently selected as the primary key. Foreign key: A foreign key is a set of attribute(s) whose values are required to match values of a candidate key in the same or another table. A foreign key is a copy of the whole of its parent candidate key i.e if the candidate key is composite, then so is the foreign key Foreign key values do not (usually) have to be unique Foreign keys can also be null A composite foreign key cannot have some attribute(s) null and others non-null Figure 4 : Foreign key Relationship : A relationship type between two entity types defines the set of all associations between these entity types. Each instance of the relationship between members of these entity types is called a relationship instance. For example: EMPLOYEEs work in a DEPARTMENT LAWYERs advise CLIENTs

EQUIPMENT is allocated to PROJECTs TRUCK is a type of VEHICLE Degree of a Relationship : The degree of a relationship is the number of entities associated with the relationship. One - Unary Two - Binary Three Ternary Unary Relationship: A unary or recursive binary relationship occurs when an entity is related to itself. An example might be "some employees are married to other employees". A unary relationship is represented as a diamond which connects one entity to itself as a loop. The relationship below means, some instances of employee manage other instances of Employee. Employee Manages Figure 5: Unary Relationship Binary Relationship: Binary relationship association between two entities is the most common type in the real world. Employee Works for Department Figure 6: Binary Relationship Ternary Relationship: A ternary relationship involves three entities and is used when a binary relationship is inadequate. Many modeling approaches recognize only binary relationships. Ternary or n-ary relationships are decomposed into two or more binary relationships.

Cardinality and Connectivity Figure 7: Ternary Relationship The connectivity of a relationship describes the mapping of associated entity instances in the relationship. The values of connectivity are "one" or "many". The cardinality of a relationship is the actual number of related occurences for each of the two entities. The basic types of connectivity for relations are: one-to-one, one-to-many, and many-tomany. Relationships can have different connectivity one-to-one (1:1) one-to-many (1:N) many-to- One (M:1) many-to-many (M:N) One-toOone (1:1) relationship: A one-to-one (1:1) relationship is when at most one instance of a entity A is associated with one instance of entity B. For example, "each employee in the company has been assigned his own office. For each employee there exists a unique office and for each office there exists a unique employee. P1 P2 P3 P4 C1 C2 C3 C4 PERSON CHAIR Figure 8 : One to One One-to-Many (1:N) relationships A one-to-many (1:N) relationships is when for one instance of entity A, there are zero, one, or many instances of entity B, but for one

instance of entity B, there is only one instance of entity A. For example a department has many employees or each employee is assigned to one department. O1 O2 O3 E1 E2 E3 E4 E5 ORGANIZATION Figure 9 : One to Many EMPLOYEE E1 E2 E3 E4 E5 D1 D2 D3 EMPLOYEE DEPARTMENT Figure 10 : Many to one Many-to-Many (M:N) relationship A many-to-many (M:N) relationship, sometimes called non-specific, is when for one instance of entity A, there are zero, one, or many instances of entity B and for one instance of entity B there are zero, one, or many instances of entity A. For example employees can be assigned to no more than two projects at the same time and projects must have assigned at least three employees. Therefore a single employee can be assigned to many projects; conversely, a single project can have assigned to it many employee. Here the cardinality for the relationship between employees and projects is two and the cardinality between project and employee is three.

S1 S2 S3 S4 C1 C2 C3 C4 STUDENT COURSE Figure 11: Many to many ER Notations for Cardinality: An entity may be associated with one, none, or many occurrences of another entity. In ER diagrams, the types of relationships are represented as follows: Figure 12: Cardinality Represents zero and represents one. Dashed line between entity box and relationship box represents optional existence A crow foot represents many type of relationship Represents minimum of one and maximum of one existence of entity instances in a relationship A is associated with a minimum of zero Bs and a maximum of 1 B. A R B Figure 13: Minimum of 0 and maximum of 1 relationship

A is associated with a minimum of 1B and a maximum of 1 B A R B Figure 14: Minimum of 1 and maximum of 1 relationship A is associated with a minimum of 0 B and maximum of that is any number greater than 1. A R B Figure 15 :Minimum of 0 and maximum of >1 relationship A is associated with a minimum of 1 B and maximum of that is any number greater than 1. A R B Figure 16 : Minimum of 1 and maximum of >1 relationship Relationships can also differ in terms of their cardinality. Maximum cardinality refers to the maximum number of instances of one entity that can be associated with a single instance of a related entity. Minimum cardinality refers to the minimum number of instances of one entity that must be associated with a single instance of a related entity. The following examples of binary relationships illustrate the concept of maximum cardinality. If one CUSTOMER can be related to only one ACCOUNT and one ACCOUNT can be related to only a single CUSTOMER, the cardinality of the CUSTOMER-ACCOUNT relationship is one-to-one (1:1). Customer Have Account Figure 17 : one-to-one (1:1) relationship If an ADVISOR can be related to one or more STUDENTS, but a STUDENT can be related to only a single ADVISOR, the cardinality is one-to-many (1:N).

Advisor Advise Student Figure 18: one-to-many (1:N) relationship Finally, the cardinality of the relationship is many-to-many (M:N) if a single STUDENT can be related to zero or more COURSES and a single COURSE can be related to zero or more STUDENTS. Student Take Course Figure 19: many -to-many (M:N) relationship Relationship Participation Total : Every entity instance must be connected through the relationship to another instance of the other participating entity types Partial: All instances need not participate E.g.: Employee and Head-of Department Employee: partial Department: total All employees will not be head-of some department. So only few instances of employee entity participate in the above relationship. But each department will be headed by some employee. So department entity s participation is total and employee entity s participation is partial in the above relationship Employee Head of Department Partial participation Total participation Figure 20 : Relationship participation Partial :All instances of the entity type Employee don t participate in the relationship, Head-of. Every employee doesn t head a department. So, employee entity type is said to partially participate in the relationship. Total : But, every department would be headed by some employee. So, all instances of the entity type Department participate in this relationship. So, we say that it is total participation from the department side.

Attribute of a relationship: These attributes best describe the relationship rather than any individual entity Medicine Dosage No. of Days Doctor Prescription Patient Figure 21: Relationship attributes Extended E-R Features Superclass and Subclass: Certain instances of an entity class can include attributes that are not needed in other instances of the same entity class. In these cases, it is useful to use a superclass/subclass structure. This structure is also called a generalization/ specialization hierarchy. i. Subclass: A subgroup an entity type which has attributes that are distinct from those in other subgroups ii. Superclass: An generic entity type that has a relationship with one or more subclasses iii. Inheritance a. Subclass entities inherit values of all attributes of the superclass b. An instance of a subclass is also an instance of the superclass Specialization : Specialization is the process of defining a set of subclasses of an entity type; this entity type is called the superclass of the specialization. The set of subclasses that form a specialization is defined on the basis of some distinguishing characteristics of the entities in the superclass. Consider an entity set EMPLOYEE with attributes Name, Employeeid, Address, Birthdate, Jobtype. An Employee may be further classified as one of the following SECERATRY ENGINEER TEHCNICIAN Each of these employee types is described by a set of attributes that includes all the attributes of entity set employee plus possibly additional attributes. For example, SECERATRY entities my be described further by the attribute TypingSpeed, whereas TECHNICIAN entities may be described further by the attribute Tgrade and ENGINEER entities may be described by EngType. The processof designating subgroupings within an entity set is called specialization. The specialization of EMPLOYEE allow us to distinguish among EMPLOYEES according to whether they are SECERATRY, TECHNICIAN or ENGINEER.

We call each of these subgrouping a subclass of the EMPLOYEE entity type, and the EMPLOYEE entity type is called the superclass for each of these subclasses. In terms of E-R diagram, specialization is depicted by a triangle component labeled ISA. The label ISA stands for is a and represents, for example, that a customer is a person. The ISA relationship can also be referred as superclass-subclass relationship. NoOfAxles NoOfPassengers Price Price Tonnage MaxSpeed CAR TRUCK VehicleId VehicleId LicencePlacte No. LicencePlacte No. Figure 22(a) Price VehicleId LicencePlacteNo VEHICLE ISA MaxSpeed Tonnage NoOfPasseng ers NoOfAxle s CAR TRUCK Figure 22 : Specialization

Generalization: Generalization is a reverse process of abstraction which suppress the differences among several entity types. It is a form of abstraction that specifies that two or more entities that share common attributes can be generalized into a higher level entity type called a supertype or generic entity. The lower-level of entities become the subtype, or categories, to the supertype. Subtypes are dependent entities. For example, consider the entity types CAR and TRUCK shown in Figure 22(a). Because they have several common attributes, they can be generalized into the entity type VEHICLE, as shown in Figure 22 (b) Generalization process can be viewed as inverse of specialization process. Therefore in figure 1(b) we can view {CAR,TRUCK} as a specialization of VEHICLE, rather than viewing VEHICLE as a generalization of CAR and TRUCK. Constraints and characteristics of Specialization : To model an enterprise more accurately, the database designer may choose to place certain constraints on a particular specialization. These constraints could be of various types. Birthdate Employeei Address Name EMPLOYEE JobType ISA TypingSpeed TGrade EngType SECRETARY TECHNICIAN ENGINEER Figure 23: Condition defined constraint Condition-defined Vs User-defined constraint : In some specialization we can determine exactly the entities that will members of each subclass by placing a condition on the value of some attribute of the superclass. Such subclasses are called conditiondefined. When we don t have a condition for determining membership in a subclass, the subclass is called user-defined

a) 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. For example, if the EMPLOYEE entity type has an attribute JobType, as shown in Figure 23 we can specify the condition of membership in the SECRETARY subclass by the condition (JobType= Secretary ), which we call the defining predicate of the subclass. The condition is a constraint specifying that exactly those entities of the EMPLOYEE entity type whose attribute value for JobType is Secretary belong to the subclass. This type of specialization is also called attribute-defined. b) User-defined:. Membership in such a subclass is determined by the database users when they apply the operation to add an entity to the subclass therefore the membership is specified individually for each entity by the user, not by any condition that may be evaluated automatically. For instance, let us assume that, after 3 months of employment, the employees of a software company are assigned to one of four work team. We therefore represent the teams as four lower-level entity sets of the higher-level employee entity set. A given employee is not assigned to a specific team entity automatically on the basis of an explicit defining condition. Instead, the user in charge of this decision makes the team assignment on an individual basis. This assignment is implemented by an operation that adds an entity to an entity set. Disjoint V/S Overlapping constraint : A second type of constraint relates to whether or not entities may belong to more than one lower-level entity set within a single generalization. The lower-level entity sets may be one of the following: a) Disjoint: In a disjoint hierarchy, an entity instance can be in only one subtype. For example, the entity EMPLOYEE, may have two subtypes, CLASSIFIED and WAGES. An employee may be one type or the other but not both. Figure 23 shows disjoint and Figure 2. 22 (b) overlapping generalization hierarchy EMPLOYEE ISA CLASSIFIED WAGES. Figure 23 Disjoint generalization b) Overlapping: An overlapping category is when an entity instance may be in two or more subtypes. An example would be a person who works for a university could also be a student at that same university. Overlapping in lower-level entity set is the default case. We can denote disjointedness constraint in an E-R diagram by adding the word disjoint next to the triangle symbol.

Completeness constraint The third constraint on specialization is called the completeness constraint, which may be total or partial. PERSON ISA FACULTY STAFF STUDENT Total v/s Partial Spcialization Figure 24 : Overlapping generalization a) Total Specialization: A total specialization constraint specifies that every entity in the superclass must be a member of least one subclass in the specialization. For example, if every employee must be either an HOURLY_EMPLOYEE or a SALARIED_EMPLOYEE, then the spcialization{hourly_employee, SALARIED_EMPLOYEE} is a total specialization. (figure 2.23) b) Partial specialization: In partial specialization some of higher-level entities may not belong to any lower-level entity set. For example, if some EMPLOYEE entities do not belong to any of the subclass {SECRETARY, ENGINEER, TECHNICIAN}, then that specialization is partial.( Figure 2. 21) Partial generalization is the default. We can specify total generalization in an E-R diagram by using a double line to connect the box representing the higher-level entity set to the triangle symbol. The disjointedness and completeness constraints are independent. Therefore, we have the following four possible constraints on specialization: 1) Disjoint, total 2) Disjoint, partial 3) Overlapping, total 4) Overlapping, partial EMPLOYEE ISA HOURLY_EMPLOYEE SALARIED_EMPLOYEE Figure 24: Total Specialization

AGGREGATION The E-R model has one limitation that it is not possible to express relationships among relationships. In such situations we use aggregation. Aggregation, is an approach of modeling a relationship set as a higher level entity set or, in other words, aggregation helps to model the participation of one relationship set into other relationship set. For example, consider publisher database in which an author writes a particular book and a publisher publishes the book on a specific date written by a particular author. To model the situation, an E-R diagram is shown in fig. 25. Author Write Book Works_For Publish Publisher Figure 25 E-R Diagram with Redundant Relationship The situation is modelled by associating publisher with entity set author and book through a relationship publish as shown in fig. 25. But this model produces redundant information since every author-book pair in publish is also in writes so better method to model the situation is aggregation. Aggregation is an abstraction through which relationships are treated as higher level entities. We can treat the relationships set writes along with the entity sets author and Book as a higher level entity set called author-book as shown in fig. 26.

Author Write Book Publish Publisher Figure 26 E-R Diagram with Aggregation So, Aggregation allow us to indicate that a relationship set participates in another relationship set. Aggregation is depicted by a rectangle as shown in fig. 26. Writes relationship can be represented as a ternary relationship involving publisher, author and Book. But it is not correct as publish and writes are two different relationships having different attributes, as publish has the attribute pub_date which specifies the date of publication and writes has the attribute from which specifies the time since the author is writing a particular book. Steps in ER Modeling Step 1: Identify the Entities Step 2: Find the relationships Step 3: Identify the key attributes Step 4: Identify other relevant attributes Step 5: Draw complete E-R diagram with all attributes including Primary Key Case Study 1 : ER Model For a college Database Assumptions : A college contains many departments Each department can offer any number of courses Many instructors can work in a department An instructor can work only in one department For each department there is a Head An instructor can be head of only one department Each instructor can take any number of courses A course can be taken by only one instructor A student can enroll for any number of courses Each course can have any number of students

Step 1: Identify the Entities DEPARTMENT STUDENT COURSE INSTRUCTOR Step 2: Find the relationships One course is enrolled by multiple students and one student enrolls for multiple courses, hence the cardinality between course and student is Many to Many. The department offers many courses and each course belongs to only one department, hence the cardinality between department and course is One to Many. One department has multiple instructors and one instructor belongs to one and only one department, hence the cardinality between department and instructor is one to Many. Each department there is a Head of department and one instructor is Head of department, hence the cardinality is one to one. One course is taught by only one instructor, but the instructor teaches many courses, hence the cardinality between course and instructor is many to one. Step 3: Identify the key attributes Deptname is the key attribute for the Entity Department, as it identifies the Department uniquely. Course# (CourseId) is the key attribute for Course Entity. Student# (Student Number) is the key attribute for Student Entity. Instructor Name is the key attribute for Instructor Entity. Step 4: Identify other relevant attributes For the department entity, the relevant attribute is location For course entity, course name, duration, prerequisite For instructor entity, room#, telephone For student entity, student name, date of birth Step 5: Draw complete E-R diagram with all attributes including Primary Key

Figure 27 Case Study2 Banking Business Scenario Assumptions : There are multiple banks and each bank has many branches. Each branch has multiple customers Customers have various types of accounts Some Customers also had taken different types of loans from these bank branches One customer can have multiple accounts and Loans

Step 1: Identify the Entities BANK BRANCH LOAN ACCOUNT CUSTOMER Step 2: Find the relationships One Bank has many branches and each branch belongs to only one bank, hence the cardinality between Bank and Branch is One to Many. One Branch offers many loans and each loan is associated with one branch, hence the cardinality between Branch and Loan is One to Many. One Branch maintains multiple accounts and each account is associated to one and only one Branch, hence the cardinality between Branch and Account is One to Many One Loan can be availed by multiple customers, and each Customer can avail multiple loans, hence the cardinality between Loan and Customer is Many to Many. One Customer can hold multiple accounts, and each Account can be held by multiple Customers, hence the cardinality between Customer and Account is Many to Many Step 3: Identify the key attributes BankCode (Bank Code) is the key attribute for the Entity Bank, as it identifies the bank uniquely. Branch# (Branch Number) is the key attribute for Branch Entity. Customer# (Customer Number) is the key attribute for Customer Entity. Loan# (Loan Number) is the key attribute for Loan Entity. Account No (Account Number) is the key attribute for Account Entity. Step 4: Identify other relevant attributes For the Bank Entity, the relevant attributes other than BankCode would be Name and Address. For the Branch Entity, the relevant attributes other than Branch# would be Name and Address. For the Loan Entity, the relevant attribute other than Loan# would be Loan Type. For the Account Entity, the relevant attribute other than Account No would be Account Type. For the Customer Entity, the relevant attributes other than Customer# would be Name, Telephone# and Address.

Step 5: Draw complete E-R diagram with all attributes including Figure 28 Reduction of an E-R Schema to Tables Convert ER model into relational schema (a specification of the table definitions and their foreign key links) There are well defined rules for this conversion Converting Strong entity types: i) Each entity type becomes a table ii) Each single-valued attribute becomes a column iii) Derived attributes are ignored iv) Composite attributes are represented by components v) Multi-valued attributes are represented by a separate table vi) The key attribute of the entity type becomes the primary key of the table

Street Floor Building Date of Joining Address Name Years of Service E# Employee Skillset Figure 29 Strong Entity example Here address is a composite attribute Years of service is a derived attribute (can be calculated from date of joining and current date) Skill set is a multi-valued attribute The final Relational Schema: Employee (E#, Name, Street, Floor, Building, Date_Of_Joining) Emp_Skillset( E#, Skillset) Figure 30 Conversion of strong entity to tables As per the rules: Derived attributes are ignored Composite attributes are represented by components Multi-valued attributes are represented by a separate table

Converting weak entity types Weak entity types are converted into a table of their own, with the primary key of the strong entity acting as a foreign key in the table. This foreign key along with the key of the weak entity form the composite primary key of this table Figure 31 Weak Entity example The Relational Schema: Employee (E#,Name,.) Dependent (Employee, Dependent_ID, Name, Address) Here dependent is a weak entity. Dependent doesn t mean anything to the problem without the information on for which employee the person is a dependent. Figure 32 Conversion of weak entity to tables Converting relationships The way relationships are represented depends on the cardinality and the degree of the relationship. The possible cardinalities are: 1:1 1:M M:N The degrees are: Unary Binary Ternar Binary (1:1) Case 1: Combination of participation types: In binary (1:1) relationship if combination of participation exists, the primary key of the partial participation will become the

foreign key of the total participation. In figure 33 there is a partial participation of Employee entity in the relationship HeadOf, because only one Employee can become head of the department. But there is a total participation of Department entity because every Department must have a head of department. Therefore the relational schema would be Employee(E#, Name.) Department (Dept#, Name,., Head) Figure 33 Binary (1:1) Combination of Participation type Figure 34 Conversion of total and partial participation to tables Case 2: Uniform participation type: If both the entities take uniform participation in the Binary (1:1) relationship the primary key of either of the participants can become a foreign key in the other.

Figrure 35 Binary (1:1) Uniform participation Figure 36 Conversion of Uniform participation to tables Binary (1:N) : The primary key of the 1 side of the relationship becomes a foreign key in the relation on the N side. Figure 37 Binary (1:N) relationship

Figure 38: Conversion of Binary (1:N) relationship to tables Binary (M:N) : A new table is created to represent the relationship. The new table contains two foreign keys- one from each of the participating entities. The primary key of the new table is the combination of the two foreign keys. Figure 39 : Binary (M:N) relationship Figure 40 : Conversion of Binary (M:N) relationship to tables

Unary (1:1) : In unary 1:1 relationship the primary key field itself will become foreign key in the same table. Figure 41 Unary (1:1) Relationship Figure 42 Conversion of Unary (1:1) Relationship to table Unary (1:N): In unary 1:N relationship the primary key field itself will become foreign key in the same table. Figure 2.42 Unary (1:N) Relationship

Figure 44 Conversion of Unary (1:N) Relationship to table Unary (M:N): In unary M:N relationship, there would be two resulting table, one to represent the entity and another to represent many to many relationship. The primary key of the entity will be copied two times in the new table, and will become a composite primary key. Figure 45 Unary (M:N) Relationship Figure 46: Conversion of Unary (M:N) Relationship to tables Ternary Relationship : Ternary relationship will be represented by a new table. This table will contain three foreign keys- one from each of the participating entities. The primary key of the new table is the combination of all three foreign keys. If relationship has any attributes it will become the attributes of the new table.

Medicine Dosage No. of Days Doctor Prescription Patient Figure 47: Ternary Relationship Figure 48 Conversion of Ternary Relationship to table Converting specialization Generalization is concept of representing entity sets in the form of hierarchy. Higher level entity set is represented by table containing attribute common to lower level entity set. Lower level entity set is represented by table containing column as primary key of higher level entity set and a specialized attribute corresponding to that lower level entity set.

E# Ename DOB EMPLOYEE Address ISA NoOfHrs BasicSal HOURLY_EMPLOYEE SALARIED_EMPLOYEE Figure 2.48 Specialization EMPLOYEE HOURL_EMPLOYEE E# PK E# PK Ename NoOfHrs DOB Address SALARAIED_EMPLOYEE E# PK BasicSal Figure 50 Conversion of specialization to table Converting Aggregation If an aggregated entity set combines two entity sets with one relationship and this aggregated entity set is related with one more entity than Each entity set is represented by one table The relationship between aggregated entity set is represented by one table, and the final table structure depends upon the relationship between the tables. The relationship between aggregated entity set and related entity is represented by one table, containing primary key from each table. Deriving Logical Schema for Banking Application (Figure 26) 1) Each Entity represented in the E-R model can be defined as a table in the relational scheme. All the attributes of the Entity will become columns of the table. 1. We can translate this Entity to a CUSTOMER table with the following columns. CUSTOMER Customer#,Name,Telephone#,Address)

2. Similarly a Bank table can be created with Bank Bankcode, Name and Address columns BANK (BankCode, Name, Address) 3. Weak Entity types are converted into a table of their own, with the primary key of the strong Entity acting as a foreign key in the table. This Foreign key along with the key of the Weak Entity form the composite primary key of this table.as per this guideline, a Branch table can be created with the following structure. BRANCH (BankCode, Branch#, Name, Address) 4. Each relationship can be defined as separate table in relational schema. Key attributes of participating entities will become key attribute of the Relationship. We can define Loan_Detail table with Loan# and Customer# together as primary key with other relevant attributes like DateOfSanction, InterestRate, LoanAmount, Duration etc. LOAN_DETAILS (Loan#, Customer#, DateofSanction, InterestRate, LoanAmount, Duration) 5. In a Many to Many relationship, it is necessary to create separate tables for participating entities and relationships. In the banking application we have Customer and Loan Entities have a Many to Many relationship. Hence one should create separate tables for CUSTOMER LOANS LOAN_DETAILS.