1 © Prentice Hall, 2002 Chapter 3: Modeling Data in the Organization Modern Database Management 7th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden

Chapter 3 © Prentice Hall, SDLC Revisited – Data Modeling is an Analysis Activity (figures 2.4, 2.5) Project Identification and Selection Project Initiation and Planning Analysis Physical Design Implementation Maintenance Logical Design Purpose –thorough analysis Deliverable – functional system specifications Database activity – conceptual data modeling

Chapter 3 © Prentice Hall, THE E-R MODEL A logical representation of the data for an organization or for a business area Expressed in terms of entities, relationships among entities, and the attributes of entities and relationships

Chapter 3 © Prentice Hall, Sample E-R Diagram Entity Relationship Cardinality

Chapter 3 © Prentice Hall, E-R Model Constructs Entity: A person, place, object, event, concept in the user environment about which the organization wishes to maintain data Given a noun name Person: EMPLOYEE, STUDENT, FACULTY Place: STORE, CLASS ROOM, HOSTEL Object: COMPUTER, PROJECTOR, PEN Event: REGISTRATION, RENEWAL, SALE, GRADUATION Concept: MESS ACCOUNT, EXTRAS, PROJECT – Entity Type – collection of entities that share common properties or characteristics Name is singular Described only once in database Ex: STUDENT(IDNO,NAME) – Entity instance – A single occurrence of an entity type Each entity type will have many instances Ex: (200A1PS111,RAVI), (2003B1A1112,KIRAN)

Chapter 3 © Prentice Hall, E-R Model Constructs Attribute - property or characteristic of an entity type that is of interest to the organization – Ex: STUDENT (Idno, Name, Hostel, Roo_No, Cgpa) Relationship: an association representing an interaction among the instances of one or more entity types that is of interest to the organization – Given a verb phrase name Relationship type: A meaningful association between entity types – Ex: STUDENT registers COURSE – FACULTY teaches COURSE – STUDENT awarded SCHOLARSHIP Relationship Instance – An association between entity instances – Ex: 2005A1PS111 awarded MCN – 2003A4PS123 awarded Pratibha – 2004B1A2111 not awarded MCN

Chapter 3 © Prentice Hall, Figure Basic E-R Notation Entity symbol s Relationshi p symbols Attribute symbols A special entity that is also a relationship

Chapter 3 © Prentice Hall, What Should an Entity Be? Entity: A person, place, object, event, concept in the user environment about which the organization wishes to maintain data SHOULD BE: – An object that will have many instances each with distinguishing characteristic – An object that will be composed of multiple attributes – An object that we are trying to model

Chapter 3 © Prentice Hall, What Should an Entity Be? Entity: A person, place, object, event, concept in the user environment about which the organization wishes to maintain data SHOULD NOT BE: – A user of the database system ACCOUNTANT receives DEPOSITS PROFESSOR uploaded GRADES – An output of the database system (e.g. a report) STUDENT receives CGCARD PAYSLIP sent to FACULTY – The names receives, sent to, uploaded refer to activities that transfer or translate data but does not indicate any association between data.

Chapter 3 © Prentice Hall, Inappropriate entities System user System output Appropriate entities Figure 3-4

Chapter 3 © Prentice Hall, Strong Vs Weak Entity Types Strong Entity Type: An entity that exists independently of other entity types. – It has identifier, attribute or combination of attributes that uniquely distinguish each occurrence of that entity – Ex: COURSE, STUDENT, FACULTY Weak Entity Type: An entity type whose existence depends on some other entity type – It doesn’t have its own identifier – Ex: COURSE and LECTURE SECTION – EMPLOYEE and FAMILY MEMBER Identifying owner: The entity type on which the weak entity type depends – Ex: COURSE and LECTURE SECTION – EMPLOYEE and FAMILY MEMBER

Chapter 3 © Prentice Hall, Attributes Attribute - property or characteristic of an entity type that is of interest to the organization – Has a noun name – Ex: STUDENT (Idno, Name, Hostel, Room_No, CGPA) Classifications of attributes: – Required versus Optional Attribute Required: An attribute of an entity that must have a value for each entity instance Optional : An attribute of an entity that may not have a value for each entity instance Ex: Idno Vs Room No

Chapter 3 © Prentice Hall, Attributes Attribute - property or characteristic of an entity type that is of interest to the organization – Has a noun name – Ex: STUDENT (Idno, Name, Hostel, Room_No, CGPA) Classifications of attributes: – Simple versus Composite Attribute Simple: An attribute that cant be broken down into smaller components Composite: An attribute that can be broken down into component parts Ex: CGPA Vs Address

Chapter 3 © Prentice Hall, Figure A composite attribute An attribute broken into component parts

Chapter 3 © Prentice Hall, Attributes Attribute - property or characteristic of an entity type that is of interest to the organization – Has a noun name – Ex: STUDENT (Idno, Name, Hostel, Room_No, CGPA) Classifications of attributes: – Single-Valued versus Multivalued Attribute – Multivalued: An attribute that can take more than one value for a given entity instance Ex: STUDENT having multiple skills

Chapter 3 © Prentice Hall, Attributes[2] Attribute - property or characteristic of an entity type that is of interest to the organization – Has a noun name – Ex: STUDENT (Idno, Name, Hostel, Room_No, CGPA) Classifications of attributes: – Identifier Attributes An attribute ( or combination of attributes) that uniquely identifies individual instances of an entity type –Ex: COURSE: comp code Identifier attribute is underlined Composite identifier:: An identifier that consists of a composite attribute –Ex: STUDENT Idno

Chapter 3 © Prentice Hall, Criteria for selecting Identifiers (keys) Should not change its value over the life of each instance of the entity type – Ex: Idno Versus Record_No Should not take null values – NULL -> no value Avoid intelligent identifiers – e.g. containing locations or classifications that might change – Intelligent identifiers: Idno, course code AAOC C311 Consider substituting single attribute surrogate identifiers for long, composite keys – Ex: comp code for Course_Code, Record_No for Idno

Chapter 3 © Prentice Hall, Figure Entity with a multivalued attribute (Skill) and derived attribute (Years_Employed) Derived from date employed and current date What’s wrong with this? Multivalued: an employee can have more than one skill

Chapter 3 © Prentice Hall, Figure 3-9a – Simple key attribute The key is underlined

Chapter 3 © Prentice Hall, Figure 3-9b -- Composite key attribute The key is composed of two subparts

Chapter 3 © Prentice Hall, Figure 3-19 – an attribute that is both multivalued and composite This is an example of time-stamping

Chapter 3 © Prentice Hall, More on Relationships Recap: Relationship: an association representing an interaction among the instances of one or more entity types that is of interest to the organization – Given a verb phrase name – Modeled as diamond with connecting lines Relationship type: A meaningful association between entity types – Ex: STUDENT registers COURSE – FACULTY teaches COURSE – STUDENT awarded SCHOLARSHIP Relationship Instance – An association between entity instances – Ex: 2005A1PS111 awarded MCN – 2003A4PS123 awarded Pratibha – 2004B1A2111 not awarded MCN

Chapter 3 © Prentice Hall, More on Relationships Relationships can have attributes – These describe features pertaining to the association between the entities in the relationship – Associated with many-many or one-one relationship – Ex: STUDENT registers COURSE. Which entity is the grade associated with? Two entities can have more than one type of relationship between them (multiple relationships) Associative Entity : An entity type that associates the instances of one or more entity types and contains attributes that are peculiar to the relationship between those entity instances – combination of relationship and entity – More on this later

Chapter 3 © Prentice Hall, Figure 3-11a A binary relationship with an attribute Here, the date completed attribute pertains specifically to the employee’s completion of a course…it is an attribute of the relationship

Chapter 3 © Prentice Hall, Figure 3-12c -- A ternary relationship with attributes

Chapter 3 © Prentice Hall, Figure 3-10a Relationship type 3-10b Entity and Relationship instances

Chapter 3 © Prentice Hall, Degree of Relationships Degree of a Relationship is the number of entity types that participate in that relationship Most common relationship degrees are – Unary Relationship Relationship between the instances of a single entity type. They are also called “recursive relationships” Ex: Employee manages employees – Binary Relationship – Ternary Relationship

Chapter 3 © Prentice Hall, Degree of Relationships [2] Degree of a Relationship is the number of entity types that participate in that relationship Most common relationship degrees are – Binary Relationship Relationship between the instances of two entity types Most commonly encountered Ex: One-to-one :WARDEN takes care of one HOSTEL One-to-Many: HOSTEL contains many ROOM s Many-to-many: STUDENT graduating in many DEGREE s – Ternary Relationship A simultaneous relationship among the instances of three entity types Ternary relationships is not same as three binary relationships Ex: COURSE or SECTION, INSTRUCTOR, CLASSROOM -> TIMETABLE All ternary relationships are represented as associative entities

Chapter 3 © Prentice Hall, Degree of relationships – from figure 3-2 One entity related to another of the same entity type Entities of two different types related to each other Entities of three different types related to each other

Chapter 3 © Prentice Hall, Unary relationships -- figure 3-12a

Chapter 3 © Prentice Hall, Binary relationships – figure 3-12b

Chapter 3 © Prentice Hall, Ternary relationships –figure 3-12c

Chapter 3 © Prentice Hall, Attribute or Relationship? Should skills be an attribute of STUDENT or Should there be relationship between STUDENT and SKILL? So when should be an attribute be linked to an entity type via a relationship? – When the attribute has to be shared by multiple instances of that entity type we can represent that attribute as entity type

Chapter 3 © Prentice Hall, Cardinality of Relationships Cardinality specifies the number of instances of entity B that can (or must) be associated with each instance of entity A. One – to – One – Each entity instance in the relationship will have exactly one related entity instance One – to – Many – An entity instance on one side of the relationship can have many related entity instances, but an entity instance on the other side will have a maximum of one related entity instance Many – to – Many – Entity instances on both sides of the relationship can have many related entity instances on the other side

Chapter 3 © Prentice Hall, Cardinality Constraints Minimum Cardinality – If zero, then optional – If one or more, then mandatory Maximum Cardinality – The maximum number

Chapter 3 © Prentice Hall, Sample E-R Diagram Entity Relationship Cardinality

Chapter 3 © Prentice Hall, Basic relationship with only maximum cardinalities showing – figure 3-16a Mandatory minimum cardinalities – figure 3-17a

Chapter 3 © Prentice Hall, Figure 3-17c Optional cardinalities with unary degree, one-to-one relationship

Chapter 3 © Prentice Hall, Figure 3-21b -- Professors and courses (fixed upon constraint) Here,max cardinality constraint is 4

Chapter 3 © Prentice Hall, Representing a bill-of -materials structure Figure 3-13a A unary relationship with an attribute. This has a many-to-many relationship

Chapter 3 © Prentice Hall, Examples of multiple relationships – entities can be related to one another in more than one way Figure 3-21a Employees and departments

Chapter 3 © Prentice Hall, Figure 3-15: Multivalued attribute vs. relationship. Alternative approaches

Chapter 3 © Prentice Hall, Figure 3-5: Strong and weak entities Strong entity Weak entity Identifying relationship

Chapter 3 © Prentice Hall, Associative Entities It’s an entity – it has attributes AND it’s a relationship – it links entities together When should a relationship with attributes instead be an associative entity ? – All relationships for the associative entity should be many-to- many – The associative entity could have meaning independent of the other entities – The associative entity preferably has a unique identifier, and should also have other attributes – The associative may be participating in other relationships other than the entities of the associated relationship – Ternary relationships should be converted to associative entities (p102)

Chapter 3 © Prentice Hall, Figure 3-11b: An associative entity (CERTIFICATE) Associative entity involves a rectangle with a diamond inside. Note that the many-to-many cardinality symbols face toward the associative entity and not toward the other entities

Chapter 3 © Prentice Hall, Figure 3-13c -- an associative entity – bill of materials structure This could just be a relationship with attributes…it’s a judgment call

Chapter 3 © Prentice Hall, Figure Ternary relationship as an associative entity

Chapter 3 © Prentice Hall, Figure 3-22 E-R diagram for Pine Valley Furniture

Chapter 3 © Prentice Hall, CASE 1 A company has a number of employees. The attributes of EMPLOYEE include Employee_ID, Name, Address, and Birthdate. The company also has several projects. Attributes of PROJECT include Project_Id, Project_Name, and Start_Date. Each employee may be assigned to one or more projects, or may not be assigned to a project. A project must have at least one employee assigned, and may have any number of employees assigned. An employee’s billing rate may vary by project and the company wishes to record the applicable billing rate for each employee when assigned to a particular project.

Chapter 3 © Prentice Hall, CASE 1