Database Systems ER Model. A.R. Hurson 323 CS Building

Size: px

Start display at page:

Download "Database Systems ER Model. A.R. Hurson 323 CS Building"

Byron Gilbert
6 years ago
Views:

1 ER Model A.R. Hurson 323 CS Building

2 Database Design Data model is a group of concepts that helps to specify the structure of a database and a set of associated operations allowing data retrieval and data manipulation.

3 Database Design Simplified description of the database design process Mini world Requirements collection and analysis Database designers interview prospective users to understand and document their data requirements. Database requirements

4 Database Design Simplified description of the database design process Captures concise description of the data requirements, including data type, constraints, and operations Conceptual design Conceptual Schema Data Model Mapping A high level conceptual data model to capture database requirements DBMS Independent DBMS Specific

5 Database Design Simplified description of the database design process Data Model Mapping Conceptual Schema in the specific data model Physical design DBMS Independent DBMS Specific Actual implementation Internal design

6 Database Design An example The database keeps track of Employees, Departments, and Projects. After the requirements collection and analysis, database designers came up with the following description: The company is organized into departments. Each department has a name, a number, and a manager. We need to keep track of starting data of the manager, managing a department. A department may be in several locations.

7 Database Design An example A department controls several projects, each project is identified by a name, a number, and a single location. Each employee is represented by a name, SSN, an address, sex, and birth date. An employee is assigned to a department, he/she may be working on several projects which are not necessarily controlled by the same department. Direct supervisor of each employee and the number of hours he/she working on a project is also recorded.

8 Database Design An example An employee s dependent (s) is (are) needed to be recorded name, sex, birth date, and relationship.

9 Entity Relationship (ER) model The Entity Relationship (ER) model is a high level conceptual data model. The ER model allows us to represent the data description in a graphical format. This graphical format, will go through several refinements. Then we need to consider performance issues and design of logical schema.

10 In ER model data is defined as entities, relationships, and attributes.

11 Entity Relationship (ER) model An entity is the basic object in an ER model. An entity is a thing in the real world an entity could physically exist (like a person) or could conceptually exist (like a job). An entity has some properties, attributes, that describe it. Each attribute will assume its value from a domain.

12 e 1 Name = John Smith Address = 2311 Kirby, State College, PA Age = 35 Home Phone = An entity and its attributes

13 Name = Sunco oil c 1 Headquarter = State College President = John Smith An entity and its attributes

14 Entity Relationship (ER) model An attribute can be a composite attribute (like an address) or a single (atomic) attribute (like age). A composite attribute can form a hierarchical structure based on a set of composite or atomic attributes.

15 Address Street Address City State Zip code Number Street Apartment Number

16 Entity Relationship (ER) model An attribute can be of single-valued, multivalued, derived, or complex type. Component of a composite attributes are grouped within ( ) and multi-valued attribute is represented by {}.

17 Entity Relationship (ER) model {Address_phone ( {Phone (Area_code, Phone_number) }, Address (Street_address (Number, Street, Appartment_number), City, State, Zip_code) This example shows an entity (person) who has multiple houses and each house has multiple phones.

18 Entity Relationship (ER) model A set of entities that have the same attributes are called an entity type. Each entity type is represented by a name and a list of attributes these two are called entity type schema. Collection of entities of a particular entity type is called an entity set or entity collection.

19 SCHEMA (intension) Employee Name, Age, Salary Company Name, Headquarter, President INSTANCES (extension) e 1 John Smith, 55, 80K e 2 Fred Brown, 40, 30K e 3 Judy Clark, 25, 35K c 1 Sunco oil, State College, John Smith c 2 Microsoft, Seattle, Bill Gates

20 In ER model: An entity type is represented as a rectangular box, An attribute is represented as an oval attached to its entity type, Composite attribute is attached to its components, Multi-value attribute is represented as a double ovals.

21 Entity Relationship (ER) model an example Initial Conceptual Design: Based on the requirements listed before and our definitions, we will define four entity types: An entity type DEPARTMENT with attributes; Name, Number, Location, Manager, ManagerStartDate Here Location is multi-valued and attributes Name and Number are the keys.

22 Entity Relationship (ER) model an example An entity type PROJECT with attributes; Name, Number, Location, ControllingDepartment Here Name and Number are the keys. An entity type EMPLOYEE with attributes; Name (FName, MInit, LName), SSN, Sex, Address, Salary, BithDate, Department, Supervisor, {WorksOn (Project, Hours)} Here both Name and Address are composite attributes and WorksOn is Multi-valued.

23 Entity Relationship (ER) model an example An entity type DEPENDENT with attributes; Employee, DependentName, Sex, BirthDate, Relationship Note that in addition to the attribute values of entities that belong to those entity types, we are also interested in relationships among the entities.

24 Entity Relationship (ER) model In addition to the attribute values of the entities that belongs to the entity types, in ER model we are also interested in relationships among the entities. A relationship is an association between two or more entities. A set of similar relationships can be collected together to form a relationship set.

25 Entity Relationship (ER) model A relationship can be thought of as a set of n- tuples: {(e 1, e 2,,e n ) e 1 E 1, e 2 E 2,, e n E n } where e i is an entity and E i is an entity set. Note, several relationship sets may involve the same entity sets.

26 Entity Relationship (ER) model A relationship of type R among n entity types E 1, E 2,, E n is a set of associations among entities from these types. Formally, R is a set of relationship instances r i, where each r i associates n individual entities (e 1, e 2,,e n ), and each entity e j in r i is a member of entity type E j, 1 j n.

27 Entity Relationship (ER) model Each of the entity type E j is said to participate in the relationship type R, and similarly each individual entities e 1, e 2,,e n is said to participate in the relationship instance r i = (e 1, e 2,,e n ). In ER diagrams, relationship types are displayed as diamond-shape boxes, connected by straight lines to the rectangular boxes representing the participating entity types.

28 e 1 e 2 e 3 e 4 e 5 EMPLOYEE r 1 r 2 r 3 r 4 r 5 WORKS-FOR A binary relationship type d 1 d 2 d 3 DEPARTMENT

29 Entity Relationship (ER) model Degree of a Relationship Type The degree of a relationship type is the number of participating entity types. A relationship type of degree two is called binary and of degree three is called ternary. In general, a ternary relationship type represents more information than three binary relationship types.

30 SUPPLIER PART S 1 S 2 P 1 P 2 P 3 r 1 r 2 r 3 r 4 r 5 r 6 PROJECT J 1 J 2 J 3 A ternary relationship type

31 Entity Relationship (ER) model Role names and recursive relationships the role name signifies the role that a participating entity from the entity type plays in each relationship instance. For example, in the WORKS-FOR relationship type, EMPLOYEE plays the role of the worker and DEPARTMENT plays the role of employer.

32 Entity Relationship (ER) model In some instances the same entity type participates more than once in a relationship type in different roles. Such a relationship type is called recursive relationship type.

33 EMPLOYEE e 1 e 2 e 3 e 4 e 5 e 6 e 7 1 shows the supervisor role 2 shows the supervisee role e 1 is the supervisor of e 2,e 3 e 4 is the supervisor of e 6,e 7 e 5 is the supervisor of e 4,e 1 SUPERVISOR r 1 r 2 r 3 r 4 r 5 r 6

34 Constraints on Relationship types Certain conditions (constraints) limit the possible contributions of entries participating in relationship instances. These constraints are determined by the underlying mini-world. As an example, assume that an employee works just for a department. This constraint should be reflected in the schema. In the following, several types of relationship constraints that occurs relatively very frequently are discussed.

35 Constraints on Relationship types Cardinality ratio in a binary relationship specifies the number of relationship instances that an entity instance can participate in. The possible cardinality ratios are: 1:1, 1:N, and M:N. In graphical representation of ER model, cardinality ratios are displayed as 1, M, N on the diamonds.

36 Constraints on Relationship types Participation Constraints and Existence Dependencies specifies whether the existence of an entity depends on its being related to another entity via a relationship type. There are two types of participation constraints: Total Partial

37 Constraints on Relationship types Total Participation Constraints If a company policy states that every employee must work for a department, then an employee entity can exist only if it participates in a WORKS-FOR relationship instance. Total participation (Existence dependency) means that every entity in the total set of employee entities must be related to a department entity via WORKS-FOR.

38 Constraints on Relationship types On the other hand, we do not expect that every employee be a manager. So the participation of EMPLOYEE in the MANAGES relationship type is partial meaning that some or part of employee entities are related to a department entity via MANAGES, but not necessarily all. In ER diagram, total and partial participation are represented by double line and single line, respectively.

39 Constraints on Relationship types Key Constraint: The restriction that each department has at most one manager is an example of a key constraint. Key constraint implies that each department entity appears in at most one MANAGES relationship in any allowable instance of MANAGES.

40 Constraints on Relationship types Key constraint is represented by an arrow from the entity type to the relationship type in an ER diagram intuitively, the arrow indicates that given a Department entity, we can uniquely determine the MANAGES relationship in which it appears.

41 Attributes of relationship types Relationship types can also have attributes, similar to those of entity types. Note, attributes of 1:1 or 1:N relationship types can be migrated to one of the participating entity types. For 1:N relationship type, a relationship attribute can be migrated only to the entity type at the N-side of the relationship.

42 Constraints on Relationship types Weak entity type are those entity types that do not have key attributes of their own. In contrast, regular entity types are called strong entity types. Entities belonging to a weak entity type are identified by being related to specific entities from another entity type (identifying or owner entity type) in combination with some of their attribute values.

43 Constraints on Relationship types A weak entity type normally has a partial key a set of attributed that can uniquely identify weak entities within the same owner entity. In ER diagram, both a weak entity type and its identifying relationship type are distinguished by double line boxes and diagrams. The partial key attribute is underlined with a dashed or dotted line.

44 ER Design for the COMPANY Database. Recall from our earlier discussion, the COMPANY database was defined as:

45 An entity type DEPARTMENT with attributes; Name, Number, Location, Manager, ManagerStartDate An entity type PROJECT with attributes; Name, Number, Location, ControllingDepartment An entity type EMPLOYEE with attributes; Name (FName, MInit, LName), SSN, Sex, Address, Salary, BithDate, Department, Supervisor, {WorksOn (Projecr, Hours)} An entity type DEPENDENT with attributes; Employee, DependentName, Sex, BirthDate, Relationship

46 The design of this database, now can be refined by: Changing the attributes that represent relationships into relationship types. Defining the cardinality ratio and participation constraints. Removing the redundant attributes.

47 Consequently we will have the following relationship types: MANAGES, a 1:1 relationship type between EMPLOYEE and DEPARTMENT. Where, EMPLOYEE participation is partial DEPARTMENT participation is not clear, after revisiting the users, a conclusion was made that a department must have a manager which implies a total participation. Finally, the attribute StartDate is assigned to this relationship type.

48 WORKS-FOR, a 1:N relationship type between DEPARTMENT and EMPLOYEE. Both participations are total. CONTROLS, a 1:N relationship type between DEPARTMENT and PROJECT. Participation of PROJECT is total. SUPERVISION, a 1:N relationship type between EMPLOYEE and EMPLOYEE. Both participations are determined to be partial not every employee is a supervisor and not every employee has a supervisor.

49 WORKS-ON, an M:N relationship type with attribute Hours a PROJECT can have several employees working on it. DEPENDENT-OF, a 1:N relationship type between EMPLOYEE and DEPENDENT, it is also the identifying relationship for the weak entity type DEPENDENT. Participation of EMPLOYEE is partial, whereas that of DEPENDENT is total.

50 Now, redundant attributes must be removed. This includes: Manager and ManagerStartDate from DEPARTMENT, ControllingDepartment from PROJECT, Department, Supervisor, and WORKS-ON from EMPLOYEE, and Employee from DEPENDENT.

51 Note that it is important to have the least amount of redundancy when we design the conceptual schema. If some redundancy is desired, at the storage level or at the user view level, it will be introduced later.

52 DEPARTMENT; Name, Number, Location PROJECT; Name, Number, Location EMPLOYEE; Name (FName, MInit, LName), SSN, Sex, Address, Salary, BithDate DEPENDENT; DependentName, Sex, BirthDate, Relationship

53 ER model notations Entity type Relationship type Attribute Weak Entity type Identifying Relationship type Key Attribute

54 ER model notations Multi-valued Attribute Composite Attribute Derived Attribute

55 ER model notations E 1 R E 2 Total representation of E 2 in R 1 N E 1 R E 2 Cardinality ratio 1: N for E 1 : E 2 in R R (min, max) E Structural constraint (min,max) on participation of E in R

56 Relationship types of degree higher than two In general, a relationship type R of degree n will have n edges in an ER diagram, one connecting R to each participating entity type.

57 SName Quantity ProjName SUPPLIER SUPPLY PROJECT PartNo PART

58 The following diagram shows three binary relationship types. However, though closely related, it is not semantically equivalent to the previous ternary relationship type.

59 SName Quantity ProjName SUPPLIER M SUPPLY N PROJECT M M CAN- SUPPLY N PartNo N USE S PART

60 INname TAUGHT- DURING Semester Sem-Year Year INSTRUCTOR OFFERS SEMESTER CAN- TEACH CNumber OFFERED- DURING COURSE

61 Refer to the previous example, a relationship instance (i, s, c) should not exist in OFFERS unless an instance (i, s) exists in TAUGHT- DURING, an instance (s, c) exists in OFFERED-DURING, and an instance (i, c) exists in CAN-TEACH. However, the reverse is not always true.

Data Modeling Using the Entity-Relationship Model

3 Data Modeling Using the Entity-Relationship Model Conceptual modeling is a very important phase in designing a successful database application. Generally, the term database application refers to a particular