Entity-Relationship (ER) Modeling

Database Design Process Application 1 Application 2 Application 3 Application 4 External Model External Model External Model External Model Application 1 Conceptual requirements Application 2 Conceptual requirements Conceptual Model Logical Model Internal Model Application 3 Conceptual requirements Application 4 Conceptual requirements

Stages in Database Design Requirements formulation and analysis Conceptual Design -- Conceptual Model Implementation Design -- Logical Model Physical Design --Physical Model

Database Design Process Requirements formulation and analysis Purpose: Identify and describe the data that are used by the organization Results: Metadata identified, Data Dictionary, Conceptual Model-- ER diagram

Database Design Process Requirements Formulation and analysis Systems Analysis Process Examine all of the information sources used in existing applications Identify the characteristics of each data element numeric text date/time etc. Examine the tasks carried out using the information Examine results or reports created using the information

Conceptual Modeling Objective: to produce HIGH-LEVEL DATA MODEL GOALS a complete understanding of the database structure, meaning (semantics), interrelationships, and constraints A stable description of the database contents Usually more expressive and general than data models of individual DBMSs Vehicle of communication among database users, designers, and analysts.

Database Design Process Conceptual Model Merge the collective needs of all applications Determine what Entities are being used Some object about which information is to maintained What are the Attributes of those entities? Properties or characteristics of the entity What attributes uniquely identify the entity What are the Relationships between entities How the entities interact with each other?

Database Design Process Logical Model How is each entity and relationship represented in the Data Model of the DBMS Hierarchic? Network? Relational? Object-Oriented?

Database Design Process Physical ( Internal) Model Choices of index file structure Choices of data storage formats Choices of disk layout

Database Design Process External Model User views of the integrated database Making the old (or updated) applications work with the new database design

Data Models: History Relational Model (1980’s) Provides a conceptually simple model for data as relations (typically considered “tables”) with all data visible.

Data Models: History Object Oriented Data Model (1990’s) Encapsulates data and operations as “Objects” Books (id, title) Publisher Subjects Authors (first, last)

Intro. to ER Models Entity/Relationship approach - one of the most well known modeling methods Developed by P.Chen in 1976 - many variations since then Data modeling is generally considered the most important component of the systems development process

Entity Relationship Diagrams A Simple ERD:  Consider the following situation A customer places an order. The order consists of parts. Entity Relationship Another Relationship Places Contain Customer Orders Parts An Organization about which we wish to maintain information An Association between Entities Another Entity Altogether, a Database

ER NOTATION Attribute Entity type Key attribute Weak entity type Multivalued attribute Relationship type Derived attribute Identifying Relationship type Composite attribute

A special entity that is also a relationship Relationship symbols Entity symbols Attribute symbols A special entity that is also a relationship Relationship degrees specify number of entity types involved Relationship cardinalities specify how many of each entity type is allowed 8

Entity An Entity is an object in the real world (or even imaginary worlds) about which we want or need to maintain information Persons (e.g.: customers in a business, employees, authors) Things (e.g.: purchase orders, meetings, parts, companies) Employee

Inappropriate entities Figure 3-4 System output System user Appropriate entities

Identifiers (Keys) Identifier (Key) - An attribute (or combination of attributes) that uniquely identifies individual instances of an entity type Simple Key versus Composite Key Candidate Key – an attribute that could be a key…satisfies the requirements for being a key 6

Characteristics of Identifiers Will not change in value Will not be null No intelligent identifiers (e.g. containing locations or people that might change) 7

Attributes Attributes are the significant properties or characteristics of an entity that help identify it and provide the information needed to interact with it or use it. (This is the Metadata for the entities.) Employee Last Middle First Name SSN Age Birthdate Projects

Figure 3-7 – A composite attribute An attribute broken into component parts 12

Weak Entities Owe existence entirely to another entity Order-line Contains Order Invoice # Part# Rep# Quantity Invoice#

Figure 3-9a – Simple key attribute The key is underlined 14

Figure 3-9b – Composite key attribute The key is composed of two subparts 15

Figure 3-8 – Entity with a multivalued attribute (Skill) and derived attribute (Years_Employed) What’s wrong with this? Derived from date employed and current date Multivalued: an employee can have more than one skill 13

Relationships Relationships are the associations between entities. They can involve one or more entities and belong to particular relationship types

Relationships Class Attends Student Part Supplier Project Supplies

Relationships Class Attends Student Part Supplier Project Supplies

Types of Relationships Concerned only with cardinality of relationship Truck Assigned Employee Project 1 n m Chen ER notation

Other Notations “Crow’s Foot” Truck Employee Project Employee Project Assigned Employee Project Assigned Employee Project Assigned Employee “Crow’s Foot”

Degree of Relationships Degree of a relationship is the number of entity types that participate in it Unary Relationship Binary Relationship Ternary Relationship 16

Degree of relationships – from Figure 3-2 Entities of two different types related to each other One entity related to another of the same entity type Entities of three different types related to each other 8

Cardinality of Relationships One-to-One Each entity in the relationship will have exactly one related entity One-to-Many An entity on one side of the relationship can have many related entities, but an entity on the other side will have a maximum of one related entity Many-to-Many Entities on both sides of the relationship can have many related entities on the other side

Cardinality Constraints Cardinality Constraints - the number of instances of one entity that can or must be associated with each instance of another entity Minimum Cardinality If zero, then optional If one or more, then mandatory Maximum Cardinality The maximum number 29

22

23