BIM Modelleren ER 1213 v01

7/22/2019 BIM Modelleren ER 1213 v01

1/132

CT

ER modelleren

BIM kwartiel 1.1

1


2/132

CT

Beoordelingscriteria wat moet jekennen en kunnen

begrippen object, entiteit, attribuut, identificatie,relatie, cardinaliteit, subtype, objectmodel, ERD

op basis van een beschrijving van dewerkelijkheid een entiteitenmodel maken

op basis van documenten uit de werkelijkheideen entiteitenmodel maken

een gegeven model beoordelen op correctheid envolledigheid

op basis van een entiteitenmodel een relationeeldatabasemodel maken

2


3/132

CT

Lesstofplanning

3

Week Soort Onderwerpen Literatuur opgaven Opgaven

1.1 2HC InleidingObject/attribuut/entiteit

Db Sys: Ch. 12 12.10

1.2 2HC Oefenen ER 12.1112.1212.13

1.3 2HC Subtypering Db Sys: Ch. 13

1.4 2HC Oefenen ER uitdelen Casus ER oefenopgaven (zie BB)

1.5 2WC Case ER, werken aan opdracht

1.6 2WC Case ER, werken aan opdracht

1.7 2HC Van ER naar logisch db modelModelleren vanuitdocumenten

Db Sys: Ch. 16, 17

1.8 Tentamen


4/132

CT

ER modelleren

H12 Entity-Relationship Modeling

Pearson Education 2009


5/132

CT31-10-2013 InformatieModellerin 5

ER vs. Fysiek model - Bouwstenen

ER model (Conceptueel model) Entiteit Relaties Attributen Specialisatie/Generalisatie

Logisch (Relationeel) model (Implementatiemodel vb MS Access ) Tabellen

Primary keys Foreign keys Attributen


6/132

CT

Alternative Terminology forRelational Model (Logisch Model)

6 Pearson Education 2009


7/132 CT31-10-2013 InformatieModellerin 7

ER vs. Fysiek model (2)

Let op:

Entiteit Tabel


8/132 CT31-10-2013 InformatieModellerin 8

ER Voorbeeld (oude notatie)

Docent VakGeeft

StudentVolgt


9/132 CT

Cardinaliteit (oude notatie)

9


10/132 CT31-10-2013

InformatieModellerin 10

ER Voorbeeld (met cardinaliteit)(oude notatie)

Docent VakGeeft

StudentVolgt


11/132 CT

Nieuwe notatie (UML)

11


12/132 CT

Nieuwe notatie (UML) metovererving

12


13/132 CT

ER diagram of Branch user views ofDreamHome (nieuwe notatie; UML)

13Pearson Education 2009


14/132 CT

Concepts of the ER Model

Entity types

Relationship types

Attributes



15/132 CT

Entity Type

Entity type Group of objects with same properties,

identified by enterprise as having anindependent existence.

Entity occurrence Uniquely identifiable object of an entity type.



16/132 CT

Examples of Entity Types


di f S ff d h


17/132 CT

ER diagram of Staff and Branchentity types



18/132 CT

Relationship Types

Relationship type Set of meaningful associations among entity

types.

Relationship occurrence Uniquely identifiable association, whichincludes one occurrence from eachparticipating entity type.


S i f H l i hi


19/132 CT

Semantic net of Has relationshiptype


ER di f B h H S ff


20/132 CT

ER diagram of Branch Has Staffrelationship



21/132 CT

Relationship Types

Degree of a Relationship Number of participating entities in

relationship.

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



22/132 CT

Binary relationship called POwns


T l ti hi ll d


23/132 CT

Ternary relationship calledRegisters


Q t l ti hi ll d


24/132 CT

Quaternary relationship calledArranges



25/132 CT

Relationship Types

Recursive Relationship Relationship type where same entity type

participates more than once in different roles.

Relationships may be given role names toindicate purpose that each participatingentity type plays in a relationship.


Rec rsi e relationship called


26/132 CT

Recursive relationship calledSupervises with role names


E titi i t d th h t di ti t


27/132 CT

Entities associated through two distinctrelationships with role names



28/132 CT

Attributes

Attribute Property of an entity or a relationship type.

Attribute Domain

Set of allowable values for one or moreattributes.



29/132 CT

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.



30/132

CT

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.



31/132

CT

Attributes

Derived Attribute Attribute that represents a value that is

derivable from value of a related attribute, orset of attributes, not necessarily in the sameentity type.



32/132

CT

Keys

Candidate Key Minimal set of attributes that uniquely

identifies each occurrence of an entity type.

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

Composite Key A candidate key that consists of two or more

attributes.


ER diagram of Staff and Branch


33/132

CT

ER diagram of Staff and Branchentities and their attributes



34/132

CT

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 onsome other entity type.


Strong entity type called Client and


35/132

CT

Strong entity type called Client andweak entity type called Preference


Relationship called Advertises with


36/132

CT

Relationship called Advertises withattributes (Associatieklasse)



37/132

CT

Structural Constraints

Main type of constraint on relationships iscalled multiplicity.

Multiplicity - number (or range) of

possible occurrences of an entity type thatmay relate to a single occurrence of anassociated entity type through a particularrelationship.

Represents policies (called business rules)established by user or company.



38/132

CT


The most common degree forrelationships is binary.

Binary relationships are generally referred

to as being: one-to-one (1:1) one-to-many (1:*) many-to-many (*:*)


Semantic net of Staff Manages


39/132

CT

Semantic net of Staff ManagesBranch relationship type


Multiplicity of Staff Manages Branch


40/132

CT

Multiplicity of Staff Manages Branch(1:1) relationship


Semantic net of Staff Oversees


41/132

CT

Semantic net of Staff OverseesPropertyForRent relationship type


Multiplicity of Staff Oversees


42/132

CT

Multiplicity of Staff OverseesPropertyForRent (1:*) relationship type


Semantic net of Newspaper Advertises


43/132

CT

Semantic net of Newspaper AdvertisesPropertyForRent relationship type


Multiplicity of Newspaper Advertises


44/132

CT

Multiplicity of Newspaper AdvertisesPropertyForRent (*:*) relationship


S l C i


45/132

CT


Multiplicity for Complex Relationships Number (or range) of possible occurrences of

an entity type in an n-ary relationship whenother (n-1) values are fixed.


Semantic net of ternary Registers relationship with


46/132

CT

Semantic net of ternary Registers relationship withvalues for Staff and Branch entities fixed


Multiplicity of ternary Registers


47/132

CT

Multiplicity of ternary Registersrelationship


S f l i li i i


48/132

CT

Summary of multiplicity constraints


S l C i


49/132

CT


Multiplicity is made up of two types ofrestrictions on relationships: cardinalityand participation.


St t l C t i t


50/132

CT


Cardinality Describes maximum number of possible

relationship occurrences for an entityparticipating in a given relationship type.

Participation Determines whether all or only some entity

occurrences participate in a relationship.


Multiplicity as cardinality and


51/132

CT

Multiplicity as cardinality andparticipation constraints


ER diagram of Branch user views of


52/132

CT

ER diagram of Branch user views ofDreamHome (nieuwe notatie; UML)


P bl ith ER M d l


53/132

CT

Problems with ER Models

Problems may arise when designing aconceptual data model called connectiontraps.

Often due to a misinterpretation of themeaning of certain relationships.

Two main types of connection traps arecalled fan traps and chasm traps.


Problems ith ER Models


54/132

CT

Problems with ER Models

Fan Trap Where a model represents a relationship

between entity types, but pathway betweencertain entity occurrences is ambiguous.

Chasm Trap Where a model suggests the existence of a

relationship between entity types, but pathwaydoes not exist between certain entityoccurrences.


An Example of a Fan Trap


55/132

CT

An Example of a Fan Trap


Semantic Net of ER Model with Fan


56/132

CT

Trap

At which branch office does staff numberSG37 work?


Restructuring ER model to remove


57/132

CT

gFan Trap


Semantic Net of Restructured ER


58/132

CT

Model with Fan Trap Removed

SG37 works at branch B003.


Chasm trap


59/132

CT

Chasm trap

Chasm Trap Where a model suggests the existence of a

relationship between entity types, but pathwaydoes not exist between certain entityoccurrences.


An Example of a Chasm Trap


60/132

CT

An Example of a Chasm Trap


Semantic Net of ER Model with


61/132

CT

Chasm Trap

At which branch office is property PA14available?


ER Model restructured to remove


62/132

CT

Chasm Trap


Semantic Net of Restructured ER


63/132

CT

Model with Chasm Trap Removed


CT


64/132

CT

ER Modelleren

H13 Enhanced Entity-RelationshipModeling

EER


Specialization / Generalization


65/132

CT


Superclass An entity type that includes one or more

distinct subgroupings of its occurrences.

Subclass A distinct subgrouping of occurrences of anentity type.




66/132

CT


Superclass/subclass relationship is one-to-one (1:1).

Superclass may contain overlapping or

distinct subclasses.

Not all members of a superclass need be amember of a subclass.




67/132

CT


Attribute Inheritance An entity in a subclass represents same real

world object as in superclass, and maypossess subclass-specific attributes, as well asthose associated with the superclass.




68/132

CT


Specialization Process of maximizing differences between

members of an entity by identifying theirdistinguishing characteristics.

Generalization Process of minimizing differences between

entities by identifying their commoncharacteristics.


AllStaff relation holding details of


69/132

CT

all staff


Specialization/generalization of Staff entityb l b l


70/132

CT

into subclasses representing job roles


Specialization/generalization of Staff entityi j b l d f l


71/132

CT

into job roles and contracts of employment


EER diagram with shared subclassd b l h b l


72/132

CT

and subclass with its own subclass


Constraints on Specialization /G li i


73/132

CT

Generalization Two constraints that may apply to a

specialization/generalization: participation constraints disjoint constraints.

Participation constraint Determines whether every member in

superclass must participate as a member of a

subclass. May be mandatory or optional .




74/132

CT

Generalization Disjoint constraint

Describes relationship between members ofthe subclasses and indicates whether memberof a superclass can be a member of one, ormore than one, subclass.

May be disjoint or nondisjoint. Disjoint = {Or} Nondisjoint = {And}




75/132

CT

Generalization There are four categories of constraints of

specialization and generalization: mandatory and disjoint optional and disjoint mandatory and nondisjoint optional and nondisjoint.


DreamHome worked example S ff S l


76/132

CT

Staff Superclass


Staff Superclass withSupervisor andManager subclasses

DreamHome worked example -O S l


77/132

CT

Owner Superclass


Owner Superclass

with PrivateOwnerandBusinessOwnersubclasses

DreamHome worked example -P l


78/132

CT

Person superclass

78


Person superclass withStaff, PrivateOwner,and Client subclasses

CT


79/132

ER Modelleren

H16MethodologyConceptual Databases Design


Chapter 16 - Objectives


80/132

CT

p j

The purpose of a design methodology.

Database design has three main phases:conceptual, logical, and physical design.

How to decompose the scope of thedesign into specific views of theenterprise.

80


Database Design Methodology


81/132

CT

g gy

Three main phases Conceptual database design Logical database design Physical database design

81


Conceptual Database Design


82/132

CT

p g

The process of constructing a model of

the data used in an enterprise,independent of all physicalconsiderations.

82


Logical Database Design


83/132

CT

g g

The process of constructing a model of

the data used in an enterprise based on a specific data model (e.g. relational) but independent of a particular DBMS and

other physical considerations .

83


Physical Database Design


84/132

CT

y g

The process of producing a description of

the implementation of the database onsecondary storage;

it describes: the base relations file organizations indexes design used to achieve efficient access

to the data

any associated integrity constraints security measures

84


Step 1 Build Conceptual Data


85/132

CT

p p

To build a conceptual data model of the data

requirements of the enterprise. Model comprises entity types, relationship types,

attributes and attribute domains, primary and alternatekeys, and integrity constraints.

Step 1.1 Identify entity types To identify the required entity types.

Step 1.2 Identify relationship types To identify the important relationships that exist

between the entity types.

85




86/132

CT

Step 1.3 Identify and associate attributes

with entity or relationship types To associate attributes with the appropriate

entity or relationship types and document thedetails of each attribute.

Step 1.4 Determine attribute domains To determine domains for the attributes in the

data model and document the details of eachdomain.

86




87/132

CT

Step 1.5 Determine candidate, primary,

and alternate key attributes To identify the candidate key(s) for each entity

and if there is more than one candidate key, tochoose one to be the primary key and the

others as alternate keys. Step 1.6 Consider use of enhanced

modeling concepts (optional step) To consider the use of enhanced modeling

concepts, such as specialization /generalization, aggregation, and composition.

87


Step 1 Build Conceptual Data Model


88/132

CT

Step 1.7 Check model for redundancy To check for the presence of any redundancy

in the model and to remove any that doesexist.

Step 1.8 Validate conceptual modelagainst user transactions To ensure that the conceptual model supports

the required transactions.

88


Step 1 Build Conceptual Data Model


89/132

CT

Step1.9 Review conceptual data model

with user To review the conceptual data model with the

user to ensure that the model is a truerepresentation of the data requirements of the

enterprise.

89


Extract from data dictionary for Staff user viewsof DreamHome showing description of entities


90/132

CT

of DreamHome showing description of entities


First-cut ER diagram for Staff userviews of DreamHome


91/132

CT

views of DreamHome

91


Extract from data dictionary for Staff user views ofDreamHome showing description of relationships


92/132

CT

DreamHome showing description of relationships

92


Extract from data dictionary for Staff user views ofDreamHome showing description of attributes


93/132

CT

DreamHome showing description of attributes

93


ER diagram with primary keysadded


94/132

CT

added

94


ER diagram for Staff user views ofDreamHome with primary keys added

Revised ER diagram withspecialization / generalization


95/132

CT

specialization / generalization

95


Example of removing a redundantrelationship called Rents


96/132

CT

relationship called Rents

96


Example of a non-redundantrelationship FatherOf


97/132

CT

relationship FatherOf

97


Using pathways


98/132

CT98


Using pathwaysto check that theconceptualmodel supports

the usertransactions

CT


99/132

ER Modelleren

H17 MethodologyLogical Database Design for theRelational Model




100/132

CT

How to derive a set of relations from a

conceptual data model.

How to validate these relations using the

technique of normalization.

100




101/132

CT

How to validate a logical data model to ensure it

supports the required transactions.

How to merge local logical data models based onone or more user views into a global logical data

model that represents all user views.

How to ensure that the final logical data model isa true and accurate representation of the data

requirements of the enterprise.

101


Step 2 Build and Validate LogicalData Model


102/132

CT

Data Model To translate the conceptual data model

into a logical data model and then tovalidate this model to check that it isstructurally correct using normalizationand supports the required transactions.

102


Step 2 Build and Validate LogicalData Model


103/132

CT

Data Model Step 2.1 Derive relations for logical data

model To create relations for the logical data model

to represent the entities, relationships, andattributes that have been identified.

103


Conceptual data model for Staffview showing all attributes


104/132

CT

v ew s ow g a att butes

104


Step 2.1 Derive relations forlogical data model


105/132

CT

g (1) Strong entity types

For each strong entity in the data model,create a relation that includes all the simpleattributes of that entity. For compositeattributes, include only the constituent simple

attributes.




106/132

CT

g (2) Weak entity types

For each weak entity in the data model, createa relation that includes all the simpleattributes of that entity. The primary key of aweak entity is partially or fully derived from

each owner entity and so the identification ofthe primary key of a weak entity cannot bemade until after all the relationships with theowner entities have been mapped.




107/132

CT

g (3) One-to-many (1:*) binary relationship

types For each 1:* binary relationship, the entity on

the one side of the relationship is designatedas the parent entity and the entity on the

many side is designated as the child entity .To represent this relationship, post a copy ofthe primary key attribute(s) of parent entityinto the relation representing the child entity,to act as a foreign key .




108/132

CT

g (4) One-to-one (1:1) binary relationship types

Creating relations to represent a 1:1 relationship ismore complex as the cardinality cannot be used toidentify the parent and child entities in a relationship.Instead, the participation constraints are used to decidewhether it is best to represent the relationship bycombining the entities involved into one relation or bycreating two relations and posting a copy of the primarykey from one relation to the other.

Z.o.z.




109/132

CT

g (a) Mandatory participation on both sides of 1:1 relationship

Combine entities involved into one relation and choose one ofthe primary keys of original entities to be primary key of thenew relation, while the other (if one exists) is used as analternate key.

(b) Mandatory participation on one side of a 1:1 relationship

Identify parent and child entities using participationconstraints. Entity with optional participation in relationship isdesignated as parent entity, and entity with mandatoryparticipation is designated as child entity . A copy of primarykey of the parent entity is placed in the relation representingthe child entity. If the relationship has one or more attributes,these attributes should follow the posting of the primary keyto the child relation.




110/132

CT

g (c) Optional participation on both sides of

a 1:1 relationship In this case, the designation of the parent and child

entities is arbitrary unless we can find out moreabout the relationship that can help a decision to bemade one way or the other.




111/132

CT

g (5) One-to-one (1:1) recursive relationships

For a 1:1 recursive relationship, follow the rules forparticipation as described above for a 1:1 relationship. mandatory participation on both sides, represent the

recursive relationship as a single relation with two copiesof the primary key.

mandatory participation on only one side, option to createa single relation with two copies of the primary key, or tocreate a new relation to represent the relationship. Thenew relation would only have two attributes , both copiesof the primary key. As before, the copies of the primarykeys act as foreign keys and have to be renamed toindicate the purpose of each in the relation.

optional participation on both sides, again create a newrelation as described above .




112/132

CT

g (6) Superclass/subclass relationship types

Identify superclass entity as parent entity andsubclass entity as the child entity. There arevarious options on how to represent such arelationship as one or more relations.

The selection of the most appropriate option isdependent on a number of factors such as thedisjointness and participation constraints onthe superclass/subclass relationship, whetherthe subclasses are involved in distinctrelationships, and the number of participantsin the superclass/subclass relationship.


Guidelines for representation ofsuperclass / subclass relationship


113/132

CT

p p


epresentat on o superc ass su c assrelationship based on participation anddisjointness


114/132

CT

disjointness




115/132

CT

(7) Many-to-many (*:*) binary relationship

types Create a relation to represent the relationship

and include any attributes that are part of therelationship. We post a copy of the primary key

attribute(s) of the entities that participate inthe relationship into the new relation, to act asforeign keys. These foreign keys will also formthe primary key of the new relation, possibly incombination with some of the attributes of therelationship.




116/132

CT

(8) Complex relationship types

Create a relation to represent the relationshipand include any attributes that are part of therelationship. Post a copy of the primary keyattribute(s) of the entities that participate in

the complex relationship into the new relation,to act as foreign keys. Any foreign keys thatrepresent a many relationship (for example,1..*, 0..*) generally will also form the primarykey of this new relation, possibly incombination with some of the attributes of therelationship.




117/132

CT

(9) Multi-valued attributes

Create a new relation to represent multi-valued attribute and include primary key ofentity in new relation, to act as a foreign key.Unless the multi-valued attribute is itself an

alternate key of the entity, the primary key ofthe new relation is the combination of themulti-valued attribute and the primary key ofthe entity.


Summary of how to map entitiesand relationships to relations


118/132

CT118 Pearson Education 2009

Relations for the Staff user views ofDreamHome


119/132


Step 2.2 Validate relations usingnormalization


120/132

CT

To validate the relations in the logical data

model using normalization.


Step 2.3 Validate relations againstuser transactions


121/132

CT

To ensure that the relations in the logical

data model support the requiredtransactions.


Step 2.4 Check integrityconstraints


122/132

CT

To check integrity constraints are

represented in the logical data model.This includes identifying: Required data Attribute domain constraints

Multiplicity Entity integrity Referential integrity General constraints


Referential integrity constraints forDreamHome


123/132

CT123Pearson Education 2009

Step 2.5 Review logical data modelwith user


124/132

CT

To review the logical data model with the

users to ensure that they consider themodel to be a true representation of thedata requirements of the enterprise.


Step 2.6 Merge logical data modelsinto global Model (optional step)


125/132

CT

To merge logical data models into a single

global logical data model that representsall user views of a database.


Step 2.6.1 Merge local logical datamodels into global model


126/132

CT

To merge local logical data model into a

single global logical data model.

This activities in this step include: Step 2.6.1 Merge local logical data models into

global model Step 2.6.2 Validate global logical data model Step 2.6.3 Review global logical data model

with users.


Step 2.6.1 Merge logical datamodels into a global model


127/132

CT

Tasks typically includes: (1) Review the names and contents of entities/relations and their

candidate keys. (2) Review the names and contents of relationships/foreign keys. (3) Merge entities/relations from the local data models (4) Include (without merging) entities/relations unique to each

local data model (5) Merge relationships/foreign keys from the local data models. (6) Include (without merging) relationships/foreign keys unique to

each local data model. (7) Check for missing entities/relations and relationships/foreign

keys. (8) Check foreign keys. (9) Check Integrity Constraints. (10) Draw the global ER/relation diagram (11) Update the documentation.


Step 2.6.2 Validate global logicaldata model


128/132

CT

To validate the relations created from the

global logical data model using thetechnique of normalization and to ensurethey support the required transactions, ifnecessary.


Step 2.6.3 Review global logicaldata model with users


129/132

CT

To review the global logical data model

with the users to ensure that theyconsider the model to be a truerepresentation of the data requirements ofan enterprise.


Relations for the Branch user viewsof DreamHome


130/132


Relations that represent the globallogical data model for DreamHome


131/132


Global relation diagram forDreamHome


132/132

BIM Modelleren ER 1213 v01

Documents

Transcript of BIM Modelleren ER 1213 v01