ims1907 database systems week 6 data modelling entity-relation diagrams

IMS1907 Database Systems

Week 6

Data ModellingEntity-Relation Diagrams

Monash University 2004 2

Regarded by many as the most important part of systems development– data characteristics captured are central to the design

of databases, programs and other system components

– facts and rules captured are essential to data integrity– data are the most complex aspect of IS and central to

structuring system requirements– data tend to be more stable than processes that use

data, so an IS developed with a data-centric focus should have longer lifespan

Data Modelling


The purpose of data modelling is to document business rules about data– identify and understand the rules that govern data– represent the rules so that they can be understood

by designers and end users without ambiguity– implement the rules in a DBMS technology

Data models cannot represent all business rules– some processing rules appear in other IS models– not all business rules govern data

Business Rules


A statement that defines or constrains some aspect of the business– intended to assert business structure– intended to control or influence the behaviour of

the business– rules prevent, cause or suggest things to happen

The Guide Business Rules Project (1997)

Expression of business policy and procedures Organisations can have thousands of rules

Business Rules


Expressed in terms familiar to the end users– allowable vocabulary, can be modelled by designers

Highly maintainable– discovered and documented once, stored, shared

and used in all IS development projectsCan be automated using software that interprets rules and applies necessary constraints– often using integrity mechanisms of DBMS

Need to be accurately, clearly and completely defined

Business Rules


Has become a mainstream data modelling technique since being proposed by Chen (1976)– relatively easy to use, and to understand– natural modelling concepts in real world – strong CASE tool support– evolving to meet complexity

Representation of structure and constraints of database that is independent of software and technologyCommunication tool between designers and end users

Entity-Relationship (ER) Modelling


Detailed, logical representation of the data for an organisation or business areaExpressed in terms of– entities or things of interest in the business

environment– relationships or associations between those entities– properties or attributes of the entities and relationships– rules and constraints that affect the integrity of

entities, attributes and relationshipsMinimum set of data objects necessary to construct the data used within the system in its various physical forms

Entity-Relationship (ER) Models


Entity– strong entity, weak entity – associative entity

Attribute– required attribute, optional attribute– single-valued attribute, multi-valued attribute

Relationship– degree, cardinality, cardinality constraints– attributes of relationship

ER Modelling Constructs and Concepts


Person, role, location, object, event or concept in the user environment about which an organisation wishes to store dataA ‘thing of interest’ to the organisation– has some real world existence

Often identified by the way things are referred to in an organisationNamed using a singular noun or noun phrase

Entities


Entity type is a set of entities that share common characteristicsEntity instance is a single occurrence of an entityA logical constructShould not be confused with users or system input or output– a ‘Treasurer’ table would only be useful if there were

more than one treasurer– an Expense Report’ is assembled from data already

stored in the DB – a process not an entity• unless…?

Entities


Most basic entities identified in organisations are strong entities– have a core meaning to the business– exist independently of other entity types– always have an identifier – a characteristic or

combination of characteristics that uniquely distinguish that entity

Weak entities are those whose existence depends on another entity type– has no business meaning without an identifying owner– has attribute or attributes that serve as partial

identifiers

Strong and Weak Entities


Strong entities

Strong and Weak Entities

CUSTOMER SALE PRODUCT

Weak entities

MOVIE VIDEOTAPE


A fact about the entityA property or characteristic of an entity type that is of interest to an organisationAn entity’s set of attributes describes the entityAttributes can be– required – must have values in every entity instance– optional – may not have a value for every instance

Attributes


Should be atomic or simpleCan be multi-valuedMay be able to be derived from other attributesAn identifier is formed from an attribute or combination of attributes that uniquely identify an entityAttributes should be sufficient to support– essential functions– current operations– measurement of performance against objectives

Attributes


Attributes

CUSTOMER

Customer_Name

Customer_ID

Customer_Address

Customer_Email

Age

Date_Of_Birth


Composite Attributes

CUSTOMER

Customer_Name

Customer_ID

Customer_Address

Last_NameFirst_Name

Street_Address Subur

b

Postcode

CUSTOMER

Flight_ID

Flight_No

No_Of_Passengers

Date


The glue holding the ER components togetherRepresent the business rules of an organisationAn association representing an interaction between one or more instances of an entity type that is of interest to an organisationThe relationship must be meaningful– allow us to answer questions that could not be

answered given just the entity types

Relationships


A relationship can have attributes– in many-to-many relationships

Associative entity– in many-to-many relationships, the relationship can

have meaning and be modelled as an entity in its own right

A relationship modelled as an associative entity can participate in relationships with other entitiesEntities can participate in multiple relationships between the same entities– reflecting different business rules

Relationships


Relationships

COURSEcompletesSTUDENT

Name

Course_ID TitleCert_ID

Date_Comp

Student_ID

COURSEcompletesSTUDENT

Name

Course_ID TitleDate_Comp

Student_ID


Degree of a relationship– number of entities participating in a relationship– unary

• an entity instance has a relationship with another instance of the same entity

– binary• a relationship between instances of two entities

– ternary• a relationship between instances of three entities

– higher or n-ary

Relationships


RelationshipsUnary relationship– one instance of an entity type has a relationship

with another instance of the same entity type

CHILDis

sibling of

EMPLOYEE supervises


Relationships

CUSTOMER

ACCOUNT

Binary relationship– one instance of an entity type has a relationship

with an instance of a different entity type

CUSTOMER

SALE

SALE

ITEM

owns makes contains


RelationshipsTernary relationship– an instance of an entity has a simultaneous relationship

with instances of two other entity types

PROJECT

supervises

LANGUAGE

TEAM MEMBER

TRUCK

allocates

DELIVERY

DRIVER


RelationshipsHigher or n-ary relationship– an instance of an entity has a simultaneous relationship

with instances of three or more other entity types

STAFF

TRUCK

allocates

DELIVERY

DRIVER


Cardinality of a relationship– number of instances of one entity that can participate

in a relationship with each instance of the other entity

Relationships

USER

PASSWORD

CATEGORY

PRODUCT

STUDENT

TUTORIAL

one-to-one one-to-many

many-to-many

Allocates into

classifiesis

assigned


Cardinality constraints on a relationship– specify whether or not an instance of one entity

must participate in a relationship with each instance of the other entity

– mandatory one – one and only one– optional one – zero or one– mandatory many – at least one to many– optional many – zero to many

Capture much of the nature of the business rules

Relationships


Cardinality constraints on a relationship

Relationships

CUSTOMER

ACCOUNT

CUSTOMER

SALE

ITEM

ORDER

Appears on

makesis

assigned


Entities can participate in multiple relationships between the same entities– reflecting different business rules

Relationships

TEACHER SUBJECT

Qualified to teach

Scheduled to

teach

4


To store a history of things we can use a time stamp– a time value associated with a data value

Time-Dependent data

CUSTOMER

Product_ID

Price_History

Price Effective_Date

SHIPMENT

Shipment_ID

Shipping_History

Location Arrival_Date


Entity Types and Sub-typesSome entities can be generalised or specialised to form other entities– some entities share common characteristics – they are

similar but we do not expect them to be identical

For example the entity types…– Motor Car– Truck– Train

…can be grouped together to form the entity supertype– Transport Vehicle


Entity Types and Sub-types

Supertype– a generic entity type that has a relationship with one or

more sub-types

Subtype– a sub-grouping of the entities in an entity type that is

meaningful to an organisation and that shares common attributes or relationships distinct from other sub-groupings


Example of an entity subtype– the entity type EMPLOYEE includes the subtypes

SALES and ADMIN

EMPLOYEE


ADMIN

SALES


Entity Types and Sub-typesWe can also represent supertypes and subtypes as below

EMPLOYEE

Sales_Target

Emp_ID

ADMINSALES


We generally only include subtypes in the ER model when they are of use - they may participate in relationships and have additional attributes

DEPARTMENT

CUSTOMER

employs

services

employed by

served bySALESPERSON

EMPLOYEE



Entity types may have multiple subtypes

Entity subtypes may be nested

EMPLOYEE

PART-TIME

FULL-TIME


CONTRACT

SALARIED


Multiple entity subtypes should be– non-overlapping (disjoint)

• an entity instance of a supertype cannot be a member of more than one subtype

• we can represent overlapping entity types in EER– collectively exhaustive

• must cover all possible instances of the supertype

This enables easier translation to a relational design



Use an allowable vocabulary based on business termsUse an allowable, agreed-on list of abbreviationsWhere possible names should suggest the meaningNames should be uniqueNames should be clear and readableManes should be conciseNames should be unambiguousWhere aliases are used they must be specified

Naming of ER Components


Quality of ER ModelsGood quality data models exhibit– correctness– completeness– understandability– simplicity– flexibility

Sometimes different interpretations of the data model can be equally valid and/or appropriate

The 5 E’s of modelling– efficacy, effectiveness, efficiency, ethicality, elegance


ReferencesChen, P., (1976), “The Entity-Relationship Model – Towards a

Unified View of Data”, ACM Transactions on Database Systems, 1:1, March 1976, pp. 9 – 36.

GUIDE, (2001),“GUIDE Business Rules Project”, Revised Final Report.

Hoffer, J.A., Prescott, M.B. and McFadden, F.R., (2005), Modern Database Management, (7th edn.), Pearson Education Inc., Upper Saddle River, NJ, USA.

Kroenke, D.M., (2004), Database Processing: Fundamentals, Design and Implementation, (9th edn.), Pearson Education Inc., Upper Saddle River, NJ, USA.

ims1907 database systems week 6 data modelling entity-relation diagrams

Documents

data business rules

data integrity data

defined business rules

relationships rules

purpose of data modelling

monash university

guide business rules

business structure