ims1907 database systems week 6 data modelling entity-relation diagrams
Post on 21-Dec-2015
222 views
TRANSCRIPT
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
Monash University 2004 3
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
Monash University 2004 4
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
Monash University 2004 5
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
Monash University 2004 6
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
Monash University 2004 7
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
Monash University 2004 8
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
Monash University 2004 9
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
Monash University 2004 10
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
Monash University 2004 11
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
Monash University 2004 12
Strong entities
Strong and Weak Entities
CUSTOMER SALE PRODUCT
Weak entities
MOVIE VIDEOTAPE
Monash University 2004 13
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
Monash University 2004 14
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
Monash University 2004 15
Attributes
CUSTOMER
Customer_Name
Customer_ID
Customer_Address
Customer_Email
Age
Date_Of_Birth
Monash University 2004 16
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
Monash University 2004 17
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
Monash University 2004 18
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
Monash University 2004 19
Relationships
COURSEcompletesSTUDENT
Name
Course_ID TitleCert_ID
Date_Comp
Student_ID
COURSEcompletesSTUDENT
Name
Course_ID TitleDate_Comp
Student_ID
Monash University 2004 20
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
Monash University 2004 21
RelationshipsUnary relationship– one instance of an entity type has a relationship
with another instance of the same entity type
CHILDis
sibling of
EMPLOYEE supervises
Monash University 2004 22
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
Monash University 2004 23
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
Monash University 2004 24
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
Monash University 2004 25
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
Monash University 2004 26
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
Monash University 2004 27
Cardinality constraints on a relationship
Relationships
CUSTOMER
ACCOUNT
CUSTOMER
SALE
ITEM
ORDER
Appears on
makesis
assigned
Monash University 2004 28
Entities can participate in multiple relationships between the same entities– reflecting different business rules
Relationships
TEACHER SUBJECT
Qualified to teach
Scheduled to
teach
4
Monash University 2004 29
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
Monash University 2004 30
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
Monash University 2004 31
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
Monash University 2004 32
Example of an entity subtype– the entity type EMPLOYEE includes the subtypes
SALES and ADMIN
EMPLOYEE
Entity Types and Sub-types
ADMIN
SALES
Monash University 2004 33
Entity Types and Sub-typesWe can also represent supertypes and subtypes as below
EMPLOYEE
Sales_Target
Emp_ID
ADMINSALES
Monash University 2004 34
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 and Sub-types
Monash University 2004 35
Entity types may have multiple subtypes
Entity subtypes may be nested
EMPLOYEE
PART-TIME
FULL-TIME
Entity Types and Sub-types
CONTRACT
SALARIED
Monash University 2004 36
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
Entity Types and Sub-types
Monash University 2004 37
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
Monash University 2004 38
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
Monash University 2004 39
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.