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 ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
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