Amity School of Engineering & Technology

The Entity-Relationship Model

Conceptual Data Modeling

Lecture 3

The Entity-Relationship model

Amity School of Engineering & Technology

The E-R model is a detailed, logical representation of the data for an organisation or business area It should be understandable to both the user and to the IT technologist The model must be as open as possible and not tied to any technology or to any particular business methodology It must be flexible enough so that it can be used and understood in practically any environment where information is modelled

The ER model

Amity School of Engineering & Technology

It is expressed in terms of entities in the business environment, the relationships (or associations) among those entities and the attributes (properties) of both the entities and their relationships The E-R model is usually expressed as an E-R diagram

E-R Model Constructs

Amity School of Engineering & Technology

Entity - person, place, object, event, concept Entity Type - is a collection of entities that share common properties or characteristics. Each entity type is given a name, since this name represents a set of items, it is always singular. It is placed inside the box representing the entity type (Fig. 3-1) Entity instance is a single occurrence of an entity type. An entity type is described just once (using metadata) in a database, while many instances of that entity type may be represented by data stored in the database. e.g. there is one EMPLOYEE entity type in most organisations, but there may be hundreds of instances of this entity stored in the database

Sample E-R Diagram

Amity School of Engineering & Technology

Amity School of Engineering & Technology

Entity type versus system input, output or user

A common mistake is to confuse data entities with other elements of the IS model A simple rule is that a true data entity will have many possible instances, each with a distinguishing characteristic Treasurer is the person entering data and data about the treasurer need not be kept

Entity type versus system input, output or user

Amity School of Engineering & Technology

Is the expense report entity necessary? It is only the result of extracting data from the database. Even though there will be multiple instances of expense reports given to the treasurer over time, data needed to compute the report contents each time are already represented by the ACCOUNT and EXPENSE entity types Gives-to and Receives are business activities, not relationships between entities.

Example of Amity School of inappropriate entities (a) System user (Treasurer) and output (Expense Report) shown as entities

Engineering & Technology

Amity School of Engineering & Technology

(b) E-R model with only the necessary entities

Amity School of Engineering & Technology

Strong versus Weak entity type

Most of the basic entity types are classified as strong entity types [Rectangle] one that exists independently from other entity types (such as EMPLOYEE) Always have a unique characteristic (identifier) an attribute or combination of attributes that uniquely distinguish each occurrence of that identity A weak entity type [[Double Rectangle]] existence depends on some other entity type. It has no meaning in the ER diagram without the entity on which it depends (such as DEPENDENT) The entity type on which the weak entity type depends is called the Identifying owner (or owner for short).

Amity School of Engineering & Technology

Strong versus Weak entity type

Identifying relationship is the relationship between a weak entity type and and its owner (such as Has in the following Fig.) Weak entity identifier is its partial identifier (double underline) combined with that of its owner. During a later design stage dependent name will be combined with Employee_ID (the identifier of the owner) to form a full identifier for DEPENDENT.

Example of a weak entity

Amity School of Engineering & Technology

Attributes

Amity School of Engineering & Technology

An attribute is a property or characteristic of an entity type, for example the entity EMPLOYEE may have attributes Employee_Name and Employee_Address. In ER diagrams place attributes name in an ellipse with a line connecting it to its associated entity Attributes may also be associated with relationships An attribute is associated with exactly one entity or relationship

Simple versus composite attributes (following Fig.)

Amity School of Engineering & Technology

Some attributes can be broken down into meaningful component parts, such as Address, which can be broken down into Street_Address, City..etc. The component attributes may appear above or below the composite attribute on an ER diagram Provide flexibility to users, as can refer to it as a single unit or to the individual components A simple (atomic) attribute is one that cannot be broken down into smaller components

A composite attribute

Amity School of Engineering & Technology

Single-Valued versus Multivalued Attribute

Amity School of Engineering & Technology

It frequently happens that there is an attribute that may have more than one value for a given instance, e.g. EMPLOYEE may have more than one Skill. A multivalued attribute is one that may take on more than one value it is represented by an ellipse with double lines

Entity with a multivalued attribute (Skill) Amity School of Engineering & Technology and derived attribute (Years_Employed)

Stored versus Derived Attributes

Amity School of Engineering & Technology

Some attribute values can be calculated or derived from others e.g., if Years_Employed needs to be calculated for EMPLOYEE, it can be calculated using Date_Employed and Today's_Date A derived attribute is one whose value can be calculated from related attribute values (plus possibly other data not in the database) A derived attribute is signified by an ellipse with a dashed line (see previous Fig.)

Identifier attribute

Amity School of Engineering & Technology

Identifier attribute or Key is an attribute (or combination of attributes) that uniquely identifies individual instances of an entity type, such as Student_ID To be a candidate identifier, each entity instance must have a single value for the attribute, and the attribute must be associated with each entity The identifier attribute is underlined, such as Student_ID

Simple and composite key attributes (a) Simple key attribute

Amity School of Engineering & Technology

Composite Identifier

Amity School of Engineering & Technology

A Composite Identifier is when there is no single (or atomic) that can serve as an identifier Flight_ID is a composite identifier that has component attributes Flight_Number and Date this combination is required to uniquely identify individual occurrences of Flight Flight_ID is underlined, whilst its components are not

(b) Composite key attribute

Amity School of Engineering & Technology

Criteria for selecting identifiers

Some entities have more than one candidate identifier, so the following criteria should be used: Choose identifier that will not change in value over the life of each instance of the entity type Choose identifier that is guaranteed to have valid values and Will not be null (or unknown). If composite, make sure all parts will have valid values

Amity School of Engineering & Technology

Criteria for selecting identifiers

Amity School of Engineering & Technology

Avoid the use of intelligent identifiers whose structure indicates classifications, locations or people that might change. e.g. the first two digits of an identifier may indicate a warehouse location, but such codes are often changed as conditions change, which renders them invalid. Consider substituting new, simple identifiers for long, composite ones, e.g. an attribute called Game_Number could be used for the entity type GAME instead of Home_Team and Away_Team

Amity School of Engineering & Technology (b) Professors and courses (fixed upon constraint)

Overview

Amity School of Engineering & Technology

Data abstraction Specification/Design of Abstract Data Types (ADTs) Implementation of ADTs

The Problem
Programs are complex.

Amity School of Engineering & Technology

Windows XP: ~45 million lines of code Mathematica: over 1.5 million

Abstraction helps
Many-to-one forget the details Must separate what from how

Information Hiding
By specification
Locality Modifiability

Amity School of Engineering & Technology

Modularity - Procedural abstraction

By parameterization

Data Abstraction
What you can do with the data is separated from how it is represented

Software development cycle

Amity School of Engineering & Technology

Specifications What do you want to do? Design How will you do what you want? Implement Code it. Test Check if it works. Maintain School projects dont usually make it this far.

Bugs are cheaper earlier in the cycle!

Database Implementation

Amity School of Engineering & Technology

Database on library web-server stores information on users: userID, name, email, etc. You are responsible for implementing the interface between the web-server and database
What happens when we ask for the email address for a specific user?

Client asks for email address

Amity School of Engineering & Technology

What is email address of nate?

Server

Database Client

Client/Server/Database Interaction

Amity School of Engineering & Technology

[email protected]

Server

Database Client

Example: Database System

Need a new data type Abstract Data Types (ADTs)

Amity School of Engineering & Technology

Help separate what from how Client will use the specifications for interaction with data Client of the web database should not know the guts of the implementation