Analysis, Design and Development of Information Systems ...

Prof. Dr. rer.nat.habil. Bernhard Thalheim 

Information Systems Engineering 

Institute of Computer Science 

Christian-Albrechts-University Kiel 

Olshausenstr. 40 

D - 24098 Kiel 

 

Skript zur Vorlesung 

Analysis, Design and Development of Information Systems 

& Modellierung von Informationssystemen 

& Web-Informationssysteme 

2. Strukturierung von IS ab SS 2012 

Sonderfarben der Seiten im Skript für zusätzliches Material. 

Forschung 

Hintergrundinformation (auch Inhalte der Grundvorlesungen) 

Zusatzliteratur und Lesestoff 

1 Einführung 

In den Vorlesungen werden vier zentrale Spezifikationssprachen zur Spezifikation von Informationssystemen im 

Co-Design-Zugang vorgestellt: die Strukturierung und die Funktionalität auf der Grundlage des erweiterten Entity- 

Relationship-Modellen HERM, die Verteilung auf der Grundlage der Verteilungsspezifikationsprache DistrLang und 

die Spezifikation durch die Web-Informationssystem-Spezifikationssprache SiteLang. 

Übungen: jeweils eine Übung zur Spezifikation der Strukturierung, zur Spezifikation der Funktionalität, zur Spezifikation 

der Medientypen und zur Spezifikation der Interaktivität. 

Es werden die Systeme ERWin und Silverrun, sowie DBMain zur Modellierung der Strukturierung bzw. Funktionalität 

eingesetzt. 

2 Strukturierung von Informationssystemen 

Strukturierung = Struktur + statische Integritätsbedingungen (+ Modellinhärentes !!!) 

HERM : higher-order entity-relationship model 

EER : extended ER model (meist auch nur für die Definition der Struktur(ierung) genutzt!!!) 

Bemerkung: Modell meint hier eigentlich Sprache. 

Brief Survey: The Higher-Order Entity-Relationship Model (HERM). 

The entity-relationship model has been extended by more than three-score proposals in the past. Some of the extensions contradict other 

extensions. Within this chapter we use the higher-order (or hierarchical) entity relationship model (HERM). It is a special case of an extended 

entity-relationship model (EER) e.g. [EWH85, Gog94, Hoh93, Tha00]. 

The higher-order ER model used in this chapter has the following basic and extended modeling constructs: 

Simple attributes: For a given set of domains there are defined attributes and their corresponding domains. 

Complex attributes: Using basic types, complex attributes can be defined by means of the tuple and the set constructors The tuple 

constructor is used to define complex attributes by Cartesian aggregation. The set constructor allow construction of a new complex 

attribute by set aggregation. Additionally, the bag, the list, and the variant constructors can be used.

CAU zu Kiel, IfI, ISE, β 2. Strukturierung von IS ab SS 2012 152 

Entities: Entity types are characterized by their attributes. Entity types have a set of attributes which serve to identify the elements of the 

class of the type. This concept is similar to the concept of key known for relational databases. 

Clusters: A disjoint union · 

∪ of types whose identification type is domain compatible is called a cluster. Cluster types (or variant types) are 

well known in programming languages, but are often overlooked in database models, where this absence creates needless fragmentation 

of the databases, confusing mixing of generalization and specialization and confusion over null values. 

First-order relationships: First-order relationship types are defined as associations between single entity types or clusters of entity 

types. They can also be characterized by attributes. 

Higher-order relationships: The relationship type of order i is defined as an association of relationship types of order less than i or of 

entity types and can also be characterized by attributes. 

Integrity constraints: A corresponding logical operator can be defined for each type. A set of logical formulas using this operator can 

define the integrity constraints which are valid for each instance of the type. 

Operations: Operations can be defined for each type. 

• The generic operations insert, delete, and update are defined for each type. 

• The algebra consists of classical set operations, such as union, intersection, difference and restricted complement, and general 

type operations, such as selection, map (particular examples of this operation are (tagged) nest, unnest, projection, renaming), 

and pump (particular examples of this operation are the classical aggregation functions). The fixpoint operator is not used. 

• Each type can have a set of (conditional) operations. 

• Based on the algebra, query forms and transactions can be specified. 

The extensions of the ER model should be safe in the sense that appropriate semantics exist. There is a large variety of proposals which are 

not safe. Some reasons for this include higher-order or function types, such as those used for the definition of derived attributes, or the loss of 

identification. 

It can be observed that higher-order functions can be attached to the type system. However, in this case types do not specify sets, although 

their semantics can be defined by topoi [Sch94, Gol06]. This possibility limits simplicity for the introduction of constraints and operations. 

Furthermore, these semantics are far too complex to be a candidate for semantics. The ER model is simpler than OO models. 

Es taucht oft die Frage auf, ob dies adäquat ist. In [HL07] wurde dazu ein Vergleich von englischen Sprachäußerungen 

und dem HERM vorgenommen. Eine der Tabellen dazu ist die folgende 

English sentence concept HERM feature 

transitive verb 

relationship type 

common noun 

component of relationship type 

adjective 

attribute of component 

adverb 

attribute of relationship type 

numerical expression attribute of object type 

preposition 

role name of component 

gerund 

relationship type that is component of another relationship type 

clause 

relationship type with components 

complex sentence relationship type of order higher than 1 

alternative phrase cluster type 

plural collection type/nested attribute 

“IsA” sentence 

specialisation 

Comparison to Chen’s original correspondences by [HL07] 

Peter P.-S. Chen: English Sentence Structure and ER Diagrams, Inf. Sci. 29(2-3): 127-149, 1983 

Mod IS IS ADD Web IS


English sentence ER feature 

concept 

transitive verb relationship type 

common noun entity type 

adjective 

attribute of entity type 

adverb 

attribute of relationship type 

numerical expression attribute of entity or relationship type 

gerund 

relationship-converted entity type 

clause 

high-level entity type abstracted from group of interconnected low-level entity and 

relationship types 

complex sentence one or more entity types connected by relationship type in which each entity type can 

be decomposed recursively into low-level entity types interconnected by relationship 

types 

Conclusions: 

EER reflects (English) sentence structures more soundly and naturally 

higher-order object types reflect dependence between sentences 

this provides justification for introduction of new ER features 

ER model does not just provide safe constructs that result in good database design, but also features that enable 

good communication between designer and user 

essential to best approximate requirements 

additional EER features justified in the sense that modelling becomes more natural 

provides also a justification why the EER features exist 

higher-order object types reminiscent of nested sentence structure in natural language text 

2.1 Spezifikation der Struktur von Datenbanken 

eine Vorlesung (da bereits in der Vorlesung Informationssystem in Grundzügen in abweichender Form behandelt) 

2.1.1 Modellierungsannahmen 

• Konstruktiver Aufbau mit kompositioneller Semantik 

damit dann auch induktive Sprache 

(inkrementelle Modellierung als resultierende Variante des Modellierens) 

Vorteil: die Semantik wird kompositional 

• Abstraktionsresistenz, Verfeinerungsstrategie (scaling depending on its modes (visibility (zoom), hierarchy 

(fold), manifestation (express, suppress))) 

Modularisierbarkeit als Option 

• Äquivalenzbegriff für Sprachkonstrukte 

• rigide Trennung von Klassen und Typen, aber 1-1-Bindung von Klassen an Typen 

• Abbildungseigenschaften 

• Wohlfundiertheit 

• Einschränkung auf Mengensemantik, keine Kollektionssemantik 

• Visualisierung 

• Skalierbarkeit/Modularisierbarkeit der Sprachäußerungen je nach Auffassungsmöglichkeiten 

Modularisierbarkeit als Option 

Modular modelling supports information abstraction and hiding by encouraging and facilitating the decomposition of systems [BM97] into components 



and their modular development based on a precise definition of interfaces and the collaboration of components through which the systems are put 

together. Implicit modularisation can be achieved by introduction of name spaces on signatures. Explicit modularisation offers a better understanding 

of structure and architecture of systems and thus supports consideration of evolution of systems and of collaboration of systems. 

Modularisation offers a number of advantages: separation of concerns, discovery of basic concepts, validation and verification of development, efficiency 

of tool support, and - last but not least - scoped changes. The last advantage of modularisation is based on an explicit framing of development to a number 

of elements while preserving all other elements in its current form. We model this impact by introducing name spaces on signatures. 

Typically, small submachines capture smaller models that are easier to understand and to refine. Small models can better be ascertained as to whether 

we need to apply refinements. 

Modularization is a specification technique of structuring large specifications into modules. It is classically based on structural and functional decomposition 

[BS00]. We additionally consider control decomposition. Modules form a lattice of associated submachines having their own states and their 

own control. 

Modularisation is based on implementation abstraction and on localization abstraction. Implementation abstraction selectively hides information about 

structures, semantics and the behavior of ASM concepts. Implementation abstraction is a generalization of encapsulation and scoping. It provides data 

independence through the implementation, allowing the private portion of a concept to be changed without affecting other concepts using that concept. 

Localization abstraction “factors out” repeating or shared patterns of concepts and functionality from individual concepts into a shared application 

environment. Naming is the basic mechanism for achieving localization. Parametrisation can be used for abstraction over partial object descriptions. 

We use the name space for handling localisation abstraction. 

• Agentorientierte Darstellung und damit Separation für verteilte Anwendungen 

A submachine consists of a vocabulary and a set of rules. In this case, any clustering of rules and of elements from the vocabulary may define a 

submachine. Turbo machines [BS03] capture our notion of a submachine by encapsulating elements of the vocabulary and rules into a machine. They 

hide the internals of subcomputations within a separate machine. The submachine has its own local state and its own interface. 

The set of functions of each submachine can be separated into basic and derived functions. Basic functions may be static functions or dynamic functions. 

Classically [BS03] dynamic functions can be classified as in(put) functions, out(put) functions, controlled or local functions that are hidden from the 

environment, and shared functions that are visible to the environment. A similar classification can also be applied to basic static functions. They are 

either functions only used by a its own machine or read by several environments. We thus extend the notion of shared and controlled functions to static 

functions as well. We do not use derived static functions since they can be considered as syntactic sugar. We differentiate these functions according to 

their role in Figure 1 which displays the functions internal for an agent machine. A similar classification can be developed for functions external to an 

agent. An agent machine consists of all functions that assigned to the agent and of rules that are assigned to the agent and that use only those functions 

assigned to the agent. 

function/relation/location 

basic 

derived 

static 

non-updatable 

by any agent 

controlled shared 

in (monitored) 

non-updatable 

by agent 

controlled 

updatable 

by agent 

dynamic 

shared (interaction) 

updatable 

by agent 

out 

updatable 

by agent 

indirectly 

monitored controlled indirectly indirectly 

shared 

Abbildung 1: The Kinds of Internal Functions for Agent Machines 

Static functions may also be local functions. They are not updated by any submachine. [BM97] distinguish derived function to whether these functions 

are monitored functions, controlled functions, or shared functions. Typically, derived functions are functions that do not exist on their own right, but 

may be dynamically computed from one or more base functions. They provide a powerful and flexible information hiding mechanism. Updates made 

in the base functions that affect the derived function are immediately reflected in derived functions. 

We may additionally assume that derived functions are allowed to update dynamic functions. In this case, dynamic functions may be used as a security 

mechanism, as an access mechanism, and as a simplification mechanism that allows to use complex derived functions in rules instead of complex 

computations in rules. 

• Perspektiven und Stile der Modellierung sind explizit wählbar 

Different modelling perspectives can be distinguished: 

1. The structure-oriented perspective focuses on structural description of the machine. Sometimes, the structure-oriented perspective is unified 

with the semantic perspective. In this case, design of the structure is combined with design of invariants. 

2. The behavior-oriented perspective is concerned with the behavior of the machine during its lifetime. It can be based on event approaches or on 

Petri-net approaches and predicate transition systems. 

3. The process-oriented perspective is concerned with the operation of the system. 



The structure-oriented perspective is often used for data-intensive applications. Almost all recognized database design approaches are based on the 

structure-oriented perspective. The process-oriented perspective uses approaches considered in software engineering. The behavior-oriented perspective 

is a high-level descriptive approach to an integrated specification of the vocabulary and rules. 

Modelling styles provide a very abstract description of a particular set of general characteristics of a model. Different constructional notations may be 

useful for describing a machine. We use the Turbo machine approach for component or submachine description. Typically, the role of the components 

of the system follow the rules specified by the style. The modelling style explains the structure, the abstraction and grouping of the elements. Parts of 

the system may follow different modelling styles. 

The style of modelling is a specification of the high level structure and organisation of system modelling. The structure describes the handling of 

elements of the vocabulary, the topology or relationships between elements, the semantical limitations for their usage, and the interaction mechanism 

between the elements such as blackboard, submodule calls,etc. The organisational style describes relevant local and global structures, the decomposition 

strategy, and control mechanisms between parts of the machine. The organisational style is based on the architectural style. It is our aim to maintain and 

to preserve the strategy over the life cycle of the system. 

The perspective and the style result in strategies that are use for step-wise development of specifications. The different strategies [Tha00] based on the 

structure-oriented perspective are sketched in Figure 2. 

structure-oriented strategies 

✙ 

flat 

second-order 

controlled 

(first-order) 

(uncontrolled) 

(one-dimensional) 

✠ ❘ ✠ ❘ 

mixed 

modular 

✠ 

❘ (skeleton-based flat) (design by modules) 

bottom-up 

1. design all 

basic concepts 

2. build more 

complex concepts 

from them 

top-down 1. design general 

module schema 

(bottom-up or top-down) 

1. design (skeleton) 

all main concepts 

2. refine concepts 

2. refine each module 

(bottom-up or 

top-down) 

1. design basic modules 

with interface 

2. (iteration step) 

connect modules 

or design 

combined modules 

Abbildung 2: Structure-Oriented Specification Strategies 

inside-out 

(by neighborhood) 

1. design central type 

2. (recursion step) 

design next level 

(bottom-up or 

top-down) 

design or attach 

concept 

• Integritätsbedingungen werden anhand von Mustern definiert und eingesetzt 

Invariants, e.g. integrity constraints in database applications, are used to define semantics of applications. We know different pattern for their specification: 

• Operational representation of invariants incorporates invariants into the programs or rules. The invariant enforcement mechanism may be hidden 

because of control conditions or to the specification of actions. 

• Descriptive representation uses explicit specification and refinement obligations. These descriptions are combined with the specification of 

invariant enforcement: 

• Eager enforcement maintains invariants based on a scheduling mechanism for maintenance of invariants. Transactional systems are typical 

scheduling mechanisms. They bind invariant enforcement to programs. 

• Lazy enforcement maintains invariants in a delayed mode. Inconsistency is temporarily tolerated. This tolerance reduces some of the cost 

of enforcing invariants within large structures. 

• Refusal enforcement maintains invariants by rollback of all activities since the last consistent state and by executing a subset of activities. 

Partially ordered runs are based on refusal enforcement. 

Depending on the pattern chosen invariant handling is varies. If we choose an implicit invariant handling then any change applied to the current ASM 

must explicitly consider all invariants and must be entirely aware of the effects of these. Therefore this pattern is the most inefficient for early design 

phases. This pattern is however applicable during implementation if later revision is going to be based on a more general ASM. 

The completeness of invariant specification is a dream that is never satisfied. Sets of invariants are inherently open since we cannot know all invariants 

valid in the current application, we cannot envision all possible changes in invariant sets, and we cannot choose the most appropriate selection of 

invariants from which all other invariants follow. Therefore, we use a separation into 

• hard (or iron) invariants that must be preserved and which are valid over a long time in the application and 

• soft invariants that can be preserved or are causing later corrections or which are not valid for a longer time in the application. 

• Modellierung im Local-As-View-Ansatz 

• Konzeptuelles Modell ist dann zugleich die globale Sicht 



• Lokale Sichten werden mit der Schema-Algebra über dem konzeptuellen Schema als abgeleitetes Konzept 

verwendet 

Damit (S, V 1 , ...., V k ) als Modell, das den Anspruch erfüllen könnte, kognitiv vollständig zu sein. 

Siehe Arbeit von B. Thalheim zur kognitiven Vollständigkeit der Modellierung mit einem erweiterten 

ER-Modell. 

• als klassischer Zugang 

Alternativ könnte auch der Global-As-View-Ansatz verwendet werden. 

• Damit wird eine natürlichere Form der Repräsentation gewählt. 

• Damit kann auch unterschiedliche Abstraktion und Granularität verwendet werden. 

• Kompromiß ist der sichtenzentrierte Entwurf. 

• ((V 1 , ..., V k ), Association Constraints) als Modell-Suite (siehe B. Thalheim, A. Dahanayake) 

• Man könnte hier den Komponenten-Zugang nach Thalheim/Hegner verwenden. 

Unterschiedliche HERM-Annahmen je nach Abstraktionsschicht 

• mit Identifikation 

• mit partiellen Constraintmengen (z.B. nur ein Schlüssel) 

• Schemavollständigkeitskriterium 

Pragmatische strikte Unterscheidung 

Wir unterscheiden in modernen Sprachen zwischen 

Einführung von Variablen, Daten, die damit auch Rechte an der Modifikation und am Auslöschen mit einschließt, 

Mitnutzung von Variablen, Daten, die immer eine entsprechende Koordination mit einschließt und 

Mitbenutzung von Variablen, Daten etc., die keine Rechte an Modifikation und Auslöschen einschließt! 

siehe auch Handbook, HERM-Kapitel 

Implicit Assumptions and Inherent Constraints of DB Specification Languages. 

Each language used should be based on a clear definition of structure, semantics, operations, behavior and environment. At the same time, 

languages presuppose implicit assumptions and constraints. The enhanced or extended ER (EER) model might, for instance, use the following 

assumptions: 

Set semantics: The default semantics of entity and relationship types are set semantics. If extended type constructors are used then their 

semantics are explicitly defined. 

Identifiability: Each entity type is identifiable. Each component type needs to be labelled whenever it cannot be distinguished from 

other components. In relationship types components are ordered. Their labels can be omitted whenever there is an identification. Set 

semantics implies identifiability of any element in the database. 

Partial Unique Name Assumption: Attribute names are unique for each entity and relationship type. Entity type names and relationship 

type names are unique for the ER-schema. 

Referential Integrity: If a type is based on component types then each value for this type can only use such values in components which 

exist as values in the component instance. 

Monotonicity of Semantics: If integrity constraints Φ are added to a given set of integrity constraints Σ, then the set of possible 

instances which satisfy the extended set of constraints Σ ∪ Φ is a subset of the set of instances which satisfy Σ. 

Resulting coincidence theorems as a matter of convenience. 



Storage and Representation Alternatives. 

The classical approach to objects is to store an object based on strong typing. Each real-life thing is thus represented by a number of 

objects which are either coupled by the object identifier or by specific maintenance procedures. This approach has led to the variety of types. 

Thus, we might consider two different approaches: 

Class-wise, strongly identification-based representation and storage: Things of reality may be represented by several 

objects. Such choice increases maintenance costs. For this reason, we couple things under consideration and objects in the database 

by an injective association. Since we may be not able to identify things by their value in the database due to the complexity of the 

identification mechanism in real life we introduce the notion of the object identifier (OID) in order to cope with identification without 

representing the complex real-life identification. Objects can be elements of several classes. In the early days of object-orientation it 

was assumed that objects belonged to one and only one class. This assumption has led to a number of migration problems which have 

not got any satisfying solution. The association among facets of the same thing that are represented by several objects is maintained by 

the object identifier. 

Object-wise representation and storage: Graph-based models which have been developed in order to simplify the object-oriented 

approaches [BT99] display objects by their sub-graphs, i.e. by the set of nodes associated to a certain object and the corresponding 

edges. This representation corresponds to the representation used in standardization. 

Object-wise storage has a high redundancy which must be maintained by the system thus decreasing performance to a significant extent. Beside 

the performance problems such systems also suffer from low scalability and poor utilization of resources. The operating of such systems leads 

to lock avalanches. Any modification of data requires a recursive lock of related objects. 

Therefore, objects-wise storage is applicable only under a number of restrictions: 

• The application is stable and the data structures and the supporting basic functions necessary for the application do not change during 

the lifespan of the system. 

• The data set is almost free of updates. Updates, insertions and deletions of data are only allowed in well-defined restricted ‘zones’ of 

the database. 

A typical application area for object-wise storage is archiving or information presentation systems. Both systems have an update system 

underneath. We call such systems play-out system. The data are stored in the way in which they are transferred to the user. The data 

modification system has a play-out generator that materializes all views necessary for the play-out system. 

Two implementation alternatives are already in use albeit more on an intuitive basis: 

Object-oriented approaches: Objects are decomposed into a set of related objects. Their association is maintained on the basis of 

OID’s or other explicit referencing mechanisms. The decomposed objects are stored in corresponding classes. 

XML-based approaches: The XML description allows to use null values without notification. If a value for an object does not exist, 

is not known, is not applicable or cannot be obtained etc. the XML schema does not use the tag corresponding to the attribute or the 

component. Classes are hidden. Thus, we have two storage alternatives for XML approaches which might be used at the same time or 

might be used separately: 

Class-separated snowflake representation: An object is stored in several classes. Each class has a partial view on the 

entire object. This view is associated with the structure of the class. 

Full-object representation: All data associated with the object are compiled into one object. The associations among the 

components of objects with other objects are based on pointers or references. 

We may use the first representation for our storage engine and the second representation for out input engine and our output engine 

in data warehouse approaches. The input of an object leads to a generation of a new OID and to a bulk insert into several classes. The 

output is based on views. 

The first representation leads to an object-relational storage approach which is based on the ER schema. Thus, we may apply translation 

techniques developed for ER schemata[Tha00]. 

The second representation is very useful if we want to represent an object with all its facets. For instance, an Address object may be 

presented with all its data, e.g., the geographical information, the contact information, the acquisition information etc. Another Address 

object is only instantiated by the geographical information. A third one has only contact information. We could represent these three 

object by XML files on the same DTD or XSchema. 

Grundlegende Strukturbeziehungen 

Modellierung muß ist auch eine Ingenieursdisziplin. Deshalb werden auch die Engineering-Annahmen des Einführungskapitels 

betrachtet. 

The four fundamental structural relations used for construction abstraction are: 



Aggregation/participation characterizing which object consists of which object or resp. which object is part of 

which object. 

Aggregation is based on constructors such as sets, lists, multisets, trees, graphs, products etc. It may include 

naming. 

Generalization/specialization characterizing which object generalizes which object or resp. which object specializes 

which object. 

Hierarchies may be defined through different classifications and taxonomies. So, we may have a different 

hierarchy for each point of view. 

Hierarchies are built based on inheritance assumptions. So, we may differentiate between generalization and 

specialization in dependence on whether characterization are not or are inherited and on whether transformation 

are or are not applicable. Qualifications may form their orthogonal hierarchy (e.g., Bachelorette for Female and 

Single and Bachelor for Male and sl Single). 

Exhibition/characterization specifying which object exhibits which object or resp. which object is characterized 

by which object. 

Exhibitions may be multi-valued depending of the data type used. They may be qualitative or quantitative. 

Classification/instantiation characterizing which object classifies which object or resp. which object is an instance 

of which object. 

Define/use separates definition of structures/types/objects from deployment of those. 

Modes of States. 

• Initial 

• Ultimate 

• Default 

Generalisation und Spezialisierung sind besser zu unterscheiden 

Aus der Enzyklopädie der Datenbanksysteme: Langfassung hier (in Enzyklopädie: Kurzfassung 

Specialisation and Generalisation. 

Definition 1 The generalisation and specialisation principles are main principles of database modelling. Generalisation maps or groups 

types or classes to more abstract or combined ones. It is used to combine common features, attributes, or methods. Specialisation is based on 

a refinement of types or classes to more specific ones. It allows to avoid null values and to hide details from non-authorised users. Typically, 

generalisations and specialisations form a hierarchy of types and classes. The more general types or classes may be bound by a mapping or by 

inheritance of attributes and methods from the more general one to the more special ones. Clusters of types to a type that represents common 

properties and abstractions from a type are the main kinds of generalisations. Is-A associations that specialise a type to a more specific one 

and Is-A-Role-Of associations that considers a specific behaviour of objects are the main kind of specialisations used in database modelling 

and implementation. 

Specialisation introduces a new entity type by adding specific properties belonging to that type which are different from the general 

properties of its generic type. Thus, generalisation introduces the Role-Of relationship or the Is-A relationship between a subtype and its 

generic type. Therefore, the constructs are different. For generalisation the generic type must be the union of its subtypes. Thus, the subtypes 

can be virtually clustered by the generic type. This tends not to be the case for specialisation. Specialisation is a refinement or restriction of 

a type to more special ones. Typical specialisations are Is-A and Has-Role associations. Exceptions can be modelled by specialisations. We 

distinguish different kinds of specialisation: 



Structural specialisation T ′ ≼ St T : The structure S ′ is a substructure of S. An embedding function η exists which relates each object in 

T ′ to one object in T . For instance, the tuple structure (A, B, C) is a substructure of (A, B). In addition, structural specialisation requires that 

according to η the class T ′C of the type T ′ is a subclass of T C , i.e., we require that for each o ′ ∈ T ′C an o ∈ T C exists such that o = η(o ′ ). 

The relationship among objects can be supported by identifiers or keys. In this case the subtype uses the identifier and keys and provides 

additional attributes and methods. 

Semantic specialisation T ′ ≼ Se T : The logical language of T ′ can be mapped onto the logical language of T in such a way that the 

constraints on T ′ are stronger than the constraints on T , i.e., a mapping θ from L T ′ to L T exists such that θ(Σ ′ s) |= Σ s . The constraints used 

in T ′ are stronger than those used in T . 

The constraint sets of types are partitioned into static constraints Σ s (applicable to elements of the type sets) and dynamic constraints Σ d 

(applicable to operations of the types). 

The strong semantic specialisation T ′ ≼ St,Se T is defined on the basis of both mappings η and θ whereas θ is created using η as the 

mapping primitive. 

Pragmatical specialisation T ′ ≼ P r T : Objects may be used in different contexts. Pragmatical specialisation allows to separate the 

different usage of objects in contexts. The identification of objects is not changed. Therefore pragmatical specialisation can be based on 

structural specialisation. We require that the additional properties of objects in T ′C represent the additional properties that context requires. 

Operational specialisation T ′ ≼ Op T : The operations defined for T can also be applied to T ′ objects. 

The strong operational specialisation T ′ ≼ St,Op T requires that mappings η : Struc ′ → Struc, θ : L T ′ → L T and ζ : Ops ′ → Ops 

exist which commute, i.e., for any n-ary operation o ′ from Ops and arbitrary objects o ′ 1, ..., o ′ n from T ′ t the equality η(o ′ (o ′ 1, ..., o ′ n)) = 

ζ(o ′ )(η(o ′ 1), ..., η(o ′ n)) and ζ(θ(Σ ′ d)) |= Σ d . 

Type specialisation T ′ ≼ T ype T requires strong operational and strong semantic specialisation. 

Is-A specialisation T ′ Is − A T requires structural and strong semantic specialisation. Is-A relationship (types) are typical semantical 

specialisations. We require that the properties of objects in T ′C specialise those in T C or are not applicable to T . 

Is-A-Role-Of specialisation T ′ Is − A − Role − Of T requires structural, pragmatical and strong semantic specialisation. We require that 

the additional properties of objects in T ′C represent the additional properties that context requires. 

Generalisation can be treated in a similar manner and is based either on abstraction or on grouping. The cluster construct of the 

extended ER model is used to represent generalisations. Generalisation tends to be an abstraction in which a more general (generic) type is 

defined by extracting common properties of one or more types while suppressing the differences between them. These types are subtypes 

of the generic type. New types are created by generalizing classes that already exist. Typical such feature abstractions are the separation or 

extraction of constructors, destructors, and identification from the rest of the type. Similarity of attributes or methods may be used for the 

development of more abstract ones. Grouping allows to combine types that partially share properties or methods into a new type that represents 

the commonalities. 

We thus consider structural combination, semantical combination, and pragmatical combinations of types into a more general one. 

Structural combination typically assumes the existence of a unifiable identification of all types. Typically unambiguity is assumed, i.e. the 

combination is based on a disjoint union of the types. Semantical combination allows the disjunction of types through the linear sum of 

semantics. Pragmatical generalisation is based on building collections whenever applications require a consideration of commonalties. 

Abstraction is the opposite of refinement. In this case, generalisation can been seen as the inverse of specialisation. The main difference is 

however which of the types has a practical relevance or importance. Kernel types can be generalised to more general types by abstraction from 

some attributes or methods, by consideration of generic methods with parameters that are mapped to the kernel type methods by instantiating 

parameters or by introduction of more general attributes. 

Generalisation and specialisation are supported by inheritance of properties and methods. It helps to factor out shared specifications 

and implementations. Type inheritance is defined on the basis of the definition of types and can be further partitioned into aggregation/decomposition 

inheritance, classification/instantiation inheritance and generalisation/specialisation inheritance. Localisation inheritance is 

based on localisation abstraction. Naming, parametrisation and binding are basic mechanisms to extract repeating or shared patterns. Implementation 

inheritance is concerned with the encapsulation and hiding of types. A typical kind of implementation inheritance is that of the 

operational environment of a type. Interface inheritance or view inheritance can cause some confusion since these can reverse other inheritance 

approaches, e.g. inclusion inheritance. Object-oriented databases allow four different kinds of inheritance: Substitution inheritance, inclusion 

inheritance, constraint inheritance, and specialisation inheritance, 

Specialisation and generalisation are based on the concept of refinement. We may use refinement steps such as refinement through instantiation 

replacing types by partially instantiated, refinement through separation using decomposition operators enabling in vertical or horizontal 

decomposition, refinement through specialisation specializing types to structurally, behaviorally or semantically more specific subtypes, and 

refinement through structural extension extending types by other components, additional semantical constraints or functions. 

B. Thalheim. Entity-relationship modeling – Foundations of database technology. Springer, Berlin, 2000. 

J. H. Ter Bekke. Semantic data modelling. Prentice-Hall, London, 1992. 

J. C. Mitchell. Type systems for programming languages. In J. Van Leeuwen, editor, Handbook of Theoretical Computer Science, 

Vol. B - Formal Models and Semantics, pages 365–458. Elsevier, Amsterdam, 1990. 



Modellierungsstil im HERM 

Aus den Annahmen heraus können wir uns einen spezifischen Modellierungsstil leisten: 

Mengensemantik als präferierte Semantik obwohl auch eine Listensemantik oder eine Referenzsemantik nicht ausgeschlossen 

ist 

Modularisierung innerhalb der Spezifikation als eine strukturelle Separation von Aspekten 

Bevorzugung der struktur-orientierten Spezifikation gegenüber der prozeß-orientierten Spezifikation 

Inhärente Unvollständigkeit der Spezifikation wird toleriert. 

Agenten-orientierte Spezifikation für verteilte Anwendungen mit expliziter Separation der Einheiten des gesamten 

Namensraumes der Modelle in 

• Input-Einheiten 

• Sharing-Einheiten 

• Control-Einheiten und 

• Output-Einheiten 

IS als Transaktionssysteme mit resultierender Steuerung und Ableitbarkeit von Informationen aus Daten 

anstatt eines prozeduralen Systemes 

Resultierende Annahmen. 

• Grunddatentypen werden als unstrukturiert vorausgesetzt 

in OLAP-Anwendungen ist dies nicht mehr aufrecht zu erhalten!!!!!! 

• Pragmatik der Typeneindeutigkeit für jede Einheit 

z.B. Typen sind entweder Attribut- oder ... Cluster-Typen 

• Eine linguistische Semantik der Namen für Einheiten kann verwendet werden. 

Es wird dazu ein Stil der Benennung im Vornherein vereinbart und dann eingehalten. 

Wir verwenden damit für alle Namen eine Minisemantik. 

• Es wird eine Pragmatik für die Repräsentation zugelassen und vorher vereinbart. 

• Wir unterscheiden explizit zwischen Rolle und Objektexistenz. 

Kern-Objekte sind in der Existenz unabhängig und werden durch Entity-Typen dargestellt. 

An object is a thing that has the potential of stable, unconditional physical or mental existence. 

Existence is derived from ‘be’, ‘have being’, ‘continue to be’. Existence means to stand out, to show 

itself, and have a identifiable, distinct uniqueness with the physical or mental realm.(D.Dori, Websters 

dictionary) 

2.2 HERM-Strukturen 

Abstrakter Datentyp mit allen Eigenschaften der Grunddatentypen 



Finiteness Granularity Expression 

Textual Symbolic Numeric 

Finite Discrete Text-enumerated Symbol-enumerated Integer-enumerated 

Continuous - Symbol-floating-enumerated Floating-enumerated 

Infinite Discrete - - Integer 

Continuous - - Floating-point 

Eine Sprache zur Beschreibung der Strukturierung von Datenbank-Anwendungen verfügt über Konstrukte zur 

Darstellung der Struktur einer Anwendung. Falls diese Sprache nicht-zyklisch und induktiv aufgebaut ist, ist damit 

auch eine Einbettung in die Sprache der Prädikatenlogik (der ersten Stufe) gegeben. Deshalb lassen sich dann statische 

Integritätsbedingungen als Formeln der Prädikatenlogik mit einer Standardinterpretation angeben. Mit der 

Sprachkonstruktion und mit Annahmen aus dem Umfeld werden implizite Integritätsbedingungen aufgenommen. Die 

Sprache zur Beschreibung der Strukturierung von Datenbanksystemen wird genutzt, um diese mit einem sogenannten 

Datenbank-Schema zu beschreiben. Inhalte eines statischen Modelles sind daher: 

Strukturen einer Anwendung, 

Statische Integritätsbedingungen einer Anwendung (meist für die zusätzliche Beschränkung evt. in einer Anwendung 

vorkommender Daten) und 

Common-sense-Annahmen (über das Modell, die Modellierungsart, über die Interpretation der Daten etc.). 

Damit wird das Wissen über die statischen Gesichtspunkte einer Anwendung modelliert durch: 

Die Spezifikation der Struktur in Abhängigkeit vom Typensystem mit der Spezifikation des Seienden (entity), der 

Beziehungen (relationship) und der Eigenschaften (Attribute). 

Dinge stehen in Beziehung bzw. besitzen Eigenschaften, die klassifiziert werden durch eine Rolle oder durch 

Klassenbildung. 

Die Gesamtheit der Dinge wird unter Berücksichtigung der Beziehungen untereinander modelliert: 

• Aussonderung (Separation/Spezialisierung), 

• Verallgemeinerung (Generalisierung von Gemeinsamkeiten) und 

• Aggregation (zur Darstellung komplexerer Daten mit entsprechenden Operationen). 

Die Spezifikation der statischen Semantik, d.h. durch einschränkende Bedingungen für wirklichkeitsgetreue Nachbildung 

der Anwendung wie 

• die eindeutige Bestimmung aller Objekte durch Schlüsselbedingungen, 

• die Hierarchie der Objekte (Aussonderungsbedingungen (specialization, IsA), Verallgemeinerungsbedingungen 

(partition constraints, uniqueness constraints)) 

• und Bedingungen für Beziehungsklassen wie die folgenden: 

• Darstellung eines funktionalen Zusammenhangs (viele-eins-Bedingung), 

• Bedingungen zur Assoziation mit Komponentenobjekten (Seinsbedingung (existence constraint)) 

und 

• Verweisbedingungen auf Objekte der Komponentenklassen, 

sowie 

• allgemeine Bedingungen (inhärente Bedingungen des Modells) wie die folgenden: 

• Gesamtheitsregel (universe of discourse) 

• Verneinungsregel 



Sichten und abgeleitete Begriffe sind erschließbare Objekte und werden durch Anwendung von Spezifikationen aus 

den Objekten der Datenbank erzeugt. 

Das allgemeine Vorgehen der statischen Datenbankmodellierungssprachen läßt sich somit wie folgt charakterisieren: 

• Typen sind über ihre Typausdrücke definiert. Den (freien) Variablen werden wiederum Typen zugeordnet. 

• Die Zuordnungsvorschrift für Typausdrücke kann sowohl hierarchisch als auch zyklisch sein. Wählt man 

eine zyklische Struktur, dann sind meist nur Topoi-Semantiken geeignet. Wählt man hierarchische 

Strukturen, dann kann meist eine Mengensemantik noch garantiert werden. 

• Typen haben eine assoziierte statische Semantik. 

• Typen haben Operationen zu ihrer Manipulation und Veränderung. Man kann diese Operationen generisch 

definieren, wenn die Typenstruktur hierarchisch aufgebaut ist. Einige Operationen können auch Prädikate 

sein. 

A type constructor is a function from types to a new type. The constructor can be supplemented 

• with a selector for retrieval (like Select) with a retrieval expression and update functions (like Insert, 

Delete, and Update) for value mapping from the new type to the component types or to the new type, 

• with correctness criteria and rules for validation, 

• with default rules, 

• with one or several user representations, and 

• with a physical representation or properties of the physical representation. 

• Klassen sind Typen zugeordnet. 

• Sie stellen “Container” für die Objekte des jeweiligen Typs dar. 

• Die assoziierte statische Semantik der Typen muß zu jedem Zeitpunkt für eine Klasse erfüllt sein. 

• Die Operationen der Typen werden auf Klassen ausgeführt. 

Wir bezeichnen Typen mit ihrem Namen, z.B. T und die zugehörigen Klassen mit einer Annotation zum Typennamen, 

z.B. T C (C steht für Klasse). 

Es sind verschiedene Modelle möglich. Jedes Modell ist durch eine Menge von inhärenten Bedingungen gekennzeichnet. 

Jeder benutzte Typ hat neben Konstruktor, Selektoren (für Retrieval) und Updatefunktionen, Korrektheitskriterien, 

default-Regeln auch eine Benutzerrepräsentation und eine physische Repräsentation. 

Günstig ist eine graphische Repräsentation. 

Eines der populärsten Modelle ist das Entity-Relationship-Modell. Wir erweitern dieses Modell zu einem 

Higher-Order Entity-Relationship-Modell (HERM). 

2.2.1 Attribut-Typen 

können einfache oder auf der Grundlage von Konstruktoren wie Mengenkonstruktor, Tupelkonstruktor, Listenkonstruktor, 

Multimengenkonstruktor induktiv konstruierte komplexe Attribut-Typen sein. Sie werden induktiv definiert: 

Basis-Datentypen sind parametrisierte Typen T = (dom(T ), ops(T ), pred(T )) des DBMS. Sie sind gegeben 

durch eine Bezeichnung T (evt. auch mit Abkürzung), einen Wertebereich dom(T ), eine Menge von Funktionen 

ops(T ) und eine Menge pred(T ) von Prädikaten. 

Oft wird auch der Basis-Datentyp mit einem Informationstyp assoziiert. 

Ein Beispiel ist der Typ der ganzen Zahlen in der 4-Byte-Repräsentation 



integer := (IntegerSet 4Byte , {0, s, +, -, *, ÷, }, { =, ≤ }) mit der Nachfolgefunktion s . 

Basis-Datentypen verfügen neben dem Wertebereich auch über Funktionen und Prädikate. Sie sind außerdem 

durch eine Reihe von Eigenschaften eingeschränkt, die im Datenbanksystem zu beachten sind und oft im Entwurf 

übersehen werden: 

• Die Präzision und Genauigkeit sind ggf. für Typen wie REAL eingeschränkt. 

• Die Granularität von Daten kann sehr unterschiedlich sein. Die Skalierung von Datentypen kann sich 

ggf. auch auf die Funktionalität auswirken. 

• Datentypen verfügen nur ggf. über eine eigene Ordnungsbeziehung. 

• Datentypen verfügen ggf. über eine Klassifikation innerhalb der Daten des Wertebereiches. Diese Klassifikation 

kann einfach oder mehrfach hierarchisch, analytisch oder synthetisch, monothetisch oder polythetisch 

und ein- oder mehrdimensional sein. 

• Datentypen können über unterschiedliche Präsentationsformen verfügen. Das Format umfaßt Länge und 

Größe. 

• Datentypen können auf unterschiedliche Art abgespeichert werden. 

• Datentypen verfügen über eigenständige Default- und Nullwerte. 

• Datentypen können durch Casting-Funktionen aufeinander abgebildet werden. 

• Datentypen sind bestimmten Anwendungen und Arbeitsgebieten zugeordnet. 

• Die Funktionen und Prädikate lassen unterschiedliche Berechnungen zu, die sich auf die Erfassung, Berechnung, 

Algorithmen etc. auswirken. 

• Bestimmte Funktionen, wie z.B. der Durchschnitt, sind evt. anders oder gar nicht definiert. 

• Datentypen sind oft mit Maßeinheiten ausgewiesen, womit auch Berechnungen unterlegt werden müssen. 

Basis-Datentypen sind meist auch in einem Typenverband geordnet. 

Neben den Basis-Datentypen des DBMS kann auch eine Anwendung über eigene Basis-Datentypen verfügen. 

Wir können z.B. den Typ varnumbersequence20 zur Darstellung von Telefonnummern mit einer angepaßten 

Ordnungsbeziehung und ohne Unterdrückung führender Nullen einführen. Analog kann ein Typ EmailTyp oder 

URL eingeführt werden. 

Kind of data type Natural order Natural zero Predefined functions Example 

extension based 

absolute + +/- +/- number of boxes 

ratio + +/- +(type dependent) length, weight 

intension based 

nominal - - (-) (except concatenation) names of cities 

ordinal + - - preferences 

rang + + - competitions 

interval + - (+)(e.g., concatenation) time, space 

Tabelle 1: Data types and their main canonical assumptions 

Attribut-Typen werden über einem Basis-Datentypen-System und einem Markierungssystem L für Attributnamen 

induktiv ausschließlich durch die folgenden beiden Regeln definiert: 

• Ein Attribut-Typ ist für eine Markierung A und einen Basis-Datentyp durch einen Ausdruck A :: T 

gegeben. Der Wertebereich dom(A) des Attribut-Typs ist der Wertebereich des Basis-Datentyps. Der 

Wertebereich des leeren Datentyps λ besteht aus ⊥. 



• Sind X 1 , ..., X n , Y Attribut-Typen und A, B, C, D Markierungen, dann sind A(X 1 , ..., X n ) (Tupel- oder 

Produkt-Konstruktor), A{Y } (Mengen-Konstruktor), A < Y > (Listenkonstruktur), A[Y ] (Konstruktor 

für optionale Elemente), A{| Y |} (Konstruktor für Multimengen). 

Die entsprechenden Wertebereiche sind durch Anwendung der Konstruktion gegeben, z.B. 

dom(A(X 1 , ..., X n )) = dom(X 1 ) × ... × dom(X n ) und dom(A{Y }) = 2 dom(Y ) . 

Markierungen können auch weggelassen werden. 

Beispiele von komplexeren Attributen sind 

Name (Vornamen, 

Familienname :: varstring30, [Geburtsname :: varstring30,] 

[Titel:{AkademischeTitel :: varstring10 } ∪ · 

FamilienTitel :: varstring10]) 

Kontakt (Tel({dienstl :: varnumbersequence20 }, privat :: varnumbersequence20), 

email :: emailType, ...) 

Geburtsdatum :: date . 

Attribute können in einer verkürzten Notation verwendet werden, wenn dies eindeutig im Schema bleibt. Das Attribut 

Kontakt ist z.B. dann auch ohne seine Bestandteile verwendbar. 

Attribute sind hierarchisch strukturiert wie - im Falle des Namens einer Person - der Baum in Bild 3 zeigt. Diese 

Name 

❄ 

( ... ) 

✾ 

Vornamen 

❄ 

< ... > 

❄ 

( ... ) 

✮ 

 

Vorname Benutzung 

❄ 

string1 

❄ 

varstring15 

✠ 

Familienname 

❄ 

varstring30 

3 

[ ... ] 

❄ 

Geburtsname 

❄ 

varstring30 

✾ 

{ ... } 

❄ 

AkademischeTitel 

❄ 

varstring10 

3 [ ... ] 

❄ 

Titel 

❄· 

∪ 

3 

Familientitel 

❄ 

varstring10 

Abbildung 3: Semi-strukturiertes Attribut Name 

hierarchische Struktur ermöglicht auch Elemente auszuzeichnen, z.B. mit der Eigenschaft Element eines Schlüssels 

zu sein. So kann z.B. zum Schlüssel das Teilattribut 

Name (Vornamen, Familienname, [Geburtsname ]) 

hinzugenommen werden, wobei wir als Abkürzungsregel benutzen, daß mit dem Nennen eines Bezeichners auch der 

damit verbundene Teilbaum mit übernommen wird, z.B. für Vornamen auch die gesamte Teilstruktur Vornamen . 

Kontrollfrage: Ist richtig Plz:String oder Plz:Number ? 

2.2.2 HERM-Typen 

werden induktiv aufeinander basierend definiert. 

Grundlagen aus der Theorie der Informationssysteme 

Wir unterscheiden zwischen der formalen Definition und der graphischen Repräsentation. Die graphische Darstellung kann unterschiedlichen 

Paradigmen folgen. 



Begründung: Da die Werkzeuge zum Datenbank-Entwurf meist einschränkend sind bei der graphischen Darstellung, sollte man sich hier die unterschiedlichen 

Darstellungsformen erschließen und parallel benutzen. 

Allgemeiner Definitionsrahmen für Typen: für korrekte Separation wird verwendet 

• T ⊜ (compon T ; identif T ; integrity T ) 

Die drei Elemente eines Typen (compon T ; identif T ; integrity T ) können als Folge definiert werden, 

wenn man die Separation durch das Semikolon benutzt. 

• Wird eine Folge verwendet, dann kann auch die Reihenfolge der Elemente für die Annotation verwendet 

werden. 

• Oft wird anstatt ⊜ auch einfach das Gleichheitszeichen verwendet. Dies ist eine Form der Bezeichnungsökonomie, 

hat aber nichts mit der mathematischen Gleichhet zu tun. 

• alternativ aber weniger korrekt T ⊜ (compon T , identif T , integrity T ) 

Verwendung von Marken ist für alle Typen zugelassen. 

I.a. wird dazu die Form Marke:Bezeichner gewählt. Dies erlaubt dann auch die Marke als Abkürzung 

oder alias zu verwenden. 

Unique-Name-Assumption für alle Bezeichner des Schemas, d.h. alle Entity-, Relationship- und Cluster-Typen, 

sowie für Komponenten der Typen selbst. Ansonsten wird eine Marke notwendig. 

Alternativen in der Darstellung 

Wir verwenden - wo immer es möglich ist - das Kartesische Produkt als Typenkonstruktoren. 

Begründung: Die Darstellung im Stile der funktionalen Programmierung mit Funktionen hat sich nicht bewährt und wurde in den 1980ern verworfen. 

Entity-Typ: Eine Seiendenklasse (Objektklasse) (Entity-Klasse im weiteren) wird durch einen Entity-Typ dargestellt. 

Ein Entity-Typ besteht aus einer nichtleeren Folge von Attributen und einer Menge von statischen Integritätsbedingungen. 

Der Primärschlüssel wird direkt durch Unterstreichen der Attribute angegeben. Ist die Menge der 

statischen Integritätsbedingungen leer, dann kann sie auch weggelassen werden. Eine Klasse von der Struktur 

des Entity-Typs ist gültig, falls alle Integritätsbedingungen gelten. Wir folgen der klassischen Notation, bei 

der ein Entity-Typ mit einer Definitionsgleichung dargestellt wird. Zum Beispiel ist ein Person-Typ spezifiziert 

durch 

Person ⊜ (Name, Adresse, Kontakt, GebDatum, PersNr : StudNr ∪ · 

MitarNr, ..., ∅) 

mit einer Folge von Attributen. Markierungen sind als solche ausgewiesen. 

Ein Entity-Typ wird durch ein Rechteck graphisch repräsentiert. 

Eine Entity-Klasse besteht aus einer Menge von Objekten vom Entity-Typ, die die statischen Integritätsbedingungen 

des Entity-Typen erfüllt. 

Hier verwendete Annahmen: 

Wir definieren die Klasse als eine Menge. Multimengen-Semantik wird z.B. im relationalen Modell für Anfragen verwendet. Dort ist die 

Multimenge relativ einfach beherrschbar. Wird dagegen ein paralleler Zugriff für unterschiedliche Benutzer erlaubt, dann muß ein explizites 

Konzept des sharing eingeführt werden. 

Begründung: Kollaboration kann über das 3C-Modell (siehe meine Publikationen) definiert werden. Der sehr komplexe und zugleich sehr schwer zu 

realiserende Teil des 3C-Modelles ist die Koordination. Man kann hier Verträge von Benutzern verwenden. Eine Spezifikation von Anwendungen wird 

dabei allerdings viel zu komplex. 

Zum Beispiel ist das folgende Objekt mit dem Identifikator β 

β: ((, Thalheim, {Prof., Dr.rer.nat.habil., Dipl.-Math.}), 

BTU Cottbus, (({ +49 355 692700, +49 355 692397}, +49 355 824054), 



thalheim@informatik.tu-cottbus.de), 10.3.52, 637861) 

vom Entity-Typ Person, wobei mit ‘z’ der Zusatzname und mit ‘r’ der Rufname bezeichnet wird. 

Darstellung im Diagramm durch ein Rechteck mit dem Namen des Typen als Bezeichner und ggf. den Attributen 

als Annotationen am Rechteck. 

Alternativ kann man auch die UML-artige Notation verwenden mit einer Liste der Attribute innerhalb 

eines Rechteckes. 

Unterschied zur Vorlesung Informationssysteme (4. Semester) 

Im Diagramm nutzen wir einen Typen mit annotierten Attributen. Man könnte auch noch Kreise um die Attribute ziehen. 

Begründung: Dies ist aber unnötigt. Die Diagramme werden unübersichtlicher. 

Hier verwendete Annahmen: 

Ein Entity-Typ hat mindestens eine Komponente, die Sinn in der Anwendung macht. 

Begründung: Künstliche, vom System erzeugte Identifikation macht für einen Anwender weder Sinn für das Retrieval noch für die Modifikation. Sie 

ist ein bequemes und zugleich sehr mächtiges Instrument der Implementation. 


Wir verwenden nur eine interne Identifikation über Komponenten des Entity-Typs. Schwache Entity-Typen sind nicht zugelassen. 

Begründung: Im Buch [Tha00] wird ausführlich begründet, warum schwache Typen zu schlechten Schemata führen, in eigenartiger Semantik 

resultieren und auch mit dem higher-order Relationship-Typ vollständig überflüssig sind. 


Wir vermeiden eine ständige Einführung eines Identifiers. Diese Attribut sollte bei der konzeptionellen Modellierung nur dann 

eingeführt werden, wenn dies erforderlich ist. 

Begründung: Der Identifier ist ein logisches Konzept. Ansonsten erfordert er eine Extra-Verwaltung, die ein Schema verschlimmbessert. 

Hinzu kommt der Albtraum, den wir für objekt-orientierte Schemata in aller Problematik kennenlernen mußten. 


Konzeptionelle Modellierung orientiert sich an echten, in der Anwendungswelt sinnvollen Konzepten. Künstliche, der Implementation geschuldete 

Konstrukte sind strikt zu vermeiden, wenn man den Benutzer nicht verwirren oder von der Anwendung fernhalten möchte. 

Begründung: Die Theorie der relationalen Datenbanken hat sich stark an den ersten Systemrealisierungen orientiert und dabei die dort erfolgten Annahmen 

einfach als ‘gottgegeben’ akzeptiert. Solche Annahmen sind meist nicht mehr hinnterfragt worden. Sie bedürfen jedoch einer Revision unter 

modernen Gegebenheiten. 


Die Identifikation kann über minimale Schlüssel definiert werden. Es ist hier nicht nur der Primärschlüssel von Interesse, sondern auch weitere 

Schlüssel, die in einer Anwendung Sinn machen. 

Begründung: Man betrachte einmal den Typ Lehrstuhl, der sowohl über den Namen (mit ggf. Zusätzen) als auch die Kostenstelle als auch den Raum 

oder andere Kantaktformen identifizierbar ist, wobei die spezifische Identifikation für unterschiedliche Assoziationen dann auch benötigt wird. 

Einfacher Relationship-Typ: Ein Relationship-Typ (erster Ordnung) besteht aus einer nicht-leeren Folge von Entity- 

Typen, einer Menge von Attributen und einer Menge von statischen Integritätsbedingungen. Eine Menge von 

der Struktur des Relationship-Typen ist eine gültige Menge, wenn sie den statischen Integritätsbedingungen 

genügt. Elemente können markiert sein. 

Ein Beispiel sind die Relationship-Typen 

InGruppe = (Person, Gruppe, { Zeit(Von [,Bis]), Funktion }, ∅ ) 



DirektVoraussetz = (setztVoraus: Kurs, vorausges : Kurs, ∅, ∅ ) 

Professor = (Person, { Berufungsgebiet }, ∅ ) . 

Ein Relationship-Typ wird mit einer Raute graphisch repräsentiert. Wir erlauben auch optionale Komponenten 

von Relationship-Typen, solange eine Identifikation über die obligatorischen Elemente definiert ist. 


Eine alternative Form ist die IDEF-Notation, bei der Relationship-Typen mit Rechtecken, die abgerundete Ecken haben, verwendet werden. Diese 

Form erlaubt auch eine einfache Umformung von Entity-Typen zu Relationship-Typen oder auch die Objektifizierung von Relationship-Typen. 

Begründung: Es wird oft argumentiert, daß die IDEF-Darstellung die natürlichere Form sei. Sie wird auch von fast allen Werkzeugen unterstützt. In 

der Forschungsliteratur hat sich jedoch die ursprüngliche Form durchgesetzt. Dem folgt auch die Lehrbuchliteratur. Ein survey der DAMA zeigt jedoch, 

daß diese Form in der Praxis weit verbreitet ist. Die Verbreitung hat sich nicht mit UML geändert, die auch sowohl die Raute als auch das abgerundete 

Rechteck erlaubt. 

Ein Objekt eines Relationship-Typs ist ein Tupel, das zu den jeweiligen Elementen auf die entsprechenden Objekte 

der Klasse der Elemente durch Angabe von identifizierenden Werten (Identifikator bzw. Primärschlüssel 

bzw. anderer Schlüssel) verweist und Werte für die Attribute des Relationship-Typs besitzt. 

Eine Relationship-Klasse besteht aus Objekten des Relationship-Typs, die den statischen Integritätsbedingungen 

genügen. 

z.B. sind Objekte der Typen Professor, InGruppe und DirektVoraussetz 

Profβ: ( 637861, Datenbank- und Informationssysteme ) 

Senator3β: ( 637861, Senat, (1995,1998), Dekan) 

Senator5β: ( 637861, Senat, (2000), Vorsitzender) 

VorausDBIVHaupt: (DBIV, DBI) . 

Cluster-Typ Eine disjunkte Vereinigung von bereits konstruierten Typen wird als Cluster-Typ bezeichnet. Ein Cluster- 

Typ wird mit einem ⊕ -Zeichen graphisch repräsentiert. 

Beispiele sind durch folgende Typen gegeben: 

JuristischePerson = Person ∪ · 

Betrieb ∪ · 

Vereinigung 

Gruppe = Senat ∪ · 

Arbeitsgruppe ∪ · 

Vereinigung, 

die den Typ JuristischePerson bzw. Gruppe als disjunkte Vereinigung von anderen Typen einführen. 

Cluster-Typen können weitere Attribute besitzen. In diesem Fall wird der Cluster-Typ durch eine Raute mit den 

Attributen repräsentiert. 

Objekte von Cluster-Typen sind analog zu den Objekten anderer Typen durch entsprechende Zuordnung zu den 

Element-Typen eingeführt. So können z.B. die Objekte β, LIM, CottbusNet e.V. juristische Personen sein. 


Cluster-Typen werden oft nicht zugelassen, so daß dann für alle Typen eine Mixvererbung geführt werden muß. 

Begründung: Die Generalisierung ist i.a. nicht die Umkehrung der Spezialisierung. Neben der Mixvererbung sind auch die virtuelle und partielle Vererbung 

von Interesse und deshalb nicht von vornherein auszuschließen. 

¨ 

Uber die Nutzung der disjunkten Vereinigung hinaus kann auch der Cluster-Konstrukt für alle algebraischen Operationen genutzt werden. 

Ein Beispiel aus dem Titelbild der 7. Auflage des Buches von A. Kemper/ A. Eickler dazu: 

The following three schemata are equivalent to each other and are tightly associated with each other by transformation mappings. A typical example of these two schemata is given in 

Figure 4. Students enrolled in a course may be examined by docents that give the course. 

The optimised conceptual schema can be easily mapped to a structure that supports smooth operating of the database. The sophisticated HERM schema uses the Θ-join for the correct 

building of the relationship type that records downloads. The optimised conceptual schema is equivalent to this schema due to the equivalence of the join decomposition and the inclusion 



Examines.Enrolls.Course 

= Examines.GivenBy.Course 

Θ := Enrolls.Course ✶ P rovides.Course 

Course ✛ GivenBy ✲ 

Docent 

Course ✛ GivenBy ✲ 

Docent 

✻ 

✻ 

✻ 

✻ 

Enrolls 

✛ 

Examines 

Enrolls 

✛ 

Θ 

Examines 

❄ 

❄ 

Student 

Student 

The simple HERM schema 

The sophisticated HERM schema 

The representational conceptual schema 

Student = ({ StudId, ... }, ...), 

Course = ({ CourseID,... }, ...), 

Docent = ({ DocentID,... }, ...), 

Enrolls ✲ Course ✛ GivenBy Enrolls = ({ StudId, CourseID,... }, ...), 

Provides = ({ CourseID, DocentID,... }, ...), 

Examines = ({ StudId, DocentID, CourseID,... }, ...) 

⊇ ✻ ⊆ 

Examines[StudId, CourseID] 

❄ 

❄ 

⊆ Enrolls[StudId, CourseID] 

Student ✛ Examines ✲ Docent Examines[CourseID, DocentID] 

⊆ Provides[CourseID, DocentID] 

The “optimized” conceptual schema 

The logical relational schema 

The association between the “optimised” schema and the relational schema 

Abbildung 4: The ‘Janus’ schema cluster for conceptual modelling 

constraints [Tha00]. 


Relationship-Typen werden im Stile der funktionalen Programmierung als Funktion des Namen auf die Rollen der Komponenten 

eingeführt. Ggf. sind auch Attribute erlaubt. 

Begründung: Es ist damit eine Defintion der Rollen unbedingt erforderlich. Rollen sind jedoch eine spezifische Form der Spezialisierung 

für die Komponenten und sollten nur dort verwendet werden, wo dies erforderlich ist. 

Relationship-Typ höherer Ordnung: Ein Relationship-Typ i-ter Ordnung besteht aus einer nicht-leeren Folge von 

Entity- und Relationship-Typen einer Ordnung von maximal (i-1), wobei ein Typ (i-1)-ter Ordnung sein muß, 

einer Menge von Attributen und einer Menge von statischen Integritätsbedingungen. Eine Menge von der 

Struktur des Relationship-Typen ist eine gültige Menge, wenn sie den statischen Integritätsbedingungen genügt. 

Eine Identifikation kann sowohl aus den Elementen bestehen als auch aus den Attributen. 


Es wird oft für Relationship-Typen höherer Ordnung der Zugang der Objektifizierung genutzt. Dieser Zugang ist äquivalent zu 

dem hier genutzten. Er führt jedoch ein weiteres Element im Diagramm ein. Es wird um die Raute ein Rechteck gezogen, so daß 

ein weiteres Element entsteht. 

Begründung: Man sollte im Diagramm Konstrukte so sparsam wie möglich verwenden. Alles andere verwirrt nur. Hinzu kommt als 

Fehler- und Verwirrungsproblem das genaue Anbringen der Attribute an den Typen. Attribute gehören dann wohl eher zum ursprünglichen 

Typ und nicht zum objektifiziertem Typ. 

Dieser Zugang erlaubt keine Einführung von Clustern. 


Besonders unübersichtlich wird die Objektifizierung über Teilschemata z.B. für einen Relationship-Typen mit seinen Komponenten. 



Begründung: Man verliert sich sehr schnell in solchen Diagrammen. 

Mit der expliziten Einführung von Typen höherer Ordnung werden objektifizierte Typen überflüssig! 

Es ist mitunter vorteilhaft, über Relationship-Typen höherer Ordnung zu verfügen, wie Bild 5 zeigt. Im oberen 

Student’ 

✻ 

✶ 

✯ 

Professor’ 

eingeschr. 

in 

Vorlesung 

☛ ✾ 

Semester 

✰ 

Raum 

 

❄ 

Kurs 

✛ 

✛ 

Direkt- 

Voraussetz 

Student’ 

✻ 

✯ 

Professor’ 

eingeschr. 

in 

✲ 

Vorlesung 

✾ 

Semester 

✰ 

Raum 

❄ 

Kurs 

✛ 

✛ 

Direkt- 

Voraussetz 

Abbildung 5: HERM Diagramme mit und ohne Relationship-Typen höherer Ordnung 

Diagramm muß eine zusätzliche Integritätsbedingung zwischen den Typen eingeschriebenIn und Vorlesung 

gelten, weil man sich nur dann einschreiben kann, wenn diese Vorlesung existiert. 

Ein etwas komplexeres Beispiel ist das Beispiel in Bild 6. Eine Lehrveranstaltung, z.B. eine Vorlesung, wird 

durch einen Lehrstuhl angeboten. Dieses Angebot kann angenommen werden. Dann wird die Lehrveranstaltung 

geplant. Wird sie auch gehalten, dann werden die aktuellen Daten in der Klasse zum Typ GehalteneLehrveranst 

gespeichert. Der Typus und die Raumzuordnung können sich vom Vorschlag zum Plan und für den Raum 

vom Plan zu den gehaltenen Lehrveranstaltungen ändern. Ein Vorschlag für eine Lehrveranstaltung wird durch 

Berechtigte eingetragen. Eine Person ist für die Lehrveranstaltung verantwortlich. Eine Lehrveranstaltung kann 

für mehrere Studiengänge angeboten werden. 

Wir wollen hier nicht die vollständige Entfaltung von Objekten zu Typen höherer Ordnung fordern. Deshalb 

erbt ein Relationship-Typ höherer Ordnung nur die Identifikation seiner Elemente oder - wenn wir an einer 

vollständigen Wertedarstellung interessiert sind - nur die identifizierenden Werte der Objekte seiner Komponenten. 

So können z.B. Objekte vom Typ geplanteLehrveranstaltung in Bild 6 auch nur auf Objekte verweisen, 

die Kurs, Semester, Professor bezeichnen, wenn wir voraussetzen, daß ein Schlüssel des Typs angeboteneVorlesung 

aus Kurs, Semester, Professor besteht. 



Kurs Semester Professor ✲ 

✯ 

❦ 

✻ 

✒ 

Dozent 

Person 

✶ 

eingetragen 

Verantwortlicher4LV 

Studiengang 

{} 

✛ angebotene Wunsch 

Vorlesung 

Zeit(Vorschlag, 

Vorschlag ✻ Nebenbeding) 

✲ 

✯ 

✻ 

Raum 

Typus 

✰ 

✛ 

geplante ✛ 

Lehrveranst 

Zeitrahmen 

gehaltene 

Lehrveranst 

Abbildung 6: HERM Diagramm zu unserem Hauptbeispiel 

Ein Objekt vom Typ 

angeboteneVorlesung = (Kurs, Semester, Studiengänge, 

Professor, eingetragen, Verantwortlicher4LV, Raumwunsch, Typus, { Zeit }, ∅) ist z.B. 

VorlesungDBIVSS02: (DBIV, SS2002, { Informatik, IMT }, 

637861, KK, 637861, SR1, Vorlesung/Übung/Praktikum 2+2+2, Mo. 1.DS) . 

Generalisierung versus Spezialisierung: Ein Cluster-Typ erlaubt die explizite Darstellung einer Generalisierung. 

Ein unärer Relationship-Typ stellt dagegen eine Spezialisierung dar, wenn der Relationship-Typ bzw. Entity- 

Typ als sein Element diesen identifiziert. Rollen werden oft durch einen generischen Typ mit der Bezeichnung 

IsA dargestellt. Da die relationalen Schemata auch ohne diesen Typ auskommen, bevorzugen wir die Darstellung 

als Rolle mit unären Relationship-Typen oder ggf. auch mehrstelligen Relationship-Typen, falls die Rolle 

durch eine Beziehung zu anderen Typen ausgezeichnet ist. Damit sind wir in der Lage, zwischen Generalisierung 

und Spezialisierung zu unterscheiden. 

Rollen, die exklusiv bzw. hierarchisch sind, lassen sich auch anstelle einer HERM-Rautenstruktur durch hierarchische 

Strukturen abbilden, wie in Bild 7 dargestellt. Welche Darstellungsform gewählt wird, hängt vom erforderlichen 

Detaillierungsgrad ab. Sollen Attribute mit dargestellt werden, wird das hierarchische ER-Modell 

sehr schnell zu unübersichtlich. In den ersten Abstraktionsschichten stellt es aber eine gute Alternative zum 

HERM-Diagramm zum. 

Person 

Student 

Diplomand 

Diplomand 

✲ 

Student 

✲ 

Person 

Universitätsmitarbeiter 

Professor 

Projektmitarbeiter 

Projektmitarbeiter 

✻ 

✲Universitäts-✛ 

mitarbeiter 


Abbildung 7: Hierarchisches ER-Diagramm versus HERM Diagramm 



Aggregation: Wir können die Konstruktion von Relationship-Typen zu einer allgemeinen Aggregationskonstruktion 

erweitern, indem wir weitere Konstruktoren zulassen: 

• Vereinigung, 

• Mengenbildung, 

• Aggregation durch Beziehungsklasse und 

• Abstraktion durch Komponentenbildung. 

Klassen werden mit der hochgestellten Annotation ‘C’ und dem Typnamen bezeichnet. Z.B. sind Person C und 

InGruppe C Klassen entsprechenden Typs. 

IsA-Beziehungen können auf sehr unterschiedliche Art repräsentiert werden, ebenso wie unterschiedliche Schemata letztendlich das gleiche 

darstellen können. 

Three different styles are depicted in Figure 8. We prefer the compact style in the left diagram. 

Person 

Person 

Person 

✻ 

✻ 

✻ 



IsA 


Abbildung 8: Variants for Representation of Unary Relationship Types 

IsA-Typen: 

hier wurde partielle, nicht disjunkte Darstellung über Teiltypen bevorzugt, denkbar sind jedoch verschiedene Typen: 

1. partiell, nicht disjunkt; 

dieser Fall wird als der typische Fall angenommen (keine weiteren semantischen Informationen) 

Im HERM darstellbar über unäre Teiltypen. 

Person ⊇ Professor ∪ Mitarbeiter ∪ Student 

E ⊇ E 1 ∪ ... ∪ E n 

2. partiell, disjunkt 

die Teiltypen erfüllen eine Exklusionsbeschränkung 

Person ⊇ Professor ∪ Student 

E = E 1 ∪ ... ∪ E n 

3. total, nicht disjunkt 

E = E 1 ∪ ... ∪ E n 

Projektmitarbeiter = Professor ∪ Mitarbeiter ∪ Student 

4. total, disjunkt 

E = E 1 ∪ ... ∪ E n 

Studenten = StudImVordiplom ∪ StudImHauptstudium ∪ Diplomand 

Weiterhin kann auch für die Spezialisierung mit Partitionsbedingung eine analoge Strukturierung betrachtet werden (wird auch in den 

meisten Büchern ‘vergessen’): 

1. partiell, nicht disjunkt 

E ⊆ E 1 ∪ ... ∪ E n 

Teilnehmer ⊆ Vortragender ∪ Organisator ∪ NormalerTeilnehmer 

2. partiell, disjunkt 

E ⊆ E 1 ∪ ... ∪ E n 

Literatur ⊆ Buch ∪ Preprint ∪ Zeitschrift 

3. total siehe oben Generalisierung ≠ (Spezialisierung) −1 

E = E 1 ∪ ... ∪ E n 



Gewöhnlich wird in der Literatur nur versimplifizierend die IsA-Beziehung als strukturelle Beziehung betrachtet. Richtig ist aber die IsA- 

Beziehung im vollen Typeninhalt zu betrachten: 

Typ = Struktur + Operationen + Semantik 

In diesem Fall wird die Richtung der Vererbung bekanntgegeben. 

Damit dann besser modellierbar: 

• Vererbung von Eigenschaften von Teiltyp nach Supertyp 

• Vererbung von Eigenschaften von Supertyp nach Teiltyp (als Weiterbenutzung, Wiederverwendung) 

• Operationen des Teiltyps sind operationale Spezialisierung der Operationen des Supertyps (wenn im supertyp definiert) 

• Semantik des Teiltyps (eingeschränkt auf im Supertyp darstellbares) folgt aus Semantik des Supertyps 


Oft wird mit dem IsA-Typen eine Mixvererbung verbunden. Das Liskov-Substitutions-Prinzip (Methoden, die Zeiger oder Referenzen 

auf Basisklassen benutzen, müssen in der Lage sein, Objekte von abgeleiteten Klassen zu benutzen, ohne es zu bemerken! 

Es ist eine andere Formulierung von totalem Polymorphismus. Wenn es für jedes Objekt O 1 vom Typ S ein Objekt O 2 vom Typ T 

gibt, so daß sich für alle Programme definiert in T das Verhalten nicht ändert, wenn O 2 durch O 1 ersetzt wird: Dann ist S eine 

Subtyp von T .) bei der Vererbung ist nur dann erforderlich, wenn die Objekte wie in Java oder UML zugleich um alle Attribute 

des Supertypen im Subtypen angereichert werden. 

Begründung: Die Vererbung von Beziehungen des Supertypen erfolgt im Schema ohnehin aufgrund der Integritätsbedingungen. Die automatische 

Anreicherung um alle Attribute des Supertypen bringt eine erhöhte Redundanz an Werten, die zudem noch gepflegt werden müssen. 


Abstraktionskonzepte, die in der Informatik entwickelt worden sind: 

• Spezialisierung und Generalisierung: Objekte sind (entgegen der üblichen Salami-Slice-Modellierung) selbst strukturiert und können in 

spezielle Rollen oder auch in Zusammenfassungen wirksam gemacht werden. 

• Dekomposition: Das ist das Prinzip der Trennung einer Abstraktion in ihre Komponenten. 

• Instantiierung: Dies wird im zusammenhang mit der Erstellung von Instanzen einer Klasse angewandt. 

• Individualisierung: Ähnliche Objekte werden für gemeinsamme Zwecke zusammengefaßt. 

Begründung: Abstraktion dient der Verkürzung und sollte nicht mit anderen Methoden verwechselt werden. 


Vererbung, Polymorphie, abstrakte Klassen, Klassenhierarchien und dynamische Binding sind in der objektorientierten Programmierung in einer 

spezifischen Form verwendet worden. Sie sind i.a. viel breiter als in der spezifischen dort verwendeten Form. 

Begründung: Die Grundlagen von Vererbung, Polymorphie, Objektidentifikation, Prototypen, Generizität etc. sind noch nicht ausreichend verstanden und 

erforscht. So wird z.B. in einer Subtypenbeziehung eine (unselige) Diskussion zur Kovarianz und Kontravarianz geführt, wobei man eigentlich das Subtypenkonzept 

meint. 

Statische Integritätsbedingungen: Die Semantikspezifikationssprache umfaßt Schlüssel und Integritätsbedingungen, 

wie funktionale Abhängigkeiten, Exklusions- und Inklusionsabhängigkeiten, mehrwertige Abhängigkeiten, Viele- 

Eins-Bedingungen, Seinsbedingungen (Existenzbeziehung), Verweisbedingungen, Teiltypenbedingungen und Regeln, 

wie z.B. die Gesamtheitsregel, die Verneinungsregel und die Sichtregeln, sowie vor allem Komplexitätsbedingungen 

(Kardinalitätbedingungen) zur Spezifikation der Beziehung zwischen einem Relationship-Typen und seinen 

Komponenten. 

Unterscheidung (s.o.) von 

Generalisierung von Typen zur Zusammenfassung gleichartiger Beziehungen, gleichartigen Verhaltens 

Spezialisierung von Typen mit Einführung zusätzlicher Charakteristiken (Attribute) und zur Spezialisierung des 

Verhaltens 

u.a. auch 



• Auszeichnung von Rollen 

• Darstellung von Zusatzeigenschaften, ggf. auch optionaler Eigenschaften 

• Darstellung von Teiltypen 

Unterschiede von Generalisierung Spezialisierung 

... ... 

Beispiel: Verantwortlichkeit 

tbd 

Mehrdimensionale Modellierung 

Im Schema in Bild 9 beobachten wir mehrere Dimensionen, die relativ unabhängig voneinander betrachtet werden 

können: 

• Gegenstandsdimension, z.B. Partei, Person, Position und Organisation 

• Klassifikationen, hierarchische und andere Untergliederungen 

• Organisationsmodelle 

• Bedienungsmodelle und deren Komponenten, z.B. Verantwortlichkeit, Verantwortlichkeitsbereich 

Kind of 

business 

✛ 

Business 

hierarchy 

Range 

Protocol 

type 

■ 

✒ 

✻ 

Product 

type ❨ 

Responsibility 

Amount range 

Quantity ■ 

Position ❦ 

Person 

✛ 

Resource 

type 

is of type 

✠ 

Party ✛server 

Responsibility 

⊕ ✛ client 

✲ 

Party 

hierarchy 

❄ ❄ 

Party 

type 

✻ ✻server 

client 

✲Responsibility 

type 

✲Responsibility 

contract 

Product 

hierarchy 

Rule 

❄ 

❄ 

✲ Kind ✛ 

of hierarchy Hierarchy ✲ Organization 

✻ ✻ 

✛ 

son 

father 

Organization 

based on ✲ ✛ 

type Structure 

✒ 

❄ 

Time 

slot 

❄ 

Responsibility✛ 

hierarchy 

✻ 

Hierarchical 

hierarchy 

Layered 

hierarchy 

Abbildung 9: A generic model of responsiblities 

Theorie und Technologie der mehrdimensionalen Schema-Architekturen: Siehe R. Noack, B. Thalheim, EJC 2013 !!! 

2.2.3 Nullwerte sind keine Werte sondern Marken 

• state of the art: wide utilisation of misinterpretation of NULLs, wrong implementation support, confusing logics 

• null marker logics 



C.J. Date (Logic and Databases - The roots of relational theory (2007), 117): “I apologize for the wording “contains a null”; as I’ve written 

elsewhere, to talk about anything “containing a null” actually makes no logical sense. Indeed one of the problems with nulls is precisely that 

you ca‘’t talk about them sensibly! ... the entire topic is a perfect illustration of The Principle of Incoherence ... ” 

(228): “... nulls are ipso facto nonsense ... 

E.F. Codd (The Relational Model for Data Management, Version 2 (1990), 172): The basic principle of the relational approach to missing 

information is that of recording the fact that a db-value is missing by means of a mark (originally called a null or null value). There is nothing 

imprecise about a mark: a db-value is either present or absent in a column of a relation in the database. 

(197) ... the way the relational model deals with missing values appears to be one of its least understood part. 

Chris J. Date’s Arguments 

• We need a proof that in particular situations NULL’s can’t never give wrong answers. CJD has already shown that in generally NULL’s can result 

in wrong answers. NULL’s can give wrong answers and at the same time correct answers. 

• Three-valued logics does not solve the NULL value problem. 

• NULL’s are mixing predicates and appear due to bad modelling techniques. 

• The introduction of NULL’s destroys strong typing in the relational database model. 

• Approaches that are better: default (or better special) values for representation of the situation (CJ Date), Hugh Darween 

(the third gen. manifesto), David Mc Govern (Relational DB writing) 

Siehe Vorlesung Datenbankprogrammierung: Der Albtraum der Nullwerte-Programmierung. 

Siehe Habilitationsschrift von H.-J. Klein mit fünfwertiger Logik. 

Lösung: Siehe K.-D. Schewe, B. Thalheim, EJC 2010!!! 

Modelling Advices 

• NOT NULL - wherever applicable 

• NULLs need additional implementation effort, e.g. an extra bit 

• NULLs require specific storage formats, indexes, search support 

in any case better: DEFAULT 

• Usage of conventions, e.g. ISO for gender 

0 - unknown; 1 - male; 2 - female; 9 - not applicable 

• Special support for arithmetic functions: explicit assignment (unknown, not applicable (-1, ..., nonsense ... 0) 

• NULLs are also used if domain types do not support special values extend the domain type 

A Simplified But Almost Real Application 

CREATE TABLE Student ( 

MatriculationNo CHAR(6) could be NULL 

StudNo CHAR(6) our internalisation 

MainProgram VARCHAR(20) could be NULL, 

could be more than one 

Name VARCHAR(50) far too simple 

SecondaryProgram VARCHAR(20) might be more than one 

PRIMARY KEY 

(StudNo) 

FOREIGN KEY (MainProgram) 

REFERENCES ProgramAtCAU (ProgName) 

ON DELETE RESTRICT 

... ); 

CREATE TABLE Enroll ( 

StudNo CHAR(6) our internalisation 

Course 

CHAR(8) 

Term 

VarCHAR(7) 

EnrollmentCondition VARCHAR(10) 

Grade VARCHAR(3) 

full of beans 

that is a devils invention 

PRIMARY KEY (StudNo, Course, Term) 

... ); 



Diploma student 

Certificate Diploma 

Graded Certificate Diploma 

Bachelor & Master 

Guest Student 

During course 

After course 

Special condition 

never 

exists 

never 

exists 

not yet 

decided 

not yet 

decided unknown unknown 

not 

exists known known 

not 

exists 

under 

change 

under 

change 

not 

applicable 

not 

applicable 

potentially 

known 

14 (or 20) Kinds of NULL ‘Values’ in Databases 

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

1.1. Independently from the point of time t. “not applicable” 

1.2. At the current point of time t. “currently not applicable” 

2. The property does not belong to the object. 

2.1. The property is not representable in the schema. 

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

2.2. The property is representable in the schema. 

2.2.1. But there is no value for the object. “unknown” 

2.2.1.1. Because it has not been transferred from another database. 

2.2.1.2. Because is has not yet inserted into the database. “existential null” 

2.2.2. The value for the property exists but is “under change”. 

2.2.2.1. However the value is trackable. 

2.2.2.1.1. But is at the moment forbidden. 

2.2.2.1.2. At the moment permitted. 

2.2.2.1.2.1. But not defined for the database. 

2.2.2.1.2.1.1. Because it is currently under change. 

2.2.2.1.2.2. The value is defined for the system. 

2.2.2.1.2.2.1. But is currently incorrect. 

2.2.2.1.2.2. But is currently doubtful. 

2. The property does not belong to the object. 

2.2. The property is representable in the schema. 

2.2.2. The value for the property exists but is “under change”. 

2.2.2.2. The value is not trackable. 

2.2.2.2.1. Because of changes. 

2.2.2.2.2. Because of reachability. “place-holder null” 

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

(2.2.3.1., 2.2.3.2.1, 2.2.3.2.2. similarly to 2.2.2.) “nondeterministic” 

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

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

3. The property is may-be applicable for this object but it unknown whether it is true for the object in this case. “may-be null” 

3.1. It is not known whether the property is applicable to the given object. If it is applicable then its value for this property is 

taken from certain domain. 

“partial may-be null” 

Who can reason with this variety? 



2.3 Statische Integritätsbedingungen 

At present we know at least five application fields of database constraints theory: 

(1) normalization for a more efficient storage, search and modification; 

(2) reduction of relations to subsets with the same information together with the semantic constraints; 

(3) utilization of dependencies for deriving new relations from basic relations in the view concept or in so-called deductive 

databases; 

(4) verification of dependencies for a more powerful and user-friendly, nearly natural language design of databases; 

(5) transformation of queries into more efficient search strategies. 

A large number of structural and dynamical database constraints have been introduced in the past. We must however acknowledge 

that a fully fledged theory of database constraints is not yet existing. 

Separation of Integrity Constraints by Their Use and Usage. 

There are several classifications for integrity constraints: 

• either utilization characteristics are used for classification into domain constraints, key and functional dependencies, referential integrity 

constraints, join dependencies etc. 

• or their specific format of the formulas is used for classification into tuple-generating dependencies, equality-generating dependencies, 

existence constraints, single-table constraints, singleton-tuple constraints, etc. 

These characterizations are useful whenever constraints are formally defined. Their practical utility is, however, more restricted. Another 

characterization approach has been used in [Tha00] by relating constraints to the phase of database modelling into design, structural, semantic 

and representational constraints. We may combine the three approaches by clustering constraints according to their structural properties into 

• constraints expressing identification or partial identification of values by other values, 

• constraints stating relative independence of values in a class or within an object, 

• constraints stating existence (or non-existence) of values in an object, or values in groups of objects, or objects in a class, and 

• constraints expressing redundancy of values or objects. 

At the same time we may distinguish constraints according to their utilization in the design process. They might be meaningful at the level of 

the user, or at the level of the conceptual schema or at the level of the implementation. The following table shows this characterization. 

Partial identificatiocy 

Relative independence Existence dependency Redundancy dependen- 

Business 

user level 

identification structure no null elementary facts 

Conceptual 

level 

Implementation 

level 

functional, 

equality generating 

key, uniqueness, 

trigger, check 

multivalued, hierarchical, join 

dependencies, exclusion dependency, 

tuple generating, horizontal 

decomposition 

decomposition, stored procedures, 

trigger 

null-value-free, union 

constraints, numerical, 

cardinality constraint 

no null, stored procedures, 

trigger 

inclusion constraint, exclusion 

constraint 

referential integrity, surrogate, 

container 

Quality Criteria for Constraint Sets. 

Database systems aim in automatic support of quality. There are a number of quality criteria that have classically been considered in many 

textbooks and papers. Structural quality criteria are structural completeness, satisfiability of the schema, liveness of the database, applicability 

of automatic control features, explicit exception handling, applicability of operations, executability of operations and framing consistency 

procedures. The first three conditions are well discussed in the database literature. Automatically generated tests and control conditions are 

still an open research field. Operations are currently mainly applied based on the transaction approach, i.e., forcing a rollback after problems 

have been detected. Exception handling and execution control use the same approach. The framing or ramification problem is not yet solved. 

It requires a separation within a database into data that are not affected by a change and into data that are under potential change. A typical 

example of non-framed executions are trigger avalanches. 

Quality control must also consider the abstraction level of the stakeholder involved. Integrity constraints may be ambiguous or may be based 

on context or ellipses. We therefore need an explicit statement of the abstraction level. For instance, join dependencies are a specific vehicle 

for structuring the database. They are not used by the requirements engineer. There are however specification constraints at the requirements 

level that must be mapped to the internal levels. 

Optimisation of Behaviour Through Normalisation of Database Structuring. 

Normalisation has been developed as a vehicle for performance improvement of database systems. It addresses at least seven different targets: 

(A) Redundancy becomes problematic whenever additional actions are required for consistency management of data that are stored within 

different objects. 



(B) Blocking of management due to the information capacity of the schema. For instance, the insertion anomaly occurs since units of 

storage such as schema types do not support insertion of partial information. 

(C) Information loss after database modification occurs whenever data are eagerly deleted despite the importance of parts of it. The deletion 

anomaly is observed whenever facts are deleted together with the objects where they are contained despite its importance for the 

application. 

(D) Evolution sensitivity and instability of the database whenever changes are applied to the database. 

(E) Different abstractions are used for the database schema at the same time. For instance, views, derived attributes, logs are stored together 

with the basic data that are used to derive these values. 

(F) Performance problems can also be solved through restructuring. Typical performance problems considered are caused by integrity 

constraint maintenance. Update anomalies have been considered as a prominent example of a performance problem since singleton 

fact operations resulted in complex bulk operations. Performance problems are however also caused by architectures chosen for the 

application, by specific behaviour of the application, by retrieval requirements, by generation and maintenance of supporting structures 

such as indexes, etc. The last set of performance problems is often resolved by denormalisation, i.e., by intentional acceptance of another 

normalisation. Denormalisation may decrease complexity of retrieval and maintenance operations, may avoid additional join operations 

and may prepare special derived data for support of repeating computations. It allows us to consider semantically meaningful units 

instead of normalised structures. Index management is optimised. Denormalisation increases however complexity of some database 

operations, leads to redundancy problems, may result in inflexibility against evolutionary changes. 

(G) Expensive maintenance, operating and modification of databases often occurs due to consistency maintenance. Parallel execution of 

transactions may result in deadlocks. 

As far as we know there is not yet any theory that integrates the six targets of normalisation. Moreover, (A), (C) and (G) are considered to be 

the primary issues. 

2.3.1 Statische Integritätsbedingungen von HERM 

Statische Integritätsbedingungen werden als Formeln der hierarchischen Prädikatenlogik allgemein dargestellt. Wir verwenden 

jedoch die üblichen Kurzdarstellungen. 

Wir gehen davon aus, daß statische Integritätsbedingungen einer Interpretation mit einer “Normallogik” unterliegen. Mitunter 

wird auch im Entwurf eine Integritätsbedingung mit einer schwachen, deontischen Interpretation benutzt, bei der ihre Gültigkeit 

für die meisten Objekte einer Datenbank oder einer Klasse gefordert wird. Mitunter wird auch eine strikte Form der Interpretation 

genutzt, bei der z.B. obere bzw. untere Schranken für Kardinalitätsbeschränkungen auch durch entsprechende Objektmengen 

genau erfüllt sein müssen. 

Wir verwenden im weiteren folgende Klassen von Integritätsbedingungen: 

Schlüssel dienen der Darstellung der Identifizierbarkeit von Objektmengen, insbesondere in Entity-Klassen). Wir nehmen an, 

daß Entity-Klassen stets eigen-identifiziert sind, d.h. Mengen sind. Eine Teilmenge der Strukturelemente kann auch als 

Schlüssel dienen. Gewöhnlich hat jeder Typ mehr als einen Schlüssel. Deshalb verwenden wir von vornherein Schlüsselmengen. 

Der Primärschlüssel eines Entity-Typs wird direkt angegeben und kann in der Schlüsselmenge weggelassen 

werden. 

Wir nehmen z.B. für das Diagramm in Bild 6 folgende Schlüssel an: 

Key(Person) = { { PersNr }, { Name, Geburtsdatum } } 

Relationship-Typen haben ggf. auch eigene Attribute, die auch Bestandteile eines Schlüssels sind. 

Zum Beispiel nehmen wir für das obige Beispiel an, daß die Zeit essentiell für InGruppe ist, d.h. 

Key(InGruppe) = {{ Person, Gruppe, Zeit }} oder 

Key’(InGruppe) = {{ Person, Gruppe, Zeit, Funktion }} 

Weiterhin kann z.B. gelten 

Key(Vorlesung) = { {Kurs, Semester}, {Semester, Raum, Zeit}, {Semester, Dozent, Zeit} } 

Schlüssel folgen der Komponentenkonstruktion und können auch für einen Teil gelten, z.B. 

Name(Vornamen, FamName). 

Mindestens ein Schlüssel wird über die Komponente an den Relationship-Typen ‘vererbt’. 

Schlüsselvererbung aus den Komponenten heraus 

z.B. in Bild 28: 

• Projekt, Institution, Mitarbeiter, Labor besitzen ihre Schlüssel; jeweils einer davon kann ausgezeichnet sein 



• fördert leitet, arbeitet in, zugeordnet erben die Schlüssel der jeweiligen Elemente zur Identifikatioon der Relationships 

in den jeweiligen Relationship-Klassen 

• analog kann auch ein Relationship-Typ höherer Ordnung seine Identifikation durch die Identifikation der Komponenten 

beziehen 

• ggf. kann auch für einen Relationship-Typen gelten, daß einige seiner Attribute für die Identifikation mit herangezogen 

werden 


Es wird oft Schlüssel anstatt minimaler Schlüssel und Superschlüssel anstatt Schlüssel verwendet. 

Begründung: Dies entspricht der ursprünglichen Herangehensweise von E.F. Codd und seinen Nachfolgern. Sie ist jedoch veraltet. 


Leider existieren maximal (wobei diese Grenze exakt ist) 

( n 

⌊ n 2 ⌋ ) 

minimale Schlüssel für Typen mit n Komponenten. Diese Schätzung wird auch nicht besser im Falle von begrenzten Wertetypen, z.B. 

| dom(B i ) |≤ k (1 ≤ i ≤ n) für k 4 < 2n + 1 

( ) n 

⌊ n 2 ⌋ − ⌊ n 2 ⌋ 

Es besteht jedoch ein besseres Verhalten im mittleren Fall. Siehe Seleznev/Thalheim. 

Begründung: Siehe B. Thalheim: Dependencies in Relational Databases. Teubner, Leipzig, 1991. 

Funktionale Abhängigkeiten sind eine wichtige Gruppe von Abhängigkeiten. Eine funktionale Abhängigkeit R : X → 

Y ist für einen Typ R und Teilmengen X, Y seiner Elemente definiert. Sie gilt in einer Klasse R C , falls die Gleichheit 

von Objekten o, o ′ aus R C über X die Gleichheit über Y für o, o ′ impliziert. 

Funktionale Beziehungen von Attributgruppen in unserem Beispiel sind 

geplanteLV : {Semester, Zeitrahmen, Raum} → {{Studiengang}, Professor, Kurs} 

geplanteLV : {Professor, Semester, Zeitrahmen} → {Kurs, Raum} 

angeboteneLV: {Semester, Kurs} → {Professor} . 


maximum number N(n) of basic functional functional dependencies for types on n components 

( 

2 n 1 − 4 log ) ( ) 

2 log 2 n 

(1 + o(1)) ≤ N(n) ≤ 2 n 1 − log 3 2 

2 n 

log 2 e log 2 n 

150 √ n 

minimal generating sets of fd’s (n odd; n even (replace 1 1 

n 2 by 5 ) ) 

n 2 2 n 8 

( ) n 

⌊ n 2 ⌋ + 1 ( ) n 

n 2 (n+3) 

2 

( ) 

≤ M(n) ≤ 2 n 1 − log 3 2 

2 n 

150 √ n 

closed families of fd’s 

2 ( n 

⌊ n 2 ⌋ ) ≤ Cl(F, n) ≤ 2 

( n 

⌊ n 2 ⌋ )(1+o(1)) 

(J. Demetrovics, G.O.H. Katona, D. Miklos, β (1982-2006)) 

Begründung: Damit ist eine vollständige Spezifikation von allen notwendigen geltenden funktionalen Abhängigkeiten nicht möglich! 




rather than describing the entire set of basic functional dependencies use a Armstrong relations R C which allows to reason on the set of 

constraints 

size however 

( ) 

1 n 

n 2 ⌊ n 2 ⌋ 

≤ L {key} (n) ≤ 

( n 

⌊ n 2 ⌋ ) 

+ 1 

c 1 n k−1 

2 ≤ L {key(k)} (n) ≤ c 2 n k−1 

2 

( ) 

1 n 

n 2 ⌊ n 2 ⌋ 

≤ L F (n) ≤ 

(J. Demetrovics, G.O.H. Katona & other Hungarians, β (1982-2005)) 

Begründung: Armstrong-Relationen stellen also auch keinen Ausweg dar! 

( n 

⌊ n 2 ⌋ ) 

(1 + c 3 

√ n 

) 


Anstatt mit logischen Formeln zu rechnen, kann man auf die Boolesche Repräsentation von funktionalen Abhängigkeiten zurückgreifen. Diese 

kann auch für funktionale und mehrwertige Abhängigkeiten (sogar hierarchische Abhängigkeiten!!!) verwendet werden und ist um einiges einfacher 

als die klassische Kalkül-Ableitung. Auch Chase ist nicht einfacher. 

Begründung: Representable by Boolean functions: 

Represent A by p A 

X = {C 1 , ..., C k } by τ(X) = p C1 ∧ ... ∧ p Ck 

τ(X → Y ) = τ(X) → τ(Y ) 

τ(X →→ Y 1 | Y 2 | ... | Y m) = τ(X) →→ (τ(Y 1 ) ∨ τ(Y 2 ) ∨ ... ∨ τ(Y m)). 

{α 1 , ..., α k , β} functional and hierarchical dependencies 

{α 1 , ..., α k } |= β iff (τ(α 1 ) ∧ ... ∧ τ(α k )) → τ(β) = 1 

Kardinalitätsbeschränkungen werden als kombinatorische Beschränkungen in der (min,max)-Notation und der Partizipations- 

Semantik als Paar von Kardinalitäten verwendet. Damit unterscheidet sich unsere Notation von der Lookup-Semantik, die 

z.B. UML verwendet. Die letztere kann jedoch in einer n..m-Notation ebenso mitgeführt werden. Wir betrachten hierzu 

ein vereinfachtes Diagramm in Bild 10. 

(gehaltene) ✛ 

Vorlesung (1,n) 

setztVoraus ✻ 

(0,2) 

✻vorausgesetzt 

(3,4) 

3..4 0..2 

Voraussetzung 

0..2 

legtab ✲ 

(0,n) 

Resultat 

(0,n) 

❄ 

Student 

Ablageform 

Abbildung 10: Kardinalitätsbeschränkungen im Vorlesungsbeispiel 

Eine Kardinalitätsbeschränkung card(R, R i ) = (n, m) gilt in einer Klasse R C , falls jedes Objekt o i von R C i in 

R C mindestens n-mal und höchstens m-mal vorkommt. 

Eine Kardinalitätsbeschränkung card(R, R i ) = (n, 1) für R = (R 1 , ...., R n , attr(R)) ist äquivalent zur funktionalen 

Abhängigkeit R : R i −→ R 1 , ...., R i−1 , R i+1 , ..., R n . 

Eine Kardinalitätsbeschränkung card(R, R i ) = (1, m) für R = (R 1 , ...., R n , attr(R)) ist äquivalent zur Inklusionsabhängigkeit 

R : R i ⊆ π Ri (R). 

Eine Kardinalitätsbeschränkung in der Lookup-Notation look(R, R i ) = (n, m) gilt in einer Klasse R C mit k 

Elementen, falls zu jeder Kombination von Objekten o j von Rj 

C (j ≠ i, 1 ≤ j ≤ k) mindestens n und höchstens m 

entsprechende Objekte o i aus Ri 

C in der Klasse R C vorkommen. 

Im Fall binärer Relationship-Typen ohne Attribute, die zur Identifikation von Relationships herangezogen werden müssen, 

kann man damit einem Objekt o von R i mindestens n und höchstens m Objekte aus Rj 

C zuordnen, d.h. das Objekt sieht 

vermittels R C höchstens m und mindestens n Objekte aus der anderen Klasse. Wir erhalten damit das folgende Bild: 



C 

A 

✛ 

(a,b) 

c...d 

A with B 

(c,d) 

✲ 

a ...b 

A 


Diese Beziehung zwischen lookup und participation-Bedingungen gilt allerdings nicht, wenn die Attribute C bei der 

Identifikation des Relationship-Typen herangezogen werden!!! 

Eine Kardinalitätsbeschränkung look(R, R i ) = (n, 1) für R = (R 1 , ...., R n , attr(R)) ist äquivalent zur funktionalen 

Abhängigkeit R : R 1 , ...., R i−1 , R i+1 , ..., R n −→ R i . 

Eine Kardinalitätsbeschränkung look(R, R i ) = (1, m) für R = (R 1 , ...., R n , attr(R)) ist äquivalent zur verallgemeinerten 

Inklusionsabhängigkeit 

R : ∀o i ∈ R C i ∃(o 1 , ..., o i−1 , o i+1 , ..., o n ) ∈ π R1,....,R i−1,R i+1,...,R n 

(R C ) : 

(o 1 , ..., o i−1 , o i , o i+1 , ..., o n ) ∈ π R1 ,....,R i−1 ,R i ,R i+1 ,...,R n 

(R C ) . 

Sie kann auch durch R C i ⊆ π Ri ( R C i × π R1 ,....,R i−1 ,R i ,R i+1 ,...,R n 

(R C ) ) dargestellt werden. 

Manchmal wird sogar das Kartesische Produkt von R C 1 , ...., R C i−1 , RC i+1 , ..., RC n anstelle der Projektion verstanden. Diese 

Interpretation wurde z.B. UML unterlegt. 

Trotzdem sind Lookup-Abhängigkeiten auch von Nutzen. Man betrachte z.B. Bild 12. Die Lookup-Bedingung 

0..1 impliziert direkt ein Pivoting im Schema auf der rechten Seite, das relativ natürlich scheint. 

look(Angebot, ver 

Kurs 

✛ 

(a,b) 

Angebot 

0..1✲ 

verantwortl. 

Person 

Semester 

✻ 

Person 

✻ 

❄ 

Semester 

Kurs 

✛ 

Angebot 

✛ Verantwortlicher 

0..1 


0..1 

Wird dagegen auch noch card(Angebot, Kurs) = (0, 1) gesetzt, dann ergibt sich natürlich eine viel stärkere Dekomposition 

in Bild 13. 

Semester 

✛ 

Angebot ✲ Kurs ✛ Verantwortl. ✲ 

(0,1) (0,1) 

Person 


Die Lookup-Notation ist für binäre Relationship-Typen ohne eigene Attribute äquivalent zur Partizipation-Notation. Sie 

wird jedoch am anderen Element angetragen. Im Beispiel nehmen an, daß 

card(Voraussetzung, setztVoraus) = (0,2) 

look(Voraussetzung, setztVoraus) = 3..4 

card(Voraussetzung, vorausgesetzt) = (3,4) 

look(Voraussetzung, vorausgesetzt) = 0..2 

gilt. Damit haben wir äquivalente Formen. 

Für n-äre Relationship-Typen ohne eigene Attribute ist die Lookup-Notation look(R, R i ) = n..m äquivalent zur verallgemeinerten 

Kardinalitätsabhängigkeit card(R, R \ R i ) = (n, m) . 

In unserem Beispiel gilt z.B. die Einschränkung, daß erst dann ein Eintrag in die Klasse legtab geführt wird, wenn der 

Student eine Vorlesung erfolgreich abgelegt hat. 

Die Lookup-Bedingung look(legtab, Ablageform) = 0..2 stellt dar, daß nur Prüfung und Schein bzw. Schein und 



Praktikum bzw. Prüfung und Praktikum absolviert werden müssen. Diese Bedingung ist äquivalent zu 

card(legtab, Student Vorlesung) = (0,2). 

Eine Kardinalitätsbeschränkung card(R, R i ) = (0, 1) ist äquivalent zur funktionalen Abhängigkeit R : {R i } → R . 

Eine Lookup-Kardinalitätsbeschränkung look(R, R i ) = 0..1 ist äquivalent zur funktionalen Abhängigkeit R : 

R \ {R i } → R . 

Spannend ist das Zusammenwirken von card und look. 

Wir betrachten z.B. einmal einen Relationshiptypen in Bild 

Weiterhin können wir z.B. fordern, daß nur solche Vorlesungen als gehalten gelten, die auch zu studentischer Beteiligung 

geführt haben. Dies wird durch card(legtab, Vorlesung) = (1,n) dargestellt. 

Eine strengere Bedingung ist, daß dies auch für das Semester gelten muß. Dann können wir spezifizieren 

look(legtab, Student) = 1..n bzw. card(legtab, Vorlesung Semester) = (1,n). 

Für Relationship-Typen mit eigenen Attributen ist die Lookup-Notation in verschiedenen Formen definiert. 

(DBIV,SS2002,β) 

(DBI,WS2002,β) 

(Compiler,SS2002,PB) 

(Informatik III,WS2002,BvB) 

(Informatik III,WS2003,β) 

◦ 

◦ ◦ ◦ 

◦ 

◦ 

◦ 

◦ ◦ ◦ 

◦ 

◦ 

◦ 

◦ 

Schein 

Prüfung 

◦ Praktikum 

Antje Bärbel Cornell Doris Emil Fjodor 

Abbildung 14: Beziehungen der Objekte im Vorlesungsbeispiel 

Wir betrachten in diesem Beispiel in Bild 14 eine kleine Klasse mit 14 Objekten. Z.B. hat Bärbel sowohl die (Informatik 

III,WS2002,BvB) als auch (DBIV,SS2002,β) mit Prüfung und Schein abgelegt, Emil dagegen nur Scheine in (Informatik 

III,WS2002,BvB) und (DBI,WS2002,β). 

Kardinalitätsbeschränkungen sind mitunter nicht erfüllbar in nicht-leeren, endlichen Klassen. Ein Beispiel einer solchen 

nicht-erfüllbaren Menge von Integritätsbedingungen ist das Paar 


card(Voraussetzung, vorausgesetzt) = (3,4) . 

Wir können dies einfach nachvollziehen, indem wir eine endliche Menge von Vorlesungen z.B. {a, b, c, d, e} betrachten. 

Mit der Kardinalitätbeschränkung card(Voraussetzung, vorausgesetzt) = (3,4) kann man z.B. folgende Besetzung für 

Voraussetzung betrachten: 

{(a, b), (a, c), (a, d)} wird dann weiter fortgeführt zu {(a, b), (a, c), (a, d), (b, a), (b, c), (b, d)}. Damit kommen c, d in 

keiner Beziehung auf der rechten Seite mehr vor aufgrund von 

card(Voraussetzung, setztVoraus) = (0,2). Wir setzen also fort mit {(c, a), (c, b), (c, e)}. Nun sind auch a, b “verbraucht”. 

Dann haben wir bereits für d als linke Seite nicht genug Elemente auf der rechten Seite. Wir benötigen also noch f, g. 

Wir können nun weiter fortsetzen und erkennen, daß nur die leere und eine unendliche Menge von Vorlesungen diese 

Kardinalitätsbeschränkungen erfüllen. 

Dagegen ist 


card(Voraussetzung, vorausgesetzt) = (3,4) 

erfüllbar und impliziert 


card(Voraussetzung, vorausgesetzt) = (3,3) . 




The diagrams can also be labeled by cardinality constraints. It should be noted that there is little agreement [BDK92] between which edge labels 

to use and what they mean in ER diagrams. The classical notation (see the first five subfigures in Figure 15) is as follows for binary relationship 

types R = (E, F, attr(R)) (see for instance [EN89, Vos87]): 

The edge R −→ E is labeled 

by comp(R, F ) = (n, m) or by 1 if comp(R, F ) ∈ {(0, 1), (1, 1)} 

or by n if comp(R, F ) ∈ {(l, k)|l ∈ {0, 1}, l < k, k > 1}. 

The edge R −→ F is labeled 

by comp(R, E) = (n, m) or by 1 if comp(R, E) ∈ {(0, 1), (1, 1)} 

or by n if comp(R, E) ∈ {(l, k)|l ∈ {0, 1}, l < k, k > 1}. 

Begründung: Siehe HERM Buch! 

ER-designer 

E 

(0,1) 

R 

(1,m) 

F 

comp(R,E) 

E 

Classical proposal 

◦ 

M 

R 

F 

= 

(1,m) 

E 

◦ 

Teorey 

R 

F 

comp(R,F) 

= 

Everest 

(0,1) 

E 

◦ 

F 

Binary ER models 

E 

✛◦ 

✲ F 

Participation for relationship type 

E ✛ R ✲ 

(1,m) (0,1) 

F 

Abbildung 15: Lookup and Participation Representation 




Using the participation approach another labeling concept can be introduced. Assume a relationship type R = (R 1 , ..., R k , {A 1 , ..., A l }). 

For 1 ≤ j ≤ k, the edge R −→ R j can be labeled by comp(R, R j ) = (n, m) 

or by 1 if comp(R, R j ) ∈ {(0, 1), (1, 1)} 

or by n if comp(R, R j ) ∈ {(l, k)|l ∈ {0, 1}, l < k, k > 1}. 

For 1 ≤ j ≤ l, the edge R −→ A j can be labeled by dom(A j ). 

The difference between definitions and labeling in diagrams is illustrated in Figure 17. In [SS83] a similar notion is used for binary relationship 

types. 

Since the first notation cannot be extended to ternary relationships, in [Teo89] cardinality constraints for ternary relationships are marked by 

shaded areas in the relationship type triangle, provided that the relationship type is “many”. More concretely, for instance, the E 1 -corner 

of the triangle which represents the relationship type R = (E 1 , E 2 , E 3 , attr(R)) is not shaded if comp(R, E 2 E 3 ) ≤ (1, 1). 

This notation is complicated, and comp(R, E j )-cardinality constraints are not represented. This proposal could be extended to quadrary 

relationship types, but then we lose information about the other cardinality constraints. 

Figure 16 shows that this generalization represents different semantics. The representation by Teorey can be used to represent the constraints 

P aper, Conference → F irstAuthor 

P aper, F irstAuthor → Conference 

which are implied by the constraint 

P aper → F irstAuthor, Conference . 

Other books either avoid the question or present examples for binary relationship types. [TL82] states that “the semantics of ternary and 

higher-order relationship sets can become quite complex to comprehend.” 

Begründung: Siehe HERM Buch! 

Paper → FirstAuthor, Conference 

comp(Submitted,Paper) = (0,1) 

Paper 

✛(0,1) 

Submitted 

✲ 

First 

Author 

❄ 

Conference 

Teorey’s proposal 

Paper,Conference → FirstAuthor 

Paper, FirstAuthor → Conference 

Paper 

■ 

✒ 

First 

Author 

Submitted 

❄ 

Conference 

Abbildung 16: Different Semantics Represented by Teorey’s Approach 

Mehrwertige Abhängigkeiten stellen im Entwurf i.a. die Separation von Gesichtpunkten bzw. Aspekten dar. Sie werden oft 

weggelassen, da ihre mathematische Notation schwierig nachzuvollziehen ist. 

Eine mehrwertige Abhängigkeit X → Y |Z wird für einen Typ R = (U R , Σ R ), mit Teilmengen X, Y ⊆ U R und 

Z = U R \ (Y ∪ X) definiert und gilt in einer Klasse Relation R C über R (dargestellt durch R C |= X →→ Y |Z ), 



Review ✛ 

(1,1) (0,m) 

For ✲ Paper ✛ 

(0,1) (1,m) 

Published ✲ Journal 

✻(1,m) 

Wrote 

(1,m) 

❄ 

Author ✛ 

(1,m) (0,m) 

Works ✲ Institute 

Teorey 

◦ ◦ 

◦ 

ER-designer 

(0,m) (1,1) (1,m) (0,1) 

(1,m) 

(1,m) 

(0,m) (1,m) 

Everest 

◦ ◦ 

Binary 

✛✛ ◦ ✛✛ ◦ ✲ 

✲ 

✻✻ 

❄ ❄ ✛✛ ✲✲ 

◦ 

◦ 

Abbildung 17: Different Notions for a Paper Reviewing Database 

falls für alle o, o ′ ∈ R C , die den gleichen Wert für die X-Elemente von R haben, ein Objekt o ′′ in R C existiert, das aus 

der Faltung von o und o ′ hervorgehen kann, d.h. formal 

für alle o, o ′ ∈ R C mit o = X o ′ existiert ein Objekt o ′′ ∈ R C mit o ′′ = X∪Y o und o ′′ = X∪Z o ′ . 

Eine nützliche, allgemein bekannte Eigenschaft von mehrwertigen Abhängigkeiten ist die Dekompositionseigenschaft. 

Es gilt R C |= X →→ Y |Z genau dann, wenn sich R C nach X ∪ Y und X ∪ Z vertikal dekomponieren läßt, d.h. 

formal R C = R C [X ∪ Y ] ✶ R C [X ∪ Z] . 

Weniger bekannt ist dagegen, daß die Gültigkeit der mehrwertigen Abhängigkeit zu einem neuen äquivalenten Schema 

führt, bei dem der Typ R durch die dekomponierten Typen wie in Bild 18 ersetzt wird. 

Y ✛ XY ✲ X ✛ XZ ✲ 

Z 

Abbildung 18: Die Zerlegung von R in zwei Relationship-Typen 

Weitere relationale Integritätsbedingungen, z.B. Wertebereichsabhängigkeiten, können im erweiterten ER-Modell verwendet 

werden. So gilt in unserem Beispiel 

Semester.Bezeichnung 

∈ {W S, SS} × {x/x+1|x ∈ 80..99, 00, 01, 02, ..., 17} . 

Andere wichtige Klassen von Abhängigkeiten sind Exklusions- und Inklusionsabhängigkeiten. 



Probleme mit Integritätsbedingungen 

Zerstörung der Lokalität durch globale Auswirkungen innerhalb von Zyklen 

{ 1 } 

Reise 

✻ 

✛ besucht 

{ 3,4,7 } 

richtig: { 3 } 

{ 1,2,3,6 } richtig: { 6 } 

❄ 

startet 

✲ 

{ 2,3,5,6 } 

richtig: { 2 } 

Stadt 

Abbildung 26: Lokale Integritätsbedingungen mit globalen Auswirkungen 

Pivotisierung durch Identifikation von faktorisierbaren Konstrukten z.B. Integritätsbedingungen, die auf Fakten hinweisen 

Übungsleiter 

❨ 

0..1 

Professor ✛ 

Kurs 

✻ 

Vorlesung 

Plan 

Übungsleiter✛ 

Professor ✛ 

betreut 

❄ 

Vorlesung 

✲ 

(3,5) 

Kurs 

✻ 

Angebot 

✙ 

Stud-Gang 

❄ 

Semester 

✙ 

Stud-Gang 

Plan 

❄ 

Semester 

look(Vorlesung,Übungsleiter) = 0..1 card(Vorlesung, Kurs Semester) = (3,5) 

Abbildung 27: Pivotisierungsauswirkungen lokaler Integritätsbedingungen in zwei Facetten 

Globalisierende Integrititätsbedingungen hervorgerufen durch Zyklen 

weitere Beispiel in Hartmann-Habil 

Institution leitet ✲ 

(0,2) 

✻ 

(0,.) 

(1,1) 

❄ 

fördert ✲ Projekt ✛ 

(1,.) 

(0,5) 

Mitarbeiter ✛ arbeitet in 

(1,1) 

✻ 

(1,3) 

(30,50) 

❄ 

zugeordnet ✲ Labor 

(0,10) 

richtig: (0,30); besser (0,.) 

Abbildung 28: Globale Verwicklungen lokaler Integritätsbedingungen 

Löcherfraß in den Integritätsbedingungen durch Nichterfüllbarkeit für Konfigurationen 

siehe Hartmann-Mitteilung 

Warum dann HERM anstatt von UML. 

Mod IS 

IS ADD


Übung: 

• EER-Modelle 

• Struktur 

• Komponenten 

• stat. Integritätsbed. 

Global versus Local Normalisation. 

Normalisation is typically carried out on the basis of one database type. This type is normalised (e.g. decomposed, split or reduced) according 

to a set of integrity constraints. The association and the influence of this normalisation to other types is typically neglected. Therefore, 

normalisation is typically local. 

Local normalisation of a singleton database type is well reflected in most database books (e.g., [AHV95, Bis95, Leo92, Yan86]) and 

publications, most database courses, and in actual database practice. It is considered as one of the pearls of database research and known 

to almost everybody who knows database technology. The provenance and acknowledgement is based on the facility it provides: keeping as 

much as possible locally and globally supporting only those processes that are inherently global. Both independence concepts of databases 

(conceptual independence and implementation independence) are based on localisation. 

Local normalisation of database structures aims in derivation of such structures of databases that can easily be supported by the DBMS. 

In the past DBMS have been supporting keys, domain constraints and key-based inclusion constraints. Therefore, it is a goal to derive another 

equivalent schema to the given one which has an equivalent but supportable set of integrity constraints. This approach can be understood as a 

procedural approach to optimisation of database structuring depending on the platform for implementation. 

Normalisation is typically considered to be vertical normalisation. Deductive normalisation and horizontal normalisation are alternatives 

to vertical normalisation. 

Horizontal normalisation [PBGG89] is based on selection and union. Horizontal normalisation uses selections based on predicates 

α 1, ..., α n which may be pairwise exclusive (α i → ¬α j, i ≠ j) and cover the truth value 1 (( ∧ n 

i=1 

αi) → 1). Horizontal normalisation also 

allows us to separate the part of a set for which a dependency is valid from the part that invalidates a dependency. For instance 2 , α X−→Y = 

(o ∈ R C → ¬∃o ′ ∈ R C (o[X] = o ′ [X] ∧ o[Y ] ≠ o ′ [Y ])) separates those objects in R C for which the functional dependency is valid from 

those which invalidate the functional dependency. 

Deductive normalisation [Tha91a] is based on reduction and extended selection. Deductive normalization reduces relations to 

those elements that cannot be generated from the other elements by generation rules. It is the most storage effective and the best computational 

method for normalisation as long as the tuple-generating dependency used for decomposition is acyclic. Horizontal and deductive normalisation 

methods have not yet received a support from the database systems vendors. Local normalisation must however take into account these three 

kinds of normalisation. 

Global normalisation aims in normalisation of the schema as a whole. It must take into account the three kinds of local normalisation. 

Global normalisation has not got an appropriate attention in research despite the interest in implementations. Therefore, a systematic treatment 

of this normalisation has not yet been given in the literature. 

2.3.4 Rahmen zur Spezifikation von Integritätsbedingungen 

Integritätsbedingungen werden in der Literatur noch immer leichtfertig nur in einfacher Form bzw. Rohform spezifiziert. Eine 

Spezifikation der Integritätsbedingungen muß umfassen: 

Integritätsbedingung in Rohform: Angabe der Integritätsbedingung als logische Formel 

Lokalisierung der Integritätsbedingung im Kontext des Systemens, d.h. 

durch Angabe der Schema-Umgebung einer Integritätsbedingung (Schema-Frame-Problem) und 

durch Angabe der betroffenen Datenbankobjekte, die neben den betroffenen Objekten kontrolliert werden müssen 

(DB-Frame-Problem) 

Gültigkeit der Integritätsbedingungen je nach Phase der Anwendung, mindestens für die folgenden Phasen 

Einfahrphase des Systemes 

Normallauf des Systemes 

Archivierung der Datenbestände 

Ausführungsmodi zur Kontrolle der Integritätsbedingungen je nach Operation 

2 We use the symbol R for type or class specification and denote the class of elements of the type by R C . Tuples (in the case of objectrelational 

models) or elements of R C are denoted by o. X −→ Y is a functional dependency. 

Mod IS 

IS ADD


Ausführungszeit der Kontrolle z.B. verzögert, sofort ggf. auch mit Aussetzen unter bestimmten Bedingungen 

Anwendungsmonitoring der Kontrolle der Integritätsbedingungen z.B. auf Objektniveau oder auf Anweisungsniveau 

Umformung (term rewriting) der Operationen 

Behandlung für den Fall des Nichtgeltens der Integritätsbedingung je nach Datenbankereignis: 

Zurückweisen der verursachenden Anweisung 

Propagierung der Integritätsbedingung 

Nutzung von (temporären) Zusatzwerten zur Kennzeichnung der Situation 

Rangordnung der Integritätsbedingung unter den Klassen von Integritätsbedingungen zur Ableitung der Kontrollreihenfolge 

Daneben können wir Default-Rahmen angeben: 

1. harte Integritätsbedingung ohne das Zulassen von Ausnahmen 

2. volle Schema- und DB-Umgebung 

3. keine Unterscheidung von Phasen 

4. sofortige Kontrolle bei Datenbankereignissen ohne Ergänzung der Operationen 

5. gleichwertige Klassen von Integritätsbedingungen 

Insbesondere nutzen wir die folgenden Rahmen und Erzwingungsmodi: 

1. Spezifikation von Existenzabhängigkeiten 

Durch die Komplexitäten sind bereits Abhängigkeiten dargestellt worden, die von den generischen Operationen insert, 

delete, update eingehalten werden müssen. Ist für eine Komplexität comp(R, R ′ ) = (a, b) a ≥ 1, dann ist jedes insert 

in R ′ durch ein insert in R zu unterstützen. Jedes delete in R ′ kann ein delete in R nach sich ziehen. Alle derartigen 

Komplexitäten werden zusammengestellt und in den folgenden Schritten angewandt. 

Man kann für jeden Typen eine insert-, delete- und eine update-Umgebung mit folgendem Algorithmus konstruieren. 

(a) Env I (R) := Env D (R) := Env U (R) := {R} für jeden Entity- und Relationshiptypen. 

(b) Man generiere die Umgebungend erster Ordnung wie folgt. 

i. Gilt comp(R, R ′ ) = (a, b) für a ≥ 1 dann sei Env I (R) := Env I (R ′ )∪Env I (R), Env U (R) := Env U (R ′ )∪ 

Env U (R) und Env D (R ′ ) := Env D (R) ∪ Env D (R). 

ii. Für jeden Relationshiptypen R ′ , in dem R eine Komponente bildet: Env I (R ′ ) := Env I (R) ∪ Env I (R ′ ), 

Env U (R ′ ) := Env U (R) ∪ Env U (R ′ ) und Env D (R) := Env D (R) ∪ Env D (R ′ ). 

iii. Für jede Exklusionsabhängigkeit R ‖ R ′ gilt Env I (R ′ ) := Env D (R) ∪ Env I (R) und Env U (R ′ ) := 

Env U (R) ∪ Env U (R). 

iv. Weitere Abhängigkeiten werden analog behandelt. 

(c) Man wiederhole diesen Schritt bis keine der Mengen verändert wird: 

i. Gilt comp(R ′′ , R ′ ) = (a, b) für a ≥ 1 und R ′′ ∈ Env I (R ′ ) dann sei Env I (R) := Env I (R ′ ) ∪ Env I (R). 

Gilt comp(R ′′ , R ′ ) = (a, b) für a ≥ 1 und R ′′ ∈ Env U (R ′ ) dann sei Env U (R) := Env U (R ′ ) ∪ Env U (R). 

Gilt comp(R ′′ , R ′ ) = (a, b) für a ≥ 1 und R ′′ ∈ Env D (R ′ ) dann sei Env D (R ′ ) := Env D (R) ∪ Env D (R). 

ii. Für jeden Relationshiptypen R ′′ mit R ′′ ∈ Env I (R ′ ), in dem R eine Komponente bildet, sei Env I (R ′ ) := 

Env I (R) ∪ Env I (R ′ ). Für jeden Relationshiptypen R ′′ mit R ′′ ∈ Env U (R ′ ), in dem R eine Komponente 

bildet, sei Env U (R ′ ) := Env U (R) ∪ Env U (R ′ ). Für jeden Relationshiptypen R ′′ mit R ′′ ∈ Env D (R ′ ), in 

dem R eine Komponente bildet, sei Env D (R) := Env D (R) ∪ Env D (R ′ ). 

iii. Für jede Exklusionsabhängigkeit R ‖ R ′′ mit R ′′ ∈ Env I (R ′ ) gilt Env I (R ′ ) := Env D (R) ∪ Env I (R). Für 

jede Exklusionsabhängigkeit R ‖ R ′′ mit R ′′ ∈ Env U (R ′ ) gilt Env U (R ′ ) := Env U (R) ∪ Env U (R). 

iv. Weitere Abhängigkeiten werden analog behandelt. 

Mod IS 

IS ADD


Diese Umgebungen sind maximale Umgebungen. Sie werden durch Eigenschaften der Anwendung eingeschränkt. 

Durch die Hierarchien sind entsprechende Existenzabhängigkeiten gegeben. Die Generalisierung (z.B. eine Person-dejure 

ist eine Firma oder eine Person) führt zu einer Existenzabhängigkeit des Supertypen von Subtypen, die unbedingt gepflegt 

werden muß (d.h. werden die Daten einer Firma entfernt, dann werden diese auch für die Persona-de-jure entfernt). 

Die Spezialisierung führt zu einer Existenzabhängigkeit des Subtypen (in unserem Falle Teiltypen (Relationshiptypen 

definiert über dem Supertypen)) vom Supertypen. 

2. Erzwingungsregeln für insert- Operationen 

Man kann für insert-Operationen verschiedene Optionen bestrachten: 

• Abhängigkeit: Eine Einfügung ist nur erlaubt, wenn alle korrespondierenden Objekte bereits existieren. 

• Automatismus: Eine Einfügung ist stets erlaubt. Wenn entsprechende Objekte nicht existieren, dann werden sie 

ebenfalls eingefügt. 

• Nullwertebehandlung: Eine Einfügung ist stets erlaubt. Existieren die entsprechenden Objekte nicht, dann werden 

für das neue Objekt Nullwerte benutzt. 

• default-Werte: Eine Einfügung ist stets erlaubt. Existieren die entsprechenden Objekte nicht, dann werden für das 

neue Objekt default-Werte benutzt. 

• Zusätzliche Einfügebedingungen: Ein Einfügen ist nur dann erlaubt, wenn eine zusätzliche Bedingung gilt. 

• Keine Einschränkung: Das Einfügen unterliegt keiner Beschränkung. 

Die letzten beiden Möglichkeiten betreffen alle Typen außerhalb von Env I (R). Die ersten vier Möglichkeiten sind für 

Env I (R) bei der Spezifikation der Anwendung zu nutzen. 

3. Erzwingungsregeln für delete-Operationen 

Man kann für delete-Operationen verschiedene Optionen bestrachten: 

• Beschränkung: Ein Streichen ist nur erlaubt, wenn kein anderes Objekt davon betroffen ist. 

• Kaskadierung: Ein Streichen zieht das Streichen anderer Objekte nach sich. 

• Bedingte Kaskadierung: Ein Streichen zieht das Streichen anderer Objekte nach sich, die nur aufgrund des zu 

streichenden Objektes noch existieren. 

• Nullwertebehandlung: Beim Streichen werden Objekte, in die das Objekt eingeht auf einen Nullwert gesetzt. 

• default-Werte: Beim Streichen werden Objekte, in die das Objekt eingeht auf einen Nullwert gesetzt. 

• Zusätzliche Streichungsbedingungen: Das Streichen ist nur unter bestimmten Bedingungen erlaubt. 

• Keine Einschränkung: Das Streichen unterliegt keiner Beschränkung. 

Die letzten beiden Möglichkeiten betreffen alle Typen außerhalb von Env D (R). Die ersten vier Möglichkeiten sind für 

Env D (R) bei der Spezifikation der Anwendung zu nutzen. 

SQL2 läßt in der Vollversion Kaskadierung, Nullwertebehandlung, Default-Werte und Beschränkung (ist default) (als ‘no 

action’) zu. 

4. Erzwingungsregeln für update-Operationen 

• Beschränkung: Ein update ist nur erlaubt, wenn kein anderes Objekt davon betroffen ist (z.B. auch über Sekundärschlüsseln, 

die nicht in Beziehungen verwandt werden). 

• Automatismus: Ein update ist stets erlaubt, solange Integritätsbedingungen des Typs nicht verletzt werden. 

• Kaskadierung: Ein update löst weitere Operationen aus. 

• Nullwertebehandlung: Konflikte werden durch Nullwerte gelöst. 

• default-Werte: Zur Konfliktbereinigung werden default-Werte benutzt. 

• Zusätzliche update-Bedingungen: Ein update ist nur unter zusätzlichen Bedingungen möglich. 

• Keine Einschränkung. 

Eine update-Operation ist nicht das Gleiche wie eine delete;insert-Folge. 

SQL2 läßt in der Vollversion Kaskadierung, Nullwertebehandlung, Default-Werte und Beschränkung (ist default) zu. 

Mod IS 

IS ADD


Erzwingungsregeln 

✙ 

Unbedingte 

Erzwingung 

❄ 

Keine 

Erzwingung 

❥ 

Bedingte 

Erzwingung 

Kaskadierung 

Abhängigkeit 

✙ ❄ ❥ 

Nullwertebehandlung 

default- 

Werte 

❄ 

an Existenz 

gebunden; 

Rollback 

Abbildung 29: Mögliche Erzwingungsregeln für generische Operationen 

❥ 

mit zusätzlichen 

Einfügebedingungen 

; 

Prädikat 

Die Erzwingung kann auch aufgrund von Regel-Trigger-Systemen spezifiziert werden. Dann ist jedoch das Resultat bei 

automatischer Erzwingung falsch. Der GCS-Zugang von Schewe/Thalheim ist ein sicherer automatischer Zugang. Er ist allerdings 

für die Betrachtungen hier zu komplex. 

Die Integritätsbedingungen sind in SQL-92 in unterschiedlichen Modi und Matching unterstützt, wobei deren Zusammenwirken 

nicht erklärt ist. 

Integrity Constraint Specification. 

Integrity Constraint ϕ 

[Localization: < unit name> ] 

[Partiality: < validity condition >] 

[Exception: < exception condition >] 

[In-Context: < enforcement rule, time, granularity >] 

[Out-Context: < conditional operation, accept on >] . 

Enforcement through 

Direct enforcement through declarative constraints with RESTRICT, NO ACTION, CASCADE, SET VALUE (null, default), [INITIALLY] DEFERR 

[INITIALLY] IMMEDIATE [DEFERABLE] 

Transactions with three mechanisms on failure: 

(1) rollback on inconsistency currently exclusive treatment 

(2) erasing effects of TA: transaction COMPENSATED_ON_FAILURE_BY transaction 

(3) raising an exception: transaction CONTINGENTED_ON_EXCEPTION_BY exception 

Triggers with the after-before activation time, row-statement granularity, 

1-n (SQL:1999, DB2, Informix, SQL Server) , n-1 (Sybase) or n-n (Ingres,Oracle) event-trigger pairs 

IC enforcement policy - checking mode (immediate, deferred), triggering, scope, checking time (before, after), row/statement level 

Problems to be Solved for Maintenance. 

A: Integrity preservation with consideration of enforcement policies 

User-defined types 

SQL’99 constraints in a large variety: 

Checking mode 

Choice of statement or row level 

Constraints may be pre- or post-conditions 

Scope conditions 

Matching conditions 

Reference types 

Triggers in variations: 

Number of triggers per events and events per triggers 

Activation time 

Mod IS 

IS ADD


Conflict resolution of execution order 

Order of constraint check differs for DB2 Sybase, Oracle, Informix, Ingres, and MS SQL 

SQL’92 declarative constraints 

B: Effect preservation of the intended update operation 

Insert effect preservation 

Delete effect preservation 

Update effect preservation 

Resultierende Betrachtungen für die Pflege der Integritätsbedingungen. 

• Problems of Integrity Maintenance 

Incompleteness of maintenance 

Infeasibility of maintenance 

Infeasibility of programming 

• Integrity maintenance is based on: 

Integrity constraint checking 

Integrity constraint detection 

• Integrity maintenance suffers from: 

Non-existence of integrity constraint axiomatisation 

Complexity of constraint check 

Complexity of database maintenance 

SQL’99 Proposals for Transactions and Consistency Specification. 

Level of enforcement: On row-level or on statement level 

Modus of enforcement: Immediate or deferred 

Equality functions: full, partial, normal 

differences in treatment of null values 

Check time for constraints: Before execution, after execution 

Hinzu kommt dann noch die Herstellung einer globalen Konsistenz der Erzwingungsmechanismen. Man betrachte z.B. 

die Erzwingung in Bild 30. 

R 1 

✾ 

R 2 

restrict 

✙ 

R 3 

nullify 

cascade 

❥ 

R 4 

cascade 

3 

R 5 

cascade 

❄ 

R 6 

cascade 

❄ 

R 6 

nullify 

❄ 

R 6 

default 

❄ 

R 6 

restrict NULL NIL ??? DEFAULT 

Abbildung 30: Das ‘diamond’-Problem bei der Erzwingung von foreign key constraints 

Es werden zwei Wertezuweisungen für den Wert des gleichen Objekts in R 1 vorgenommen ausgehend von gleichen Objekt 

in R 6 . Die zugehörigen foreign key constraints sind R 2 ⊆ R 6 , R 3 ⊆ R 6 , R 4 ⊆ R 6 , R 5 ⊆ R 6 , R 1 ⊆ R 2 , R 1 ⊆ R 3 , R 1 ⊆ 

R 4 , R 1 ⊆ R 5 , . 

Mod IS 

IS ADD


2.4 Ein Datenbank-Schema 

ER besteht aus einer Menge von Typen {T i = (U Ti , Σ Ti )} und globalen statischen Integritätsbedingungen Σ ER . 

Datenbankmodellierung und das Abstraktionsschichtenmodell 

Unsere Strukturierungssprache unterstützt das Abstraktionsschichtenmodell. Es kann die Strukturierung der Daten in jeder 

Schicht durch das Entity-Relationship-Modell repräsentiert werden. Wir verwenden dazu Schemata unterschiedlicher Abstraktheit 

und Granularität. 

Datenstrukturierung des Lastenhefts: Es wird ein allgemeines HERM-Diagramm mit den Haupttypen entwickelt. 

Datenstrukturierung des Pflichtenhefts: Es wird ein grobes HERM-Diagramm mit entsprechenden Integritätsbedingungen 

angegeben, das die Typen des Lastenhefts verfeinert. Die Verfeinerung findet durch Spezialisierung der Typen, Dekomposition, 

strukturelle Erweiterung, semantische Einschränkung, Separation von Aspekten und durch Instantiierung statt. 

Zusätzlich werden weitere Typen eingeführt. 

Anwendungsschema: Das Anwendungsschema repräsentiert alle Typen, die für den Anwender eine Bedeutung haben. Die 

Typen stellen eine Verfeinerung der Typen des Pflichtenhefts dar oder sind neu eingeführt. 

Konzeptionelles ER-Schema: Auf der konzeptionellen Schicht wird ein detailliertes HERM-Diagramm erstellt, das u.a. auch 

für alle Typen des Anwendungsschemas entsprechende Verfeinerungen enthält. Diese Beziehungen finden auch Eingang 

in die Sichten-Suite. 

Logisches Schema: Das HERM-Schema wird in ein entsprechendes Schema des logischen Datenbank-Modelles transformiert. 

Es kann üblicherweise ein objekt-relationales oder relationales Schema, aber auch eine Beschreibung als XML- 

Schema oder DTD-Datei (document type definition) sein. 

Diese Schemata sind aufeinander abbildbar. Demzufolge kann jede Entwurfseinheit einer höheren Schicht - so wie in Bild ?? 

auf Seite ?? dargestellt - einer Menge von Entwurfseinheiten der folgenden Schicht direkt zugeordnet werden. 

Wir merken an, daß wir über zwei unterschiedliche Methoden zur Darstellung, Repräsentation, Verarbeitung und Speicherung 

von Objekten verfügen: 

Klassen-Separation: Die Menge aller Objekte wird durch ein ER-Schema dargestellt. Jedes Objekt wird genau einer Klasse 

zugeordnet und in beliebig vielen anderen Klassen auf der Grundlage des ER-Schemas verwendet. Die Verwendung kann 

über einen Surrogat-Schlüssel, eine Markierung oder Werte zum ausgewählten Schlüssel des Objektes erfolgen. 

Wir nennen diese Form der Behandlung von Objektmengen klassen-separierte Darstellung. Ein Objekt ist dann mit 

dem erweiterten ER-Modell als Schneeflocke mit einer Wurzel darstellbar. 

Objekt-Entfaltung: Die Menge aller Objekte bildet unter Einbeziehung der Beziehungen der Objekte untereinander einen 

Objektmengen-Graphen. Wir können über diesem Graphen beliebige Überdeckungen U bilden, d.h. Mengen von Teilgraphen, 

die zusammen den Objektmengen-Graphen ergeben. Ein Teilgraph besitzt evt. ein Wurzel-Objekt, d.h. es gibt 

ein Objekt, das rekursiv auf alle anderen Objekte des Teilgraphen verweist. Besitzt jeder dieser Teilgraphen ein Wurzelobjekt, 

dann heißt U Objekt-Gesellschaft. 

Damit ist in Objekt-Gesellschaften jedes Objekt ein volles Objekt mit allen Eigenschaften. 

Ein Beispiel für eine Objekt-Entfaltung zum Schema in Bild 6 ist folgendes XML-Dokument: 

 

 

 

Montag 

Mittwoch 

 

 

Normalvorlesung 2+2+2 

.... ... 

Sommersemester 2000, 10.4. 2000 - 15.7.2000 

 

 

Fak.-Ref. Schenk 

Mod IS 

IS ADD


Anwendungsschicht 

Vorstudie 

Skizzierung 

Konzeptlandkarte 

Konzept 

Lastenheft: Daten 

Geschäftsprozeßschicht 

Feinstudie 

Darstellung 

Skizze 

Grober Typ 

Pflichtenheft: Daten 

Aktionsschicht 

Entwurf 

Entwurf 

Skelett 

Anwendungstyp 

Anwendungsschema 

konzeptionelle 

Schicht 

Implementation 

Transformation 

Schema 

Typ 

ER-Schema 

Implementationsschicht 

Schema 

logischer 

Typ 

logisches Schema 

Abbildung 31: Die Arbeitsprodukte im Abstraktionsschichtenmodell für die Strukturierung 

Mod IS 

IS ADD


1.4.1999, .... 

AB, Montag, 7.30-11.00 

Beamer, Netzanschluß 

Datenbanken I 

 

Die erste Methode wird meist für die Speicherung und Verarbeitung in relationalen und objekt-relationalen DBMS angewandt. 

Die Repräsentation erfolgt auf der Grundlage von Sichten, die im Kapitel ?? ausführlich dargestellt werden. OLAP-Zugänge 

verwenden oft den zweiten Zugang. Die zweite Methode wird auch bei XML-DBMS angewandt. 

Die Redundanz-Beherrschung ist nach wie vor für beliebige Objektmengen wichtig. Deshalb ist der erste Zugang vorzuziehen. 

Wir unterstützen diesen Zugang durch Einführung einer Sichten-Suite. 

2.5 Normalisierung versus Denormalisieurng 

Normalization aims at solving the following five problems: 

Anomalies in operations behavior: If data represent different semantic facts at the same time then operations such as Insert, 

Delete and Update behave differently. Deletion may lead to the deletion of facts which should not be removed from the 

database. Updating needs a complete table scan instead of a one fact correction. Insertion of a fact cannot be made since 

other facts are missing. In this case, the tables need to be replaced by tables which represent semantic units of facts. 

Normalization includes such kinds of decomposition. 

Existence of inconsistent data: Data are interrelated. Any modification applied to objects in the database should also be 

accompanied by modifications on related objects. Databases and views are often based on macro-data, i.e., derived data. 

If the meaning of the derivation is not understandable to the user then wrong conclusions are made on the data provided 

by the database. Derived data are shipped to other users who include such data into their databases and computations. If 

the basic data are changed afterwards then the derived data have to also be changed in order to avoid inconsistencies. 

Redundancy of data in the database: Data may be stored in the database in different associations. If this is not to be done 

intentionally and with care then modifications of data on one place are not enforced to modifications of data on the other 

place. Data can be encoded with additional information. For instance, the student’s number often includes the year of 

admittance. In this case changes to the admittance should be reflected in the number. However, the number is assumed to 

be a stable key which does not have modifications. 

Instability of schemata after changes: Database applications are not stable over a long period of time. New requirements, 

new structures which have to be included into the existing application and changing environments cause restructuring of 

schemata. Thus, the schema resembles a ‘mannerisms cathedral’, that is, it is hard to maintain. A complete documentation 

is missing. Schema restructuring is also caused by performance problems. In this case, the physical and logical schemata 

do not match and are not an image of the conceptual schema. A wide range of legacy problems leads to problematic 

database behavior. 

Careful design with consideration of possible changes can partially solve this problem. Conceptual design with integrated 

normalization over the entire life span of the database is the best solution. Database schemata can be extended by 

propagation patterns [HLM93]. They encourage the reuse of specifications as opposed to the structural modification of 

schemata. 

Different abstraction level in applications: User groups have different requirements regarding data abstraction, granularity 

and representation of data. Data have different meanings to users and users apply a different interpretation to their data. 

There are differences in the meaning of the functions. Users operate their data in different fashions and have different 

rights and roles. The three level architecture can be used for the solution of heterogeneity problems. The integrated 

schema should lead to good behavior. Optimization is an important design step. Since normalization is mainly structural 

optimization, normalization approaches are applied. 

Normalization and ER techniques are often understood as being two opposite techniques. ER techniques are seen as attempts 

to provide a taxonomy of objects to allow a user to intuitively recognize different types of objects, and to classify the objects 

and their relationships. The normalization approach seems to be entirely different: all data are listed and then all interrelatedness 

rules such as dependencies are identified. In the next step classes are decomposed according to the semantic structure of their 

objects. In fact, normalization and ER techniques reinforce one another in providing needed intuition on behavior and structure 

of objects stored in the database. 

Mod IS 

IS ADD


2.5.1 The Normalization Problem 

Generally speaking, the normalization problem is defined based on a set of scheme transformation operators O and a property 

P . 

For a given scheme ERS, the normalization problem is to determine whether a translation Φ exists in O which can be applied 

to ERS such that 

1. Φ(ERS) is equivalent to ERS and 

2. Φ(ERS) satisfies the property P . 

The translation Φ is called decomposition mapping or transformation mapping if simple operations are used. We usually assume 

the existence of a reconstruction mapping Ψ such that for each database on ERS C the equality ERS C = Ψ(Φ(ERS C )) 

is valid. 

A translation Φ is a mapping from a schema ERS to another schema ERS ′ . Integrity constraints are defined for the 

schemata: Σ ERS , Σ ERS ′. The set of all databases on ERS is denoted by R(ERS). Let SAT (ERS) (SAT (ERS ′ )) be the set 

of all databases defined on ERS that satisfy Σ ERS (respectively Σ ERS ′). The translation Φ is a mapping from R(ERS) to 

R(ERS ′ ). 

Some examples of properties are the third normal form, the fourth normal form or the BCNF. In this case the operations 

used are projections on the type and constraint levels. The equivalence of the two schemes is maintained by join operations. This 

normalization is known as vertical decomposition of schemes. 

Another kind of decomposition is horizontal decomposition. Operations used are selection or general selectors [Sch77]. Reconstruction 

mappings are the union or exclusive union. 

Deductive normalization is a third example of a normalization. Formulas are used for reconstruction mapping. Reduction is the 

normalization mapping. The schemes do not change during deductive normalization. Deductive normalization can be used for 

archiving large amounts of data. Retrieval of these data can be effectively supported by indexes which are specified in accordance 

with formulas. 

In [YT89, VS93b, Vin94], a normalization theory was developed. The main criteria for normalization are maintenance 

simplicity, which consists of two parts: storage and access simplicity, and operational simplicity. Since the two parts of maintenance 

simplicity conflict with the specification of the user, the user should specify his/her preferences. On the basis of integrity 

constraints, several normal forms could be chosen. For instance, if only functional dependencies are specified then the goal of 

normalization is the elementary key normal form (for nested relations). Relationship types inherit the keys of underlying component 

types. The decomposition of keys of these types leads to an increase in the arity of the relationship type. Therefore, a 

decomposition can be rejected for performance reasons. Integrity constraints can be used to decide whether a decomposition is 

rejected or not. 

Relational normalization procedures incorporate few semantic aspects of aggregation. For instance, the entity type 

Student = ({StNumber, Course, Address}, 

{StNumber, Course, Address}) 

represents the relationship of students with a course and their addresses. This type is in third normal form but not in fourth 

normal form. We cannot possibly define the intentional meaning of this relation. 

If the maintenance simplicity is considered to be one of the most important design criteria, there are at least three requirements 

which should be satisfied: 

1. The schemes should be normalized in the classical sense. 

2. The schemes should be minimal. The information represented in one class should be not repeated in another class. 

3. The set of integrity constraints used should be simple to maintain. 

The last criteria is the most difficult one. The first requirement can be easily represented, even in ER schemes [CCN80]. The 

first and the second requirement can be represented in HERM schemes but can also be represented in ER schemes. 

In [CCN80] normal forms in ER models are discussed on the basis of the relational database theory. However this approach 

is not completely appropriate, as we have seen in Figures ?? and ??. 

2.5.2 Local (Vertical) Normalization 

Local vertical normalization is based on the operator Φ d = (π X1 , ...π Xn ) for a join dependency d = (X 1 , ...X n ) and the 

reconstruction operator Ψ =✶. Local vertical normalization on the type level is often considered to be the ultimate goal of the 

database design process. 

Mod IS 

IS ADD


The argument that normalization beyond third normal form is not useful, offers only little benefit and incurs serious performance 

costs is based on the observation that most, and usually all, of the problems associated with unnormalized data are solved 

on the basis of 3NF or BCNF. Structures that are in 3NF or BCNF still exhibit serious problems, of very much the same sort addressed 

in the earlier stages of normalization: redundancy; insertion, deletion, and update complexity; difficulty in storing facts 

independently. The main reason for denormalization is performance. The performance argument is valid for all normal forms 

in the same strength. Since the behavior has to optimized, we may ultimately need to make compromises to achieve adequate 

performance. 

The normal forms developed so far have different aims: 

Store only basic facts in the database: Facts are represented by entities and relationships. Basic facts [Hal95] are assertions 

about the database application such as ‘The student “Maier” takes the “database” course’ or ‘The person named “Maier” 

is a student’. The adjective ‘basic’ indicates that the fact cannot be split into smaller units of information which collectively 

provide the same information as the original. The existence of a functional dependency indicates that components 

represent a fact or a basic fact. 

Do not represent the same fact twice: A fact should be represented only once in the database. There is no redundancy. If a 

relation is defined on a schema with several functional dependencies and the left hand sides of such dependencies are not 

equivalent, then we might store the same fact several times. The address is stored several times in the Student class since 

students are taking several courses. Thus we search for a decomposition such that each new schema represents facts only 

once. BCNF is the solution to this requirement if functional dependencies are considered. 

Do not store unrelated facts in the same type: Facts can be related or unrelated or related via other facts. For instance, 

in the Student class above, the courses are related to addresses only through the student’s number. They do not together 

represent a unit of information. Thus, the class can be decomposed into a class containing objects representing information 

on students and their addresses and another class representing information on students and the courses they take. The 

class for Student is in BCNF. Nevertheless a multivalued dependency is valid. The update anomaly disappears after 

decomposition. 

Keep maintenance simple: Maintenance simplicity is one of the main goals of database design. Whether maintenance procedures 

are simple depends on the language provided by the system. If the system allows the expression of simple integrity 

constraints in a declarative form and has other facilities for expressing more complex constraints then design is oriented 

to simple integrity constraints. For instance, the domain/key normal form is based on domain, key and referential integrity 

constraints. They can be expressed in a simple declarative form. 

Vertical normalization is achieved through decomposition of types into smaller types. The correctness of the transformation 

mapping is based on several properties: 

No loss of information: The schema and the decomposed schema have the same capacity to store information. We do not lose 

information when the class of type R is replaced by its projections. The decomposition of a type R via a join dependency 

d = (X 1 , ..., X n ) is called lossless if for each class R C the equality R C = π X1 (R C ) ✶ ... ✶ π Xn (R C ) is valid. 

If the join dependency d is implied by the functional dependencies Σ of the type then the decomposition is lossless. 

Invariance of integrity constraints: The integrity constraints expressible in the decomposed schema and derived from the integrity 

constraints of the original schema imply together with the join dependency the integrity constraints of the original 

schema: 

Given the type R = (compon(R), Σ) where Σ contains only functional dependencies, given the join dependency 

d = (X 1 , ..., X n ), let Σ i = {X → Y |X, Y ⊂ X i , Σ |= X → Y }. 

The decomposition via d is constraint preserving if 

⋃ n 

i=1 Σ i |= Σ. 

If a decomposition is constraint preserving then functional dependencies can be enforced on the level of the decomposed 

types. Unfortunately there are types that do not have a constraint preserving lossless decomposition into BCNF. In this 

case we might have to sacrifice some dependencies. However, there are two compromises if we do not want to make this 

sacrifice: the third normal form or splitting of attributes. The first approach can be applied if there is a strong requirement 

to constraint preservation. The latter approach is considered at the end of this subchapter. The following characterizations 

can be given for schemata which are in 3NF and not in BCNF: 

• Given a type R and a set Σ of functional dependencies. If the type R is in 3NF but not in BCNF then two different 

minimal K, K ′ exist in R with K ∩ K ′ ≠ ∅ [VS93a]. 

Mod IS 

IS ADD


• Given a type R which is in 3NF according to a set Σ of functional dependencies. If all different minimal K, K ′ in 

R are disjoint, i.e., K ∩ K ′ = ∅ then R is in BCNF according to Σ [Mok97]. 

• Given a type R and a set of functional dependencies. If R is in 3NF and all minimal keys consists of only one 

attribute then R is in BCNF. 

The second and the first statement are equivalent. The third sufficient condition is a corollary of the first. 

Adequacy of decomposed schemata: A schema S is an adequate representation of R if there is a transformation mapping 

Φ from R to S such that Φ is a reduction of SAT (R) to Φ(SAT (R)) ∩ SAT (S)[AT93]. Adequacy depends on the constraints 

Σ S specified in S. Let us consider the case of vertical decomposition F d via a join dependency d = (X 1 , ..., X n ) 

with Σ S ⊆ ⋃ n 

i=1 Σ i. Φ d maps relations from R(R) \ SAT (R) to SAT (S). The schema S is called fully adequate if 

Φ d (R(R) \ SAT (R)) ⊆ R(S) \ SAT (S) and if Φ(SAT (R)) = SAT (S). 

Adequacy cannot be based on functional dependencies only. We also need inclusion dependencies and other constraints: 

For all i, j, 1 ≤ i, j ≤ n and S = (S 1 , ..., S n , Σ S ) the inclusion constraints Si C[X i ∩ X j ] ⊆ Sj C[X i ∩ X j ] are implied 

from Σ S . Furthermore, Σ S ⊇ ⋃ n 

i=1 Σ i. 

Let us now consider the pair (Φ d , Ψ) for a set of functional dependencies Σ R and a decomposition dependency d defined 

for R. Thus, Φ ∗ decomposes R into a set of projections. Ψ is a S − R-translation. Based on Proposition ?? we observe[MR98]: 

Corollary 2 (i) Let Σ be a set of functional dependencies. Then Φ # d 

(Σ) is equivalent to a set of functional dependencies. 

(ii) Ψ # (Σ R ) is not necessarily equivalent to a set of functional dependencies. It is equivalent to a set of weak functional 

dependencies. Thus, it is equivalent to a generalized functional dependency. 

Therefore, functional dependencies cannot be used to characterize all databases which have been obtained by vertical decomposition. 

Dependencies of the same class might be not powerful enough for the characterization. The following table shows 

to which constraints functional dependencies (FD), general embedded implicational dependencies (EID), equality generating 

dependencies (EGD), tuple-generating dependencies (TGD), inclusion dependencies (ID) and embedded tuple-generating dependencies 

are mapped by translations based on projections (PROJ), based on joins (JOIN) and by translations of the smallest 

set (BASIC) of translations which contain projection and join and which are closed under composition. 

dependency class FD EID EGD TGD ID ETGD 

PROJ FD EID EGD ETGD ID ETGD 

JOIN EGD EID EGD ETGD ETGD ETGD 

BASIC EGD EID EGD ETGD ETGD ETGD 

Basically closed classes DEP of dependencies are such classes for which for each Φ ∈BASIC and every Σ ⊆DEP the 

property Φ # (Σ) ⊆DEP. In [MR98] the following observation is stated. 

Corollary 3 Embedded implicational dependencies are the smallest basically closed class of dependencies which contain both 

the functional and inclusion dependencies. 

Embedded implicational dependencies are the smallest basically closed class of dependencies which contain (0, 1), (0, m), (1, m), (1, 1) 

cardinality constraints. 

The proof is based on Proposition ??. 

Currently, two approaches to normalization on the basis of functional dependencies are known: 

Synthesis approach: The synthesis approach is based on a precomputation of an appropriate set of functional dependencies. 

This set can be computed on the basis of the axiomatization of functional dependencies. 

A type R = (compon(R), Σ) has a minimal set of constraints if Σ obeys the following properties: 

• Each dependency in Σ has the form X → {A} for a component A of R. 

• No proper subset of Σ implies Σ. 

• Each dependency in Σ is left-reduced, i.e., there is no proper subset Y of X for a functional dependency X → Z 

in Σ with Σ |= Y → Z. 

We assume that each component appears in at least one functional dependency of Σ. We compute the decomposed schema 

based on the following choice: 

• If for a dependency X → {A} ∈ Σ X ∪ {A} = compon(R) then R cannot be decomposed. 

Mod IS 

IS ADD


• For any dependency X → {A} ∈ Σ define a new type with the components X ∪ {A} and the key X. We choose a 

key K of R and create a new type with K as its components. 

If components do not participate in any functional dependency then we add a new component ω and a functional dependency 

whose right side is the new component and whose left side contains those components together with the ‘dangling’ 

components which should not be separated from the latter. Then we compute the decomposition and remove the new 

component at the end. 

The same approach can be applied if there are components which should not be separated. 

Let us consider a movie display database type [AHV95] containing attributes for the movie (A(ctor), D(irector), M(ovie 

title)), the theatre (Th(eatre name), A(ddress), P(hone)) and some display data (Ti(me), Pr(ice)). Further we are given the 

dependencies: 

{ Th } → { Ad, P }, 

{ Th, Ti, M } → { Pr } and 

{ M } → { D }. 

In addition, we assume that the attributes A and T cannot be separated. 

We obtain the types with the following components and the corresponding projected constraints: 

{ Th, Ad, P }, 

{ M, D }, 

{ Th, Ti, M, Pr }, 

{ Th, M, Ti, A }. 

If we assume furthermore that M →→ A then the last type can be decomposed according to the decomposition approach 

into 

{ Th, M, Ti } and 

{ M, A }. 

Since the first new schema is subsumed by the third type it can be removed. Thus we obtain: 

{ Th, Ad , P }, 

{ M, D }, 

{ Th, Ti, M, Pr }, 

{ M, A }. 

The synthesis approach will generate a lossless, constraint preserving decomposition to third normal form. BCNF can 

only be computed for some sets of functional dependencies. 

If the inclusion constraints are added then this approach leads to a decomposition which is fully adequate. 

Decomposition approach: Given a type R = (compon(R), Σ), we compute stepwise a new schema based on functional dependencies 

until all new component schemata are in BCNF by the decomposition step: 

Choose a type R ′ = (compon(R ′ ), Σ R ′) which is not in BCNF. 

Choose a partition of compon(R ′ ) into X, Y, Z such that 

Σ R ′ |= X → Y and 

Σ R ′ ̸|= X → {A} for each A ∈ Z. 

Replace R ′ = (compon(R ′ ), Σ R ′) by R 1 ′ = (compon(R ′ ) ∩ XY, Σ R ′ 

XY 

) and R 2 ′ = (compon(R ′ ) ∩ XZ, Σ R ′ 

XZ 

). 

If there are S = (compon(S), Σ S ) and T = (compon(T ), Σ T ) in the decomposed schema with compon(S) ⊆ 

compon(T ) then remove S from the decomposed schema. 

Let us consider the same movie display database type. We apply the first dependency and obtain the schema 

({ Th, Ad, P }, {{ Th } → { Ad, P }}) 

({ A, D, M, Th, Ti, Pr }, {{ Th, Ti, M } → { Pr }, 

{ M } → { D }} ). 

Now we can apply the third dependency and obtain 

({ Th, Ad, P }, {{ Th } → { Ad, P }} ), 

({ A, M, Th, Ti, Pr }, {{ Th, Ti, M } → { Pr }} ), 

({ D, M }, {{ M } → { D }} ). 

Furthermore the second type can be decomposed. Thus we obtain: 

({ Th, Ad, P }, {{ Th } → { Ad, P }} , 

({ M, Th, Ti, Pr }, {{ Th, Ti, M } → { Pr }} , 

( { A, M, Th, Ti }, { key = { Th, Ti, M, A }} , 

({ D, M }, {{ M } → { D }} . 

The third type can be decomposed as well if we consider also the multivalued dependency discussed above. 

Mod IS 

IS ADD


The decomposition approach leads to a BCNF schemata and a lossless decomposition. 

Adequacy requires adding the corresponding inclusion constraints and path functional constraints. 

The decomposition approach can also be applied if multivalued dependencies are present. In this case we can generate 

normal forms higher than the BCNF such as the fourth normal form or the project/join normal form. The fourth normal 

form requires that each valid multivalued dependency in the type is a key dependency. Project/join normal form requires 

that each join dependency valid for the type is implied by the key dependencies valid for this type. 

The decomposition approach is well-based for sets of functional dependencies which are hierarchical. In this case, the leaf 

dependencies are used for decomposition. The schema obtained in this case is lossless and constraint preserving. If the set of 

functional dependencies cannot be represented in a tree then the decomposition approach produces a schema in BCNF which is 

not constraint preserving. 

For illustration let us extend the type Lecture in the university example. We also consider text books assigned to courses. 

Each course is offered in any number of sections. Each section has a lecturer and a number of teaching assistants (graders). 

Courses use for their section different labs. Slides and additional material are available for courses and sections. The type 

Lecture ∗ = ( Course, Text, Semester, Room, Lab, Material, 

Lecturer : Professor, Grader : Person 

{ Time(Day,Hour), Section } ) 

with the set of multivalued dependencies 

{ Course } →→ { Text }, 

{ Course, Section, Semester } →→ { Time }, 

{ Course, Section, Semester } →→ { Room }, 

{ Course, Section, Semester } −→ { Lecturer }, 

{ Course, Section, Semester } →→ { Grader }, 

{ Course, Section, Semester, Lecturer } →→ { Material }, 

{ Course, Section, Semester, Lecturer } →→ { Lab } 

represents the information on lectures. 

✮ 

Text 

Course 

✾ ✮ ✠ ❘ 

Lecturer Time Room Grader 

✠ ❘ 

Lab Material 

 

Section, Semester 

Abbildung 32: Tree Dependency in the Extended Relationship Type Lecture ∗ 

The constraints can be represented by a tree dependency, displayed in Figure 32. The dependency structure allows decomposition 

of the type Lecture ∗ into the types 

CourseText = ( Course , Text , ∅ ), 

Lecture 0 = (Course, Semester, { Section }), 

Lecture 1 = (Lecture 0 , { Time }), 

Lecture 2 = (Lecture 0 , Room, ∅ ), 

Lecture 3 = (Lecture 0 , Grader, ∅ ), 

Lecture 4 = (Lecture 0 , Lecturer, ∅ ), 

Lecture 41 = (Lecture 4 , Lab, ∅ ), 

Lecture 42 = (Lecture 4 , Material, ∅ ). 

We can prefer the following decomposition which is more appropriate in the application context: 

CourseText = ( Course , Text , ∅ ), 

LectureActual = (Course, Semester, Lecturer, Room, { Section, Time } ), 

LectureMaterial = (LectureActual, Material, ∅ ), 

LectureLab = (LectureActual, Lab, ∅ ), 

LectureGrading = (LectureActual, Grader, ∅ ) . 

In this case the grading results for each student are assigned to 

LectureGrading. 

Mod IS 

IS ADD


The decomposition approach does not lead to a lossless, constraint preserving and adequate schema if the dependency 

{ Course, Section, Semester, Lecturer } →→ { Material } 

is changed to the dependency 

{ Course, Semester, Lecturer } →→ { Material }. 

The latter constraint causes a split virtual key problem. This problem can be solved if additional redundant types are introduced 

with a corresponding explicit treatment of redundancy: 

LectureTerm = (Course, Semester, ∅ ), 

LecturerAssignment = (LectureTerm, Lecturer, { Section } ), 

LectureActual = (LecturerAssignment, Room, { Time } ), 

LectureMaterial = (LectureTerm, Lecturer, Material, ∅ ). 

The types LecturerAssigment and LectureMaterial are correlated by inclusion constraints and their components LectureTerm 

and Lecturer. 

We note that the decomposition steps can be applied to relationship types as well. In this case the components of other 

relationship types have to be changed as well. We shall consider this case below. 

2.5.3 Flaws of the Classical Synthesis Algorithm 

Erfassung der äquivalenten linken Seiten 

. 

Einige Synthesealgorithmen verzichten auf die Bildung von Äquivalenzklassen. Damit kann ggf. ein Schema entstehen, das 

zwar normalisiert, aber nicht sinnvoll ist. 

Es ist jedoch sinnvoll, die folgende Ergänzung vorzunehmen. 

Problem 

Problem dieser Vereinfachung: Es können unnötig viele Relationstypen erzeugt werden. 

Als Beispiel betrachte man das Schema 

({A, B, C}, {{A} → {B}, {B} → {C}, {C} → {A}}) 

das man ggf. nach der Reduktion erhalten hat. Dann entstehen drei neue Teilschemata. 

Behebung Es werden im ersten Schritt (1 (d)) der Normalisierung Äquivalenzklassen von Teilmengen von Attributmengen 

eingeführt. Dann wird eine Zusammenfassung der FD’s mit äquivalenten linken Seiten vorgenommen (statt gleiche linke Seiten). 

Die Sammlung erfolgt dann für eine Äquivalenzklasse. 

Im Beispiel gilt dann [{A}] = [{B}] = [{C}] und somit wird nicht dekomponiert. 

Pragmatische Separation von Schemata 

. 

Der klassische Normalisierungalgorithmus empfiehlt im vorletzten Schritt 

die Zusammenführung aller funktionalen Abhängigkeiten mit der gleichen rechten Seite. 

Man betrachte dazu folgende Relation: 

AG AGNummer Bezeichn Institut WebAdr Fax Sachgebiet Sekr.Ort Sekr.Tel EmailKontakt ... 

... ... ... ... ... ... ... ... ... ... 

AG AGNummer ... Lieferadr Besuchsadr Postadr Kostenstelle Leiter Anreisekarte ... 

... ... ... ... ... ... ... ... 

In dieser Relation ist das Attribut AGNummer ein Schlüssel, wobie durchaus andere sinnvolle Schlüssel existieren, z.B. das 

Attribut Kostenstelle. 

Beobachtung: Diese Relation vereinigt zuviele unterschiedliche Aspekte, die eigentlich getrennt werden sollten. 

Mod IS 

IS ADD


Eine günstige Darstellung findet man im folgenden Schema im erweiterten ER-Modell 3 . Sie zeigt auf, daß man die Arbeitsgruppeneigenschaften 

separieren kann in ArbeitsgruppeDirekt und ArbeitsgruppeFinanzen sowie als Option ArbeitsgruppeSekretariat. 

Es ist durchaus eine Separation von ArbeitsgruppeKontakt sinnvoll (aufgrund der Besonderheiten von Daten wie 

Karten). 

Fonds 

✻ 

Kostenstelle 

Sachgebiet 

✲ 

Sachgebiets- 

Klassifikation 

AGNummer 

Bezeichnung 

WebAdr 

... 

Fax 

❄ 

Arbeitsgruppe 

✻ ❑ 

✙ 

✛ 

■ 

Hauptzuordnung 

✲ 

Institut 

Tel 

Ort 

Sekretariat 

✻ 

Postadresse 

Lieferadresse 

Kontakt Besuchsadresse 

Anreisekarte 

EmailKontakt 

Sekretär(in) 

Leiter 

❄ 

Person 

✠ 

Abbildung 33: Ein HERM-Diagramm mit einer Separation von Gesichtspunkten 

2.5.4 Normalisation and its Impact 

Classical database books don’t tell the full truth about normalisation. Any (vertical) decomposition of a type T into types 

T 1 , ..., T n results in additional integrity constraints. 

Pairwise inclusion constraints: In the case of vertical decomposition we introduce pairwise inclusion constraints on components 

compon(T i ) of the types T i . 

T i [compon(T i ) ⊓ compon(T j )] ⊆ ⊇ T j [compon(T i ) ⊓ compon(T j )] ∀i, j(1 ≤ i < j ≤ n) 

We denote by ⊓ the componentwise intersection of the elements. 

Beobachtung 1. 

These pairing inclusion constraints have an impact on integrity maintenance and thus limit the impact of normalisation. 

2.5.5 Denormalisation Ruins Normalisation 

Strict local normalisation may be inadequate. Therefore a large number of publications, e.g., [Cel95, Dat05, SW05] advocate 

denormalisation whenever problems are observed within database structures. A theory of denormalisation has not yet been 

3 Unäre Relationship-Typen stellen u.a. auch Spezialisierungen dar, so daß der Typ Sekretariat z.B. auch die Identifikation vom Typ Arbeitsgruppe 

erbt. 

Die Darstellung der funktionalen Abhängigkeiten als (0,1)-Kardinalitäten sind dabei ausgelassen. 

Mod IS 

IS ADD


proposed as far as we know. Instead, a number of heuristic rules for denormalisation are provided. These rules are based on 

observations for performance traps for some of the platforms and often use the 80/20% rule. 

It is well known that denormalisation is bad for updates since they are harder to formulate and can jeopardise database 

integrity. Denormalisation may also lead to complications for query formulation. It becomes easier to formulate incorrectly 

a query to a request meaning that the query does not correspond to the request. Typically, tricky view creation is used for 

denormalised tables. Therefore, it seems that normalisation is the best way for optimisation of database behaviour. 

Despite these advantages of normalisation the denormalisation is considered a method for performance improvement method. 

It is based on precomputing derived data, on minimising the need of joins, on reducing the number of foreign keys in 

relations, on reducing the number of indexes and on reducing the number of relations. OLAP and data warehouse techniques 

rely on denormalisation. We shall however detect in the next sections that denormalisation can be minimised if global normalisation 

is applied. [LTN07] lists some key effects of thoughtful denormalisation: definite improvement in query time, a potential 

increase in update time or in storage space, a potential loss of data integrity due to certain deletions, the necessity for program 

transformations for all relevant queries and the overhead needed to reorganise some tables. 

Physical database design should follow logical database design. Logical database design should follow conceptual database 

design. We thus need the ‘Janus’ schema cluster for translating conceptual queries and programs to logical programs. Denormalisation 

is an approach to improve efficiency and performance of the database. Since we advocate co-design of structuring and 

functionality we develop a broader view to optimisation. Typical denormalisation techniques are 

• the introduction of controlled redundancy for avoiding joins, e.g. by copying attributes to other tables, 

• the introduction of nested types such as repetition groups, 

• the composition or join of tables which are separated by functional or multivalued dependencies and which would not be 

separated if exceptions for these dependencies would be separately stored, and 

• the maintenance of lookup tables that keep referenced values of other tables without having additional attributes. 

The first technique is supported by restrictions to modifications of redundant components and by flooding their values from the 

base table. The second technique is supported by modern object-relational systems. If nested types are used in minimal keys then 

surrogate key can be introduced. The third technique uses horizontal decomposition into the (rare) exceptional cases together 

with vertical decomposition of the exception table. The fourth technique uses enumeration domains and thus supports domain 

constraints. 

Mod IS 

IS ADD


2.10 Transformation von Schemata in andere Modelle 

Man kann für die Übersetzung zwei verschiedene Zugänge unterscheiden: 

Interpretation: Typen des Ausgangschemas werden in einer bestimmten Reihenfolge in Konstrukte der Zielsprache überführt. 

Compilierung: Eine Transformation kann zu Schemata führen, die ein ungünstiges Verhalten haben. Deshalb wird oft von 

einem Entwerfer erwartet, daß er nach einer Übersetzung das Zielschema ‘glättet’. Ein Compilierungszugang dagegen 4 

berücksichtigt Eigenschaften der Zielsprache bei der Übersetzung mit. Übersetzer können wie ein klassischer Compiler 

aufgebaut sein. 

siehe auch H.C. Mayr’s Vorlesungen 

siehe Embley-Kapitel im Handbuch 

Wir stellen zuerst einige Transformationstechniken vor. Diese Techniken stellen den Hintergrund der betrachteten Konzeptualisierung. 

Sie können bereits in diesem Schritt angewandt werden. Da wir uns hier jedoch vollständig auf den konzeptionellen 

Entwurf konzentrieren und nicht mit mehreren Entwurfsmodellen und -sprachen den Entwerfer verwirren wollen, dient die folgende 

Darstellung der Transformationstechniken nur dem Verständnis der folgenden Schritte. Erst im letzten Schritt wenden wir 

eine Transformation an. Dadurch wird gesichert, daß sich der Entwerfer nur mit einem Modell beschäftigen muß. Er kann die 

Transformation am Ende als vollständig automatisierbares Verfahren anwenden, ohne gezwungen zu sein, das physische oder 

das logische Schema im Detail zu betrachten. Spätere Änderungen oder Anpassungen sind dadurch stets auf konzeptionellen 

Niveau darzustellen. Dieser Vorteil rechtfertigt das Verschieben der Transformation auf den letzten Schritt. 

Grundkenntnisse. 

Übersetzungstechniken kann man analog zu den Ansätzen der Theorie der Programmiersprachen unterscheiden nach 

ER-Modellen: Es gibt eine Vielzahl von erweiterten Entity-Relationship-Modellen. Meist sind jedoch nur strukturelle Erweiterungen 

vorgeschlagen wurden. 

Einbeziehen von Integritätsbedingungen: Ein Schema hat implizite und explizite Integritätsbedingungen. Übersetzungstechniken 

verwenden oft nur einen Teil der entwickelten semantischen Bedingungen. 

Prozeßunterstützung: Einige erweiterte Entity-Relationship-Modelle lassen das explizite Modellieren von Prozessen z.B. 

durch Transaktionen zu. Andere dagegen erlauben keine Operationen. Aufgrund der Integritätserzwingungsmechanismen, 

die in Kapitel ?? bereits entwicklet wurden, sind generische Operationen bereits modelliert. Darüber hinausgehende 

Mechanismen können angewandt werden. 

Entwerferinteraktion: Einige Transformationstechniken sind nichtdeterministisch und lassen eine direkte Interaktion mit dem 

Entwerfer zu. 

Übersetzungsvoraussetzungen: Oft setzen Übersetzungen spezifische Normalformen voraus. Weiterhin werden oft Metaannahmen 

(unique-name-assumption u.a.) vorausgesetzt. 

Erhaltung der gesamten Entwurfsinformation: Es ist möglich, die gesamte Entwurfsinformation in das logische Zielmodell 

zu transformieren. Meist fehlt aber eine Umsetzung in ein physischen Modell, so daß darauf auch für physische Modelle 

verzichtet werden muß. 

Qualität des Zielschemas: Durch eine Reihe von Zugängen kann ein minimales, normalisiertes oder nichtredundantes Schema 

für verschiedene Arten von Ausgangsschemata erreicht werden. 

4 Die Arbeit Incremental translation of database schemas as an optimization process von N. Runge und P.C. Lockemann ist leider nach einer turbulenten 

EMISA-Tagung in Tutzingen 1996 nach unberechtigter Kritik von der Veröffentlichung zuruückgezogen worden. Wir verwenden diesen Ansatz aufgrund seiner 

Richtigkeit jedoch im weiteren. 

Mod IS IS ADD WebIS


2.10.1 Interpreter-Zugang 

Interpretation von ER-Konstrukten durch relationale Konstrukte. 

Fast alle Bücher und auch die entsprechenden Vorlesungen bieten nur den interpretierenden Zugang 

an!!! 

Mehrschrittverfahren wobei Semantik und Funktionalität mit übertragen werden muß 

Schlüssel und funktionale Abhängigkeiten in Schlüssel, funktionale und mehrwertige Abhängigkeiten 

implizite Komponenten in Inklusionsabhängigkeiten 

Exklusionsabhängigkeiten in Exklusionsabhängigkeiten 

Kardinalitätsbedingungen in funktionale, Inklusions- und No-null-Abhängigkeiten 

1. Herstellen der ersten Normalform (Tupelattribute durch Verkettungsregel, Mengenattribute entweder über Wiederholung 

in Tupeln oder durch eigene Relation); Neuberechnung der Schlüssel (bei Mengenattributen, die bislang im Schlüssel 

vorkamen, wird dann eine mehrwertige Abhängigkeit generiert und der Schlüssel verändert sich stark) 

2. Flache Entity-Typen werden in Relationenschema überführt 

3. Schwache flache Entity-Typen werden in Relationenschema übersetzt, wobei die Attributmenge um die Schlüssel der 

identifizierenden Schemas erweitert werden. 

4. Hierarchien von Typen sind in einem der folgenden Zugänge überführbar 

• event-nonseparation: Student, Professor, Person 

• event-separation: Student, Professor, AnderePerson 

• union: Person = Student + Professor + AnderePerson 

• weak universal relation: Person 

5. Relationship-Typen werden entsprechend ihrer Ordnung überführt 

• Binäre 1:1-Relationship-Typen : 

Mehrere Optionen: 

• Einbetten in vorhandenes Relationenschema (möglichst der ‘mandatory’-Seite; d.h. bei (1,1):(0,1)-Typen in 

ersten Typ) des Primärschl¨ssels des anderen Typen, sowie der Attribute des Relationship-Typen (Einfügen 

eines Fremdschlüssels) 

• Definieren eines separaten Relationenschemas mit Primärschlüssel der Komponenten und Attributen des Relationship- 

Typen 

• Zusammenfügen der beiden Relationenschemas unter Beifügung der entsprechenden Relationship-Typ-Attribute 

falls Attribute keine Nullwerte enthalten dürfen, dann nur bei (1,1):(1,1)-Typen 

• N-äre 1:...-Relationship-Typen (n > 2): 


• Einbetten in vorhandenes Relationenschema (möglichst der ‘mandatory’-Seite; d.h. bei (1,1):(0,1)...-Typen in 




Typen 



• Binäre 1:n-Relationship-Typen : 






Typen 

Mod IS


• N-äre 1:n...-Relationship-Typen (n > 2): 


• Einbetten in vorhandenes Relationenschema (möglichst der ‘mandatory’-Seite; d.h. bei (1,1):(0,1)...-Typen in 




Typen 

• n:m -Relationship-Typen 

Definieren eines separaten Relationenschemas mit Primärschlüssel der Komponenten und Attributen des Relationship- 

Typen 

• Rekursive Relationship-Typen 

wier normale Relationship-Typen aber unter Beibehaltung der Rollennamen 

• Is-A-Relationship-Typen 





Typen 



• Cluster 



Typen unter Einbeziehung der Rollennamen 

• Einbetten in vorhandenes Relationenschema (möglichst der ‘mandatory’-Seite) des Primärschl¨ssels des anderen 

Typen (Einfügen eines Fremdschlüssels) unter Beibehaltung der Rollennamen 

• Einführen eines virtuellen Clusters durch Nutzung der Indexisierung 

CREATE CLUSTER 

und damit eines Typs, der nur die Schlüssel vereinigt! 

Interpretation durch XML-Modelle (DTD). 

Nach Lipeck/Kleiner [KL02] 

Mod IS


Der Algorithmus nach Lipeck/Kleiner: 

Mod IS


Übersetzung von HERM in XML-Bäume. 

HERM ist besser geeignet als einfache ER-Modelle 

• Typen bereits genestete Struktur 

• Typen höherer Ordnung 

• unäre Kardinalitätsbeschränkungen mit Participation-Semantik 

HERM ist besser geeignet als UML 

• Typen haben klar definierte Semantik 

• Schematakomponenten sind integriert 

• durch Codesign auch Pragmatik und Entwicklungsmethodik 

XML ist Einschränkung von HERM 

• XML Schema und XForms geeignet für hierarchische Extrakte von HERM 

• HERM-Spezialisierung entspricht Schema-Typen-Spezialisierung 

• einelementige Kardinalitäten 

ansonsten clustering mit pivoting 

• Varianten von I-Objekten über XDNL-Zugang 

• XML - objekt-orientiertes hierarchisches Datenmodell 

• Mehrfach-Szenarien werden mit XDNL-Varianten verbunden 

damit ist Übertragung von HERM-Schemata in XML Schemata determiniert 

Übersetzung 

Mod IS


• Objektifizierung mit Master-Slave-Mirror 

für Auflösung mit ID’s 

alle Typen, auf die verwiesen wird 

unter Beachtung der Exklusionsabhängigkeiten 

• starke Aggregationen sind exklusiv (Komponente gehört zu genau einem Supertyp) 

• schwache (nicht-exklusive) Aggregationen werden in (evt. auch künstliche) Mirror-Beziehung abgebildet 

evt. mit Varianten je nach Interaktion un Szenarien 

• schrittweise Übersetzung von HERM-Typen von 0. Ordnung bis zu i. Ordnung 

Entity-Typen werden direkt übertragen 

Attributtypen sind auch in HERM exklusiv, gehören zu ER-Typen 

Cluster-Typen werden in Varianten übertragen 

Relationship-Typen werden ggf. auch kolladiert ((1, 1)(1, 1)-Typen) bzw. objektifiziert 

Hierarchien müssen nicht aufgelöst werden, sondern werden direkt als Subtypen realisiert 

• Sichten werden als Anfragen in XML-QL formuliert, falls nicht bereits in Schema-Definition eingegangen 

• Integritätsbedingungen der Datenbank für XML-Interaktion müssen spezifisch behandelt werden 

• Translationsmechanismus wird analog für die Datenbank mit HERM-Reengineering-Zugang erweitert 

damit ist dann Direktanbindung der Datenbank möglich 

Interpretation durch Netzwerk- und hierarchische Modelle. 

Netzwerkmodell 

Zwei Konstrukte: Recordtyp, Settyp 

stark implmentationsabhängig trotz Codasyl-Standards 

Recordtyp : Name, Menge von Attributen mit ihren Wertebereichen 

Attribute 

• einfache Attribute 

• mengenwertige Attribute: Vektor 

• zusammengesetzte mengenwertige Attribute: Wiederholgruppe 

Settyp : beschreibt 1-m-Beziehung zwischen Recordtypen 

Records, die mit mehreren anderen Records in Beziehung stehen: Owner 

die in Beziehung gesetzten: Member 

hat eigenen Namen und keine Attribute 

Settypen können auch mehrere Membertypen haben, meist wird jedoch Zweistelligkeit der Beziehung hervorgehoben 

und nur jeweils ein Membertyp zugelassen; damit dann graphische Repräsentation durch Bachman-Diagramme 

Settyp ist kein Mengentyp !! Codasyl empfiehlt Liste !! 


hält 

✲ 

Vorlesung 

Mod IS


Ein Pfeil wird von A nach B gezeichnet, wenn eine partielle Funktion von B C nach A C existiert. entgegen der 

Pfeilrichtung 

Settyp (Member-Records eines Sets) wird kann auf folgende Art und Weise implementiert: 

• entweder first/last: neuer Record stets als erstes/letztes Mitglied einer Set-Occurrence eingefügt 

• oder next/prior: Einfügen jeweils vor bzw. nach laufendem Pointer (z.B. letzte Anfrag) 

• oder System Default: wird durch System übernommen 

• oder Sortiert: nach Werten vorgegebener Attribute 

Einschränkungen : 

jeder Record - Member in höchstens einer Occurrence eines gegebenen Settyps 

Member-Record kann nicht im gleichen Settyp Owner sein 

erlaubt ist jedoch zusätzlich: 

ein Record kann mehrfach Owner-Record verschiedener Settypen sein 

ein Record kann gleichzeitig Member-Record verschiedener Settypen sein 

es können gleichzeitig mehrere Settypen zwischen gleichen Paaren von Recordtypen gebildet werden 

Abfederung der Inflexibilität durch: 

Set-Insertion-Option Einfügen eines neuen Member-Records vom Typ R 

• Automatisch: falls R Membertyp in Settyp S, dann neuer Record auch in S eingefügt 

• Manual: Einfügen in S ist Programmierersache 

Set-Retention-Option Member-Record vom Typ R in S löschen 

• Optional: Record kann ohne Mitgliedschaft in Set-Occurrence in DB existieren 

• Mandatory: Record muß in eine Occurrence eingebunden sein 

• Fixed: Record R muß in S verbleiben 

Da im obigen Schema Vorlesung kein Attribut haben darf: 

• entweder Hinzunahme der Vorlesungsattribute zum Professor 

• oder 

Übersetzung von ER-Schemata in Netzwerkdiagramme 

Verschiedene Strukturen müssen aufgelöst werden: 

• Relationship-Typen höherer Ordnung (> 1) bzw. Arität (> 2) 

• Relationship-Typen mit eigenen Attributen 

• rekursive Relationship-Typen 

• IsA-Relationship-Typen 

• z.T. 1-1-Beziehungen 

• Cluster 

Mod IS


Folgende Strukturen können im wesentlichen erhalten bleiben: 

• Entity-Typen mit genesteten Attributen 

• attributlose, binäre 1:n Relationshiptypen 

Übersetzung der Problemfälle 

• 1-1-Beziehungen ohne Attribute: entweder Zusammenfassen zu einem Typ oder Bildung eines Settyps für einen 

der beiden Typen 

• m-n-Beziehungen bzw. nicht-binaäre Beziehungen: Einführen mehrerer Settypen und eines Membertyps (Kett- 

Typ) mit Set-Beziehungen zwischen diesem und dem Ownertypen 

Attribute werden dem Kett-Typen zugeordnet 

• IsA-Beziehungen: wie 1-1-Beziehungen in umgekehrter Richtung 

Unterscheidung total/partiell geht verloren; muß über DML gelöst werden 

• Rekursive Typen: Duplizierung des Recordtyps mit Umbenennung oder Einbeziehung eines Dummy-Member- 

Typs 

Person 

IsA 

IsA 

❄ 


✠ 

Student 

✠ betreut 

hält 

❘ 

Vorlesung 

besucht wird-besucht 

❘ 

✠ 

Stud-Vorles 

Vorlesung 

Vorlesung 

Vorlesung 

setzt 

voraus IsA 

❄ ❄ 

Dummy 

wird vorausgesetzt 

von IsA 

✻ 

❄ 

Vorausges 

Vorlesung 

✻ wird vorausgesetzt 

von 

✻ 

IsA 

Vorausges 

Vorlesung 

Optimierung der Übersetzung durch entsprechende ER-Normalisierung 

Ersetzung der genesteten Strukturen durch flache: 

Mengennestung wird durch Einführung eines neuen Kett-Typs aufgehoben mit entsprechender Set-Typen-Einführung 

Mod IS


Tupelnestung wird verflacht 

Integritätsbedingungen sind Programmiereraufgabe bis auf: 

Domain-Bedingungen: mit CHECK-Klausel 

Intrarecord-Bedingung: duplicates are not allowed for < Attribut > 

ist aber keine Schlüsselbedingung 

Interrecord-Bedingung: gleichbenannte Attribute können über CHECK getestet werden (damit referentielle Integrität 

möglich) 

Hierarchisches Modell 

alle Daten durch Baumstrukturen dargestellt 

Datenbank durch Wald strukturiert 

Beziehungen sind 1:1 oder 1:n 

Wurzel ist nicht optional 

Mod IS


2.14 Ein Beispiel 

2.14.1 Ein HERM-Beispiel 

2.14.2 Die relationale Transformation des Beispieles 

Annahmen für die Transformation im Vorlesungsbeispiel: 

• volle ID-Entfaltung 

• rigides Nullwerte-Management 

• Separation von Schemadefintion und Integritätsbedingungen 

• minimale Indexunterstützung (nur Schl¨ssel (Primär- und Fremd-)) 

• minimale Menge von Wertebereichen 

• vollständige Verflachung 

• Auflösung aller Cluster-Typen 

• Event-Nonseparation mit Surrogat-Auflösung 

• Einbettung von (0,1)-*-Beziehungen 

• Namensgenerierung mit Präfixerweiterung und vorgegebener Präfixmenge, Trennung durch 

als Delimiter 

-- Database Section 

-- ________________ 

create database DB1_Vorlesungsbeipiel; 

-- DBSpace Section 

-- _______________ 

-- Table Section 

-- _____________ 

create table Studiengang ( 

ID_Stu char(10) not null, 

SName char(1) not null, 

Betreuer char(1) not null, 

Pruefungsamt char(6) not null, 

ID_Ins char(10) not null, 

primary key (ID_Stu)); 

create table Kurs ( 

ID_Kur char(10) not null, 

KursNr char(7) not null, 

Bezeichnung char(20) not null, 

primary key (ID_Kur)); 

create table Raum ( 

ID_Rau char(10) not null, 

Gebaeude char(4) not null, 

Raumnr numeric(5) not null, 

primary key (ID_Rau)); 



Name(First,Fam,{Title}) 

Person 

Adr(Zip,Town,Street(Name,Nr)) 

❃ 

❑ 

■ 

Person’s number 

Supervisor 

Since 

StudNr 

✙ 

Student 

❖ 

✠ 

■ 

Major 

Minor 

Department 

✸ 

Phones{Phone} 

Director 

✛ 

DName 

In 

✲ 

❃ 

❥ 


✻ 

Primary 

Investigator 

Speciality 

Member 

Result 

Time(Day,Hour) 

Enroll ✲ Lecture Has 

⊕ 

✾ 

✰ 

❄ 

Semester 

Year Season 

Nr 

Room 

Building 

✻ 

Course 

✻ 

CNu 

CName 

❄ 

Project 

Prerequis 

Begin 

Num 

End 

PName 

Abbildung 82: HERM-Diagram of the University Database 



create table Institut ( 


RaumSekret char(8) not null, 

Kostenstelle char(12), 

Telefon numeric(4) not null, 

IName char(1) not null, 

Sprecher char(15) not null, 

Fakultaet char(1) not null, 

primary key (ID_Ins)); 

create table Semester ( 

ID_Sem char(10) not null, 

Jahreszeit char(2) not null, 

Jahr numeric(4) not null, 

primary key (ID_Sem)); 

create table Projekt ( 

ID_Pro char(10) not null, 

Projektnr char(8) not null, 

Beschreibung varchar(90) not null, 

Bezeichnung char(20) not null, 

primary key (ID_Pro)); 

create table Student ( 


ID_Per char(10) not null, 

MatrNr char(7) not null, 

primary key (ID_Stu), 

unique (ID_Per)); 

create table Professor ( 



Spezialisierung char(1) not null, 

primary key (ID_Pro), 

unique (ID_Per)); 

create table Person ( 


Geburtsort char(15) not null, 

Adresse char(40) not null, 

Personenname char(25) not null, 

Geburtsdatum date not null, 

primary key (ID_Per)); 

create table Betreuer ( 



von date not null, 

bis date, 

Thema varchar(30) not null, 

primary key (ID_Pro, ID_Stu)); 

create table eingeschrieben in ( 

E_S_ID_Stu char(10) not null, 



bis date not null, 

primary key (ID_Stu, E_S_ID_Stu)); 



create table hoert ( 


ID_Vor char(10) not null, 

Resultat char(10) not null, 

Note char(2), 

primary key (ID_Vor, ID_Stu)); 

create table Projektmitarbeiter ( 



P_P_ID_Pro char(10) not null, 

primary key (ID_Pro), 

unique (ID_Stu), 

unique (P_P_ID_Pro)); 

create table Vorlesung ( 

ID_Vor char(10) not null, 

Wochentag char(2) not null, 

Block char(2) not null, 

Nummer char(9) not null, 


ID_Sem char(10) not null, 

ID_Rau char(10) not null, 

ID_Kur char(10) not null, 

primary key (ID_Vor)); 

create table In ( 


Seit char(1) not null, 


primary key (ID_Pro)); 

create table wirkt mit ( 

W_P_ID_Pro char(10) not null, 


bis date not null, 

Kontraktnr char(6) not null, 


primary key (ID_Pro, W_P_ID_Pro)); 

-- Constraints Section 

-- ___________________ 

alter table Studiengang add constraint FKverantwortlich fuer 

foreign key (ID_Ins) 

references Institut; 

--alter table Student add constraint 

-- check(exists(select * from eingeschrieben in 

-- where eingeschrieben in.E_S_ID_Stu = ID_Stu)); 

alter table Student add constraint FKPer_Stu 

foreign key (ID_Per) 

references Person; 

--alter table Professor add constraint 

-- check(exists(select * from In 

-- where In.ID_Pro = ID_Pro)); 



alter table Professor add constraint FKPer_Pro 

foreign key (ID_Per) 

references Person; 

alter table Betreuer add constraint FKBet_Stu 

foreign key (ID_Stu) 

references Student; 

alter table Betreuer add constraint FKBet_Pro 

foreign key (ID_Pro) 

references Professor; 

alter table eingeschrieben in add constraint FKein_Stu_1 


references Studiengang; 

alter table eingeschrieben in add constraint FKein_Stu 

foreign key (E_S_ID_Stu) 


alter table hoert add constraint FKhoer_Vor 

foreign key (ID_Vor) 

references Vorlesung; 

alter table hoert add constraint FKhoer_Stu 



alter table Projektmitarbeiter add constraint FKStu_Pro 



alter table Projektmitarbeiter add constraint FKPro_Pro 

foreign key (P_P_ID_Pro) 


alter table Vorlesung add constraint FKliest 



alter table Vorlesung add constraint FKim 

foreign key (ID_Sem) 

references Semester; 

alter table Vorlesung add constraint FKveranstaltet 

foreign key (ID_Rau) 

references Raum; 

alter table Vorlesung add constraint FKzu 

foreign key (ID_Kur) 

references Kurs; 

alter table In add constraint FKIn_Pro 



alter table In add constraint FKIn_Ins 

foreign key (ID_Ins) 

references Institut; 



alter table wirkt mit add constraint FKwir_Pro_1 


references Projektmitarbeiter; 

alter table wirkt mit add constraint FKwir_Pro 

foreign key (W_P_ID_Pro) 

references Projekt; 

-- Index Section 

-- _____________ 

create unique index ID 

on Studiengang (ID_Stu); 

create index FKverantwortlich fuer 

on Studiengang (ID_Ins); 


on Kurs (ID_Kur); 


on Raum (ID_Rau); 


on Institut (ID_Ins); 


on Semester (ID_Sem); 


on Projekt (ID_Pro); 


on Student (ID_Stu); 

create unique index FKPer_Stu 

on Student (ID_Per); 


on Professor (ID_Pro); 

create unique index FKPer_Pro 

on Professor (ID_Per); 


on Person (ID_Per); 

create unique index IDBetreuer 

on Betreuer (ID_Pro, ID_Stu); 

create index FKBet_Stu 

on Betreuer (ID_Stu); 

create index FKBet_Pro 

on Betreuer (ID_Pro); 

create unique index IDeingeschrieben in 

on eingeschrieben in (ID_Stu, E_S_ID_Stu); 



create index FKein_Stu_1 

on eingeschrieben in (ID_Stu); 

create index FKein_Stu 

on eingeschrieben in (E_S_ID_Stu); 

create unique index IDhoert 

on hoert (ID_Vor, ID_Stu); 

create index FKhoer_Vor 

on hoert (ID_Vor); 

create index FKhoer_Stu 

on hoert (ID_Stu); 


on Projektmitarbeiter (ID_Pro); 

create unique index FKStu_Pro 

on Projektmitarbeiter (ID_Stu); 

create unique index FKPro_Pro 

on Projektmitarbeiter (P_P_ID_Pro); 


on Vorlesung (ID_Vor); 

create index FKliest 

on Vorlesung (ID_Pro); 

create index FKim 

on Vorlesung (ID_Sem); 

create index FKveranstaltet 

on Vorlesung (ID_Rau); 

create index FKzu 

on Vorlesung (ID_Kur); 

create unique index FKIn_Pro 

on In (ID_Pro); 

create index FKIn_Ins 

on In (ID_Ins); 

create unique index IDwirkt mit 

on wirkt mit (ID_Pro, W_P_ID_Pro); 

create index FKwir_Pro_1 

on wirkt mit (ID_Pro); 

create index FKwir_Pro 

on wirkt mit (W_P_ID_Pro); 



Literatur 

[AFT92] S. S. Al-Fedaghi and B. Thalheim. The key concept in database models. Unpublished manuscript, 1992. 

[AHV95] S. Abiteboul, R. Hull, and V. Vianu. Foundations of databases. Addison-Wesley, Reading, MA, 1995. 

[All84] J.F. Allen. Towards a general theory of action and time. Artificial intelligence, (6):123–154, 1984. 

[AT93] 

[BDK92] 

[Bis95] 

[BM97] 

[BS00] 

[BS03] 

P. Atzeni and R. Torlone. A metamodel approach for the management of multiple models and the translation 

of schemes. Information Systems, 18(6):349–362, 1993. 

P. Buneman, S. Davidson, and A. Kosky. Theoretical aspects of schema merging. In A. Pirotte, C. Delobel, 

and G. Gottlob, editors, Proc. 3rd Int. Conf. on Extending Database Technology - EDBT’92, LNCS 

580, pages 152–167, Vienna, 1992. Springer, Berlin/New York. 

J. Biskup. Foundations of information systems. Vieweg, Wiesbaden, 1995. In German. 

E. Börger, , and L. Mearelli. Integrating ASM into the software development life cycle. J. Universal 

Computer Science, 3(5):603–665, 1997. 

E. Börger and W. Schulte. Architecture Design and Validation Methods, chapter Modular design for the 

Java virtual machine architecture, pages 297–357. Springer, Berlin, 2000. 

E. Börger and R. Stärk. Abstract state machines - A method for high-level system design and analysis. 

Springer, Berlin, 2003. 

[BT92] C. Beeri and B. Thalheim. Identification is well-founded in object-oriented databases. Manuscript, 1992. 

[BT95] C. Beeri and B. Thalheim. Can I see your identification, please? - Identification is well-founded in 

object-oriented databases. Manuscript, Cottbus/Jerusalem, 1995. 

[BT99] 

[Cad76] 

C. Beeri and B. Thalheim. Identification as a primitive of database models. In Proc. FoMLaDO’98, pages 

19–36. Kluwer, London, 1999. 

J.-M. Cadiou. On semantic issues in the relational model of data. In A. W. Mazurkiewicz, editor, Proc. 5th 

Symp. on Mathematical Foundations of Computer Science - MFCS’76, LNCS 45, pages 23–38, Gdańsk, 

1976. Springer, Berlin. 

[CCN80] P. P. Chen, I. Chung, and F. Nakamura. Entity-relationship normal forms. unpublished manuscript, 1980. 

[Cel95] 

[CGT90] 

[CL73] 

J. Celko. Joe Celko’s SQL for smarties - Advanced SQL programming. Morgan Kaufmann, San Francisco, 

1995. 

S. Ceri, G. Gottloba, and L. Tanca. Logic programming and databases. Springer, Heidelberg/New York, 

1990. 

C. L. Chang and R. C. T. Lee. Symbolic logic and mechanical theorem proving. Academic Press, New 

York, 1973. 

[Das92] S. K. Das. Deductive databases and logic programming. Addison-Wesley, Wokingham, England, 1992. 

[Dat05] C.J. Date. Database in depth: Relational theory for practitioners. O’Reilly, Sebastopol, 2005. 

[DMT04] 

J. Demetrovics, A. Molnar, and B. Thalheim. Graphical and spreadsheet reasoning for sets of functional 

dependencies. In ER’2004, LNCS 3255, pages 54–66, 2004. 



[DMT07] 

[EN89] 

[EWH85] 

[Fag81] 

[Fownn] 

[Gog94] 

J. Demetrovics, A. Molnar, and B. Thalheim. Graphical axiomatisation of sets of functional dependencies 

in relational databases. In Alkalmazott Matematikai Lapok, volume 24, pages 223–264. 2007. 

R. Elmasri and S. B. Navathe. Fundamentals of database systems. Benjamin/Cummings, Redwood City, 

1989. 

R. Elmasri, J. Weeldreyer, and A. Hevner. The category concept: An extension to the entity-relationship 

model. DKE, 1(1):75–116, 1985. 

R. Fagin. A normal form for relational data bases that is based on domains and keys. ACM TODS, 

6(3):387–415, 1981. 

M. Fowler. Analysemuster. Addison-Wesley, 1999, Bonn. 

M. Gogolla. An extended entity-relationship model - fundamentals and pragmatics. LNCS 767. Springer, 

Berlin, 1994. 

[Gol06] R. Goldblatt. Topoi: The Categorial Analysis of Logic. Dover Books on Mathematics, 2006. 

[GSS89] 

G. Gottlob, M. Schrefl, and M. Stumptner. On the interaction between closure and functional dependencies. 

LNCS 364, pages 187–206, Visegrád, Hungary, Jun 26 - 30, 1989, 1989. Springer, Berlin. 

[Hal95] T. A. Halpin. Conceptual schema and relational database design. Prentice-Hall, Sydney, 1995. 

[HL07] 

[HLM93] 

[Hoh93] 

[KL02] 

[Kle07] 

[KR97] 

S. Hartmann and S. Link. English sentence structures and eer modeling. In APCCM, volume 67 of 

CRPIT, pages 27–35. Australian Computer Society, 2007. 

W. L. Hürsch, K.-J. Lieberherr, and S. Mukherjea. Object-oriented schema extension and abstraction. In 

Proc. 1993 ACM/SIGAPP Symp. on Applied Computing: States of the Art and Practice - SAC’93, pages 

54–62, Indianapolis, 1993. ACM Press, New York. 

U. Hohenstein. Formale Semantik eines erweiterten Entity-Relationship-Modells. Teubner, Stuttgart, 

1993. 

Carsten Kleiner and Udo W. Lipeck. Automatische Erzeugung von XML DTDs aus konzeptuellen Datenbankschemata. 

Datenbankspektrum, 1(2):14–22, 2002. 

M. Klettke. Modellierung, Bewertung und Evolution von XML-Dokumentkollektionen. Advanced PhD 

(Habilitation Thesis), Rostock University, Faculty for Computer Science and Electronics, 2007. 

H.-J. Klein and J. Rasch. Value based identification and functional dependencies for object databases. 

In Proc. 3rd Basque Int. Workshop on Information Technology, pages 22–34. IEEE Computer Science 

Press, New York, 1997. 

[Lei60] G.W. Leibniz. Fragmente zur Logik. Berlin, 1960. 

[Leo92] M. Leonard. Database design theory. MacMillan, Houndsmills, 1992. 

[LTN07] S. Lightstone, T. Teorey, and T. Nadeau. Physical database design. Morgan Kaufmann, 2007. 

[MN83] J. Minker and J.-M. Nicolas. On recursive axioms in deductive databases. Information Systems, 8(1):1– 

13, 1983. 

[Mok97] W. Y. Mok. On keys and normal forms. Information Processing Letters, 62(5):255–258, 1997. 

[MR92] 

H. Mannila and K.-J. Räihä. The design of relational databases. Addison-Wesley, Wokingham, England, 

1992. 



[MR98] 

J. A. Makowsky and E. V. Ravve. Dependency preserving refinements and the fundamental problem of 

database design. DKE, 24(3):277–312, 1998. Special Issue: ER’96 (ed. B. Thalheim). 

[PBGG89] J. Paredaens, P. De Bra, M. Gyssens, and D. Van Gucht. The structure of the relational database model. 

Springer, Berlin, 1989. 

[PS89] 

[RK02] 

C. Parent and S. Spaccapietra. Complex objects modelling: An entity-relationship approach. In S. Abiteboul, 

P. C. Fischer, and H.-J. Schek, editors, Nested Relations and Complex Objects, Workshop Theory 

and Applications of Nested Relations and Complex Objects, LNCS 361, pages 272–296, Darmstadt, 1987, 

1989. Springer, Berlin. 

J. Rasch and H.-J. Klein. Database Integrity: Challenges and Solutions, chapter Functional Dependencies 

for Value Based Identification in Object-Oriented Databases, pages 250–292. Idea Group Publishing, 

2002. 

[Sch77] J. W. Schmidt. Some high level language constructs for data of type relation. ACM TODS, 2(3):247–261, 

1977. 

[Sch94] 

[SI91] 

K.-D. Schewe. The specification of data-intensive application systems. Advanced PhD (Habilitation 

Thesis), Brandenburg University of Technology at Cottbus, Faculty of Mathematics, Natural Sciences 

and Computer Science, 1994. 

D.-G. Shin and K. B. Irani. Fragmenting relations horizontally using a knowledge-based approach. IEEE 

TSE, 17(9):872–883, 1991. 

[SS83] G. Schlageter and W. Stucky. Datenbanksysteme: Konzepte und Modelle. Teubner, Stuttgart, 1983. 

[ST93] 

[ST98] 

K.-D. Schewe and B. Thalheim. Fundamental concepts of object oriented databases. Acta Cybernetica, 

11(4):49–81, 1993. 

K.-D. Schewe and B. Thalheim. Readings in object-oriented databases. Reprint, BTU-Cottbus, accessible 

through http://www.is.informatik.uni-kiel.de/∼thalheim, Collection of papers by C. Beeri, K.-D. Schewe, 

J.-W. Schmidt, D. Stemple, B. Thalheim, I. Wetzel, 1998. 

[SW05] G. Simsion and G.C. Witt. Data modeling essentials. Morgan Kaufmann, San Francisco, 2005. 

[Teo89] 

T. J. Teorey. Database modeling and design: The entity-relationship approach. Morgan Kaufmann, San 

Mateo, 1989. 

[Tha85] B. Thalheim. Abhängigkeiten in Relationen. PhD thesis, TU Dresden, 1985. 

[Tha90] A. Thayse, editor. From modal logic to deductive databases. John Wiley & Sons, vol. 1: 1989, vol. 2: 

1990. 

[Tha91a] B. Thalheim. Dependencies in relational databases. Teubner, Leipzig, 1991. 

[Tha91b] B. Thalheim. Reconsidering key and identifier definitions in database models. Technical Report CS - 08 

- 91, Rostock University, Computer Science Department, 1991. 

[Tha00] B. Thalheim. Entity-relationship modeling – Foundations of database technology. Springer, Berlin, 2000. 

[TL82] D. Tsichritzis and F. H. Lochovsky. Data Models. Prentice-Hall, Englewood Cliffs, 1982. 

[Vin94] 

M. W. Vincent. The semantic justification for normal forms in relational database design. PhD thesis, 

Monash University, Melbourne, 1994. 



[Vos87] 

G. Vossen. Datenmodelle, Datenbanksprachen und Datenbank-Management-Systeme. Addison-Wesley, 

Bonn, 1987. (2nd edition, 1994). 

[VS93a] M. W. Vincent and B. Srinivasan. A note on relation schemes which are in 3NF but not in BCNF. 

Information Processing Letters, 48(6):281–283, 1993. 

[VS93b] 

[Wan98] 

M. W. Vincent and B. Srinivasan. Redundancy and the justification for fourth normal form in relational 

databases. Journal of Foundations of Computer Science, 4(4):355–365, 1993. 

G. Wanner. Entwurf eines objektorientierten Datenbankmodells für relationale Datenbanksysteme. DIS- 

BIS 46. infix-Verlag, 1998. 

[Wit58] L. Wittgenstein. Philosophical Investigations. Basil Blackwell, Oxford, 1958. 

[Yan86] C.-C. Yang. Relational Databases. Prentice-Hall, Englewood Cliffs, 1986. 

[YT89] 

M. Yaseen and B. Thalheim. Practical database design methodologies. Technical report, Kuwait University, 

Faculty of Science, 1989. 

[ZB92] J. Zhou and P. Baumann. Evaluation of complex cardinality constraints. LNCS 645, pages 24–40, 

Karlsruhe, Germany, Oct. 7 - 9, 1992, 1992. Springer, Berlin.

Analysis, Design and Development of Information Systems ...

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?