Why We Model

y We build models of complex systems because we cannot comprehend any such system in its entirety y Need to develop a common understanding of the problem and the solution y Cannot afford a trial-and-error approach y to communicate the desired structure and behavior of our systems

Why We Model
to visualize and control systems architecture to understand the system we are building, often exposing opportunities for simplification and reuse to manage risk

How We Model
y The choice of which model we use has a profound influence on how a problem is attacked and how a solution is shaped y No single model is sufficient; every complex system is best approached through a set of independent models Every model may be expressed at different levels of fidelity y The best models are connected to reality

Data Model
Integrated collection of concepts for describing and manipulating data, relationships between data, and constraints on the data in an organization. Data Model comprises:
a structural part(set of rules to construct DB) a manipulative part(defines operations allowed in DB) possibly a set of integrity rules.
4

Data Model
Purpose
To represent data in an understandable way.

Categories of data models include:

Object-based
(describes data at ext. & conc. Level)

Record-based
(describes data internal Level)

Physical.
(describes data at ext. & conc. Level)
5

Data Models
Object-Based Data Models
(use concept of entities, attributes and relationships)

Entity-Relationship Semantic Functional Object-Oriented.

Record-Based Data Models

(describes data at logical and view level)

Relational Data Model Network Data Model Hierarchical Data Model.

Physical Data Models

physically on computer)

(describes how data is stored 6

Entity Relationship (E-R) Modeling

Learning Objectives
How to use EntityRelationship (ER) modeling in database design. Basic concepts associated with ER model. Diagrammatic technique for displaying ER model using Unified Modeling Language (UML). How to identify and resolve problems with ER models called connection traps. How to build an ER model from a requirements specification.
8

Concepts of the ER Model

Entity types Relationship types Attributes

ENTITY
an object that exists distinguishable from other objects could be concrete or abstract Examples : a book, an item, a student, a purchase order (a/an above indicates that we are referring to one of these)

Entity Type
Entity type
Group of objects with same properties, identified by enterprise as having an independent existence.

Entity occurrence
Uniquely identifiable object of an entity type.

13

Examples of Entity Types

14

ER Diagram of Staff and Branch Entity Types

15

Entity Type
Strong Entity Type
Entity type that is not existence-dependent on some other entity type.

Weak Entity Type

Entity type that is existence-dependent on some other entity type.

16

Strong Entity Type called Client and Weak Entity Type called Preference

17

ENTITY SET
a set of similar entities need not be disjoint with other entity sets
e.g., supplier and customer may have common entities

Example : set of all books in a library

set of all customers

entity set also called entity type or entity class entity considered as an occurrence of entity

ENTITY SET
we often use the words entity to mean entity-set entity sets are named using singular common nouns :
Book Student Course

RELATIONSHIP
represents association among entities e.g., a particular book is a text for particular course
book Database Systems by C.J. Date is text for course identified by code CS644

e.g., student GANESH has enrolled for course CS644

RELATIONSHIP SET
set of relationships of same type words relationship and relationship set often used interchangeably

Relationship Types
Relationship type
Set of meaningful associations among entity types.

Relationship occurrence
Uniquely identifiable association, which includes one occurrence from each participating entity type.
22

Relationship Types
Degree of a Relationship
Number of participating entities in relationship.

Relationship of degree:
two is binary; three is ternary; four is quaternary.

23

ER Diagram of Branch Has Staff Relationship

24

Binary Relationship called POwns

25

Ternary Relationship called Registers

26

Quaternary Relationship called Arranges

27

Relationship Types
Recursive Relationship
Relationship type where same entity type participates more than once in different roles.

Relationships may be given role names to indicate purpose that each participating entity type plays in a relationship.

28

Recursive Relationship called Supervises with Role Names

29

RELATIONSHIP CARDINALITY
is a constraint on a relationship it characterizes relationships further given as (mapping) cardinality : how many entities of an entity set participate in a relationship especially useful for binary relationships

RELATIONSHIP CARDINALITY
a relationship set R between entity sets A and B may be one of the following
one-to-one : one entity in A associated with at most one entity in B one-to-many : one entity in A may be associated with zero/more number of entities in B. However, one entity in B can be associated with at most one entity from A. many-to-one : reverse of above definition (like a mathematical function)

RELATIONSHIP CARDINALITY
many-to-many : one entity in A may be associated with any number of entities in B, and vice-versa.

EXAMPLES :
relationship set TEACHES from TEACHER to COURSE is one-to-many (TAUGHT-BY from COURSE to TEACHER is many-to-one) relationship STUDY between STUDENT and COURSE is many-to-many

Attributes
Attribute
Property of an entity or a relationship type.

Attribute Domain
Set of allowable values for one or more attributes.

33

ATTRIBUTE
an entity has a set of attributes attribute defines property of an entity it is given a name attribute has value for each entity value may change over time same set of attributes are defined for entities in an entity set

ATTRIBUTE.
Example : entity set BOOK has the following attributes
TITLE ISBN ACC-NO AUTHOR PUBLISHER YEAR PRICE

a particular book has value for each of the above attributes

Attributes
Simple Attribute
Attribute composed of a single component with an independent existence.

Composite Attribute
Attribute composed of multiple components, each with an independent existence.

36

Attributes
Single-valued Attribute
Attribute that holds a single value for each occurrence of an entity type.

Multi-valued Attribute
Attribute that holds multiple values for each occurrence of an entity type.

37

Attributes
Derived Attribute
Attribute that represents a value that is derivable from value of a related attribute, or set of attributes, not necessarily in the same entity type.

38

ER Diagram of Staff and Branch Entities and their Attributes

39

Semantic Net of Has Relationship Type

40

Entities associated through two distinct Relationships with Role Names

41

Problems with ER Models

Problems may arise when designing a conceptual data model called connection traps. Often due to a misinterpretation of the meaning of certain relationships. Two main types of connection traps are called fan traps and chasm traps.
42

Problems with ER Models

Fan Trap
Where a model represents a relationship between entity types, but pathway between certain entity occurrences is ambiguous.

Chasm Trap
Where a model suggests the existence of a relationship between entity types, but pathway does not exist between certain entity occurrences.

43

An Example of a Fan Trap

44

Semantic Net of ER Model with Fan Trap

At which branch office does staff number SG37 work?

45

Restructuring ER Model to Remove Fan Trap

46

Semantic Net of Restructured ER Model with Fan Trap Removed

SG37 works at branch B003.

47

An Example of a Chasm Trap

48

Semantic Net of ER Model with Chasm Trap

At which branch office is property PA14 available?

49

ER Model Restructured to Remove Chasm Trap

50

Semantic Net of Restructured ER Model with Chasm Trap Removed

51

Comparison of E-R Modeling Symbols

52

Keys
Candidate Key
Minimal set of attributes that uniquely identifies each occurrence of an entity type.

Primary Key
Candidate key selected to uniquely identify each occurrence of an entity type.

Composite Key
A candidate key that consists of two or more attributes.

53

Structural Constraints
Main type of constraint on relationships is called multiplicity. Multiplicity - number (or range) of possible occurrences of an entity type that may relate to a single occurrence of an associated entity type through a particular relationship. Represents policies (called business rules) established by user or company.
54

Structural Constraints
The most common degree for relationships is binary. Binary relationships are generally referred to as being:
one-to-one (1:1) one-to-many (1:*) many-to-many (*:*)
55

Semantic Net of Staff Manages Branch Relationship Type

56

Multiplicity of Staff Manages Branch (1:1) Relationship Type

57

Semantic Net of Staff Oversees PropertyForRent Relationship Type

58

Multiplicity of Staff Oversees PropertyForRent (1:*) Relationship Type

59

Semantic Net of Newspaper Advertises PropertyForRent Relationship Type

60

Multiplicity of Newspaper Advertises PropertyForRent (*:*) Relationship

61

Structural Constraints
Multiplicity for Complex Relationships
Number (or range) of possible occurrences of an entity type in an n-ary relationship when other (n-1) values are fixed.

62

Semantic Net of Ternary Registers Relationship with Values for Staff and Branch Entities Fixed

63

Multiplicity of Ternary Registers Relationship

64

Summary of Multiplicity Constraints

65

Structural Constraints
Multiplicity is made up of two types of restrictions on relationships: cardinality and participation. Cardinality
Describes maximum number of possible relationship occurrences for an entity participating in a given relationship type (1,4), (1,N) ...

Participation
Determines whether all or only some entity occurrences participate in a relationship (optional/mandatory).
66

Multiplicity as Cardinality and Participation Constraints

67

Problems with ER Models

Problems may arise when designing a conceptual data model called connection traps. Often due to a misinterpretation of the meaning of certain relationships. Two main types of connection traps are called fan traps and chasm traps.
68

Problems with ER Models

Fan Trap
Where a model represents a relationship between entity types, but pathway between certain entity occurrences is ambiguous.

Chasm Trap
Where a model suggests the existence of a relationship between entity types, but pathway does not exist between certain entity occurrences.

69

An Example of a Fan Trap

70

Semantic Net of ER Model with Fan Trap

At which branch office does staff number SG37 work?

71

Restructuring ER Model to Remove Fan Trap

72

Semantic Net of Restructured ER Model with Fan Trap Removed

SG37 works at branch B003.

73

An Example of a Chasm Trap

74

Semantic Net of ER Model with Chasm Trap

At which branch office is property PA14 available?

75

ER Model Restructured to Remove Chasm Trap

76

Semantic Net of Restructured ER Model with Chasm Trap Removed

77

Comparison of E-R Modeling Symbols

78

First ERD Segment Established

Figure 3.43

79

Second and Third ERD Segments Established

80

Fourth and Fifth ERD Segments Established

81

Sixth and Seventh ERD Segments Established

82

Eighth ERD Segment Established

83

Ninth ERD Segment Established

Figures 3.51

84

Components of E-R Model

85

Completed ERD

86

Burger Inventory Example

INVOICE SALE Receipt_Number Sale_Date Invoice_Number Vendor_Id Invoice_Date Paid

sells ITEM SALE Quantity_Sold

includes INVOICE ITEM Quantity_Added

is ordered on

is invoiced on INVENTORY ITEM

PRODUCT Product_Id Product_Description

RECIPE LINE is produced by Quantity_Used is used in

Item_Number Item_Description Quantity_in_Stock Type_of_Item Minimum_Order_Quantity

87

ER Diagram of Branch View of DreamHome

88

ANSI-SPARC Three-Level Architecture

89

Degrees of Abstraction
Conceptual
Global view of data from application domain, based on end-users requirements Basis for identification and description of main data items ERD used to graphically represent conceptual data model (or class diagram in UML) Hardware and software (and DBMS) independent

Internal
Representation of database as seen by DBMS Adapts conceptual model to a specific DBMS Software dependent
90

Degrees of Abstraction
Three main levels of data models: deliverables
Conceptual data model
Project initiation and planning: ERDs with entities and relationships only Analysis: ERDs refined with attributes

Logical data model = Internal + external data model: a set of normalized relations, based on ERD and views/forms design Physical data model = physical file and database design
91

Degrees of Abstraction
External
Users views of data environment Provides subsets of internal view Makes application program development easier Facilitates designers tasks Ensures adequacy of conceptual model Ensures security constraints in design

Physical
Lowest level of abstraction Software and hardware dependent Requires definition of physical storage devices and access methods
92