1. IMS1907 Database Systems Week 6 Data Modelling Entity-Relation Diagrams

2. Monash University 20042 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

3. Monash University 20043 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

4. Monash University 20044 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

5. Monash University 20045 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

6. Monash University 20046 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

7. Monash University 20047 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

8. Monash University 20048 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

9. Monash University 20049 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

10. Monash University 200410 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

11. Monash University 200411 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

12. Monash University 200412 Strong entities Strong and Weak Entities CUSTOMERSALEPRODUCT Weak entities MOVIEVIDEOTAPE

13. Monash University 200413 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

14. Monash University 200414 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

15. Monash University 200415 Attributes CUSTOMER Customer_Name Customer_ID Customer_Address Customer_Email Age Date_Of_Birth

16. Monash University 200416 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

17. Monash University 200417 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

18. Monash University 200418 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

19. Monash University 200419 Relationships COURSE completes STUDENT Name Course_ID Title Cert_IDDate_CompStudent_ID COURSE completes STUDENT Name Course_ID Title Date_CompStudent_ID

20. Monash University 200420 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

21. Monash University 200421 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

22. Monash University 200422 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

23. Monash University 200423 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

24. Monash University 200424 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

25. Monash University 200425 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

26. Monash University 200426 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

27. Monash University 200427 Cardinality constraints on a relationship Relationships CUSTOMER ACCOUNT CUSTOMER SALE ITEM ORDER Appears on makes is assigned

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

29. Monash University 200429 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

30. Monash University 200430 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

31. Monash University 200431 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

32. Monash University 200432 Example of an entity subtype –the entity type EMPLOYEE includes the subtypes SALES and ADMIN EMPLOYEE Entity Types and Sub-types ADMIN SALES

33. Monash University 200433 Entity Types and Sub-types We can also represent supertypes and subtypes as below EMPLOYEE Sales_Target Emp_ID ADMINSALES

34. Monash University 200434 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

35. Monash University 200435 Entity types may have multiple subtypes Entity subtypes may be nested EMPLOYEE PART-TIME FULL-TIME Entity Types and Sub-types CONTRACT SALARIED

36. Monash University 200436 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

37. Monash University 200437 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

38. Monash University 200438 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

39. Monash University 200439 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.