Higher-order entity-relationship modelling language, co-design and ...
07.03.2014 • Views
Share Embed Flag

Higher-order entity-relationship modelling language, co-design and ...

Higher-order entity-relationship modelling language, co-design and ...

Higher-order entity-relationship modelling language, co-design and ...

SHOW MORE
SHOW LESS
ePAPER READ
DOWNLOAD ePAPER
is.informatik.uni.kiel.de

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

START NOW

The Extended Entity-Relationship Modelling<br />

Language HERM<br />

Eötvös Loránd University of Sciences<br />

Budapest<br />

3.7.2012<br />

Bernhard Thalheim<br />

Technologie der Informationssysteme<br />

Institut für Informatik, Christian-Albrechts-Universität zu Kiel, BRD<br />

Kolmogorow-Professor e.h. der Lomonossow-Universität Moskau

My Background<br />

HERM ’bible’ H<strong>and</strong>book<br />

Dependencies<br />

Practical<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Database<br />

Design<br />

Methodologies.<br />

Kuwait University<br />

Press, 1989<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

ADBIS ASM CM EJC e-Bus. ER<br />

FoIKS MFDBS NLDB Semantics WIS WISE<br />

Content<br />

Information<br />

Concept<br />

Topic<br />

i.e., reaching the big triple ”3”s (3, 30, 300)<br />

(3 (habilitation students, profs, books), 30 (PhD students, editorials, projects),<br />

300 (master/diploma students, papers, presentations))

Instead of a Personal Profile: General<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

Concept<br />

Topic

Instead of a Personal Profile: My Co-Authors<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

Concept<br />

Topic

Instead of a Personal Profile: Most Cited Papers (h ≥ 25)<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

Concept<br />

Topic

Language Matters<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Global versus local: Petri nets as a local representation<br />

pitfalls in Michael Jackson’s crossroad example<br />

State-oriented versus event-oriented representation<br />

Conceptual <strong>co</strong>mpleteness of the <strong>language</strong><br />

Users, users, users are different in their (visual, oral, literacy) <strong>co</strong>mmunication<br />

skills, (visual, oral, literacy) <strong>co</strong>gnition <strong>and</strong> thus require<br />

different <strong>design</strong><br />

Hearer, speaker, archiver views<br />

Content<br />

Information<br />

Concept<br />

Topic

A Picture Might Replace a Full Subsection<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

The database aims in supporting lecture <strong>and</strong> <strong>co</strong>urse scheduling within a university<br />

application. A <strong>co</strong>urse is typically proposed. If the proposal be<strong>co</strong>mes accepted then<br />

the <strong>co</strong>urse is going to be planned. Typically planned <strong>co</strong>urse may be also held. The<br />

<strong>co</strong>urse proposal, planning <strong>and</strong> organisation is bound to a semester. Some university<br />

employees may be responsible for a <strong>co</strong>urse. Typically a <strong>co</strong>urse has one responsible<br />

person. Responsibilities may vary by semesters. Courses are taught by professors.<br />

Professors are specialisations of a person.<br />

Courses may be given for various programs. The proposal also includes the assignment<br />

of a <strong>co</strong>urse kind. The <strong>co</strong>urse proposal typically also requests for a room<br />

<strong>and</strong> for a time at which the <strong>co</strong>urse preferably <strong>co</strong>uld be given. Additionally time slots<br />

may be in <strong>co</strong>nflict with other proposals. Therefore, <strong>co</strong>nflicting time slots are given<br />

as well. The room <strong>and</strong> time preference may be overwritten during the planning<br />

phase. The same opportunity exists for proposals for the kind of the <strong>co</strong>urse to be<br />

given. If the time is assigned then typically a time slot is assigned. A <strong>co</strong>urse may<br />

have several non-overlapping time slots.<br />

The proposal for a <strong>co</strong>urse should be re<strong>co</strong>rded. A person may act in the role of<br />

somebody who inserted the <strong>co</strong>urse.<br />

Finally, <strong>co</strong>urses may also be held at a different location than originally planned.

Compare Visual Representation with<br />

Textual One<br />

✞<br />

☎<br />

Is this better to read for users of ER diagrams?<br />

✝<br />

✆<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Course Semester Professor ✲<br />

❦<br />

✻ ✒<br />

inserted<br />

✯<br />

✶<br />

Teacher<br />

Responsible4Course<br />

Person<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Program<br />

Kind<br />

✛<br />

✰<br />

✛<br />

{}<br />

Proposal<br />

[]<br />

proposed<br />

Course<br />

✻<br />

planned<br />

Course<br />

Time(Proposal,<br />

SideCondition)<br />

✛<br />

Request<br />

[]<br />

✲<br />

✯<br />

✻<br />

Course<br />

held<br />

Room<br />

[]<br />

Content<br />

TimeFrame<br />

Information<br />

For more information:<br />

http://www.is.informatik.uni-kiel.de/∼thalheim/slides.htm<br />

Concept<br />

Topic

Cognition Completeness<br />

✞<br />

☎<br />

Sapir-Whorf<br />

✝<br />

✆<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

“Principle of linguistic relativity”: actors skilled in a <strong>language</strong> may not have a<br />

(deep) underst<strong>and</strong>ing of some <strong>co</strong>ncepts of other <strong>language</strong>s.<br />

Six Lakoff schemata<br />

<strong>co</strong>ntainer schema (class-building, aggregating, <strong>co</strong>mposing)<br />

part-whole schema (specialisation/generalisation, categorisation,<br />

...)<br />

link schema (within many kinds)<br />

center-periphery schema (oil stain, ...)<br />

source-path-goal schema<br />

<strong>order</strong>ing schemata, e.g., up-down, front-back <strong>and</strong> linear <strong>order</strong>ing<br />

Content<br />

Information<br />

Concept<br />

Topic

Indoeuropean Languages <strong>and</strong> HERM<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

English sentence <strong>co</strong>ncept<br />

transitive verb<br />

<strong>co</strong>mmon noun<br />

adjective<br />

adverb<br />

numerical expression<br />

preposition<br />

gerund<br />

clause<br />

HERM feature<br />

<strong>relationship</strong> type<br />

<strong>co</strong>mponent of <strong>relationship</strong> type<br />

attribute of <strong>co</strong>mponent<br />

attribute of <strong>relationship</strong> type<br />

attribute of object type<br />

role name of <strong>co</strong>mponent<br />

<strong>relationship</strong> type that is <strong>co</strong>mponent of another <strong>relationship</strong><br />

type<br />

<strong>relationship</strong> type with <strong>co</strong>mponents<br />

<strong>co</strong>mplex sentence <strong>relationship</strong> type of <strong>order</strong> higher than 1<br />

alternative phrase<br />

plural <strong>co</strong>llection<br />

“IsA” sentence<br />

cluster type<br />

type/nested attribute<br />

specialisation<br />

Concept<br />

Topic

Comparison to Chen’s Original<br />

Correspondences<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Peter P.-S. Chen: English Sentence Structure <strong>and</strong> ER Diagrams, Inf.<br />

Sci. 29(2-3): 127-149, 1983<br />

English sentence <strong>co</strong>ncept<br />

transitive verb<br />

<strong>co</strong>mmon noun<br />

ER feature<br />

<strong>relationship</strong> type<br />

<strong>entity</strong> type<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

adjective<br />

adverb<br />

numerical expression<br />

gerund<br />

clause<br />

<strong>co</strong>mplex sentence<br />

attribute of <strong>entity</strong> type<br />

attribute of <strong>relationship</strong> type<br />

attribute of <strong>entity</strong> or <strong>relationship</strong> type<br />

<strong>relationship</strong>-<strong>co</strong>nverted <strong>entity</strong> type<br />

high-level <strong>entity</strong> type abstracted from group of inter<strong>co</strong>nnected lowlevel<br />

<strong>entity</strong> <strong>and</strong> <strong>relationship</strong> types<br />

one or more <strong>entity</strong> types <strong>co</strong>nnected by <strong>relationship</strong> type in which<br />

each <strong>entity</strong> type can be de<strong>co</strong>mposed recursively into low-level <strong>entity</strong><br />

types inter<strong>co</strong>nnected by <strong>relationship</strong> types<br />

Information<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

Conclusions for ERM versus HERM<br />

S. Hartmann <strong>and</strong> S. Link. English sentence structures <strong>and</strong> eer modeling.<br />

In APCCM, volume 67 of CRPIT, pages 2735. Australian<br />

Computer Society, 2007.<br />

EER reflects (English) sentence structures more soundly <strong>and</strong> naturally<br />

higher-<strong>order</strong> object types reflect dependence between sentences<br />

this provides justification for introduction of new ER features<br />

ER model does not just provide safe <strong>co</strong>nstructs that result in<br />

good database <strong>design</strong>, but also features that enable good <strong>co</strong>mmunication<br />

between <strong>design</strong>er <strong>and</strong> user<br />

essential to best approximate requirements<br />

additional EER features justified in the sense that <strong>modelling</strong> be<strong>co</strong>mes<br />

more natural<br />

provides also a justification why the EER features exist<br />

higher-<strong>order</strong> object types reminiscent of nested sentence structure<br />

in natural <strong>language</strong> text

Extended Entity-Relationship Models<br />

Syntax of the model<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

Structuring as <strong>co</strong>nsistent extension of the classical <strong>entity</strong><strong>relationship</strong><br />

model<br />

Behavior specification on the basis of generic operations forming<br />

the algebra <strong>and</strong> on the basis of ASM semantics<br />

Interacting of users with the information engine on the basis of<br />

their specific s<strong>co</strong>pe on the database<br />

Environment: technical <strong>co</strong>ntext, organizational <strong>co</strong>ntext, distribution<br />

Views, <strong>co</strong>ntainers for delivery of information to the user <strong>and</strong> for<br />

accepting information from the user<br />

Semantics via hierarchical predicate logics<br />

can be extended by pragmatics (variety of semantics)<br />

Pragmatism based on the <strong>co</strong><strong>design</strong> methodology

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Type Constructor<br />

with a selector for retrieval (like Select) with a retrieval expression<br />

<strong>and</strong> update functions (like Insert, Delete, <strong>and</strong> Update) for value<br />

mapping from the new type to the <strong>co</strong>mponent types or to the new<br />

type,<br />

with <strong>co</strong>rrectness criteria <strong>and</strong> rules for validation,<br />

with default rules,<br />

with one or several user representations, <strong>and</strong><br />

with a physical representation or properties of the physical representation.<br />

Content<br />

Information<br />

Concept<br />

Topic

Structuring in HERM<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

Structuring - extension of the ER model<br />

strict set semantics (no pointer semantics)<br />

1. Complex attributes, <strong>entity</strong> , <strong>relationship</strong>, cluster types,<br />

types of higher <strong>order</strong>,<br />

hierarchical schemata for structuring<br />

2. Static integrity <strong>co</strong>nstraints<br />

Basic data types - parameterized types of the DBMS<br />

integer := (IntegerSet, {0, s, +, -, *, ÷, }, { =, ≤ })<br />

Attribute type induced on basic data type system<br />

Name : (FirstNames, FamName,<br />

[NameOfBirth,] Title:{AcadTitle} ∪ ·<br />

FamTitle)<br />

Contact : (Phone({AtWork}, private), email, ...)<br />

DateOfBirth :: date<br />

AcadTitel :: titleType<br />

Entity type - product of attribute types with at least one direct identification<br />

Person : (Name, Address, Contact, DateOfBirth,<br />

PersNo: StudNo ∪ ·<br />

EmplNo, ...)<br />

Concept<br />

Topic

Structuring in HERM<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Relationship type via hierarchical <strong>co</strong>nstruction<br />

unary type: Role, specialisation<br />

InGroup : (Person, Group,<br />

Time(From [,To]), Position)<br />

DirectPrerequsite : (hasPrerequsite: Course, isPrerequisite : Course)<br />

Professor : (Person, Specialization)<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

Cluster type - disjoint (labelled) union<br />

especially for generalization<br />

JuristPerson : Person ·<br />

∪ Company ·<br />

∪ Association<br />

Group : Senat ·<br />

∪ WorkingGroup ·<br />

∪ Association<br />

Constructors ×, ∪, {} <strong>co</strong>nstruction <strong>co</strong>mplete<br />

·<br />

usually: ×, ∪, < . >, {|.|}, P<br />

with underlying type system<br />

<strong>and</strong> generic operations<br />

plus <strong>co</strong>nstruction of operations through structural recursion

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Topic<br />

Content<br />

Information<br />

Student<br />

Professor<br />

einrolled<br />

in<br />

Course<br />

Room<br />

Semester<br />

Module<br />

direct<br />

prerequisite<br />

✛<br />

✛<br />

✯<br />

✰<br />

✾<br />

❄<br />

☛<br />

<br />

✶<br />

✻<br />

Student<br />

Professor<br />

enrolled<br />

in<br />

Course<br />

Room<br />

Semester<br />

Module<br />

direct<br />

prerequisite<br />

✛<br />

✛<br />

✯<br />

✰<br />

✾<br />

❄<br />

✲<br />

✻

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Reasons for <strong>Higher</strong>-Order Relationship<br />

Types<br />

they are naturally occurring<br />

awful integrity <strong>co</strong>nstraints otherwise<br />

schema <strong>co</strong>mplexity decreasing via <strong>co</strong>mpactification<br />

unary <strong>relationship</strong> types are sometime IsA-<strong>co</strong>nstraints<br />

unary <strong>relationship</strong> types with additional identification allow also<br />

general-special specialisation<br />

e.g., item list or book-<strong>co</strong>yp<br />

natural identification inheritance<br />

relational <strong>and</strong> network translation creates them anyway<br />

Content<br />

Information<br />

Concept<br />

Topic

Implicit Assumptions<br />

Set semantics: default semantics<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Identifiability: each <strong>entity</strong> type is identifiable<br />

Partial Unique Name Assumption: attribute names are unique<br />

Referential integrity<br />

Monotonicity of semantics: if Φ are added to Σ, then the set of possible<br />

instances which satisfy the extended set of <strong>co</strong>nstraints Σ ∪ Φ is a<br />

subset of the set of instances which satisfy Σ.<br />

Compositionality<br />

Destinction of define <strong>and</strong> use<br />

Content<br />

Information<br />

Concept<br />

Topic

A Sample Schema<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Course Semester Professor ✲<br />

✯<br />

Kind<br />

❦<br />

Program<br />

✛<br />

✰<br />

✛<br />

{}<br />

Proposal<br />

✻<br />

proposed<br />

Course<br />

✻<br />

planned<br />

Course<br />

Time(Proposal,<br />

SideCondition)<br />

TimeFrame<br />

✒<br />

Teacher<br />

✛<br />

Request<br />

inserted<br />

✲<br />

✯<br />

✻<br />

Course<br />

held<br />

✶<br />

Responsible4Course<br />

Room<br />

Person<br />

Content<br />

Information<br />

Concept<br />

Topic

Basic Data Types<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Precision <strong>and</strong> accuracy: precision is the degree of refinement in<br />

the calculations<br />

accuracy is a measure of how repeatable the assignment of values<br />

for properties is.<br />

Granularity: scales<br />

Ordering<br />

Classification<br />

Presentation<br />

Implementation<br />

Default values<br />

Casting functions<br />

Information<br />

Concept<br />

Topic

Data types <strong>and</strong> their main canonical<br />

assumptions<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Kind of data<br />

type<br />

extension based<br />

Natural<br />

<strong>order</strong><br />

Natural<br />

zero<br />

Predefined functions<br />

Example<br />

absolute + +/- +/- number of boxes<br />

ratio + +/- +(type dependent) length, weight<br />

intension based<br />

nominal - - (-) (except <strong>co</strong>ncatenation)<br />

names of cities<br />

ordinal + - - preferences<br />

rang + + - <strong>co</strong>mpetitions<br />

interval + - (+)(e.g., <strong>co</strong>ncatenation)<br />

time, space<br />

Content<br />

Information<br />

Concept<br />

Topic

Graphical Notions Might Vary<br />

Person<br />

Student<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Diplom student<br />

University employee<br />

Professor<br />

Project member<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Diplom<br />

student<br />

✲<br />

Student<br />

✲<br />

Person<br />

✻<br />

Content<br />

Information<br />

Project<br />

member<br />

✲<br />

University<br />

employee<br />

✛<br />

Professor<br />

Concept<br />

Topic

Unary Relationship Types<br />

Person<br />

Person<br />

Person<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

✻<br />

Professor<br />

✻<br />

Professor<br />

✻<br />

IsA<br />

Professor<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

Concept<br />

Topic

Generalising Cluster Types<br />

Examines.Enrolls.Course<br />

= Examines.GivenBy.Course<br />

Θ := Enrolls.Course Provides.Course<br />

Course ✛ GivenBy ✲<br />

Lecturer<br />

Course ✛ GivenBy ✲<br />

Lecturer<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

✻<br />

Enrolls<br />

✛<br />

✻<br />

Examines<br />

✻<br />

Enrolls<br />

✛<br />

Θ<br />

✻<br />

Examines<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

❄<br />

Student<br />

The simple HERM schema<br />

Enrolls ✲ Course ✛<br />

❄<br />

Student<br />

⊇<br />

The “optimized” <strong>co</strong>nceptual schema<br />

❄<br />

Student<br />

The sophisticated HERM schema<br />

The representational <strong>co</strong>nceptual schema<br />

GivenBy<br />

Student = ({ StudId, ... }, ...),<br />

Course = ({ CourseID,... }, ...),<br />

Lecturer = ({ LecturerID,... }, ...),<br />

Enrolls = ({ StudId, CourseID,... }, ...),<br />

Provides = ({ CourseID, LecturerID,... }, ...),<br />

Examines = ({ StudId, LecturerID, CourseID,... }, ...)<br />

✻<br />

⊆<br />

Examines[StudId, CourseID]<br />

❄<br />

⊆ Enrolls[StudId, CourseID]<br />

✛ Examines ✲ Lecturer Examines[CourseID, LecturerID]<br />

⊆ Provides[CourseID, Lecturer<br />

The logical relational schema<br />

The association between the “optimised” schema <strong>and</strong> the relational schema

Constraints in Brief<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Static integrity <strong>co</strong>nstraints are formulas of the hierarchical predicate<br />

logic (with abbreviations)<br />

in “normal definition frame” (may be deontic or strikt)<br />

Keys for identification of objects (esp. <strong>entity</strong> types)<br />

Key(Person) = { { PersNo }, { Name, DateOfBirht } }<br />

Relationship types with attributs<br />

Key(InGroup) = {{ Person, Group, Time }} (!?)<br />

Key’(InGroup) = {{ Person, Group, Time, Position }}<br />

Key(Lecture) = { { Course, Semester},<br />

{Semester, Room, Time }, {Semester, Teacher, Time}<br />

}<br />

Keys defined by the <strong>co</strong>mponent <strong>co</strong>nstruction<br />

Name(FirstNames, FamName)<br />

at least one key is ‘inherited’ from the <strong>co</strong>mponent<br />

Information<br />

Concept<br />

Topic

Constraints<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Functional dependencies for functional associations among groups of<br />

attributes<br />

plannedCourse : {Sem, Time, Room} → {{Program}, Prof, Course}<br />

plannedCourse : {Prof, Sem, Time} → {Course, Room}<br />

proposedCourse : {Semester, Course} → {Prof} (??)<br />

<strong>and</strong> other relational <strong>co</strong>nstraints<br />

e.g. Domain <strong>co</strong>nstraints<br />

Semester.Description ∈ {WS, SS} × {x/x +1|x ∈ 1980..99, 2000..03}<br />

Cardinality <strong>co</strong>nstraints are restrictions of <strong>co</strong>mbinatorics with<br />

(min,max)-notation<br />

card(DirectPrerequisite, hasPrerequisite) = (0,2)<br />

card(DirektVoraussetz, isPrequisite) = (3,4)<br />

not satisfiable<br />

card(plannedCourse, Course Sem Prof) = (0,3)<br />

Content<br />

card(proposedCourse, Sem Prof) = (3,5) (!??) or (0,5) (!!)<br />

Information<br />

Concept<br />

Topic

Classes <strong>and</strong> Instances<br />

Classes are sets of (markable) objects of <strong>co</strong>rresponding type<br />

Entity class is the basic class of objects<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

β: ((, Thalheim, {Prof., Dr.rer.nat.habil, Dipl.-Math.}), BTU<br />

Cottbus,<br />

(({ +49 355 692700, +49 355 692397}, +49 355 824054),<br />

thalheim@informatik.tu-<strong>co</strong>ttbus.de), 10.3.52, 637861)<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

(DBIV, Database theory, CS Programm , m<strong>and</strong>atory, 2+0+0, certificate)<br />

Relationship classes for association of objects of <strong>co</strong>mponent classes<br />

exp<strong>and</strong>ed by properties (through attributes)<br />

Profβ: ( 637861, Database <strong>and</strong> information systems )<br />

Senator3β: ( 637861, Senat, (1995,1998), Dekan)<br />

Senator5β: ( 637861, Senat, (2000), Chair)<br />

PrerequDBIVMain: (DBIV, DBI) ,<br />

Content<br />

Information<br />

Concept Topic<br />

...<br />

...<br />

CourseDBIVSS02: (DBIV, SS2002, 637861, SR1, Mo. first pair)

Classes <strong>and</strong> Instances<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Classes are sets of (markable) objects of <strong>co</strong>rresponding type<br />

....<br />

Cluster classes for disjoint (!), i.a. virtual union of objects of the<br />

<strong>co</strong>mponent classes<br />

{ Senator2π: ( 889721, Senat, (1998,2000), Chair),<br />

Senator5β: ( 637861, Senat, (2000), Chair),<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

DBIS: ( Database <strong>and</strong> information systems, 637861, IfI),<br />

CBnetβ: (CottbusNet e.V., 637861, Member, Services Group ) }<br />

Classes are extended by generic operations insert, delete, update,<br />

retrieve<br />

may have additional methods<br />

static integrity <strong>co</strong>nstraints must remain valid<br />

inherent integrity <strong>co</strong>nstraint: existence of <strong>co</strong>mponents<br />

Information<br />

Concept<br />

Topic

Representation <strong>and</strong><br />

Classes <strong>and</strong> Instances<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Storage<br />

possibly with weak value-based OID or label<br />

either as full objects (with all properties (XML)) or as<br />

class-separated object (similar to snowflakes) object-relational representation<br />

or<br />

hybrid<br />

Content<br />

Information<br />

Concept<br />

Topic

Constraints in Detail<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

see<br />

my theory lecture<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

Concept<br />

Topic

Null Markers instead of Null “Values”<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

state of the art: wide utilisation of misinterpretation of NULLs,<br />

wrong implementation support, <strong>co</strong>nfusing logics<br />

null marker logics<br />

C.J. Date (Logic <strong>and</strong> Databases - The roots of relational theory (2007), 117): “I apologize<br />

for the wording “<strong>co</strong>ntains a null”; as I’ve written elsewhere, to talk about anything<br />

“<strong>co</strong>ntaining a null” actually makes no logical sense. Indeed one of the problems with<br />

nulls is precisely that you ca‘’t talk about them sensibly! ... the entire topic is a perfect<br />

illustration of The Principle of In<strong>co</strong>herence ... ”<br />

(228): “... nulls are ipso facto nonsense ...<br />

E.F. Codd (The Relational Model for Data Management, Version 2 (1990), 172): The<br />

basic principle of the relational approach to missing information is that of re<strong>co</strong>rding the<br />

fact that a db-value is missing by means of a mark (originally called a null or null<br />

value). There is nothing imprecise about a mark: a db-value is either present or absent in<br />

a <strong>co</strong>lumn of a relation in the database.<br />

(197) ... the way the relational model deals with missing values appears to be one of its<br />

Content<br />

least understood part.<br />

Information<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Arithmetics with Null “Values”<br />

✞<br />

☎<br />

Missing theory resulted in <strong>co</strong>nfusing implementations<br />

✝<br />

✆<br />

be careful with proposal: CAST (NULL AS INTEGER)<br />

NULL<br />

0<br />

= ?<br />

CREATE TABLE Got Null (test INTEGER);<br />

INSERT INTO GotNullVALUES (NULL);<br />

CREATE TABLE GotOne (test INTEGER);<br />

INSERT INTO GotOne VALUES (1);<br />

CREATE TABLE GotZero (test INTEGER);<br />

INSERT INTO GotZero VALUES (0);<br />

SELECT test/0 FROM Got One | Got Zero | Got NULL<br />

Ingres NULL float point err no data float point err no data<br />

Oracle NULL divide by 0 err no data divide by 0 err no data<br />

Progress NULL NULL NULL<br />

R:BASE NULL divide by 0 err no data divide by 0 err no data<br />

Rdb<br />

truncation at runtime<br />

divide by 0<br />

truncation at runtime<br />

divide by 0<br />

truncation by runtime<br />

divide by 0<br />

SQL Server NULL NULL & error NULL & error<br />

SQL Base NULL plus infinity plus infinity<br />

Sybase NULL Null & error NULL & error<br />

WATCOMSQL NULL NULL NULL<br />

XDD NULL divide by 0 err no data divide by 0 err no data<br />

Information<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Problems with SQL NULL<br />

✞<br />

☎<br />

Overloading is a bad business: ad-hoc polymorphism<br />

✝<br />

✆<br />

semantically different aspects are represented in the same form<br />

Predicates with NULL<br />

SELECT *<br />

FROM Table<br />

WHERE Column = 2<br />

SELECT *<br />

FROM Table<br />

WHERE Column 2<br />

SELECT *<br />

FROM Table<br />

WHERE Column IS NULL<br />

SQL-92 decision IS [NOT] TRUE | FALSE | UNKNOWN<br />

e.g., z.B. ((Age

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Modelling Advices<br />

NOT NULL - wherever applicable<br />

NULLs need additional implementation effort, e.g. an extra bit<br />

NULLs require specific storage formats, indexes, search support<br />

in any case better: DEFAULT<br />

Usage of <strong>co</strong>nventions, e.g. ISO for gender<br />

0 - unknown; 1 - male; 2 - female; 9 - not applicable<br />

Special support for arithmetic functions: explicit assignment (unknown,<br />

not applicable (-1, ..., nonsense ... 0)<br />

NULLs are also used if domain types do not support special values<br />

extend the domain type<br />

Content<br />

Information<br />

Concept<br />

Topic

A Simplified But Almost Real Application<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

CREATE TABLE Student (<br />

MatriculationNo CHAR(6) <strong>co</strong>uld be NULL<br />

StudNo CHAR(6) our internalisation<br />

MainProgram VARCHAR(20) <strong>co</strong>uld be NULL,<br />

<strong>co</strong>uld be more than one<br />

Name VARCHAR(50) far too simple<br />

Se<strong>co</strong>ndaryProgram VARCHAR(20) might be more than one<br />

PRIMARY KEY<br />

(StudNo)<br />

FOREIGN KEY (MainProgram)<br />

... );<br />

CREATE TABLE Enroll (<br />

REFERENCES ProgramAtCAU (ProgName)<br />

ON DELETE RESTRICT<br />

StudNo CHAR(6) our internalisation<br />

Course<br />

Term<br />

CHAR(8)<br />

VarCHAR(7)<br />

EnrollmentCondition VARCHAR(10) full of beans<br />

Grade VARCHAR(3) that is a devils invention<br />

PRIMARY KEY (StudNo, Course, Term)<br />

... );<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

A Simplified But Almost Real Application<br />

CREATE TABLE Enroll (<br />

StudNo<br />

EnrollmentCondition<br />

Grade<br />

... );<br />

During <strong>co</strong>urse<br />

After <strong>co</strong>urse<br />

Special <strong>co</strong>ndition<br />

Diploma student<br />

never<br />

exists<br />

never<br />

exists<br />

not yet<br />

decided<br />

✞<br />

☎<br />

✝Who can h<strong>and</strong>le the mess? ✆<br />

CHAR(6)<br />

VARCHAR(10)<br />

VARCHAR(3)<br />

Certificate Diploma<br />

Graded Certificate Diploma<br />

Bachelor & Master<br />

not yet<br />

decided unknown unknown<br />

not<br />

exists known known<br />

not<br />

exists<br />

under<br />

change<br />

under<br />

change<br />

Guest Student<br />

not<br />

applicable<br />

not<br />

applicable<br />

potentially<br />

known<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

A Simplified But Almost Real Application<br />

CREATE TABLE Enroll (<br />

StudNo<br />

EnrollmentCondition<br />

Grade<br />

... );<br />

During <strong>co</strong>urse<br />

After <strong>co</strong>urse<br />

Special <strong>co</strong>ndition<br />

Diploma student<br />

never<br />

exists<br />

never<br />

exists<br />

not yet<br />

decided<br />

✞<br />

☎<br />

✝Who can h<strong>and</strong>le the mess? ✆<br />

CHAR(6)<br />

VARCHAR(10)<br />

VARCHAR(3)<br />

Certificate Diploma<br />

Graded Certificate Diploma<br />

Bachelor & Master<br />

not yet<br />

decided unknown unknown<br />

not<br />

exists known known<br />

not<br />

exists<br />

under<br />

change<br />

under<br />

change<br />

Guest Student<br />

not<br />

applicable<br />

not<br />

applicable<br />

potentially<br />

known<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

A Simplified But Almost Real Application<br />

CREATE TABLE Enroll (<br />

StudNo<br />

EnrollmentCondition<br />

Grade<br />

... );<br />

During <strong>co</strong>urse<br />

After <strong>co</strong>urse<br />

Special <strong>co</strong>ndition<br />

Diploma student<br />

never<br />

exists<br />

never<br />

exists<br />

not yet<br />

decided<br />

✞<br />

☎<br />

✝Who can h<strong>and</strong>le the mess? ✆<br />

CHAR(6)<br />

VARCHAR(10)<br />

VARCHAR(3)<br />

Certificate Diploma<br />

Graded Certificate Diploma<br />

Bachelor & Master<br />

not yet<br />

decided unknown unknown<br />

not<br />

exists known known<br />

not<br />

exists<br />

under<br />

change<br />

under<br />

change<br />

Guest Student<br />

not<br />

applicable<br />

not<br />

applicable<br />

potentially<br />

known<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

A Simplified But Almost Real Application<br />

CREATE TABLE Enroll (<br />

StudNo<br />

EnrollmentCondition<br />

Grade<br />

... );<br />

During <strong>co</strong>urse<br />

After <strong>co</strong>urse<br />

Special <strong>co</strong>ndition<br />

Diploma student<br />

never<br />

exists<br />

never<br />

exists<br />

not yet<br />

decided<br />

✞<br />

☎<br />

✝Who can h<strong>and</strong>le the mess? ✆<br />

CHAR(6)<br />

VARCHAR(10)<br />

VARCHAR(3)<br />

Certificate Diploma<br />

Graded Certificate Diploma<br />

Bachelor & Master<br />

not yet<br />

decided unknown unknown<br />

not<br />

exists known known<br />

not<br />

exists<br />

under<br />

change<br />

under<br />

change<br />

Guest Student<br />

not<br />

applicable<br />

not<br />

applicable<br />

potentially<br />

known<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

A Simplified But Almost Real Application<br />

CREATE TABLE Enroll (<br />

StudNo<br />

EnrollmentCondition<br />

Grade<br />

... );<br />

During <strong>co</strong>urse<br />

After <strong>co</strong>urse<br />

Special <strong>co</strong>ndition<br />

Diploma student<br />

never<br />

exists<br />

never<br />

exists<br />

not yet<br />

decided<br />

✞<br />

☎<br />

✝Who can h<strong>and</strong>le the mess? ✆<br />

CHAR(6)<br />

VARCHAR(10)<br />

VARCHAR(3)<br />

Certificate Diploma<br />

Graded Certificate Diploma<br />

Bachelor & Master<br />

not yet<br />

decided unknown unknown<br />

not<br />

exists known known<br />

not<br />

exists<br />

under<br />

change<br />

under<br />

change<br />

Guest Student<br />

not<br />

applicable<br />

not<br />

applicable<br />

potentially<br />

known<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

A Simplified But Almost Real Application<br />

CREATE TABLE Enroll (<br />

StudNo<br />

EnrollmentCondition<br />

Grade<br />

... );<br />

Diploma student<br />

✞<br />

☎<br />

✝Who can h<strong>and</strong>le the mess? ✆<br />

CHAR(6)<br />

VARCHAR(10)<br />

VARCHAR(3)<br />

Certificate Diploma<br />

Graded Certificate Diploma<br />

Bachelor & Master<br />

never<br />

During <strong>co</strong>urse exists<br />

not yet<br />

decided unknown unknown<br />

not<br />

applicable<br />

After <strong>co</strong>urse<br />

never<br />

exists<br />

not<br />

exists known known<br />

not<br />

applicable<br />

not yet<br />

Special <strong>co</strong>ndition decided<br />

not<br />

exists<br />

under<br />

change<br />

under<br />

change<br />

potentially<br />

known<br />

✞<br />

☎<br />

Practical solution: No programmer cares; let’s educate the user<br />

✝<br />

✆<br />

Guest Student

14 (or 20) Kinds of NULL ‘Values’ in<br />

Databases (1/2)<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

1. The property is not applicable for this object but belongs to this class of objects.<br />

1.1. Independently from the point of time t. “not applicable”<br />

1.2. At the current point of time t. “currently not applicable”<br />

2. The property does not belong to the object.<br />

2.1. The property is not representable in the schema.<br />

2.1.1. Due to changes of value type (temporarily, fuzzy, ...). “many-typed”<br />

2.2. The property is representable in the schema.<br />

2.2.1. But there is no value for the object. “unknown”<br />

2.2.1.1. Because it has not been transferred from another database.<br />

2.2.1.2. Because is has not yet inserted into the database. “existential null”<br />

2.2.2. The value for the property exists but is “under change”.<br />

2.2.2.1. However the value is trackable.<br />

2.2.2.1.1. But is at the moment forbidden.<br />

2.2.2.1.2. At the moment permitted.<br />

2.2.2.1.2.1. But not defined for the database.<br />

2.2.2.1.2.1.1. Because it is currently under change.<br />

2.2.2.1.2.2. The value is defined for the system.<br />

2.2.2.1.2.2.1. But is currently in<strong>co</strong>rrect.

14 (or 20) Kinds of NULL ‘Values’ in<br />

Databases (2/2)<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

2. The property does not belong to the object.<br />

2.2. The property is representable in the schema.<br />

2.2.2. The value for the property exists but is “under change”.<br />

2.2.2.2. The value is not trackable.<br />

2.2.2.2.1. Because of changes.<br />

2.2.2.2.2. Because of reachability. “place-holder null”<br />

2.2.3. There are several values for the property of this object. “partial null”<br />

(2.2.3.1., 2.2.3.2.1, 2.2.3.2.2. similarly to 2.2.2.) “nondeterministic”<br />

2.2.4. There is no value for the property of this object. “not exists”<br />

2.2.5. There is never a value for the property of this object. “never exists”<br />

3. The property is may-be applicable for this object but it unknown whether it is true for<br />

the object in this case.<br />

“may-be null”<br />

3.1. It is not known whether the property is applicable to the given object. If it is<br />

applicable then its value for this property is taken from certain domain. “partial<br />

may-be null”<br />

✞<br />

☎<br />

Who can reason with this variety?<br />

✝<br />

✆<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

NULL Marker Logics<br />

Dom(NULL) = { Unknown, NotApplicable,<br />

NotExists, NeverExists }<br />

Correspondence of the NULL domain <strong>and</strong> logical values<br />

x ∧ y 1 0<br />

1 1 0<br />

<br />

0 0 0<br />

NULL domain value<br />

Unknown<br />

NotApplicable<br />

Logical value for values<br />

unk<br />

∌<br />

NotExists ¬!<br />

NeverExists<br />

Observation: < 0 < 1<br />

<br />

x ∨ y 1 0<br />

1 1 1<br />

<br />

0 1 0<br />

¬<br />

0 1<br />

1 0<br />

<br />

Concept<br />

Topic

NULL Marker Logics<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

NULL domain value Logical value for values<br />

Unknown<br />

unk<br />

NotApplicable<br />

∌<br />

NotExists ¬!<br />

NeverExists<br />

<br />

∌ ∌<br />

∌<br />

∌ ∌ ∌ ∌ ∌<br />

x ∧ y 1 ¬! 0<br />

x ∨ y 1 ¬! 0<br />

1 1 ¬! 0<br />

1 1 1 1<br />

¬! ¬! ¬! ¬!<br />

¬! 1 ¬! ¬!<br />

0 0 ¬! 0<br />

0 1 ¬! 0<br />

x ∧ y 1 0<br />

x ∨ y 1 0<br />

1 1 0<br />

1 1 1 1<br />

0<br />

1 0<br />

0 0 0 0<br />

0 1 0 0<br />

¬<br />

0 1<br />

1 0<br />

¬! ¬!<br />

¬<br />

0 1<br />

1 0<br />

∌ ∌<br />

Content<br />

Information<br />

Concept Topic<br />

x ∧ y 1 unk 0<br />

1 1 unk 0<br />

unk unk unk 0<br />

0 0 0 0<br />

x ∨ y 1 unk 0<br />

1 1 1 1<br />

unk 1 unk unk<br />

0 1 unk 0<br />

¬<br />

0 1<br />

1 0<br />

unk unk

Negation for NULL Marker Logics<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

NULL domain value<br />

Unknown<br />

NotApplicable<br />

Logical value for values<br />

unk<br />

NotExists ¬!<br />

NeverExists<br />

NOT ¬ S̷lupezki ∼ ∼ 3 x ∼ 2 3 x<br />

0 1 L 1 L 1<br />

1 0 L 0 0 L<br />

L L L 1 1 0<br />

We need at least three kinds of negation!!!<br />

∧, ¬ is not <strong>co</strong>mplete for 3-valued logics<br />

∧, ¬ ∼ is not <strong>co</strong>mplete for 3-valued logics<br />

∧, ¬ ∼ 3 is not <strong>co</strong>mplete for 3-valued logics<br />

∌<br />

<br />

Content<br />

∧, ¬, ∼, ∼ 3 is <strong>co</strong>mplete for 3-valued logics<br />

Information<br />

Concept<br />

Topic

Introduction of a Combined Logical Value<br />

Lattice<br />

NULL domain value<br />

Logical value for values<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Unknown<br />

unk<br />

NotApplicable<br />

∌<br />

NotExists ¬!<br />

NeverExists<br />

<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

unk<br />

para<strong>co</strong>nsistent<br />

system<br />

1<br />

4-valued<br />

system<br />

0<br />

¬!<br />

<br />

∌<br />

∌<br />

information <strong>order</strong> (infological) with 0 < unk < 1<br />

<strong>and</strong> 0 < ∌ < 1<br />

Dunn/Belnap’s 4-valued system<br />

problem 1: unk ∧ ∌ = 0<br />

problem 2: unk ∨ ∌ = 1<br />

resolution 1: 0 < ∌ < unk < 1<br />

resolution 2: redefine ∧, ∨<br />

resolution 3: introduce two more truth values for<br />

unk ∧ ∌ <strong>and</strong> unk ∨<br />

strict <strong>order</strong> for <strong>and</strong> ¬!<br />

para<strong>co</strong>nsistent logics<br />

Information<br />

Concept<br />

Topic

Truth Value Table<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

∌<br />

NULL domain value Logical value for values<br />

Unknown<br />

unk<br />

NotApplicable<br />

∌<br />

NotExists ¬!<br />

NeverExists<br />

<br />

x ∧ / ∨ y ¬! 0 unk 1<br />

<br />

¬! ¬! min/weakmax min/weakmax min/weakmax min/weakmax<br />

0 min/weakmax 0 min/max min/max min/max<br />

∌ min/weakmax min/max ∌ min/max min/max<br />

unk min/weakmax min/max min/max unk min/max<br />

1 min/weakmax min/max min/max min/max 1<br />

based on resolution 1 but not on resolution 2 of the <strong>co</strong>nnectives problems<br />

weakmax: <strong>co</strong>ntraction operator for para<strong>co</strong>nsistent values<br />

Content<br />

Information<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

User-Defined Domain Types <strong>and</strong> Functions<br />

for NULL Markers<br />

✞<br />

☎<br />

SQL:1999 already supports flexible management<br />

✝<br />

✆<br />

CREATE DOMAIN BOOLExt AS VARSTRING(14)<br />

[ DEFAULT value ]<br />

CHECK (VALUE = ’TRUE’ OR VALUE = ’FALSE’<br />

OR VALUE IS ’UnknownNULL’<br />

OR VALUE IS ’NotExistNULL’<br />

OR VALUE IS ’NeverExistNULL’<br />

OR VALUE IS ’NotApplNULL’);<br />

GO;<br />

CREATE FUNCTION [dbo.]OrExtend (@FirstBool BOOLExt , @Se<strong>co</strong>ndBool BOOLExt)<br />

RETURNS BOOLExt WITH ENCRYPTION AS<br />

BEGIN<br />

DECLARE @ResultBool BOOLExt<br />

....<br />

RESULT @ResultBool<br />

END;<br />

GO;

Treatment in Predicates<br />

✞<br />

SQL:1999 already supports flexible management<br />

✝<br />

☎<br />

✆<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Known<br />

Unknown<br />

NOT IN<br />

predicate<br />

NotApplicable<br />

NotExists<br />

NeverExists<br />

treat as value<br />

treat as NULL marker<br />

remove object from result<br />

questionable query<br />

remove object<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Known<br />

treat as value<br />

Unknown<br />

treat as NULL marker<br />

NOT EXISTS<br />

predicate<br />

NotApplicable<br />

treat as empty object<br />

NotExists<br />

remove object from result<br />

NeverExists<br />

questionable query<br />

Content<br />

Information<br />

Concept<br />

Topic

Support for Aggregation<br />

✞<br />

SQL:1999 already supports flexible management<br />

✝<br />

☎<br />

✆<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Known<br />

Unknown<br />

SUM<br />

aggregation<br />

NotApplicable<br />

NotExists<br />

Never Exists<br />

use value<br />

use expectation value<br />

use 0<br />

questionable sum<br />

questionable sum<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

similar for<br />

min/max/<strong>co</strong>unt<br />

average<br />

other distributive, algebraic <strong>and</strong> holistic aggregation functions<br />

Content<br />

Information<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Health Care Information Systems<br />

People <strong>and</strong> organisations that are <strong>co</strong>ncerned with patients, health<br />

care provider organisations, individual practitioners, insurance <strong>co</strong>mpanies;<br />

Relationships between parties such as patient <strong>relationship</strong>s <strong>and</strong><br />

practitioners <strong>relationship</strong>s;<br />

Types of services <strong>and</strong> goods available from the health care providers;<br />

Types of agreements that exist between the various parties;<br />

Re<strong>co</strong>rds of health care services performed;<br />

Claims submitted <strong>and</strong> the status of the claim;<br />

Amounts directly owned from the patients as well as payments made<br />

by the patients;<br />

Other supporting information such as ac<strong>co</strong>unting information to<br />

create the financial statements <strong>and</strong> human resource information to<br />

track personnel.<br />

Content<br />

Information<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

People <strong>and</strong> Organisations in Health Care<br />

1/2<br />

✞<br />

☎<br />

Inherent <strong>co</strong>mplexity because of the application area ...<br />

✝<br />

✆<br />

Roles: patients, insured individuals, individual health care practitioners, administrators,<br />

provider staff support, <strong>co</strong>ntact people (insurance <strong>co</strong>mpany, pharmaceutical<br />

<strong>co</strong>mpany), ...<br />

Other parties: Employer, Supplier, Household, Regulatory Agency,<br />

Organisational Unit (Parent Organisation, Subsidiary, Division,<br />

Department, <strong>and</strong> Other Organisation), Internal Organisation, ...<br />

Generic dimensions: Contact, Employee, Party Qualification, Party<br />

Skill, Skill Type, Qualification Type<br />

Organisations: Health Care Provider Organisation (Institution,<br />

Health Care Practice, .... Institutional Provider), Group (Employer,<br />

Third Party Administrator, Insurance Provider, Payor,<br />

Health Care Association), Network, Employer, Third Party Administrator,<br />

Insurance Provider, Payor, Health Care Association.<br />

...

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

...<br />

People <strong>and</strong> Organisations in Health Care<br />

2/2<br />

✞<br />

☎<br />

Inherent <strong>co</strong>mplexity because of the application area ...<br />

✝<br />

✆<br />

Resulting associations: Insured Party, Insured Organisation, Employer,<br />

Insured Individuals, Insured Contract Holder, Organisation<br />

Contact Relationship, Supplier Relationship Employment,<br />

Organisation Rollup, Family Dependency, Household<br />

Membership, Patient Practitioner Relationship, Patient Provider<br />

Relationship, Practice Affiliation, Provider Network, Patient<br />

Provider Relationship, Health Care Provider Organisation,<br />

Practice Affiliation<br />

Generic associations: Party Role, Party Relationship, ...<br />

Health care facilities: Hospital, Office, Room, Clinic, ...<br />

Generic facility types: Facility (Medical Building, Ambulatory<br />

Surgery Center, Floor, ... Bed, Room), ...<br />

Specific types: Licencewithin a Geographic Boundary, ...<br />

Generic characterisations: Medical Condition, Physical Characteristic,<br />

...

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

Reporting Schemata<br />

✞<br />

☎<br />

One of many<br />

✝<br />

✆<br />

Financial analysis: Balance sheets <strong>and</strong> statement trends allow to determine trends<br />

on the in<strong>co</strong>me <strong>and</strong> the profitability over time, incident types, patient types,<br />

health care practitioner types etc.<br />

Human resource analysis: Employees can be classified regarding age, gender, marital<br />

status, position <strong>and</strong> other demographic information.<br />

Claims analysis: History of claims <strong>and</strong> settlements can be classified regarding service<br />

<strong>co</strong>des, types of diagnosis, episode types, geographic areas, dates, <strong>and</strong><br />

payors. Trend analysis allows an insight what types of health care deliveries have<br />

been reimbursed <strong>and</strong> allows to predict what to expect regarding insurance<br />

receipts.<br />

Health care delivery out<strong>co</strong>me analysis: The out<strong>co</strong>me of health care deliveries can<br />

be analysed under various circumstances.<br />

Health care episode out<strong>co</strong>me analysis: The out<strong>co</strong>me of different kinds of health<br />

care episodes is of specific interest depending on various circumstances.<br />

Concept<br />

Topic

Schemata Easily Get Large<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

Concept Topic<br />

✞<br />

☎<br />

Layered Solution<br />

✝<br />

✆

Generic Entity Types<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

Concept<br />

Topic

Star Schema for Person<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

CREATE TABLE person (<br />

person id<br />

NUMBER NOT NULL,<br />

first name<br />

VARCHAR2(20) NULL,<br />

mi<br />

VARCHAR2(20) NULL,<br />

gender<br />

VARCHAR2(20) NULL,<br />

date of birth DATE NULL,<br />

date of death DATE NULL<br />

);<br />

ALTER TABLE person<br />

ADD ( PRIMARY KEY (person id) ) ;<br />

CREATE TABLE person <strong>language</strong> (<br />

person <strong>language</strong> seq id NUMBER NOT NULL,<br />

person id<br />

NUMBER NOT NULL,<br />

<strong>language</strong> <strong>co</strong>de VARCHAR2(20) NULL<br />

);<br />

ALTER TABLE person <strong>language</strong><br />

ADD ( PRIMARY KEY (person <strong>language</strong> seq id, person id) ) ;<br />

CREATE TABLE person address (<br />

person address seq id NUMBER NOT NULL,<br />

person id<br />

NUMBER NOT NULL,<br />

address type VARCHAR2(20) NULL,<br />

address line 1 VARCHAR2(20) NULL,<br />

address line 2 VARCHAR2(20) NULL,<br />

city<br />

VARCHAR2(20) NULL,<br />

state<br />

VARCHAR2(20) NULL,<br />

zip<br />

VARCHAR2(20) NULL<br />

);<br />

separation of <strong>co</strong>ncern<br />

deep normalisation<br />

<strong>co</strong>mponentisation<br />

view towers instead of redundant storage<br />

ALTER TABLE person address<br />

ADD ( PRIMARY KEY (person address seq id, person id) ) ;<br />

CREATE TABLE person phone (<br />

person phone seq id NUMBER NOT NULL,<br />

person id NUMBER NOT NULL,<br />

phone type VARCHAR2(20) NULL,<br />

area <strong>co</strong>de NUMBER NULL,<br />

phone numberNUMBER NULL,<br />

extension NUMBER NULL<br />

);<br />

ALTER TABLE person phone<br />

ADD ( PRIMARY KEY (person phone seq id, person id) ) ;<br />

ALTER TABLE person <strong>language</strong><br />

ADD ( FOREIGN KEY (person id)<br />

REFERENCES person ) ;<br />

ALTER TABLE person address<br />

ADD ( FOREIGN KEY (person id)<br />

REFERENCES person ) ;<br />

ALTER TABLE person phone<br />

ADD ( FOREIGN KEY (person id)<br />

REFERENCES person ) ;<br />

Concept<br />

Topic

The Star Schema for Health Care Episode<br />

Out<strong>co</strong>me Analysis<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

(0,1)<br />

(0,n)<br />

Episodes<br />

ID, Description,<br />

...<br />

■<br />

✻<br />

(0,n)<br />

Practitioners<br />

ID, Description<br />

Name(Last, First),<br />

...<br />

(0,1)<br />

✒<br />

Providers<br />

ID, Description,<br />

Name, ...<br />

(0,n)<br />

(0,1)<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

(0,1)<br />

(0,1)<br />

(0,n)<br />

Diagnoses<br />

ID, Description,<br />

...<br />

Incidents<br />

ID, Description,<br />

...<br />

✛<br />

✠<br />

# Of<br />

Episodes<br />

Total<br />

Charges<br />

(0,1)<br />

Health<br />

CareEpisode<br />

Fact<br />

❄<br />

Avg<br />

Length<br />

Of<br />

Episode<br />

Times<br />

ID, Description,<br />

Day, Weak, Month,<br />

Quarter, Year<br />

# Of<br />

Visits<br />

# Of<br />

Deliveries<br />

✲<br />

❘<br />

Patients<br />

ID, Description,<br />

...<br />

Out<strong>co</strong>mes<br />

ID, Description,<br />

...<br />

(0,n)<br />

(0,n)<br />

(0,1)<br />

(0,1)<br />

Information<br />

(0,n)<br />

(0,n)<br />

Concept<br />

Topic

Functionality<br />

Operations + dynamic integrity <strong>co</strong>nstraints<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

Operations as a generalization of relational algebra<br />

Basic operations: union, difference, intersection, projection, selection, various<br />

types of join operations, product, (un-)nesting, power-set, aggregation<br />

Manipulation operations (insert, delete, update) as specific basic operations<br />

Retrieval operations as type-<strong>co</strong>nstructing basic operations<br />

restricted to <strong>co</strong>mponents or sub-schemata or unrestricted<br />

Workflows on the basis of transaction models <strong>and</strong> on <strong>co</strong>ntrol models<br />

Dynamic integrity <strong>co</strong>nstraints defined in a temporal logic<br />

Abstract state machine semantics for state changes<br />

Transition <strong>co</strong>nstraints restricting state changes caused by operations<br />

General pre- <strong>and</strong> post-<strong>co</strong>nditions for state changes<br />

http://www.informatik.uni-kiel.de/∼thalheim/slides.htm<br />

Concept<br />

Topic

Intensional Functionality Specification<br />

Business Case: Enter information on lectures after being requested<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

Caller Organizational unit Help <strong>and</strong> auxiliary information<br />

Request to responsible<br />

person<br />

Actions<br />

Chair<br />

Courses, programs,<br />

rooms<br />

1. Entry Responsible person of chair<br />

Main information entry ;<br />

(Classification || categorize || input of other data || input of side <strong>co</strong>nditions );<br />

2. Confirmation step Responsible person <strong>and</strong> members of chair<br />

Proofreading, <strong>co</strong>rrection, extension for requests, main <strong>and</strong> other data<br />

3. Submission step Responsible person of the chair<br />

Archive in chair folder ; send data to caller; publish at chairs internal page<br />

for:<br />

Concept<br />

Topic

HERM Query Algebra<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Operations are defined on the basis of structural recursion op = src[e, g, ⊔]<br />

with a value e of type t ′ , a function g : t → t ′ <strong>and</strong> a function ⊔ : t ′ × t ′ → t ′ :<br />

src[e, g, ⊔](∅) = e<br />

src[e, g, ⊔]({x}) = g(x) for x of type t,<br />

src[e, g, ⊔](X ∪Y ) = src[e, g, ⊔](X ) ∪ src[e, g, ⊔](Y ) for X , Y of type {t} ,<br />

e.g., filter(φ) = src[∅, if then else ⋆ (φ × single × (empty ⋆ triv)), ∪] ,<br />

sum = src[0, id, +]<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

Operations for tuple types are defined by structural recursion on basic operations<br />

projection π i : t 1 × ... × t n → t i , (Cartesian) product × : t → t 1 × ... × t n ,<br />

re<strong>order</strong>ing ρ, renaming κ<br />

Operations for set types are defined by structural recursion on basic operations union ∪,<br />

difference \, <strong>co</strong>nstant, singleton element,<br />

e.g., join operation<br />

Operations on function types are defined by structural recursion on basic operations <strong>co</strong>mposition<br />

⋆ : (t 2 → t 3 )×(t 1 → t 2 ) → (t 1 → t 3 ), evaluation ev : (t 1 → t 2 )×t 1 → t 2<br />

<strong>and</strong> abstraction abstr : (t 1 × t 2 → t 3 ) → (t 1 → (t 2 → t 3 ))<br />

Conversion operations from tuple to set types, from function types to <strong>co</strong>llections, etc.<br />

Operations for URL extension using labels l extending the type system to<br />

t = b | l | t 1 × ... × t n | {t} | [t] | l : t<br />

that is restricted to rational trees (number of different subtrees is finite)

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

HERM-Algebra via Structural Recursion<br />

Selection: σ α = srec ∅,ια ,∪ ⎧<br />

⎨ {o} if {o} |= α<br />

ι α ({o}) =<br />

⎩ ∅ otherwise<br />

Projection: π X = T [X ] = srec ∅,πX ,∪, X ⋐ T ,<br />

π X ({o}) = {o| X }<br />

(Natural) Join: = srec ∅,T ,∪<br />

T ({(o 1 , o 2 )}) = {o ∈ Dom(T 1 ∪ T 2 ) | o| T1 = o 1 ∧ o| T2 = o 2 }<br />

Cartesian product <strong>and</strong> intersection as special cases<br />

Renaming: ρ X ,Y = srec ∅,ρX ,Y ,∪<br />

ρ X ,Y ({(o)}) = {o ′ ∈ Dom((T \X )◦Y ) | o| T \X = o ′ | T \X ∧o| X = o ′ | Y }<br />

Nesting: ν X = srec ∅,ρX ,{X } ,h 2<br />

for X ⋐ T = R,<br />

T ′ = C (R\X )⊔ R{X } , o ′ | X ∈ π X (T ′C ),<br />

h 2 ({o ′ }, T ′C ) = {o ′ }∪T ′C if o ′ | X ∉ π X (T ′C )<br />

h 2 ({o ′ }, T ′C ) = { o ∈ Dom(T ′ ) | ∃o ′ ∈ T ′C : o| R\X = o ′ | R\X<br />

∧o(X ) = { o ′′ [X ] | o ′′ ∈ T ′C ∧o ′ | R\X = o ′′ | R\X }}<br />

Unnesting : µ X = srec ∅,ρX ,{X } ,h 2<br />

, {X } ⋐ T = R,<br />

T ′ = C (R\{X })◦X ,<br />

h 2 ({o ′ }, T ′C ) = {o ′ }∪<br />

{ o ∈ Dom(T ′ ) | ∃o ′′ ∈ R C : o[R\{X }] = o ′′ [R\{X }]∧o| X ∈ o ′′ | X }<br />

Concept<br />

Topic

Programming Support Through Visual SQL<br />

Lecture L<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Person P1<br />

√ Name<br />

√ BirthData<br />

√ Address<br />

=<br />

=<br />

Student S1<br />

StudNo<br />

Name<br />

BirthData<br />

=<br />

Supervisor<br />

StudNo<br />

Name<br />

BirthData<br />

...<br />

=<br />

=<br />

Professor P2<br />

√ Name<br />

BirthData<br />

...<br />

=<br />

=<br />

CourseNo<br />

Semester<br />

Name<br />

BirthData<br />

...<br />

...<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

S1 = S2<br />

Student S2<br />

StudNo<br />

Name<br />

BirthData<br />

=<br />

Enroll E<br />

StudNo<br />

CourseNo<br />

...<br />

{ L.CourseNo } = { E.CourseNo }<br />

Result NOT NULL<br />

Content<br />

Information<br />

Concept<br />

Topic<br />

Provide data on students who have successfully <strong>co</strong>mpleted those <strong>and</strong> only those<br />

<strong>co</strong>urses which have successfully been given or which are currently given by the<br />

student’s supervisor?

VisualSQL versus SQL<br />

SELECT P1.Name, P1.BirthDate, P1. Address,<br />

P2.Name AS ‘‘Name of supervisor’’<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

FROM Person P1, Professor P2, Student S1, Supervisor, Lecture L,<br />

Enroll E<br />

WHERE P1.Name = Student.Name AND P1.BirthDate = Student.BirthDate<br />

AND S1.StudNo = E.StudNo<br />

AND E.Result NOT NULL<br />

AND S1.StudNo = Supervisor.StudNo<br />

AND Supervisor.Name = Professor.Name<br />

AND Supervisor.BirthDate = Professor.BirthDate<br />

AND P2.Name = Professor.Name AND P2.BirthDate = P2.BirthDate<br />

AND L.Name = Professor.Name AND L.BirthDate = Professor.BirthDate<br />

AND<br />

L.CourseNo<br />

IN (SELECT E2.CourseNo<br />

FROM Enroll E2<br />

WHERE S1.StudNo = E2.StudNo AND<br />

E2.Result NOT NULL )<br />

AND<br />

E.CourseNo<br />

IN (SELECT L2.CourseNo<br />

FROM Lecture L2<br />

WHERE<br />

L2.Name = P2.Name AND<br />

L2.BirthDate = P2.BirthDate );<br />

Content<br />

Information<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

SQL is Easy to Read, to Develop <strong>and</strong> to<br />

Underst<strong>and</strong>? Of Course, for Everybody!!!<br />

✞<br />

☎<br />

What does this query?<br />

✝<br />

✆<br />

SELECT P1.Name, P2.Name<br />

FROM Person P1, Person P2, Student S1, Student S2, Enrol H1, Enrol H2<br />

WHERE P1.Name = S1.Name AND P1.DateOfBirth = S1.DateOfBirth AND<br />

S1.StudNo = H1.StudNo AND H1.Grade IS NOT NULL AND<br />

P2.Name = S2.Name AND P2.DateOfBirth = S2.DateOfBirth AND<br />

S2.StudNo = H2.StudNo AND H2.Grade IS NOT NULL<br />

AND NOT EXISTS<br />

(SELECT *<br />

FROM Enrol H3<br />

WHERE H3.Grade IS NOT NULL AND<br />

H3.StudNo NOT IN<br />

(SELECT H4.StudNo<br />

FROM Enrol H4<br />

WHERE H4.StudNo = H2.StudNo<br />

AND H4.Grade IS NOT NULL)<br />

AND H1.StudNo = H3.StudNo)<br />

AND NOT EXISTS<br />

(SELECT *<br />

FROM Enrol H5<br />

WHERE H5.Grade IS NOT NULL AND<br />

H5.StudNo NOT IN<br />

(SELECT H6.StudNo<br />

FROM Enrol H6<br />

WHERE H6.StudNo = H1.StudNo<br />

AND H4.Grade IS NOT NULL)<br />

AND H2.StudNo = H5.StudNo)<br />

AND S1.StudNo < S2.StudNo<br />

GROUP BY P1.Name, P2.Name;<br />

✞<br />

☎<br />

Person, Student, Lecture, Enrol<br />

✝<br />

✆

VisualSQL Query<br />

✞<br />

Which students <strong>co</strong>mplete <strong>co</strong>urses all the time together?<br />

✝<br />

☎<br />

✆<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Person P1<br />

√ Name<br />

DateOfBirth<br />

...<br />

=<br />

=<br />

Student S1<br />

StudNo<br />

Name<br />

DateOfBirth<br />

...<br />

=<br />

Enrol<br />

StudNo<br />

Semester<br />

CourseNo<br />

Grade<br />

...<br />

IS NOT NULL<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

<<br />

Person P2<br />

√ Name<br />

DateOfBirth<br />

...<br />

=<br />

=<br />

Student S2<br />

StudNo<br />

Name<br />

DateOfBirth<br />

...<br />

=<br />

==<br />

Enrol<br />

StudNo<br />

Semester<br />

CourseNo<br />

Grade<br />

...<br />

IS NOT NULL<br />

Content<br />

Information<br />

Concept Topic<br />

far simpler <strong>and</strong> easier to formulate, to capture, to underst<strong>and</strong><br />

without the SQL burden<br />

http://www.informatik.uni-kiel.de/en/information-systems-engineering/<br />

miscellaneous/visualsql/

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

Yet Another Resulting Query<br />

SELECT P1.Name, P2.Name<br />

FROM Person P1, Person P2, Student S1, Student S2, Enrol H1, Enrol H2<br />

WHERE P1.Name = S1.Name AND P1.DateOfBirth = S1.DateOfBirth AND<br />

S1.StudNo = H1.StudNo AND H1.Grade IS NOT NULL AND<br />

P2.Name = S2.Name AND P2.DateOfBirth = S2.DateOfBirth AND<br />

S2.StudNo = H2.StudNo AND H2.Grade IS NOT NULL<br />

AND NOT EXISTS<br />

(SELECT *<br />

FROM Enrol H3<br />

WHERE H3.Grade IS NOT NULL AND<br />

H3.StudNo NOT IN<br />

(SELECT H4.StudNo<br />

FROM Enrol H4<br />

WHERE H4.StudNo = H2.StudNo<br />

AND H4.Grade IS NOT NULL)<br />

AND H1.StudNo = H3.StudNo)<br />

AND NOT EXISTS<br />

(SELECT *<br />

FROM Enrol H5<br />

WHERE H5.Grade IS NOT NULL AND<br />

H5.StudNo NOT IN<br />

(SELECT H6.StudNo<br />

FROM Enrol H6<br />

WHERE H6.StudNo = H1.StudNo AND H4.Grade IS NOT NULL)<br />

AND H2.StudNo = H5.StudNo)<br />

AND S1.StudNo < S2.StudNo<br />

GROUP BY P1.Name, P2.Name;<br />

✞<br />

☎<br />

How long would it take you to formulate this query?<br />

✝<br />

✆<br />

✞<br />

☎<br />

Is the first query in this talk equivalent to this query?<br />

✝<br />

✆

The VisualSQL Tool<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

Concept<br />

Topic

The VisualSQL Tool<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

Concept<br />

Topic

Abstracting from HERM Programs to<br />

Diagrams in the Business Process<br />

Modelling & Notation<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

Concept<br />

Topic

Ex.: Paper Submission Review System<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

Concept<br />

Topic

Ex.: Paper Submission Review System<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

Concept<br />

Topic

Yet an Example of a Workflow Diagram<br />

✞<br />

☎<br />

A BPMN diagram taken from literature with many problems<br />

✝<br />

✆<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

BPMN Assumptions<br />

separation of the specification into workflow process <strong>and</strong> workflow<br />

process instance<br />

singleton isolatable process instance bound to its token<br />

inter-process <strong>co</strong>llaboaration only through messages <strong>and</strong> events<br />

hidden resource dependences<br />

swimlanes for different roles of users<br />

pools for views on process sets<br />

separation of nodes<br />

Node = Activity ∪ Event ∪ Gateway<br />

separation of events<br />

Event = StartEvent ∪ IntermEvent ∪ EndEvent<br />

tasks <strong>co</strong>mprehend only some of possible executions<br />

TaskType = {Service, User, Receive, Send, Script, Manual, Reference, None}<br />

rigid localisation<br />

avalanches of side <strong>co</strong>nstraints<br />

<strong>co</strong>ntext-sensitiv functions,<br />

none-incremental semantics,<br />

goto jumps, token progression may be<strong>co</strong>me “arbitrary”

Resulting Orchestration Problems<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

Communication through explicit specification of proto<strong>co</strong>ls <strong>and</strong> services:<br />

interprocess <strong>co</strong>mmunication exclusively by messages <strong>and</strong> links<br />

Coordination only implicitly by message proto<strong>co</strong>ls or links<br />

typical <strong>co</strong>ordination problems:<br />

opportunities, obligations, permissions <strong>and</strong> forbids must intentionally<br />

be taken into <strong>co</strong>nsideration by the modeller<br />

<strong>co</strong>ntracts among parties<br />

exceptional cases, timeouts<br />

Cooperation between processes only through messages<br />

typical <strong>co</strong>operation problems:<br />

Zachman enactment: who, what, when, where, how, why<br />

rights, obligations <strong>and</strong> roles<br />

Data dependencies among processes be<strong>co</strong>me a sideway task for the<br />

modeller

Implicit BPMN Assumptions<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

Petri net illustration for token flow results in messy problems<br />

limitations of Petri nets<br />

negative token with runtime overwriting of semantics of <strong>co</strong>nstructs<br />

token <strong>co</strong>louring<br />

token with history transfer for sub-processes<br />

Process instance duplication for each call of a process with optimisation<br />

by elimination of dead paths<br />

In<strong>co</strong>rporation of other st<strong>and</strong>ards in rather fuzzy way: interchange<br />

of messages, SOAP, UDDI, web services, web transaction,<br />

XML (XPath, XPDL, XSchema, ..), ...<br />

Concentration on workflow processes leaving out <strong>co</strong>ntrol<br />

among process instance <strong>and</strong> data flow among them<br />

Partial BPEL transformation with reference to BPEL meaning

Formalisation of the Business Process<br />

Modelling & Notation<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

see<br />

my theory talk<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

✞<br />

☎<br />

Event Process Chains can be h<strong>and</strong>led in a similar way<br />

✝<br />

✆<br />

✞<br />

☎<br />

Activity <strong>and</strong> other dynamic UML diagram <strong>language</strong>s ...<br />

✝<br />

✆<br />

Content<br />

Information<br />

Concept<br />

Topic

Advanced Views <strong>and</strong> Media Types<br />

Specification Frame<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

generate Mapping : Vars → output structure<br />

from database types<br />

where selection <strong>co</strong>ndition<br />

represent using general presentation style<br />

& Abstraction (Granularity, measure, precision)<br />

& Orders within the presentation<br />

& Hierarchical representations<br />

& Points of view<br />

& Separation<br />

browsing definition <strong>co</strong>ndition<br />

& Navigation<br />

functions Search functions<br />

& Export functions<br />

& Input functions<br />

& Session functions<br />

& Marking functions

Views: Archiv view<br />

Description = “SS00/01”<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Course<br />

retrieve<br />

❦<br />

Semester<br />

slice/sort<br />

✻<br />

Responsible4Course<br />

✸<br />

Person<br />

retrieve<br />

✻<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Program<br />

retrieve<br />

✛<br />

{}<br />

Course<br />

held<br />

retrieve<br />

❄<br />

Kind<br />

retrieve<br />

Teacher<br />

✲<br />

Professor<br />

retrieve<br />

Content<br />

Information<br />

XML as the display medium<br />

XML specifications can be automatically generated out of this view<br />

Concept<br />

Topic

Algebraic expressions for views<br />

Views for internet presentation as Read-Only-View<br />

Archiv view as materialized Read-Only-View<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

Slice SS00/01 with Archiv.Semester := e(Semester)<br />

for e = σ Bezeichn=“SS00/01 ′′<br />

Archiv.Course := e(CourseHeld [Course])<br />

Archiv.Person := e(CourseHeld[plannedCourse[<br />

proposedCourse[Responsible4Course : Person]]])<br />

Program, Kind, Professor analoguous<br />

Archiv.CourseHeld := e(CourseHeld[plannedCourse[<br />

proposedCourse [ Course, Program, Teacher:Professor,<br />

Responsible4Course : Person], Kind]])<br />

Be careful: changing set of integrity <strong>co</strong>nstraints!<br />

Insert view for new <strong>co</strong>urse proposals: als Read-Write-View with identifiable sub-views <strong>and</strong><br />

side <strong>co</strong>nditions<br />

with optional <strong>and</strong> m<strong>and</strong>atory <strong>co</strong>mponents<br />

Media object schema as <strong>co</strong>ntainers based on views with <strong>co</strong>ntainer functionality <strong>and</strong> attached<br />

functions<br />

representation bound by <strong>order</strong>, adhesion, <strong>co</strong>hesion of types<br />

taylored by user profile, user environment, history, channel capacity<br />

are associated with dialogue scenes

View: Insertion view for new <strong>co</strong>urse<br />

proposals<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

required<br />

Course<br />

retrieve<br />

❄<br />

Course<br />

❑<br />

retrieve, select, input<br />

(1,1)<br />

Program<br />

❦<br />

retrieve, select<br />

✛<br />

+<br />

{}<br />

❦<br />

Description = “SS01/02”<br />

Proposal<br />

<br />

Semester<br />

retrieve<br />

✻<br />

proposed<br />

Course<br />

input<br />

✲<br />

Teacher<br />

Time(Proposal,<br />

SideConditions)<br />

Chair<br />

retrieve<br />

✻<br />

Professor<br />

retrieve, select<br />

✒<br />

default = Profβ<br />

Wish<br />

insertedBy<br />

= “SecrKK”<br />

ShortDescr = “DBIS”<br />

✲<br />

✯<br />

✲<br />

Room<br />

Person<br />

retrieve<br />

Responsible4Course = “β”<br />

retrieve, select<br />

✶<br />

Content<br />

Information<br />

Concept Topic<br />

Kind<br />

retrieve, select<br />

✰

Outlook: Media Types, Media Object<br />

Suites<br />

Theoretical Basis<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Raw media types = (<strong>co</strong>nt(M ), sup(M ), view(M ), op(M ))<br />

<strong>co</strong>ntent type <strong>co</strong>nt(M ), set of supertypes sup(M ),<br />

view(M ) = Q (S inp , S outp )<br />

HERM view<br />

generic functions op(M ) for changing the database<br />

Attached operations: (signature, selection type, body)<br />

selection type - supertype of <strong>co</strong>nt(M )<br />

e.g. generalization/specialization, re<strong>order</strong>ing, browsing, linking, surveying,<br />

searching, join<br />

Media type: raw media type + unit extension<br />

+ <strong>order</strong> extension + <strong>co</strong>hesion/adhesion + hierarchical versions<br />

Usage modeling: usage dimensions, scales, user profiles, user kind<br />

Container = (<strong>co</strong>nt(C), layout(C), kind(C))<br />

for shipping <strong>and</strong> representation<br />

Content<br />

Information<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Lot<br />

lot id nr<br />

Pitfalls <strong>and</strong> Misunderst<strong>and</strong>ings of<br />

Micro-/Meso-/Macrodata<br />

Snodgrass Example for Temporality Problems<br />

✛<br />

HD CNT<br />

Resides<br />

from<br />

to<br />

✲<br />

Pen<br />

penn id<br />

Awful queries, overwhelming <strong>co</strong>mplexity<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Microdata of the Temporal Database<br />

✛ Belongs<br />

Lot<br />

✲ Cattle ✛ Resides ✲ Pen<br />

(0,.)<br />

To<br />

(1,1) (1,.) (0,.)<br />

from to<br />

lot id nr gender <strong>co</strong>de penn id<br />

Content<br />

Information<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Micro-data versus Macro-data<br />

✞<br />

☎<br />

The right level of data granularity<br />

✝<br />

✆<br />

Typical Snodgrass query: “Give the History of Lots being <strong>co</strong>-resident in a Pen”<br />

select L1.Lot Id num, L2.Lot Id Num, L1.Pen Id, L1.From Date, L1.To Date<br />

from Lot Loc as L1, Lot Loc as L2<br />

where L1.Lot Id num< L2.Lot Id num <strong>and</strong> L1.Fdyd Id = L2.Fdyd Id<br />

<strong>and</strong> L1.Pen Id= L2.Pen Id <strong>and</strong> L1.From Date= L2.From Date<br />

<strong>and</strong> L1.To Date L1.From Date<br />

<strong>and</strong> L2.To Date

Pitfalls, Misunderst<strong>and</strong>ings, Practice, <strong>and</strong><br />

Theory of Aggregation<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Paradoxes like for Cantor set theory<br />

but this time statistical <strong>and</strong> structural paradoxes<br />

Aggregation against semantics through roll-up, drill-down, dicing<br />

<strong>and</strong> slicing<br />

independence of properties is assumed but not true<br />

There are three kinds of lie: lies, damned lies <strong>and</strong> statistics.<br />

attributed to Benjamin Disraeli (1804-81) by Mark Twain (Autobiography, 1924)<br />

Forgetful schema transformation due to properties of aggregation<br />

functions<br />

Ignoring properties of type systems e.g. granularity, nulls,<br />

defaults, interpretations<br />

Content<br />

Information<br />

Concept<br />

Topic

The Hierarchy Paradox<br />

Cube A: Participants per Lecture <strong>and</strong> Day<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Lectures ✛ HeldOn ✲<br />

#Participants<br />

Day<br />

Cube B: Usage of Rooms per Day<br />

Room<br />

✛<br />

Usage<br />

✲<br />

Day<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

Scheduling Schema on University <strong>and</strong> Evening Lectures<br />

Room<br />

University<br />

Lectures ✛<br />

HeldOn<br />

#Participants<br />

✲<br />

Working<br />

Day<br />

✻<br />

#TotalUsage<br />

Room<br />

IsA ✲ Day ✛ Organized ✲ Evening<br />

On Lectures<br />

#Participants<br />

Title

Hierarchies in the Example 2: 1<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

day<br />

✮<br />

❥<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

✠<br />

✰<br />

morning<br />

date of<br />

university lectures<br />

day inside term<br />

<br />

evening<br />

❘<br />

date of<br />

evening lectures<br />

day outside term<br />

❄<br />

date of<br />

evening lectures<br />

Content<br />

Information<br />

Concept<br />

Topic

Hierarchies in the Example 2: 2<br />

day<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

✠<br />

working day<br />

<br />

non-working day<br />

✙<br />

<br />

❄<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

✠<br />

date of<br />

university lectures<br />

morning<br />

✠<br />

day<br />

inside term<br />

❥<br />

day<br />

outside term<br />

evening<br />

❥<br />

date<br />

date of<br />

evening lectures<br />

at working days<br />

Content<br />

Information<br />

Concept<br />

Topic

Cube B Data in the Example 2<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Day category Room utilization Daytime # of rooms<br />

working occupied morning 20<br />

working occupied evening 12<br />

working free morning 10<br />

working free evening 4<br />

non-working occupied morning 2<br />

non-working occupied evening 8<br />

non-working free morning 6<br />

non-working free evening 16<br />

Daytime Working day Non-working day All days<br />

Evening 75 % 33 % 50 %<br />

Morning 67 % 25 % 58 %<br />

Content<br />

Information<br />

Concept<br />

Topic

Cube B Data in the Example 2<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Day category Room utilization Daytime # of rooms<br />

working occupied morning 20<br />

working occupied evening 12<br />

working free morning 10<br />

working free evening 4<br />

non-working occupied morning 2<br />

non-working occupied evening 8<br />

non-working free morning 6<br />

non-working free evening 16<br />

Daytime Working day Non-working day All days<br />

Evening 75 % 33 % 50 %<br />

Morning 67 % 25 % 58 %<br />

Content<br />

Information<br />

Concept<br />

Topic

Weighted Cube B Data in the Example 2<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Day category Room utilization Daytime # of rooms<br />

working occupied morning 20<br />

working occupied evening 12<br />

working free morning 10<br />

working free evening 4<br />

non-working occupied morning 2<br />

non-working occupied evening 8<br />

non-working free morning 6<br />

non-working free evening 16<br />

Daytime Working day Non-working day All days<br />

Evening (75 % , 16<br />

30<br />

24<br />

24<br />

) (33 % ,<br />

30<br />

) (50 %,<br />

30 )<br />

Morning (67 %, 30<br />

30 ) (25 %, 8<br />

30<br />

) (58 %,<br />

30<br />

30 )<br />

The hierarchy paradox<br />

Information<br />

Concept<br />

Topic

The Simpson Paradox<br />

✞<br />

Revisited but based on a classical OLAP example<br />

✝<br />

☎<br />

✆<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

model Chevy Ford ALL<br />

<strong>co</strong>lor blue white blue white ALL<br />

year 90 91 90 91 90 91 90 91 ALL<br />

<strong>co</strong>unt 187 155 131 108 217 180 151 125 1254<br />

<strong>co</strong>unt(*) by model, <strong>co</strong>lor, year (data under independence <strong>co</strong>nstraint)<br />

Ratios ’Market Share Percentages of Chevy’<br />

p(chevy|blue, 90) =<br />

187 · 100<br />

187 + 217<br />

= 46%<br />

p(chevy|blue, 91) = 155 · 100<br />

335<br />

= 46%<br />

p(chevy|white, 90) = 131 · 100<br />

282<br />

= 46%<br />

p(chevy|white, 90) = 108 · 100<br />

233<br />

= 46%<br />

Market share of sold units where model = ‘chevy’<br />

<strong>co</strong>nstant for both <strong>co</strong>lors over years 90-91

The Simpson Paradox<br />

✞<br />

Revisited but based on a classical OLAP example<br />

✝<br />

☎<br />

✆<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

model Chevy Ford ALL<br />

year 90 91 90 91 ALL<br />

<strong>co</strong>unt 187 155 217 180 1254<br />

<strong>co</strong>unt (*) by model, year<br />

p(chevy, 90) = 308<br />

686<br />

p(chevy, 91) = 263<br />

568<br />

<strong>co</strong>herent with the results before<br />

· 100 ≈ 46%<br />

· 100 ≈ 46%<br />

global independence assumption (integrity <strong>co</strong>nstraint) on the data space<br />

spanned by the attributes ‘model’, ‘year’ <strong>and</strong> ‘<strong>co</strong>lor’, cite<br />

Information<br />

Concept<br />

Topic

The Simpson Paradox<br />

✞<br />

Revisited but based on a classical OLAP example<br />

✝<br />

☎<br />

✆<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

Tm: model Chevy Ford ALL<br />

<strong>co</strong>unt 581 673 1254<br />

Ty: year 90 91 ALL<br />

<strong>co</strong>unt 739 515 1254<br />

Tc: <strong>co</strong>lor blue white ALL<br />

<strong>co</strong>unt 687 567 1234<br />

Tabelle 1: Marginal tables Tm, Ty, Tc used to generate ??<br />

insert <strong>and</strong> delete operations<br />

model Chevy Ford ALL<br />

<strong>co</strong>lor blue white blue white ALL<br />

year 90 91 90 91 90 91 90 91 ALL<br />

<strong>co</strong>unt 255 156 88 82 174 102 222 175 1254<br />

<strong>co</strong>unt (*) by model, <strong>co</strong>lor, year

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

The Simpson Paradox<br />

✞<br />

☎<br />

Revisited but based on a classical OLAP example<br />

✝<br />

✆<br />

p(chevy|blue, 90) = 255 · 100<br />

429<br />

≈ 59%<br />

p(chevy|blue, 91) = 156 · 100<br />

258<br />

≈ 60%<br />

Market share of a blue car of type ‘chevy’ increases slightly over years<br />

Increase of the share is stronger for white cars:<br />

p(chevy|white, 90) =<br />

p(chevy|white, 91) =<br />

88 · 100<br />

310<br />

≈ 28%<br />

82 · 100<br />

257<br />

≈ 32%<br />

Content<br />

Information<br />

Concept<br />

Topic

The Simpson Paradox<br />

✞<br />

Revisited but based on a classical OLAP example<br />

✝<br />

☎<br />

✆<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

Slice now over ‘<strong>co</strong>lor’, π year,<strong>co</strong>unt<br />

The bad guy:<br />

model Chevy Ford ALL<br />

year 90 91 90 91 ALL<br />

<strong>co</strong>unt 324 238 396 277 1254<br />

<strong>co</strong>unt (*) by model, year<br />

p(chevy, 90) = 308<br />

686<br />

p(chevy, 91) = 263<br />

568<br />

✙<br />

Z (<strong>co</strong>lor)<br />

· 100 ≈ 46%<br />

· 100 ≈ 46%<br />

X (year) Y (model)<br />

Dependency graph XYZ with separator (influential) attribute Z<br />

❥

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Explaining the Simpson Paradox<br />

Changing meaning of attributes: Chevys has in 90 <strong>and</strong> 91 an equal<br />

ratio<br />

but there are more white cars<br />

Problems of slicing:<br />

• Blue slice: Cheveys ratio is in 91 better than 90<br />

• White slice: Chevys ratio is in 91 better than 90<br />

Based on both slices: Chevys ratio is in 91 better than 90<br />

Not told (but valid):<br />

Overall selling is decreasing from 90 to 91<br />

Reason why Chevys are better: lower relative decrease<br />

Content<br />

Information<br />

Concept<br />

Topic

Other Problematic OLAP Applications<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Non-<strong>co</strong>mmutative operators: Let O be a given set of numeric operators.<br />

Let o 1 ∈ O be a linear operator <strong>and</strong> o 2 ∈ O a non-linear operator.<br />

Then it is generally not true that o 1 ◦ o 2 = o 2 ◦ o 1 .<br />

Perfect aggregation: The perfect homomorphism H : ŷ = y exists if<br />

<strong>and</strong> only if ŷ = SAT ∨ A = S + AT + where S + (T + ) is the Moore-Penrose<br />

inverse of S(T ).<br />

x ✲ y<br />

A<br />

T<br />

✻<br />

S<br />

❄ A<br />

X ✲ Y<br />

Summarizability <strong>and</strong> <strong>co</strong>ver properties<br />

Extensions of These Cases<br />

Non-<strong>co</strong>nfluence of aggregations<br />

Identifiability <strong>and</strong> inclusion/exclusion <strong>co</strong>mputation<br />

Information<br />

Concept<br />

Topic

Generalising the Unique Name Assumption<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

population Place Inhabitants<br />

Municipality Region Area #Inhabitants AvgIn<strong>co</strong>me<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

π Region,#Inhabitants (R C ) |= {Region} −→ {#Inhabitants}<br />

σ Municipality=‘Raisdorf ′(R C ) |= {Region} −→ {#Inhabitants}<br />

meaning of attributes is different:<br />

<strong>co</strong>urtesy by A. Molnar<br />

#Inhabitants as the number of inhabitants of certain municipality<br />

#Inhabitant as the number of inhabitants in a certain region<br />

Concept<br />

Topic

S<strong>co</strong>ping <strong>and</strong> Hierarchies Mismatches<br />

✞<br />

☎<br />

✝Dis<strong>co</strong>veries of A. Molnar ✆<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

✞<br />

☎<br />

Solution: Dependency bases <strong>and</strong> existence hierarchies<br />

✝<br />

✆<br />

<strong>co</strong>urtesy<br />

by A. Molnar<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Lessons Learned<br />

(1) Explicit treatment of basic data types<br />

domains <strong>and</strong> equivalences<br />

basic operations <strong>and</strong> their semantics<br />

basic predicates <strong>and</strong> their semantics<br />

(2) Explicit definition of aggregation functions<br />

behaviour <strong>and</strong> properties of aggregation functions<br />

<strong>co</strong>mbinations of aggregation functions<br />

distributive, algebraic <strong>and</strong> holistic aggregation functions<br />

(3) Definition of cubes<br />

explicit definition of aggregations<br />

explicit h<strong>and</strong>ling of equivalence classes<br />

definition of operations<br />

Content<br />

Information<br />

Concept<br />

Topic

Basic Data Types<br />

Extended basic data type B = (Dom(B), Op(B), Pred(B), Υ)<br />

algebraic system (Malzev!) (homomorphism are different)<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Equivalence relations eq on Dom(B)<br />

Each of these equivalence relations defines a<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

partition Π eq of the domain into equivalence classes<br />

Equivalence classes c may be named by n c<br />

Named partitions by Π ∗<br />

trivial named partition (⊥ ∗ , fine)<br />

top named partition: (⊤ ∗ , B)<br />

Content<br />

Information<br />

Concept Topic<br />

Equivalence relations <strong>and</strong> partitions may be <strong>order</strong>ed<br />

⊥ ∗ ≼ Π ∗ <strong>and</strong> Π ∗ ≼ ⊤ ∗

The Lattice of One Basic Data Type<br />

B = (Dom(B), Op(B), Pred(B), Υ)<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Canonical <strong>order</strong> of partitions on DOM (B): Π ∗ ≼ Π ′∗<br />

for all (c, n c ) from Π ∗ there exists one <strong>and</strong> only<br />

one element (c ′ , n c ′) ∈ Π ′∗ such that c ⊆ c ′ .<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

Majority <strong>order</strong> (c, n c ) ≼ choice<br />

m (c ′ , n c ′):<br />

either |c ∩ c ′ | > max{|c ∩ c ′′ | | (c ′′ , n c ′′) ∈ Π ′∗ , c ′′ ≠ c ′ }<br />

or (c ′ , n c ′) ∈ Π ′∗ is determined by<br />

a (deterministic) choice operator among<br />

{c + ∈ Π ′∗ | |c ∩ c + | = max{|c ∩ c ′′ | | (c ′′ , n c ′′) ∈ Π ′∗ }}.<br />

Omit the choice operator in ≼ choice<br />

m if <strong>co</strong>ntext determines<br />

DateTime: eq hour , eq day<br />

partitions ⊥ ∗ , Days, Weeks, Months, Quarters, Years, <strong>and</strong> ⊤ ∗<br />

Days ≼ Months ≼ Quarters ≼ Years.<br />

Weeks ≼ m Months

Combination of Lattices<br />

✞<br />

☎<br />

Is Application-Dependent<br />

✝<br />

✆<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

Combination of<br />

characterisations (time, region, ...)<br />

characterisations <strong>and</strong> <strong>entity</strong> types (sales within a region)<br />

Germany: Municipality - Region - County - Country<br />

versus Store - Chain area - Chain subregion - Sales region<br />

Hungary: Telespülés - Kistérség - Megye - Régió - Country versus Store<br />

US: City - State -Country versus Store - Sale region<br />

Mexi<strong>co</strong>: City - State versus Store - Sale region (States are parts)<br />

Canada: City - Province versus Store - Sale region (Provinces are parts)<br />

different meanings of characterisations, e.g. time, business time,<br />

academic time, ac<strong>co</strong>unting time<br />

overlay, multiway partitioning, naming <strong>co</strong>nventions, attributes suffering by aggregation,<br />

structuring, navigation facilities, <strong>co</strong>nstraints<br />

errors in union <strong>and</strong> intersection: without derived attributes (unless they are already algebraic)<br />

join must by redefined

Aims <strong>and</strong> assumptions<br />

Aggregation<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

Grouping of data, re<strong>co</strong>rds, objects based on selections<br />

Summarisability depending on <strong>co</strong>mpleteness <strong>and</strong> disjointness assumptions<br />

Invariance properties of aggregation operators<br />

for-<br />

Harmonisation of aggregation <strong>and</strong> abstraction without<br />

getful h<strong>and</strong>ling<br />

Preservation or transformation of semantics or explicit semantics<br />

transformation<br />

Derivation of repair functions in the case of demages<br />

Detection of misleading aggregations <strong>and</strong> prevention from misapplication<br />

Concept<br />

Topic

Aggregation Functions: General Definition<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

Family F = {f 0 , ...., f k , ..., f ω }<br />

f k : Bag k → Num (maps a bag on dom(M j ) with k elements<br />

to a numerical range Num)<br />

Minimum preserving: f k (min, ...., min) = min Num min ∈ dom(M j )<br />

Maximum preserving: f k (max, ..., max) = max Num max ∈ dom(M j )<br />

Monotone ac<strong>co</strong>rding to the <strong>order</strong> of dom(M j ) <strong>and</strong> T (k ≥ 1)<br />

Idempotent: f k (x, ...., x) = x for all x ∈ dom(M j )<br />

Continuous: lim x i →x f (x i ) = f (x) for all sequences x i of size k<br />

Lipschitz property: |f k (x 1 , ..., x k ) − f k (y 1 , ..., y k )|<br />

≤ c ∑ n<br />

i=1 |x i − y j | for some <strong>co</strong>nstant c<br />

Symmetric: f k (x 1 , ..., x k ) = f k (x ρ(1) , ..., x ρ(k) ) for any k-permutation ρ<br />

Self-identical: f k (x 1 , ..., x k ) = f k+1 (x 1 , ..., x k , f k (x 1 , ..., x k ))<br />

Shift-invariant: f k (x 1 + b, ..., x k + b) = f k (x 1 , ..., x k ) + b<br />

Homogeneous: f k (bx 1 , ..., bx k ) = bf k (x 1 , ..., x k )<br />

Additive: f k (x 1 + y 1 , ..., x k + y k ) = f k (x 1 , ..., x k ) + f k (y 1 , ..., y k )<br />

Associative: f r (f k1 (x 1 ), ..., f kr (x r )) = f k1 +...+k r<br />

(x 1 , ..., x r )

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

Aggregation Functions: Properties<br />

✞<br />

☎<br />

Be careful with the average functions used for OLAP<br />

✝<br />

✆<br />

max, min are minimum preserving, maximum preserving, idempotent,<br />

<strong>co</strong>ntinuous, symmetric, self-identical, additive, homogeneous,<br />

associative, <strong>and</strong> obey the Lipschitz property,<br />

sum is 1-minimum preserving, 1-maximum preserving, 1-monotone,<br />

<strong>co</strong>ntinuous, symmetric, homogeneous, additive, associative, obeys<br />

the Lipschitz property, <strong>and</strong><br />

not idempotent, not self-identical, not shift-invariant,<br />

avg is minimum preserving, maximum preserving, 1-monotone,<br />

idempotent, <strong>co</strong>ntinuous, symmetric, shift-invariant, homogeneous,<br />

additive, obeys the Lipschitz property,<br />

is not self-identical, not associative,<br />

<strong>co</strong>unt is <strong>co</strong>ntinuous, symmetric, associative, obeys the Lipschitz<br />

property,<br />

not idempotent, not self-identical, not shift-invariant, not homogeneous,<br />

not additive.<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

Classes of Aggregation Functions:<br />

Distributive (Inductive) Functions<br />

preserving partitions of sets<br />

∀f ∃g f (X ) = g(f (X 1 ), ..., f (X n ))<br />

X = X 1 ∪ X 2 ∪ ... ∪ X n , X i ∩ X j = ∅ , i ≠ j<br />

types T , T ′ , <strong>co</strong>llection type C T on T , operations ∪ C T , ∩ C T , ∅ C T<br />

h 0 ∈ T ′ h 1 : T → T ′ h 2 : T ′ × T ′ → T ′<br />

srec h0 ,h 1 ,h 2<br />

(∅ C T ) = h 0<br />

srec h0 ,h 1 ,h 2<br />

(|{|s|}|) = h 1 (s)<br />

for |{|s|}|<br />

srec h0 ,h 1 ,h 2<br />

(R C 1 ∪ C T R C 2 ) = h 2 (srec h0 ,h 1 ,h 2<br />

(R C 1 ), srec h0 ,h 1 ,h 2<br />

(R C 2 ))<br />

iff R1 C ∩ C T R2 C = ∅ C T<br />

sum = srec 0,Id,+ for relations without nulls<br />

sum null<br />

on C T<br />

0 = srec 0,h 0<br />

Id<br />

,+ h 0 f (s) = {<br />

0 if s = NULL<br />

sum null<br />

undef<br />

= srec 0,h undef ,+ h undef<br />

f (s) =<br />

Id<br />

f (s) if s ≠ NULL<br />

{<br />

undef if s = NULL<br />

f (s)<br />

if s ≠ NULL<br />

<strong>co</strong>unt = srec 0,1,+ <strong>co</strong>unt null<br />

1 = srec 0,h 0<br />

1 ,+, <strong>co</strong>unt null<br />

undef = srec 0,h undef<br />

1 ,+<br />

max = srec NULL,Id,max min = srec NULL,Id,min for sets, bags<br />

max, max undef are different functions<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Classes of Aggregation Functions:<br />

Algebraic Functions<br />

Finite algebraic expressions based on distributive functions<br />

average:<br />

(++)<br />

remember SQL x 0 = 0<br />

sum<br />

<strong>co</strong>unt<br />

(SQL!?) sumnull 0<br />

<strong>co</strong>unt<br />

(+?!) sumnull undef<br />

<strong>co</strong>unt<br />

(??)<br />

(+!)<br />

sum<br />

<strong>co</strong>unt null<br />

1<br />

sum null<br />

0<br />

<strong>co</strong>unt null<br />

1<br />

(??) sumnull undef<br />

<strong>co</strong>unt null<br />

1<br />

(??)<br />

(??)<br />

(++)<br />

sum<br />

<strong>co</strong>unt null<br />

undef<br />

sum null<br />

0<br />

<strong>co</strong>unt null<br />

undef<br />

sum null<br />

undef<br />

<strong>co</strong>unt null<br />

undef<br />

variance ( ∑ k (x k − EX ) 2 · p k EX = ∑ k x k · p k )<br />

ratio values (e.g. <strong>co</strong>nsumption)<br />

most of them can be extended to distributive functions<br />

e.g. avg null<br />

0,1<br />

based on <strong>order</strong>ing on pairs (value, occ#)<br />

Content<br />

Information<br />

Concept<br />

Topic

Classes of Aggregation Functions: Holistic<br />

Functions<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

the vast majority of functions<br />

no storage bound for <strong>co</strong>mputing sub-aggregates<br />

mostFrequent, n-mostFrequent<br />

statistical <strong>and</strong> financial median<br />

rank<br />

averageDeviation<br />

geometric key-area <strong>co</strong>mputations<br />

<strong>co</strong>mputable over temporal views (on temporal views ...)<br />

distinction between raw data <strong>and</strong> ‘data’<br />

maintenance of identification be<strong>co</strong>mes the main issue<br />

data warehouse data<br />

versions of data, temporality<br />

Content<br />

Information<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Invariance of Functions<br />

Given: aggregation function ψ<br />

database function f ,<br />

e.g., view function, selection function<br />

Problem: does the application of f change the aggregation ?<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Can we delay <strong>co</strong>mputation of aggregation to the view?<br />

Is there a need to <strong>co</strong>mpute results based on raw data only?<br />

D<br />

ψ<br />

❄ ✙<br />

ψ(D) = ψ(f (D))<br />

f<br />

✲<br />

ψ<br />

f (D)<br />

f is<br />

ψ-invariant<br />

in D<br />

if<br />

ψ(f (D)) = ψ(D)<br />

Information<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Invariance Examples<br />

Bag2Set: (DISTINCT)<br />

• min-, max-invariant<br />

• not sum-invariant<br />

sum-invariant for sets<br />

• not avg-invariant<br />

avg-invariant for sets without NULL’s<br />

Project: invariant for all distributive functions<br />

Select, Join: not invariant for most aggregation functions<br />

Union, Difference, Intersection: mostly not invariant<br />

Renaming: invariant for all aggregation functions<br />

Content<br />

Information<br />

Concept<br />

Topic

Repairing Approaches<br />

1. Aggregation Transformation<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

D<br />

Aggregation function<br />

ψ<br />

ψ(D)<br />

❄<br />

Abstraction function<br />

f<br />

Abstraction function<br />

F<br />

Problem: find the f -transformation Ψ f<br />

infeasible<br />

of ψ<br />

✲<br />

f (D)<br />

Aggregation function<br />

Ψ f<br />

✲<br />

❄<br />

Ψ f (f (D))<br />

=<br />

F (ψ(D))<br />

Content<br />

Information<br />

Concept<br />

Topic

Repairing Approaches<br />

1. Aggregation Transformation<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

D<br />

Aggregation function<br />

ψ<br />

ψ(D)<br />

❄<br />

Abstraction function<br />

f<br />

Abstraction function<br />

F<br />

Problem: find the f -transformation Ψ f<br />

infeasible<br />

of ψ<br />

✲<br />

f (D)<br />

Aggregation function<br />

Ψ f<br />

✲<br />

❄<br />

Ψ f (f (D))<br />

=<br />

F (ψ(D))<br />

Content<br />

Information<br />

Concept<br />

Topic

Repairing Approaches<br />

2. Preparing Explicit Aggregation<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

g - ψ-supplement of f<br />

∃ψ ∗ ∀D ψ ∗ (g(f (D), D)) = ψ(D)<br />

D<br />

✲<br />

(f , g)<br />

g(f (D), D)<br />

ψ ψ ∗<br />

❄ ✰<br />

ψ(D) = ψ ∗ (g(f (D), D))<br />

Supposition: g is based on the mapping of algebraic functions to distributive<br />

functions<br />

Content<br />

Information<br />

Concept<br />

Topic

Observation Supporting the Supposition<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

supplement function which generates the occurrence number for each<br />

value<br />

for instance for<br />

f = Bag2Set<br />

sum ∗ = srec 0,h,+ for h((v, n)) = n · v<br />

<strong>co</strong>unt ∗ = srec 0,h ′ ,+<br />

for h((v, n)) = n , <strong>co</strong>unt = srec 0,1,+<br />

avg null<br />

0,1 = sumnull 0<br />

<strong>co</strong>unt null<br />

avg null∗<br />

0,1 = sumnull∗ 0<br />

1<br />

<strong>co</strong>unt null∗<br />

1<br />

extended to<br />

Content<br />

Information<br />

Concept<br />

Topic

Behavior of Aggregation Functions<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Subset sensitivity: For given D, ψ <strong>and</strong> a selection <strong>co</strong>ndition α:<br />

ψ(D) ≠ ψ(σ α (D))<br />

All classical aggregation functions are subset-sensitive.<br />

Critical operations: selection, join, intersection, difference<br />

Object invariance: All objects are residing after application of the<br />

operation.<br />

Object-invariant functions are min- <strong>and</strong> max-invariant.<br />

Value-set invariance: All values of the domain <strong>co</strong>nsidered are remaining.<br />

Set-value invariant functions are min- <strong>and</strong> max-invariant.<br />

Content<br />

Information<br />

Concept<br />

Topic

Behavior within Hierarchies<br />

Poly-Hierarchy Lattices<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

generalizing the characteristic function h to Boolean lattices of classes<br />

C 1 , ..., C m :<br />

L(C i1 , ...C in ) - intersection C i1 ,..., C in<br />

<strong>co</strong>unting based on the exclusion/inclusion property:<br />

ψ(D) = ∑ m<br />

i=1 ψ(C i) − ∑ m−1<br />

j =1<br />

∑ n<br />

k=j +1 ψ(L(C j , C k )) + −...<br />

+(−1) r−1 ∑ 1≤j 1

Algebraic Aggregation Functions<br />

H<strong>and</strong>ling Through Distributive Functions<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Extended<br />

aggregation<br />

function<br />

Example: average<br />

D<br />

❄<br />

ψ ∗ (D)<br />

Aggregation✲<br />

function<br />

✸<br />

h1({s}) = (1, s)<br />

ψ(D)<br />

Forgetful<br />

functor<br />

h2((i, k)(j , l)) = (i + j , i · k + j · l<br />

i + j<br />

)<br />

Content<br />

Information<br />

Concept<br />

Topic

Supplements for Algebraic Functions<br />

Given a database abstraction f <strong>and</strong> an algebraic aggregation function<br />

ψ. If a ψ-supplement g of f exists then the function ψ ∗ is distributive.<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Collapseability along MVD Trees<br />

Collapsing along MVD trees is invariant for distributive functions.<br />

Collapsing along MVD trees is invariant for algebraic functions.<br />

Term algebras might not exist<br />

Distributive functions can be <strong>co</strong>ncatenated. Algebraic functions are not<br />

<strong>co</strong>ncatenatable.<br />

Content<br />

Information<br />

Concept<br />

Topic

Data Cube Definition (1)<br />

Grounding schema of a cube: (cube) <strong>relationship</strong> type<br />

R = (R 1 , ...., R n , {(A 1 , q 1 , f 1 ), ..., (A m , q m , f m )})<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

hierarchical types R 1 , ...., R n<br />

forming <strong>co</strong>mponent (or dimension) types<br />

(“fact”) attributes A 1 , ..., A m<br />

defined over extension based data types<br />

instantiated by singleton-value queries q 1 , ..., q m<br />

aggregation functions f 1 , ..., f m defined for A 1 , ..., A m<br />

defined over B 1 , ..., B n<br />

typically defined by a view over a database schema<br />

Notice: also hidden attributes<br />

Content<br />

Information<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Data Cube Definition (2)<br />

grounding schema R = (R 1 , ...., R n , {(A 1 , q 1 , f 1 ), ..., (A m , q m , f m )})<br />

class R C ,<br />

partitions Π i on DOM (R i ) for any <strong>co</strong>mponent R 1 , ..., R n<br />

cell of R C : non-empty set σ R1 ∈c 1 ,...R n ∈c n<br />

(R C )<br />

for c i ∈ Π i <strong>and</strong> σ α<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

named partitions Π ∗ 1, ..., Π ∗ n for all <strong>co</strong>mponent types<br />

cube cube Π∗ 1 ,...,Π∗ n (R C ) on R C <strong>and</strong> on Π ∗ i , 1 ≤ i ≤ n:<br />

{σ R1 ∈c 1 ,...R n ∈c n<br />

(R C ) ≠ ∅ | c 1 ∈ Π 1 , ..., c n ∈ Π n }<br />

of cells of R C<br />

for named partitions Π ∗ i , 1 ≤ i ≤ n<br />

Information<br />

If Π ∗ i<br />

= ⊤ ∗ then we may omit the partition Π ∗ i<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Essentials <strong>and</strong> Differences of the Cube<br />

OLAP cube definition<br />

flat hierarchies (e.g. time instead of time equivalence)<br />

instead of heterogeneous, application dependent deep hierarchies<br />

attributes<br />

• hidden (invisible in the cube) attributes<br />

• aggregation functions f B ɛ 1<br />

j<br />

,...,ɛ B n (R C )<br />

1 jn<br />

• semantics <strong>and</strong> meaning changes after OLAP operations<br />

partiality of data existence <strong>and</strong> cube breaks through<br />

dependency preserving operations<br />

Content<br />

Information<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Operations of the Data Cube<br />

cube cube Π∗ 1 ,...,Π∗ n (R C )<br />

on R = (R 1 , ...., R n , {(A 1 , q 1 , f 1 ), ..., (A m , q m , f m )})<br />

given for a dimension i<br />

<strong>and</strong> partitions Π ∗ i ≼ Π ′∗<br />

i ≼ ⊤ ∗ i<br />

Basic drill-down functions map cube Π∗ 1 ,...,Π′∗ i ,...,Π∗ n (R C ) to<br />

cube Π∗ 1 ,...,Π∗ i ,...,Π∗ n (R C ).<br />

Basic roll-up functions map cube Π∗ 1 ,...,Π∗ i ,...,Π∗ n (R C ) to<br />

cube Π∗ 1 ,...,Π′∗ i ,...,Π∗ n (R C ).<br />

Basic slice functions map cube Π∗ 1 ,...,Π∗ n (R C ) to<br />

σ α (cube Π∗ 1 ,...,Π∗ n (R C )).<br />

Basic dice functions map cube Π∗ 1 ,...,Π∗ i ,...,Π∗ n (R C ) to<br />

cube Π∗ 1 ,...,⊤∗ i ,...,Π∗ n (R C )<br />

Information<br />

Concept<br />

Topic

Operations of the Data Cube<br />

cube cube Π∗ 1 ,...,Π∗ n (R C ) on R = (R 1 , ...., R n , {(A 1 , q 1 , f 1 ), ..., (A m , q m , f m )})<br />

a dimension i, Π ∗ i ≼ Π′∗ i ≼ ⊤ ∗ i<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Roll-up functions are the inverse of drill-down functions.<br />

Basic slice functions are definable through cells:<br />

dimension(α): set of all dimensions that are restricted by α<br />

⎧<br />

⎨<br />

σα(c ⊓ ∅ if R i ∈ dimension(α) ∧ σ α (c i ) ≠ c i<br />

i ) =<br />

⎩ c i otherwise<br />

Eager slice functions restrict cube cells to those that entirely fulfill the selection<br />

criterion α,<br />

{σ R1 ∈σα ⊓(c 1),...R n ∈σα ⊓(c n )(R C ) ≠ ∅ | c 1 ∈ Π 1 , ..., c n ∈ Π n }<br />

Liberal slice functions restrict cells to those that partially fulfill the selection<br />

criterion α,<br />

{σ R1 ∈σ α (c 1 ),...R n ∈σ α (c n )(R C ) ≠ ∅ | c 1 ∈ Π 1 , ..., c n ∈ Π n }.<br />

Content<br />

Information<br />

Basic dice functions similar to projection<br />

full roll-up functions<br />

Concept<br />

Topic

Constraints <strong>and</strong> Operations on the Cube<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Student Id<strong>entity</strong> Personal Study characteristics<br />

StudNo Address Major Semester registered<br />

... ... .... ....<br />

different meaning of <strong>co</strong>nstraints <strong>and</strong> thus different behaviour:<br />

{ StudNo } −→ { Address }<br />

{ StudNo } −→ { Major }<br />

{ StudNo } → { Semester registered }<br />

<strong>co</strong>unt(dice Semester registered (R C ))<br />

<strong>co</strong>unt(dice StudNo (R C ))<br />

<strong>co</strong>unt(dice Semester (dice StudNo (R C )))<br />

semester overall for students<br />

# of students per semester, address(?), major<br />

# for address, major <strong>co</strong>mbinations<br />

Content<br />

Information<br />

Concept<br />

Topic

Extended Cube Schemata<br />

given cube cube Π∗ 1 ,...,Π∗ n (R C ) on<br />

R = (R 1 , ...., R n , {(A 1 , q 1 , f 1 ), ..., (A m , q m , f m )})<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

the cube operation O<br />

maps cube Π∗ 1 ,...,Π∗ n (R C ) to<br />

O(cube Π∗ 1 ,...,Π∗ n (R C ))<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

new cube schema<br />

R = (R 1 , ...., R n , {(A 1 , q 1 , f 1 ), ..., (A i , q i , f i , O)(A m , q m , f m )})<br />

re<strong>co</strong>rding the history of <strong>co</strong>mputation through expressions<br />

Content<br />

Information<br />

Concept<br />

Topic

Special Issues<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Multi-layered semantics depending on operations <strong>and</strong> changing<br />

the meaning of attributes<br />

Forgetting semantics: projection results in independence instead of<br />

hidden dependence<br />

Hidden structures are necessary for <strong>co</strong>rrectness<br />

are also essential for <strong>co</strong>rrect <strong>co</strong>mputation<br />

e.g. algebraic functions<br />

roll-up then by approximation functions<br />

rough values<br />

Hidden auxiliary functions <strong>and</strong> structures e.g. for repair<br />

Content<br />

Information<br />

Concept<br />

Topic

Some General Results<br />

Roll-up functions are neither sum-invariant nor avg-invariant in general.<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Roll-up functions are not min- or max-invariant in general.<br />

Rearrangement functions are min-, max-, sum- <strong>and</strong> avg-invariant.<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

Summarizability cannot be obtained for relations after application of<br />

any subset-generating function.<br />

Summarizing is <strong>co</strong>rrect for union of classes if an exclusion <strong>co</strong>nstraint<br />

is valid for classes to which union is applied.<br />

Summarizability cannot be maintained for functions after application<br />

of which identification of objects is lost.<br />

Summarizability cannot be obtained trough <strong>co</strong>llapsing hierarchies.<br />

Concept<br />

Topic

Some General Extensions<br />

Summarizability cannot be obtained moving up to generalizations of<br />

classes.<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Summarizability is maintained moving downwards through functional<br />

dependencies.<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Summarizability is <strong>co</strong>rrect on separting <strong>co</strong>llapsing hierarchies if the<br />

portion is used for the supplement.<br />

Summarizability can be maintained on the basis of identification<br />

properties of values.<br />

Content<br />

Information<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

The Good Message<br />

✞<br />

☎<br />

EER Functions Enable Complete OLAP<br />

✝<br />

✆<br />

operations on views (selection as dice, projection as slice, generalized<br />

relational algebra)<br />

calculation functions, visualization functions<br />

group-by as roll-up (drill-up), un-nest as drill-down<br />

schema restructuring operation for unfold (e.g., drill-down), fold<br />

(nest), classification<br />

B. Thalheim, Entity-Relationship Modeling –<br />

Foundations of Database Technology.<br />

Springer 2000, 640pp.<br />

Content<br />

Information<br />

Concept<br />

Topic

Modelling Assumptions: Drill-Down<br />

Functions<br />

De<strong>co</strong>mposing groups of data along a hierarchy, refine grouping<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Observation 1.<br />

Drill-down functions are well defined if the cube <strong>co</strong>nstruction is based<br />

on disjointness <strong>and</strong> <strong>co</strong>mpleteness <strong>modelling</strong> assumptions.<br />

Observation 2.<br />

Drill-down functions are well defined if data granularity is guaranteed<br />

at leaf level L 1 <strong>and</strong> no structural null are used at any level L i (i > 1)<br />

in between.<br />

Content<br />

Information<br />

Concept<br />

Topic

Modelling Assumptions: Roll-Up Functions<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

used for <strong>co</strong>mbining groups along a hierarchy, i.e., for fusion of groups.<br />

Problematic for <strong>co</strong>llapsing hierarchies<br />

especially in the case of algebraic <strong>and</strong> holistic aggregation functions<br />

Observation 3.<br />

Roll-up functions are only well-defined if data granularity is guaranteed<br />

at leaf level L 1 <strong>and</strong> no structural null are used at any level L i<br />

(i > 1) in between.<br />

Observation 4.<br />

Roll-up functions must be query-invariant, i.e. for the roll-up function<br />

f <strong>and</strong> the query function ψ:<br />

ψ(¯x 1 , ...¯x n ) = ψ(f (¯x 1 ), ...., f (¯x n )) .<br />

Observation 5.<br />

The Simpson paradox is observed if for groups at roll-up level L p ≼<br />

L r<br />

(∀j (f (G ij ) < f (G kj ))) ⇏ f ( ∑ n<br />

j =1 G ij ) < f ( ∑ n<br />

j =1 G kj )<br />

Concept<br />

Topic

Modelling Assumptions: Dice Functions<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

projection, marginalization (statistics),<br />

unproblematic for distributive functions<br />

∑<br />

unions of values<br />

<strong>co</strong>mbinable with repairing functions<br />

Observation 6.<br />

The Simpson paradox is observed if for groups at roll-up level L p<br />

(∀j (f (G ij ) < f (G kj ))) ⇏ f ( ∑ n<br />

j =1 G ij ) < f ( ∑ n<br />

j =1 G kj )<br />

≼ L r<br />

Observation 7.<br />

Dice functions can only <strong>co</strong>rrectly be applied if the cube <strong>co</strong>nstruction is based<br />

on union invariance, i.e. aggr(⊔ ∗ o∈G i<br />

value(o)) = ⊔ ∗ o∈G i<br />

(aggr(value(o))) for<br />

groups G i along dimensions.<br />

If f is distributive then the ⊔ ∗ ≡ f .<br />

If f is algebraic then repair functions must be applied.<br />

Observation 8.<br />

Dice functions can only be used along dimensions for which <strong>co</strong>nstraints among<br />

cube dimensions are not lost, i.e. Σ| π(X ) |= π(X )(Σ).<br />

Observation 9.<br />

Dice functions must be based on disjointness <strong>and</strong> <strong>co</strong>mpleteness <strong>modelling</strong> assumptions.

Modelling Assumptions: Slice Functions<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Requirement for applicability: query-invariance,<br />

for the roll-up function f <strong>and</strong> the query function ψ:<br />

ψ(¯x 1 , ...¯x n ) = ψ(f (¯x 1 ), ...., f (¯x n )) .<br />

Observation 10.<br />

Slice functions must be subset invariant.<br />

Constraints invalidated by subset <strong>co</strong>nstruction are those integrity <strong>co</strong>nstraints<br />

that have to be expressed through ∀∃-<strong>co</strong>nstraints, e.g., inclusion<br />

dependencies, multivalued dependencies, tuple-generating <strong>co</strong>nstraints.<br />

Content<br />

Information<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Information<br />

Modelling Assumptions: OLTP-OLAP<br />

Transformations<br />

Modelling pragmatism, e.g.,<br />

instead of arithmetic average function: mean average, weighted average, root<br />

mean square, average mean, moving average, weighted average<br />

very sensitive to extreme values such as outliers <strong>and</strong> may be distorted by them<br />

arithmetic averages may be normalized by skew functions<br />

Averages are measures of central tendency. The median is the middle-most value in<br />

an <strong>order</strong>ed set.<br />

Observation 11.<br />

Application of median instead of mean average functions for aggregation leads<br />

to more stable OLAP query operations.<br />

Observation 12.<br />

Harmonic mean functions<br />

n ∑ n<br />

i=1 1 x i<br />

are shift-invariant, additive, symmetric, <strong>co</strong>ntinuous,<br />

<strong>and</strong> homogeneous.<br />

Observation 13.<br />

Geometric mean functions n√ x 1 · x 2 · ... · x n provide a better picture for relative<br />

scales among values <strong>and</strong> are OLAP query invariant.<br />

Observation 14.<br />

The sampling frequency must be based on the Sampling Theorem <strong>and</strong> the<br />

generalizations of Nyquist.<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Publications on Science <strong>and</strong> Art of<br />

Conceptual Modelling<br />

A. Dahanayake <strong>and</strong> B. Thalheim. Towards a framework for emergent modeling. In ER Workshops,<br />

volume 6413 of Lecture Notes in Computer Science, 128–137. Springer, 2010.<br />

A. Dahanayake <strong>and</strong> B. Thalheim. Enriching <strong>co</strong>nceptual <strong>modelling</strong> practices through <strong>design</strong><br />

science. In BMMDS/EMMSAD, volume 81 of Lecture Notes in Business Information Processing,<br />

497–510. Springer, 2011.<br />

B. Thalheim. Towards a theory of <strong>co</strong>nceptual <strong>modelling</strong>. Journal of Universal Computer Science,<br />

2010, 16, 20, 3102–3137.<br />

B. Thalheim. The theory of <strong>co</strong>nceptual models, the theory of <strong>co</strong>nceptual <strong>modelling</strong> <strong>and</strong> foundations<br />

of <strong>co</strong>nceptual <strong>modelling</strong>. In The H<strong>and</strong>book of Conceptual Modeling: Its Usage <strong>and</strong> Its<br />

Challenges, chapter 12, 543–578. Springer, Berlin, 2011.<br />

B. Thalheim. The science of <strong>co</strong>nceptual <strong>modelling</strong>. In Proc. DEXA 2011, volume 6860 of LNCS,<br />

12–26, Berlin, 2011. Springer.<br />

B. Thalheim. Integrity <strong>co</strong>nstraints in (<strong>co</strong>nceptual) database models. In The Evolution of Conceptual<br />

Modeling, volume 6520 of Lecture Notes in Computer Science, 42–67, Berlin, 2011.<br />

Springer.<br />

B. Thalheim. The art of <strong>co</strong>nceptual <strong>modelling</strong>. In Proc. EJC 2011, 203–222, Tallinn, 2011.<br />

B. Thalheim. Culture <strong>and</strong> art of <strong>co</strong>nceptual <strong>modelling</strong>. Anwendungsorientierte Organisationsgestaltung,<br />

127–144. baar, Hamburg, 2011.<br />

Content<br />

Information<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

Publications on Model Suites, Evolution,<br />

Migration<br />

A. Dahanayake <strong>and</strong> B. Thalheim. Co-evolution of (information) system models. In EMMSAD<br />

2010, volume 50 of LNBIP, 314–326. Springer, 2010.<br />

A. Dahanayake <strong>and</strong> B. Thalheim. Towards a framework for emergent modeling. In ER Workshops,<br />

volume 6413 of Lecture Notes in Computer Science, 128–137. Springer, 2010.<br />

M. Klettke <strong>and</strong> B. Thalheim. Evolution <strong>and</strong> migration of information systems. In The H<strong>and</strong>book<br />

of Conceptual Modeling: Its Usage <strong>and</strong> Its Challenges, chapter 12, 381–420. Springer, Berlin,<br />

2011.<br />

B. Neumayr <strong>and</strong> M. Schrefl und B. Thalheim. Modeling techniques for multi-level abstraction.<br />

In The Evolution of Conceptual Modeling, volume 6520 of Lecture Notes in Computer Science,<br />

68–92, Berlin, 2011. Springer.<br />

B. Thalheim. Model suites. In H. Jaakkola, editor, Selected Topics on Distributed Disaster<br />

Management: Towards Collaborative Knowledge Clusters., 108 – 128. Tampere University Press,<br />

Porin yksikkö, 2008.<br />

B. Thalheim. The <strong>co</strong>nceptual framework to multi-layered database <strong>modelling</strong>. In Proc. EJC,<br />

118–138, Maribor, Slovenia, 2009.<br />

B. Thalheim. Model suites for multi-layered database <strong>modelling</strong>. In Information Modelling<br />

<strong>and</strong> Knowledge Bases XXI, volume 206 of Frontiers in Artificial Intelligence <strong>and</strong> Applications,<br />

116–134. IOS Press, 2010.<br />

Information<br />

Concept<br />

Topic

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Publications on Tool-Based Development<br />

M. Albrecht, M. Altus, E. Buchholz, H. Cyriaks, A. Düsterhöft, J. Lewerenz, H. Mehlan, M. Steeg,<br />

K.-D. Schewe, <strong>and</strong> B. Thalheim.<br />

RADD - Rapid application <strong>and</strong> database development. Readings<br />

- Main papers published in the RADD project.<br />

CAU Kiel, Department of Computer Science,<br />

http://www.is.informatik.uni-kiel.de/∼thalheim/indeeerm.htm, 1998.<br />

G. Fiedler, H. Jaakkola, T. Mäkinen, B. Thalheim, <strong>and</strong> T. Varkoi. Co-<strong>design</strong> of web information systems<br />

supported by SPICE. Information Modelling <strong>and</strong> Knowledge Bases, XIX, 2009.<br />

H. Jaakkola <strong>and</strong> B. Thalheim. A framework for high quality software <strong>design</strong> <strong>and</strong> development: A<br />

systematic approach. IET Software, 2010. to appear.<br />

H. Ma, K.-D.Schewe, B. Thalheim, <strong>and</strong> J. Zhao. View integration <strong>and</strong> <strong>co</strong>operation in databases, data<br />

warehouses <strong>and</strong> web information systems. Journal on Data Semantics, LNCS 3730, 213–249, 2005.<br />

M. Steeg. RADD/raddstar - A rule-based database schema <strong>co</strong>mpiler, evaluator, <strong>and</strong> optimizer. PhD<br />

thesis, BTU Cottbus, Computer Science Institute, Cottbus, October 2000.<br />

B. Thalheim. Entity-<strong>relationship</strong> modeling – Foundations of database technology. Springer, Berlin,<br />

2000.<br />

B. Thalheim, K.-D. Schewe, <strong>and</strong> Hui Ma. Conceptual application domain <strong>modelling</strong>. In APCCM,<br />

volume 96 of CRPIT, 49–57. Australian Computer Society, 2009.<br />

B. Thalheim. Co-<strong>design</strong> of structuring, functionality, distribution, <strong>and</strong> interactivity of large information<br />

systems. Technical Report 15/03, BTU Cottbus, Computer Science Institute, Cottbus, September 2003.<br />

190pp.<br />

B. Thalheim. Conceptual modeling in information systems engineering. In J.Krogstie <strong>and</strong> A. Lothe,<br />

editors, Challenges to Conceptual Modelling, 59–74, Berlin, 2007. Springer.<br />

Content<br />

Information<br />

Concept<br />

Topic

Publications on Pattern Development<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

Content<br />

T. Feyer, K.-D. Schewe, <strong>and</strong> B. Thalheim. Conceptual <strong>design</strong> <strong>and</strong> development of information<br />

services. In Proc. ER’98, LNCS 1507, Springer, 1998, 7–20. Springer, Berlin, 1998.<br />

T. Feyer <strong>and</strong> B. Thalheim. Many-dimensional schema modeling. In ADBIS 2002, LNCS 2435,<br />

305–318. Springer, 2002.<br />

T. Feyer <strong>and</strong> B. Thalheim. A model for defining <strong>and</strong> <strong>co</strong>mposing interaction pattern. In EJC’2002,<br />

volume Information Modelling <strong>and</strong> Knowledge Bases XIV, 277–289, 2002.<br />

Hui Ma, K.-D. Schewe, <strong>and</strong> B. Thalheim. Modelling <strong>and</strong> maintenance of very large database<br />

schemata using meta-structures. In UNISCON, volume 20 of Lecture Notes in Business<br />

Information Processing, 17–28. Springer, 2009.<br />

K.-D. Schewe <strong>and</strong> B. Thalheim. Development of <strong>co</strong>llaboration frameworks for web information<br />

systems. In IJCAI’07 (20th Int. Joint Conf on Artificial Intelligence), Section EMC’07<br />

(Evolutionary models of <strong>co</strong>llaboration), 27–32, Hyderabad, 2007.<br />

B. Thalheim. Many-dimensional database modeling on the basis of application frameworks.<br />

Technical Report Preprint I-08-2000, Br<strong>and</strong>enburg University of Technology at Cottbus, Institute<br />

of Computer Science, 2000.<br />

B. Thalheim. The person, organization, product, production, <strong>order</strong>ing, delivery, invoice, ac<strong>co</strong>unting,<br />

budgeting <strong>and</strong> human resources pattern in database <strong>design</strong>. Technical Report I-07-2000,<br />

Computer Science Institute, Br<strong>and</strong>enburg University of Technology at Cottbus, 2000.<br />

Information<br />

Concept<br />

Topic

Publications on Component Development<br />

IS<br />

Modelling<br />

by HERM<br />

3.7.2012<br />

B. Thalheim<br />

Why<br />

Structuring<br />

Null marker<br />

CoMoL<br />

Functionality<br />

Views<br />

OLAP<br />

References<br />

A. Düsterhöft <strong>and</strong> B. Thalheim. Linguistic based search facilities in snowflake-like database schemes.<br />

Data <strong>and</strong> Knowledge Engineering, 48:177–198, 2004.<br />

T. Feyer <strong>and</strong> B. Thalheim. Component-based interaction <strong>design</strong>. In EJC’2003, volume Information<br />

Modelling <strong>and</strong> Knowledge Bases XV, 19 – 36, 2003.<br />

G. Fiedler <strong>and</strong> B. Thalheim. An approach to <strong>co</strong>nceptual schema evolution. Technical report,<br />

Christian-Albrechts-Universität Kiel, 2007.<br />

K.-D. Schewe <strong>and</strong> B. Thalheim. Component-driven engineering of database applications. In Markus<br />

Stumptner, Sven Hartmann, <strong>and</strong> Yasushi Kiyoki, editors, Third Asia-Pacific Conference on Conceptual<br />

Modelling (APCCM2006), volume 53 of CRPIT, 105–114, Hobart, Australia, 2006. ACS.<br />

P. Schmidt <strong>and</strong> B. Thalheim. Component-based modeling of huge databases. In ADBIS’2004,<br />

LNCS 3255, 113–128, 2004.<br />

B. Thalheim. Component <strong>co</strong>nstruction of database schemes. In Proc. ER’02, LNCS 2503, 20–34.<br />

Springer, 2002.<br />

B. Thalheim. Component development <strong>and</strong> <strong>co</strong>nstruction for database <strong>design</strong>. Data <strong>and</strong> Knowledge<br />

Engineering, 54:77–95, 2005.<br />

B. Thalheim. Engineering database <strong>co</strong>mponent ware. In TEAA’06 post proceedings, LNCS 4473,<br />

1–15, Berlin, 2007. Springer.<br />

Content<br />

Information<br />

Concept<br />

Topic

Co-Design of Structure, Functionality,<br />

Distribution, <strong>and</strong> Interaction<br />

Eötvös Loránd University of Sciences<br />

Budapest<br />

4.7.2012<br />

Bernhard Thalheim<br />

Technologie der Informationssysteme<br />

Institut für Informatik, Christian-Albrechts-Universität zu Kiel, BRD<br />

Kolmogorow-Professor e.h. der Lomonossow-Universität Moskau

Overview<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

• Co-Design - why ?<br />

• Structuring<br />

• Functionality [behavior]<br />

• Advanced views <strong>and</strong> media types<br />

(the classical <strong>and</strong> the non-classical case)<br />

(the hidden programmer’s cave)<br />

(the long waited link)<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

• Interactivity<br />

• Making <strong>co</strong>-<strong>design</strong> working<br />

• References, <strong>co</strong>nferences, open problems<br />

(playout of scenarios, actors <strong>and</strong> interfacing)<br />

(h<strong>and</strong>ling <strong>co</strong>mplexity well-educated)<br />

Maximal exploitation of database theory <strong>and</strong> technology<br />

for intelligent information systems <strong>design</strong> support<br />

Content<br />

Information<br />

Concept<br />

Topic

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

Modeling is out<br />

SAP Chief Manager 1999: Modeling is out !<br />

but: > 20,000 + > 42,000 + > 87,000 + > 3,500,000<br />

but relational schema redundancy in the SAP data schema: ><br />

4.5<br />

but large runtime <strong>and</strong> performance problems<br />

but huge integration problems<br />

but hyper-huge development problems: instead of integration<br />

development once more<br />

but until 1999: no documentation on R/3<br />

but: heavy maintenance, installation <strong>and</strong> extension problems<br />

hyper-redundancy in SAP R/3, e.g., more than 75 address relations<br />

simple update (“change the zip for one street”) may take 2-3 days or<br />

weeks<br />

SAP database system is initialized within a two weeks time frame <strong>and</strong><br />

not less<br />

Concept<br />

Topic

Stone-age Computer Engineering<br />

No Engineering Yet<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

h<strong>and</strong>icraft programming<br />

except <strong>co</strong>mputer game industry<br />

everybody programs from scratch<br />

Are there other approaches?<br />

why pupils are programming websites?<br />

Solution A: Script <strong>language</strong>s<br />

Modeling of small programs<br />

Meta-modeling<br />

No Engineering Science Yet<br />

Content<br />

Information<br />

Concept<br />

Topic

H<strong>and</strong>ling Large Schemata Through<br />

Layered Architectures<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

Concept Topic<br />

✞<br />

☎<br />

Layered Solution<br />

✝<br />

✆

Why Do We Need Co-Design<br />

Support of work is the killer requirement<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

Ease of work is the bargain requirement<br />

Efficiency of work trigger <strong>co</strong>mpany’s choices<br />

High utility is the shopping argument<br />

Data are not the kernel<br />

Functions, procedures, triggers should support work<br />

Users need to interact in changing exchanges<br />

Users are different (<strong>co</strong>nfiguration, exception, adaptation support)<br />

Context of work is changing (high flexibility, adaptation to environment)<br />

Large variety of very different users due to <strong>co</strong>mputers omnipresence<br />

Concept<br />

Topic

The Knowledge Gap on Database Design<br />

Decisions<br />

“Partial reality”<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Things of<br />

reality<br />

Foundation of<br />

decisions<br />

✻<br />

Usage of<br />

theory<br />

❄<br />

Modality<br />

✛<br />

Part<br />

of reality<br />

✻<br />

Modeling<br />

decision<br />

✻<br />

✻<br />

Observed<br />

property<br />

✻<br />

“Topic”<br />

☛<br />

Revision<br />

during the ❯<br />

development process<br />

“Schema” as result<br />

<strong>and</strong> partial point of view<br />

of a database<br />

development process<br />

✲<br />

Predicator<br />

Context<br />

✻<br />

acts<br />

within<br />

❄<br />

Modeler<br />

✛<br />

under<br />

usage<br />

❄<br />

Reference<br />

model<br />

Information<br />

Exactness<br />

Confidence<br />

Concept<br />

Topic

Application Systems are Task-Oriented<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

• task: specification of goal-oriented actions;<br />

subtasks: workflow with activities, restricted by <strong>co</strong>nditions, data <strong>and</strong><br />

<strong>co</strong>ntext (organization, policy, environment, channel, ...)<br />

• participatory <strong>design</strong> (task analysis, user-oriented)<br />

mapped to essential <strong>design</strong> (data <strong>and</strong> function analysis)<br />

three spaces: task world, system space, interaction space<br />

• website as services (scenario of activities which can be called by the<br />

user with supporting proto<strong>co</strong>ls <strong>and</strong> delegation facilities)<br />

request, indication, response, <strong>co</strong>nfirmation<br />

(a)synchronous, layering, resource-sharing, error-robustness, <strong>co</strong>mmunication<br />

support, (temporary) workspace<br />

• generic user model <strong>and</strong> profile<br />

Content<br />

Information<br />

Concept<br />

Topic

• Oneness<br />

Requirements to Co-Design<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

• Full fledged theory underneath<br />

• Consistency, interpretability<br />

• S<strong>co</strong>ping to various aspects<br />

• Reasoning facilities<br />

• Translatability<br />

• Extensibility, scalability, integrability, performance<br />

• Team work support, tools<br />

• Methodology<br />

Content<br />

Information<br />

Concept<br />

Topic

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

State Of The Art So Far<br />

Used in practice Theoretical background<br />

Structures well done well developed strategic<br />

Earliest layer of<br />

specification<br />

Static semantics partially used well developed <strong>co</strong>nceptual<br />

Processes somehow done parts <strong>and</strong> pieces requirements<br />

Dynamic semantics<br />

some parts parts <strong>and</strong><br />

glimpses<br />

implementation<br />

Services implementations ad-hoc implementation<br />

Exchange frames intentionally done nothing implementation<br />

Interfaces intuitive nothing implementation<br />

Stories intuitive nothing implementation<br />

Late Specification, Inflexibility, <strong>and</strong> Unmaintainability<br />

extension, change management <strong>and</strong> integration be<strong>co</strong>me a nightmare<br />

Content<br />

Information<br />

Concept<br />

Topic

Languages: Extended ER + DistrLang +<br />

SiteLang<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Structuring on the basis of an extended ER model<br />

that is based on hierarchical predicate logic<br />

Functionality on the basis of HERM/LC<br />

with HERM-algebra, HERM/QBE, query forms <strong>and</strong> transactions<br />

with some kinds of dynamic integrity <strong>co</strong>nstraints, behavior<br />

GCS integrity enforcement instead of rule triggering pitfalls<br />

Interactivity in integrated form based on SiteLang<br />

description of dialogue scenes, stories, story space<br />

( actors, scenario, dialogue steps)<br />

Distribution through service specification <strong>and</strong> exchange frames<br />

Translation <strong>and</strong> transformation methods for <strong>co</strong>mpilation of <strong>design</strong> into other models<br />

(logical, physical) or XML<br />

see B. Thalheim, Entity-Relationship Modeling. Springer, Berlin, 2000<br />

Development <strong>and</strong> engineering methods for pragmatism (see my homepage)<br />

Content<br />

Information<br />

Concept<br />

Topic

Constructs of the Co-Design Languages<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Structuring as pair<br />

Structuring := ( Structure, Static Constraints)<br />

Structure as (marked) expression on <strong>co</strong>nstructors<br />

Functionality as pair (Operations, Dynamic <strong>co</strong>nstraints)<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

... .<br />

Functionality := ((StateChange∪Retrieval)Operations ,<br />

DynamicConstraints)<br />

Operations on the basis of the HERM algebra (for modification <strong>and</strong><br />

retrieval)<br />

providing a <strong>language</strong> for generalized views (media types)<br />

Content<br />

Information<br />

Concept<br />

Topic

...<br />

Constructs of the Co-Design Languages<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Distributivity as pair (Services, Exchange Frames)<br />

Distribution := ( Service (Informational process, Service Manager,<br />

Competence),<br />

ExchangeFrame (Architecture Collaboration Style,<br />

CollaborationPattern))<br />

Services on the basis of generalized views (media types)<br />

Interactivity as 4-tuple<br />

Interaction := (StorySpace, Actors,<br />

MediaObjects, Presentation)<br />

StorySpace as graph of scenes <strong>and</strong> activities<br />

Actors are abstractions of user groups<br />

MediaObjects are used by actors <strong>and</strong> are based on generalized views<br />

(media types)<br />

Information<br />

Concept<br />

Topic

Modern Information Systems<br />

Database systems as the kernel<br />

DBS = DBMS + { DB }<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

• Structuring of databases (structure + static integrity)<br />

• Functionality based on programming by generic functions<br />

Information systems based on database systems <strong>and</strong><br />

<strong>co</strong>ping with the user perspective:<br />

• Users stories, scenarios within the story space<br />

• Users views on <strong>co</strong>ntent based on media types<br />

• Context (users, <strong>co</strong>ntent, functionality, environment, provider, history)<br />

Collaborating information systems <strong>co</strong>ping with <strong>co</strong>mponent systems<br />

• Components providing services over networks<br />

• Collaboration for task solution<br />

Nowadays: Co-Design of Four Dimensions<br />

Concept<br />

Topic

Languages (syntax √ , semantics ??,<br />

pragmatics ????)<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

• Languages for specification<br />

• Structures<br />

(object-relational) √<br />

• Functions DML-based ?????<br />

• Distribution<br />

system-based<br />

• Interaction interface, XML ???<br />

• Languages of tools<br />

• Language <strong>and</strong> wording <strong>co</strong>nventions of developers <strong>and</strong> teams<br />

• Educational gap<br />

• Binarization, weak types, pointers <strong>and</strong> other non-sense<br />

Payoff: Babylonian Language Utilization<br />

may be also UML<br />

• Mismatches: structure / function, structure / static <strong>co</strong>nstraints,<br />

static <strong>co</strong>nstraints / maintenance, dynamic <strong>co</strong>nstraints in implementations<br />

• Interfaces are going to be developed later<br />

Concept<br />

Topic<br />

• Distribution in the Las Vegas approach

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

Conceptualisation: Oneness of Schema(ta)<br />

✞<br />

☎<br />

Depending on the viewpoint<br />

✝<br />

✆<br />

Leading, governing schemata in UML (13 of 142)<br />

Class diagram with associated object, package, <strong>co</strong>mposite structure, deployment,<br />

<strong>and</strong> distribution diagrams<br />

State machine diagram with associated use case, activity diagrams<br />

Interaction diagram with associated <strong>co</strong>mmunication, sequence, timing<br />

diagrams<br />

or <strong>co</strong>nsider the ER-backed layered <strong>co</strong>nceptual <strong>modelling</strong><br />

(1) (Extended) Entity-Relationship schema with H(igher-<strong>order</strong>)ER algebra,<br />

HERM logics as the governing or kernel schema<br />

(2) Business process model ,e.g., BPMN<br />

(3) Distribution styles, profiles, pattern with <strong>co</strong>mmunication + <strong>co</strong>operation<br />

+ <strong>co</strong>ordination<br />

(4) Storyboards <strong>and</strong> stories as the often neglected dimensions

Separation of Concern<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

(a) Properties essential for things of <strong>co</strong>nsideration in the application<br />

domain<br />

(b) Log as a volatile but essential piece of data<br />

... ...<br />

(b1) docket / superimposed schemata<br />

(b2) source<br />

(b3) time<br />

resulting in<br />

• binding schemata for references<br />

• implicit exclusion via explicit exclusion<br />

• special viewpoints (with importance in the development <strong>and</strong> deployment<br />

processes)<br />

Concept<br />

Topic

Different S<strong>co</strong>pe - Need - Dem<strong>and</strong><br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

• Business user, application-oriented s<strong>co</strong>pes, local processes, representation<br />

in an adequate form<br />

• S<strong>co</strong>pe-oriented representation for reasoning of a singleton user<br />

(object-centred model style (XML style)<br />

• Data representation at different abstraction <strong>and</strong> granularity levels<br />

(raw, cleansed/settled, stored, aggregated, analysis data)<br />

• All necessary information for implementation, e.g., usage profile<br />

<strong>and</strong> portfolio, set cardinalities, performance dem<strong>and</strong>s with performance<br />

tolerances, denormalisation <strong>and</strong> normalisation opportunities,<br />

semantics enforcement profiles<br />

✞<br />

☎<br />

Salami-slice-oriented <strong>co</strong>nceptual models as the main style.<br />

✞<br />

✝<br />

✆<br />

☎<br />

Delay all other information to implementation (logical/physical) levels! ☹<br />

✝<br />

✞<br />

☎<br />

✆<br />

Conceptual <strong>modelling</strong> is the programming of the future!!!! ☺<br />

✝<br />

✆<br />

Concept<br />

Topic

Three-Model-Conceptualisation<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

Natural model: representing reality as it is<br />

m-schema as an object-centred representation:<br />

my car my car product my car model <br />

my car br<strong>and</strong> my car manufacturer my product my product registration<br />

thing of reality with s<strong>co</strong>pe, role, <strong>co</strong>hesion/adhesion, <strong>co</strong>ntext, function,<br />

‘personality’, <strong>co</strong>mpeting viewpoints, with ‘natural’ semantics<br />

Universal model: ER-architecture with inner (abstract) structure<br />

<strong>and</strong> s<strong>co</strong>ping profiles, explicit shuffling among schema dimensions,<br />

folders <strong>and</strong> mappers, with full semantics <strong>and</strong> enforcement styles<br />

Implementation model: class-separation schema with central -<br />

view tower architecture, performance information as an classcentred<br />

representation, with rigid implementation semantics<br />

✞<br />

☎<br />

Information (iso-)morphism among the three schemata<br />

✝<br />

✞<br />

☎<br />

✆<br />

Mapping theory with the universal model as governor.<br />

✝<br />

✞<br />

☎<br />

✆<br />

Refinement of ER schemata (see Qing/β @ ER’2011)

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Conceptualisation: Solution<br />

✞<br />

☎<br />

Assumption nowadays: Oneness of <strong>co</strong>nceptual schema<br />

✝<br />

✆<br />

instead however<br />

<strong>co</strong>mpacti-<br />

Application-oriented <strong>co</strong>nceptual schema: typically<br />

fied;<br />

with different viewpoints for roles of stakeholders;<br />

zooming out, scaling, s<strong>co</strong>ping<br />

Universal (real) <strong>co</strong>nceptual schema: represents the <strong>co</strong>nceptualisation;<br />

based on many-dimensional separation of <strong>co</strong>ncern<br />

Realisation-oriented <strong>co</strong>nceptual schema: depending on implementation<br />

policy, style <strong>and</strong> implementation platform;<br />

also object-wise realisation<br />

Content<br />

Information<br />

Concept<br />

Topic

Abstraction Layer Models<br />

✞<br />

☎<br />

Separation by Level of Detail<br />

✝<br />

✆<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

Application domain layer <strong>co</strong>ncerned with description of the application<br />

Requirements acquisition layer <strong>co</strong>ncerned with prescription of<br />

system requirements<br />

Business user layer <strong>co</strong>ncerned with behaviour or users, their dem<strong>and</strong>s<br />

to the system<br />

Conceptual layer <strong>co</strong>ncerned with specifications (schemata) that describe<br />

the system<br />

Implementation layer <strong>co</strong>ncerned with logical <strong>and</strong> physical (specifications<br />

<strong>and</strong>) programs<br />

Deployment layer <strong>co</strong>ncerned with introduction, usage, maintenance,<br />

evolution of the system<br />

Concept<br />

Topic

Application domain<br />

layer<br />

Abstraction Layer<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

S<strong>co</strong>ping<br />

❄<br />

Requirements<br />

acquisition<br />

layer<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

Designing<br />

❄<br />

Conceptual<br />

layer<br />

Variating<br />

❄<br />

Business user<br />

layer<br />

Implementing<br />

❄<br />

Implementation<br />

layer<br />

Structuring<br />

specification<br />

Distribution<br />

specification<br />

Functionality<br />

specification<br />

Dialogue<br />

specification

Abstraction Layer Models<br />

✞<br />

☎<br />

Separation by Level of Detail<br />

✝<br />

✆<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

Application domain layer <strong>co</strong>ncerned with description of the application<br />

Requirements acquisition layer <strong>co</strong>ncerned with prescription of<br />

system requirements<br />

Business user layer <strong>co</strong>ncerned with behaviour or users, their dem<strong>and</strong>s<br />

to the system<br />

Conceptual layer <strong>co</strong>ncerned with specifications (schemata) that describe<br />

the system<br />

Implementation layer <strong>co</strong>ncerned with logical <strong>and</strong> physical (specifications<br />

<strong>and</strong>) programs<br />

Deployment layer <strong>co</strong>ncerned with introduction, usage, maintenance,<br />

evolution of the system<br />

Concept<br />

Topic

Classical dichotomy: Human-<strong>co</strong>mputer<br />

systems <strong>and</strong> information systems<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

Description/<br />

prescription<br />

layer<br />

Conceptual<br />

layer<br />

Implementation<br />

layer<br />

Design<br />

Refinement<br />

Application<br />

area<br />

description<br />

Presentation system<br />

specification<br />

Implementation<br />

Transformation<br />

Presentation<br />

system<br />

Requirements<br />

prescriptions<br />

WIS description<br />

<strong>and</strong> prescription<br />

WIS specification<br />

Information system<br />

specification<br />

Web information system<br />

Information<br />

system

Dichotomy of human-<strong>co</strong>mputer systems<br />

<strong>and</strong> the software systems<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

Description/<br />

prescription<br />

layer<br />

Conceptual<br />

layer<br />

Implementation<br />

layer<br />

Design<br />

Refinement<br />

Implementation<br />

Transformation<br />

Application<br />

area<br />

description<br />

WIS description<br />

<strong>and</strong> prescription<br />

Presentation system<br />

specification<br />

Presentation<br />

system<br />

WIS specification<br />

Web information system<br />

Requirements<br />

prescriptions<br />

Information systems<br />

specification<br />

Information<br />

system

The Software Engineering Quadruple<br />

Application domain description<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

Architecture<br />

blueprint<br />

Software specification<br />

The ‘holy’ triade so far extended by <strong>co</strong>ntext<br />

• Application domain description<br />

• Requirements prescription<br />

• Software specification<br />

Requirements<br />

prescription<br />

Concept<br />

Topic

Distributivity Specification Through<br />

DistrLang<br />

Service S = (I, F, Σ S ) specifying<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

Informational processes I = (V, M, Σ T ) specifying<br />

the <strong>co</strong>ntent V based on media types (“what”),<br />

the service manager M (“how”), <strong>and</strong><br />

the <strong>co</strong>mpetence Σ T through a set of tasks (“for what”)<br />

Service characteristics F specifying the organization frame (“how”),<br />

the parties (“who”) <strong>and</strong> the <strong>co</strong>ntext (“whereby”)<br />

Quality of service Σ S agreeing on the quality <strong>and</strong> motivation (“why”)<br />

Exchange frame specifying<br />

Architecture drafting the general engine (“where”)<br />

Collaboration style drafting the flow (“when”)<br />

Collaboration pattern describing the functionality (“how”, “whereby”)<br />

as a generalization of distributed systems, <strong>co</strong>mmunication systems,<br />

groupware systems, <strong>and</strong> <strong>co</strong>llaboration architectures<br />

Concept<br />

Topic

Conceptual Modelling of Collaboration<br />

✞<br />

Collaboration Triangle Relating Communication, Coordination, <strong>and</strong> Cooperation<br />

✝<br />

☎<br />

✆<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

dem<strong>and</strong>s ✠<br />

in ✒<br />

supports<br />

Coordination<br />

Cooperation<br />

Communication<br />

❘<br />

Collaboration■<br />

requires<br />

creates<br />

✲<br />

arranges ✛<br />

opportunities for tasks for<br />

✞<br />

☎<br />

✝Collaboration Acts ✆<br />

generates <strong>co</strong>mmitments<br />

that are managed by<br />

Communication act view based on sending <strong>and</strong> receiving<br />

Concurrency view based on <strong>co</strong>mmonly used data, functions, <strong>and</strong> tools<br />

Cooperation <strong>co</strong>ntext view <strong>co</strong>mbines the <strong>co</strong>ntext of <strong>co</strong>operation,<br />

i.e. portfolio to be fulfilled, the <strong>co</strong>operation story <strong>and</strong> the resources that are<br />

used<br />

Concept<br />

Topic

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Explicit Collaboration<br />

Communication via exchange of messages <strong>and</strong> information<br />

as only one of the perspectives<br />

dem<strong>and</strong>s <strong>co</strong>operation <strong>and</strong><br />

generates <strong>co</strong>mmitments that are managed by <strong>co</strong>ordination<br />

choice of media, transmission modes, meta-information,<br />

<strong>co</strong>nversation structure <strong>and</strong> paths, restriction policy<br />

Coordination via management of individuals, their activities<br />

<strong>and</strong> resources<br />

as the dominating perspective<br />

generates <strong>co</strong>mmunication <strong>and</strong> arranges tasks for <strong>co</strong>operation<br />

pre-/post-articulation of tasks; management of tasks, objects, <strong>and</strong> time;<br />

loosely ... tightly integrated activities, enabled, forced, blocked<br />

Cooperation as production taking place on a shared space<br />

as the workflow or life case perspective<br />

creates opportunities for <strong>co</strong>ordination <strong>and</strong> dem<strong>and</strong>s <strong>co</strong>mmunication<br />

storyboard-based interaction, mapped to (generic, structured) workflows<br />

production, manipulation, organization of <strong>co</strong>ntributions through media objects<br />

Awareness is fostered by each of the aspects <strong>and</strong><br />

mediates each of the aspects<br />

Information<br />

Concept<br />

Topic

Support for Collaboration<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

media type: views + functionality + adaptation + presentation<br />

Active media types: in parallel<br />

open(<strong>co</strong>ntent); inform(proprietor, usage)<br />

Self-protecting media types: <strong>co</strong>ntent based on queries <strong>and</strong> supported view<br />

proto<strong>co</strong>l: <strong>co</strong>ntact(proprietor,possessor, usage);<br />

obtain(proprietor,token); provide(media type, token)<br />

Communication proto<strong>co</strong>ls based on service (distributed ADT), signals, shared<br />

variables, sender/reponder ASM (signature (e.g., signal), phases (via small<br />

ASM)), <strong>and</strong> timer<br />

represented through SDL or message sequence chart or other proto<strong>co</strong>ls<br />

Security techniques against passive/active sniffling, trust exploitation, viruses,<br />

downloadables, OS holes, hacking<br />

Control techniques for focusing, access, user authorization, (password)<br />

protection, biometrics, <strong>co</strong>ntent/<strong>co</strong>ncept/topic security, firewalls, hiding/anonymizing/translating,<br />

id<strong>entity</strong> management<br />

Privacy enhancing techniques based on virtual private networks, key encryption,<br />

secure transaction, <strong>and</strong> <strong>co</strong>rporate policy on security, privacy <strong>and</strong> <strong>co</strong>ntrol,<br />

<strong>co</strong>okie <strong>co</strong>oker

Services for Distribution:<br />

✞<br />

☎<br />

✝Informational Processes ✆<br />

Media types Services manager Competence<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Raw<br />

media<br />

type<br />

Extensions<br />

(unit/<br />

<strong>order</strong>)<br />

Co-<br />

/Adhesion<br />

Hierarchy<br />

Task<br />

Playout Kind Communication<br />

Coordination<br />

Cooperation<br />

Activity<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Course<br />

insertion<br />

view<br />

Chair<br />

priority<br />

Coursecentered<br />

Term<br />

<strong>order</strong><br />

Mac-<br />

XSL5<br />

Daily<br />

refresh<br />

Deliver<br />

only<br />

None None Input<br />

main<br />

<strong>co</strong>urse<br />

Select<br />

or<br />

insert<br />

<strong>order</strong><br />

data<br />

Course<br />

negotiation<br />

Assistant<br />

<strong>order</strong><br />

Coursecentered<br />

Workload<br />

<strong>order</strong><br />

Mozi-<br />

XSL5<br />

Weekly<br />

refresh<br />

Exchange<br />

View<br />

others<br />

Other<br />

assistants<br />

Assignment<br />

Accept<br />

or<br />

reject<br />

view<br />

... ... ... ... ... ... ... ... ... ... ...<br />

Content<br />

Information<br />

Concept<br />

Topic

Services for Distribution:<br />

✞<br />

☎<br />

✝Services Characteristics ✆<br />

Party Organization Context<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Characteristics<br />

Time<br />

slot<br />

Media<br />

types<br />

Roles Rights Relations<br />

Hierarchy<br />

Synchronization<br />

Coordination<br />

Environment<br />

Range<br />

of<br />

variation<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Responsible<br />

Inform, Insert Dependent<br />

[request, none none none Last 3 Linux, Full<br />

person<br />

provide<br />

new,<br />

select (chair)<br />

deadline]<br />

terms<br />

lectures<br />

PC,<br />

browser<br />

Assistant<br />

at<br />

chair,<br />

assigned<br />

Negotiate<br />

Own<br />

plan<br />

Cooperate,<br />

ApproveBy<br />

[request,<br />

meeting]<br />

none <strong>co</strong>lleagues<br />

∃!!<br />

assignment<br />

for<br />

Chair<br />

schedule<br />

Linux History,<br />

profile,<br />

adaptation<br />

(<strong>co</strong>urse)<br />

(chair)<br />

chair<br />

... ... ... ... ... ... ... ... ... ... ...<br />

Content<br />

Information<br />

Concept<br />

Topic

Services for Distribution:<br />

✞<br />

☎<br />

Quality requirements<br />

✝<br />

✆<br />

• General requirements (enforced by the entire system)<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

• ubiquity, e.g., 7-24-60-60 frame<br />

• security, including all aspects<br />

• User requirements (for interactivity <strong>and</strong> distribution support)<br />

• interpretability (meaningful <strong>co</strong>ntent, adaptive, <strong>co</strong>ntext-sensitive)<br />

• <strong>co</strong>nsistency (of the story, of the <strong>co</strong>ntent, of the dialogues)<br />

• view <strong>co</strong>nsistency (within a media object suite)<br />

• System requirements (applied to implementations)<br />

• scalability (h<strong>and</strong>ling large system <strong>co</strong>nfigurations as well as small)<br />

• durability (of data)<br />

• robustness (against any kind of (user/system) errors)<br />

• performance (at least for usability)<br />

Information<br />

Concept<br />

Topic

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Exchange Frames for Distribution:<br />

Local users of A<br />

User<br />

interface<br />

Local<br />

applications<br />

Local<br />

DBS<br />

✞<br />

☎<br />

Architecture, e.g. Database Farms<br />

✝<br />

✆<br />

System A<br />

Farm<br />

<strong>co</strong>ntainer<br />

system<br />

Filter <strong>and</strong><br />

transformation<br />

system<br />

Global users<br />

User<br />

interface<br />

Global<br />

<strong>co</strong>mmunications<br />

<strong>and</strong> farming<br />

system<br />

System B<br />

Farm<br />

<strong>co</strong>ntainer<br />

system<br />

Filter <strong>and</strong><br />

transformation<br />

system<br />

as generalization of federated systems <strong>and</strong> multi-database systems<br />

Local user of B<br />

User<br />

interface<br />

Local<br />

applications<br />

Local<br />

DBS<br />

Content<br />

Information<br />

Concept<br />

Topic

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Exchange Frames for Distribution:<br />

Application<br />

system<br />

wrapper<br />

✞<br />

☎<br />

Another Architecture Supporting Distribution<br />

✝<br />

✆<br />

✛<br />

✲<br />

Exchange support system<br />

Communication<br />

(asynchronous<br />

|×| synchronous)<br />

Sender<br />

Receiver<br />

Stub<br />

Function<br />

manager<br />

Cooperation<br />

Work process<br />

manager<br />

Organizations<br />

manager<br />

Working space<br />

Media object suite management system<br />

Object suites Association manager Consistency manager<br />

Exchange = Cooperation + Coordination + Communication<br />

Collaboration system supporting groups, workspace, media object suites<br />

Coordination<br />

Task<br />

manager<br />

Coordinator<br />

Version<br />

manager<br />

Content<br />

Information<br />

Concept<br />

Topic

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Exchange Frames for Distribution:<br />

✞<br />

☎<br />

Collaboration Style<br />

✝<br />

✆<br />

supporting programs (session, user, payment management)<br />

data access pattern (release, sharing, remote)<br />

model of <strong>co</strong>llaboration (P2P, ...)<br />

<strong>co</strong>llaboration interplay (partner, mapping, rules<br />

access / <strong>co</strong>nfiguration<br />

event processing<br />

synchronization<br />

<strong>co</strong>ncurrent/parallel execution<br />

Collaboration Pattern<br />

Information<br />

Concept<br />

Topic

Typical Collaboration Pattern<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

Proxy <strong>co</strong>llaboration: partial system <strong>co</strong>pies (remote proxy, protection<br />

proxy, cache proxy, synchronization proxy, etc.)<br />

Broker <strong>co</strong>llaboration: <strong>co</strong>ordination of <strong>co</strong>mmunication either directly,<br />

through message passing, based on trading paradigms, by adapterbroker<br />

systems, or callback-broker systems<br />

Master/slave <strong>co</strong>llaboration: tight replication in various application scenarios<br />

(fault tolerance, parallel execution, precision improvement; as<br />

processes, threads; with(out) <strong>co</strong>ordination)<br />

Client/dispatcher <strong>co</strong>llaboration: for name spaces <strong>and</strong> mappings<br />

Publisher/subscriber <strong>co</strong>llaboration (observer-dependents paradigm)<br />

active/passive subscribers or passive with their subscription profile<br />

Model/view/<strong>co</strong>ntroller <strong>co</strong>llaboration: e.g. three-layer architecture of<br />

database systems<br />

Concept<br />

Topic

Portfolio <strong>and</strong> Task Specification<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

Party portfolio: 〈party portfolio name〉<br />

Task:<br />

〈general description〉<br />

Characterization: 〈general description〉<br />

Initial state: 〈characterization of initial states〉<br />

Target state: 〈characterization of target states〉<br />

Profile: 〈profile presupposed for solution〉<br />

Instruments: 〈list of instruments for solution〉<br />

Collaboration: 〈<strong>co</strong>llaboration style/pattern〉<br />

Auxiliary: 〈list of auxiliary <strong>co</strong>nditions〉<br />

Execution:<br />

〈list of activities, <strong>co</strong>ntrol, data〉<br />

Result:<br />

〈final state, target <strong>co</strong>nditions〉<br />

Party involvement: 〈general description〉<br />

Role:<br />

〈description of role〉<br />

Part:<br />

〈behavioral categories/stereotypes〉<br />

Collaboration: 〈general description〉<br />

Communication: 〈proto<strong>co</strong>ls, services <strong>and</strong> exchange〉<br />

Coordination: 〈<strong>co</strong>ntracts <strong>and</strong> enforcement〉<br />

Cooperation: 〈flow of work〉<br />

Restrictions:<br />

〈general description〉<br />

Party restrictions: 〈general description〉<br />

Environment: 〈general description〉

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

Coordination Contracts<br />

Contract: 〈name〉<br />

Based on: general <strong>co</strong>nditions<br />

Parties: 〈general description〉<br />

Proprietor: 〈...〉<br />

Possessor: 〈...〉<br />

Trustee: 〈...〉<br />

Arbiter: 〈...〉<br />

Subject matter: 〈Media object suite〉<br />

Exchange: 〈binding obligations, permissions〉<br />

Computation: 〈obligations, permissions〉<br />

Distribution: 〈obligations, permissions〉<br />

Monitoring: 〈managers: re<strong>co</strong>gnizer, 〉<br />

〈states, timer, <strong>co</strong>nstraint scanner〉<br />

Notification: 〈obligations, permissions〉<br />

Correlation: 〈proto<strong>co</strong>ls, obligations, permissions〉<br />

Considerations: 〈legal <strong>co</strong>nditions〉<br />

Enforcement: 〈actions, termination〉<br />

Concept<br />

Topic

Coordination Specification<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Coordination profile: 〈name〉<br />

Based on:<br />

general <strong>co</strong>nditions<br />

Formation:<br />

〈general description〉<br />

Contract: ...<br />

Lifespan: ...<br />

Contract variant: ...<br />

Parties:<br />

〈names〉<br />

Organization:<br />

〈names, general description〉<br />

Infrastructure: 〈name, general description〉<br />

Content<br />

Information<br />

Concept<br />

Topic

Party Specification<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Party:<br />

〈names〉<br />

Characteristics: ...<br />

Profile: ...<br />

Roles: ...<br />

Rights: ...<br />

Relations: ...<br />

Part:<br />

〈general description〉<br />

Organization: 〈general description〉<br />

Infrastructure: 〈general description〉<br />

Party profile: 〈party profile name〉<br />

Information dem<strong>and</strong>: 〈general description〉<br />

Utilization pattern: 〈general description〉<br />

Specific utilization: 〈general description〉<br />

Party <strong>co</strong>ntext: 〈general description〉<br />

Information<br />

Concept<br />

Topic

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Party Group Specification<br />

organizations, e.g., groups:<br />

Organization: 〈name〉<br />

Synchronization: ...<br />

Stories: ...<br />

Hierarchy: ...<br />

Time slot: ...<br />

Task distribution: ...<br />

Coordination: name<br />

Infrastructures: 〈names〉<br />

Content<br />

Information<br />

Concept<br />

Topic

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

Services<br />

Service:<br />

〈name〉<br />

Based on: general <strong>co</strong>nditions<br />

Media types: 〈general description〉<br />

Raw media type : ...<br />

Extensions: ...<br />

Unit: ...<br />

Order: ...<br />

Co-/Adhesion: ...<br />

Hierarchy: ...<br />

Playout: ...<br />

Services manager: 〈general description〉<br />

Kind: ...<br />

Communication: ...<br />

Coordination: ...<br />

Cooperation: ...<br />

Competence: 〈general description〉<br />

Task: ...<br />

QoS : ...<br />

Concept<br />

Topic

Context of a Service<br />

Context:<br />

〈name〉<br />

Media types: ...<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Environment: ...<br />

Range of variation: ...<br />

Context in general: Enrichment by super-typing<br />

Pragmatical <strong>co</strong>ntext (situational, physical environment, social, policy, time)<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Website <strong>co</strong>ntext (provider, supporter, SW/HW stakeholder)<br />

Syntactic<br />

verbal <strong>co</strong>ntext<br />

Media type suite,<br />

meta-information<br />

Explicit <strong>co</strong>ntext (Story space)<br />

Extra-syntactic<br />

auxiliary <strong>co</strong>rrelates<br />

Actors, profile,<br />

payment, ...<br />

Potential environment, information system, scenes, tasks, roles<br />

Intention, theme, occasion, mission, purpose<br />

Content<br />

Current scenario, history, current environment, user, goals, particular, culture<br />

Information<br />

Concept<br />

Topic

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Topic<br />

Content<br />

Information<br />

Communication/Coordination<br />

Infrastructure<br />

✛<br />

User<br />

interface<br />

Process<br />

Message<br />

❄<br />

✲<br />

Channel<br />

buffer<br />

✛<br />

✻<br />

Log<br />

File<br />

Channel<br />

Channel<br />

status<br />

❫<br />

✛<br />

✻<br />

✲<br />

Work/meeting<br />

session<br />

Session<br />

manager<br />

User<br />

✛<br />

❄<br />

✲<br />

Event<br />

h<strong>and</strong>ler<br />

Event<br />

h<strong>and</strong>ler<br />

kind<br />

✠<br />

✒<br />

Item<br />

✛<br />

❄<br />

Contribution<br />

Agenda ✛ ✲<br />

Scheduled in

Layers of a Typical Collaboration System<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Cooperation<br />

Layer<br />

Cooperation space/workspace:<br />

workspace <strong>co</strong>ntrol,<br />

awareness, notifications,<br />

security over user functions<br />

Media object<br />

unit manager<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Coordination<br />

Layer<br />

Communication<br />

Layer<br />

Coordination space:<br />

operation management,<br />

session management<br />

shared resources management,<br />

users management<br />

Communication space:<br />

(a)synchronous,<br />

multicast/broadcast,<br />

proto<strong>co</strong>ls, st<strong>and</strong>ard<br />

Coordination <strong>and</strong><br />

<strong>co</strong>ntracting system<br />

Communication<br />

support system<br />

generalising Ochoa, Guerrero, Fuller, Herrera: Infrastructure of Groupware Systems<br />

Content<br />

Information<br />

Concept<br />

Topic

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

Exchange Frames for Distribution<br />

✞<br />

☎<br />

Workspace <strong>and</strong> Group Collaboration Using the Trader Approach<br />

✝<br />

✆<br />

Trader exchange<br />

Communication Cooperation Coordination<br />

Architecture Asynchronous client Cooperation manager, Coordination manager<br />

Media suite management<br />

system<br />

Formation<br />

Model Proto<strong>co</strong>l: trader P2P Contract, TA FIFO schedule<br />

Release Login Hierarchical Sharing, lifespan<br />

Data exchange Stub, error track Public, personal space Replica of suites<br />

Interplay Event, open space Reactor, proactor Trade, book, pay<br />

Processing<br />

Model Message passing Trader FIFO<br />

Programs IP5 Workspace, user billing Session manager<br />

managers<br />

Data exchange Push through, <strong>co</strong>mpletion<br />

token<br />

S<strong>co</strong>ped 2-phase locking Half-sync among, fullsync<br />

with DBS<br />

Interplay IP5 sequencing Involve on dem<strong>and</strong> 2-phase <strong>co</strong>mmit<br />

Concept<br />

Topic

Experiences with Web Information Systems<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

• Many WISs are still developed in an ad-hoc way, not using appropriate<br />

methodology:<br />

• page not found or does not <strong>co</strong>ntain what was expected, page<br />

overloaded<br />

• link points to general entry point ignoring <strong>co</strong>ntext<br />

• search produces heaps of pages, in one of which the desired<br />

information may be found<br />

• repeated information, repeated requests for data entry<br />

• etc.<br />

Content<br />

Information<br />

Concept<br />

Topic

Need for WIS Development Methods<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

• In general, the need for methodological development arises, if<br />

systems tend to be<strong>co</strong>me large, if <strong>co</strong>ntent changes frequently, if<br />

<strong>co</strong>mplex tasks are to be supported, if multiple users use the system<br />

• WIS often serve purposes such as booking, selling, edutainment,<br />

etc., i.e. users are customers: giving up <strong>and</strong> turning away is highly<br />

undesirable<br />

• The web is an attractive (<strong>and</strong> fast) business channel for <strong>co</strong>mmunication,<br />

advertisement, <strong>co</strong>mmerce: systems have to serve the business<br />

goals<br />

Content<br />

Information<br />

Concept<br />

Topic

Existing WIS Development Methods<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

• Most WIS development methods (OOHDM, ARANEUS, HERA,<br />

WISM, WebML, UWE, Co-Design, etc.) <strong>co</strong>ncentrate on the<br />

data-intensive aspect: views on some underlying database schema<br />

• All methods support the generation of pages <strong>and</strong> layout<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

• Some (Co-Design) emphasize also the <strong>modelling</strong> of users/actors,<br />

tasks <strong>and</strong> action schemes/plots<br />

• Some (WISM, Co-Design) emphasize personalisation<br />

• Strategic <strong>modelling</strong> is rarely addressed (except Co-Design)<br />

Content<br />

Information<br />

Concept<br />

Topic

Differences from IS: Task-Centredness<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

• task: specification of goal-oriented actions;<br />

subtasks: workflow with activities, restricted by <strong>co</strong>nditions, data <strong>and</strong><br />

<strong>co</strong>ntext (organization, policy, environment, channel, ...)<br />

• participatory <strong>design</strong> (task analysis, user-oriented)<br />

mapped to essential <strong>design</strong> (data <strong>and</strong> function analysis)<br />

three spaces: task world, system space, interaction space<br />

• website as services (scenario of activities which can be called by the<br />

user with supporting proto<strong>co</strong>ls <strong>and</strong> delegation facilities)<br />

request, indication, response, <strong>co</strong>nfirmation<br />

(a)synchronous, layering, resource-sharing, error-robustness, <strong>co</strong>mmunication<br />

support, (temporary) workspace<br />

• generic user model <strong>and</strong> profile<br />

Content<br />

Information<br />

Concept<br />

Topic

Differences from IS: Usage-Centredness<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

• Identify essential user <strong>and</strong> business purposes<br />

• Underst<strong>and</strong> targeted users by roles in relation to site<br />

• Underst<strong>and</strong> tasks in terms of user intentions <strong>and</strong> needs<br />

• Prioritize user roles <strong>and</strong> user tasks in terms of expected frequency<br />

<strong>and</strong> business importance<br />

• Engineer site <strong>design</strong> to fit user <strong>and</strong> business priorities<br />

Thus: Questions to answer<br />

• What types of people will be visiting the site?<br />

• What’s the <strong>relationship</strong> between the users <strong>and</strong> the site?<br />

• What are the users trying to do?<br />

• What do the users need from the site in <strong>order</strong> to ac<strong>co</strong>mplish their<br />

goal?<br />

• How do we organize the site <strong>co</strong>ntent to help them succeed?<br />

Concept<br />

Topic

Key Questions<br />

• Who will be using the system?<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

• When will the system be used?<br />

• Where is the information system used?<br />

• What is represented in the system?<br />

• How will the system be used?<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

• Why is the system used?<br />

• What is the policy, intention, goal, <strong>and</strong> aim of the provider?<br />

Additional dimension in the Zachman model are:<br />

Competency:<br />

Time: (schedule; delay)<br />

Environment: (<strong>co</strong>ntext; technical <strong>and</strong> organizational)<br />

Quality: (in which quality; with which guarantees)<br />

Runtime characteristics: (adaptation; exceptions; delays)<br />

Collaboration: (with whom)<br />

Concept<br />

Topic

Storyboarding an Old Issue ?<br />

E.g., great script <strong>and</strong> movie: Tootsie, Witness, Back to the Future<br />

story + characters + topic + pictures + dialogues<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

• well structured (set-up, development, midpoint scene, climax, resolution)<br />

job-less, changing sex, job success, friendship, love, overwhelming problems,<br />

happy end<br />

+ brief <strong>and</strong> focused, <strong>co</strong>nstraint enforcement through dimensions<br />

• top-down (expose, outline of scenes, treatment, plot, production)<br />

• using all elements (catalysts, action point, attraction, barrier, <strong>co</strong>mplication,<br />

<strong>co</strong>ntrast, momentum, motives, pay-off, reversal, sequence, A-story, B-story,<br />

subjective point-of-view, subplot, twist)<br />

motivation action goal <strong>co</strong>nflict<br />

A well known story:<br />

The wild swans: ib 1 a 1 c 1 A 1 B 4 C ↗ {Sch 1 H 1 ¬Z 1 ¬‖sch 7 H 7 Z 9 }W 4 L 1 ↘<br />

V 1 [Sch 1 H 1 Z 9 ≡ R 4 ] × 3<br />

Information<br />

Concept<br />

Topic

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

Separation of Concern in the Web<br />

Utilisation Space by the Specification<br />

Context<br />

Technics<br />

organisation<br />

WIS <strong>co</strong>ntext<br />

Content<br />

Data<br />

objects<br />

knowledge<br />

Hexagon<br />

User <strong>and</strong> intention<br />

Web IS<br />

<strong>co</strong>llaboration<br />

group <strong>co</strong>ntent<br />

<strong>co</strong>llective id<strong>entity</strong><br />

Presentation<br />

Goal, application area<br />

profile,<br />

information dem<strong>and</strong><br />

Interfaces<br />

depending on the environment<br />

Storyboard<br />

Stories<br />

tasks<br />

Functionality<br />

Navigation<br />

search<br />

work<br />

Concept<br />

Topic

From Web 1.0 to Web 3.0<br />

((User <strong>and</strong> intention))<br />

Goal, application area<br />

profile,<br />

information dem<strong>and</strong><br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

Content<br />

Data<br />

objects<br />

knowledge<br />

Web 1.0<br />

Functionality<br />

Navigation<br />

search<br />

Presentation work<br />

Interfaces<br />

depending on the environment<br />

(Context)<br />

Technics<br />

organisation<br />

WIS <strong>co</strong>ntext<br />

Topic<br />

Content<br />

Data<br />

objects<br />

knowledge<br />

Web 3.0<br />

asset<br />

extends <strong>co</strong>ntent<br />

by annotation<br />

Presentation<br />

((((Storyboard))))<br />

Stories<br />

tasks<br />

Interfaces<br />

depending on the environment<br />

Derivation<br />

association<br />

declare<br />

Functionality<br />

Navigation<br />

search<br />

work<br />

Web 3.0: asset driven, <strong>co</strong>ntent-asset centered, provides<br />

Web 1.0: author driven,<br />

additionally linguistic semantics,<br />

publish/provide story/support or<br />

Technology <strong>co</strong>mbines: artificial intelligence, automated<br />

advertise/wait/attract/react/retain reasoning, <strong>co</strong>gnitive architecture, <strong>co</strong>mposite applications,<br />

for users:<br />

distributed <strong>co</strong>mputing, knowledge representation, ontology<br />

(<strong>co</strong>mputer science), re<strong>co</strong>mbinant text, scalable vector<br />

inform/subscribe/obtain/answer/<strong>co</strong>me back<br />

graphics, semantic Web, semantic Wiki, software agents<br />

Concept<br />

Topic

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

Web x.0 <strong>and</strong> the Co-Design Hexagonal<br />

Dimensions<br />

✞<br />

☎<br />

Web x.0: Towards sophisticated web engineering<br />

✝<br />

✆<br />

Context<br />

Technics<br />

organisation<br />

Content<br />

Data<br />

objects<br />

knowledge<br />

User <strong>and</strong> intention<br />

Web 2.0<br />

<strong>co</strong>llaboration<br />

group <strong>co</strong>ntent<br />

<strong>co</strong>llective id<strong>entity</strong><br />

Presentation<br />

Goal, application area<br />

profile,<br />

information dem<strong>and</strong><br />

Storyboard<br />

Stories<br />

tasks<br />

Functionality<br />

Navigation<br />

search<br />

work<br />

Interfaces<br />

depending on the environment<br />

✞<br />

☎<br />

Web 2.0 allows <strong>co</strong>ntext injection <strong>and</strong> is user-centered <strong>and</strong> story-centered<br />

✝<br />

✆<br />

Concept<br />

Topic

Interactivity Specification Through<br />

SiteLang<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Story space - space of all specified stories<br />

Story - labeled graph of different integrated scenarios<br />

Scenario - run through a system by a <strong>co</strong>operating set of actors<br />

Scene of scenario - <strong>co</strong>nsistent set of dialogue steps<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Dialogue step - <strong>co</strong>nditional actions of an enabled actor on page based<br />

on provided media objects<br />

ru i : on event if pre<strong>co</strong>nd do actions accept on post<strong>co</strong>nd<br />

if pre<strong>co</strong>ndru i<br />

<strong>and</strong> event then actions <strong>and</strong> CommitStateru i<br />

= toCommit<br />

if CommitStateru i<br />

= toCommit <strong>and</strong> post<strong>co</strong>ndru i<br />

then Commitru i<br />

if CommitStateru i<br />

= toCommit <strong>and</strong> ¬ post<strong>co</strong>ndru i<br />

then Undoru i<br />

Interaction space - space of all possible interaction stories<br />

System space - glass box of system (all runs integrated)<br />

Information<br />

Concept<br />

Topic

Interaction Modeling<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Story as labeled di-graph S = (V, E, λ, κ)<br />

V - scenes, E ⊆ V × V - transitions<br />

media object assignment λ : V → {MediaObj}<br />

representation through media objects<br />

with permitted rights, permitted roles, obligations of actors<br />

MediaObject (Container, ManipulatRequests, SuppliedFunctions)<br />

activity assignment κ : E → {Activity}<br />

activity = ( actor(profile) , task,<br />

<strong>co</strong>ntext (equipment, channel, rights, roles, particular),<br />

representation (style, default, emphasis, ...))<br />

Scenario - run through the system<br />

with cumulative history (<strong>and</strong> adaptation)<br />

<strong>co</strong>nsists of scenes<br />

visited sequentially or in parallel by actors<br />

story space - <strong>co</strong>mposition of sequences<br />

Information<br />

Concept<br />

Topic

Scene Specification<br />

Scene expression v ∈ Alg(DialogueStep)<br />

• basic <strong>co</strong>ntrol: sequence ;, parallel split | ∧ |, exclusive choice | ∨ |,<br />

synchronization | sync |, simple merge +<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

• advanced branching <strong>and</strong> synchronization <strong>co</strong>ntrol: multiple choice, multiple merge, discriminator,<br />

n-out-of-m join, synchronizing join<br />

• structural <strong>co</strong>ntrol: arbitrary cycles ∗, implicit termination ↓<br />

• <strong>co</strong>ntrol on multiple objects: CMO with a priori known <strong>design</strong> time knowledge, CMO with a<br />

priori known runtime knowledge, CMO with no a priori runtime knowledge; CMO requiring<br />

synchronization (synchronization edges)<br />

• state-based <strong>co</strong>ntrol: deferred choice, interleaved parallel executing, milestone<br />

• cancellation <strong>co</strong>ntrol: cancel action, cancel case<br />

frame: on event if α doScene v accept on γ<br />

representation of scenes via Montages<br />

<strong>co</strong>ntrol <strong>and</strong> object flow specification<br />

Content<br />

Information<br />

Concept<br />

Topic

scene<br />

Scene Specification<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

header<br />

<strong>co</strong>ntent name developer <strong>co</strong>pyright<br />

problem area motivation source<br />

solution intention also known as see too<br />

variants<br />

application<br />

applicability<br />

application area<br />

usability profile experience reports DBMS<br />

description<br />

sample applications<br />

known applications<br />

<strong>co</strong>nstraints<br />

implementation<br />

<strong>co</strong>nstraints,<br />

enforcement<br />

procedures<br />

<strong>co</strong>nsequences of application<br />

media objects, representation<br />

implementation <strong>co</strong>de sample associated scenario<br />

associated scenes exchange integration strategy<br />

structuring: functionality: interactivity: <strong>co</strong>ntext:<br />

structure, static operations, dynamic story space, actors, tasks, intention, history,<br />

particular<br />

m<strong>and</strong>atory good practice optional useful<br />

environment,

Representation of Dialogue Steps within a<br />

Dialogue Scene<br />

dialogue scene<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

dialogue<br />

step<br />

<strong>co</strong>ntrol(event,preCondition,acceptCondition)<br />

❄<br />

✲<br />

sub-unit<br />

supplied<br />

process<br />

✿<br />

transition ac<strong>co</strong>rding to<br />

❯ dialogue scene expression<br />

✻<br />

involved<br />

actors<br />

next<br />

dialogue<br />

step<br />

✻<br />

enabled actor<br />

✲<br />

manipulation<br />

sub-request<br />

✻ ✻ ✻ ✻<br />

story scene<br />

sequence<br />

media<br />

object<br />

representation<br />

style<br />

<strong>co</strong>ntext,<br />

task<br />

Information<br />

Concept<br />

Topic

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

dialogue step<br />

header<br />

name<br />

title<br />

<strong>co</strong>ntainer<br />

<strong>co</strong>ntent<br />

text<br />

multimedia object<br />

functionality<br />

tayloring style<br />

<strong>order</strong>ing by hierarchies<br />

adhesion<br />

adaptation<br />

interaction style<br />

<strong>co</strong>ntrol style<br />

actors applicable<br />

layout<br />

graphics<br />

picture<br />

video<br />

audio<br />

operations<br />

algorithmic object

Storyboards: Example Wikis<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Evaluator<br />

close<br />

group<br />

❑<br />

check<br />

answers<br />

❨<br />

develop new<br />

wikis<br />

❯<br />

3<br />

<strong>co</strong>llect<br />

wikis<br />

define<br />

new<br />

wikis<br />

❑<br />

H<br />

group<br />

❯ <strong>co</strong>mmuni-<br />

❯<br />

cation<br />

<strong>co</strong>ntent<br />

chunk<br />

space<br />

wiki<br />

delivery<br />

box<br />

H<br />

❯<br />

new<br />

wiki<br />

wiki<br />

sheet<br />

quit<br />

group<br />

Wiki Team<br />

Member<br />

✾<br />

2<br />

✾<br />

❥ discussion<br />

& evaluation<br />

❯<br />

revised<br />

wiki<br />

next<br />

wiki<br />

❑<br />

group<br />

help<br />

hints<br />

&<br />

tricks<br />

room<br />

Supporting<br />

Expert<br />

forming a Wiki team with three roles (evaluator, member, supporter)<br />

<strong>modelling</strong> the Wiki <strong>co</strong>llaboration story<br />

<strong>modelling</strong> the intended result<br />

pending<br />

wikis<br />

❯<br />

<strong>co</strong>nfirmed<br />

wikis<br />

❯<br />

❑<br />

outdated<br />

wikis<br />

Content<br />

Information<br />

Concept<br />

Topic

Wiki Specification Based on Content<br />

Chunks<br />

Wiki W = (I, S, Σ W ) specifying<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

Content chunk processes I = (V, M, Σ T ) specifying<br />

the <strong>co</strong>ntent chunks V based on media types (“what”),<br />

the wiki manager M (“how”), <strong>and</strong><br />

the <strong>co</strong>mpetence Σ T through a set of tasks (“for what”)<br />

Wiki storyboard S specifying the organization frame (“how”),<br />

the parties (“who”) <strong>and</strong> the <strong>co</strong>ntext (“whereby”)<br />

Quality of wiki Σ W agreeing on the quality <strong>and</strong> motivation (“why”)<br />

Exchange frame specifying<br />

Architecture drafting the general engine (“where”)<br />

Wiki <strong>co</strong>llaboration style drafting the flow (“when”)<br />

Wiki <strong>co</strong>llaboration pattern describing the functionality (“how”, “whereby”)<br />

as a generalization of distributed systems, <strong>co</strong>mmunication systems,<br />

groupware systems, <strong>and</strong> <strong>co</strong>llaboration architectures<br />

Concept<br />

Topic

Support for Wikis<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

<strong>co</strong>ntent chunks based on media types: views + functionality + adaptation + presentation<br />

Active media types: in parallel<br />

open(<strong>co</strong>ntent); inform(proprietor, usage)<br />

Self-protecting media types: <strong>co</strong>ntent based on queries <strong>and</strong> supported view<br />

proto<strong>co</strong>l: <strong>co</strong>ntact(proprietor,possessor, usage);<br />

obtain(proprietor,token); provide(media type, token)<br />

Communication proto<strong>co</strong>ls based on service (distributed ADT), signals, shared<br />

variables, sender/reponder ASM (signature (e.g., signal), phases (via small<br />

ASM)), <strong>and</strong> timer<br />

represented through SDL or message sequence chart or other proto<strong>co</strong>ls<br />

Security techniques against passive/active sniffling, trust exploitation, viruses,<br />

downloadables, OS holes, hacking<br />

Control techniques for focusing, access, user authorization, (password)<br />

protection, biometrics, <strong>co</strong>ntent/<strong>co</strong>ncept/topic security, firewalls, hiding/anonymizing/translating,<br />

id<strong>entity</strong> management<br />

Privacy enhancing techniques based on virtual private networks, key encryption,<br />

secure transaction, <strong>and</strong> <strong>co</strong>rporate policy on security, privacy <strong>and</strong> <strong>co</strong>ntrol,<br />

<strong>co</strong>okie <strong>co</strong>oker

Scene in a Storyboard<br />

Course Data Entry Scene Extended With Internal Negotiations<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Chairs Lecture Proposal Scene<br />

Login<br />

by chairs<br />

responsible<br />

❑<br />

❥<br />

✿<br />

3<br />

Accept<br />

<strong>co</strong>urse<br />

dem<strong>and</strong><br />

Generate<br />

new <strong>co</strong>urse<br />

proposal<br />

Collect<br />

seminar<br />

proposals<br />

❥<br />

❥<br />

Settle<br />

data for<br />

proposal<br />

Settle<br />

data for<br />

seminar<br />

❥<br />

❯<br />

Confirmation<br />

Entry<br />

of necessary<br />

data<br />

✿<br />

❑<br />

❯<br />

Auxiliary<br />

& historic<br />

data<br />

❨<br />

2<br />

❑<br />

Submission<br />

chair<br />

data<br />

✿<br />

❯<br />

❥ Assignment<br />

of <strong>co</strong>urses<br />

to members<br />

❯<br />

Negotiation of<br />

assignments<br />

by members<br />

❯<br />

Formulation<br />

of side<br />

<strong>co</strong>nditions<br />

Content<br />

Information<br />

Concept<br />

Topic

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Dialogue Steps for Event etc. Search<br />

event search scene<br />

individual<br />

request step<br />

property-based<br />

search<br />

✾<br />

❨<br />

❥<br />

map browsing<br />

step<br />

3<br />

entry<br />

step<br />

❑<br />

❯<br />

result &<br />

clarification<br />

step<br />

✾<br />

❥<br />

3❯<br />

❥ target seeking<br />

step<br />

❥<br />

❯<br />

points of<br />

interest<br />

booking<br />

step<br />

❑<br />

❑<br />

Content<br />

Information<br />

Concept<br />

Topic

Storyboard with [1,1]-[n≫ 1,m] Workflow<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

Supervised Solution of Exercises<br />

Supervisor<br />

close<br />

group<br />

❑<br />

check<br />

answers<br />

❨<br />

3<br />

❯ ❯<br />

develop new<br />

assignments<br />

❯<br />

<strong>co</strong>llect<br />

answers<br />

❑<br />

define<br />

new<br />

assignments<br />

H<br />

group<br />

<strong>co</strong>mmunication<br />

workplace<br />

assignment<br />

&<br />

answer<br />

delivery<br />

box<br />

H<br />

new<br />

assignments<br />

❯<br />

answering<br />

sheet<br />

quit<br />

group<br />

Parallel actions of users: dotted separation<br />

Workspace for <strong>co</strong>mmunication between parties<br />

History for reentering the scene<br />

✾<br />

2<br />

✾<br />

Exercise Team<br />

Member<br />

revised<br />

assignment<br />

❥ discussion<br />

& evaluation<br />

❯<br />

❑<br />

next<br />

assignment<br />

group<br />

help<br />

hints<br />

&<br />

tricks<br />

room<br />

Socrate<br />

new<br />

pending<br />

tricks<br />

❯<br />

hints<br />

& tricks<br />

❯<br />

❑<br />

outdated<br />

hints<br />

& tricks<br />

Rules are based on scenario (<strong>and</strong> didactic, pedagogical <strong>and</strong> psychological profile)<br />

Persistent media object suite re<strong>co</strong>rding long-running sessions<br />

Variant: KoPra with (problem solver, <strong>co</strong>rrector, advisor)-scenarios<br />

Concept<br />

Topic

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

Selection<br />

of problem<br />

typ<br />

Task<br />

delivery<br />

step<br />

❨<br />

❑<br />

❑<br />

Sequenced Scenes<br />

Sequenced Competitive Solution Scene<br />

❥<br />

Analysis<br />

of learners<br />

selection<br />

❯<br />

❑<br />

Selection<br />

of appropriate<br />

algorithm<br />

❯ Selection<br />

of appropriate<br />

attributes<br />

❨<br />

Competitive Solution Scene<br />

Task<br />

delivery<br />

step<br />

❑<br />

❥<br />

Delivery<br />

of prepared<br />

data<br />

✿<br />

Collection<br />

of learners<br />

data<br />

3<br />

Information<br />

on applicable<br />

algorithms<br />

Selection<br />

of appropriate<br />

data<br />

❥<br />

❥<br />

Code<br />

upload &<br />

installation<br />

❑<br />

Selection<br />

of target<br />

attribute<br />

2<br />

❑<br />

❥Preparation<br />

of learners<br />

data<br />

Code<br />

upload &<br />

installation<br />

❥Consideration<br />

on missing<br />

data<br />

❯<br />

Finding<br />

a solution for<br />

missing data<br />

❯<br />

Computation<br />

of associations<br />

through mining<br />

❯<br />

❥Formulation<br />

of learners<br />

hypotheses<br />

✿<br />

❑<br />

❨<br />

Computation<br />

of associations<br />

through mining<br />

2<br />

❑<br />

❯ Reminder<br />

of learning element<br />

on hypotheses<br />

❑<br />

Evaluation<br />

of learners<br />

<strong>co</strong>mpetition<br />

results<br />

❑<br />

Inspection<br />

of sample<br />

solution<br />

❑<br />

❥Submission<br />

of solution<br />

for <strong>co</strong>mpetition<br />

Submission<br />

of <strong>co</strong>mpetitive<br />

solution<br />

✿<br />

❯<br />

❥<br />

Evaluation<br />

of submitted<br />

solution<br />

❯ Inspection of<br />

sample solution<br />

& <strong>co</strong>mparison<br />

❯Repetition<br />

of solution<br />

for <strong>co</strong>mpetition

Underpinning Workflows with BPMN<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

Concept<br />

Topic

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Paper Submission <strong>and</strong> Reviewing System:<br />

Dialogue Scene<br />

✲<br />

v 1<br />

insert T Info<br />

α<br />

❄<br />

submit<br />

PaperData<br />

step<br />

✻<br />

A<br />

✲<br />

update T Info<br />

❥<br />

✲<br />

TInfo<br />

β<br />

❄<br />

obtain<br />

✻<br />

∅<br />

✲<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

✲<br />

TInfo<br />

∅<br />

γ<br />

❄<br />

insert<br />

PaperBody<br />

✻<br />

∅<br />

❨<br />

✲<br />

update<br />

v 1 = σ P aperID=pID (PaperBody)<br />

α = on LinkPaperSubmit if deadline = ok ∧ Login = ok<br />

A = actor[pID,pwrd]<br />

accept on submitConfirmed ∧ ¬ <strong>co</strong>llectError<br />

✲<br />

sessionInfo<br />

<strong>co</strong>nfirm<br />

β = on submitPaper if paperBody = ok accept on extension = ok<br />

γ = accept on ¬ transferError<br />

δ = on submitPaper if 1 accept on <strong>co</strong>nfirmed<br />

❯<br />

δ<br />

❄<br />

submit<br />

Permit<br />

✻<br />

A<br />

✲<br />

<strong>co</strong>nfirmed<br />

Concept<br />

Topic

Modelling Life Cases by Stories<br />

✞<br />

Digicult: Representing successful behavioural pattern<br />

✝<br />

☎<br />

✆<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Analogous search<br />

Deleting<br />

options<br />

❑<br />

❥<br />

No<br />

further<br />

options<br />

❥ Gaining info<br />

on problems<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

❯<br />

Survey<br />

on opportunities<br />

❑<br />

❨<br />

❥<br />

Sample<br />

cases<br />

❥<br />

❯ 3<br />

Successful<br />

cases<br />

2❨<br />

❑<br />

Similar<br />

cases<br />

Approaches<br />

for use<br />

Mapping behaviour of users with full option space<br />

Intelligent representation of information <strong>and</strong> knowledge spaces<br />

Adaptation to the user, curent situation, <strong>co</strong>ntext, ...<br />

Logistics for <strong>co</strong>ntent<br />

✾<br />

3<br />

Background<br />

info<br />

✿<br />

Concept<br />

Topic

Formal Specification of Scenarios<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Scenario:<br />

〈name of the scenario〉<br />

Scenes:<br />

〈list of scene names〉<br />

Start Scene: 〈scene name〉<br />

Final Scenes: 〈list of scene names〉<br />

Actions:<br />

〈list of action names〉<br />

Transitions: 〈list of transitions〉<br />

Process Expression: 〈SiteLang process〉<br />

Content<br />

Information<br />

Concept<br />

Topic

Formal Specification of Scenes<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Scene:<br />

〈scene name〉<br />

Actions:<br />

〈list of action names〉<br />

Roles:<br />

〈list of role specifications〉<br />

User Types:<br />

〈list of user type names〉<br />

Defining Scenario: 〈scenario name〉<br />

Acceptance Condition: 〈<strong>co</strong>ndition〉<br />

Content<br />

Information<br />

Concept<br />

Topic

Formal Specification of Actions<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Action:<br />

〈action name〉<br />

Pre<strong>co</strong>ndition:<br />

〈<strong>co</strong>ndition〉<br />

Post<strong>co</strong>ndition: 〈<strong>co</strong>ndition〉<br />

Roles:<br />

〈list of role names〉<br />

User Types:<br />

〈list of user type names〉<br />

Enabling Event: +〈list of actions〉<br />

−〈list of actions〉<br />

Triggering Event: +〈list of actions〉<br />

−〈list of actions〉<br />

Manipulation Requests: 〈list of manipulation requests〉<br />

Content<br />

Information<br />

Concept<br />

Topic

Formal Specification of Tasks<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Task:<br />

〈name of the task〉<br />

Goal:<br />

〈<strong>co</strong>ndition〉<br />

Subtasks:<br />

〈list of subtask names〉<br />

Problem:<br />

〈problem statement〉<br />

Actions:<br />

〈list of action names〉<br />

Pre<strong>co</strong>ndition: 〈<strong>co</strong>ndition〉<br />

Event:<br />

〈action〉 by 〈role name〉<br />

Scenario:<br />

〈scenario name〉<br />

Relationship: 〈description〉<br />

Description: 〈textual description〉<br />

Participants: 〈list of users〉<br />

Required Content: 〈list of <strong>co</strong>ntent items〉<br />

Produced Content: 〈list of <strong>co</strong>ntent items〉<br />

Result:<br />

〈textual description〉<br />

Starting situation: 〈list of situation parameters〉<br />

Closing <strong>co</strong>ndition: 〈acceptance <strong>co</strong>nstraints〉<br />

Execution <strong>co</strong>ntext: 〈textual characterization〉<br />

Enables:<br />

〈list of task names〉<br />

Specialises: 〈list of task names〉<br />

Information<br />

Concept<br />

Topic

Application of SiteLang Specification<br />

Deriving the Structuring Schemata<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

• purpose: structure <strong>and</strong> <strong>order</strong> information:<br />

• arbitrary with ambiguities, ellipses, definitions<br />

• heterogeneous (e.g., granularity, formats, <strong>co</strong>ntent)<br />

• perspective-driven (e.g., client support)<br />

• intension-driven (e.g., vendor policy, marketing)<br />

• choice of <strong>order</strong>:<br />

• <strong>order</strong> criteria: subject, tasks, usage, metaphors<br />

• fairly r<strong>and</strong>om (e.g., vendor policy) or clearly defined, easily underst<strong>and</strong>able<br />

<strong>order</strong> (e.g., telephone book)<br />

• <strong>co</strong>mbine different <strong>order</strong>s<br />

• classification:<br />

• mono- or polydimensional, mono- or polyhierarchies

Application of SiteLang Specification<br />

Deriving the Content Structure<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

• goal: structure the <strong>co</strong>ntent, though often determining the navigation<br />

as well<br />

• functionality is <strong>co</strong>nsidered to be attached<br />

• hierarchical structures:<br />

• easy to achieve, but difficult to use<br />

• possible use in catalogues, ontologies, etc.<br />

• includes directed acyclic graphs<br />

• hypermedia structures:<br />

• highly flexible, but risk to loose orientation<br />

• the <strong>co</strong>nceptual model relies on infinite (rational) structures <strong>and</strong><br />

is difficult to underst<strong>and</strong><br />

• underlying database structures: determinant by different <strong>design</strong><br />

desiderata (non-redundancy, <strong>co</strong>nsistency, fast accessibility, etc.)<br />

Concept<br />

Topic

Application of SiteLang Specification<br />

Deriving the Navigation Structure<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

• goal: help user to keep orientation within a site<br />

• do not give up flexibility goal<br />

• navigation systems:<br />

• hierarchical navigation via simple backtracking<br />

• global navigation to enable general vertical <strong>and</strong> horizontal navigation<br />

• local navigation extending the global one in a closed subarea<br />

• ad-hoc navigation via meaningful anchors <strong>and</strong> hyperlinks<br />

• navigation aids:<br />

• explicit map (floor plan, structuring schema) of the site as long as this is<br />

two-dimensional<br />

• separation of pages into primary information <strong>and</strong> navigation information<br />

• use of a <strong>co</strong>ntent description<br />

• use of an index / catalogue<br />

• markups in a navigation system: headers, meaningful anchors, meaningful<br />

i<strong>co</strong>ns, keywords

Application of SiteLang Specification<br />

Extending Navigation by Exploration Techniques<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

• Development of the exploration techniques for <strong>co</strong>mplex navigation spaces<br />

• Fish-eye view techniques (center in s<strong>co</strong>pe, rest <strong>co</strong>mpressed)<br />

• 3D-fish-eye techniques<br />

• adorned fish-eye views<br />

• fish-eye views with transformation of <strong>co</strong>ordinates (radial (locally or globally),<br />

orthogonal (locally or globally), 3-dimensional (implicitly or explicitly))<br />

• filtered fish-eye views (hierarchically or by graph structures)<br />

• Zoom navigation techniques<br />

• Non-linear visualization of navigation based on focus points or by multipoint<br />

hyperbolic representation<br />

• Adopting size by weight functions (measures of relevancy or importance,<br />

size of data)<br />

• Development of visualization alternatives<br />

Concept<br />

Topic

Application of SiteLang Specification<br />

Extending by Retrieval <strong>and</strong> Search Facilities<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

• goal: support users to find specific information:<br />

• ideal: system acts like a skilled, experienced librarian<br />

• usage factors:<br />

• ability to formulate search query<br />

• precision of expectation<br />

• search-engine for the site?<br />

• only necessary, if there is a frequently changing <strong>co</strong>ntent as in databasebacked<br />

sites<br />

• can otherwise be replaced by sophisticated browsing / navigation<br />

• user support:<br />

• explanation: <strong>co</strong>nnectives, string versus keyword, s<strong>co</strong>pe of search, etc.<br />

• feedback: recall, precision as in Information Retrieval<br />

• integration of search, browsing <strong>and</strong> navigation aids<br />

Concept<br />

Topic

Making Co-Design Working: Abstraction<br />

Design Layers<br />

Application domain<br />

layer<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

S<strong>co</strong>ping<br />

❄<br />

Requirements<br />

acquisition<br />

layer<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Designing<br />

Variating<br />

Business user<br />

layer<br />

Implementing<br />

Conceptual<br />

layer<br />

❄<br />

❄<br />

❄<br />

Implementation<br />

layer<br />

Structuring<br />

specification<br />

Distribution<br />

specification<br />

Functionality<br />

specification<br />

Dialogue<br />

specification<br />

Information<br />

Concept<br />

Topic

Making Co-Design Working: General<br />

Description<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Application domain or strategic layer:<br />

HERM (<strong>co</strong>ncept map (<strong>co</strong>ncept)),<br />

HERM (functionality (feature)),<br />

DistrLang (<strong>co</strong>ntract sketch (<strong>co</strong>ntract, quality criteria))<br />

SiteLang (application story (application step))<br />

(1) Developing visions, aims <strong>and</strong> goals<br />

(2) Analysis of challenges <strong>and</strong> <strong>co</strong>mpetitors<br />

Stakeholder <strong>co</strong>ntract (“Lastenheft”)<br />

nowadays: Product feature catalog<br />

Content<br />

Information<br />

Concept<br />

Topic

Making Co-Design Working<br />

Requirements Specification<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Requirements acquisition layer:<br />

HERM (sketch (rough type)),<br />

HERM (business process (business step)),<br />

DistrLang (<strong>co</strong>ntract opportunities),<br />

SiteLang (story (event))<br />

(3) Separation into system <strong>co</strong>mponents<br />

(4) Sketching the story space<br />

(5) Sketching the view suite<br />

(6) Specifying business processes<br />

IS development <strong>and</strong> system documentation (“Pflichtenheft”)<br />

Content<br />

Information<br />

Concept<br />

Topic

Making Co-Design Working<br />

Usage, Usability <strong>and</strong> Application Stories<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Business user layer:<br />

HERM (skeleton (application type)),<br />

HERM (activity (action)),<br />

DistrLang (media types, <strong>co</strong>ntract),<br />

SiteLang (plot (theme), actors, media types)<br />

(7) Development of scenarios of the story space<br />

(8) Elicitation of main data types <strong>and</strong> their associations<br />

(9) Development of kernel integrity <strong>co</strong>nstraints, e.g., identification <strong>co</strong>nstraints<br />

(10) Specification of user actions, usability requirements, <strong>and</strong> sketching media<br />

types<br />

(11) Elicitation of ubiquity <strong>and</strong> security requirements<br />

Playout system specification<br />

Content<br />

Information<br />

Concept<br />

Topic

Making Co-Design Working<br />

Conceptual Specification<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Conceptual layer:<br />

HERM (schema(types)),<br />

HERM (workflow (process)),<br />

DistrLang (service space, exchange frame),<br />

SiteLang (story space, actors, media types, presentation)<br />

(12) Specification of the story space<br />

(13) Development of data types, integrity <strong>co</strong>nstraint, their enforcement<br />

(14) Specification of the view suite, services <strong>and</strong> exchange frames<br />

(15) Development of workflows<br />

(16) Control of results by sample data, sample processes, <strong>and</strong> sample scenarios<br />

(17) Specification of the media type suite<br />

(18) Modular refinement of types, views, operations, services, <strong>and</strong> scenes<br />

(19) Normalization of structures<br />

(20) Integration of <strong>co</strong>mponents along architecture<br />

Conceptual schemata<br />

Information<br />

Concept<br />

Topic

Making Co-Design Working<br />

Implementation Layer<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Implementation layer:<br />

o-r DDL (o-r schema (relation)),<br />

PL (module) <strong>language</strong> (program, trigger, sp, ...),<br />

Distribution specification <strong>language</strong> (distributed system<br />

(distribution, proto<strong>co</strong>l, call))<br />

Dialog system <strong>language</strong> (presentation space (working sheet))<br />

(21) Transformation of <strong>co</strong>nceptual schemata into logical schemata, programs,<br />

<strong>and</strong> interfaces<br />

(22) Development of logical services <strong>and</strong> exchange frames<br />

(23) Developing solutions for performance improvement, tuning<br />

(24) Transformation of logical schemata into physical schemata<br />

(25) Checking durability, robustness, scalability, <strong>and</strong> extensibility<br />

Program library<br />

Information<br />

Concept<br />

Topic

The Onion Approach<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

presentation engine<br />

<strong>co</strong>ntainer engine<br />

media object engine<br />

view h<strong>and</strong>ler<br />

DBS<br />

DBMS<br />

XML scene onion<br />

<strong>co</strong>ntainer onion<br />

media object onion<br />

XML suite<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

...<br />

virtual ∨ materialized views<br />

update views<br />

survey, l<strong>and</strong>mark, indexing, I/O,<br />

navigation, integration etc. functions<br />

services packages, wrapping functions,<br />

dialogue scene <strong>and</strong> scenario functions<br />

actor profiles, profile adaptation, equipment adaptation,<br />

channel adaptation, de<strong>co</strong>mposer, style extension<br />

Content<br />

Information<br />

Concept<br />

Topic

(WIS-E 1): Application Domain<br />

Description <strong>and</strong> Requirements Statement<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

Process Purpose: Goals <strong>and</strong> Subject<br />

Goals <strong>and</strong> subject<br />

Application domain description<br />

Agreement for development<br />

Project s<strong>co</strong>pe: Milestones, financial issues<br />

Clarification of development goals (intentions, rationale)<br />

Sketch of requirements<br />

Process Out<strong>co</strong>mes: Work Products as Process Results<br />

Developed documents<br />

Official <strong>and</strong><br />

<strong>co</strong>ntracting section<br />

Developed documents<br />

Internal section<br />

Stakeholder <strong>co</strong>ntract: goal information,<br />

<strong>co</strong>ncept sketch, product functionality, story space,<br />

views on product data, view <strong>co</strong>llaboration sketch<br />

Comparison with products of <strong>co</strong>mpetitors<br />

Evaluation of development <strong>co</strong>sts<br />

Planning of goals, development strategy <strong>and</strong> plan,<br />

quality management<br />

Development documents on product <strong>co</strong>mponents<br />

<strong>and</strong> quality requirements<br />

with base practices, generic practices<br />

<strong>and</strong> capabilities, estimation of efforts<br />

Concept<br />

Topic

(WIS-E 1): Application Domain<br />

Description <strong>and</strong> Requirements Statement<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

Process Out<strong>co</strong>mes: Work Products as Process Results<br />

Developed documents<br />

Application domain<br />

description section<br />

Information analysis<br />

missions <strong>and</strong> goals of the WIS, br<strong>and</strong> of the WIS<br />

general characterization of tasks <strong>and</strong> users<br />

general characterization of <strong>co</strong>ntent <strong>and</strong> functions<br />

description of WIS <strong>co</strong>ntext<br />

Intensions of the web information system,<br />

catalog of requirements<br />

scenarios, scenes, actions, <strong>co</strong>ntext <strong>and</strong> life cases<br />

user profiles <strong>and</strong> user portfolio<br />

actor profiles <strong>and</strong> actor portfolio, personas<br />

Business rule model <strong>and</strong> storyboards<br />

scenarios, scenes, <strong>and</strong> actions<br />

life cases <strong>and</strong> <strong>co</strong>ntext<br />

WIS utilization portfolio<br />

scenarios, activities<br />

supporting <strong>co</strong>ntent <strong>and</strong> functions<br />

non-functional requirements, <strong>co</strong>ntext space<br />

Metaphor description<br />

base metaphors, overlay metaphors<br />

metaphor integration <strong>and</strong> deployment

(WIS-E 1): Application Domain<br />

Description <strong>and</strong> Requirements Statement<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

Base Activities <strong>and</strong> Steps<br />

Development<br />

of application<br />

domain<br />

description<br />

1. Analyze strategic information<br />

Specify mission <strong>and</strong> br<strong>and</strong><br />

Characterize in general tasks <strong>and</strong> users<br />

Characterize in general <strong>co</strong>ntent <strong>and</strong> functions<br />

Describe WIS <strong>co</strong>ntext<br />

2. Derive intensions of the WIS,<br />

Obtain general requirements<br />

Extract life cases<br />

Describe scenarios, scenes, actions, <strong>and</strong> <strong>co</strong>ntext<br />

Describe user profiles <strong>and</strong> user portfolio<br />

Derive actor profiles <strong>and</strong> actor portfolio, personas<br />

3. Extract business rule model <strong>and</strong> storyboards<br />

Develop scenarios, scenes, <strong>and</strong> actions<br />

Specify life cases <strong>and</strong> <strong>co</strong>ntext<br />

Eliciting metaphors<br />

4. Revise business rules of the application<br />

possibly with reorganization models<br />

5. Compare new business rules with known visions<br />

6. Compare with products of <strong>co</strong>mpetitors<br />

Concept<br />

Topic

(WIS-E 1): Application Domain<br />

Description <strong>and</strong> Requirements Statement<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Base Activities <strong>and</strong> Steps<br />

Development<br />

of application<br />

domain<br />

description<br />

Pre<strong>co</strong>ndition<br />

Post<strong>co</strong>ndition<br />

7. Derive WIS utilization<br />

Describe scenarios to be supported<br />

Describe activities based on word fields<br />

Describe supporting <strong>co</strong>ntent<br />

Describe supporting functions<br />

Describe non-functional requirements<br />

Describe the <strong>co</strong>ntext space<br />

8. Develop metaphor<br />

Describe base <strong>and</strong> overlay metaphors<br />

Find metaphor integration<br />

Develop templates for deployment<br />

Contracted <strong>co</strong>llaboration of all partners<br />

Real necessity<br />

Descr. of application domain accepted <strong>and</strong> <strong>co</strong>nsistent<br />

New business rule model accepted<br />

Content<br />

Information<br />

Concept<br />

Topic

Abstraction Layers <strong>and</strong> SPICE Model<br />

Categories in WIS Co-Design<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

Concept<br />

Topic

SPICEing Co-Design: Towards Optimizing<br />

Processes<br />

✞<br />

☎<br />

Model Space Restrictions during Co-Design<br />

✝<br />

✆<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

Concept<br />

Topic

Evaluated Development by Rapid<br />

Prototyping <strong>and</strong> Executable Specifications<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

executable specifications based on Model Driven Software Development<br />

automatic transformation of specifications on higher layers of abstraction to executable<br />

programs without manual transformation steps

Media Types, Media Object Suite<br />

✞<br />

☎<br />

✝Theoretical Basis ✆<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

• Raw media types = (<strong>co</strong>nt(M), sup(M), view(M), op(M))<br />

<strong>co</strong>ntent type <strong>co</strong>nt(M), set of supertypes sup(M),<br />

view(M) = Q (S inp , S outp )<br />

HERM view<br />

generic functions op(M) for changing the database<br />

• Attached operations: (signature, selection type, body)<br />

selection type - supertype of <strong>co</strong>nt(M)<br />

e.g. generalization/specialization, re<strong>order</strong>ing, browsing, linking,<br />

surveying, searching, join<br />

• Media type: raw media type + unit extension<br />

+ <strong>order</strong> extension + <strong>co</strong>hesion/adhesion + hierarchical versions<br />

• Usage modeling: usage dimensions, scales, user profiles, user kind<br />

• Container = (<strong>co</strong>nt(C), layout(C), kind(C))<br />

for shipping <strong>and</strong> representation

Layout <strong>and</strong> Playout: The General Picture<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

• • • • • •<br />

• • • • • •<br />

✻<br />

❨ ✯<br />

✻<br />

❨ ✯<br />

✻<br />

✻<br />

• • • • • •<br />

✐ ✶ ✐ ✶ ✻<br />

✻<br />

• • • • • •<br />

profiling<br />

users<br />

❄<br />

✻<br />

wrap<br />

objects<br />

media<br />

✻ cut / glue<br />

raw<br />

objects<br />

media<br />

✻ extract<br />

main data<br />

es<strong>co</strong>rt data<br />

Content<br />

Information<br />

Concept<br />

Topic

Media Objects<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

✻<br />

personalized<br />

global<br />

media<br />

objects<br />

filtration<br />

summarization<br />

scaling<br />

✻<br />

database<br />

schema<br />

static<br />

✠<br />

information<br />

<strong>co</strong>ntainers<br />

✲ dialogues<br />

enabled<br />

manipulation<br />

requests<br />

enabled<br />

processes<br />

✻<br />

✲ processes<br />

dynamic<br />

supplied<br />

processes<br />

✲<br />

Content<br />

Information<br />

Concept<br />

Topic

Example: Elli’s Juice trader<br />

• use an e-<strong>co</strong>mmerce application as a running example for this part<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

• Content:<br />

• Elli’s Juice trader is going to deliver grapes, champagners, nectars, juices,<br />

blended drinks <strong>and</strong> <strong>co</strong>ncentrates (esp. Cocktail, Limonade, Sweet <strong>and</strong> Vitaminized<br />

juice) via the internet<br />

• catalogue / specials: there shall be a catalogue <strong>co</strong>ntaining the offered products<br />

as well as occasional special offers<br />

• news: additional information about grapes, fruits, grape yards (also for<br />

Cocktail, Limonade, Dried juice <strong>and</strong> Concentrate) shall be provided<br />

• self-info / news: there shall be information about the shop itself, historical<br />

<strong>and</strong> actual information about certain grapes, grape producers, etc.<br />

• news: there shall be special information about best sellers, new products,<br />

etc.<br />

• blackboard: <strong>co</strong>mments from (pleased) clients shall be made available on<br />

the web<br />

Information<br />

Concept<br />

Topic

Example: Elli’s Juice trader<br />

• Functionality:<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

• cart: the web site shall allow to walk through the shop, <strong>co</strong>llecting <strong>and</strong><br />

dropping bottles to be bought<br />

• search: internal search will be supported as well as a link to a st<strong>and</strong>ard<br />

search engine, if a specific product cannot be found<br />

• special: there will be a permanent offer to be<strong>co</strong>me a member of Elli’s Club<br />

with special <strong>co</strong>nditions <strong>and</strong> offers<br />

• <strong>order</strong> form: it shall be possible to <strong>order</strong> grape or Cocktail, etc. in advance,<br />

if it is not available at the moment<br />

• <strong>co</strong>mments: <strong>co</strong>mments about products <strong>and</strong> service can be delivered at any<br />

time<br />

• Usage:<br />

• roles: there will be clients (normal <strong>and</strong> club members), product <strong>and</strong> marketing<br />

agents <strong>and</strong> just the vendor keeping track on quantities on stock<br />

• profiles: clients may be just curious, bargain-oriented or <strong>co</strong>nnaisseurs<br />

Concept<br />

Topic

Example: Elli’s Juice trader<br />

Entry Page<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Order Form<br />

Cashier<br />

Search<br />

Catalogue<br />

Authentication<br />

Floor plan<br />

Specials<br />

Comments Cart<br />

Ac<strong>co</strong>unt<br />

News<br />

Self-Info<br />

Content<br />

Information<br />

Concept<br />

Topic

Content Modelling<br />

• first introduce extended views <strong>and</strong> raw media types<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

• for this we assume an underlying database schema S, i.e., a <strong>co</strong>llection<br />

of database types<br />

• a database type of level k has a name E <strong>and</strong> <strong>co</strong>nsists of<br />

• a set <strong>co</strong>mp(E) = {r 1 : E 1 , . . . , r n : E n } of <strong>co</strong>mponents with<br />

pairwise different role names r i ,<br />

• a set attr(E) = {a 1 , . . . , a m } of attributes, each associated<br />

with a data type dom(a i ) as its domain,<br />

• <strong>and</strong> a key id(E) ⊆ <strong>co</strong>mp(E) ∪ attr(E)<br />

• the database types E i ∈ S are on levels lower than k with at<br />

least one database type of level exactly k − 1.<br />

Content<br />

Information<br />

Concept<br />

Topic

Data Types<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

• assume an underlying type system (data types) defined as, e.g.,<br />

t = b | (a 1 : t 1 , . . . , a n : t n ) | {t} | [t]<br />

• b represents an arbitrary <strong>co</strong>llection of base types:<br />

• CARD for non-negative integers, INT for integers, FLOAT for<br />

floating-point numbers<br />

• CHAR for characters, STRING for character strings<br />

• MONEY for decimals, DATE for date values, BOOL for truth<br />

values<br />

• URL for URL-addresses, MAIL for e-mail-addresses, OK for a<br />

single value ok, etc.<br />

• (· · · ), {·} <strong>and</strong> [·] are <strong>co</strong>nstructors for re<strong>co</strong>rds, sets <strong>and</strong> lists<br />

• the semantics is defined by assigning sets of values to each type<br />

Information<br />

Concept<br />

Topic

Example<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

grape<br />

⊕ mixed drink blended drink nectar<br />

✻<br />

⊕<br />

❨<br />

producer<br />

⊕<br />

package ✛ offer<br />

✻<br />

❄<br />

⊕<br />

❄<br />

✻<br />

Cocktailery grape yard<br />

bottle<br />

<strong>order</strong><br />

✠<br />

❄<br />

region publication delivery<br />

✠ ✲ client<br />

❄<br />

❄<br />

<strong>co</strong>untry news<br />

Content<br />

Information<br />

Concept<br />

Topic

Extended Views<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

• a view V on a database schema S <strong>co</strong>nsists of a view schema S V<br />

<strong>and</strong> a defining query q V , which transforms databases over S into<br />

databases over S V<br />

• extend the query <strong>language</strong> in a way that allows to create URLs <strong>and</strong><br />

links (create facility):<br />

• create urls transforms a set {v 1 , . . . , v m } of values into a set<br />

{(u 1 , v 1 ), . . . , (u m , v m )} of pairs with new created URLs u i of<br />

type URL<br />

• create urls also transforms a list [v 1 , . . . , v m ] of values into a<br />

list [(u 1 , v 1 ), . . . , (u m , v m )] of pairs with new created URLs u i of<br />

type URL<br />

• create url transforms a value v of any type into a pair (u, v)<br />

with a new URL u<br />

Information<br />

Concept<br />

Topic

Raw Media Types<br />

• extension by es<strong>co</strong>rt information: supertyping mechanism.<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

• a raw media type has a name M <strong>and</strong> <strong>co</strong>nsists of<br />

• a <strong>co</strong>ntent data type <strong>co</strong>nt(M) (the place of a base type may be<br />

occupied by a pair l : M ′ ),<br />

• a finite set of supertypes sup(M) of raw media type names M i ,<br />

• a defining query q M with create-facility such that ({t M }, q M )<br />

defines a view<br />

• a set of operations op(M) for accessing <strong>and</strong> changing the underlying<br />

database<br />

• finite closed sets C of raw media types define <strong>co</strong>ntent schemata<br />

• defining a raw media type may be regarded as a three-phase procedure<br />

using filtration <strong>and</strong> summarization <strong>and</strong> operation attachment<br />

Information<br />

Concept<br />

Topic

Example<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

<strong>co</strong>lour = ‘red’<br />

grape year ≥ 1995<br />

❨<br />

✻<br />

producer<br />

❄<br />

grape yard<br />

❄<br />

region<br />

❄<br />

<strong>co</strong>untry<br />

❄<br />

bottle<br />

name = ‘NZ’<br />

package ✛ offer<br />

✻<br />

<strong>order</strong><br />

Filtration<br />

(simple view)<br />

New Zeal<strong>and</strong><br />

red grapes<br />

from 1995 on<br />

plus grape yards,<br />

regions<br />

plus <strong>order</strong>s<br />

plus offers,<br />

packages<br />

Content<br />

Information<br />

Concept<br />

Topic

Example (<strong>co</strong>nt.)<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

grape<br />

✻<br />

producer<br />

❄<br />

grape yard<br />

❄<br />

region<br />

<strong>co</strong>lour = ‘red’<br />

year ≥ 1995<br />

{. . . , (morello, ≥ 30),. . . }<br />

{ (price, year) }<br />

{ (<strong>co</strong>nsumption, year) }<br />

Summarization<br />

(<strong>co</strong>mputable<br />

view)<br />

≥ 30 % morello<br />

average price<br />

per<br />

liter <strong>and</strong> year<br />

<strong>co</strong>nsumed<br />

liters<br />

Content<br />

Information<br />

Concept<br />

Topic

Functionality Modelling: Attached<br />

Operations<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

• on operation on a raw media type M <strong>co</strong>nsists of<br />

• an operation signature: name, input-parameters, outputparameters<br />

• a selection type which is a supertype of <strong>co</strong>nt(M)<br />

• <strong>and</strong> a body which is defined via operations accessing the underlying<br />

database<br />

• several st<strong>and</strong>ard operations are of particular interest:<br />

• ...<br />

Content<br />

Information<br />

Concept<br />

Topic

Functionality Modelling: Attached<br />

Operations<br />

• ...<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

• several st<strong>and</strong>ard operations are of particular interest:<br />

• Generalization: generation of aggregated data, especially in the case of<br />

insufficient space, i.e., roll-up, slicing, grouping<br />

• Specialization: used for querying the database in <strong>order</strong> to obtain more details<br />

for aggregated data, e.g., drill-down<br />

• Re<strong>order</strong>ing: used for the rearrangement of data, e.g., pivoting, dimension<br />

destroying, pull, push, rotate<br />

• Browsing: useful in the case that information cannot be presented <strong>co</strong>mpletely<br />

• Linking: useful whenever the user is required to imagine the <strong>co</strong>ntext or link<br />

structure<br />

• Surveying: used for the graphical visualization of the <strong>co</strong>ntent<br />

• Searching: attached to enable the <strong>co</strong>mputation of ad-hoc aggregates<br />

• Join: used for the <strong>co</strong>nstruction of more <strong>co</strong>mplex raw media objects

Content Tailoring<br />

• four extensions turning a raw media type into a media type<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

• unit extension: introduce measure units<br />

• <strong>order</strong>-extension:<br />

• use <strong>order</strong>ing-operators ord ≤ on lists <strong>and</strong> sets<br />

• replace set types in <strong>co</strong>nt(M) by list type<br />

• Example: <strong>order</strong> the previous raw media type by average price followed by<br />

percentage of Cabernet followed by year<br />

• <strong>co</strong>hesion / adhesion:<br />

• allow a <strong>co</strong>ntrolled form of information loss<br />

• determine which data has to be kept together (preferably), if technical<br />

<strong>co</strong>nstraints or user preferences require to split the raw media type<br />

• hierarchical versions:<br />

• flatten or deflatten along dimensions (analogous to OLAP)<br />

• allow <strong>co</strong>ndensed or detailed information presentation<br />

Concept<br />

Topic

Cohesion / Adhesion<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

• define a partial <strong>order</strong> ≤ on <strong>co</strong>ntent data types, which extends subtyping:<br />

• for any expression exp we have exp ≤ OK<br />

• for link expressions we have (l : M ′ ) ≤ (l : M ′′ ) iff M ′′ is a<br />

direct or indirect (via transitive closure) supertype of M ′<br />

• for re<strong>co</strong>rd expressions we have (a 1 : exp 1 , . . . , a m : exp m ) ≤<br />

(a σ(1) : exp ′ σ(1) , . . . , a σ(1) : exp ′ σ(n)<br />

) with injective σ :<br />

{1, . . . , n} → {1, . . . , m} <strong>and</strong> exp σ(i) ≤ exp ′ σ(i)<br />

• for list <strong>and</strong> set structures we have {exp} ≤ {exp ′ } (or [exp] ≤<br />

[exp ′ ], respectively) iff exp ≤ exp ′ holds<br />

• let sup(<strong>co</strong>nt(M)) be the set of all <strong>co</strong>ntent expressions exp with<br />

<strong>co</strong>nt(M) ≤ exp<br />

Content<br />

Information<br />

Concept<br />

Topic

Adhesion Pre<strong>order</strong> <strong>and</strong> Proximity Values<br />

• Pre<strong>order</strong>ing:<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

• an adhesion pre<strong>order</strong> on M is a pre<strong>order</strong> ≼ M on sup(<strong>co</strong>nt(M)) extending<br />

the <strong>order</strong> ≤<br />

• smaller types with respect to ≼ represent a preferred data <strong>co</strong>llection (for<br />

the case of unavoidable split)<br />

• Example: keep name, year <strong>and</strong> grapes for a grape more ‘important’ than<br />

grape yard or region or additional information<br />

• Proximity:<br />

• choose an antichain exp 1 , . . . , exp n with respect to ≼<br />

• this represents a possible split of information<br />

• define a symmetric (n × n)-matrix {p ij } 1≤i,j≤n of proximity values with<br />

0 ≤ p ij ≤ 1<br />

• the higher the proximity value, the more do we wish to keep the <strong>co</strong>mponents<br />

together<br />

• Example: a proximity value of 0.2 for (<strong>co</strong>nsumption) to all other expressions<br />

in an antichain indicates that we are like to separate this part

Hierarchical Versions (1/2)<br />

• <strong>co</strong>nsider dimension hierarchies as in OLAP<br />

• the hierarchy is already implicitly defined by the <strong>co</strong>mponent or link structures<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

• flattening of dimensions results in information growth, its <strong>co</strong>nverse in information<br />

loss<br />

• flattening:<br />

• if E ′ is a <strong>co</strong>mponent of E <strong>co</strong>rresponding to the role r, then we may replace<br />

E by flat r (E) defined as follows:<br />

<strong>co</strong>mp(flat r (E)) = <strong>co</strong>mp(E) − {r : E ′ } ∪ <strong>co</strong>mp(E ′ )<br />

attr(flat r (E)) = attr(E) ∪ attr(E ′ ) <strong>and</strong><br />

⎧<br />

⎨id(E) − {r : E ′ } ∪ id(E ′ )<br />

id(flat r (E)) =<br />

⎩id(E)<br />

for (r : E ′ ) ∈ id(E)<br />

• flatten occurrences of links l : M ′ in <strong>co</strong>ntent data types <strong>co</strong>nt(M ′ ) by simply<br />

substituting <strong>co</strong>nt(M ′ ) for l : M ′<br />

• the resulting raw media type will be denoted as flat l (M)<br />

• Example: a hierarchy in our example database is grape yard/<strong>co</strong>cktailery —<br />

region — <strong>co</strong>untry<br />

else

Hierarchical Versions (2/2)<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

• deflattening:<br />

• any subset P ⊆ <strong>co</strong>mp(E) ∪ attr(E) allows to replace E by raise P (E) <strong>and</strong><br />

a new database type E new defined as follows:<br />

<strong>co</strong>mp(raise P (E)) = <strong>co</strong>mp(E) − P ∪ {r new : E new } ,<br />

attr(raise P (E)) = attr(E) − P <strong>and</strong><br />

⎧<br />

⎨id(E) − P ∪ {r new : E new }<br />

id(raise P (E)) =<br />

⎩id(E)<br />

<strong>co</strong>mp(E new ) = P ∩ <strong>co</strong>mp(E) ,<br />

attr(E new ) = P ∩ attr(E) <strong>and</strong><br />

⎧<br />

⎨id(E)<br />

for id(E) ⊆ P<br />

id(E new ) =<br />

⎩P<br />

else<br />

for P ∩ id(E) ≠ ∅<br />

• define raise exp (M) for a <strong>co</strong>ntent expression occurring within <strong>co</strong>nt(M) by<br />

introducing a new link expression replacing exp<br />

• let ¯H(M) be the set of all raw media types arising from M by applying a sequence<br />

of flat- <strong>and</strong> raise-operations to raw media types or underlying database<br />

types<br />

• a set of hierarchical versions of M is a finite subset H(M) of ¯H(M) with<br />

M ∈ H(M)<br />

.<br />

else<br />

.

Media Types<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

• a media type is a unit-extended, <strong>order</strong>-extended raw media type<br />

M together with an adhesion <strong>order</strong> ≼ M <strong>and</strong> a set of hierarchical<br />

versions H(M)<br />

• extensions to raw media types require changes to the attached operations:<br />

• unit-extension: whenever values are <strong>co</strong>mputed, the translation of<br />

measure units has to be taken into ac<strong>co</strong>unt<br />

• <strong>order</strong>-extension: replace <strong>co</strong>mputations on sets by <strong>co</strong>mputations<br />

on lists<br />

• <strong>co</strong>hesion / adhesion: split operations as well<br />

• hierarchies: extend or reduce operations as well<br />

• in addition decide for each operation on its importance: ‘nice to<br />

have’ or ‘indispensible’<br />

Information<br />

Concept<br />

Topic

Usage Modelling<br />

• distinguish between user roles <strong>and</strong> user types:<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

• a role <strong>co</strong>rresponds to specific tasks to be done on the site: normal user /<br />

client, administrator, etc.<br />

• roles are associated with access rights<br />

• a user type <strong>co</strong>rresponds to different behaviour<br />

• modeling user types:<br />

• finite set ∆ of user dimensions, e.g.,<br />

∆ = {goal-orientation, presentation preferences}<br />

• each dimension δ ∈ ∆ has a scale sc(δ) (totally <strong>order</strong>ed set), e.g.,<br />

sc(goal-orientation) = {surfer, navigator, searcher}<br />

surfer ≤ navigator ≤ searcher<br />

• the set of user profiles over ∆ = {δ 1 , . . . , δ n } is<br />

gr(∆) = sc(δ 1 ) × · · · × sc(δ n ) .<br />

• a user type over ∆ is a <strong>co</strong>nvex region U ⊆ gr(∆)<br />

Concept<br />

Topic

Example<br />

• roles in the bottle shop example:<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

• occasional client: access to normal offers / catalogue<br />

• client who is a member of the club: access to special offers<br />

• product officer: access to add / delete offered products<br />

• marketing officer: access to add / delete offers <strong>and</strong> specials<br />

• vendor: access to update quantities on stock<br />

• user types (as above) apply to the first two roles<br />

Content<br />

Information<br />

Concept<br />

Topic

Relationship to Scenarios<br />

• <strong>co</strong>nsider stories, i.e., sequences of user actions<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

• abstract description by certain directed graphs: scenarios<br />

• a scenario is a finite, directed graph G = (V, E), where the nodes<br />

are called scenes<br />

• associate with each scene sc a view V sc (information <strong>co</strong>nsumption)<br />

<strong>and</strong> a user type U sc<br />

• associate with each edge from sc 1 to sc 2 a data type (information<br />

<strong>co</strong>mmunicated)<br />

• scenes will be supported by media objects, but media objects are<br />

not <strong>co</strong>upled to just one scene<br />

Content<br />

Information<br />

Concept<br />

Topic

Example<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

interest<br />

in red grape<br />

grape yards catalogue special grapes<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

general grapes<br />

information<br />

additional<br />

information<br />

offers<br />

bargains<br />

wish list <strong>co</strong>mment <strong>order</strong><br />

Content<br />

Information<br />

Concept<br />

Topic

Figures<br />

• use a restricted form of media types to support session objects<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

• formally, a session object S <strong>co</strong>nsists of a data type T (S), a role r(S), a user<br />

type U(S) <strong>and</strong> operations op(S)<br />

• session objects occur as es<strong>co</strong>rt information on all visited pages<br />

• these are created on entering the site <strong>and</strong> kept persistent during the whole site<br />

visit<br />

• session objects are used to support metaphors / figures:<br />

• wish list, trolley, cart, cashier, <strong>order</strong> form, etc. in e-<strong>co</strong>mmerce<br />

• time table, note book, etc. for <strong>co</strong>mmunity sites<br />

• guide, floor plan, help desk, note book, news feeds, etc. for entertainment<br />

/ edutainment<br />

• Example: in the bottle shop example the cart is a session object<br />

Content<br />

Information<br />

Concept<br />

Topic

Presentation: The Container Metaphor<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

• underlying picture: selected information will be wrapped, loaded<br />

into a (generic) <strong>co</strong>ntainer, shipped to the user <strong>and</strong> then unloaded<br />

• a <strong>co</strong>ntainer has a name C <strong>and</strong> <strong>co</strong>nsists of<br />

• a <strong>co</strong>ntent data type <strong>co</strong>nt(C)<br />

• <strong>and</strong> a presentation layout lay(C)<br />

• influences on <strong>co</strong>ntainer <strong>design</strong>:<br />

• usage of media objects in the scenarios<br />

• user types<br />

• technical <strong>co</strong>nstraint: size <strong>and</strong> presentation facilities of supported<br />

presentation devices, e.g., sizes tiny, small, normal, large<br />

Content<br />

Information<br />

Concept<br />

Topic

Presentation: The Container Metaphor<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

• <strong>co</strong>ntainer parameters:<br />

• capacity of a <strong>co</strong>ntainer means restrictions to size of representable<br />

data types<br />

• loadability of a media object (u, (M 1 : v 1 , . . . , M k : v k )) into<br />

a <strong>co</strong>ntainer C holds, if the <strong>co</strong>ntent data type <strong>co</strong>nt(M i ) is a<br />

supertype of <strong>co</strong>nt(C) for at least one i<br />

• for low capacity exploit prefetching, caching in ac<strong>co</strong>rdance with<br />

the split due to adhesion<br />

• unloadability means the representability of the <strong>co</strong>ntainer <strong>co</strong>ntent<br />

on a given device<br />

• wrapping of the media object (u, (M 1 : v 1 , . . . , M k : v k )) into the<br />

<strong>co</strong>ntainer C means the identification of the suitable M i in <strong>order</strong> to<br />

load a maximum amount of information<br />

• loading of the <strong>co</strong>ntainer <strong>co</strong>nsists in the generation of the page<br />

replacing the parameters by the loaded information<br />

• we may use style rules for the <strong>co</strong>ntainer layout

Example<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

interest<br />

in red grape<br />

grape yards catalogue special grapes<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

large<br />

es<strong>co</strong>rt info<br />

large<br />

general grapes<br />

information<br />

additional<br />

information<br />

offers<br />

bargains<br />

wish list <strong>co</strong>mment <strong>order</strong><br />

small / middle<br />

es<strong>co</strong>rt info<br />

small<br />

middle<br />

Content<br />

Information<br />

Concept<br />

Topic

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

Publications on Co-Design<br />

• Düsterhöft, A., Thalheim, B.: SiteLang: Conceptual Modelling of Internet Sites. Proc. ER’2001, LNCS 2224,<br />

179 - 192. Application to webservices<br />

• Feyer, Th.; Thalheim, B.: E/R Based Scenario Modelling for Rapid Prototyping of Web Information Services.<br />

Proc. WWWCM’99, 253 - 263. Application to webservices generation<br />

• G. Fiedler, H. Jaakkola, T. Mäkinen, B. Thalheim, <strong>and</strong> T. Varkoi. Co-<strong>design</strong> of web information systems<br />

supported by SPICE. Information Modelling <strong>and</strong> Knowledge Bases, XX:123–138, 2009.<br />

• Goldin, D., Srinivasa, S., Thalheim, B.: IS=DBS + Interaction: Towards principles of information system<br />

<strong>design</strong>. Proc. ER 2000, LNCS 1920, 140 - 153. The theoretical foundation<br />

• Klettke, M.: Reuse of database <strong>design</strong> decisions. Proc. REIS’2000, LNCS 1727, 213-224. Reuse structures<br />

<strong>and</strong> intelligently acquire integrity <strong>co</strong>nstraints<br />

• Lewerenz, J., Schewe, K.-D., Thalheim, B.: Modelling data warehouses <strong>and</strong> OLAP applications by means of<br />

dialogue objects. Proc. ER’1999, LNCS 1728, 354-368. OLAP in a <strong>co</strong>nsistent, powerful <strong>and</strong> simple way<br />

• K.-D. Schewe <strong>and</strong> B. Thalheim. The <strong>co</strong>-<strong>design</strong> approach to web information systems development. International<br />

Journal of Web Information Systems, 1(1):5–14, March 2005.<br />

• Schewe, K.-D.; Thalheim, B.: Towards a theory of <strong>co</strong>nsistency enforcement. Acta Informatica, 36, 1999, 97-141.<br />

Instead of falling into the traps of rule triggering systems<br />

• Steeg, M; Thalheim, B.: Conceptual Database Application Tuning. Proc. SCI’2000, 226-231. Tune instead of<br />

normalize<br />

• Thalheim, B.: Entity-Relationship Modelling - Foundations of Database Technology. Springer, Berlin, 2000.<br />

The HERM “bible”<br />

• Thalheim, B.: Logics <strong>and</strong> Database Modelling. Proc. ICLP ‘99, MIT Press, 6-21. The <strong>relationship</strong> to logics<br />

• Thalheim, B.: Co<strong>design</strong> of database systems <strong>and</strong> interaction - Thin <strong>and</strong> <strong>co</strong>nsistent UML. Proc. OTS’2000,<br />

1-17. Co<strong>design</strong> - the ultimate basis for best practices UML

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

Publications on Web IS Engineering<br />

• A. Binemann-Zdanowicz. Sitelang::edu - towards a <strong>co</strong>ntext-driven e-learning <strong>co</strong>ntent utilization model. In<br />

Proc. SAC’2004 (ACM SIGAPP), Ni<strong>co</strong>sia, Cyprus, March 2004, pages 924–928. Association for Computing<br />

Machinery, 2004.<br />

• A. Düsterhöft <strong>and</strong> B. Thalheim. Linguistic based search facilities in snowflake-like database schemes. Data<br />

<strong>and</strong> Knowledge Engineering, 48:177–198, 2004.<br />

• T. Feyer, K.-D. Schewe, <strong>and</strong> B. Thalheim. Conceptual <strong>design</strong> <strong>and</strong> development of information services. In<br />

Proc. ER’98, LNCS 1507, Springer, 1998, pages 7–20. Springer, Berlin, 1998.<br />

• R. Kaschek, K.-D. Schewe, B. Thalheim, <strong>and</strong> Lei Zhang. Integrating <strong>co</strong>ntext in <strong>co</strong>nceptual <strong>modelling</strong> for<br />

web information systems, web services, e-business, <strong>and</strong> the semantic web. In WES 2003, LNCS 3095, pages<br />

77–88. Springer, 2003.<br />

• T. Moritz, R. Noack, K.-D. Schewe, <strong>and</strong> B. Thalheim. Intention-driven screenography. In Proceedings ISTA<br />

2007, volume LNI 107, pages 128–139, 2007.<br />

• T. Moritz, K.-D. Schewe, <strong>and</strong> B. Thalheim. Strategic <strong>modelling</strong> of web information systems. International<br />

Journal on Web Information Systems, 1(4):77–94, 2005.<br />

• K.-D. Schewe <strong>and</strong> B. Thalheim. Conceptual <strong>modelling</strong> of web information systems. Data <strong>and</strong> Knowledge<br />

Engineering, 54:147–188, 2005.<br />

• K.-D. Schewe <strong>and</strong> B. Thalheim. Pragmatics of storyboarding for web information systems: Usage analysis.<br />

Int. Journal Web <strong>and</strong> Grid Services, 3(2):128–169, 2007.<br />

• K.-D. Schewe <strong>and</strong> B. Thalheim. Personalisation of web information systems - a term rewriting approach.<br />

Data <strong>and</strong> Knowledge Engineering, 62(1):101–117, 2007.<br />

• B. Thalheim. Readings in fundamentals of interaction in information systems. Reprint, BTU-Cottbus,<br />

accessible through http://www.is.informatik.uni-kiel.de/∼thalheim, Collection of papers by C. Binder, W.<br />

Clauß, A. Düsterhöft, T. Feyer, T. Gutacker, B. Heinze, J. Lewerenz, M. Roll, B. Schewe, K.-D. Schewe, K.<br />

Seelig, S. Srinivasa, B. Thalheim, 2000.<br />

• B. Thalheim <strong>and</strong> A. Düsterhöft. Sitelang: Conceptual modeling of internet sites. In H. S. Kunii, S. Jajodia,<br />

<strong>and</strong> A. Sølvberg, editors, ER, volume 2224 of LNCS, pages 179–192. Springer, 2001.

Publications on Science <strong>and</strong> Art of<br />

Conceptual Modelling<br />

• A. Dahanayake <strong>and</strong> B. Thalheim. Towards a framework for emergent modeling. In ER Workshops,<br />

volume 6413 of Lecture Notes in Computer Science, 128–137. Springer, 2010.<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Content<br />

Information<br />

• A. Dahanayake <strong>and</strong> B. Thalheim. Enriching <strong>co</strong>nceptual <strong>modelling</strong> practices through <strong>design</strong><br />

science. In BMMDS/EMMSAD, volume 81 of Lecture Notes in Business Information Processing,<br />

497–510. Springer, 2011.<br />

• B. Thalheim. Towards a theory of <strong>co</strong>nceptual <strong>modelling</strong>. Journal of Universal Computer Science,<br />

2010, 16, 20, 3102–3137.<br />

• B. Thalheim. The theory of <strong>co</strong>nceptual models, the theory of <strong>co</strong>nceptual <strong>modelling</strong> <strong>and</strong> foundations<br />

of <strong>co</strong>nceptual <strong>modelling</strong>. In The H<strong>and</strong>book of Conceptual Modeling: Its Usage <strong>and</strong> Its<br />

Challenges, chapter 12, 543–578. Springer, Berlin, 2011.<br />

• B. Thalheim. The science of <strong>co</strong>nceptual <strong>modelling</strong>. In Proc. DEXA 2011, volume 6860 of LNCS,<br />

12–26, Berlin, 2011. Springer.<br />

• B. Thalheim. Integrity <strong>co</strong>nstraints in (<strong>co</strong>nceptual) database models. In The Evolution of Conceptual<br />

Modeling, volume 6520 of Lecture Notes in Computer Science, 42–67, Berlin, 2011.<br />

Springer.<br />

• B. Thalheim. The art of <strong>co</strong>nceptual <strong>modelling</strong>. In Proc. EJC 2011, 203–222, Tallinn, 2011.<br />

• B. Thalheim. Culture <strong>and</strong> art of <strong>co</strong>nceptual <strong>modelling</strong>. Anwendungsorientierte Organisationsgestaltung,<br />

127–144. baar, Hamburg, 2011.<br />

Concept<br />

Topic

Publications on Model Suites, Evolution,<br />

Migration<br />

• A. Dahanayake <strong>and</strong> B. Thalheim. Co-evolution of (information) system models. In EMMSAD<br />

2010, volume 50 of LNBIP, 314–326. Springer, 2010.<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

• A. Dahanayake <strong>and</strong> B. Thalheim. Towards a framework for emergent modeling. In ER Workshops,<br />

volume 6413 of Lecture Notes in Computer Science, 128–137. Springer, 2010.<br />

• M. Klettke <strong>and</strong> B. Thalheim. Evolution <strong>and</strong> migration of information systems. In The H<strong>and</strong>book<br />

of Conceptual Modeling: Its Usage <strong>and</strong> Its Challenges, chapter 12, 381–420. Springer, Berlin,<br />

2011.<br />

• B. Neumayr <strong>and</strong> M. Schrefl und B. Thalheim. Modeling techniques for multi-level abstraction.<br />

In The Evolution of Conceptual Modeling, volume 6520 of Lecture Notes in Computer Science,<br />

68–92, Berlin, 2011. Springer.<br />

• B. Thalheim. Model suites. In H. Jaakkola, editor, Selected Topics on Distributed Disaster<br />

Management: Towards Collaborative Knowledge Clusters., 108 – 128. Tampere University Press,<br />

Porin yksikkö, 2008.<br />

• B. Thalheim. The <strong>co</strong>nceptual framework to multi-layered database <strong>modelling</strong>. In Proc. EJC,<br />

118–138, Maribor, Slovenia, 2009.<br />

• B. Thalheim. Model suites for multi-layered database <strong>modelling</strong>. In Information Modelling<br />

<strong>and</strong> Knowledge Bases XXI, volume 206 of Frontiers in Artificial Intelligence <strong>and</strong> Applications,<br />

116–134. IOS Press, 2010.

Publications on Pattern Development<br />

• T. Feyer, K.-D. Schewe, <strong>and</strong> B. Thalheim. Conceptual <strong>design</strong> <strong>and</strong> development of information<br />

services. In Proc. ER’98, LNCS 1507, Springer, 1998, 7–20. Springer, Berlin, 1998.<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

• T. Feyer <strong>and</strong> B. Thalheim. Many-dimensional schema modeling. In ADBIS 2002, LNCS 2435,<br />

305–318. Springer, 2002.<br />

• T. Feyer <strong>and</strong> B. Thalheim. A model for defining <strong>and</strong> <strong>co</strong>mposing interaction pattern. In EJC’2002,<br />

volume Information Modelling <strong>and</strong> Knowledge Bases XIV, 277–289, 2002.<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

• Hui Ma, K.-D. Schewe, <strong>and</strong> B. Thalheim. Modelling <strong>and</strong> maintenance of very large database<br />

schemata using meta-structures. In UNISCON, volume 20 of Lecture Notes in Business<br />

Information Processing, 17–28. Springer, 2009.<br />

• K.-D. Schewe <strong>and</strong> B. Thalheim. Development of <strong>co</strong>llaboration frameworks for web information<br />

systems. In IJCAI’07 (20th Int. Joint Conf on Artificial Intelligence), Section EMC’07<br />

(Evolutionary models of <strong>co</strong>llaboration), 27–32, Hyderabad, 2007.<br />

• B. Thalheim. Many-dimensional database modeling on the basis of application frameworks.<br />

Technical Report Preprint I-08-2000, Br<strong>and</strong>enburg University of Technology at Cottbus, Institute<br />

of Computer Science, 2000.<br />

• B. Thalheim. The person, organization, product, production, <strong>order</strong>ing, delivery, invoice, ac<strong>co</strong>unting,<br />

budgeting <strong>and</strong> human resources pattern in database <strong>design</strong>. Technical Report I-07-2000,<br />

Computer Science Institute, Br<strong>and</strong>enburg University of Technology at Cottbus, 2000.

Publications on Component Development<br />

• A. Düsterhöft <strong>and</strong> B. Thalheim. Linguistic based search facilities in snowflake-like database schemes.<br />

Data <strong>and</strong> Knowledge Engineering, 48:177–198, 2004.<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

• T. Feyer <strong>and</strong> B. Thalheim. Component-based interaction <strong>design</strong>. In EJC’2003, volume Information<br />

Modelling <strong>and</strong> Knowledge Bases XV, 19 – 36, 2003.<br />

• G. Fiedler <strong>and</strong> B. Thalheim. An approach to <strong>co</strong>nceptual schema evolution. Technical report,<br />

Christian-Albrechts-Universität Kiel, 2007.<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

• K.-D. Schewe <strong>and</strong> B. Thalheim. Component-driven engineering of database applications. In Markus<br />

Stumptner, Sven Hartmann, <strong>and</strong> Yasushi Kiyoki, editors, Third Asia-Pacific Conference on Conceptual<br />

Modelling (APCCM2006), volume 53 of CRPIT, 105–114, Hobart, Australia, 2006. ACS.<br />

• P. Schmidt <strong>and</strong> B. Thalheim. Component-based modeling of huge databases. In ADBIS’2004,<br />

LNCS 3255, 113–128, 2004.<br />

• B. Thalheim. Component <strong>co</strong>nstruction of database schemes. In Proc. ER’02, LNCS 2503, 20–34.<br />

Springer, 2002.<br />

• B. Thalheim. Component development <strong>and</strong> <strong>co</strong>nstruction for database <strong>design</strong>. Data <strong>and</strong> Knowledge<br />

Engineering, 54:77–95, 2005.<br />

• B. Thalheim. Engineering database <strong>co</strong>mponent ware. In TEAA’06 post proceedings, LNCS 4473,<br />

1–15, Berlin, 2007. Springer.

Publications on Content Management<br />

• A. Düsterhöft <strong>and</strong> B. Thalheim. Information Modeling for Internet applications, chapter Systematic<br />

development of internet sites: Extending approaches of <strong>co</strong>nceptual modeling, pages<br />

80–101. Idea Group Publishing, 2003.<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

Concept<br />

Content<br />

Information<br />

Topic<br />

• G. Fiedler, A. Czerniak, D. Fleischer, H. Rumohr, M. Spindler, <strong>and</strong> B. Thalheim. Content<br />

Warehouses. Preprint 0605, Department of Computer Science, Kiel University, March 2006.<br />

• G. Fiedler <strong>and</strong> B. Thalheim. Towards linguistic foundations of <strong>co</strong>ntent management. In Springer,<br />

editor, NLDB’2004, LNCS 3136, pages 348–353, 2004.<br />

• G. Fiedler <strong>and</strong> B. Thalheim. Towards semantic wikis: Modelling intensions, topics, <strong>and</strong> origin in<br />

<strong>co</strong>ntent management systems. In Proc. EJC 2008, 2008.<br />

• T. Hashimoto, J. Henno, H. Jaakkola, A. Sasa, <strong>and</strong> B. Thalheim. Infrastructures for knowledge<br />

systems environments. In EJC, volume 237 of Frontiers in Artificial Intelligence <strong>and</strong> Applications,<br />

pages 369–398. IOS Press, 2011.<br />

• B. Thalheim. The <strong>co</strong>-<strong>design</strong> framework to <strong>co</strong>ntent specification. In W. Abramowicz, editor,<br />

BIS’2004, pages 326–351. IEEE Press, 2004.<br />

• B. Thalheim. The <strong>co</strong>nceptual framework to user-oriented <strong>co</strong>ntent management. In EJC’06,<br />

Trojanovice, May 2006.<br />

• B. Thalheim, Y. Kitawara, E. Karttunen, <strong>and</strong> H. Jaakkola. Future directions of knowledge<br />

systems environments for web 3.0. In Information Modelling <strong>and</strong> Knowledge Bases, volume 225<br />

of Frontiers in Artificial Intelligence <strong>and</strong> Applications, pages 413–446. IOS Press, 2011.

Publications on Privacy<br />

• S. S. Al-Fedaghi, G. Fiedler, <strong>and</strong> B. Thalheim. Privacy enhanced information systems. In EJC,<br />

volume 136 of Frontiers in Artificial Intelligence <strong>and</strong> Applications, pages 94–111. IOS Press,<br />

2005.<br />

Information<br />

Systems<br />

Co-Design<br />

4.7.2012<br />

B. Thalheim<br />

Why<br />

Co-Design?<br />

Layering<br />

Distribution<br />

Interactivity<br />

Methodology<br />

Media Types<br />

Open<br />

References<br />

• S. A. Al-Fedaghi <strong>and</strong> B. Thalheim. Databases of personal identifiable information. In Proc. 4th<br />

SITIS-SePTIS, pages 617–624. IEEE, ACM SIGAPP, 2008.<br />

• S. S. Al-Fedaghi <strong>and</strong> B. Thalheim. Personal information databases. CoRR, abs/0909.4196,<br />

2009.<br />

• B. Thalheim, S. S. Al-Fedaghi, <strong>and</strong> K. Al-Saqabi. Information stream based model for organizing<br />

security. In ARES, pages 1405–1412. IEEE Computer Society, 2008.<br />

• B. Thalheim. The <strong>co</strong>nceptual framework to user-oriented <strong>co</strong>ntent management. Series Frontiers<br />

in Arificial Intelligence, 154, Information Modelling <strong>and</strong> Knowledge Bases, XVII:30–49, 2007.<br />

Content<br />

Information<br />

Concept<br />

Topic

Database <strong>and</strong> Information Systems Theory<br />

Eötvös Loránd University of Sciences<br />

Budapest<br />

5.7.2012<br />

Bernhard Thalheim<br />

Technologie der Informationssysteme<br />

Institut für Informatik, Christian-Albrechts-Universität zu Kiel, BRD<br />

Kolmogorow-Professor e.h. der Lomonossow-Universität Moskau

Database <strong>and</strong> Information Systems Theory<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information

Observations<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Right logic in the best-fitted structure, in the best <strong>co</strong>mplexity <strong>and</strong><br />

micro-structure, fitted to its purpose <strong>and</strong> to the user<br />

• Counterexamples<br />

• Tuple calculus in relational database theory<br />

with the nonsense of safe formula<br />

• Null value logics without <strong>co</strong>nsideration of nil semantics <strong>and</strong><br />

pragmatics<br />

State of the art:<br />

• Relational databases: poor structuring <strong>and</strong> superficial, in<strong>co</strong>mprehensible<br />

classification of <strong>co</strong>nstraints<br />

• with many non-axiomatisation or non-decidability results<br />

• ER schemata: implicit structuring semantics<br />

Constraints with insufficient expressive power despite the high variety,<br />

e.g., cardinality <strong>co</strong>nstraints cannot express finiteness of cycles<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Distinguishability <strong>and</strong> Identifiability<br />

Objects with their way of identification.<br />

Value-representability is a must.<br />

Objects with their properties (intext).<br />

Objects with their <strong>co</strong>ntext<br />

e.g. <strong>relationship</strong>s to other objects, <strong>co</strong>ncerns, viewpoints<br />

General management of worlds, e.g., <strong>relationship</strong>s with properties<br />

also many-dimensional, multi-layered<br />

Detecting cycles is a nightmare. Cyclic structuring leads to nonfirst-<strong>order</strong><br />

logics. Structures with abstract linking are potentially<br />

cyclic.<br />

The OID has already been implemented by relational databases:<br />

tuple identifier. The OID is too expressive.<br />

Object-oriented approaches have improved <strong>and</strong> damaged culture at the<br />

same time.<br />

Next after OO: <strong>co</strong>mponents!!!!<br />

Content<br />

Information

Pearls of Structuring<br />

✞<br />

✝Lessons Learned for the Good<br />

☎<br />

✆<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Hierarchical structuring of types leads to a generalized first-<strong>order</strong> predicate<br />

logics.<br />

Optionality is difficult <strong>and</strong> is h<strong>and</strong>led by<br />

weak semantics for object sets O with <strong>co</strong>mpon opt (O) ≠ ∅<br />

not true: O |= {α 1 , ...., α m } iff O |= {α i }<br />

strong semantics for object sets O with <strong>co</strong>mpon opt (O) ≠ ∅<br />

in general: O ̸|= α → α<br />

O |= α → β <strong>and</strong> O |= β → γ do not imply O |= α → γ .<br />

Axiomatizability: Implication operator Φ ∗ |=<br />

reflexive, monotone, closed<br />

<strong>and</strong> <strong>co</strong>mpact ⇔ deductive system Γ Φ Γ ≡ Φ |=<br />

Φ |= inference , deduction properties <strong>and</strong> generalization invariant:<br />

Φ ∗ Γ (∅) = Φ∗ |= (∅)<br />

Content<br />

Information

Constraints<br />

✞<br />

Insufficient Expressivity of Database Models<br />

✝<br />

☎<br />

✆<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Functional, key, inclusion <strong>and</strong> exclusion dependencies are <strong>co</strong>nstraints<br />

that are natural in the relational model<br />

Key-based inclusion dependencies are h<strong>and</strong>icapped<br />

Multi-valued dependencies are far better expressed in the ER model<br />

Cardinality <strong>co</strong>nstraints are overloaded<br />

better treat maximal <strong>and</strong> minimal cardinality in separate systems<br />

Integrity enforcement is treated separately for types<br />

Join dependencies are representational <strong>co</strong>nstraints<br />

Content<br />

Information

Static Integrity Constraints<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Conceptual<br />

layer<br />

Implementation<br />

layer<br />

functional,<br />

equalitygenerating<br />

key, uniqueness,<br />

trigger, check<br />

inde-<br />

relative<br />

pendence<br />

Partial identification<br />

multivalued,<br />

hierarchical,<br />

join, exclusion,<br />

tuplegenerating<br />

<strong>co</strong>nstraint,<br />

horizontal<br />

de<strong>co</strong>mposition<br />

de<strong>co</strong>mposition,<br />

stored procedures,<br />

trigger<br />

existence <strong>co</strong>nstraint<br />

null-valuefree,<br />

union<br />

<strong>co</strong>nstraint,<br />

numerical,<br />

cardinality<br />

no null, stored<br />

procedures,<br />

trigger<br />

redundancy<br />

<strong>co</strong>nstraint<br />

inclusion, exclusion<br />

<strong>co</strong>nstraint<br />

referential integrity,<br />

surrogate,<br />

capsules<br />

User layer identification structure ! no null elementary<br />

facts<br />

✞<br />

☎<br />

95 classes in “Dependencies in Relational Databases”!!<br />

✝<br />

✆<br />

Content<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information<br />

Optimisation of Behaviour Through<br />

Normalisation of Database Structuring<br />

✞<br />

☎<br />

Normalisation as a vehicle for performance improvement<br />

✝<br />

✆<br />

(A) Redundancy problematic whenever additional actions are required;<br />

(B) Blocking of management due to the information capacity of the schema (e.g.,<br />

insertion anomaly);<br />

(C) Information loss after database modification whenever data are eagerly deleted<br />

(e.g., deletion anomaly);<br />

(D) Evolution sensitivity <strong>and</strong> instability of the database due to changes;<br />

(E) Different abstractions at the same time (e.g., views, derived attributes, logs as<br />

part of structures);<br />

(F) Performance problems caused by integrity <strong>co</strong>nstraint maintenance (e.g., update<br />

anomalies);<br />

denormalisation, index management, inflexibility against evolutionary changes;<br />

(G) Expensive maintenance, operating <strong>and</strong> modification due to <strong>co</strong>nsistency maintenance.

The Constraints H<strong>and</strong>ling Framework<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

(1) Specification level: description of the <strong>co</strong>nstraints<br />

property, validation, policies for evaluation, specific policies, transformations<br />

of <strong>co</strong>nstraint properties to others;<br />

(2) Control or technical level: application of the <strong>co</strong>nstraint<br />

<strong>co</strong>nstraint property portfolio, techniques <strong>and</strong> methods<br />

(e.g., cascade, restrict, no action, defaultify nullify);<br />

(3) Application or technology level: management of <strong>co</strong>nstraint h<strong>and</strong>ling<br />

(4) Establishment or organisational level: based on a methodology <strong>and</strong><br />

<strong>co</strong>nstraint maintenance system.<br />

Level five: facilities for h<strong>and</strong>ling satisfaction of <strong>co</strong>nstraints <strong>and</strong> for predicting changes<br />

of satisfaction<br />

Level six optimises the <strong>co</strong>nstraint management;<br />

Level seven uses experiences for innovation <strong>and</strong> adaptation.<br />

Content<br />

Information

Constraints: Forgotten Properties<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Functional dependencies: ∀x 1 , x 2 (ψ(x 1 , x 2 ) → ϕ(x 1 , x 2 )), expressible<br />

through equality sets, invariance properties for subsets, sensitive<br />

against supersets, pair algebra, two-tuple-implication<br />

Hierarchical dependencies: reasoning through the tableau calculus,<br />

not invariant for most operations, semantical gap between FD’s <strong>and</strong><br />

MVD’s, variety of definitions<br />

Implicit model assumptions: <strong>co</strong>mponent inclusion <strong>co</strong>ndition, identifiability<br />

whenever set semantics, cycles <strong>and</strong> finiteness, superficial<br />

structural representation<br />

Normalization as structural instead of behavioral optimization<br />

Schema transformation <strong>and</strong> equivalence<br />

Content<br />

Information

Constraints: Supplanted Properties<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Finiteness properties: finite implication, finite calculi, finite representation<br />

of potentially infinite sets, finite <strong>co</strong>mputation (‘safety’)<br />

Parallel execution: transaction based <strong>co</strong>ncurrent semantics, causal<br />

semantics of processes, predicative semantics for engines<br />

Unsafety of data: null values (overloaded, logics, <strong>co</strong>mputation, identification),<br />

fuzzy data with error model, aggregated macro-data versus<br />

micro-data<br />

Completeness of specification: infeasible for humans, normal forms<br />

based on <strong>co</strong>mpleteness, <strong>order</strong> dependence of (normalization) algorithms,<br />

time-dependence of <strong>co</strong>nstraints validity, real-life <strong>co</strong>nstraints<br />

Weak <strong>co</strong>nstraints: deontic maintenance, temporal maintenance,<br />

default values<br />

Content<br />

Information

Normal Forms<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Maintenance through keys, domain <strong>and</strong> referential <strong>co</strong>nstraints<br />

Forbidden substructures used for the definition of normal forms, e.g.,<br />

3NF: Z → {A} ∈ Σ + , A ∉ Z , A non-key attribute Z → U ∉ Σ +<br />

Boyce-Codd-Normalform: Z → {A} ∈ Σ + , A ∉ Z , Z → U i ∉ Σ +<br />

4NF: Z →→ X ∈ Σ + , X ⊈ Z , Z → U ∉ Σ +<br />

5NF: (Y 1 , ..., Y k ) ∈ Σ + , ∃j : Y j → U i ∉ Σ +<br />

Project-Join-NF: (Y 1 , ..., Y k ) ∈ Σ + , {X → U i ∈ Σ + } ̸|= (Y 1 , ..., Y k )<br />

Inklusion-NF: R i [X ] ⊆ R j [Y ] ∈ Σ + , Y → U j ∉ Σ +<br />

Domain-Key NF (DKNF): α ∈ Σ + , non-trivial, Σ K ̸|= α<br />

more than 35 other useful normal forms have been introduced<br />

Synthesis <strong>and</strong> de<strong>co</strong>mposition algorithms<br />

Content<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information<br />

Solved <strong>and</strong> Open Problems<br />

class axiomatiz. <strong>co</strong>mplexity<br />

keys<br />

keys (bounded domains)<br />

keys (with nulls)<br />

Hilbert/Gentzen worst average<br />

√ Hilbert √ √<br />

√ Hilbert √ √<br />

√ Hilbert<br />

√<br />

<strong>co</strong>nj.<br />

keys NF 2 ? √LogChar (hierarch.) ???? ???<br />

√<br />

fd’s<br />

Hilbert<br />

, √ Graph √<br />

<strong>co</strong>nj.<br />

√<br />

Hungarian deps<br />

LogChar<br />

?? ??<br />

√<br />

multivalued deps<br />

Hilbert<br />

, √ Graph<br />

????? ????<br />

√<br />

hierarchical deps.<br />

Hilbert<br />

, √ Graph<br />

?? ??<br />

√<br />

join deps.<br />

Gentzen<br />

?? ??<br />

√<br />

cardinality <strong>co</strong>nstr.<br />

Charact.<br />

?? ??<br />

√<br />

inclusion/exclusion<br />

Hilbert<br />

????? ????<br />

transition <strong>co</strong>nstr. ????? ??? ???<br />

✞<br />

☎<br />

Warning: Hilbert-/Gentzen-kind calculi are only one option !<br />

✝<br />

✆

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Problems: Implicit Model-Inherent<br />

Integrity Constraints<br />

Typical implicit model-inherent integrity <strong>co</strong>nstraints:<br />

Component-<strong>co</strong>nstruction <strong>co</strong>nstraints existence, cardinality <strong>and</strong> inclusion<br />

of <strong>co</strong>mponents;<br />

Identification <strong>co</strong>nstraints implicitly used for the set <strong>co</strong>nstructor<br />

value-representability or weak-value representability;<br />

Acyclicity <strong>and</strong> finiteness of structuring<br />

cardinality <strong>co</strong>nstraints may be based on potentially infinite cycles;<br />

Implicit meaning of <strong>co</strong>nstraints ,e.g., value <strong>co</strong>nstruction, optional/m<strong>and</strong>atory<br />

existence, derived value/object, identification,<br />

union, <strong>co</strong>mbination/association;<br />

Superficial structuring leads to representation of <strong>co</strong>nstraints through<br />

structures.<br />

Content<br />

Information

However: Enrichment<br />

✞<br />

☎<br />

Lessons of implicit definition<br />

✝<br />

✆<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Component-<strong>co</strong>nstruction <strong>co</strong>nstraints: existence, cardinality, inclusion<br />

impact on translation <strong>and</strong> implication<br />

Identification <strong>co</strong>nstraints: set, list <strong>co</strong>nstructors<br />

Acyclicity <strong>and</strong> finiteness of structuring supports axiomatization <strong>and</strong> definition<br />

of the algebra<br />

Superficial structuring leads to representation of <strong>co</strong>nstraints through<br />

structures<br />

Implicit model-inherent <strong>co</strong>nstraints belong to the performance <strong>and</strong><br />

maintenance traps.<br />

Content<br />

Information

Problems: Modelling Problems with<br />

Constraints<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Representable by structuring e.g. join dependencies<br />

X →→ Y |Z<br />

Y ∩ Z = ∅, X ∪ Y ∪ Z = R<br />

another relational representation by de<strong>co</strong>mposition :<br />

X Y<br />

<br />

...... .....<br />

X first se<strong>co</strong>nd<br />

Y Z<br />

...... ..... .....<br />

X Z<br />

..... .....<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Humans Do you reason abstractly ?<br />

Can you underst<strong>and</strong> logics ?<br />

Do you underst<strong>and</strong> your <strong>co</strong>lleagues semantics ?<br />

Systems Are there systems which use integrity <strong>co</strong>nstraints beyond keys, referential integrity<br />

<strong>and</strong> domain <strong>co</strong>nstraints?<br />

Content<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information<br />

Problems: Computational Problems with<br />

Constraints<br />

Combinatorial <strong>co</strong>mplexity is exponential<br />

necessary <strong>co</strong>mplete set of <strong>co</strong>nstraints for normalization, optimization<br />

either we need to know all valid <strong>co</strong>nstraints (CWA) or to know<br />

<strong>co</strong>nstraints which are valid <strong>and</strong> invalid<br />

Too simple properties simple axiomatisation, ...<br />

“too simple” is misunderstood <strong>and</strong> taken for granted, also intentionally<br />

extended to all other cases<br />

Maintenance of <strong>co</strong>nsistency full of mis-<strong>co</strong>nceptions<br />

triggers are only <strong>and</strong> only applicable to strict hierarchical <strong>co</strong>nstraint<br />

sets<br />

but active database people believe in triggering<br />

solution: greatest <strong>co</strong>nsistent specialization approach to refinement of operations<br />

Object-identification through identifiers has to be supported by value<br />

identification<br />

thus XML will never have a <strong>co</strong>mputational query algebra

Combinatorial Problems with Constraints 1<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Maximal number of minimal keys (sharp)<br />

( n<br />

(J. Demetrovics (1979))<br />

⌊ n 2 ⌋ )<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Restricted domains<br />

| dom(B i ) |≤ k (1 ≤ i ≤ n) k 4 < 2n + 1<br />

(β (1984))<br />

( n<br />

⌊ n 2 ⌋ )<br />

− ⌊ n 2 ⌋<br />

same behavior on non-uniform domains<br />

similar behavior in presence of null values<br />

(Selesnev, β (1985))<br />

Information

Combinatorial Problems with Constraints 2<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Functional dependencies<br />

maximum number N (n) of basic functional functional dependencies<br />

for schemata on n attributes<br />

2 n (<br />

1 − 4 log 2 log 2 n<br />

log 2 e log 2 n<br />

minimal generating sets of fd’s<br />

(1 + 1 ( ) n<br />

n ) 2 n/2<br />

closed families of fd’s<br />

)<br />

(1+o(1)) ≤ N (n) ≤ 2 n (<br />

≤ M (n) ≤ 2 n (<br />

)<br />

1 − log 3 2<br />

2 n<br />

150 √ n<br />

2 ( n<br />

⌊ n 2 ⌋ ) ≤ Cl(F, n) ≤ 2<br />

( n<br />

⌊ n 2 ⌋ )(1+o(1))<br />

1 − log 3 2<br />

2 n<br />

150 √ n<br />

(J. Demetrovics, G.O.H. Katona, D. Miklos, β & Hungarians (1982-<br />

2005))<br />

)<br />

Information

Combinatorial Problems with Constraints 3<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

rather than describing the entire set of basic functional dependencies<br />

use a relation R C which allows to reason on the set of <strong>co</strong>nstraints<br />

Armstrong relations - size<br />

( )<br />

1 n<br />

n 2 ⌊ n ⌋ 2<br />

≤ L {key} (n) ≤<br />

( n<br />

⌊ n 2 ⌋ )<br />

c 1 n k−1<br />

2 ≤ L {key(k)} (n) ≤ c 2 n k−1<br />

2<br />

1<br />

n 2 ( n<br />

⌊ n 2 ⌋ )<br />

≤ L F (n) ≤<br />

+ 1<br />

( n<br />

⌊ n 2 ⌋ )<br />

(1 + c 3<br />

√ n<br />

)<br />

(J. Demetrovics, G.O.H. Katona & Hungarians, β (1982-2005))<br />

Content<br />

Information

Good Case however: Average Complexity<br />

of Constraints 1<br />

<strong>co</strong>njecture: average relation has a key system of polynomial size<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

average relation: almost all minimal keys are of same length<br />

2 log ||D|| (R C )<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Poisson distribution<br />

deviation is <strong>co</strong>nstant<br />

if X is of length 2 log ||D|| (R C ) then X is minimal<br />

deviation decreases with increasing domain sizes<br />

same behaviour for the non-Bernoulli case<br />

small fraction of relations with large key systems<br />

similar results for functional dependencies<br />

(J. Demetrovics, G.O.H. Katona, D. Miklos, O. Selesnev, β, 1995-<br />

2005)<br />

Information

Good Case however: Average Complexity<br />

of Constraints 2<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

0.6<br />

0.5<br />

0.4<br />

D=2<br />

D=10<br />

D=4<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Length distribution<br />

0.3<br />

0.2<br />

0.1<br />

0<br />

2 4 6 8 10 12 14 16 18<br />

attributes<br />

Dependence on domain size<br />

Behavior of the Key Probability (Frequency Polygon)<br />

Content<br />

Information

Good Case however: Average Complexity<br />

of Constraints 3<br />

average length av n (l, 2) of minimal keys in relations with m tuples<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

r<strong>and</strong>om relation<br />

P(X → {A j }, l) =<br />

⌋ log 2 m⌊ ≤ av n (m, 2) ≤ 2⌋ log 2 m⌊ .<br />

⎧<br />

⎪⎨<br />

⎪⎩<br />

0 , if 2log l −<br />

∑<br />

A i ∈X H 2(κ i ) → +∞ ,<br />

e −2a−1 (2 −H 2 (κ j ) −1) ,<br />

if 2log l<br />

− ∑ A i ∈X H 2(κ i ) → a ,<br />

1 , if 2log l −<br />

∑<br />

A i ∈X H 2(κ i ) → −∞ .<br />

If X is a set of attributes of size definitely larger than 2 log l<br />

H 2<br />

{A j } holds with high probability for any A j .<br />

then X →<br />

Content<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Problems: Logical Problems Restricting<br />

Reasoning based on Constraints<br />

(un-)decidable implication<br />

P, NP, PSpace, ExpSpace, ...<br />

|= =|= fin or not<br />

Axiomatization or not Hilbert type Gentzen type<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Properties of <strong>co</strong>nstraint sets<br />

Decidability of implication<br />

decidable for tuple-generating <strong>and</strong> equality-generating dependencies<br />

undecidable for embedded JD’s<br />

undecidable for embedded MVD’s<br />

undecidable for FD’s <strong>and</strong> ID’s<br />

Axiomatizability of <strong>co</strong>nstraint classes<br />

FD’s <strong>and</strong> ID’s are not axiomatizable<br />

but weak FD’s <strong>and</strong> ID’s axiomatizable<br />

JD’s not axiomatizable<br />

but tuple-generating <strong>and</strong> equality-generating dependencies are axiomatizable<br />

Content<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Missing Research on Constraints<br />

✞<br />

H<strong>and</strong>ling <strong>co</strong>nstraints by their real nature!<br />

✝<br />

“Tuple-generating” <strong>co</strong>nstraints are in reality existence <strong>co</strong>nstraints<br />

value must (not) exist; also in domain, referenced type (inclusion/exclusion/<strong>co</strong>mponent),<br />

potentially also in same class (redundancy <strong>co</strong>nstraint)<br />

multivalued <strong>and</strong> hierarchical dependencies<br />

hidden properties, e.g., subset property<br />

“Equality-generating” <strong>co</strong>nstraints are in reality binding <strong>co</strong>nstraints<br />

value must/might (not) be equal, is potentially derivable,<br />

generalised to (p,q) <strong>co</strong>nstraints, used for cardinality <strong>co</strong>nstraints<br />

Cycle <strong>co</strong>nstraints are not yet developed<br />

cycle must/might (not) exist, cycles in values (‘marriage’, ‘friend’), cycle in types, cycles in value sets<br />

Logical gap between existence <strong>and</strong> binding <strong>co</strong>nstraints<br />

Derived <strong>co</strong>nstraints for derived structures<br />

Kinds of <strong>co</strong>nstraints ,e.g., explicit declaration, <strong>co</strong>upling, semantic association,<br />

semantic unit, structural representability<br />

☎<br />

✆<br />

Information

The Power of Functional Dependencies<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information<br />

A<br />

C<br />

C<br />

C<br />

A<br />

✛<br />

C<br />

✻<br />

R<br />

✲<br />

✛ R2<br />

R2 ✲ C ✛<br />

❄<br />

❄<br />

✛ R1 ✲ B A ✛ R1 ✲<br />

Schema 2<br />

Schema 3<br />

✛ R1 ✲ A ✛ R2 ✲ C<br />

Schema 1’<br />

✛ R1 ✲ A ✛ R2 ✲ C<br />

Schema 1<br />

Functional dependencies Schema after de<strong>co</strong>mposition<br />

{A} → {B} Schema 1<br />

{A} → {B} → {C } Schema 1’<br />

{A} → {B, C } Schema 1<br />

{A} ↔ {B} → {C } Schema 1, Schema 1’<br />

{A} ↔ {B, C } Schema 2<br />

{A} ↔ {B} ↔ {C } Schema 3<br />

{A} → {B} ← {C } Schema 3<br />

{A, B} → {C }<br />

no new schema<br />

{A} ↔ {B} Schema 1, Schema 1’<br />

B<br />

R3<br />

❄<br />

B

Axiomatisation of Functional Dependencies<br />

in HERM<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Classical: tuple <strong>and</strong> list <strong>co</strong>nstructors<br />

Y ⋐ X , X →Y<br />

,<br />

X →Y X →X ⊔ T Y<br />

X →Y , Y →Z<br />

X →Z<br />

HERM: tuple, list, set, <strong>and</strong> multiset <strong>co</strong>nstructors<br />

X , Y, Z ⊆ Sub(T )<br />

Y ⊆ X , , Y ≤ X , X →Y<br />

X →Y {X }→{Y } X →X ∪Y<br />

X →Y, Y→Z<br />

{X ,Y }→{X ⊔ N<br />

X, Y re<strong>co</strong>ncilable, ,<br />

Y } X →Z<br />

re<strong>co</strong>ncilable: inductively have the same structuring for tuple <strong>and</strong><br />

multiset <strong>co</strong>nstructors or Y ≤ X or X ≤ Y<br />

Y ≤ X : there exist a projection from X to Y<br />

X ⊔ T Y : lattice operation on T -subtypes<br />

c⃝Hartmann/Link DEXA 2005<br />

Content<br />

Information

Functional Dependencies<br />

✞<br />

✝Not as well understood as it seems!<br />

☎<br />

✆<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Explicit declaration of partial identification: explicitly declaring a functional association<br />

X Ident<br />

−→ Y .<br />

Tight functional <strong>co</strong>upling: numerical <strong>co</strong>nstraints i.e., X Num<br />

−→ Y<br />

Another denotation is based on cardinality <strong>co</strong>nstraints.<br />

Semantic <strong>co</strong>nstraint specific for the given application: application has a limited<br />

s<strong>co</strong>pe <strong>and</strong> allows us to strengthen the <strong>co</strong>nstraint X −→ Sem<br />

Y .<br />

Semantical unit with functional <strong>co</strong>upling: Semantical units are those reducts of<br />

a type that are essential in the given application X −→ Unit<br />

Y .<br />

Structural association among units: Semantical units may allow a separation of<br />

<strong>co</strong>ncerns for certain elements X Struct<br />

−→ Y .<br />

Content<br />

Information

Functional Dependencies<br />

✞<br />

✝Not as well understood as it seems!<br />

☎<br />

✆<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information<br />

A<br />

T A<br />

C<br />

(1,1)<br />

✛<br />

T A .to.T B<br />

{A} −→ {C }: explicit <strong>and</strong> direct dependency.<br />

{A} −→ {B} is an inter-type <strong>co</strong>nstraint <strong>and</strong> leaves the s<strong>co</strong>pe of type T A .<br />

Explicit declaration<br />

Tight <strong>co</strong>upling<br />

Semantic <strong>co</strong>nstraint<br />

Semantical unit<br />

Structural association<br />

instantiation<br />

✲<br />

B<br />

T B = StudyProgram , B = ProgramCode, D = ProgramName<br />

T A = Student, T A .to.T B = MajorProgram, T B = StudyProgram<br />

T B = StudyProgram , B = ProgramCode, D = Responsible-<br />

Professor<br />

T B = StudyProgram , B = ProgramCode, D = ProgramDegree<br />

T A = Student, T B = RegisteredStudent, A = PersonID, B<br />

= StudentNr<br />

T B<br />

D

Axiomatisation follows the Classical<br />

Approach<br />

Augmentation<br />

e.g.,<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Trivilisation<br />

of identification<br />

R : X Ident<br />

−→ Y ⊔ R Y ′<br />

R : X ⊔ R X ′<br />

Ident<br />

−→ Y<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information<br />

Implication<br />

e.g.:<br />

Adaptation of<br />

semantics s<strong>co</strong>pe<br />

R : X Sem<br />

−→ Y ⊔ R Y ′<br />

R : X ⊔ R X ′<br />

R : X Ident<br />

−→ Y , R : Y Sem<br />

−→ Z<br />

R : X Ident<br />

−→ Z<br />

R : X Sem<br />

−→ Y , R : Y Ident<br />

−→ Z<br />

R : X Sem<br />

−→ Z<br />

Sem<br />

−→ Y<br />

✞<br />

☎<br />

Axiomatisation as pair algebra <strong>and</strong> by lifting among types.<br />

✞<br />

✝<br />

✆<br />

☎<br />

Basis: subset, substructuring, implication properties of FD’s.<br />

✝<br />

✆

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Key Dependencies<br />

✞<br />

☎<br />

Descriptive meanings of the key <strong>co</strong>ncept depending on the levels<br />

✝<br />

✆<br />

Language definition level: uniqueness<br />

External level: uniqueness inherited<br />

expressed via identification<br />

existence property: se<strong>co</strong>ndary role<br />

integrity <strong>and</strong> accessibility <strong>co</strong>ncepts not under <strong>co</strong>nsideration<br />

Conceptual level: identification <strong>and</strong> integrity<br />

surrogate <strong>co</strong>ncept, key dependency<br />

Internal level: uniqueness <strong>co</strong>vered by identification<br />

additionally of interest: restrictions like invariant values in keys, accessibility<br />

✠<br />

identification<br />

uniqueness<br />

external level 7<br />

<strong>co</strong>nceptual level internal level<br />

identification<br />

(surrogate)<br />

existence<br />

<strong>language</strong> definition level<br />

❯<br />

integrity <strong>co</strong>nstraint<br />

(key dependency)<br />

❥<br />

3<br />

✲<br />

identification<br />

accessibility<br />

invariance<br />

Information

Explicit <strong>and</strong> Excluded Functional<br />

Dependencies<br />

X −→/ Y : the functional dependency X −→ Y is not valid.<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Axioms<br />

Rules<br />

(1)<br />

(6)<br />

(4)<br />

X −→ Y<br />

X ∪ V ∪ W −→ Y ∪ V<br />

(3)<br />

X −→/ Y<br />

X −→/ Y ∪ Z<br />

X −→ Z , X −→/ Y ∪ Z<br />

X −→/ Y<br />

X ∪ Y → Y<br />

(2)<br />

X −→ Y , X −→/ Z<br />

Y −→/ Z<br />

(7)<br />

X −→ Y , Y −→ Z<br />

X −→ Z<br />

(5) X ∪ Z −→/ Y ∪ Z<br />

X ∪ Z −→/ Y<br />

Y −→ Z , X −→/ Z<br />

X −→/ Y<br />

Content<br />

Information

Multivalued Dependency X →→ Y |Z<br />

Given a relational schema R = (U R , Σ R ), some relation R C on R<br />

subsets X , Y ⊆ U R <strong>and</strong> Z = U R \ (Y ∪ X )<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

(1) Classical definition: R C |= X →→ Y |Z<br />

if for all t, t ′ ∈ R C with t = X t ′ an object t ′′ ∈ R C<br />

exists with t ′′ = X ∪Y t <strong>and</strong> t ′′ = X ∪Y t ′<br />

(2) De<strong>co</strong>mposition definition: R C |= X →→ Y |Z<br />

if R C = R C [X ∪ Y ] R C [X ∪ Z ]<br />

We may further <strong>co</strong>nclude: If R C |= X −→ Y then R C |= X →→ Y |Z<br />

(3) Independence definition: R C |= X →→ Y |Z<br />

if (σ X =x (R C ))[Y ] = (σ (X =x)∧(Z =z ) (R C ))[Y ]<br />

for all X-values x ∈ R C [X ] <strong>and</strong> all Z-values z ∈ R C [Z ]<br />

Proof of equivalence: (1) ⇒ (2) ⇒ (3) ⇒ (1)<br />

E.g., for (1) ⇒ (2) we need to prove: R C ⊇ R C [X ∪ Y ] R C [X ∪ Z ]<br />

Given t 1 ∈ R C [X ∪ Y ] <strong>and</strong> t 2 ∈ R C [X ∪ Z ] mit t 1 = X t 2<br />

⇒ {t 1 } {t 2 } ⊆ R C because R C |= X →→ Y |Z<br />

Content<br />

Information

Multivalued Dependency X →→ Y |Z<br />

Given a relational schema R = (U R , Σ R ), some relation R C on R<br />

subsets X , Y ⊆ U R <strong>and</strong> Z = U R \ (Y ∪ X )<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

(4) Constructor definition: R C |= X →→ Y |Z<br />

if for all x ∈ R C [X ] with (σ X =x (R C ))[Y ∪ Z ] = (σ X =x (R C ))[Y ] ×<br />

(σ X =x (R C ))[Z ]<br />

i.e. ν Z (ν Y \X (ν X (R C ))) = ν Y \X (ν Z (ν X (R C )))<br />

(5) Structuring definition: R C |= X →→ Y |Z<br />

R C {X } {Y } {Z }<br />

A 1 ... A k A k+1 ... A m A m+1 ... A n<br />

... ... ... ... ... ... ... ... ...<br />

X = {A 1 , ..., A k }, Y = {A k+1 , ...., A m }, Z = {A m+1 , ..., A n }<br />

by a nested relation<br />

Content<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information<br />

Points of View through Separation<br />

Example: Employee, Dependent, Project, Supplier, Product<br />

{ Employee } →→ { Department, Dependent }|{ Project, Product, Supplier }<br />

{ Employee } →→ { Dependent }|{ Department, Project, Product, Supplier }<br />

{ Project } →→ { Employee, Department, Dependent }|{ Product, Supplier }<br />

{ Product } →→ { Department, Employee, Dependent, Project }|{ Supplier }<br />

Definition (6): MVD defined by two (Y,Z) <strong>relationship</strong> types<br />

can be generalised to hierarchical dependencies <strong>and</strong> n-ary <strong>relationship</strong> types<br />

Department<br />

✛<br />

✲<br />

DepBasis(Employee,Σ) \{ Employee} =<br />

Works<br />

OnIn<br />

❄<br />

✲<br />

Employee<br />

Product Project ✛ Supplier<br />

{{ Department }, { Dependent }, { Project, Product, Supplier }}<br />

DepBasis(Project,Σ) \{ Project} =<br />

{{ Product }, { Supplier }, { Employee, Department, Dependent }}<br />

✛<br />

Dependent

Derivation Rules for MVD <strong>and</strong> FD<br />

X , X ′ , X ′′ , Y , Y ′ , Z , Z ′ , V , W ⊆ U<br />

All sets within an MVD <strong>co</strong>nstitute a <strong>co</strong>ver of U<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Axiom: (1 F ) X ∪ Y −→ Y (1 M ) X →→ ∅|Z<br />

Rules X −→ Y<br />

(21 F )<br />

(FD − MVD reduction)<br />

X →→ Y<br />

X −→ Y , Y −→ Z<br />

(22 F )<br />

(FD transitivity)<br />

X ∪ V ∪ W −→ V ∪ Z<br />

(23 M )<br />

(3 F ,M )<br />

(21 M )<br />

X →→ X ′ ∪ Y |X ′′ ∪ Z<br />

X ∪ X ′ ∪ X ′′ →→ Z |Y<br />

X ∪ V →→ Y |Z , X →→ Y ∪ Z |V<br />

X →→ Y |Z ∪ V<br />

X ∩ Y →→ Y \ X |X \ Y , X −→ Z<br />

X ∩ Y −→ Y ∩ Z<br />

(MVD weakening)<br />

(1 F ), (1 M ), (21 F ), (22 F ), (23 M ), (3 F ,M ) are <strong>co</strong>mplete <strong>and</strong> <strong>co</strong>rrect<br />

for functional <strong>and</strong> multivalued dependencies<br />

(MVD root reduction)<br />

(FD pushback)<br />

Content<br />

Information

Derivation Rules (structurally)<br />

Axiom<br />

Root reduction<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

X ∪ Z<br />

✲<br />

X<br />

Y (X)<br />

✲ X ∪ V ✛ (X)Z Y ∪ Z (X)<br />

✲ X ✛ (X)V<br />

Y (X)<br />

✲<br />

X<br />

✛ (X)Z ∪ V<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

✲<br />

X ′ ∪ Y (X)<br />

Y<br />

(X ∪ X ′<br />

∪X ′′ )<br />

Weakening<br />

✲<br />

X<br />

X<br />

∪X ′<br />

∪X ′′<br />

✛ (X)X ′′ ∪ Z<br />

✛<br />

Z<br />

(X ∪ X ′<br />

∪X ′′ )<br />

Y ∪ Y ′ (X )<br />

❄<br />

X<br />

Tree restructuring<br />

✛ (X )Z ∪ Z ′<br />

✲<br />

Y ∪ Z (X )<br />

(X )Y ′ ∪ Z ′<br />

❄<br />

X<br />

✲ Y (X )<br />

✛ (X )Z ∪ Z ′ ∪ Y ′<br />

X<br />

Content<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Referential Constraints<br />

✞<br />

☎<br />

Generalising foreign key <strong>co</strong>nstraints<br />

✝<br />

✆<br />

Relational underst<strong>and</strong>ing π list(A) (α) ⊆ π list(C ) (β)<br />

(1) table / relation type α with primary key A<br />

either artificial ID or surrogate key or value key<br />

(2) B is a key in β<br />

(3) C can be property based<br />

generalise to view 1,list(A) (α) ⊆ view 2,list(C ) (β)<br />

meaning:<br />

reference as a pointer to already existing data<br />

reference as a binding means<br />

reference with master/slave <strong>and</strong> other proto<strong>co</strong>ls<br />

✞<br />

☎<br />

✝Differentiate introduction <strong>and</strong> reference ✆<br />

Content<br />

Information

Cardinality Constraints are Global<br />

Constraints<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

{ 1 }<br />

Trip<br />

✻<br />

✛<br />

{ 3,4,7 }<br />

<strong>co</strong>rrected: { 3 }<br />

visits<br />

{ 1,2,3,6 } <strong>co</strong>rrected: { 6 }<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

c⃝Sven Hartmann<br />

✲<br />

starts in<br />

{ 2,3,5,6 }<br />

<strong>co</strong>rrected: { 2 }<br />

❄<br />

City<br />

Content<br />

Information

“Remembering the Future”<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Semantics with explicit <strong>co</strong>nsideration of structuring <strong>and</strong> type system variants<br />

(e.g., multivalued dependencies representing structuring <strong>and</strong> de<strong>co</strong>mposition<br />

Combinatorial <strong>co</strong>mplexity for holistic <strong>co</strong>nsideration<br />

(i.e., exponential (‘worst case’))<br />

Ability for expressing <strong>co</strong>nstraints by users<br />

(Too natural <strong>and</strong> not state <strong>co</strong>nstraints; difficult to express <strong>co</strong>nstraints; abstraction; semantics<br />

by different users; everyday life logics, different interpretations (strong, ‘normal’ (logics),<br />

weak))<br />

Computational facilities in systems<br />

(keys, referential integrity <strong>co</strong>nstraints, domain <strong>co</strong>nstraints, implementation (physical <strong>and</strong>/or<br />

logical) <strong>co</strong>nstraints, views, CASE tool biases)<br />

Too simple properties (also for axiomatisation) are misleading<br />

anything in the world has its price we have to pay at the minimum; <strong>co</strong>mplex things will remain to be<br />

<strong>co</strong>mplex<br />

Logical systems are in general <strong>co</strong>mplex<br />

(not decidable or axiomatisable, deriviation <strong>co</strong>mplexity, ...)<br />

Content<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

A<br />

······<br />

✻<br />

The Simplicity of Graphical Reasoning<br />

✲<br />

· · · · · · ·<br />

AB ✲<br />

B<br />

✿<br />

D ✲ E<br />

FD sets equivalent??<br />

ABD<br />

·<br />

C<br />

✲ E<br />

·<br />

·<br />

✒<br />

·<br />

AB ✲ G<br />

·<br />

·<br />

·<br />

H<br />

A<br />

✻<br />

D<br />

✲<br />

❥<br />

✲<br />

CJ ✲ I<br />

B ✲ F C ✲ J<br />

What is a minimal key?<br />

·<br />

·<br />

·<br />

· · · · · · · · · · · · ·<br />

B<br />

C<br />

E<br />

Darwen FD rule<br />

X → Y 0 Y 1 , Y 1 Y 2 → W<br />

XY 2 → Y 0 Y 1 W<br />

X ✲ Y0<br />

··············<br />

···················<br />

Y 0 Y 1 W<br />

<br />

Y1<br />

·<br />

·<br />

XY 2<br />

Y 1 Y 2<br />

✲ W<br />

·<br />

Y 2 ··················<br />

XY 2<br />

✿ Y 0<br />

✲ Y1<br />

3 W<br />

·<br />

Content<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Graphical FD Reasoning<br />

(S)<br />

Y → B<br />

Y → A, YA → B<br />

YC → B<br />

(T )<br />

(P)<br />

YC → B<br />

Y → B<br />

Y → B<br />

(Q)<br />

Y → A, Y → B YA → B, Y → B<br />

(R)<br />

() ¬(Y → B, Y → B)<br />

YA → B<br />

Y → A<br />

✞<br />

☎<br />

Resulting rules for graphical reasoning<br />

✝<br />

✆<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information

The Simplicity of Graphical Reasoning<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

U R = {A, B, D, F , G, I }<br />

σ R = {A −→ IG, D −→ FG, IAB −→ D, IF −→ AG}<br />

✲<br />

✯ G<br />

I ✛<br />

✻<br />

✯ A<br />

I<br />

IF ABI ✲ D<br />

IF<br />

✙<br />

F<br />

✛<br />

✯<br />

A<br />

AB<br />

F<br />

✙<br />

✯<br />

✲<br />

G<br />

✻<br />

D<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Classical synthesis algorithms:<br />

R 1 = ({A, G, I }, {A −→ GI })<br />

R 2 = ({A, F , I }, {A −→ I , FI −→ A})<br />

R 3 = ({A, B, D}, {AB −→ D})<br />

R 4 = ({D, F , G}, {D −→ FG})<br />

This normalisation not minimal<br />

Instead of R 1 take R 1 ′ = ({A, G}, {A −→ G}).<br />

R 2 is not in BCNF. It cannot be split into two relation schemata.<br />

Content<br />

Information

The Simplicity of Graphical Reasoning<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Easy exploration<br />

Is D in any minimal key?<br />

What are the minimal keys?<br />

AB, BC, BE, CF?<br />

Is Date <strong>co</strong>rrect?<br />

Difficult but possible<br />

What are alternative reductions?<br />

Which dependencies are<br />

central?<br />

Content<br />

Information

Another FD Example<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information

Another FD Example<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information

Another FD Example<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

A directly reduced set<br />

Content<br />

Information<br />

Another irreducible set<br />

Derivation of {A, C , D} → {B} as two<br />

step procedure

Graphical FD !!Set!! Reasoning<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Pilot<br />

0..1<br />

Flight<br />

0..1<br />

Flies<br />

card(Flies[Flight,Time],Flight)=[0,1]<br />

Time<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information

FD-Set-Graphs<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Card(...)=[0,1]<br />

...<br />

Pilot<br />

Flight<br />

Flies<br />

Gate<br />

Time<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Additional cardinalities:<br />

card(Flies[Gate,Time,Flight],(Gate,Time))=[0,1]<br />

card(Flies[Gate,Time,Flight],(Flight,Time))=[0,1]<br />

potentially card(Flies[Time,Flight],(Flight))=[0,1]<br />

As FD’s:<br />

{Flight Time → Pilot, Time Pilot → Flight, Flight → Time,<br />

Gate Time → Flight, Flight Time → Gate} ?<br />

Is this set <strong>co</strong>mplete or do we need other <strong>co</strong>nstraints?<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

The Triangular Representation<br />

Trivial or redundant FD’s not represented, eg.:<br />

Flight → Flight, Flight → Flight Time<br />

Flight → Time Pilot ⇐⇒ {Flight → Time, Flight → Pilot}<br />

Example ternary case:<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Initial set of FD’s: filled circles<br />

• Flight Time → Pilot 2D<br />

• Time Pilot → Flight 2D<br />

• Flight → Time 1D<br />

There is a sound <strong>and</strong> <strong>co</strong>mplete axiomatisation!<br />

Content<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Graphical Reasoning for Ternary Cases<br />

Sound <strong>and</strong> <strong>co</strong>mplete implication system: (A ≠ B; A, B /∈ Y )<br />

(S)<br />

Extension:<br />

Y →A<br />

YB→A<br />

(T) Rotation:<br />

Y → A is extended by B<br />

Example ternary case:<br />

Y →A, YA→B<br />

Y →B<br />

Y → A is rotated around Y<br />

supported by YA → B<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Implied set of FD’s: empty circles<br />

⊢ (S) ◦ Flight Pilot → Time<br />

⊢ (T ) ◦ Flight → Pilot<br />

Content<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

In<strong>co</strong>rporating Negated Dependencies<br />

Sound <strong>and</strong> <strong>co</strong>mplete implication system: (S), (T) +<br />

(P)<br />

YB→A<br />

Y →A<br />

(Q)<br />

Y →B, Y →A<br />

YA→B<br />

(R)<br />

Y →B, YA→B<br />

Y →A<br />

Reduction Extension Rotation<br />

Example ternary case:<br />

• Flight Time → Pilot<br />

• Time Pilot → Flight<br />

• Flight → Time<br />

•× Time → Pilot<br />

⊢ (S) ◦ Flight Pilot → Time<br />

⊢ (T ) ◦ Flight → Pilot<br />

⊢ (R) ◦× Time → Flight<br />

Content<br />

Information

Graphical Reasoning for Ternary Cases<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Example ternary case:<br />

The closed set:<br />

• Flight Time → Pilot<br />

• Time Pilot → Flight<br />

• Flight → Time<br />

◦ Flight Pilot → Time<br />

◦ Flight → Pilot<br />

The result is one of the 14 different ternary cases<br />

(schema / <strong>relationship</strong> types).<br />

What about raising the number of attributes?<br />

Content<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

The Tetrahedral Representation<br />

A quaternary case has ( 4<br />

3)<br />

= 4 nested ternary cases<br />

forming the surface of a tetrahedron.<br />

Edges <strong>co</strong>rrespond to the ( 4<br />

2)<br />

= 6 nested binary cases, each shared<br />

between two triangles.<br />

The initial set:<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

• Flight Time → Pilot<br />

• Time Pilot → Flight<br />

• Flight → Time<br />

• Gate Time → Flight<br />

• Flight Time → Gate<br />

Content<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

The Quadratic Representation<br />

Ternary case - triangle 2D<br />

Quaternary case - square 2D<br />

Example <strong>co</strong>mplete case:<br />

The initial set:<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Key features: ’points towards’, ’parallel’<br />

• Flight Time → Pilot<br />

• Time Pilot → Flight<br />

• Flight → Time<br />

• Gate Time → Flight<br />

• Flight Time → Gate<br />

Content<br />

Information

Graphical Reasoning by the ST Algorithm<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Example (full):<br />

FD’s with minimal left sides:<br />

• Flight → Time<br />

◦ Flight → Pilot<br />

◦ Time Gate → Pilot<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

◦ Flight → Gate<br />

◦ Time Pilot → Gate<br />

• Time Pilot → Flight<br />

• Gate Time → Flight<br />

The result is one of the 165 different quaternary cases<br />

(schema / <strong>relationship</strong> types).<br />

Content<br />

Information

The Pentagonal Representation<br />

A quinary case has ( 5<br />

4)<br />

= 4 nested quaternary,<br />

( 5<br />

) (<br />

3 = 10 nested ternary <strong>and</strong> 5<br />

)<br />

2 = 10 nested binary cases.<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information<br />

Key features: ’points towards’, ’parallel’<br />

Derivation by extension:<br />

• C → A<br />

◦ BC → A<br />

◦ CD → A<br />

◦ CE → A<br />

◦ BCD → A<br />

◦ CDE → A<br />

◦ BCE → A<br />

◦ BCDE → A

Hexagonal Representation<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information

Feasibility ???<br />

✞<br />

✝The number of closed sets<br />

☎<br />

✆<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

#Attrs #Sets #Cases #Sets* #Cases*<br />

1 1 1 2 2<br />

2 4 3 7 5<br />

3 45 14 61 19<br />

4 2 271 165 2 480 184<br />

5 1 373 701 14 480 1 385 552 14 664<br />

6 75 965 474 236 ? 75 973 751 474 ?<br />

... ? ? ? ?<br />

Two sets belong to the same case (<strong>relationship</strong>/schema type) if<br />

they differ only in the <strong>order</strong> of attributes.<br />

* means zero-dimensional FD’s are allowed (eg. ∅ → Pilot).<br />

Content<br />

Information

Foundations of BPMN Semantics<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Operational semantics by reduction rules for execution of the <strong>language</strong><br />

opportunity: <strong>co</strong>nstructing an interpreter<br />

☼<br />

Axiomatic semantics by <strong>co</strong>rrectness assertions that describe how<br />

to draw <strong>co</strong>nclusions about the input/output interface of a program<br />

opportunity: verifying a program<br />

☹<br />

Denotational semantics by a valuation function that maps a program<br />

into a mathematical object which is <strong>co</strong>nsidered as its meaning<br />

opportunity: reasoning about its properties<br />

w<br />

Transformational semantics based on mappings <strong>and</strong> semantics of<br />

the target machine<br />

requires thorough knowledge<br />

E<br />

on mappings, their dependencies <strong>and</strong> interactions, <strong>and</strong><br />

on target machine<br />

Information

Yet an Example of a Workflow Diagram<br />

✞<br />

☎<br />

A BPMN diagram taken from literature with many problems<br />

✝<br />

✆<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information

Why not Petri Nets?<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information

BPMN gateway<br />

Why not Petri Nets?<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information

Why not Petri Nets?<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information

The Pisa-Kiel BPMN-ASM Project<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

ASM semantics: extensible semantical framework for business process<br />

<strong>modelling</strong> notations<br />

Guiding underst<strong>and</strong>ing of BPMN <strong>co</strong>nstructs based on ASM<br />

Proposals for<br />

improvement of BPMN<br />

rigid semantics of all BPMN <strong>co</strong>ncepts<br />

treatment of all underspecified, overspecified, ... <strong>co</strong>ncepts<br />

Systematic framework based on separate behavior from scheduling<br />

issues<br />

Description of behavior directly in business process terms<br />

Case study for <strong>co</strong>mplex business processes<br />

e.g., <strong>co</strong>nference paper submission <strong>and</strong> reviewing system,<br />

<strong>co</strong>nference management<br />

(muComs ∪ BYU ⊇ EasyChair ∪ ....)<br />

Information

Specifics of the ASM Approach<br />

State model based on static <strong>and</strong> dynamic functions<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

basic<br />

function/relation/location<br />

derived<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

static<br />

non-updatable<br />

by any agent<br />

<strong>co</strong>ntrolled shared<br />

in (monitored)<br />

non-updatable<br />

by agent<br />

<strong>co</strong>ntrolled<br />

updatable<br />

by agent<br />

dynamic<br />

shared (interaction)<br />

updatable<br />

by agent<br />

out<br />

updatable<br />

by agent<br />

All rules fire in parallel if they are enabled<br />

parallel <strong>and</strong> <strong>co</strong>ntinuous execution<br />

indirectly<br />

monitored<br />

indirectly<br />

<strong>co</strong>ntrolled<br />

indirectly<br />

shared<br />

Conflicting updates are resolved by disabling some of rules that<br />

can be fired<br />

Locations as an abstraction of storage<br />

Turing/Church hypothesis with scaling abstraction<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information<br />

Fireable workflow transition<br />

at node for its execution:<br />

WorkflowTransitionInterpreter =<br />

let node = select Node ({n | n ∈ Node <strong>and</strong> Enabled(n)})<br />

let rule = select WorkflowTransition ({r |<br />

r ∈ WorkflowTransition <strong>and</strong> Fireable(r, node)})<br />

rule<br />

✞<br />

☎<br />

Separation of behaviour from scheduling<br />

✝<br />

✆<br />

✞<br />

☎<br />

✝Execution of all firable instance nodes ✆<br />

WorkflowTransition(node) =<br />

if EventCond(node) <strong>and</strong> CtlCond(node)<br />

<strong>and</strong> DataCond(node) <strong>and</strong> ResourceCond(node) then<br />

DataOp(node)<br />

CtlOp(node)<br />

EventOp(node)<br />

ResourceOp(node)

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

AND-Split Gateway (Fork)<br />

in : ✲t<br />

CtlCond<br />

If (Data|Event)Cond .<br />

❄<br />

Consume<br />

+<br />

AssignOp<br />

Produce<br />

All<br />

. . .<br />

✲<br />

: ✲t j<br />

out j<br />

OutCond j<br />

. . .<br />

✲<br />

AndSplitGateTransition(node) = WorkflowTransition(node)<br />

where<br />

CtlCond(node) = Enabled(in)<br />

CtlOp(node) =<br />

let t = firingToken(in)<br />

Consume(t, in)<br />

ProduceAll({(<strong>and</strong>SplitToken(t, o), o) | o ∈ outArc(node)})<br />

DataOp(node) = //performed for each selected gate<br />

forall o ∈ outArc(node) forall i ∈<br />

assignments(o) Assign(to i , from i )<br />

✞<br />

Separation of rule schemes from <strong>co</strong>ncrete rules<br />

✝<br />

☎<br />

✆<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

✞<br />

AND-Join Gateway<br />

. . .<br />

Consume<br />

All<br />

.<br />

If (Data|Event)Cond<br />

✲<br />

in i : t i<br />

CtlCond i<br />

. . .<br />

✲❄<br />

+<br />

AssignOp<br />

✲<br />

Produce<br />

out : ✲t<br />

OutCond<br />

AndJoinGateTransition(node) = WorkflowTransition(node)<br />

where<br />

CtlCond(node) = forall in ∈ inArc(node) Enabled(in)<br />

CtlOp(node) =<br />

let [in 1 , . . . , in n ] = inArc(node)<br />

let [t 1 , . . . , t n ] = firingToken(inArc(node))<br />

ConsumeAll({(t j , in j )) | 1 ≤ j ≤ n})<br />

Produce(<strong>and</strong>JoinToken({t 1 , . . . , t n }), out)<br />

DataOp(node) = forall i ∈ assignments(out) Assign(to i , from i )<br />

Be careful: BPMN assumes strict local <strong>co</strong>nsideration!<br />

✝<br />

☎<br />

✆<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information<br />

The Token Problem in the BPMN<br />

St<strong>and</strong>ard<br />

For each un<strong>co</strong>ntrolled Sequence Flow a “Token” will flow from the source object to the target object.<br />

To facilitate this discussion, we will employ the <strong>co</strong>ncept of a “Token” that will traverse the Sequence<br />

Flow <strong>and</strong> pass through the Flow Objects in the Process. The behavior of the Process can be described<br />

by tracking the path(s) of the Token through the Process. A Token will have a unique id<strong>entity</strong>, called a<br />

TokenId set, that can be used to distinguish multiple Tokens that may exist because of <strong>co</strong>ncurrent Process<br />

instances or the dividing of the Token for parallel processing within a single Process instance. The parallel<br />

dividing of a Token creates a lower level of the TokenId set. The set of all levels of TokenId will identify a<br />

Token. A Start Event generates a Token that must eventually be <strong>co</strong>nsumed at an End Event (which may<br />

be implicit if not graphically displayed). The path of Tokens should be traceable through the network of<br />

Sequence Flow, Gateways, <strong>and</strong> activities within a Process.<br />

If an upstream Inclusive OR produces two out of a possible three Tokens, then a downstream Inclusive OR<br />

will synchronize those two Tokens <strong>and</strong> not wait for another Token, even though there are three in<strong>co</strong>ming<br />

Sequence Flow (see Figure 9.25).<br />

Email from a <strong>co</strong>lleague: The most interesting <strong>and</strong>, in my opinion, advanced paper on that<br />

is the paper of Frank Pullman <strong>and</strong> Matthias Weske from BPM’2005 where the authors used<br />

lambda calculi to derive workflow pattern semantics. The only problem they had then was<br />

related to OR-JOIN operator (gateway) while it was not possible to express memory of<br />

the generated tokens.<br />

Comparing to what you propose I see that Pullman <strong>and</strong> Weske had problem with defining<br />

semantics of tokens <strong>and</strong> this was crucial for the overall workflow patterns semantics.<br />

Therefore I would expect that you in a clear <strong>and</strong> unambiguous way define semantics of<br />

tokens <strong>and</strong> that, in my opinion, would be a real step forward in defining semantics of<br />

BPMN.

The Token Problem: Acyclic Case<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information<br />

The BPMN St<strong>and</strong>ard 1.0: All the Tokens that were generated within the Process must be <strong>co</strong>nsumed<br />

by an End Event before the Process has been <strong>co</strong>mpleted.<br />

The Process will be in a running state until all Tokens are <strong>co</strong>nsumed.<br />

When the Inclusive Gateway is used as a Merge, it will wait for (synchronize) all Tokens that have been<br />

produced upstream. It does not require that all in<strong>co</strong>ming Sequence Flow produce a Token (as the Parallel<br />

Gateway does). It requires that all Sequence Flow that were actually produced by an upstream (by an<br />

Inclusive OR situation, for example). If an upstream Inclusive OR produces two out of a possible three<br />

Tokens, then a downstream Inclusive OR will synchronize those two Tokens <strong>and</strong> not wait for another<br />

Token, even though there are three in<strong>co</strong>ming Sequence Flow (see Figure 9.25).

The Token Problem: Cyclic Case<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

✞<br />

Be careful: Underspecified, <strong>co</strong>nfusing <strong>and</strong> difficult<br />

✝<br />

The BPMN St<strong>and</strong>ard 1.0: In<strong>co</strong>ming Sequence Flow that have a source<br />

that is a downstream activity (that is, is part of a loop) will be treated<br />

differently than those that have an upstream source.<br />

☎<br />

✆<br />

Content<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Our solution<br />

Controller structures based on the <strong>co</strong>ncept of the program <strong>co</strong>unter<br />

new(token) of process instance, derivable owner<br />

token at location of <strong>co</strong>ntrol flow, i.e. arc<br />

multiset of token at location<br />

returnProcess(token)<br />

frames of execution h<strong>and</strong>ling:<br />

• (ASM BPMN) rule<br />

• <strong>co</strong>nsumed token,<br />

• produced token,<br />

• <strong>co</strong>nditions applicable,<br />

• methods applied,<br />

• locals<br />

invoke or scheduler frames<br />

supporting infrastructure for retransmission of potential enactment<br />

Content<br />

Information

Alternative Token Model<br />

✞<br />

☎<br />

Token with clan memory<br />

✝<br />

✆<br />

start token T of process instance<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Or T.1.1<br />

And T.1<br />

Or T.1.2<br />

And T.2 And T.3<br />

Xor T.2<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Multi T.1.1. 1 Multi T.1.1. 2 Multi T.1.1. 3 Multi T.1.1. 4<br />

And T.2.1 And T.2.2<br />

each token has <strong>co</strong>mplete knowledge on its siblings <strong>and</strong> parents<br />

splits generate new children<br />

joins return parent of <strong>co</strong>mplete join otherwise more <strong>co</strong>mplex model<br />

special model for structures of splits <strong>and</strong> joins that do not have an<br />

equivalent Fitch structure<br />

Content<br />

Information

Control Flow Models<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Implicit (defined by the <strong>language</strong>) or explicit (e.g. goto) <strong>co</strong>ntrol: based on<br />

structuring (<strong>and</strong> the <strong>co</strong>rresponding <strong>co</strong>mpositional semantics), exchange<br />

interfaces (statements, messages, data, events) <strong>and</strong> subroutines<br />

Control of subroutines: call/return structures, recursive?, call rules, <strong>co</strong>mpletion<br />

of subroutines, eager/lazy execution, transfer of <strong>co</strong>ntrol, uniqueness<br />

of <strong>co</strong>ntrol, current instruction <strong>and</strong> environment pointer (CIP, CEP);<br />

implicit data <strong>co</strong>ntrol by indirect transfer, binding, naming, association<br />

<strong>and</strong> reference environments, aliases, sharing <strong>co</strong>nceptions; static/dynamic<br />

visibility <strong>and</strong> lifespan <strong>co</strong>nceptions; block structures ... TA’s;<br />

local variables <strong>and</strong> environments, parameters, stack/heap support structures<br />

shared/monitored/<strong>co</strong>ntrolled/out parameters, (direct) call by name/reference/value/result/value<br />

result/<strong>co</strong>nstant value<br />

Control of <strong>co</strong>llaboration cases: only by orchestration<br />

<strong>co</strong>ntrol flow on parallelism: <strong>co</strong>ntrol dependence analysis, executing multiple<br />

flows of <strong>co</strong>ntrol simultaneously, <strong>and</strong> speculative execution<br />

Content<br />

Information

Normal Forms<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Splits only at the gates<br />

Entry <strong>and</strong> leave for a process only at start <strong>and</strong> end events<br />

Activities can be separated into<br />

Activity = Task ∪ SubProcess ∪ IterProc<br />

IterProc = Loop ∪ MultiInstance ∪ AdHoc<br />

St<strong>and</strong>ard looping only<br />

Tracking of token<br />

catch environment for local <strong>co</strong>ntrol token<br />

Prenex normal form<br />

also for ad-hoc processes<br />

Communication normal form: explicit <strong>co</strong>mmunication only by links<br />

<strong>and</strong> messages<br />

Exception normal form (????)<br />

Content<br />

Information

ASM BPMN Assumptions<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Token are assigned to arcs in the process diagrams<br />

token : Arc → Multiset(Token)<br />

token are identifiable<br />

Execution of workflow steps is reflected at nodes<br />

Enabled(in, t) = (| token(in, t) |≥ qty(in, t))<br />

token enabled execution<br />

Support <strong>and</strong> auxiliary functions<br />

Consume(t, in) = Delete(t, inQty(in), token(in))<br />

Produce(t, out) = Insert(t, outQty(out), token(out))<br />

ConsumeAll(X ) = forall x ∈ X Consume(x)<br />

ProduceAll(Y ) = forall y ∈ Y Produce(y)<br />

Context-sensitive dynamic functions<br />

Content<br />

Information

ASM Rules<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

ProduceSync(t, in) = Insert(t, syncToken(in))<br />

ConsumeSync(t, in) = Delete(t, syncToken(in))<br />

ProduceSyncAll(Y ) = forall y ∈ Y ProduceSync(y)<br />

ConsumeSyncAll(X ) = forall x ∈ X ConsumeSync(x)<br />

Split gate transition rules<br />

ProduceSyncAll({(t.o, i) | i ∈ AllJoinArc(o), o ∈ O})<br />

ConsumeSyncAll({(t, i) | i ∈ AllJoinArc(o) forsome o ∈ O})<br />

Join gate transition rules<br />

ProduceSyncAll({(joinToken(t 1 , . . . , t n ), in) | in ∈ AllJoinArc(out)})<br />

ConsumeSyncAll({(t i , in) | in ∈ AllJoinArc(out)})<br />

Synchronization <strong>co</strong>unterpart<br />

CtlCondSync(node, I ) =<br />

forall i ∈ I syncToken(i) ≠ ∅ <strong>and</strong><br />

forall i ∈ inArc(node) \ I syncToken(i) = ∅<br />

Content<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Separation of Concern<br />

✞<br />

☎<br />

The Concern Space of BPMN: Control space, abstraction, dimensions, user<br />

✝<br />

✆<br />

“Concern space” of systems: what <strong>co</strong>ncerns are present, how<br />

they relate, <strong>and</strong> how they can be used for modularization.<br />

http://researchweb.watson.ibm.<strong>co</strong>m/hyperspace/ConcernSpaces.htm<br />

Encapsulation of all kinds of <strong>co</strong>ncerns in a<br />

software system, simultaneously.<br />

Overlapping <strong>and</strong> interacting <strong>co</strong>ncerns.<br />

On-dem<strong>and</strong> remodularization.<br />

Multiple, arbitrary kinds (dimensions) of<br />

<strong>co</strong>ncerns.<br />

Separation ac<strong>co</strong>rding to these <strong>co</strong>ncerns simultaneously.<br />

Overlapping or interacting <strong>co</strong>ncerns.<br />

Connection of <strong>co</strong>ncerns.<br />

Content<br />

Information

The Concern Space of BPMN<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Separation of behavior from scheduling based on explicit<br />

schedulers<br />

Separation of orthogonal <strong>co</strong>nstructs beyond of what BPMN<br />

envisioned<br />

TaskType = {Service, User, Receive, Send, Script, Manual, Reference, None}<br />

Separation of different model dimensions like <strong>co</strong>ntrol, events,<br />

data <strong>and</strong> resources<br />

Separation of <strong>design</strong>, experimental validation <strong>and</strong> mathematical<br />

verification<br />

see <strong>co</strong>ming demo<br />

Content<br />

Information

The Concern Space of BPMN<br />

Separation of rule schemes <strong>and</strong> <strong>co</strong>ncrete rules e.g. by generalising<br />

rule schemes to generic ones or patterns<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

GateTransitionPattern(node) =<br />

let I = select Consume (node)<br />

let O = select Produce (node) in<br />

WorkflowTransition(node, I , O)<br />

where<br />

CtlCond(node, I ) = (I ≠ ∅ <strong>and</strong> forall in ∈ I Enabled(in))<br />

CtlOp(node, I , O) =<br />

ProduceAll({(patternToken(firingToken(I ), o), o) | o ∈ O})<br />

ConsumeAll({(t i , in i ) | 1 ≤ i ≤ n}) where<br />

[t 1 , . . . , t n ] = firingToken(I )<br />

[in 1 , . . . , in n ] = I<br />

AssignOp(node, O) = forall o ∈ O forall a ∈<br />

assignments(o) Assign(to a , from a )<br />

Separation of responsibilities, rights <strong>and</strong> roles of users<br />

Content<br />

Information

Illustration of the Separation Principles:<br />

OR-Gateways<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Separation of send-<strong>co</strong>llect for OR-gates as either global <strong>co</strong>nception<br />

or (better) local subscribing OR-joins of runtime behaviour of<br />

publishing OR-splits<br />

Clustering of cycles as a good practice<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Tokenisation of cycle <strong>co</strong>unters through Tokensets as a facility<br />

to model associated token<br />

separation of pathes ac<strong>co</strong>rding to their effect<br />

Completion of semantics for meaning of synchronisation, cycles<br />

as a graph extension with specific stratification or encapsulation<br />

structures<br />

Content<br />

Information

Results for Token Problems<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information

Fitch Structures for Acyclic Diagram<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Separation of send-<strong>co</strong>llect for OR-gates as either global<br />

<strong>co</strong>nception or (better) local subscribing OR-joins of runtime<br />

behaviour of publishing OR-splits<br />

Content<br />

Information

Fitch Structures for Cyclic Diagram<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

The ‘vicious cycle’ example: explicit treatment of cycles,<br />

tokensets as an association tool, encapsulation of cycle pathes,<br />

separation of send-<strong>co</strong>llect synchronisation from cycle<br />

synchronisation<br />

Content<br />

Information

The Token Problem: Cyclic Case<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

The BPMN St<strong>and</strong>ard 1.0: In<strong>co</strong>ming Sequence Flow that have a source that is a<br />

downstream activity (that is, is part of a loop) will be treated differently than those<br />

that have an upstream source.<br />

Content<br />

Information

The Token Problem: Vicious Cycle<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

The BPMN St<strong>and</strong>ard 1.0: In<strong>co</strong>ming Sequence Flow that have a source that is a<br />

downstream activity (that is, is part of a loop) will be treated differently than those<br />

that have an upstream source.<br />

Information

Lessons for Cyclic Diagrams<br />

✞<br />

☎<br />

Level of support depends on diagram<br />

✝<br />

✆<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Acyclic diagrams without OR-splits <strong>and</strong> joins: local execution<br />

with local rules<br />

Acyclic diagrams with OR-splits <strong>and</strong> joins: local<br />

with send-<strong>co</strong>llect information enrichment at join nodes<br />

execution<br />

Cyclic diagrams with XOR-entry/leave: separation of inside<br />

cycle flow <strong>and</strong> outside cycle flow<br />

Stratified cyclic diagrams with OR/AND-entry/leave:<br />

explicit extension of diagrams <strong>and</strong> <strong>co</strong>mpletion of underspecified<br />

semantics<br />

Non-stratified cyclic diagrams led to many problems, e.g., deadlocks<br />

Content<br />

Information

Orthogonal Concerns<br />

✞<br />

Co-<strong>design</strong>, <strong>co</strong>existence <strong>and</strong> <strong>co</strong>-evolution of specifications<br />

✝<br />

☎<br />

✆<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Database support: <strong>co</strong>mputation in <strong>co</strong>llaboration, shared resources,<br />

modification-in-place ∨ -in-private<br />

Transactional systems: short-term, long-term, <strong>co</strong>llaboration transactions<br />

Security: integrity, availability, <strong>co</strong>nfidentiality<br />

also privacy<br />

History: runtime, log, revival (re<strong>co</strong>very, restart, session),<br />

Context: <strong>co</strong>ncurrency, infrastructure, architecture,<br />

QoS, SLA: quality of use, external/internal quality<br />

Collaboration: <strong>co</strong>mmunication, <strong>co</strong>operation, <strong>co</strong>ordination<br />

or simply orchestration, syndication<br />

Actors, users: shared usage beyond message exchange<br />

Information

Model Evolution as the Real Challenge<br />

already evolution of one model is a challenge<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

models change over time<br />

<strong>co</strong>-evolution be<strong>co</strong>mes a nightmare if not planned in advance<br />

dynamic adaptation is another challenge<br />

Content<br />

Information

Variety of UML-“<strong>language</strong>s”<br />

Main UML Diagrams<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Class<br />

Diagram<br />

Object<br />

Diagram<br />

Package<br />

Diagram<br />

Structure<br />

Diagram<br />

Deployment<br />

Diagram<br />

Component<br />

Diagram<br />

Composite<br />

Structure<br />

Diagram<br />

Behavioral<br />

Diagrams<br />

Superstructure<br />

Metamodel<br />

Diagram<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Sequence<br />

Diagram<br />

Use Case<br />

Diagram<br />

Behavioral Diagrams<br />

Interaction<br />

Diagrams<br />

Activity<br />

Diagram<br />

Interaction Diagrams<br />

Communication<br />

Diagram<br />

Timing<br />

Diagram<br />

State<br />

Machine<br />

Diagram<br />

Interaction Overview<br />

Diagram<br />

Content<br />

Information

Coherence of UML Diagram Clusters<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information<br />

inherent integrity <strong>co</strong>nstraints in diagrams<br />

StateChart({IsBorrowed, IsReturned}) ⊆ ClassDiagram(π LendingState (Book))<br />

states(SC ,CT )<br />

EC1 : StateChart(States) ⊆ ClassDiagram(π X (RulingClass))<br />

State ′ ∉ ClassDiagram(π X (RulingClass)) −→ F modify(StateChart(State, State ′ ))<br />

O cascade(modify(ClassDiagram(RulingClass, X )), modify(StateChart(State)))<br />

do(Agent 1 , modify(ClassDiagram(RulingClass, X ))) <br />

do(notify(Agent 2 , modify(ClassDiagram(RulingClass, X ))))

Challenges in Multi-Model Environments<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Explicit specification of model <strong>co</strong>llaboration: interdependencies<br />

among models<br />

Integrated development of different models: different views of the<br />

same problem or application<br />

Co-evolution of models: exchange between models <strong>and</strong> change propagation<br />

Combining different (e.g., graphical) representations with mathematical<br />

rigor of models<br />

Evolution of different representations: refinements of previous models<br />

or explicit revisions of models<br />

Management of multi-model IS development: scheduling mechanisms,<br />

rollback<br />

Version h<strong>and</strong>ling for multi-model IS development: different versions<br />

Explicit refinement <strong>and</strong> abstraction treatment: systems development<br />

abstraction layers<br />

Information

Model Suites<br />

✞<br />

as a part of ISE@CAU model integration theory<br />

✝<br />

☎<br />

✆<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Model structure based on model <strong>co</strong>nstructors starting from model<br />

kernels <strong>and</strong> model orchestration <strong>and</strong> model choreographies<br />

<strong>co</strong>nstraints <strong>and</strong> structural soundness<br />

<strong>co</strong>nstraint enforcement<br />

Model repository for <strong>co</strong>existence of models based on the <strong>co</strong>llaboration<br />

pattern <strong>and</strong> style<br />

model <strong>co</strong>mmunication generalising model proto<strong>co</strong>ls<br />

model <strong>co</strong>ordination generalising model <strong>co</strong>ntracts<br />

model <strong>co</strong>operation generalising model evolution<br />

Model metadata as the basis for model quality management<br />

Model evolution<br />

Content<br />

Information

Model Suite: Constituents<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

set of models {M 1 , ...., M n } ,<br />

association or <strong>co</strong>llaboration schema among the models,<br />

<strong>co</strong>ntrollers that maintain <strong>co</strong>nsistency or <strong>co</strong>herence of the model<br />

suite,<br />

application schemata for explicit maintenance <strong>and</strong> evolution of the<br />

model suite, <strong>and</strong><br />

tracers for the establishment of the <strong>co</strong>herence.<br />

Coherence describes a fixed <strong>relationship</strong> between the models in a model<br />

suite.<br />

✞<br />

☎<br />

only inductive <strong>language</strong>s with <strong>co</strong>mpositionality principle<br />

✝<br />

✆<br />

✞<br />

☎<br />

✝<strong>co</strong>ncentration on discrete domains ✆<br />

Content<br />

Information

Model Suite: Languages<br />

Model <strong>language</strong> L: signature S <strong>and</strong> a set of <strong>co</strong>nstructors C<br />

Σ S,C well-formedness <strong>co</strong>nditions<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Model type T LS = (L S , Σ LS )<br />

<strong>language</strong> of the model <strong>and</strong><br />

<strong>co</strong>nstraints Σ LS ∈ L(Σ WellFormed<br />

S )<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Partial mappings R i,j : L Si → L Sj among L S1 , ...L Sn<br />

Model M: struct M in L S<br />

that obeys Σ LS ,<br />

<strong>and</strong> set of <strong>co</strong>nstraints Σ M defined in the logics of this <strong>language</strong>.<br />

Content<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Model Suite: Model Association <strong>and</strong><br />

Contracting<br />

Collaboration <strong>co</strong>ntract among models<br />

Collaboration<br />

Communication is used in a variety of facets as an act or instance<br />

of transmitting or a process by which information is exchanged<br />

between models through a <strong>co</strong>mmon system.<br />

Coordination expresses the act or action of <strong>co</strong>ordinating the harmonious<br />

functioning of models for effective results.<br />

Cooperation expresses the action of <strong>co</strong>operating.<br />

Collaboration style: supporting programs, data access pattern, style<br />

of <strong>co</strong>llaboration, <strong>co</strong>ordination workflows<br />

Collaboration pattern: supporting access <strong>and</strong> <strong>co</strong>nfiguration, event<br />

processing, synchronization, <strong>and</strong> parallel execution<br />

Content<br />

Information

Model Suite<br />

Model suite type ST = (T LS1 , ..., T LS n , Σ L S1 ,...,L S n )<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

model types T LS1 ... T defined on a set Σ LS n S 1 ,...,S n<br />

of<br />

L S1 , ..., L Sn <strong>co</strong>nstraints<br />

Model suite S<br />

on a model suite type ST<br />

models (M 1 , ..., M n ) of type T LS1 ... T LS n<br />

that obey Σ LS1 ,...,L S n<br />

Contract on C:<br />

<strong>co</strong>nstraints Σ LS1 ∪ ... ∪ Σ LS n ∪ Σ L S1 ,...,L S n ,<br />

description of the enforcement mechanisms for any operation that<br />

can be used for modification of one model, <strong>and</strong><br />

set of <strong>co</strong>nsistent evolution transformations.<br />

Content<br />

Information

Model Suite: Synchronisation <strong>and</strong><br />

Coherence<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

extract e i,j<br />

✲<br />

transform t i,j<br />

✲ load l i,j<br />

✲<br />

M i M i,j ,outp M j ,i,inp M j<br />

Commuting diagrams <strong>and</strong> <strong>co</strong>-evolution<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

M i<br />

put ∗ i,j<br />

✲<br />

M j<br />

✛<br />

put<br />

M i ′<br />

j ∗ ,i<br />

M j<br />

′<br />

M i<br />

change j<br />

❄<br />

M ′<br />

change i<br />

❄<br />

put ∗ i,j<br />

<br />

✲<br />

change j<br />

M j<br />

❄<br />

✛<br />

putj ∗ ,i<br />

i M j<br />

′<br />

Content<br />

Information

Model Suite: Co-evolution<br />

Information system model<br />

M IS<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Database structure<br />

model<br />

M struct<br />

Database<br />

schema<br />

M funct<br />

✛<br />

Static<br />

integrity<br />

<strong>co</strong>nstraints<br />

put ∗ struct,funct<br />

Database function<br />

model<br />

M func<br />

Database<br />

functionality<br />

model<br />

M struct<br />

M ′ struct<br />

change funct<br />

❄<br />

put ∗<br />

M ′ funct,struct✲<br />

funct M ′′<br />

struct<br />

Dynamic<br />

integrity<br />

<strong>co</strong>nstraints<br />

put ∗ struct,<strong>co</strong>ntent<br />

put ∗ <strong>co</strong>ntent,struct<br />

✛<br />

✲<br />

change <strong>co</strong>ntent<br />

put ∗ struct,<strong>co</strong>ntent✲<br />

Database support models<br />

Content<br />

model<br />

M <strong>co</strong>ntent<br />

M <strong>co</strong>ntent<br />

❄<br />

M ′ <strong>co</strong>ntent<br />

M ′′<br />

<strong>co</strong>ntent<br />

Interaction<br />

model<br />

M interact<br />

... model<br />

put ∗ <strong>co</strong>ntent,interact✲<br />

put ∗ <strong>co</strong>ntent,interact✲<br />

put ∗ <strong>co</strong>ntent,interact✲<br />

M interact<br />

M ′ interact<br />

M ′′<br />

interact<br />

Content<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Triggers: One of the Hereditary Diseases<br />

✞<br />

☎<br />

✝Issues That Are Still Unsolved ✆<br />

Trigger defined through term rewriting systems<br />

<strong>co</strong>nfluence<br />

termination<br />

effect preservation<br />

unfortunately only for strongly hierarchical systems (KDS/β).<br />

Execution semantics for trigger set needed<br />

Be careful: changes with DBMS<br />

C 1 ⊆ C 2 , C 1 ⊆ C 3 , C 2 ∥C 3<br />

insert C1 → ∗ delete C3 delete C2 delete C1<br />

insert C1 → ∗ insert C3 delete C2 delete C1<br />

insert C1 → ∗ insert C2 delete C3 delete C1<br />

Greatest <strong>co</strong>nsistent specialisation (KDS/β)<br />

Information

Rule triggering is nice but<br />

Rule Triggering May Fail<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

termination problem<br />

<strong>co</strong>nfluence property (Church-Rosser)<br />

<strong>and</strong> it may fail:<br />

Consider a simplistic example: three classes A, B, C<br />

integrity <strong>co</strong>nstraints: A ⊆ B, A ⊆ C (inclusion <strong>co</strong>nstraints)<br />

B||C (exclusion <strong>co</strong>nstraint)<br />

rule triggering system: i A (x) i A (x); i B (x), i A (x) i A (x); i C (x),<br />

d B (x) d B (x); d A (x), d C (x) d C (x); d A (x)<br />

i B (x) i B (x); d C (x), i C (x) i C (x); d B (x)<br />

general <strong>co</strong>mpression rules: i T (x); d T (x) d T (x) , d T (x); i T (x) i T (x)<br />

applying this ECA set to the operation i A (x) allows to derive either<br />

i C (x); d B (x); d A (x) or<br />

or i B (x); d C (x); d A (x) or d B (x); d C (x); d A (x)<br />

Therefore: be careful during <strong>design</strong> of <strong>co</strong>nstraints <strong>and</strong> structures!<br />

GCS result: FAIL<br />

Content<br />

Information

Can The Designer Repair ECA Faults?<br />

R 1 = (A :: INT , C :: INT )<br />

R 2 = (B :: INT , D :: INT )<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

I 1 ≡ R 1 [A] ⊆ R 2 [B] (inclusion dependency)<br />

I 2 ≡ R 2 : D → B (functional dependency)<br />

I 3 ≡ R 1 [C ] ∥ R 2 [D] (exclusion dependency)<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

r 1 = ON insert R1 (a, c)<br />

IF a /∈ R 2 [B] THEN insert R2 (a, ?)<br />

r 2 = ON delete R2 (b, d)<br />

IF b ∈ R 1 [A] ∧ b /∈ R 2 [B] THEN delete R1 (b, ?)<br />

r 3 = ON insert R2 (b, d)<br />

IF (b ′ , d) ∈ R 2 ∧ b ′ ≠ b THEN fail<br />

r 4 = ON insert R1 (a, c)<br />

IF c ∈ R 2 [D] THEN delete R2 (?, c)<br />

r 5 = ON insert R2 (b, d)<br />

IF d ∈ R 1 [C ] THEN delete R1 (?, d)<br />

Content<br />

Information<br />

insert R1 (a, c) AFTER INSERT a ∉ R 1 [A]<br />

AFTER INSERT c ∉ R 2 [D]

Loving or Hating ECA ?<br />

Size of triggers: Triggers tend to be<strong>co</strong>me large, in<strong>co</strong>mprehensible, resist maintenance <strong>and</strong><br />

cause the trigger crisis<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Rule triggering is safe iff the structuring (structure <strong>and</strong> static integrity <strong>co</strong>nstraints) is<br />

strictly hierarchical (stratifiable)<br />

this property is undecidable<br />

Effect preservation of rule triggering systems is undecidable<br />

Insert operation: Ins(db,set) ⊒ db<br />

Delete operation: Del(db,set) ⊑ db<br />

Practical advice of DBMS: Whenever a problem occurs, disable rule triggering<br />

Sybase: at most one trigger per event <strong>and</strong> per relation<br />

The sad example: LAUBAG lost their data in 1996<br />

All execution models fail: For each execution model <strong>and</strong> a <strong>co</strong>rrectness <strong>co</strong>ndition<br />

a set of types <strong>and</strong> a set of <strong>co</strong>nstraints exists<br />

such that the ECA enforcement does not<br />

satisfy the <strong>co</strong>rrectness <strong>co</strong>ndition<br />

Therefore: either use GCS or be careful during <strong>design</strong> of <strong>co</strong>nstraints <strong>and</strong> structures!<br />

Content<br />

Information

Integrity Enforcement via GCS instead of<br />

ECA<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Basic idea: Enhance (specialise) [basic] operations of the DBMS in such a way<br />

that the application of the operations to a <strong>co</strong>nsistent database will lead to a<br />

<strong>co</strong>nsistent database again<br />

Restriction: Use the smallest enhancement<br />

Greatest <strong>co</strong>nsistent specialisation allows to derive integrity enforcing operations for<br />

the generic database functions<br />

reflection + predicate transformer ⇒ greatest <strong>co</strong>nsistent specialisation<br />

state variable<br />

state space<br />

state <strong>co</strong>nstraints<br />

extended state space<br />

Extending GCS by weakening the <strong>order</strong>, by <strong>co</strong>nsidering specific workflows instead<br />

of all, by distributed enforcement<br />

Content<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

The GCS Approach<br />

Linguistic reflection:<br />

reflection types SCHEMA rep , CLASS rep , TYPE rep , METHOD rep ,<br />

COMMAND rep ,<br />

insert : S :: SCHEMA rep × C :: CLASS rep<br />

delete : S :: SCHEMA rep × C :: CLASS rep<br />

→ METHOD rep<br />

→ METHOD rep<br />

update : S :: SCHEMA rep × C :: CLASS rep → METHOD rep .<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

one macro generic with signature SCHEMA rep → SCHEMA rep<br />

operation on state space X -<br />

characterized by two predicate transformers wp(S) <strong>and</strong> wlp(S)<br />

assign to some post<strong>co</strong>ndition R<br />

weakest (liberal) pre<strong>co</strong>ndition of S to establish R<br />

wlp(S)(R) - initial states with all terminating executions of S reach final state<br />

characterized by R (provided S defined)<br />

wp(S)(R) - initial states with all executions of S terminate, reach a final state<br />

characterized by R (provided S defined)<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

GCS Approach (2)<br />

Y -operation S on X<br />

Greatest Consistent Specialization (GCS) of S with respect to I :<br />

S I specialises S (S I ⊑ S),<br />

S I is <strong>co</strong>nsistent with respect to I<br />

S I is maximal for each X -operation T satisfying the properties: T ⊑ S I<br />

specialisation <strong>order</strong> T ⊑ S<br />

GCSs always exist<br />

wp(S)(true) ⇒ wp(T )(true)<br />

wlp(S)(R) ⇒ wlp(T )(R)<br />

<strong>co</strong>mpatible with <strong>co</strong>njunctions - universal <strong>co</strong>njunctivity<br />

subsumption freeness<br />

usually non-deterministic<br />

quasi-deterministic branches of a GCS<br />

<strong>and</strong><br />

maximal quasi-deterministic <strong>co</strong>nsistent specialisations (MQCSs)<br />

quasi-determinism - determinism up to the selection of some values<br />

X -<strong>co</strong>nstraint I<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

The Computation Of GCS<br />

R 1 = (A :: INT , C :: INT )<br />

R 2 = (B :: INT , D :: INT )<br />

I 1 ≡ R 1 [A] ⊆ R 2 [B] (inclusion dependency)<br />

I 2 ≡ R 2 : D → B (functional dependency)<br />

I 3 ≡ R 1 [C ] ∥ R 2 [D] (exclusion dependency)<br />

ON insert R1 (a, c)<br />

IF c ∈ R 2 [D] THEN Fail<br />

ELSE insert R1 (a, c) IF a ∉ R 1 [A]<br />

THEN insert R2 (a, d) WHERE d ∉ R 1 [C ] ∪ R 2 [D]<br />

Content<br />

Information

Identifiability, Identifier, Accessibility<br />

✞<br />

☎<br />

✝Three kinds of identification statement ✆<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Identifiability as the existence of a potential identification<br />

Identification as the declaration of a specific identification<br />

Identifier as the special implementation<br />

Key access as a special identifier<br />

✠<br />

uniqueness<br />

external level <strong>co</strong>nceptual level<br />

7<br />

internal lev<br />

identification<br />

(surrogate)<br />

identification<br />

existence<br />

<strong>language</strong> definition level<br />

❯<br />

integrity <strong>co</strong>nstraint<br />

(key dependency)<br />

❥<br />

3<br />

✲<br />

identification<br />

accessibility<br />

invariance<br />

Content<br />

Information

Equality Concepts<br />

Functions of an object<br />

Equality <strong>co</strong>ncepts<br />

object-equal<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

i<br />

✛Ident<br />

✲<br />

Obj<br />

t<br />

✻<br />

Thing<br />

Val ✲<br />

o<br />

Struc<br />

❄<br />

s<br />

v<br />

ObjVal s ′<br />

❄<br />

✛Val<br />

✲<br />

v ✲<br />

ObjVal Proj<br />

Struc<br />

❄<br />

o<br />

s<br />

Sub<br />

❄<br />

s’<br />

v| s<br />

′<br />

❄<br />

shallow-equal<br />

❄<br />

deep-equal<br />

i<br />

❄ ✾<br />

similar<br />

✛Ident ✲<br />

Obj<br />

ObjVal s ′<br />

❄<br />

✛Val<br />

✲<br />

v ✲<br />

ObjVal Proj<br />

Struc<br />

❄<br />

o<br />

s<br />

Sub<br />

❄<br />

s’<br />

3<br />

referential-equal<br />

3<br />

<strong>co</strong>ntent-equal<br />

v| s<br />

′<br />

Information<br />

Functions in value-oriented ...<br />

... in value-based databases with keys

Object identifier<br />

✞<br />

✝The devil <strong>and</strong> the beast<br />

☎<br />

✆<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Value-representability is a must.<br />

Detecting cycles is a nightmare.<br />

Cyclic structuring leads to non-first-<strong>order</strong> logics. Structures with<br />

abstract linking are potentially cyclic.<br />

The OID is too expressive.<br />

The OID has already been implemented by relational databases:<br />

tuple identifier.<br />

Object-oriented approaches have improved <strong>and</strong> damaged culture.<br />

Next after OO: <strong>co</strong>mponents<br />

Content<br />

Information

Varieties of representations<br />

✞<br />

☎<br />

Implementation alternatives<br />

✝<br />

✆<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Object-oriented <strong>and</strong> object-relational approaches: objects are de<strong>co</strong>mposed<br />

into a set of related objects<br />

XML-based approaches: classes are hidden<br />

Storage alternatives<br />

Class-separated snowflake representation: an object is stored in several<br />

classes<br />

storage engine<br />

object-relational viewpoint<br />

Full-object representation: all data associated with the object are <strong>co</strong>mpiled<br />

into one object<br />

input engine, output engine<br />

XML viewpoint<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information<br />

Identification is not for free<br />

values - identified by themselves<br />

objects - <strong>co</strong>ntext-dependent identification<br />

1-1 association of real world things <strong>and</strong> objects<br />

real world things have an identification<br />

most general: history<br />

this approach is not applicable: ⇒ OID<br />

objects identifiable<br />

existence generic operations<br />

support for <strong>co</strong>nsistency<br />

Value representability<br />

Object identifiers do not have a meaning to the user.<br />

In general, a unique identification of an object is impossible if all<br />

values <strong>and</strong> references are equal.<br />

It is a <strong>design</strong> decision whether each object should be identifiable.<br />

an object in D is identifiable iff its orbit (for the automorphism group)<br />

is trivial

Value Identifiability<br />

C a class with representation type T C<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

C value-identifiable : Unique(C , I C )<br />

C value-representable : Unique(C , V C )<br />

all objects in each instance D S are identifiable iff all classes in S are<br />

weak value-representable<br />

Value Representability<br />

C value-representable : Unique(C , V C )<br />

∃ proper value type V C ∀ D of S ∃ c : T C → V C<br />

(1) uniqueness <strong>co</strong>nstraint on C defined by c holds<br />

(2) ∀ uniqueness <strong>co</strong>nstraint on C defined by c ′ : T C → V C ′ with<br />

value type V C ′ exists a function c′′ : V C → V C ′ that is unique on<br />

c(<strong>co</strong>dom(D(C ))) with c ′ = c ′′ ◦ c<br />

Content<br />

Information

Values versus Objects<br />

Values:<br />

7, “Hugo”, (Seminar 9434, Key<strong>co</strong>de 1535)<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Objects:<br />

Cicero - as author, historical person<br />

Tully - as friend<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

values - identified by themselves<br />

objects - <strong>co</strong>ntext-dependent identification<br />

⇒<br />

1-1 association of real world things <strong>and</strong> objects<br />

real world things have an identification<br />

most general: history<br />

this approach is not applicable: ⇒ OID<br />

Content<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information<br />

⇒<br />

Values versus Objects<br />

(1) OID invisible for users<br />

(2) separation value/object<br />

(3) objects have values<br />

(4) operations (better events) are associated with objects<br />

(5) requirements<br />

(a) objects identifiable<br />

(b) existence generic operations<br />

(c) support for <strong>co</strong>nsistency<br />

general object:<br />

identifier<br />

‘set’ of values<br />

‘set’ of references<br />

‘set’ of methods<br />

no definition<br />

formal approach:<br />

define set of objects<br />

schema definition, instance<br />

primary notion

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Distinguishability Problem<br />

o 1<br />

o 3<br />

o 5<br />

o 7<br />

s<br />

s<br />

s<br />

s<br />

✲<br />

✲<br />

✲<br />

✲<br />

o 2<br />

o 4<br />

o 6<br />

o 8<br />

s ′<br />

❥<br />

3✿<br />

✯<br />

s ′<br />

s ′ 2<br />

s ′<br />

s ′<br />

✲<br />

1<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

o 2<br />

s 2<br />

s<br />

✿<br />

2 2<br />

✲<br />

✻ s 3 3<br />

s 1 o 1 s 1 s 1 s 3<br />

o 4 s 1<br />

✛<br />

2<br />

s<br />

s 3 ❄<br />

2 2<br />

3 o 3 ✾ s 2<br />

s 3<br />

Content<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

✛<br />

✻❦<br />

o 1<br />

Distinguishability Problem<br />

s ′<br />

o 1<br />

✲ o 3<br />

✯<br />

s<br />

<br />

s<br />

5<br />

❥<br />

✿<br />

o<br />

o 4<br />

ss<br />

′′<br />

s ′<br />

′ s ′′ s<br />

✲ o 2<br />

5 o 3<br />

✲<br />

✻<br />

s ′ s ′ s ′ s s<br />

s<br />

o 2<br />

❄<br />

✛<br />

✻❦<br />

5 o 3<br />

o 1<br />

s ′ s ′ s ′ s<br />

✙<br />

s<br />

✿<br />

3<br />

o 3 s ′′<br />

s ′′ ✿ 5<br />

o 2<br />

✲<br />

o 2<br />

✻<br />

s<br />

3<br />

Content<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information<br />

Reference graphs<br />

reference graph of C in S smallest labelled graph G rep = (V , E, l)<br />

(1) ∃ v C ∈ V : l(v C ) = {t, C }<br />

t - top-level type in the structure expression S of C<br />

(2) for each proper occurrence of a type t ≠ ID in T C there exists a unique vertex v t ∈ V with<br />

l(v t ) = {t}<br />

(3) for each reference r i : C i in S the reference graph Gref i is a subgraph of G ref<br />

(4) for each vertex v t or v C <strong>co</strong>rresponding to t(x 1 , . . . , x n ) in S there exist unique edges e (i)<br />

t from v t<br />

or v C respectively to v ti in case x i is the type t i or to v Ci in case x i is the reference r i : C i<br />

in the first case l(e (i)<br />

t ) = {S i } for the <strong>co</strong>rresponding selector name S i<br />

in the latter case the label is {S i , r i }<br />

S = {C 1 , . . . , C n } , S ′ = {C ′ 1, . . . , C ′ n} another schema such that for all i there exists a uniqueness<br />

<strong>co</strong>nstraint on C i defined by some c i : T Ci<br />

→ T C ′<br />

i<br />

identification graph G id of the class C i is obtained from the reference graph of C i<br />

′<br />

each label C j<br />

′ to C j<br />

Algorithm<br />

⎧<br />

⎨ T i for uniqueness <strong>co</strong>nstraint c i : T Ci → T i<br />

F (C i ) =<br />

⎩ undefined else<br />

by changing<br />

iterate as long as possible:<br />

(1) If F (C j ) is a proper value type <strong>and</strong> ID occurs in some F (C i ) <strong>co</strong>rresponding to a reference to C j<br />

(i ≠ j ), then replace this ID in F (C i ) by F (C j ).<br />

(2) If ID occurs in some F (C i ), then let F (C i ) be recursively defined by F (C i ) == S i , where S i is<br />

the result of replacing ID i in F (C i ) by the type name F (C i ).

Acyclic <strong>and</strong> cyclic schemata<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

If in the reference graph G ref there exist uniqueness <strong>co</strong>nstraints for<br />

C <strong>and</strong> each C i such that C i occurs as a label in G ref , then C is<br />

value-representable.<br />

If there exist an identification graph G id <strong>and</strong> uniqueness <strong>co</strong>nstraints<br />

for C <strong>and</strong> each C i occuring as a label in G id , then C is valueidentifiable.<br />

Value-representability is decidable for acyclic graphs.<br />

If there exists an acyclic identification graph the value-identifiability<br />

is decidable.<br />

If all explicit <strong>co</strong>nstraints are uniqueness <strong>co</strong>nstraints then valueidentifiability<br />

<strong>and</strong> value-representability are decidable.<br />

Content<br />

Information

Weak value-representability<br />

<strong>co</strong>nsidering all references to <strong>and</strong> from a class<br />

for identification<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

weak value-representable classes<br />

C - weak value-representable class in S<br />

⇒ ∃ value type V w C : Unique(C , V w C )<br />

S : all objects in each instance D S are identifiable iff all classes in S<br />

are weak value-representable<br />

Content<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Information Dem<strong>and</strong> based on User<br />

Profiles <strong>and</strong> Portfolio<br />

Information dem<strong>and</strong> support depending on specifics<br />

Workplace <strong>and</strong> workspace support<br />

Consumed <strong>and</strong> produced data<br />

Context dem<strong>and</strong><br />

Formulation, <strong>language</strong><br />

based on characterisation of the user, user stories<br />

Task/work portfolio support for the user<br />

Tasks: characteristics, execution, result, <strong>co</strong>ntrol<br />

Involvement: role, part<br />

Collaboration: <strong>co</strong>mmunication, <strong>co</strong>ordination, <strong>co</strong>operation<br />

Restrictions: subtasks, environment<br />

Personal profile support for the user<br />

Work profile<br />

Education profile<br />

Group profile<br />

Content<br />

Information

Information Versus Knowledge <strong>and</strong> Data<br />

What do we need? INFORMATION !<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information as processed by humans, is data perceived or noticed,<br />

selected <strong>and</strong> organized by its receiver, because of his subjective human<br />

interests, originating from his instincts, feelings, experience,<br />

intuition, <strong>co</strong>mmon sense, values, beliefs, personal knowledge, or<br />

wisdom simultaneously processed by his <strong>co</strong>gnitive <strong>and</strong> mental processes,<br />

<strong>and</strong> seamlessly integrated in his recallable knowledge.<br />

General knowledge as sustainable, evolving, potentially durable<br />

<strong>and</strong> verifiable data that is grounded on <strong>co</strong>nsensus<br />

Skills as ability to do something well<br />

T. S. Eliot (1888-1965), The rock, 1934:<br />

Where is the wisdom we have lost in knowledge?<br />

Where is the knowledge we have lost in information?<br />

β nowadays:<br />

Where is the information we have lost in news?<br />

Where is the information we have lost in data?<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Differentiating Dimensions<br />

The four dimensions of the knowledge space surrounded by the <strong>co</strong>ntext dimension:<br />

(1) data dimension through <strong>co</strong>ntent;<br />

(2) foundation dimension through <strong>co</strong>ncepts;<br />

(3) <strong>language</strong> dimension through topics;<br />

(4) user dimension through information;<br />

(5) <strong>co</strong>ntext of data (<strong>co</strong>ntent) or theories (<strong>co</strong>ncept) or user (information) or<br />

carrier/<strong>language</strong> (topic)<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Databases<br />

utilisation<br />

Content space<br />

Media types<br />

functionality, adaptation<br />

Topics<br />

ontology<br />

Topic space<br />

Knowledge<br />

space<br />

Concept space<br />

Annotation, linking<br />

culture, <strong>co</strong>ntext<br />

Context<br />

User profiles<br />

user portfolio<br />

Information space<br />

Memes<br />

cultural units<br />

Content<br />

Information<br />

Semantic theories<br />

ontology<br />

Pragmatics<br />

general culture

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information<br />

Knowledge Chunk<br />

Knowledge pieces cannot be <strong>co</strong>nsidered in an isolated form. They are <strong>co</strong>mposed.<br />

Knowledge chunk C: a suite of knowledge pieces <strong>co</strong>nsisting of <strong>co</strong>ntent,<br />

<strong>co</strong>ncepts, topics <strong>and</strong> information.<br />

Content chunk D = {D 1 , ..., D n }<br />

typically given as a set of media objects<br />

Concept chunk C = {C 1 , ..., C k }<br />

typically given as a small ‘theory’<br />

Topic chunk T = {T 1 , ..., T m }<br />

typically given as a map of associated topics<br />

Associated by generalised mappings<br />

interpretation: D → C (opposite to foundation)<br />

explanation: T → C (opposite to presentation)<br />

annotation: D → T (opposite to <strong>co</strong>ntent delivery)<br />

Information chunk of a user<br />

for a given universe of <strong>co</strong>ntexts I A of an agent A<br />

with <strong>co</strong>rresponding associations (partial)<br />

to <strong>co</strong>ntent D A , <strong>co</strong>ncepts C A , topics T A of the user<br />

May also be extended by the agent, ... <strong>co</strong>ntext.

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information<br />

Knowledge Chunk<br />

Knowledge pieces cannot be <strong>co</strong>nsidered in an isolated form. They are <strong>co</strong>mposed.<br />

Knowledge chunk C: a suite of knowledge pieces <strong>co</strong>nsisting of <strong>co</strong>ntent,<br />

<strong>co</strong>ncepts, topics <strong>and</strong> information.<br />

Content chunk D = {D 1 , ..., D n }<br />

typically given as a set of media objects<br />

Concept chunk C = {C 1 , ..., C k }<br />

typically given as a small ‘theory’<br />

Topic chunk T = {T 1 , ..., T m }<br />

typically given as a map of associated topics<br />

Associated by generalised mappings<br />

interpretation: D → C (opposite to foundation)<br />

explanation: T → C (opposite to presentation)<br />

annotation: D → T (opposite to <strong>co</strong>ntent delivery)<br />

Information chunk of a user<br />

for a given universe of <strong>co</strong>ntexts I A of an agent A<br />

with <strong>co</strong>rresponding associations (partial)<br />

to <strong>co</strong>ntent D A , <strong>co</strong>ncepts C A , topics T A of the user<br />

May also be extended by the agent, ... <strong>co</strong>ntext.

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information<br />

(C + +) Example of a Mathematical Concept<br />

(The Concept as a Small Theory)<br />

⟨Definition:⟩ A sequence of real (or <strong>co</strong>mplex) numbers is said to <strong>co</strong>nverge to a real (or <strong>co</strong>mplex)<br />

number c if for every ϵ > 0 there is an integer n ϵ > 0 such that if j > n ϵ then |a j − c| < ϵ. The<br />

number c is called the limit of the sequence <strong>and</strong> we sometimes write a j −→ c.<br />

If a sequence does not <strong>co</strong>nverge, then we say that it diverges.<br />

In other words, a sequence can be denoted by f (1), f (2), f (3), ..... Usually, we will denote such a sequence<br />

by the symbol (a j ) j , where a j = f (j ).<br />

⟨Sub-<strong>co</strong>ncept:⟩ Sequences that <strong>co</strong>nverge to zero are called null sequences.<br />

⟨Annotation⟩: A sequence which <strong>co</strong>nverges.<br />

⟨Prerequisite <strong>co</strong>ncept:⟩ A sequence of real numbers is a function f : N −→ R.<br />

⟨More specific prerequisites:⟩ monotone de/increasing sequences<br />

For example, the sequence 1, 1 2 , 1 2 , 1 3 , 1 4 , 1 5 , ... is written as ( 1 n ) n . Keep in mind that despite the strange notation,<br />

a sequence can be thought of as an ordinary function. However, in many cases, that may not be the most expedient<br />

way to look at the situation. It is often easier to simply look at a sequence as a ‘string’ of numbers that may or<br />

may not exhibit a certain pattern.<br />

⟨Context⟩: The limit of a sequence is one of the oldest <strong>co</strong>ncepts in mathematical analysis. It provides a rigorous<br />

definition of the idea of a sequence <strong>co</strong>nverging towards a point called the limit.<br />

⟨Related <strong>co</strong>ncepts:⟩ A <strong>co</strong>nvergent sequence is bounded <strong>and</strong> the limit is unique. Cauchy sequences ....<br />

Do not <strong>co</strong>nfuse this with the idea of a series defined by the result of summarising infinitely many numbers<br />

∑ ∞<br />

j =1 a j . Despite the fact that the <strong>co</strong>mmon non-mathematical meaning of “sequence” <strong>and</strong> “series” is identical<br />

there are separate definitions of <strong>co</strong>nvergence for sequences <strong>and</strong> series, <strong>and</strong> separate theories for these with some<br />

important differences that you need to be aware of. An infinite series is an expression of the form ∑ n<br />

j =1 a j ,<br />

where (a n ) is a sequence.<br />

limit inferior, limit superior

(C + +) Example of a Mathematical Concept<br />

(Annotation as Topic, Data as Content)<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information<br />

⟨Definition:⟩ A sequence of real (or <strong>co</strong>mplex) numbers is said to <strong>co</strong>nverge to a real (or <strong>co</strong>mplex)<br />

number c if for every ϵ > 0 there is an integer n ϵ > 0 such that if j > n ϵ then |a j − c| < ϵ. The<br />

number c is called the limit of the sequence <strong>and</strong> we sometimes write a j −→ c.<br />

If a sequence does not <strong>co</strong>nverge, then we say that it diverges.<br />

In other words, a sequence can be denoted by f (1), f (2), f (3), ..... Usually, we will denote such a sequence<br />

by the symbol (a j ) j , where a j = f (j ).<br />

⟨Sub-<strong>co</strong>ncept:⟩ Sequences that <strong>co</strong>nverge to zero are called null sequences.<br />

⟨Annotation⟩: A sequence which <strong>co</strong>nverges.<br />

⟨Prerequisite <strong>co</strong>ncept:⟩ A sequence of real numbers is a function f : N −→ R.<br />

⟨More specific prerequisites:⟩ monotone de/increasing sequences<br />

For example, the sequence 1, 1 2 , 1 2 , 1 3 , 1 4 , 1 5 , ... is written as ( 1 n ) n . Keep in mind that despite the strange notation,<br />

a sequence can be thought of as an ordinary function. However, in many cases, that may not be the most expedient<br />

way to look at the situation. It is often easier to simply look at a sequence as a ‘string’ of numbers that may or<br />

may not exhibit a certain pattern.<br />

⟨Context⟩: The limit of a sequence is one of the oldest <strong>co</strong>ncepts in mathematical analysis. It provides a rigorous<br />

definition of the idea of a sequence <strong>co</strong>nverging towards a point called the limit.<br />

⟨Related <strong>co</strong>ncepts:⟩ A <strong>co</strong>nvergent sequence is bounded <strong>and</strong> the limit is unique. Cauchy sequences ....<br />

Do not <strong>co</strong>nfuse this with the idea of a series defined by the result of summarising infinitely many numbers<br />

∑ ∞<br />

j =1 a j . Despite the fact that the <strong>co</strong>mmon non-mathematical meaning of “sequence” <strong>and</strong> “series”is identical<br />

there are separate definitions of <strong>co</strong>nvergence for sequences <strong>and</strong> series, <strong>and</strong> separate theories for these with some<br />

important differences that you need to be aware of. An infinite series is an expression of the form ∑ n<br />

j =1 a j ,<br />

where (a n ) is a sequence.

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Example of a Computer Science Concept<br />

Definition<br />

Transaction as <strong>co</strong>ncurrent operation (Elmasri/Navathe): “The execution<br />

of a program that accesses or changes the <strong>co</strong>ntents of the database is<br />

called a transaction. The transaction submitted by various users may<br />

execute <strong>co</strong>ncurrently <strong>and</strong> may access <strong>and</strong> update the same database<br />

re<strong>co</strong>rds. If this <strong>co</strong>ncurrency is un<strong>co</strong>ntrolled, it may lead to problems<br />

such as an in<strong>co</strong>nsistent database.”<br />

Transactions must have four properties:<br />

Atomicity.<br />

Consistency.<br />

Isolation.<br />

Durability.<br />

Content<br />

Information

Syntactic transaction <strong>and</strong> their behavior<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Syntax: transaction T over (S, Σ) is a<br />

finite sequence o 1 ; o 2 ; o 3 ; ...; o m of<br />

basic modification operations (insert, delete, update) <strong>and</strong><br />

retrieval operations map(filter(join(...), ψ), S)<br />

over (S, Σ).<br />

Semantics of application: effect of application of T to S C<br />

as a transition <strong>co</strong>nstraint preserving transformation<br />

{<br />

T (S C<br />

T (S C ) if T (S C ) |= Σ<br />

) =<br />

S C if T (S C ) ̸|= Σ<br />

The effect defines the granularity of the transaction.<br />

TA’s in general understood as invariant state transitions<br />

invariant ac<strong>co</strong>rding to the set of<br />

static integrity <strong>co</strong>nstraints<br />

is defined<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information<br />

Potential parallel execution of TA’s<br />

T 1 , T 2 are <strong>co</strong>mpeting<br />

if read(T 1 ) ∩ write(T 2 ) ≠ ∅ or read(T 2 ) ∩ write(T 1 ) ≠ ∅<br />

or write(T 2 ) ∩ write(T 1 ) ≠ ∅ .<br />

read(T i ) resp. write(T i ) : locations of objects read or written by T i<br />

Parallel execution of transactions T 1 ∥ T 2 is <strong>co</strong>rrect<br />

if either T 1 ∥ T 2 are not <strong>co</strong>mpeting<br />

or (T 1 ∥T 2 )(S C ) ∈ ≡ { T 1 (T 2 (S C )), T 2 (T 1 (S C ))} for any<br />

S C<br />

Observation: If parallel execution is <strong>co</strong>rrect for a set of transactions<br />

transaction execution can be scheduled entirely in parallel.<br />

Remarks: 0. We are <strong>co</strong>ncerned with the <strong>co</strong>nceptual definition of TA’s <strong>and</strong> not<br />

with their implementation techniques that must satisfy a number of properties<br />

(with a proof of validity).<br />

1. Classically, <strong>co</strong>nflict serializability expresses potential parallel execution.<br />

2. View serializability is definable in a similar way.<br />

3. Testing of potential parallel execution is simple (<strong>co</strong>nflict graph resolution)<br />

as long as read, write are <strong>co</strong>nsidered <strong>and</strong> rather <strong>co</strong>mplex if retrieval<br />

<strong>and</strong> modification operations (insert, delete, update) are allowed.

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Information<br />

Content<br />

base<br />

✻<br />

❄<br />

Database<br />

Proposal for an Architecture of<br />

User-Oriented Content Management<br />

Systems<br />

✲✛<br />

✲✛<br />

Web Playout System<br />

Story Space<br />

Stories<br />

Scenarios<br />

Content<br />

Management System<br />

Content types<br />

Service<br />

Structure Functionality<br />

Container<br />

Structuring Functionality<br />

Structure<br />

Static IC<br />

(Pragmatics)<br />

✞<br />

☎<br />

Towards this century CMS<br />

✝<br />

✆<br />

Actors<br />

Context<br />

✻<br />

❄<br />

Processes<br />

Dynamic IC<br />

(Pragmatics)<br />

User Management System<br />

Profile<br />

manager<br />

Portfolio<br />

manager<br />

Association generator /<br />

Natural <strong>language</strong> engine<br />

Privacy Protection System✲✛<br />

✻❄<br />

Topic Management System<br />

Topic Community<br />

manager manager<br />

Asset manager /<br />

✲✛ Topic<br />

Infon representer<br />

l<strong>and</strong>scape<br />

Concept Managem. System<br />

Concept Derivation<br />

manager engine<br />

Unit manager /<br />

Infon representer<br />

✲✛<br />

Private<br />

database<br />

Concept<br />

base

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Publications on Database Theory<br />

E. Börger <strong>and</strong> B. Thalheim. A method for verifiable <strong>and</strong> validatable business process modeling. In<br />

Software Engineering, volume 5316 of Lecture Notes in Computer Science, pages 59 – 115. Springer,<br />

2008.<br />

D. Goldin, S. Srinivasa, <strong>and</strong> B. Thalheim. IS = DBS + interaction - towards principles of information<br />

systems. In A. H. F. Laender, S. W. Liddle, <strong>and</strong> V. C. Storey, editors, ER, volume 1920 of LNCS,<br />

pages 140–153. Springer, 2000.<br />

H.-J. Lenz <strong>and</strong> B. Thalheim. A formal framework of aggregation for the OLAP-OLTP model. Journal<br />

of Universal Computer Science, 15(1):273 – 303, 2009.<br />

K.-D. Schewe <strong>and</strong> B. Thalheim. Reasoning about web information systems using story algebra. In<br />

ADBIS’2004, LNCS 3255, pages 54–66, 2004.<br />

K.-D. Schewe <strong>and</strong> B. Thalheim. Fundamental <strong>co</strong>ncepts of object oriented databases. Acta Cybernetica,<br />

11(4):49–81, 1993.<br />

K.-D. Schewe <strong>and</strong> B. Thalheim. Readings in object-oriented databases. Reprint, BTU-Cottbus,<br />

accessible through http://www.is.informatik.uni-kiel.de/∼thalheim, Collection of papers by C. Beeri,<br />

K.-D. Schewe, J.-W. Schmidt, D. Stemple, B. Thalheim, I. Wetzel, 1998.<br />

O. Seleznev <strong>and</strong> B. Thalheim. Average case analysis in database problems. Methodology <strong>and</strong> Computing<br />

in Applied Probability, 48:177–198, 2003.<br />

B. Thalheim. Entity-<strong>relationship</strong> modeling – Foundations of database technology. Springer, Berlin,<br />

2000.<br />

B. Thalheim. Entity-<strong>relationship</strong> modeling – Foundations of database technology. Springer, Berlin,<br />

2000.<br />

B. Thalheim. Model suites. In 2nd International Workshop on Knowledge Cluster Systems, pages<br />

20–40. IOS Press, 2008.<br />

Information

Publications on Genericity<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

A. Bienemann. A generative approach to functionality of interactive information systems. PhD<br />

thesis, CAU Kiel, Dept. of Computer Science, 2008.<br />

A. Bienemann, K.-D. Schewe, <strong>and</strong> B. Thalheim. Towards a theory of genericity based on government<br />

<strong>and</strong> binding. In Proc. ER’06, LNCS 4215, 311–324. Springer, 2006.<br />

A. Binemann-Zdanowicz, B. Thalheim, <strong>and</strong> B. Tschiedel. Storyboarding for adaptive <strong>co</strong>ntent generation<br />

for e-learning web services. In Computer Science Report I-10/2003, Br<strong>and</strong>enburg University<br />

of Technology at Cottbus, 2003.<br />

A. Binemann-Zdanowicz. Towards generative engineering of <strong>co</strong>ntent-intensive applications. In Proc.<br />

Principles of Software Engineering Conference (PRISE 2004), 41–49, 2004.<br />

M. Klettke. Reuse of database <strong>design</strong> decisions. In P. P. Chen, D. W. Embley, J. Kouloumdjian,<br />

S. W. Liddle, <strong>and</strong> J. F. Roddick, editors, Proc. Advances in Conceptual Modeling, LNCS 1727,<br />

213–224. Springer, Berlin, 1999.<br />

T. Moritz. Visuelle Gestaltungsraster interaktiver Informationssysteme als integrativer Best<strong>and</strong>teil<br />

des immersiven Bildraumes. PhD thesis, HFF Berlin-Babelsberg, 2006.<br />

B. Thalheim. The <strong>co</strong>nceptual framework to multi-layered database <strong>modelling</strong>. In Proc. EJC, 118–<br />

138, Maribor, Slovenia, 2009.<br />

Content<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Publications on Model Suites, Evolution,<br />

Migration<br />

A. Dahanayake <strong>and</strong> B. Thalheim. Co-evolution of (information) system models. In EMMSAD<br />

2010, volume 50 of LNBIP, 314–326. Springer, 2010.<br />

A. Dahanayake <strong>and</strong> B. Thalheim. Towards a framework for emergent modeling. In ER Workshops,<br />

volume 6413 of Lecture Notes in Computer Science, 128–137. Springer, 2010.<br />

M. Klettke <strong>and</strong> B. Thalheim. Evolution <strong>and</strong> migration of information systems. In The H<strong>and</strong>book<br />

of Conceptual Modeling: Its Usage <strong>and</strong> Its Challenges, chapter 12, 381–420. Springer, Berlin,<br />

2011.<br />

B. Neumayr <strong>and</strong> M. Schrefl und B. Thalheim. Modeling techniques for multi-level abstraction.<br />

In The Evolution of Conceptual Modeling, volume 6520 of Lecture Notes in Computer Science,<br />

68–92, Berlin, 2011. Springer.<br />

B. Thalheim. Model suites. In H. Jaakkola, editor, Selected Topics on Distributed Disaster<br />

Management: Towards Collaborative Knowledge Clusters., 108 – 128. Tampere University Press,<br />

Porin yksikkö, 2008.<br />

B. Thalheim. The <strong>co</strong>nceptual framework to multi-layered database <strong>modelling</strong>. In Proc. EJC,<br />

118–138, Maribor, Slovenia, 2009.<br />

B. Thalheim. Model suites for multi-layered database <strong>modelling</strong>. In Information Modelling<br />

<strong>and</strong> Knowledge Bases XXI, volume 206 of Frontiers in Artificial Intelligence <strong>and</strong> Applications,<br />

116–134. IOS Press, 2010.<br />

Content<br />

Information

Publications on Business Process<br />

Modelling & Notation<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

E. Börger <strong>and</strong> O. Sörensen. Bpmn <strong>co</strong>remodeling <strong>co</strong>ncepts: Inheritance-based execution semantics.<br />

In The H<strong>and</strong>book of Conceptual Modeling: Its Usage <strong>and</strong> Its Challenges, chapter 9, pages<br />

287–334. Springer, Berlin, 2011.<br />

E. Börger, O. Sörensen, <strong>and</strong> B. Thalheim. On defining the behavior of or-joins in business<br />

process models. Journal of Universal Computer Science, 15(1):3–32, 2009.<br />

E. Börger <strong>and</strong> B. Thalheim. A method for verifiable <strong>and</strong> validatable business process modeling.<br />

In Software Engineering, volume 5316 of Lecture Notes in Computer Science, pages 59 – 115.<br />

Springer, 2008.<br />

E. Börger <strong>and</strong> B. Thalheim. Modeling workflows, interaction patterns, web services <strong>and</strong> business<br />

processes: The ASM-based approach. In ABZ, volume 5238 of Lecture Notes in Computer<br />

Science, pages 24–38. Springer, 2008.<br />

M. Kirchberg, O. Sörensen, <strong>and</strong> B. Thalheim. A BPMN case study: Paper review <strong>and</strong> submission<br />

system. In GI Jahrestagung, volume 154 of LNI, pages 4067–4081. GI, 2009.<br />

K.-D. Schewe <strong>and</strong> B. Thalheim. ASM foundations of database management. In Information<br />

Systems <strong>and</strong> e-Business Technologies, volume LNBIP 5, pages 318–331, Berlin, 2008. Springer.<br />

Q. Wang, K.-D. Schewe, <strong>and</strong> B. Thalheim. XML database transformations with tree updates.<br />

In ABZ, volume 5238 of Lecture Notes in Computer Science, page 342. Springer, 2008.<br />

Content<br />

Information

Publications on Object Identification<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

C. Beeri <strong>and</strong> B. Thalheim. Can I see your identification, please? - Identification is wellfounded<br />

in object-oriented databases. Manuscript, Cottbus/Jerusalem, 1995.<br />

C. Beeri <strong>and</strong> B. Thalheim. Identification as a primitive of database models. In Proc.<br />

FoMLaDO’98, pages 19–36. Kluwer, London, 1999.<br />

K.-D. Schewe, D. W. Stemple, <strong>and</strong> B. Thalheim. <strong>Higher</strong>-level genericity in object-oriented<br />

databases. In S. Chakravarthy <strong>and</strong> P. Sadan<strong>and</strong>an, editors, Proc. 6th Int. Conf. on<br />

Management of Data - COMAD’94, 1994. Bangalore.<br />

B. Schewe, K.-D. Schewe, <strong>and</strong> B. Thalheim. Object-oriented <strong>design</strong> of data intensive<br />

business information systems. Informatik-Forschung und Entwicklung, 10(3):115–127,<br />

1995. (In German).<br />

K.-D. Schewe <strong>and</strong> B. Thalheim. Fundamental <strong>co</strong>ncepts of object oriented databases.<br />

Acta Cybernetica, 11(4):49–81, 1993.<br />

K.-D. Schewe <strong>and</strong> B. Thalheim. Readings in object-oriented databases. Reprint, BTU-<br />

Cottbus, accessible through http://www.is.informatik.uni-kiel.de/∼thalheim, Collection<br />

of papers by C. Beeri, K.-D. Schewe, J.-W. Schmidt, D. Stemple, B. Thalheim, I. Wetzel,<br />

1998.<br />

Content<br />

Information

Publications on Enforcement <strong>and</strong> GCS<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

K.-D. Schewe, J. W. Schmidt, D. W. Stemple, B. Thalheim, <strong>and</strong> I. Wetzel. Generating methods<br />

to assure global integrity. Technical Report Rostocker Informatik-Berichte, 14, Universität<br />

Rostok, 1992.<br />

K.-D. Schewe <strong>and</strong> B. Thalheim. Limitations of rule triggering systems for integrity maintenance<br />

in the <strong>co</strong>ntext of transition specification. Acta Cybernetica, 13:277–304, 1998.<br />

K.-D. Schewe <strong>and</strong> B. Thalheim. On the strength of rule triggering systems for integrity maintenance.<br />

In C. McDonald, editor, Proc. Database Systems, 9th Australasian Database Conf. -<br />

ADC’98, pages 77–88, 1998. Australian Computer Science Communications, 20(2).<br />

K.-D. Schewe <strong>and</strong> B. Thalheim. Towards a theory of <strong>co</strong>nsistency enforcement. Acta informatica,<br />

36:97–141, 1999.<br />

K.-D. Schewe <strong>and</strong> B. Thalheim. Towards a theory of <strong>co</strong>nsistency enforcement. Acta Informatica,<br />

36(2):97–141, 1999.<br />

K.-D. Schewe, B. Thalheim, J. W. Schmidt, <strong>and</strong> I. Wetzel. Integrity enforcement in objectoriented<br />

databases. In U. W. Lipeck <strong>and</strong> B. Thalheim, editors, Proc. Modelling Database<br />

Dynamics, selected papers from the 4th Int. Workshop on Foundations of Models <strong>and</strong> Languages<br />

for Data <strong>and</strong> Objects - FoMLaDO’92, Workshops in Computing, pages 174–195, Volkse, 1992,<br />

1993. Springer, London.<br />

Content<br />

Information

Publications on Concepts, Content, Topics<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

G. Fiedler, A. Czerniak, D. Fleischer, H. Rumohr, M. Spindler, <strong>and</strong> B. Thalheim. Content<br />

Warehouses. Preprint 0605, Department of Computer Science, Kiel University, March 2006.<br />

G. Fiedler <strong>and</strong> B. Thalheim. Towards linguistic foundations of <strong>co</strong>ntent management. In Springer,<br />

editor, NLDB’2004, LNCS 3136, pages 348–353, 2004.<br />

G. Fiedler <strong>and</strong> B. Thalheim. Towards semantic wikis: Modelling intensions, topics, <strong>and</strong> origin in<br />

<strong>co</strong>ntent management systems. Information Modelling <strong>and</strong> Knowledge Bases, XX:1–21, 2009.<br />

K.D. Schewe <strong>and</strong> B. Thalheim. Web information systems: Usage, <strong>co</strong>ntent, <strong>and</strong> functionality<br />

<strong>modelling</strong>. Technical Report 2004-3, Christian Albrechts University Kiel, Institute of Computer<br />

Science <strong>and</strong> Applied Mathematics, Kiel, 2004.<br />

B. Thalheim. The <strong>co</strong>-<strong>design</strong> framework to <strong>co</strong>ntent specification. In W. Abramowicz, editor,<br />

BIS’2004, pages 326–351. IEEE Press, 2004.<br />

B. Thalheim. The <strong>co</strong>nceptual framework to user-oriented <strong>co</strong>ntent management. In Information<br />

Modelling <strong>and</strong> Knowledge Bases XVIII, Frontiers in Artificial Intelligence <strong>and</strong> Applications. IOS<br />

Press, 2007.<br />

Content<br />

Information

Publications on Keys<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

O. Seleznjev <strong>and</strong> B. Thalheim. On the number of minimal keys in relational databases over<br />

nonuniform domains. Acta Cybernetica, 8(3):267–271, 1988.<br />

O. Seleznjev <strong>and</strong> B. Thalheim. Applying poisson approximation to database theory. In Proc. 4th<br />

Bernoulli Congress, Vienna, abstracts, page 425, 1996.<br />

O. Seleznjev <strong>and</strong> B. Thalheim. Behavior of keys in r<strong>and</strong>om databases. In Proc. SCCC’98, pages<br />

171–183, Antofagasta,Chile, 1998.<br />

O. Seleznev <strong>and</strong> B. Thalheim. Average case analysis in database problems. Methodology <strong>and</strong><br />

Computing in Applied Probability, 48:177–198, 2003.<br />

O. Seleznev <strong>and</strong> B. Thalheim. R<strong>and</strong>om databases with approximate re<strong>co</strong>rd matching. Methodology<br />

<strong>and</strong> Computing in Applied Probability, 12:63–89, 2010.<br />

B. Thalheim. Design tools for large relational database systems. LNCS 305, pages 210–224,<br />

Dresden, 1988. Springer, Berlin/New York.<br />

B. Thalheim. On semantic issues <strong>co</strong>nnected with keys in relational databases permitting null<br />

values. Journal of Information Processing <strong>and</strong> Cybernetics, EIK, 25(1/2):11–20, 1989.<br />

B. Thalheim. On the number of keys in relational <strong>and</strong> nested relational databases. Discrete<br />

Applied Mathematics, 38:265–282, 1992.<br />

Content<br />

Information

Publications on Science <strong>and</strong> Art of<br />

Conceptual Modelling<br />

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

A. Dahanayake <strong>and</strong> B. Thalheim. Towards a framework for emergent modeling. In ER Workshops,<br />

volume 6413 of Lecture Notes in Computer Science, 128–137. Springer, 2010.<br />

A. Dahanayake <strong>and</strong> B. Thalheim. Enriching <strong>co</strong>nceptual <strong>modelling</strong> practices through <strong>design</strong><br />

science. In BMMDS/EMMSAD, volume 81 of Lecture Notes in Business Information Processing,<br />

497–510. Springer, 2011.<br />

B. Thalheim. Towards a theory of <strong>co</strong>nceptual <strong>modelling</strong>. Journal of Universal Computer Science,<br />

2010, 16, 20, 3102–3137.<br />

B. Thalheim. The theory of <strong>co</strong>nceptual models, the theory of <strong>co</strong>nceptual <strong>modelling</strong> <strong>and</strong> foundations<br />

of <strong>co</strong>nceptual <strong>modelling</strong>. In The H<strong>and</strong>book of Conceptual Modeling: Its Usage <strong>and</strong> Its<br />

Challenges, chapter 12, 543–578. Springer, Berlin, 2011.<br />

B. Thalheim. The science of <strong>co</strong>nceptual <strong>modelling</strong>. In Proc. DEXA 2011, volume 6860 of LNCS,<br />

12–26, Berlin, 2011. Springer.<br />

B. Thalheim. Integrity <strong>co</strong>nstraints in (<strong>co</strong>nceptual) database models. In The Evolution of Conceptual<br />

Modeling, volume 6520 of Lecture Notes in Computer Science, 42–67, Berlin, 2011.<br />

Springer.<br />

B. Thalheim. The art of <strong>co</strong>nceptual <strong>modelling</strong>. In Proc. EJC 2011, 203–222, Tallinn, 2011.<br />

B. Thalheim. Culture <strong>and</strong> art of <strong>co</strong>nceptual <strong>modelling</strong>. Anwendungsorientierte Organisationsgestaltung,<br />

127–144. baar, Hamburg, 2011.<br />

Content<br />

Information

Information<br />

Systems<br />

Theory<br />

5.7.2012<br />

B. Thalheim<br />

Why<br />

Constraints<br />

Visuality<br />

BPMN<br />

Model suite<br />

Triggering<br />

Id<strong>entity</strong><br />

Concepts<br />

Open<br />

Publications<br />

Content<br />

Hungarian Publications<br />

J. Demetrovics, G. O. H. Katona, D. Miklós, O. Seleznjev, <strong>and</strong> B. Thalheim. The average length of keys<br />

<strong>and</strong> functional dependencies in (r<strong>and</strong>om) databases. LNCS 893, 266–279, Prague, 1995. Springer, Berlin.<br />

J. Demetrovics, G. O. H. Katona, D. Miklós, O. Seleznjev, <strong>and</strong> B. Thalheim. Asymptotic properties of<br />

keys <strong>and</strong> functional dependencies in r<strong>and</strong>om databases. Theor. Comput. Sci., 190(2):151–166, 1998.<br />

J. Demetrovics, G. O. H. Katona, D. Miklós, O. Seleznjev, <strong>and</strong> B. Thalheim. Functional dependencies in<br />

r<strong>and</strong>om databases. Journal Studia Scientarium Matematicarum Hungarica, special issue in memoriam to<br />

A. Renyi, 34:127–140, 1998.<br />

J. Demetrovics, G. O. H. Katona, D. Miklós, <strong>and</strong> B. Thalheim. On the number of independent functional<br />

dependencies. In FoIKS, LNCS 3861, 83–91. Springer, 2006.<br />

J. Demetrovics, A. Molnar, <strong>and</strong> B. Thalheim. Graphical <strong>and</strong> spreadsheet reasoning for sets of functional<br />

dependencies. In ER’2004, LNCS 3255, 54–66, 2004.<br />

J. Demetrovics, A. Molnár, <strong>and</strong> B. Thalheim. Relationship <strong>design</strong> using spreadsheet reasoning for sets of<br />

functional dependencies. In ADBIS, LNCS 4152, 108–123. Springer, 2006.<br />

J. Demetrovics, A. Molnar, <strong>and</strong> B. Thalheim. Graphical axiomatisation of sets of functional dependencies<br />

in relational databases. In Alkalmazott Matematikai Lapok, volume 24, pages 223–264. 2007.<br />

A. Molnar, J. Demetrovics, <strong>and</strong> B. Thalheim. Graphical <strong>and</strong> spreadsheet reasoning for sets of functional<br />

dependencies. Technical Report 2004-2, Christian Albrechts University Kiel, Institute of Computer Science<br />

<strong>and</strong> Applied Mathematics, Kiel, 2004.<br />

A. Molnar <strong>and</strong> B. Thalheim. Conceptual development of OLAP applications. In Business Intelligence:<br />

Methods <strong>and</strong> Applications, pages 27 – 38. Klöden-Verlag, 2007.<br />

Editing: LNCS 305, 364, 495, 2582<br />

Information

logo

products

Resources

Company

Terms of service
Privacy policy
Cookie policy
Cookie settings
Imprint
Change language
Made with love in Switzerland
© 2024 Yumpu.com all rights reserved

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!