IMS1907 Database Systems Week 6 Data Modelling Entity-Relation Diagrams

Monash University 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 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 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 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 projects Can 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 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 technology Communication tool between designers and end users Entity-Relationship (ER) Modelling

Monash University Detailed, logical representation of the data for an organisation or business area Expressed 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 relationships Minimum set of data objects necessary to construct the data used within the system in its various physical forms Entity-Relationship (ER) Models

Monash University 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 Person, role, location, object, event or concept in the user environment about which an organisation wishes to store data A ‘thing of interest’ to the organisation –has some real world existence Often identified by the way things are referred to in an organisation Named using a singular noun or noun phrase Entities

Monash University Entity type is a set of entities that share common characteristics Entity instance is a single occurrence of an entity A logical construct Should 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 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 Strong entities Strong and Weak Entities CUSTOMERSALEPRODUCT Weak entities MOVIEVIDEOTAPE

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

Monash University Should be atomic or simple Can be multi-valued May be able to be derived from other attributes An identifier is formed from an attribute or combination of attributes that uniquely identify an entity Attributes should be sufficient to support –essential functions –current operations –measurement of performance against objectives Attributes

Monash University Attributes CUSTOMER Customer_Name Customer_ID Customer_Address Customer_ Age Date_Of_Birth

Monash University Composite Attributes CUSTOMER Customer_Name Customer_ID Customer_Address Last_Name First_Name Street_Address Suburb Postcode CUSTOMER Flight_ID Flight_No No_Of_Passengers Date

Monash University The glue holding the ER components together Represent the business rules of an organisation An association representing an interaction between one or more instances of an entity type that is of interest to an organisation The relationship must be meaningful –allow us to answer questions that could not be answered given just the entity types Relationships

Monash University 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 entities Entities can participate in multiple relationships between the same entities –reflecting different business rules Relationships

Monash University Relationships COURSE completes STUDENT Name Course_ID Title Cert_IDDate_CompStudent_ID COURSE completes STUDENT Name Course_ID Title Date_CompStudent_ID

Monash University 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 Relationships Unary relationship –one instance of an entity type has a relationship with another instance of the same entity type CHILD is sibling of EMPLOYEE supervises

Monash University Relationships CUSTOMER ACCOUNT Binary relationship –one instance of an entity type has a relationship with an instance of a different entity type CUSTOMER SALE ITEM ownsmakescontains

Monash University Relationships Ternary 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 Relationships Higher 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 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-oneone-to-manymany-to-many Allocates into classifies is assigned

Monash University 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 Cardinality constraints on a relationship Relationships CUSTOMER ACCOUNT CUSTOMER SALE ITEM ORDER Appears on makes is assigned

Monash University Entities can participate in multiple relationships between the same entities –reflecting different business rules Relationships TEACHERSUBJECT Qualified to teach Scheduled to teach 4

Monash University 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 PriceEffective_Date SHIPMENT Shipment_ID Shipping_History LocationArrival_Date

Monash University Entity Types and Sub-types Some 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 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 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 Entity Types and Sub-types We can also represent supertypes and subtypes as below EMPLOYEE Sales_Target Emp_ID ADMINSALES

Monash University 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 by SALESPERSON EMPLOYEE Entity Types and Sub-types

Monash University 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 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 Use an allowable vocabulary based on business terms Use an allowable, agreed-on list of abbreviations Where possible names should suggest the meaning Names should be unique Names should be clear and readable Manes should be concise Names should be unambiguous Where aliases are used they must be specified Naming of ER Components

Monash University Quality of ER Models Good 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 References Chen, 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, (7 th edn.), Pearson Education Inc., Upper Saddle River, NJ, USA. Kroenke, D.M., (2004), Database Processing: Fundamentals, Design and Implementation, (9 th edn.), Pearson Education Inc., Upper Saddle River, NJ, USA.