Zawansowane Modelowanie i Analiza Systemów Informatycznych

(1)

Zawansowane Modelowanie i Analiza Systemów

Informatycznych

(l- 4)

Polsko-Japońska Wyższa Szkoła Technik Komputerowych

Katedra Systemów Informacyjnych 2012

(2)

Overwiev

• The CSDP steps 4-6 ,

NOTE !!!!

This lecture covers LOTS of material – students’

study will be necessary!!!!

(3)

The 7 steps of CSDP

Step 1: transform familiar information examples into elementary facts, and apply quality checks

Step 2: draw the fact types, and apply a population check

Step 3: check for entity types that should be combined, and note any arithmetic derivations

Step 4: add uniqueness constraints, arity of fact types, splitting of fact types.

Step 5: add mandatory role constraints, and check for logical derivations

Step 6: add value, set comparison and subtyping constraints Step 7: add other constraints and perform final quality checks

(e.g., populating fact type instances)

(4)

Step 4 -Uniqueness constraints across several fact types

A room is identified by Campus, Building, Level, Room number

Example:

(Gardens, A, 3, 11)

Room

is nr has nr

Number (NO)

Room#

is on level

Level

level holds

Floor (FLOOR#)

has

room is in bld

Building (BLD#)

Block

Campus (C_NAME)

Campus_location

is on campus U

(5)

Uniqueness constraints across several fact types ‘Tennis Tournaments’

M-id Tour Lev Win Los 001 Wi Q A H 002 Wi Q B G 003 Wi Q C F 004 Wi Q D E 005 Wi S A D 006 Wi S B C 007 Wi F A B 008 AO Q B D 009 AO S D J ...

U

Match (M-id)

{F, S, Q}

Level (Lev-id)

Player (Pl_id)

Tournam

(T-symbol)

was in

Winner won lost Loser

held in tour

match_level

F – final, S –semi-final, Q- quarter-final

(6)

Hierarchical Structures for entity type

identification

CITY_

NAME City_Id

is id has id

City

Suburb_Called

SUBURB_

NAME

for called

In_City

has in

U

Suburb

STREET_

NAME Street_Called

called for

In_Suburb

has

in U

Street House

House_Called

HOUSE#

called for

In_Street

has in

U

(7)

The distinction between entity types and label types:

The distinguishing characteristic of a label type is that it is involved in ONLY ONE ROLE

Number INTEGER

_LABELS

r1 r2 r3

r4' r4

Illustration:

Number may be involved in many roles (r1, r2, r3, r4) and so is an entity

type, whereas INTEGER is and will only ever be involved in one role r4'.

(8)

The following diagram is

syntactically incorrect

^Company

NAME

Department

r1 r2

NAME is involved in two roles.

Would the following declarations shown below be correct?

Company

Name

Department

r1 r2

NAME_

STRING

(9)

Valid situations for

UCons in declaration of

label types

^Company ^NAME

Company NAME

In the following situations NAME has to be an entity type, not a label type:

Company Name

Incorrect schema

(10)

TYPES AND INSTANCES

The failure of drawing the distinction between an entity type and an

instance of an entity type is a common mistake.

Factory

Despatch (BLD#)

Reception (BLD#) Max_level

Max_level

found in found

in

found in

has

(BLD#)

(DECIBEL)Noise_level

Example:

Factory, Despatch and Reception are instances of an entity type.

The fact type Max_level occurs several times.

The correct schema should be:

Max_level

found

in has

Noise_level (DECIBEL)

Location (BLD#)

(11)

Let us consider a more complex example for UCons construction – remember the close relationship between the step 1 of the CSDP and configurations of Ucons.

Example 1

Departments

_Department _Building Head of Dept

Accounts B B Counter

Accounts C B Counter

Economics D G N Product

Computing B A L Gorithm

(D_NAME)Dept Building

(B_CODE) Manager (M_NAME)

in bld/

has mgr

has ept/

with mgr

manages /in bld

Depts_mgrs

Notice the redundancy in this output report in all columns!!!

The schema is incorrect!

(12)

The output report should be modelled as follows:

(D_NAME)Dept

Building (B_CODE)

Manager (M_NAME)

Accounts B Counter Economics G N Product Computing A L Gorithm

Accounts B Accounts C Economics D Computing B

managed

by manages located

in houses

Location

HoD

The above schema containing 2 elementary fact types (with shown UCons) correctly represents the UoD illustrated by the output report.

In

this example, Dept, Building, and Manager are not all

semantically related together.

Dept is associated with Building, and INDEPENDENTLY

Dept is also associated with Manager.

Manager is ‘partially’ dependent on the pair (Dept, Building)

Shall we add one more Ucon for the fact type HoD?

(13)

Determine the length of elementary fact types:

4A: perform reducibility check, and if necessary, correct the conceptual schema diagram; the fact type was too ‘long’.

4B: perform information loss check. Bring all the information of the output

report into facts permitted by the conceptual schema and check that the

original reports can be reconstructed without loss of information; the fact

type was too restrictive.

(14)

Example 2

Project Needs

Splitting of this ternary fact type into two binary ones (on Project)

C1 P1 A1

C1 P1 A2

C2 P1 A2

C2 P2 A2

supplies receives is supply

Article (A_CODE) Project

(PROJ#) Company

(C_NAME)

C1 P1

C2 P1

C2 P2

P1 A1

P1 A2

P2 A2

In this example,

Company, Project,

and Article are inter-

related.

(15)

Grouping of two binary fact types.

(C_NAME)

C1 P1

C2 P1

C2 P2

P1 A1

P1 A2

P2 A2

Project (PROJ#) Company

(C_NAME)

Article (A_CODE)

C1 P1 A1

C1 P1 A2

C2 P1 A1

C2 P1 A2

C2 P2 A2

Non-fact

Conclusion:

The ternary fact type CANNOT be split in the manner tried. Further splits should be tried: see next

C1 P1 A1 C1 P1 A2 C2 P1 A2 C2 P2 A2

After Join:

(16)

Split on Article.

Project (Proj#) Article

(A_code) Company

(C_NAME)

C1 A1

C1 A2

C2 A2

A1 P1 A2 P1 A2 P1 A2 P2

(C_NAME)

C1 P1 A1

C1 P1 A2

C1 P2 A2

C2 P1 A2

C2 P2 A2

Non-fact

Conclusion:

Again, the ternary fact type CANNOT be split in the manner tried. Further splits should be tried: see next..

C1 P1 A1 C1 P1 A2 C2 P1 A2 C2 P2 A2

After Join:

(17)

Another split, on Company.

Article (A_CODE) Company

(C_name) Project

(Proj#)

P1 C1

P1 C2

P2 C2

C1 A1

C1 A2

C2 A2

(C_NAME)

C1 P1 A1

C1 P1 A2

C2 P1 A2

C2 P2 A2

Join Produces original population

Conclusion :

The ternary fact type CAN be split in the manner tried. No further splits should be tried in this case BUT WE MUST BE SURE about the data

representativenes used for the splits

C1 P1 A1 C1 P1 A2 C2 P1 A2 C2 P2 A2

After Join:

(18)

Example 3:

Dealers

Smith Ford car

Smith Ford truck

Smith Nissan car Smith Nissan truck Jones Ford car Dealer

(D_NAME) Manufact

(M_NAME) Veh_Type

(V_CODE)

Split and join

(on manufacturer)

Dealer

(D_NAME) Manufact

(M_NAME)

Veh_Type (V_CODE)

Smith Ford Smith Ford Smith Nissan Smith Nissan Jones Ford

Ford car

Ford truck

Nissan car Nissan truck

Ford car

After join:

Smith Ford car Smith Ford truck Smith Nissan car Smith Nissan truck Jones Ford car Jones Ford truck

N on -f ac t

A non-fact has been generated.

Therefore, this split is not correct!

(19)

Consider another splitting possibility (there is a third one):

Dealer (D_NAME) Manufact

(M_NAME)

Veh_Type (V_CODE)

Ford Smith Ford Smith Nissan Smith Nissan Smith Ford Jones

Smith car Smith truck Smith car Smith truck Jones car

Join the two data samples:

Smith Ford car Smith Ford truck Smith Nissan car Smith Nissan truck Jones Ford car

The original significant population has been recovered.

Therefore, the ternary is splittable

on Dealer. This is an important result

Redundancy is eliminated.

(20)

Supplier

(SNAME) Type.of.Serv

(TS)

Customer (CNAME)

gives_service is_supplied receives

ABC Ltd Mowing Green Tow

ABC Ltd Pool maint Waterford

Better Staff Mowing Green Tow

Better Staff Mowing Light Plaza Better Staff Windows Light Plaza

Care4U Mowing Light Plaza

Projections

ST (Supplier – Type of service)

SC

TC

ABC Ltd Mowing ABC Ltd Pool maint Better Staff Mowing Better Staff Mowing Better Staff Windows

Care4U Mowing

ABC Ltd Green Tow ABC Ltd Waterford Better Staff Green Tow Better Staff Light Plaza Better Staff Light Plaza Care4U Light Plaza

Mowing Green Tow Pool maint Waterford Mowing Green Tow Mowing Light Plaza Windows Light Plaza Mowing Light Plaza

Theoretically ALL COMBINATIONS should be tried before jumping to a conclusion:

1. (s,t) join (t,c), (split on t)

2. (s,t) join (s,c) (split on s) and 3. (t,c) join (s,c) (split on c)

Before attempting the three way join 4. (s,t) join (t,c) join (s,c).

Example 4:

Services

(21)

ST Join SC:

ABC Ltd Mowing Green Tow ABC Ltd Mowing Waterford ABC Ltd Pool maint Green Tow ABC Ltd Pool maint Waterford Better Staff Mowing Green Tow Better Staff Mowing Light Plaza Better Staff Windows Green Tow Better Staff Windows Light Plaza Care4U Mowing Light Plaza

(ST Join SC) Join TC:

ABC Ltd Mowing Green Towers ABC Ltd Pool maint Waterford Better Staff Mowing Green Towers Better Staff Mowing Light Plaza Better Staff Windows Light Plaza Care4U Mowing Light Plaza

Original table

The original population is recovered from the three binary fact types. The correct schema is shown below to

replace the 3-ary fact type on slide 20.

supplied uses to offered

by gives supplies buys

Supplier from

(SNAME)

Type.of.Serv (TS)

Customer (CNAME)

Joins of any two tables differ from the original output report .

(22)

IMPORTANT OBSERVATIONS!!!!

Even though an n-ary fact type should have a uniqueness

constraint spanning at least n-1 roles it may be splittable into several smaller fact types.

All possible splits have to be considered before a fact type can

be considered unsplittable. In practice the analysis should be

simplified by designer understanding of terms and relatioships

in the considered UoD.

(23)

Advices and summary for beginners:

1. You only model semantically inter-related entities (N>= 3) as ternary or higher order fact types;

2. Refine your model by the splitability check;

3. In real life UoDs we might have higher order fact types present.

So we should be able to identify them;

4. Nested FT is useful when it participates in another non-nested

FT(s). Otherwise there is no need to use it. So, use nesting with

care!

(24)

Step 5 - Add mandatory role constraint – (each instance of an entity MUST participate in the role)

Example : Each lecturer must conduct teaching and research.

A student is either enrolling in subjects or on-leave.

student (student#)

leave

(leave-id)

subject (sub-ode)

lecturer (name)

publication (publication-id)

taketaken Performed-byconduct

enrol- in

taken- by

lecture d-by

lecture

enrolment teaching

On-leave research

(25)

Step 5 (con’t)

2. Add cardinality entity/label constraints.

Entity constraint: No. of students is less than or equal to one thousand.

Label constraint: Valid subject codes are between ITB001 and ITN555.

student (student#)

leave (leave-id)

subject (sub-code)

lecturer (name)

enrol- in

taken- by

lecture d-by

lecture

On-leave research

Count(student)

<= 1000 Sub-code:[ITB001..ITN555]

(26)

Step 5 (con’t)

3. Add role constraints.

Role constraint: Only subjects with subject-codes between ITB001 and ITB999 can be taken by students.

student (student#)

leave (leave-id)

subject (sub-code)

lecturer (name)

publication (publication-id

)

enrol- in

taken- by

Lectu- red-by

lecture

On-leave Research

Count(student)

<= 1000

Sub-code:[ITB001..ITN555]

Sub-code:

[ITB001..ITB999]

(27)

Step 5 (con’t)

4. Check logical derivation.

The total-enrolment fact type can be derived from other facts:

Therefore, total-enrolment should be removed at Step 5!

student (student#

)

leave

(leave-id)

subject (sub-code)

lecturer (name)

enrol- in

taken- by

lecture d-by

lecture

On-leave Research

current-enrol (number)

Has-no- enrolledIs-no-enrol

Total-enrolment Count(student)

<= 1000 Sub-code:

[ITB001..ITB999]

Sub-code:[ITB001..ITN555]

CREATE VIEW total- enrolment (subject- code, student#) AS SELECT subject-code, count(*)

FROM enrolment GROUP BY subject- code

(28)

Step 5 (con’t)

Is the TEACH fact type logically derived from the the teaching fact type and enrolment fact types?

Answer: Yes. So, it should be deleted from the conceptual schema.

However, if a supervision relationship (e.g. thesis supervision) exists independent of normal teaching (course-work) relationship, a thesis- supervision fact type may be added.

teaching

student

(student-no) subject

(subject-code)

lecturer (name) enroll-

in

taken- by

lecture d-by

lecture

enrolment

supervi sed-by

take- care-of

teach

?? ??

02244556 ITB220 02244557 ITB106

ITB220 P. Brown ITB106 J. Reye

(29)

Equality constraint - SET EQUALITY

The set of entity instances involved in one role is exactly the same as a set of the entity instances involved in a second role.

=

sells in used

by

has car

rep by

Car_

Use

Sales_

Territory Salesrep

(REP#) Car

(REG#)

Area (AREA#)

{R1, R2, R3, R4, R5, R6}

R1 R2 R3 R4 R1

R2 R3 R4

Example

R4

Step 6 - Set Constraints

(30)

Subset constraint

The set of entity instances involved in one role is a subset of the entity instances involved in a second role.

has is

on

Budget_

Allocation Project_

Worker

is

$pa

Project

(PROJ#) Employee

(EMP#) Budget

($)

{P1, P2, P3, P4, P5}

P1 P2 P3

P1 P1 P2 P2 P2

has

$pa

⊇

Each Project that can employ workers must have a budget; some of these project can have no a worker allocated yet, but other projects can have many workers allocated.

Set Constraints

(31)

Exclusion constraint If an entity instance is involved in one role

it is excluded from involvement in another role.

Manager

Worker

has

Dept

(DEPT#) Employee

(EMP#)

has mgr

in mgr

of {E1, E2, E3, E4}

E1

E2 E3

X

Set Constraints

(32)

Multiple-role Equality

constraint The set of combinations of entity instances of two or more entity types involved in two fact types are exactly the same.

Lecturer (Lct_name)

is run

co- ordinates

STAFF ALLOCATION

during

=

STUDENT ENROLMENT

in is

enrolled

Subject (U_code)

Student (St#)

Semester (YY/sem)

during

Example 12

Set Constraints

(33)

Multiple-role Subset

constraint The sets of combinations of entity instances of the same entities involved in two fact types are in a inclusion relationship .

Example 13:

has is

on

Project Leadership

Project_

Worker

is

run by Is the leader

Project

(PROJ#) Employee

(EMP#)

⊆

Set Constraints

(34)

Multiple-role

Exclusion constraint The sets of combinations of entity

instances of the same entities involved in two fact types are in an exclusion

relationship.

Example 14:

Property Ownership

Owns

Person (Pers_Id)

Property (Prop_addres)

Wants to

buy Intended

Purchase

X

Set Constraints

(35)

X

General definitions (more formal)

Consider two Fact Types F and F’ that have subsets of their roles

R = {R

^k1

, R

^{k2, …,}

R

^km

} and R’ = {R’

^h1

, R’

^{h2, …,}

R’

^hm

}

where in each pair of corresponding roles R^ki and R’^hi (i=1..m) are defined on the same entity type. We say that these sets of roles satisfy a set constraint, if the

population of any instance of the fact type F restricted to the set R of roles , pop(R), is involved in the same set_relationship with the population of F’ restricted to R’,

pop(R’). In particular;

Fact types F and F’ satisfy equality constraint on R and R’ if for any instance of the UoD pop(R) = pop(R’)

Fact types F and F’ are involved in the subset constraint on R and R’ if for any instance of the UoD pop(R) ⊆ pop(R’)

Fact types F and F’ are involved in the exclusion constraint on R and R’ if for any instance of the UoD pop(R) ∩ pop(R’) = ∅ (are disjoint)

X

=

⊆

(36)

Example to illustrate complex configurations of constraints.

The first purpose of the presented example is to show how the set constraints could be identified from the rules valid in a larger domain. The other purpose is to identify a possibly complete set of constraints that will guarantee the consistency of data with the rules that must be enforced in the particular domain. The example is concerned with the UOD ‘Tennis tournaments’. For simplicity we consider only data from one year and we introduce limitation to cover only events from one stream (say men singles) and from quarter-finals upwards.

The rules of any tournament organisation are well known. Two players play a match and the winner advances to the next level. No other players than winners in Quarter-final and Semi-finals, can play in Semi-finals and Final of a given tournament respectively. To check if the set of constraints on the schema is sufficient to enforce consistency of data with the rules of the UoD, we may introduce an amendement of the output report by some corrupted data that violate UOD rules but satisfy constraints that are introduced so far. We will identify the constraint(s) that could prevent presence of such data.

The abbreviations used are;

Q, S, F (in the column Lev(el)) – Quarter-final, Semi-final, Final

A, B, C, ….(in the columns Win(ner), Los(er)) – Synonyms for Player Ids

Wi, AO – examples of tornament shortened names (Wimbledon, Australia Open)

(37)

Tennis Tournaments

Tour Lev Win Los Wi Q A H Wi Q B G Wi Q C F Wi Q D E Wi S A D Wi S B C Wi F A B AO Q B D AO S D J

For simplicity, label types are omitted here.

1. During any tournament one can be defeated only once

2. During any tournament one can win only once in any stage (Q,S,F)

Match

Tournament Player Level

wins with loses to

Is the exclusion constraints valid for this UoD?

Obviously NOT.

x

Set Constraints –Example

(38)

Match Tennis Tournaments

Tour Lev Win Los Wi Q A H Wi Q B G Wi Q C F Wi Q D E Wi S A D Wi S B C Wi F A B Ao Q B D Ao S D J

...

During no stage (Q,S,F) of a tournament one can win a match and lose another match.

Wi A Q Wi B Q Wi C Q Wi D Q

...

Wi H Q Wi G Q Wi F Q Wi E Q

...

Tournament Player Level

wins with loses to

x

IT is because above projections of any sample data are disjoint.

(39)

Match

Tournament Player Level

wins with loses to

Tennis Tournaments

x

Note, that the above constraints are valid also for data which do not satsfy ‘tournament rules”. The

compromised data (in green) still satisfy the constraints but they show that it is still possible for the losers in Q to win in S and/or in F. Also, it is not prevented to have other players at the higher stages. The constraints on the diagram do not enforce tournament logistics.

Tour Lev Win Los

Wi Q A H

Wi Q B G

Wi Q C F

Wi Q D E

Wi S E D

Wi S F C

Wi F G K

Ao Q B D

Ao S D J

...

(40)

To guarantee, that only winners from Q-finals will advance to S-finals and this will be enforced by our Schema, we have to separate

QF- matches and SF- matches

Now it is easy to incorporate

in the schema two inclusion constraints, one for winners

in S-finals and one for losers in S-finals.

All of them are winners in Q-finals

Note that the fortnary fact type has been transformed into ternary fact types and the uniqueness and exclusion constraints have been modified accordingly .

⊆ ⊆

x

wins in S loses in S

SF-matches

Tournament Player

wins in Q loses in Q

x

QF-matches

(41)

Next we have to ensure that only winners from S-finals advance to Finals.

The relevant Fact Types on the

schema differ from the one for Q- or S-finals, since there is only one

winner and one loser in Finals of each tournament (*)

Now, we incorporate an exclusion constraint

...and two inclusion constraints, one for winner in Finals and one for losers in Finals

wins in Q loses in Q

x

wins in S loses in S

x

⊆⊆

SF-matches

QF-matches

⊆

x

⊆

wins in F

loses in F

(*) Note that one could try to set a ternary fact type for finals, but in this case the uniquenes constraint could be on only one role - for

Tournament, and that ternary fact type had to be split

(42)

The requirement: ONLY all winners from lower stage have advanced to the next stage is not supported

The above ‘corrupted’ data satisfy all constraints shown currently on the conceptual schema.

And the medicine is …… ^{wins in Q} ^{loses in Q}

x

wins in S loses in S

x

⊆⊆

SF-matches

QF-matches

wins in F

loses in F

x

⊆⊆

Tour Lev Win Los Wi Q A H Wi Q B G Wi Q C F Wi Q D E Wi Q X Z WI Q Y W Wi S A D Wi S B C Wi S X Y Wi F A B

Still… some constraints are missing

(43)

• The need for subtyping

• Method of construction

– Entity-Role matrix

• Subtype notation

Step 6 cont - Subtype construction

(44)

Consider the

following output report:

Article Code Colour Price Size Neck

Dress Skirt Shirt Shirt

134-6 214-5 712-0 615-8

547-2 White

White Red Red Yellow

50.00 45.00 34.95 50.00 25.00

12 14 12

90 85 Dress

-

Shirt 615-9 White 25.00 90

- - -

- -

The conceptual schema diagram

Money ($)

type (string)

Article (CODE)

Colour (C_NAME)

Size

(SIZE_CODE) Measure

(CM)

is cost of costs

is colour of

is of kind

is kind of

fitting size

is fitting

size

has neck size is neck

size

Style Price

Fitting

Size Article_type

is neck

size has

colour

(45)

From the output report it is evident that shirts have a neck size and skirts and dresses have a fitting size.

Therefore, although we are concerned with one type of thing, article of clothing, there are variations in the UoD.

Article Ladies Shirts

This is shown as follows:

Money ($)

Type (string) Article

(CODE)

Colour (C_NAME)

Measure (CM)

is

cost of costs

is colour

of

has colour

is of

kind is kind of

has neck

size is neck

size

Style Price

Size

Article_type

Size (SIZE_CODE)

fitting size

is fitting

size

Fitting

Ladies Shirts

(46)

Supertype: contains the entity type name, and facts giving entity instance identification and subtype categorisation information.

Subtype: contains the name of the subtype and the facts that relate only to that subtype.

The supertype is involved in facts which are to be recorded

about every instance of the entity type (total role). The

subtype is involved in facts which are to be recorded about

every instance of that particular subtype, and no other

(47)

General subtype characteristics

Supertype name

Subtype 1 name

Entity subtype categorisation

Entity instance identification

Facts involved in every instance

of the entity type.

Facts recorded only for Subtype 1.

Facts recorded only for Subtype 2.

Facts recorded only for Subtype 3.

Facts recorded only for Subtype 4.

(48)

Entity/Role Matrix

1. Record all roles related to an entity type as columns in the matrix.

2. Record each instance of the entity type as a row in the matrix.

3. For each instance, if it participates in a role (i.e. it has a particular property), put ‘x’ in the corresponding cell; otherwise leave blank.

4. Remove repeating rows.

5. Mark columns (roles) with the same pattern of values ‘x’/blank in constructed matrix, and assign to each such pattern an entity sub- type name.

6. In general, an entity type Y is a sub-type of entity type Z iff for each row where Y =‘x’, Z = ‘x’.

7. Draw the sub-type graph and delete any transitively implied arcs.

(49)

Article Code Colour Price Size Neck Dress

Skirt Shirt Shirt

134-6 214-5 712-0 615-8

547-2 White

White Red Red Yellow

50.00 45.00 34.95 50.00 25.00

12 14 12

90 85 Dress

-

Shirt 615-9 White 25.00 90

- - -

- -

X X X X X X

X X X - - - X

X X X X X X

X X X X X

X X X X X X

- - - X X X

X X

X - X

X X

X

- X

A B C

Example (cont)

(50)

In general -

If for every cross in the column representing a set Y there exists a cross in the same rows in a column representing the set Z, then we say that there is a subtype relationship between Y and Z, more precisely: Y is a subtype of Z (notation: YZ).

x x x x x x x x x x Y Z

Y is a subtype of Z.

Y Z

Each cross in column Y has a coresponding cross on the same level in the Z column

x x x

x x x x x x x x Y Z

Y is not a subtype of Z.

Z is not a subtype of Y

The cross in the second row in column Y has no a

coresponding cross on the same level in the column Z.

Crosses in the fifth and sixth row in the column C have no corresponding crosses in the column Y

(51)

ZMA-4

X X

X - X

X X

X

- X

A B C Example (cont)

The subtype relationships are:

B  A and C A

A

B C

(52)

Example

r1 r1 r2 r2 r3 r3 r4 r4 r5 r5 r6 r6 r7 r7 r8 r8 r9 r9 r10 r10 x x x x x x x x

x x x x x x x x

x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x

x x x x x x

Role/

Instance

1

2

3

4 5 6

Processing of the object role matrix

(53)

Example

r1 r1 r2 r2 r3 r3 r4 r4 r5 r5 r6 r6 r7 r7 r8 r8 r9 r9 r10 r10 x x x x x x x x

x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x

x x x x x x

Role/

Group

(Instance 1&2) 1

2

3

4 5