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 für zusätzliches Material.
Forschung
Hintergrundinformation (auch Inhalte der Grundvorlesungen)
Zusatzliteratur und Lesestoff
1 Einführung
In den Vorlesungen werden vier zentrale Spezifikationssprachen zur Spezifikation von Informationssystemen im
Co-Design-Zugang vorgestellt: die Strukturierung und die Funktionalität auf der Grundlage des erweiterten EntityRelationship-Modellen HERM, die Verteilung auf der Grundlage der Verteilungsspezifikationsprache DistrLang und
die Spezifikation durch die Web-Informationssystem-Spezifikationssprache SiteLang.
Übungen: jeweils eine Übung zur Spezifikation der Strukturierung, zur Spezifikation der Funktionalität, zur Spezifikation der Medientypen und zur Spezifikation der Interaktivität.
Es werden die Systeme ERWin und Silverrun, sowie DBMain zur Modellierung der Strukturierung bzw. Funktionalität eingesetzt.
2 Strukturierung von Informationssystemen
Strukturierung = Struktur + statische Integritätsbedingungen (+ Modellinhärentes !!!)
HERM : higher-order entity-relationship model
EER : extended ER model (meist auch nur fü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 adäquat ist. In [HL07] wurde dazu ein Vergleich von englischen Sprachä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
CAU zu Kiel, IfI, ISE, β
English
sentence
concept
transitive verb
common noun
adjective
adverb
numerical expression
gerund
clause
complex sentence
2. Strukturierung von IS
ab SS 2012
153
ER feature
relationship type
entity type
attribute of entity type
attribute of relationship type
attribute of entity or relationship type
relationship-converted entity type
high-level entity type abstracted from group of interconnected low-level entity and
relationship types
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 Grundzü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
• Äquivalenzbegriff für Sprachkonstrukte
• rigide Trennung von Klassen und Typen, aber 1-1-Bindung von Klassen an Typen
• Abbildungseigenschaften
• Wohlfundiertheit
• Einschränkung auf Mengensemantik, keine Kollektionssemantik
• Visualisierung
• Skalierbarkeit/Modularisierbarkeit der Sprachäußerungen je nach Auffassungsmöglichkeiten
Modularisierbarkeit als Option
Modular modelling supports information abstraction and hiding by encouraging and facilitating the decomposition of systems [BM97] into components
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
154
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 fü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
static
non-updatable
by any agent
derived
dynamic
indirectly indirectly indirectly
monitored controlled shared
out
in (monitored) controlled shared (interaction)
updatable
updatable
non-updatable updatable
by agent
by agent
by agent
by agent
controlled 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 wä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.
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
155
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
¼
s
flat
(first-order)
(uncontrolled)
(one-dimensional)
ª
ª
R
q
second-order
mixed
(skeleton-based flat)
controlled
R
ª
modular
(design by modules)
R
inside-out
(by neighborhood)
1. design central type
1. design general
1. design basic modules 2. (recursion step)
module schema
with interface
(bottom-up or top-down)
design next level
1. design all
2. (iteration step)
1. design
(skeleton)
(bottom-up or
basic concepts
connect modules
top-down)
2. build more all main concepts 2. refine each module
or
design
(bottom-up or
complex concepts 2. refine concepts
design or attach
combined modules
top-down)
concept
from them
bottom-up
top-down
Abbildung 2: Structure-Oriented Specification Strategies
• Integritä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
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
156
• Lokale Sichten werden mit der Schema-Algebra über dem konzeptuellen Schema als abgeleitetes Konzept
verwendet
Damit (S, V1 , ...., Vk ) als Modell, das den Anspruch erfüllen könnte, kognitiv vollständig zu sein.
Siehe Arbeit von B. Thalheim zur kognitiven Vollständigkeit der Modellierung mit einem erweiterten
ER-Modell.
• als klassischer Zugang
Alternativ könnte auch der Global-As-View-Ansatz verwendet werden.
• Damit wird eine natürlichere Form der Repräsentation gewählt.
• Damit kann auch unterschiedliche Abstraktion und Granularität verwendet werden.
• Kompromiß ist der sichtenzentrierte Entwurf.
• ((V1 , ..., Vk ), Association Constraints) als Modell-Suite (siehe B. Thalheim, A. Dahanayake)
• Man könnte hier den Komponenten-Zugang nach Thalheim/Hegner verwenden.
Unterschiedliche HERM-Annahmen je nach Abstraktionsschicht
• mit Identifikation
• mit partiellen Constraintmengen (z.B. nur ein Schlüssel)
• Schemavollständigkeitskriterium
Pragmatische strikte Unterscheidung
Wir unterscheiden in modernen Sprachen zwischen
Einführung von Variablen, Daten, die damit auch Rechte an der Modifikation und am Auslö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 Auslö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
Mod IS
as a matter of convenience.
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
157
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 Einführungskapitels betrachtet.
The four fundamental structural relations used for construction abstraction are:
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
158
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 Enzyklopädie der Datenbanksysteme: Langfassung hier (in Enzyklopä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:
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
159
Structural specialisation T 0 ¹St T : The structure S 0 is a substructure of S. An embedding function η exists which relates each object in
T 0 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 0C of the type T 0 is a subclass of T C , i.e., we require that for each o0 ∈ T 0C an o ∈ T C exists such that o = η(o0 ).
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 0 ¹Se T : The logical language of T 0 can be mapped onto the logical language of T in such a way that the
constraints on T 0 are stronger than the constraints on T , i.e., a mapping θ from LT 0 to LT exists such that θ(Σ0s ) |= Σs . The constraints used
in T 0 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 0 ¹St,Se T is defined on the basis of both mappings η and θ whereas θ is created using η as the
mapping primitive.
Pragmatical specialisation T 0 ¹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 0C represent the additional properties that context requires.
Operational specialisation T 0 ¹Op T : The operations defined for T can also be applied to T 0 objects.
The strong operational specialisation T 0 ¹St,Op T requires that mappings η : Struc0 → Struc, θ : LT 0 → LT and ζ : Ops0 → Ops
exist which commute, i.e., for any n-ary operation o0 from Ops and arbitrary objects o01 , ..., o0n from T 0 t the equality η(o0 (o01 , ..., o0n )) =
ζ(o0 )(η(o01 ), ..., η(o0n )) and ζ(θ(Σ0d )) |= Σd .
Type specialisation T 0 ¹T ype T requires strong operational and strong semantic specialisation.
Is-A specialisation T 0 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 0C specialise those in T C or are not applicable to T .
Is-A-Role-Of specialisation T 0 Is − A − Role − Of T requires structural, pragmatical and strong semantic specialisation. We require that
the additional properties of objects in T 0C 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.
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
160
Modellierungsstil im HERM
Aus den Annahmen heraus können wir uns einen spezifischen Modellierungsstil leisten:
Mengensemantik als prä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 gegenüber der prozeß-orientierten Spezifikation
Inhärente Unvollständigkeit der Spezifikation wird toleriert.
Agenten-orientierte Spezifikation fü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 für jede Einheit
z.B. Typen sind entweder Attribut- oder ... Cluster-Typen
• Eine linguistische Semantik der Namen für Einheiten kann verwendet werden.
Es wird dazu ein Stil der Benennung im Vornherein vereinbart und dann eingehalten.
Wir verwenden damit für alle Namen eine Minisemantik.
• Es wird eine Pragmatik für die Repräsentation zugelassen und vorher vereinbart.
• Wir unterscheiden explizit zwischen Rolle und Objektexistenz.
Kern-Objekte sind in der Existenz unabhä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
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
Finiteness
Finite
Infinite
2. Strukturierung von IS
Granularity
Discrete
Continuous
Discrete
Continuous
Textual
Text-enumerated
-
ab SS 2012
Expression
Symbolic
Symbol-enumerated
Symbol-floating-enumerated
-
161
Numeric
Integer-enumerated
Floating-enumerated
Integer
Floating-point
Eine Sprache zur Beschreibung der Strukturierung von Datenbank-Anwendungen verfügt ü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 Prädikatenlogik (der ersten Stufe) gegeben. Deshalb lassen sich dann statische Integritätsbedingungen als Formeln der Prädikatenlogik mit einer Standardinterpretation angeben. Mit der
Sprachkonstruktion und mit Annahmen aus dem Umfeld werden implizite Integritä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 Integritätsbedingungen einer Anwendung (meist für die zusätzliche Beschränkung evt. in einer Anwendung vorkommender Daten) und
Common-sense-Annahmen (über das Modell, die Modellierungsart, über die Interpretation der Daten etc.).
Damit wird das Wissen über die statischen Gesichtspunkte einer Anwendung modelliert durch:
Die Spezifikation der Struktur in Abhä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 Berü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 einschränkende Bedingungen für wirklichkeitsgetreue Nachbildung der Anwendung wie
• die eindeutige Bestimmung aller Objekte durch Schlüsselbedingungen,
• die Hierarchie der Objekte (Aussonderungsbedingungen (specialization, IsA), Verallgemeinerungsbedingungen (partition constraints, uniqueness constraints))
• und Bedingungen fü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 (inhärente Bedingungen des Modells) wie die folgenden:
• Gesamtheitsregel (universe of discourse)
• Verneinungsregel
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
162
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 läßt sich somit wie folgt charakterisieren:
• Typen sind über ihre Typausdrücke definiert. Den (freien) Variablen werden wiederum Typen zugeordnet.
• Die Zuordnungsvorschrift für Typausdrücke kann sowohl hierarchisch als auch zyklisch sein. Wählt man
eine zyklische Struktur, dann sind meist nur Topoi-Semantiken geeignet. Wä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 Veränderung. Man kann diese Operationen generisch
definieren, wenn die Typenstruktur hierarchisch aufgebaut ist. Einige Operationen können auch Prä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” für die Objekte des jeweiligen Typs dar.
• Die assoziierte statische Semantik der Typen muß zu jedem Zeitpunkt für eine Klasse erfüllt sein.
• Die Operationen der Typen werden auf Klassen ausgeführt.
Wir bezeichnen Typen mit ihrem Namen, z.B. T und die zugehörigen Klassen mit einer Annotation zum Typennamen, z.B. T C (C steht für Klasse).
Es sind verschiedene Modelle möglich. Jedes Modell ist durch eine Menge von inhärenten Bedingungen gekennzeichnet. Jeder benutzte Typ hat neben Konstruktor, Selektoren (für Retrieval) und Updatefunktionen, Korrektheitskriterien, default-Regeln auch eine Benutzerrepräsentation und eine physische Repräsentation.
Günstig ist eine graphische Repräsentation.
Eines der populärsten Modelle ist das Entity-Relationship-Modell. Wir erweitern dieses Modell zu einem
Higher-Order Entity-Relationship-Modell (HERM).
2.2.1 Attribut-Typen
kö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 Abkürzung), einen Wertebereich dom(T ), eine Menge von Funktionen ops(T ) und eine Menge pred(T ) von Prädikaten.
Oft wird auch der Basis-Datentyp mit einem Informationstyp assoziiert.
Ein Beispiel ist der Typ der ganzen Zahlen in der 4-Byte-Repräsentation
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
163
integer := (IntegerSet4Byte , {0, s, +, -, *, ÷, }, { =, ≤ }) mit der Nachfolgefunktion s .
Basis-Datentypen verfügen neben dem Wertebereich auch über Funktionen und Prädikate. Sie sind außerdem
durch eine Reihe von Eigenschaften eingeschränkt, die im Datenbanksystem zu beachten sind und oft im Entwurf übersehen werden:
• Die Präzision und Genauigkeit sind ggf. für Typen wie REAL eingeschränkt.
• Die Granularität von Daten kann sehr unterschiedlich sein. Die Skalierung von Datentypen kann sich
ggf. auch auf die Funktionalität auswirken.
• Datentypen verfügen nur ggf. über eine eigene Ordnungsbeziehung.
• Datentypen verfügen ggf. ü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 können über unterschiedliche Präsentationsformen verfügen. Das Format umfaßt Länge und
Größe.
• Datentypen können auf unterschiedliche Art abgespeichert werden.
• Datentypen verfügen über eigenständige Default- und Nullwerte.
• Datentypen können durch Casting-Funktionen aufeinander abgebildet werden.
• Datentypen sind bestimmten Anwendungen und Arbeitsgebieten zugeordnet.
• Die Funktionen und Prä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 müssen.
Basis-Datentypen sind meist auch in einem Typenverband geordnet.
Neben den Basis-Datentypen des DBMS kann auch eine Anwendung über eigene Basis-Datentypen verfügen.
Wir können z.B. den Typ varnumbersequence20 zur Darstellung von Telefonnummern mit einer angepaßten
Ordnungsbeziehung und ohne Unterdrückung führender Nullen einführen. Analog kann ein Typ EmailTyp oder
URL eingeführt werden.
Kind of data type
extension based
absolute
ratio
intension based
nominal
ordinal
rang
interval
Natural order
Natural zero
Predefined functions
+
+
+/+/-
+/+(type dependent)
+
+
+
+
-
(-) (except concatenation)
(+)(e.g., concatenation)
Example
number of boxes
length, weight
names of cities
preferences
competitions
time, space
Tabelle 1: Data types and their main canonical assumptions
Attribut-Typen werden über einem Basis-Datentypen-System und einem Markierungssystem L für Attributnamen
induktiv ausschließlich durch die folgenden beiden Regeln definiert:
• Ein Attribut-Typ ist fü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 ⊥.
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
164
• Sind X1 , ..., Xn , Y Attribut-Typen und A, B, C, D Markierungen, dann sind A(X1 , ..., Xn ) (Tupel- oder
Produkt-Konstruktor), A{Y } (Mengen-Konstruktor), A < Y > (Listenkonstruktur), A[Y ] (Konstruktor
für optionale Elemente), A{| Y |} (Konstruktor für Multimengen).
Die entsprechenden Wertebereiche sind durch Anwendung der Konstruktion gegeben, z.B.
dom(A(X1 , ..., Xn )) = dom(X1 ) × ... × dom(Xn ) und dom(A{Y }) = 2dom(Y ) .
Markierungen können auch weggelassen werden.
Beispiele von komplexeren Attributen sind
Name (Vornamen<(Vorname :: varstring15 , Benutzung :: string1)>,
Familienname :: varstring30, [Geburtsname :: varstring30,]
·
[Titel:{AkademischeTitel :: varstring10 } ∪ FamilienTitel :: varstring10])
Kontakt (Tel({dienstl :: varnumbersequence20 }, privat :: varnumbersequence20),
email :: emailType, ...)
Geburtsdatum :: date .
Attribute können in einer verkü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
?
( ... )
z
9
Vornamen
?
< ... >
?
( ... )
)
Vorname
ª
Familienname
?
varstring30
q
Benutzung
?
string1
[
... ]
?
Geburtsname
?
varstring30
z
9
... }
?
AkademischeTitel
?
varstring10
{
?
varstring15
[ ... ]
?
Titel
·?
∪
z
Familientitel
?
varstring10
Abbildung 3: Semi-strukturiertes Attribut Name
hierarchische Struktur ermöglicht auch Elemente auszuzeichnen, z.B. mit der Eigenschaft Element eines Schlüssels
zu sein. So kann z.B. zum Schlüssel das Teilattribut
Name (Vornamen, Familienname, [Geburtsname ])
hinzugenommen werden, wobei wir als Abkürzungsregel benutzen, daß mit dem Nennen eines Bezeichners auch der
damit verbundene Teilbaum mit übernommen wird, z.B. für Vornamen auch die gesamte Teilstruktur Vornamen<(Vorname
:: varstring15 , Benutzung :: string1)> .
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 Repräsentation. Die graphische Darstellung kann unterschiedlichen
Paradigmen folgen.
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
165
Begründung: Da die Werkzeuge zum Datenbank-Entwurf meist einschränkend sind bei der graphischen Darstellung, sollte man sich hier die unterschiedlichen
Darstellungsformen erschließen und parallel benutzen.
Allgemeiner Definitionsrahmen für Typen: für korrekte Separation wird verwendet
• T $ (componT ; identifT ; integrityT )
Die drei Elemente eines Typen (componT ; identifT ; integrityT ) können als Folge definiert werden,
wenn man die Separation durch das Semikolon benutzt.
• Wird eine Folge verwendet, dann kann auch die Reihenfolge der Elemente für die Annotation verwendet
werden.
• Oft wird anstatt $ auch einfach das Gleichheitszeichen verwendet. Dies ist eine Form der Bezeichnungsökonomie, hat aber nichts mit der mathematischen Gleichhet zu tun.
• alternativ aber weniger korrekt T $ (componT , identifT , integrityT )
Verwendung von Marken ist für alle Typen zugelassen.
I.a. wird dazu die Form Marke:Bezeichner gewählt. Dies erlaubt dann auch die Marke als Abkürzung
oder alias zu verwenden.
Unique-Name-Assumption für alle Bezeichner des Schemas, d.h. alle Entity-, Relationship- und Cluster-Typen,
sowie für Komponenten der Typen selbst. Ansonsten wird eine Marke notwendig.
Alternativen in der Darstellung
Wir verwenden - wo immer es möglich ist - das Kartesische Produkt als Typenkonstruktoren.
Begründung: Die Darstellung im Stile der funktionalen Programmierung mit Funktionen hat sich nicht bewä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 Integritätsbedingungen. Der Primärschlüssel wird direkt durch Unterstreichen der Attribute angegeben. Ist die Menge der
statischen Integritätsbedingungen leer, dann kann sie auch weggelassen werden. Eine Klasse von der Struktur
des Entity-Typs ist gültig, falls alle Integritä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 repräsentiert.
Eine Entity-Klasse besteht aus einer Menge von Objekten vom Entity-Typ, die die statischen Integritätsbedingungen des Entity-Typen erfüllt.
Hier verwendete Annahmen:
Wir definieren die Klasse als eine
Menge. Multimengen-Semantik wird z.B. im relationalen Modell für Anfragen verwendet. Dort ist die
Multimenge relativ einfach beherrschbar. Wird dagegen ein paralleler Zugriff für unterschiedliche Benutzer erlaubt, dann muß ein explizites
Konzept des sharing eingeführt werden.
Begründung: Kollaboration kann ü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 Verträge von Benutzern verwenden. Eine Spezifikation von Anwendungen wird
dabei allerdings viel zu komplex.
Zum Beispiel ist das folgende Objekt mit dem Identifikator β
β : ((<(Karl,z),(Bernhard,r)>, Thalheim, {Prof., Dr.rer.nat.habil., Dipl.-Math.}),
BTU Cottbus, (({ +49 355 692700, +49 355 692397}, +49 355 824054),
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
166
[email protected]), 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 könnte auch noch Kreise um die Attribute ziehen.
Begründung: Dies ist aber unnötigt. Die Diagramme werden unübersichtlicher.
Hier verwendete Annahmen:
Ein Entity-Typ hat mindestens eine Komponente, die Sinn in der Anwendung macht.
Begründung: Künstliche, vom System erzeugte Identifikation macht für einen Anwender weder Sinn für das Retrieval noch für die Modifikation. Sie
ist ein bequemes und zugleich sehr mächtiges Instrument der Implementation.
Unterschied zur Vorlesung Informationssysteme (4. Semester)
Wir verwenden nur eine interne Identifikation über Komponenten des Entity-Typs. Schwache Entity-Typen sind nicht zugelassen.
Begründung: Im Buch [Tha00] wird ausführlich begründet, warum schwache Typen zu schlechten Schemata führen, in eigenartiger Se-
mantik resultieren und auch mit dem higher-order Relationship-Typ vollständig überflüssig sind.
Unterschied zur Vorlesung Informationssysteme (4. Semester)
Wir vermeiden eine ständige Einführung eines Identifiers. Diese Attribut sollte bei der konzeptionellen Modellierung nur dann
eingeführt werden, wenn dies erforderlich ist.
Begründung: Der Identifier ist ein logisches Konzept. Ansonsten erfordert er eine Extra-Verwaltung, die ein Schema verschlimmbessert.
Hinzu kommt der Albtraum, den wir für objekt-orientierte Schemata in aller Problematik kennenlernen mußten.
Grundlagen aus der Theorie der Informationssysteme
Konzeptionelle Modellierung orientiert sich an echten, in der Anwendungswelt sinnvollen Konzepten. Künstliche, der Implementation geschuldete
Konstrukte sind strikt zu vermeiden, wenn man den Benutzer nicht verwirren oder von der Anwendung fernhalten möchte.
Begrü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 bedürfen jedoch einer Revision unter
modernen Gegebenheiten.
Grundlagen aus der Theorie der Informationssysteme
Die Identifikation kann über minimale Schlüssel definiert werden. Es ist hier nicht nur der Primärschlüssel von Interesse, sondern auch weitere
Schlüssel, die in einer Anwendung Sinn machen.
Begründung: Man betrachte einmal den Typ Lehrstuhl, der sowohl über den Namen (mit ggf. Zusätzen) als auch die Kostenstelle als auch den Raum
oder andere Kantaktformen identifizierbar ist, wobei die spezifische Identifikation für unterschiedliche Assoziationen dann auch benötigt wird.
Einfacher Relationship-Typ: Ein Relationship-Typ (erster Ordnung) besteht aus einer nicht-leeren Folge von EntityTypen, einer Menge von Attributen und einer Menge von statischen Integritätsbedingungen. Eine Menge von
der Struktur des Relationship-Typen ist eine gültige Menge, wenn sie den statischen Integritätsbedingungen
genügt. Elemente können markiert sein.
Ein Beispiel sind die Relationship-Typen
InGruppe = (Person, Gruppe, { Zeit(Von [,Bis]), Funktion }, ∅ )
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
167
DirektVoraussetz = (setztVoraus: Kurs, vorausges : Kurs, ∅, ∅ )
Professor = (Person, { Berufungsgebiet }, ∅ ) .
Ein Relationship-Typ wird mit einer Raute graphisch repräsentiert. Wir erlauben auch optionale Komponenten
von Relationship-Typen, solange eine Identifikation über die obligatorischen Elemente definiert ist.
Alternativen in der Darstellung
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.
Begründung: Es wird oft argumentiert, daß die IDEF-Darstellung die natürlichere Form sei. Sie wird auch von fast allen Werkzeugen unterstützt. In
der Forschungsliteratur hat sich jedoch die ursprü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 geä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. Primärschlüssel
bzw. anderer Schlüssel) verweist und Werte für die Attribute des Relationship-Typs besitzt.
Eine Relationship-Klasse besteht aus Objekten des Relationship-Typs, die den statischen Integritätsbedingungen
genü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
LVereinigung von bereits konstruierten Typen wird als Cluster-Typ bezeichnet. Ein ClusterTyp wird mit einem -Zeichen graphisch reprä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 einführen.
Cluster-Typen können weitere Attribute besitzen. In diesem Fall wird der Cluster-Typ durch eine Raute mit den
Attributen repräsentiert.
Objekte von Cluster-Typen sind analog zu den Objekten anderer Typen durch entsprechende Zuordnung zu den
Element-Typen eingeführt. So können z.B. die Objekte β , LIM, CottbusNet e.V. juristische Personen sein.
Alternativen in der Darstellung
Cluster-Typen werden oft nicht zugelassen, so daß dann für alle Typen eine Mixvererbung geführt werden muß.
Begrü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 fü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
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
Θ := Enrolls.Course 1P rovides.Course
Examines.Enrolls.Course
= Examines.GivenBy.Course
Course
¾
Enrolls
-
GivenBy
6
Docent
6
¾
168
Course
¾
GivenBy
6
Examines
Enrolls
?
?
Student
Student
The simple HERM schema
-
Docent
6
¾
Θ
Examines
The sophisticated HERM schema
The representational conceptual schema
-
Enrolls
⊇
Course
¾
6
GivenBy
⊆
Student = ({ StudId, ... }, ...),
Course = ({ CourseID,... }, ...),
Docent = ({ DocentID,... }, ...),
Enrolls = ({ StudId, CourseID,... }, ...),
Provides = ({ CourseID, DocentID,... }, ...),
Examines = ({ StudId, DocentID, CourseID,... }, ...)
Examines[StudId, CourseID]
⊆ Enrolls[StudId, CourseID]
- Docent
Student ¾
Examines
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].
Unterschied zur Vorlesung Informationssysteme (4. Semester)
Relationship-Typen werden im Stile der funktionalen Programmierung als Funktion des Namen auf die Rollen der Komponenten
eingeführt. Ggf. sind auch Attribute erlaubt.
Begründung: Es ist damit eine Defintion der Rollen unbedingt erforderlich. Rollen sind jedoch eine spezifische Form der Spezialisie-
rung für die Komponenten und sollten nur dort verwendet werden, wo dies erforderlich ist.
Relationship-Typ hö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 Integritätsbedingungen. Eine Menge von der
Struktur des Relationship-Typen ist eine gültige Menge, wenn sie den statischen Integritätsbedingungen genügt.
Eine Identifikation kann sowohl aus den Elementen bestehen als auch aus den Attributen.
Unterschied zur Vorlesung Informationssysteme (4. Semester)
Es wird oft für Relationship-Typen höherer Ordnung der Zugang der Objektifizierung genutzt. Dieser Zugang ist äquivalent zu
dem hier genutzten. Er führt jedoch ein weiteres Element im Diagramm ein. Es wird um die Raute ein Rechteck gezogen, so daß
ein weiteres Element entsteht.
Begründung: Man sollte im Diagramm Konstrukte so sparsam wie möglich verwenden. Alles andere verwirrt nur. Hinzu kommt als
Fehler- und Verwirrungsproblem das genaue Anbringen der Attribute an den Typen. Attribute gehören dann wohl eher zum ursprünglichen Typ und nicht zum objektifiziertem Typ.
Dieser Zugang erlaubt keine Einführung von Clustern.
Alternativen in der Darstellung
Besonders unübersichtlich wird die Objektifizierung über Teilschemata z.B. für einen Relationship-Typen mit seinen Komponenten.
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
169
Begründung: Man verliert sich sehr schnell in solchen Diagrammen.
Mit der expliziten Einführung von Typen höherer Ordnung werden objektifizierte Typen überflüssig!
Es ist mitunter vorteilhaft, über Relationship-Typen höherer Ordnung zu verfügen, wie Bild 5 zeigt. Im oberen
Student’
1
*
6
eingeschr.
in
®9
Vorlesung
+
q
?
Raum
Semester
Professor’
¾
Kurs
¾
Student’
Professor’
*
6
eingeschr.
in
9
Semester
DirektVoraussetz
- Vorlesung
+
?
Raum
¾
Kurs
¾
DirektVoraussetz
Abbildung 5: HERM Diagramme mit und ohne Relationship-Typen höherer Ordnung
Diagramm muß eine zusätzliche Integritä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 können sich vom Vorschlag zum Plan und für den Raum
vom Plan zu den gehaltenen Lehrveranstaltungen ändern. Ein Vorschlag für eine Lehrveranstaltung wird durch
Berechtigte eingetragen. Eine Person ist für die Lehrveranstaltung verantwortlich. Eine Lehrveranstaltung kann
für mehrere Studiengänge angeboten werden.
Wir wollen hier nicht die vollständige Entfaltung von Objekten zu Typen höherer Ordnung fordern. Deshalb
erbt ein Relationship-Typ höherer Ordnung nur die Identifikation seiner Elemente oder - wenn wir an einer
vollständigen Wertedarstellung interessiert sind - nur die identifizierenden Werte der Objekte seiner Komponenten. So kö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 Schlüssel des Typs angeboteneVorlesung aus Kurs, Semester, Professor besteht.
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
Kurs
ab SS 2012
Semester
k
Studiengang
{}
Person
1
eingetragen
Verantwortlicher4LV
µ
Dozent
Wunsch
angebotene
Vorlesung
Vorschlag
*
Professor
6
¾
170
Zeit(Vorschlag,
6 Nebenbeding)
-
Raum
*6
+
Typus
¾
geplante
Lehrveranst
¾
gehaltene
Lehrveranst
Zeitrahmen
Abbildung 6: HERM Diagramm zu unserem Hauptbeispiel
Ein Objekt vom Typ
angeboteneVorlesung = (Kurs, Semester, Studiengänge,
Professor, eingetragen, Verantwortlicher4LV, Raumwunsch, Typus, { Zeit }, ∅) ist z.B.
VorlesungDBIVSS02: (DBIV, SS2002, { Informatik, IMT },
637861, KK, 637861, SR1, Vorlesung/Übung/Praktikum 2+2+2, Mo. 1.DS) .
Generalisierung versus Spezialisierung: Ein Cluster-Typ erlaubt die explizite Darstellung einer Generalisierung.
Ein unärer Relationship-Typ stellt dagegen eine Spezialisierung dar, wenn der Relationship-Typ bzw. EntityTyp 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 unä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 gewählt wird, hängt vom erforderlichen Detaillierungsgrad ab. Sollen Attribute mit dargestellt werden, wird das hierarchische ER-Modell
sehr schnell zu unübersichtlich. In den ersten Abstraktionsschichten stellt es aber eine gute Alternative zum
HERM-Diagramm zum.
Person
Student
Diplomand
Diplomand
-
Student
Universitätsmitarbeiter
-
Person
6
Professor
Projektmitarbeiter
Projektmitarbeiter
- Universitäts- ¾
mitarbeiter
Abbildung 7: Hierarchisches ER-Diagramm versus HERM Diagramm
Mod IS
IS ADD
Web IS
Professor
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
171
Aggregation: Wir kö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 PersonC und
InGruppeC Klassen entsprechenden Typs.
IsA-Beziehungen können auf sehr unterschiedliche Art repräsentiert werden, ebenso wie unterschiedliche Schemata letztendlich das gleiche
darstellen können.
Three different styles are depicted in Figure 8. We prefer the compact style in the left diagram.
Person
Person
6
Professor
6
Professor
Person
6
IsA
Professor
Abbildung 8: Variants for Representation of Unary Relationship Types
IsA-Typen:
hier wurde partielle, nicht disjunkte Darstellung ü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 über unäre Teiltypen.
Person ⊇ Professor ∪ Mitarbeiter ∪ Student
E ⊇ E1 ∪ ... ∪ En
2. partiell, disjunkt
die Teiltypen erfüllen eine Exklusionsbeschränkung
Person ⊇ Professor ∪ Student
E = E1 ∪ ... ∪ En
3. total, nicht disjunkt
E = E1 ∪ ... ∪ En
Projektmitarbeiter = Professor ∪ Mitarbeiter ∪ Student
4. total, disjunkt
E = E1 ∪ ... ∪ En
Studenten = StudImVordiplom ∪ StudImHauptstudium ∪ Diplomand
Weiterhin kann auch für die Spezialisierung mit Partitionsbedingung eine analoge Strukturierung betrachtet werden (wird auch in den
meisten Büchern ‘vergessen’):
1. partiell, nicht disjunkt
E ⊆ E1 ∪ ... ∪ En
Teilnehmer ⊆ Vortragender ∪ Organisator ∪ NormalerTeilnehmer
2. partiell, disjunkt
E ⊆ E1 ∪ ... ∪ En
Literatur ⊆ Buch ∪ Preprint ∪ Zeitschrift
3. total
E =
Mod IS
siehe oben
Generalisierung 6= (Spezialisierung)−1
E1 ∪ ... ∪ En
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
172
Gewöhnlich wird in der Literatur nur versimplifizierend die IsA-Beziehung als strukturelle Beziehung betrachtet. Richtig ist aber die IsABeziehung 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 (eingeschränkt auf im Supertyp darstellbares) folgt aus Semantik des Supertyps
Unterschied zur Vorlesung Informationssysteme (4. Semester)
Oft wird mit dem IsA-Typen eine Mixvererbung verbunden. Das Liskov-Substitutions-Prinzip (Methoden, die Zeiger oder Referenzen auf Basisklassen benutzen, mü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 für jedes Objekt O1 vom Typ S ein Objekt O2 vom Typ T
gibt, so daß sich für alle Programme definiert in T das Verhalten nicht ändert, wenn O2 durch O1 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.
Begründung: Die Vererbung von Beziehungen des Supertypen erfolgt im Schema ohnehin aufgrund der Integritätsbedingungen. Die automa-
tische Anreicherung um alle Attribute des Supertypen bringt eine erhöhte Redundanz an Werten, die zudem noch gepflegt werden müssen.
Alternativen in der Darstellung
Abstraktionskonzepte, die in der Informatik entwickelt worden sind:
•
Spezialisierung und Generalisierung: Objekte sind (entgegen der üblichen Salami-Slice-Modellierung) selbst strukturiert und kö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: Ähnliche Objekte werden für gemeinsamme Zwecke zusammengefaßt.
Begründung: Abstraktion dient der Verkürzung und sollte nicht mit anderen Methoden verwechselt werden.
Grundlagen aus der Theorie der Informationssysteme
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.
Begründung: Die Grundlagen von Vererbung, Polymorphie, Objektidentifikation, Prototypen, Generizität etc. sind noch nicht ausreichend verstanden und
erforscht. So wird z.B. in einer Subtypenbeziehung eine (unselige) Diskussion zur Kovarianz und Kontravarianz geführt, wobei man eigentlich das Subtypenkonzept meint.
Statische Integritätsbedingungen: Die Semantikspezifikationssprache umfaßt Schlüssel und Integritätsbedingungen,
wie funktionale Abhängigkeiten, Exklusions- und Inklusionsabhängigkeiten, mehrwertige Abhängigkeiten, VieleEins-Bedingungen, Seinsbedingungen (Existenzbeziehung), Verweisbedingungen, Teiltypenbedingungen und Regeln, wie z.B. die Gesamtheitsregel, die Verneinungsregel und die Sichtregeln, sowie vor allem Komplexitätsbedingungen (Kardinalitä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 Einführung zusätzlicher Charakteristiken (Attribute) und zur Spezialisierung des
Verhaltens
u.a. auch
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
173
• 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 unabhängig voneinander betrachtet werden
können:
• Gegenstandsdimension, z.B. Partei, Person, Position und Organisation
• Klassifikationen, hierarchische und andere Untergliederungen
• Organisationsmodelle
• Bedienungsmodelle und deren Komponenten, z.B. Verantwortlichkeit, Verantwortlichkeitsbereich
Protocol
I
Product
type
Y
Position k
Business
hierarchy
Kind of ¾
business
Person
-
Kind
¾
of hierarchy
6
¾
Hierarchy
based on
-Organization¾
type
is of type
?
- Organi-
?
Time
slot
zation
son
¾
µ
-
Party
type
66
server
client
ª server
Party ¾ ¾ Responsibility -Responsibility
type
L
client
66
Rule
Party
hierarchy
Resource
type
??
Responsibility
Amount range I
Quantity
?
Product
hierarchy
Range
type
µ
father
Structure
?
Responsibility¾
hierarchy
-Responsibility
contract
Layered
hierarchy
6
Hierarchical
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
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
174
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 fünfwertiger Logik.
Lö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
y 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 y extend the domain type
A Simplified But Almost Real Application
CREATE TABLE Student (
MatriculationNo
StudNo
MainProgram
CHAR(6)
CHAR(6)
VARCHAR(20)
could be NULL
our internalisation
could be NULL,
could be more than one
far too simple
might be more than one
Name
VARCHAR(50)
SecondaryProgram
VARCHAR(20)
PRIMARY KEY
(StudNo)
FOREIGN KEY (MainProgram)
REFERENCES ProgramAtCAU (ProgName)
ON DELETE RESTRICT
... );
CREATE TABLE Enroll (
our internalisation
StudNo
CHAR(6)
Course
CHAR(8)
Term
VarCHAR(7)
full of beans
EnrollmentCondition
VARCHAR(10)
Grade
VARCHAR(3)
that is a devils invention
PRIMARY KEY (StudNo, Course, Term)
... );
Mod IS
IS ADD
Web IS
unknown
unknown
known
under
change
known
under
change
Stud
ent
175
Gues
t
Bach
not yet
decided
not
exists
not
exists
Grad
never
exists
never
exists
not yet
decided
& Ma
ster
ed C
erti
f
Dipl
ific
Cert
Special condition
ate
ent
stud
oma
After course
Dipl
During course
ab SS 2012
elor
icat
e Di
plom
a
2. Strukturierung von IS
oma
CAU zu Kiel, IfI, ISE, β
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?
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
176
2.3 Statische Integritä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 identifi- Relative independence
Existence dependency
Redundancy dependencation
cy
Business
identification
structure
no null
elementary facts
user level
Conceptual
functional,
multivalued, hierarchical, join null-value-free, union inclusion constraint, exlevel
equality genera- dependencies, exclusion depen- constraints, numerical, clusion constraint
ting
dency, tuple generating, hori- cardinality constraint
zontal decomposition
Implemenkey, uniqueness, decomposition, stored procedu- no null, stored procedu- referential integrity, surtation level
trigger, check
res, trigger
res, trigger
rogate, 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.
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
177
(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 Integritätsbedingungen von HERM
Statische Integritätsbedingungen werden als Formeln der hierarchischen Prädikatenlogik allgemein dargestellt. Wir verwenden
jedoch die üblichen Kurzdarstellungen.
Wir gehen davon aus, daß statische Integritätsbedingungen einer Interpretation mit einer “Normallogik” unterliegen. Mitunter
wird auch im Entwurf eine Integritätsbedingung mit einer schwachen, deontischen Interpretation benutzt, bei der ihre Gültigkeit
fü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 für Kardinalitätsbeschränkungen auch durch entsprechende Objektmengen
genau erfüllt sein müssen.
Wir verwenden im weiteren folgende Klassen von Integritätsbedingungen:
Schlü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
Schlüssel dienen. Gewöhnlich hat jeder Typ mehr als einen Schlüssel. Deshalb verwenden wir von vornherein Schlüsselmengen. Der Primärschlüssel eines Entity-Typs wird direkt angegeben und kann in der Schlüsselmenge weggelassen
werden.
Wir nehmen z.B. für das Diagramm in Bild 6 folgende Schlüssel an:
Key(Person) = { { PersNr }, { Name, Geburtsdatum } }
Relationship-Typen haben ggf. auch eigene Attribute, die auch Bestandteile eines Schlüssels sind.
Zum Beispiel nehmen wir für das obige Beispiel an, daß die Zeit essentiell für InGruppe ist, d.h.
oder
Key(InGruppe) = {{ Person, Gruppe, Zeit }}
Key’(InGruppe) = {{ Person, Gruppe, Zeit, Funktion }}
Weiterhin kann z.B. gelten
Key(Vorlesung) = { {Kurs, Semester}, {Semester, Raum, Zeit}, {Semester, Dozent, Zeit} }
Schlüssel folgen der Komponentenkonstruktion und können auch für einen Teil gelten, z.B.
Name(Vornamen<(Vorname,use)>, FamName).
Mindestens ein Schlüssel wird über die Komponente an den Relationship-Typen ‘vererbt’.
Schlüsselvererbung aus den Komponenten heraus
z.B. in Bild 28:
• Projekt, Institution, Mitarbeiter, Labor besitzen ihre Schlüssel; jeweils einer davon kann ausgezeichnet sein
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
178
• fördert leitet, arbeitet in, zugeordnet erben die Schlüssel der jeweiligen Elemente zur Identifikatioon der Relationships in den jeweiligen Relationship-Klassen
• analog kann auch ein Relationship-Typ höherer Ordnung seine Identifikation durch die Identifikation der Komponenten beziehen
• ggf. kann auch für einen Relationship-Typen gelten, daß einige seiner Attribute für die Identifikation mit herangezogen werden
Unterschied zur Vorlesung Informationssysteme (4. Semester)
Es wird oft Schlüssel anstatt minimaler Schlüssel und Superschlüssel anstatt Schlüssel verwendet.
Begründung: Dies entspricht der ursprünglichen Herangehensweise von E.F. Codd und seinen Nachfolgern. Sie ist jedoch veraltet.
Grundlagen aus der Theorie der Informationssysteme
µ
Leider existieren maximal (wobei diese Grenze exakt ist)
n
¶
b n2 c
minimale Schlüssel für Typen mit n Komponenten. Diese Schätzung wird auch nicht besser im Falle von begrenzten Wertetypen, z.B.
4
| dom(Bi ) |≤ k (1 ≤ i ≤ n)
für k < 2n
µ
¶
n
b n2 c
+1
n
−b c
2
Es besteht jedoch ein besseres Verhalten im mittleren Fall. Siehe Seleznev/Thalheim.
Begründung: Siehe B. Thalheim: Dependencies in Relational Databases. Teubner, Leipzig, 1991.
Funktionale Abhängigkeiten sind eine wichtige Gruppe von Abhängigkeiten. Eine funktionale Abhängigkeit R : X →
Y ist für einen Typ R und Teilmengen X, Y seiner Elemente definiert. Sie gilt in einer Klasse RC , falls die Gleichheit
von Objekten o, o0 aus RC über X die Gleichheit über Y für o, o0 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} .
Grundlagen aus der Theorie der Informationssysteme
maximum number
N (n) of basic functional functional dependencies for types on n components
!
Ã
3
µ
¶
4 log2 log2 n
log22 n
n
n
√
2 1−
(1 + o(1)) ≤ N (n) ≤ 2
1−
log2 e log2 n
150 n
minimal generating sets of fd’s (n odd; n even (replace n12 by
µ
n
¶
b n2 c
1
+ 2
n
closed families of fd’s
(b nn2 c)
2
(J. Demetrovics, G.O.H. Katona, D. Miklos,
µ
n
(n+3)
2
1
5
))
n2 2n 8
Ã
¶
n
≤ M (n) ≤ 2
≤ Cl(F, n) ≤ 2
3
log22 n
√
1−
150 n
!
(b nn2 c)(1+o(1))
β (1982-2006))
Begründung: Damit ist eine vollständige Spezifikation von allen notwendigen geltenden funktionalen Abhängigkeiten nicht möglich!
Grundlagen aus der Theorie der Informationssysteme
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
179
rather than describing the entire set of basic functional dependencies use a Armstrong relations
RC
which allows to reason on the set of
constraints
µ
¶
µ
¶
1
n
n
≤
L
(n)
≤
+1
{key}
n2 b n2 c
b n2 c
size however
k−1
k−1
c1 n 2 ≤ L{key(k)} (n) ≤ c2 n 2
µ
¶
µ
¶
1
n
n
c3
≤ LF (n) ≤
(1 + √ )
n2 b n2 c
b n2 c
n
(J. Demetrovics, G.O.H. Katona & other Hungarians,
β (1982-2005))
Begründung: Armstrong-Relationen stellen also auch keinen Ausweg dar!
Alternativen in der Darstellung
Anstatt mit logischen Formeln zu rechnen, kann man auf die Boolesche Repräsentation von funktionalen Abhängigkeiten zurückgreifen. Diese
kann auch für funktionale und mehrwertige Abhängigkeiten (sogar hierarchische Abhängigkeiten!!!) verwendet werden und ist um einiges einfacher
als die klassische Kalkül-Ableitung. Auch Chase ist nicht einfacher.
Begründung: Representable by Boolean functions:
Represent A by pA
X = {C1 , ..., Ck } by τ (X) = pC1 ∧ ... ∧ pCk
τ (X → Y ) = τ (X) → τ (Y )
τ (X →→ Y1 | Y2 | ... | Ym ) = τ (X) →→ (τ (Y1 ) ∨ τ (Y2 ) ∨ ... ∨ τ (Ym )).
{α1 , ..., αk , β} functional and hierarchical dependencies
{α1 , ..., αk } |= β iff (τ (α1 ) ∧ ... ∧ τ (αk )) → τ (β) = 1
Kardinalitätsbeschränkungen werden als kombinatorische Beschränkungen in der (min,max)-Notation und der PartizipationsSemantik als Paar von Kardinalitä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 mitgeführt werden. Wir betrachten hierzu
ein vereinfachtes Diagramm in Bild 10.
0..2
(0,n)
Resultat
(gehaltene)
Vorlesung
setztVoraus 6
(0,2)
3..4
¾
(1,n)
vorausgesetzt
6
(3,4)
0..2
legtab
Ablageform
(0,n)
Voraussetzung
?
Student
Abbildung 10: Kardinalitätsbeschränkungen im Vorlesungsbeispiel
Eine Kardinalitätsbeschränkung card(R, Ri ) = (n, m)
RC mindestens n-mal und höchstens m-mal vorkommt.
gilt in einer Klasse RC , falls jedes Objekt oi von RiC in
Eine Kardinalitätsbeschränkung card(R, Ri ) = (n, 1) für R = (R1 , ...., Rn , attr(R)) ist äquivalent zur funktionalen Abhängigkeit R : Ri −→ R1 , ...., Ri−1 , Ri+1 , ..., Rn .
Eine Kardinalitätsbeschränkung card(R, Ri ) = (1, m) für R = (R1 , ...., Rn , attr(R)) ist äquivalent zur Inklusionsabhängigkeit R : Ri ⊆ πRi (R).
Eine Kardinalitätsbeschränkung in der Lookup-Notation look(R, Ri ) = (n, m) gilt in einer Klasse RC mit k
Elementen, falls zu jeder Kombination von Objekten oj von RjC (j 6= i, 1 ≤ j ≤ k) mindestens n und höchstens m
entsprechende Objekte oi aus RiC in der Klasse RC vorkommen.
Im Fall binärer Relationship-Typen ohne Attribute, die zur Identifikation von Relationships herangezogen werden müssen,
kann man damit einem Objekt o von Ri mindestens n und höchstens m Objekte aus RjC zuordnen, d.h. das Objekt sieht
vermittels RC höchstens m und mindestens n Objekte aus der anderen Klasse. Wir erhalten damit das folgende Bild:
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
180
C
A
(a,b)
¾
c...d
A with B
(c,d)
a ...b
A
Abbildung 11: Kardinalitätsbeschränkungen im Vorlesungsbeispiel
Diese Beziehung zwischen lookup und participation-Bedingungen gilt allerdings nicht, wenn die Attribute C bei der
Identifikation des Relationship-Typen herangezogen werden!!!
Eine Kardinalitätsbeschränkung look(R, Ri ) = (n, 1) für
tionalen Abhängigkeit R : R1 , ...., Ri−1 , Ri+1 , ..., Rn −→ Ri
R = (R1 , ...., Rn , attr(R)) ist äquivalent zur funk.
Eine Kardinalitätsbeschränkung look(R, Ri ) = (1, m) für R = (R1 , ...., Rn , attr(R)) ist äquivalent zur verallgemeinerten Inklusionsabhängigkeit
R : ∀oi ∈ RiC ∃(o1 , ..., oi−1 , oi+1 , ..., on ) ∈ πR1 ,....,Ri−1 ,Ri+1 ,...,Rn (RC ) :
(o1 , ..., oi−1 , oi , oi+1 , ..., on ) ∈ πR1 ,....,Ri−1 ,Ri ,Ri+1 ,...,Rn (RC ) .
Sie kann auch durch RiC ⊆ πRi ( RiC × πR1 ,....,Ri−1 ,Ri ,Ri+1 ,...,Rn (RC ) ) dargestellt werden.
C
C
, Ri+1
, ..., RnC anstelle der Projektion verstanden. Diese
Manchmal wird sogar das Kartesische Produkt von R1C , ...., Ri−1
Interpretation wurde z.B. UML unterlegt.
Trotzdem sind Lookup-Abhä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 natürlich scheint.
Kurs
¾
(a,b)
Angebot
0..1- verantwortl.
Person
look(Angebot, ver
Person
Semester
6
6
?
Kurs
Semester
¾
Angebot ¾ Verantwortlicher
0..1
Abbildung 12: Kardinalitätsbeschränkungen im Vorlesungsbeispiel
0..1
Wird dagegen auch noch
komposition in Bild 13.
Semester
¾
card(Angebot, Kurs) = (0, 1)
Angebot
(0,1)
Kurs
gesetzt, dann ergibt sich natürlich eine viel stärkere De-
¾
Verantwortl.
(0,1)
-
Person
Abbildung 13: Kardinalitätsbeschränkungen im Vorlesungsbeispiel
Die Lookup-Notation ist für binäre Relationship-Typen ohne eigene Attribute ä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 äquivalente Formen.
Für n-äre Relationship-Typen ohne eigene Attribute ist die Lookup-Notation look(R, Ri ) = n..m äquivalent zur verallgemeinerten Kardinalitätsabhängigkeit card(R, R \ Ri ) = (n, m) .
In unserem Beispiel gilt z.B. die Einschränkung, daß erst dann ein Eintrag in die Klasse legtab geführt wird, wenn der
Student eine Vorlesung erfolgreich abgelegt hat.
Die Lookup-Bedingung
look(legtab, Ablageform) = 0..2
stellt dar, daß nur Prüfung und Schein bzw. Schein und
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
181
Praktikum bzw. Prüfung und Praktikum absolviert werden müssen. Diese Bedingung ist äquivalent zu
card(legtab, Student Vorlesung) = (0,2).
Eine Kardinalitätsbeschränkung card(R, Ri ) = (0, 1) ist äquivalent zur funktionalen Abhängigkeit R : {Ri } → R .
Eine Lookup-Kardinalitätsbeschränkung look(R, Ri ) = 0..1 ist äquivalent zur funktionalen Abhängigkeit R :
R \ {Ri } → R .
Spannend ist das Zusammenwirken von card und look.
Wir betrachten z.B. einmal einen Relationshiptypen in Bild
Weiterhin können wir z.B. fordern, daß nur solche Vorlesungen als gehalten gelten, die auch zu studentischer Beteiligung
geführt haben. Dies wird durch card(legtab, Vorlesung) = (1,n) dargestellt.
Eine strengere Bedingung ist, daß dies auch für das Semester gelten muß. Dann können wir spezifizieren
look(legtab, Student) = 1..n
bzw.
card(legtab, Vorlesung Semester) = (1,n).
Für Relationship-Typen mit eigenen Attributen ist die Lookup-Notation in verschiedenen Formen definiert.
(DBIV,SS2002,β)
◦
◦
◦
◦
◦◦
Schein
◦
(DBI,WS2002,β)
(Compiler,SS2002,PB)
◦◦
(Informatik III,WS2002,BvB)
◦
◦
◦
◦
Prüfung
◦
Praktikum
◦
(Informatik III,WS2003,β)
Antje Bä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 Bärbel sowohl die (Informatik
III,WS2002,BvB) als auch (DBIV,SS2002,β ) mit Prüfung und Schein abgelegt, Emil dagegen nur Scheine in (Informatik
III,WS2002,BvB) und (DBI,WS2002,β ).
Kardinalitätsbeschränkungen sind mitunter nicht erfüllbar in nicht-leeren, endlichen Klassen. Ein Beispiel einer solchen
nicht-erfüllbaren Menge von Integritätsbedingungen ist das Paar
card(Voraussetzung, setztVoraus) = (0,2)
card(Voraussetzung, vorausgesetzt) = (3,4) .
Wir können dies einfach nachvollziehen, indem wir eine endliche Menge von Vorlesungen z.B. {a, b, c, d, e} betrachten.
Mit der Kardinalitätbeschränkung card(Voraussetzung, vorausgesetzt) = (3,4) kann man z.B. folgende Besetzung für
Voraussetzung betrachten:
{(a, b), (a, c), (a, d)} wird dann weiter fortgefü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 für d als linke Seite nicht genug Elemente auf der rechten Seite. Wir benötigen also noch f, g.
Wir können nun weiter fortsetzen und erkennen, daß nur die leere und eine unendliche Menge von Vorlesungen diese
Kardinalitätsbeschränkungen erfüllen.
Dagegen ist
card(Voraussetzung, setztVoraus) = (0,3)
card(Voraussetzung, vorausgesetzt) = (3,4)
erfüllbar und impliziert
card(Voraussetzung, setztVoraus) = (3,3)
card(Voraussetzung, vorausgesetzt) = (3,3) .
Grundlagen aus der Theorie der Informationssysteme
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
182
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
R = (E, F, attr(R)) (see for instance [EN89, Vos87]):
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}.
Begründung: Siehe HERM Buch!
types
The edge
ER-designer
E
(0,1)
R
(1,m)
F
=
Classical proposal
E
◦
R
M
(1,m)
F
Teorey
R
E
comp(R,E)
comp(R,F)
◦
F
=
(0,1)
Everest
E
◦
F
Binary ER models
E
¾◦
-
F
Participation for relationship type
E
¾
(1,m)
R
(0,1)
F
Abbildung 15: Lookup and Participation Representation
Grundlagen aus der Theorie der Informationssysteme
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
183
Using the participation approach another labeling concept can be introduced. Assume a relationship type R
= (R1 , ..., Rk , {A1 , ..., Al }).
1 ≤ j ≤ k , the edge R −→ Rj can be labeled by comp(R, Rj ) = (n, m)
or by 1 if comp(R, Rj ) ∈ {(0, 1), (1, 1)}
or by n if comp(R, Rj ) ∈ {(l, k)|l ∈ {0, 1}, l < k, k > 1}.
For 1 ≤ j ≤ l, the edge R −→ Aj can be labeled by dom(Aj ).
For
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
E1 -corner
comp(R, E2 E3 ) ≤ (1, 1).
shaded areas in the relationship type triangle, provided that the relationship type is “many”. More concretely, for instance, the
of the triangle which represents the relationship type
This notation is complicated, and
R = (E1 , E2 , E3 , attr(R))
is not shaded if
comp(R, Ej )-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, Conf erence → F irstAuthor
P aper, F irstAuthor → Conf erence
which are implied by the constraint
P aper → F irstAuthor, Conf erence
.
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.”
Begrü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
First
Author
Paper
I
µ
Submitted
?
Conference
Abbildung 16: Different Semantics Represented by Teorey’s Approach
Mehrwertige Abhä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 Abhängigkeit X →
→ Y |Z wird für einen Typ R = (UR , ΣR ), mit Teilmengen X, Y ⊆ UR und
Z = UR \ (Y ∪ X) definiert und gilt in einer Klasse Relation RC über R (dargestellt durch RC |= X →→ Y |Z ),
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
(1,1)
Review ¾
ab SS 2012
184
(0,m)
(0,1)
(1,m)
- Paper ¾
Published - Journal
For
6
(1,m)
Wrote
(1,m)
? (1,m)
(0,m)
- Institute
Author ¾
Works
Teorey
◦
(0,m)
◦
ER-designer
(1,1) (1,m)
(0,1)
(1,m)
(1,m)
(0,m)
◦
(1,m)
Binary
Everest
◦
¾
¾◦
◦
- ¾
¾
6
6
?
?
¾
¾◦
◦
◦-
-
Abbildung 17: Different Notions for a Paper Reviewing Database
falls für alle o, o0 ∈ RC , die den gleichen Wert für die X-Elemente von R haben, ein Objekt o00 in RC existiert, das aus
der Faltung von o und o0 hervorgehen kann, d.h. formal
für alle o, o0 ∈ RC mit o =X o0 existiert ein Objekt o00 ∈ RC mit o00 =X∪Y o und o00 =X∪Z o0 .
Eine nützliche, allgemein bekannte Eigenschaft von mehrwertigen Abhängigkeiten ist die Dekompositionseigenschaft.
Es gilt RC |= X →→ Y |Z genau dann, wenn sich RC nach X ∪ Y und X ∪ Z vertikal dekomponieren läßt, d.h.
formal RC = RC [X ∪ Y ] 1 RC [X ∪ Z] .
Weniger bekannt ist dagegen, daß die Gültigkeit der mehrwertigen Abhängigkeit zu einem neuen äquivalenten Schema
fü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 Integritätsbedingungen, z.B. Wertebereichsabhängigkeiten, kö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 Abhängigkeiten sind Exklusions- und Inklusionsabhängigkeiten.
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
185
2.3.2 Revisiting Database Dependency Theory
The Power of Simplicity.
Functional and multivalued dependencies are a very powerful and simple class of integrity constraints. It is well-known that
their reasoning and deduction can be based on propositional formulas [Tha91a]. At the same time, a simple and powerful
axiomatisation can be given for simple dependencies and their negations. As an example we give an axiomatisation for functional
and negated functional dependencies:
Axioms
XY → Y
Rules
(1)
(4)
X −→ Y , Y −→ Z
X −→ Y , X −→
/ Z
X −→ Y
(2)
(3)
XV W −→ Y V
X −→ Z
Y −→
/ Z
X −→
/ Y
XZ −→
/ YZ
X −→ Z , X −→
/ YZ
Y −→ Z , X −→
/ Z
(5)
(6)
(7)
X −→
/ YZ
XZ −→
/ Y
X −→
/ Y
X −→
/ Y
Funktionale Abhängigkeiten umfassen zu viele Aspekte auf einmal.
Explicit declaration of partial identification: Functional dependencies are typically explicitly declaring a functional associaIdent
tion among components of types. The left hand attribute uniquely identify right side attributes, i.e. X −→ Y .
Identification can either be based on surrogate or on natural attributes.
Tight functional coupling: Functional dependencies may also be numerical constraints. We denote such constraints by i.e.
N um
X −→ Y . Another denotation is based on cardinality constraints.
Semantic constraint specific for the given application: Constraints may be stronger than observed in usual life since the
application has a limited scope and allows to strengthen the constraint. In this case, constraints restrict the application
only to those cases in which the left side has only one associated right side value despite that this restriction may not be
Sem
valid for any application. We denote this case by X −→ Y
Semantical unit with functional coupling: Semantical units are those reducts of a type that are essential in the given application. Their components cannot be separated without loosing their meaning. Semantical units may have their inner
structure. This structure tightly couples dependent object parts to those that are determining them. We denote this coupU nit
ling by X −→ Y .
Structural association among units: Semantical units may allow a separation of concern for certain elements. Their separation supports a more flexible treatment while requiring that the dependent part cannot exist without the determining part.
Struct
If this dependence is functional we may represent such by the constraint X −→ Y .
Funktionale Abhängigkeiten als Funktion1 kann direkt ausgelagert werden bereits vor Normalisierung
ISBN kodiert bereits den Verlag
ISBN/ISSN muß aber nicht für Buch existieren (alte Bücher), kann ggf. auch mehrere Ausgaben mit umfassen oder auch
nur genau die Ausgabe mit bezeichnen
ist dann tacit knowledge, auf das die anderen Daten aufbauen, das ggf. nicht einen update erfährt
Example 1 Let us consider an abstract example with the functional dependencies
{A} −→ {B, C} and {B} −→ {D}.
TA
A
(1,1)
¾
TA .to.TB
B
C
TB
D
The functional dependency {A} −→ {C} declares an explicit and direct dependency among the attributes. The functional
dependency {A} −→ {B} is an inter-type constraint and leaves the scope of type TA . These two dependencies are completely
different and need different support mechanisms.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
186
The first five cases may be observed for the following instantiations of this example:
instantiation
Explicit declaration
TB = StudyProgram , B = ProgramCode, D = ProgramName
Tight coupling
TA = Student, TA .to.TB = MajorProgram, TB = StudyProgram
Semantic constraint
TB = StudyProgram , B = ProgramCode, D = ResponsibleProfessor
Semantical unit
TB = StudyProgram , B = ProgramCode, D = ProgramDegree
Structural association TA = Student, TB = RegisteredStudent, A = PersonID, B = StudentNr
Let us consider, for instance, that the type TB represents a study program, and the attributes B represent a program code,
D the program name. The functional dependency {B} −→ {D} is an explicit key dependency. If the attribute D represents
the professors that are responsible program then we might assume or not assume {B} −→ {D}. This depends on the given
application. Therefore the dependency is a semantical constraint. From the other side, if the attribute D represents the program
degree then this degree cannot be separated from the values for the program code. In this case the attributes form a semantical
unit. Furthermore, in most universities a student is registered for one and only one major degree. The student must have a major
program. In this case, the two types Student and StudyProgram are thus tightly coupled. Finally, we can separate the student
personal data from the student university data. The person identification number is structurally associated to the student number.
This separation results also in a different meaning of derivation rules. For instance, the augmentation rule has a different meaning
depending on the kind of functional dependency:
Trivilisation
of identification
Ident
R : X −→ Y tR Y 0
Ident
R : X tR X 0 −→ Y
Adaptation of
semantics scope
Sem
R : X −→ Y tR Y 0
Sem
R : X tR X 0 −→ Y
We may also use the Armstrong axiomatisation for derivation of functional dependencies of a given kind. The following two
rules are examples of refined rules:
Ident
Sem
R : X −→ Y, R : Y −→ Z
Ident
R : X −→ Z
Sem
Ident
R : X −→ Y, R : Y −→ Z
Sem
R : X −→ Z
Kinds of Key Dependencies..
A key dependency or simply key X is a functional dependency R : X −→ R . A key is called minimal if none of its proper
substructures forms a key. The set of all minimal keys of R is denoted
¡ ¢ by Keys(R). We notice that this nset may be very large.
For instance, an entity type E with n atomic attributes may have b nn c minimal keys which is roughly c2√n .
2
The key concept reflects a variety of descriptive meanings depending of the level of consideration. Let us distinguish between external, conceptual and internal levels. The meaning of the key concept can be based on the uniqueness property (each
object is unique with this key in the database), the identification property (each object can be identified by its key values), the
existence property (for each object there exist key values), the integrity property (the database satisfies a key constraint), and the
accessibility property (the properties of an object can be accessed through the key values of the object). These meaning are not
equally important at all levels:
• At the language definition level, the uniqueness concept is used to express the key property. The identifier, existence,
integrity and accessibility functionalities are not considered.
• The uniqueness concept is inherited by the external level and expressed mainly via the identification property. The existence property plays a secondary role. The integrity and accessibility concepts are not mainly under consideration.
• At the conceptual level, the uniqueness concept of the language definition level is inherited by the identification and the
integrity property. In order to express the identification concept, the surrogate concept is introduced. The key dependency
is the integrity constraint usually used to express the key property.
• At the internal level, the uniqueness concept is completely covered by the identification concept. From the external
level the existence and uniqueness concepts are inherited and used in implementation restrictions like the requirement of
invariant values in keys. The internal levels also inherit the integrity concept of the conceptual level and uses this concept
for the accessibility property of the key.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
187
language definition level
uniqueness
conceptual
level internal level
~
identification
(surrogate)
external level
ª
U integrity constraint
identification
(key dependency)
j identification
z accessibility
- invariance
existence
Abbildung 19: Descriptive meanings of the key concept depending on the levels
These descriptive meanings of the key concept are pictured in Figure 19.
Beside the descriptive meanings we may also use implementation concepts such as pointers and pragmatic meanings such
as naming.
Typen mit genau einem minimalen Schlüssel.
Menge der Extremalattribute für gegebene Menge Σ von funktionalen Abhängigkeiten und Komponenten R eines Typs T :
extr(R, Σ) := {B ∈ R | Σ 6|= R \ {B} −→ {B}}
Corollary 1 Folgende Aussagen sind äquivalent:
• T besitzt genau einen Schlüssel.
• extr(R, Σ) ist ein Schlüssel von T .
• Σ |= extr(R, Σ) −→ R.
The Power of Graphical Reasoning.
FD Graphs..
Functional dependencies are typically treated in a linear fashion. Graphical representation can however be used for reasoning on
constraints as well. It is a folklore approach that deserves more attention.
Example 2 Given the set UR = {A, B, C, D, E} of attributes and the set σR = {A −→ E, B −→ E, CE −→ D} of
functional dependencies. This set can be represented by the following graph: This graph is easier to survey, simpler for reasoning
- E
- D
A
CE
*
B
C
and contains the full information on σR .
Let us consider for instance, the dependency {A, C} −→ E. The derivation can directly be derived from the following
∪Z−→V
.
schema due to the validity of the left-side extension rule X−→Y,Y
X∪Z−→V
A
AC
- D
C
FD graphs can be axiomatised. This axiomatisation mainly follows the rule system of the Armstrong axiomatisation except
that right hand side attributes are limited to singleton attribute sets. This axiomatisation [DMT04] provides the first axiomatisation for FD graphs (Y denotes a set; A, B, C denote attributes):
(S)
Y →B
YC →B
(T )
Y → A, Y A → B
Y →B
IS ADD
(P )
Y C Y→ B
Y Y→ B
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
188
Y → A, Y Y→ B
Y A → B, Y Y→ B
(R)
()¬(Y → B, Y Y→ B)
Y A Y→ B
Y Y→ A
() is a formalization of ’Y→’ being the negation of ’→’, i.e., ¬() can be deduced starting with contradictory sets of constraints.
(Q)
Theorem 1 [DMT07] The ST implication system over graphs of functional dependencies with rules (S) and (T) and no axioms
is sound and complete for functional dependencies.
The PQRST implication system over graphs of functional and negated functional dependencies with all the presented rules and
the symbolic axiom (), which is used for indicating contradiction, is sound and complete for functional dependencies and their
negations if they are not conflicting.
At the same time reasoning on graphs is more appropriate also for normalisation. Yang [Yan86] has discussed a reduction
algorithm that allows a simple generation of canonical covers and of minimal covers for a set of integrity constraints.
We can also use graphs of functional dependencies for detection of normal forms that are better than those generated by
classical synthesis algorithms. Synthesis algorithms blindly collect all dependencies with the same left side at the final step.
Using graphical reasoning we may collect only those dependencies that are not covered by any other group.
Example 3 Given: the set UR = {A, B, D, F, G, I} of attributes and the set σR = {A −→ IG, D −→ F G, IAB −→
D, IF −→ AG} of functional dependencies. This set can be represented by the graph in the left picture. The graph in the right
* G
* G
6
6
¾
¾
I
I
* A
* A
- D
- D
IF
ABI
IF
AB
F
¼
F
¼
picture displays its reduction to a minimal cover.
These graph also support reasoning on redundancy of constraints. Consider, for instance, whether AB −→ D can be
redundant. The answer is “no” since D has only one entry point. The same observation is true for A −→ I, D −→ F .
By a similar reasoning we can derive non-redundancy of D −→ G.
Additionally we can directly see that {A −→ I, F I −→ A} creates a structure that cannot be represented by a BCNF.
Classical synthesis algorithms generate the following relation schemata:
R1 = ({A, G, I}, {A −→ GI})
R2 = ({A, F, I}, {A −→ I, F I −→ A})
R3 = ({A, B, D}, {AB −→ D})
R4 = ({D, F, G}, {D −→ F G})
This normalisation is however not minimal. Instead of R1 we can use
R10 = ({A, G}, {A −→ G}).
The relation schema R1 is obtained through the relation schema R2 in combination with R10 . R2 is not in BCNF. It cannot be
split into two relation schemata.
The graph in the picture directly allows us to detect this better normalisation since the dependency A −→ I is covered by
R2 .
This example illustrates the power of graphical reasoning. Normalisation is typically driven by goals such as being dependency preserving, providing the basis for key-based integrity maintenance (BCNF) or being redundancy-free (3NF) at least at
the attribute level or avoiding maintenance problems (e.g., insert anomaly) or avoiding data losses (e.g., delete anomaly) or
occurrence of performance traps (e.g., update anomaly). It might be extended to such criteria as being redundancy-free at the
value level.
Textbooks typically dont’t mention that normalisation also introduces additional constraints.
Example 4 The last example results in pairwise inclusion constraints such as the multiple value occurrence bindings R10 [A] ⊆⊇
R2 [A] ⊆⊇ R3 [A]. This inclusion dependency set adds an overhead to integrity maintenance. The functional dependencies
are directly represented through key dependencies. At the same time, any change to A-values in one of the relations must be
harmonised with changes to A-values in the other relations.
Example 5 An example from Date (Theory book)
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
A·
·
-· B
·
·
6··
ab SS 2012
- B
A
·
··
6
- C
:
- E
D
D
FD sets equivalent??
·
··
j C
AB
- E
ABD
·
·
·
·
·
·
189
- E
H
µ
- G
AB
- I
CJ
·
·
·
·
·
·
·
·
·
·
·
·
···
···
···
···
·
-F
- J
C
B
What is a minimal key?
Example 6 An example from Date (Theory book)
Darwen FD rule expressed in a simple graphical form and directly understandable!!!
X → Y0 Y1 , Y1 Y2 → W
XY2 → Y0 Y1 W
X··
- Y
s
Y
0·············
·
··
··
·········
··
··········
··
1
·
···
···
2
··
··
·
·
··
1 2
··
·
·
··
·
···
··
· ······
··
XY
Y Y
Y0 Y· 1 W
···
··
··
··
·
- W
XY2
Y2
Abbildung 20: Darwen’s FD rule
Example 7 An example from Date (Theory book)
An amasingly simple example if graphical reasoning is used
Easy graphical exploration
Is D in any minimal key?
What are the minimal keys? AB, BC, BE, CF?
Is Date correct? NO!!!!
Difficult but possible
What are alternative reductions?
Which dependencies are central?
Mitunter ist auch die Betrachtung von äquivalenten Mengen von Attributen im Vorfeld sinnvoll.
Example 8 Gegeben seien die Abhängigkeiten:
IS ADD
: Y0
- Y1
zW
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
IS ADD
ab SS 2012
190
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
191
{Kurs} → {Dozent}
{Anf angszeit, Raum} → {Kurs}
{Kurs, Anf angszeit} → {Dauer, Raum}
{Dozent, Anf angszeit} → {Raum}
{Kurs, Student} → {Abschluß}
{Student, Anf angszeit} → {Raum}
Dann erhalten wird den folgenden Graph:
- Dozent
Dauer
Kurs
Abschluß
· ·· ·· · · · · · ·
·
*
········ ····
6 ···
6
· · · · · · ·· ·· ·
···
· ·· ·· · · · · ·
········
···
···
········
···
···
········
···
···
········
·····
··
··
Raum, Anfangszeit
Kurs, Anfangszeit
Dozent, Anfangszeit
Kurs, Student
···
·
··
·
·
·
···
··
·
···
·
···
·
·
·
···
·
·
·
···
···
·
·
···
···
·
·
·
·
·· · ··
¼
9
·
Anfangszeit · · · · · · · · · · · · · Student, Anfangszeit
Raum
Y
Abbildung 21: Ein etwas trickreicheres Beispiel
Es ergibt sich in diesem Beispiel eine Äquivalenzbeziehung:
[{Dozent, Anf angszeit}] = [{Kurs, Anf angszeit}] = [{Raum, Anf angszeit}] .
Daraus resultiert ein Relationship-Typ
oder
Angebot = ( Kurs, Raum, Dozent, { Anfangszeit, Dauer })
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
192
Angebot’ = ( Kurs, Raum, Dozent, Anfangszeit, { Dauer })
mit drei minimalen Schlüsseln.
Mit dem ER-Modell ergibt sich dann das folgende Diagramm:
Schlüssel von Lehrveranstaltung: { Kurs, Anfangszeit }, { Raum, Anfangszeit }
Abhängigkeit {Dozent, Anf angszeit} → {Raum} nur mittelbar
Abhängigkeit {Student, Anf angszeit} → {Raum} wird mittelbar gepflegt!!
Dozent
¾
(0,1)
-
given by
¾
Kurs
belegt
Abschluß
6
?
¾
Raum
Lehrveranstaltung
Anfangszeit
Student
Dauer
Abbildung 22: ER-Diagramm für das Lerhveranstaltungsbeispiel
FD Set Graphs..
Demetrovics, et al., [DMT07] introduce graphical reasoning for sets of constraints. We may represent validity and invalidity of
functional dependencies by a graph. Let us illustrate this approach for relational schemata with three attributes. Visualisations
may be based on more complex figures, e.g. a hexagon for six attributes. To do so we distinguish two kinds of functional
dependencies and display them as follows in Figure 23: Functional dependencies of the form {A} → {B, C} can be decomposed
to canonical functional dependencies {A} → {B} and {A} → {C}. They are represented by endpoints of binary edges in the
triangle representation. Functional dependencies with two-element left-hand sides {A, B} → {C} cannot be decomposed. They
are represented in the triangle on the node relating their right side to the corner.
This notation has the advantage that we are supported for reasoning on potential validity of constraints as well. We may represent also candidates for excluded functional dependencies by crossed circles for the case that we know that the corresponding
functional dependency is not valid in applications or by small circles for the case that we do not know whether the functional
dependency holds or does not hold.
Since the ST implication system is sound and complete for non-trivial canonical functional dependencies, rules (S) and (T)
can be used for deriving all implied functional dependencies given an initial set. Moreover, the PQRST implication system forms
a sound and complete system for both positive and negative (excluded) non-trivial singleton functional constraints, rules (P), (Q)
and (R) can be applied as complements of rules (S) and (T) when excluded functional constraints are taken into account.
These rules can be interpreted in terms of the graphical representation as well. A deduction step using one of them deals
with a node of a higher-dimension object (e.g., a triangle as a two-dimensional object with one of its three vertices) and one or
two of its borders (with one dimension lower, e.g., edges of the same triangle as one-dimensional objects).
(1)
C
A
(2)
B
A
C
(3)
B
C
A
×
×
×
B
Abbildung 23: Examples of the triangle representation. From left to right: (1) The functional dependency {A} → {B}
(filled circle at B side (right side of the FD) of the AB edge) and the implied functional dependency {A, C} → {B}
(circle around node B in the ABC triangle). (2) The functional dependencies {A} → {B}, {B} → {C} and their
implied functional dependencies {A} → {C}, {A, B} → {C}, {A, C} → {B}. (3) The negated functional
dependency {A, C} Y→ {B} (crossed filled circle around node B in the ABC triangle) and the implied negated
functional dependencies {A} Y→ {B} (crossed circle at B side of the AB edge) and {C} Y→ {B}.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
193
Abbildung 24: Graphical versions of rules (P), (Q), (R), (S) and (T) in terms of the triangle representation. The small
black arrows indicate support (necessary context) while the large grey arrows show the implication effects.
Graphical versions of rules are shown on Figure 24 for the triangle representation (case Y = {C}). The large grey arrows
indicate the implication effect of each rule. Rule (S) is a simple extension rule and rule (T) can be called the “rotation rule” or
“reduction rule”. We may call the left-hand side of a functional dependency the determinant of it and the right-hand side the
determinate. Rule (S) can be used to extend the determinant of a dependency resulting in another dependency with one dimension
higher, while rule (T) is used for rotation, that is, to replace the determinate of a functional dependency by the support of another
functional dependency with one dimension higher (the small black arrow at B indicates support of AC → B). Another possible
way to interpret rule (T) is for reduction of the determinant of a higher-dimensional dependency by omitting an attribute if a
dependency holds among the attributes of the determinant.
For excluded functional constraints, rule (Q) acts as the extension rule (i.e., it needs the support of a positive constraint, i.e.,
functional dependency) and (R) as the rotation rule (which needs a positive support too). These two rules can also be viewed as
negations of rule (T). Rule (P) is the reduction rule for excluded functional constraints, with the opposite effect of rule (Q) (but
without the need of support). Rule (Q) is also viewed as the negation of rule (S).
Mehrwertige Abhängigkeiten im falschen Modell.
Cadiou-Definition als die zweitbeste Form und ER-Definition als die bei weitem beste Form!!!
It is often claimed that multivalued dependencies are difficult to model, to teach, to learn and to handle. They are introduced
in almost any database book. The classical introduction is based on the tuple-generating definition of the multivalued dependency
X →
→ Y |Z . It requires that whenever two tuples have the same value on the left-hand side then there also exists a tuple in
the relation class which matches to the first tuple by the left-hand side and the first element of the right-hand side and which
matches to the second tuple by the left-hand side and the second element of the right-hand side. This definition has the clarity of
a mathematical definition and the problematic treatment often observed for other mathematical constructs.
There are however five other definitions for multivalued dependencies that are easier to understand, to handle, and to represent. We may group these definitions as follows:
Derivation constraint: The classical definition is based on the above mentioned tuple generating property. Another definition
uses the construction approach for hinged Cartesian products and binds the validity of the multivalued dependency to the
equality on query expressions (σX=x (RC ))[Y ∪ Z] = (σX=x (RC ))[Y ] × (σX=x (RC ))[Z] is valid for Y, Z with
Y ∩ Z = ∅ for all x ∈ RC [X].
Structure constraint: The structure-oriented definition can be given through
• the decomposition of the original class into two classes, i.e., the original class can be reconstructed by applying the
natural join to the projection of RC to X ∪ Y and X ∪ Z respectively or
• the potential structuring by a nested relation class
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
νY (νZ (RC ))
A1
...
X
...
...
Ak
...
Ak+1
...
ab SS 2012
{Y }
... Am
...
...
Am+1
...
194
{Z}
...
...
An
...
or
• the potential restructuring in an ER model in the following form
Y
¾
XY
(1,n)
¾
XZ
(1,n)
X
-
Z
Independence concept: The original definition [Cad76] uses relative independence of Y -components from Z-components in
a relation class, i.e., the values of the X-components determine the values of Y-components of objects in RC independently
from the values of Z-components, ( (σX=x (RC ))[Y ] = (σ(X=x)∧(Z=z) (RC ))[Y ] for all x-values x ∈ RC [X] and all
z-values z ∈ RC [Z]).
The generation definition is certainly the most mathematical and the least useful among the definitions. The construction definition provides a facility for checking validity. Both definitions also demonstrate that the relational model language is not
appropriate for reasoning on these constraints. The independence notion is the simplest for modelling and for considering. The
structure definitions are certainly the best way for the understanding of these constraints. The ER approach is the best suited
model language for multivalued dependencies.
Example 9 Let us consider a relationship type EmployeeAssociation defined on the entity types: StaffMember, DependentPerson, Project, Supplier, Product with the following multivalued dependencies:
{ StaffMember } →
→ { Department, DependentPerson }|{ Project, Product, Supplier }
{ StaffMember } →
→ { DependentPerson }|{ Department, Project, Product, Supplier }
{ Project } →
→ { StaffMember, Department, DependentPerson }|{ Product, Supplier }
{ Product } →
→ { Department, StaffMember, DependentPerson, Project }|{ Supplier } .
The ER model allows us to derive a new structuring by the decomposition of the relationship type. We obtain the schema in
Figure 25 for which a new type ‘Working’ reflects the separation of concern to PP roduct, Department Staf f M ember and the
independence of suppliers and projects according to the multivalued dependencies.
Department ¾
- StaffMember ¾
Working
Dependent
0..1
0..1
?
Project
of Product
-
Product
¾
Supplier
of Product
Abbildung 25: The decomposition of the relationship type based on multivalued dependencies
Inklusions- und Exklusionsabhängigkeiten.
in 2 verschiedenen Facetten
• Klassenabhängigkeiten zur Existenz von Klassen
daraus resultierend verschiedene Art von Schemata R[X] ⊆ S[Y ]
• partielle Objektredundanz
spezielle Form: referentielle Abhängigkeit mit Fremdschlüssel-Imputation in die existierende Klasse und entsprechender imputierter zusätzlicher Identifikation
2.3.3 Umgebungsdefinition für Integritätsbedingungen
Allgemeines Herangehen:
Umgebung
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
Gültigkeit
Ausnahmebehandlung
Erzwingungsstrategie mit Erzwingungsregel und Erzwingungszzeitpunkt, sowie Priorisierung
Nachsorgestrategie
genauere Ausführung nach den HERM-IC
IS ADD
195
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
196
Probleme mit Integritätsbedingungen
Zerstörung der Lokalität durch globale Auswirkungen innerhalb von Zyklen
¾
Reise
{ 3,4,7 }
richtig: { 3 }
6
besucht
{ 1,2,3,6 }
{1}
richtig: { 6 }
?
startet
-
Stadt
{ 2,3,5,6 }
richtig: { 2 }
Abbildung 26: Lokale Integritätsbedingungen mit globalen Auswirkungen
Pivotisierung durch Identifikation von faktorisierbaren Konstrukten z.B. Integritätsbedingungen, die auf Fakten hinweisen
Übungsleiter
Übungsleiter¾
Kurs
Y
Kurs
betreut
6
0..1
Professor ¾
6
Vorlesung
?
Plan<(Zeit,Raum)>
Professor ¾
Vorlesung
- Angebot
(3,5)
Plan<(Zeit,Raum)>
¼
?
Stud-Gang
¼
?
Stud-Gang
Semester
Semester
card(Vorlesung, Kurs Semester) = (3,5)
look(Vorlesung,Übungsleiter) = 0..1
Abbildung 27: Pivotisierungsauswirkungen lokaler Integritätsbedingungen in zwei Facetten
Globalisierende Integrititätsbedingungen hervorgerufen durch Zyklen
weitere Beispiel in Hartmann-Habil
Institution
(0,.)
leitet
6
- Mitarbeiter ¾
(0,2)
(1,1)
(1,1)
(1,3)
6
arbeitet in
(30,50)
?
fördert
-
(1,.)
Projekt
?
¾
(0,5)
Labor
(0,10)
richtig: (0,30); besser (0,.)
zugeordnet
Abbildung 28: Globale Verwicklungen lokaler Integritätsbedingungen
Löcherfraß in den Integritätsbedingungen durch Nichterfüllbarkeit für Konfigurationen
siehe Hartmann-Mitteilung
Warum dann HERM anstatt von UML.
Mod IS
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
197
Übung:
• EER-Modelle
• Struktur
• Komponenten
• stat. Integritä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
V
α1 , ..., αn which may be pairwise exclusive (αi → ¬αj , i 6= 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 instance2 , αX−→Y =
(o ∈ RC → ¬∃o0 ∈ RC (o[X] = o0 [X] ∧ o[Y ] 6= o0 [Y ])) separates those objects in RC 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 Integritätsbedingungen
Integritätsbedingungen werden in der Literatur noch immer leichtfertig nur in einfacher Form bzw. Rohform spezifiziert. Eine
Spezifikation der Integritätsbedingungen muß umfassen:
Integritätsbedingung in Rohform: Angabe der Integritätsbedingung als logische Formel
Lokalisierung der Integritätsbedingung im Kontext des Systemens, d.h.
durch Angabe der Schema-Umgebung einer Integritätsbedingung (Schema-Frame-Problem) und
durch Angabe der betroffenen Datenbankobjekte, die neben den betroffenen Objekten kontrolliert werden müssen
(DB-Frame-Problem)
Gültigkeit der Integritätsbedingungen je nach Phase der Anwendung, mindestens für die folgenden Phasen
Einfahrphase des Systemes
Normallauf des Systemes
Archivierung der Datenbestände
Ausführungsmodi zur Kontrolle der Integritä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 RC . Tuples (in the case of objectrelational models) or elements of RC are denoted by o. X −→ Y is a functional dependency.
Mod IS
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
198
Ausführungszeit der Kontrolle z.B. verzögert, sofort ggf. auch mit Aussetzen unter bestimmten Bedingungen
Anwendungsmonitoring der Kontrolle der Integritätsbedingungen z.B. auf Objektniveau oder auf Anweisungsniveau
Umformung (term rewriting) der Operationen
Behandlung für den Fall des Nichtgeltens der Integritätsbedingung je nach Datenbankereignis:
Zurückweisen der verursachenden Anweisung
Propagierung der Integritätsbedingung
Nutzung von (temporären) Zusatzwerten zur Kennzeichnung der Situation
Rangordnung der Integritätsbedingung unter den Klassen von Integritätsbedingungen zur Ableitung der Kontrollreihenfolge
Daneben können wir Default-Rahmen angeben:
1. harte Integritätsbedingung ohne das Zulassen von Ausnahmen
2. volle Schema- und DB-Umgebung
3. keine Unterscheidung von Phasen
4. sofortige Kontrolle bei Datenbankereignissen ohne Ergänzung der Operationen
5. gleichwertige Klassen von Integritätsbedingungen
Insbesondere nutzen wir die folgenden Rahmen und Erzwingungsmodi:
1. Spezifikation von Existenzabhängigkeiten
Durch die Komplexitäten sind bereits Abhängigkeiten dargestellt worden, die von den generischen Operationen insert,
delete, update eingehalten werden müssen. Ist für eine Komplexität comp(R, R0 ) = (a, b) a ≥ 1, dann ist jedes insert
in R0 durch ein insert in R zu unterstützen. Jedes delete in R0 kann ein delete in R nach sich ziehen. Alle derartigen
Komplexitäten werden zusammengestellt und in den folgenden Schritten angewandt.
Man kann für jeden Typen eine insert-, delete- und eine update-Umgebung mit folgendem Algorithmus konstruieren.
(a) EnvI (R) := EnvD (R) := EnvU (R) := {R} für jeden Entity- und Relationshiptypen.
(b) Man generiere die Umgebungend erster Ordnung wie folgt.
i. Gilt comp(R, R0 ) = (a, b) für a ≥ 1 dann sei EnvI (R) := EnvI (R0 )∪EnvI (R), EnvU (R) := EnvU (R0 )∪
EnvU (R) und EnvD (R0 ) := EnvD (R) ∪ EnvD (R).
ii. Für jeden Relationshiptypen R0 , in dem R eine Komponente bildet: EnvI (R0 ) := EnvI (R) ∪ EnvI (R0 ),
EnvU (R0 ) := EnvU (R) ∪ EnvU (R0 ) und EnvD (R) := EnvD (R) ∪ EnvD (R0 ).
iii. Für jede Exklusionsabhängigkeit R k R0 gilt EnvI (R0 ) := EnvD (R) ∪ EnvI (R) und EnvU (R0 ) :=
EnvU (R) ∪ EnvU (R).
iv. Weitere Abhängigkeiten werden analog behandelt.
(c) Man wiederhole diesen Schritt bis keine der Mengen verändert wird:
i. Gilt comp(R00 , R0 ) = (a, b) für a ≥ 1 und R00 ∈ EnvI (R0 ) dann sei EnvI (R) := EnvI (R0 ) ∪ EnvI (R).
Gilt comp(R00 , R0 ) = (a, b) für a ≥ 1 und R00 ∈ EnvU (R0 ) dann sei EnvU (R) := EnvU (R0 ) ∪ EnvU (R).
Gilt comp(R00 , R0 ) = (a, b) für a ≥ 1 und R00 ∈ EnvD (R0 ) dann sei EnvD (R0 ) := EnvD (R) ∪ EnvD (R).
ii. Für jeden Relationshiptypen R00 mit R00 ∈ EnvI (R0 ), in dem R eine Komponente bildet, sei EnvI (R0 ) :=
EnvI (R) ∪ EnvI (R0 ). Für jeden Relationshiptypen R00 mit R00 ∈ EnvU (R0 ), in dem R eine Komponente
bildet, sei EnvU (R0 ) := EnvU (R) ∪ EnvU (R0 ). Für jeden Relationshiptypen R00 mit R00 ∈ EnvD (R0 ), in
dem R eine Komponente bildet, sei EnvD (R) := EnvD (R) ∪ EnvD (R0 ).
iii. Für jede Exklusionsabhängigkeit R k R00 mit R00 ∈ EnvI (R0 ) gilt EnvI (R0 ) := EnvD (R) ∪ EnvI (R). Für
jede Exklusionsabhängigkeit R k R00 mit R00 ∈ EnvU (R0 ) gilt EnvU (R0 ) := EnvU (R) ∪ EnvU (R).
iv. Weitere Abhängigkeiten werden analog behandelt.
Mod IS
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
199
Diese Umgebungen sind maximale Umgebungen. Sie werden durch Eigenschaften der Anwendung eingeschränkt.
Durch die Hierarchien sind entsprechende Existenzabhängigkeiten gegeben. Die Generalisierung (z.B. eine Person-dejure ist eine Firma oder eine Person) führt zu einer Existenzabhängigkeit des Supertypen von Subtypen, die unbedingt gepflegt werden muß (d.h. werden die Daten einer Firma entfernt, dann werden diese auch für die Persona-de-jure entfernt).
Die Spezialisierung führt zu einer Existenzabhängigkeit des Subtypen (in unserem Falle Teiltypen (Relationshiptypen
definiert über dem Supertypen)) vom Supertypen.
2. Erzwingungsregeln für insert- Operationen
Man kann für insert-Operationen verschiedene Optionen bestrachten:
• Abhängigkeit: Eine Einfügung ist nur erlaubt, wenn alle korrespondierenden Objekte bereits existieren.
• Automatismus: Eine Einfügung ist stets erlaubt. Wenn entsprechende Objekte nicht existieren, dann werden sie
ebenfalls eingefügt.
• Nullwertebehandlung: Eine Einfügung ist stets erlaubt. Existieren die entsprechenden Objekte nicht, dann werden
für das neue Objekt Nullwerte benutzt.
• default-Werte: Eine Einfügung ist stets erlaubt. Existieren die entsprechenden Objekte nicht, dann werden für das
neue Objekt default-Werte benutzt.
• Zusätzliche Einfügebedingungen: Ein Einfügen ist nur dann erlaubt, wenn eine zusätzliche Bedingung gilt.
• Keine Einschränkung: Das Einfügen unterliegt keiner Beschränkung.
Die letzten beiden Möglichkeiten betreffen alle Typen außerhalb von EnvI (R). Die ersten vier Möglichkeiten sind für
EnvI (R) bei der Spezifikation der Anwendung zu nutzen.
3. Erzwingungsregeln für delete-Operationen
Man kann für delete-Operationen verschiedene Optionen bestrachten:
• Beschrä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.
• Zusätzliche Streichungsbedingungen: Das Streichen ist nur unter bestimmten Bedingungen erlaubt.
• Keine Einschränkung: Das Streichen unterliegt keiner Beschränkung.
Die letzten beiden Möglichkeiten betreffen alle Typen außerhalb von EnvD (R). Die ersten vier Möglichkeiten sind für
EnvD (R) bei der Spezifikation der Anwendung zu nutzen.
SQL2 läßt in der Vollversion Kaskadierung, Nullwertebehandlung, Default-Werte und Beschränkung (ist default) (als ‘no
action’) zu.
4. Erzwingungsregeln für update-Operationen
• Beschränkung: Ein update ist nur erlaubt, wenn kein anderes Objekt davon betroffen ist (z.B. auch über Sekundärschlüsseln, die nicht in Beziehungen verwandt werden).
• Automatismus: Ein update ist stets erlaubt, solange Integritätsbedingungen des Typs nicht verletzt werden.
• Kaskadierung: Ein update löst weitere Operationen aus.
• Nullwertebehandlung: Konflikte werden durch Nullwerte gelöst.
• default-Werte: Zur Konfliktbereinigung werden default-Werte benutzt.
• Zusätzliche update-Bedingungen: Ein update ist nur unter zusätzlichen Bedingungen möglich.
• Keine Einschränkung.
Eine update-Operation ist nicht das Gleiche wie eine delete;insert-Folge.
SQL2 läßt in der Vollversion Kaskadierung, Nullwertebehandlung, Default-Werte und Beschränkung (ist default) zu.
Mod IS
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
200
Erzwingungsregeln
¼
?
Unbedingte
Erzwingung
Keine
Erzwingung
j
Bedingte
Erzwingung
j
mit
zusätzlichen
Kaskadierung
EinfügeNullwertedefaultbehandlung
Werte
Abhängigkeit
bedingungen ;
Prädikat
Abbildung 29: Mögliche Erzwingungsregeln für generische Operationen
¼
?
j
?
an Existenz
gebunden;
Rollback
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 für die Betrachtungen hier zu komplex.
Die Integritätsbedingungen sind in SQL-92 in unterschiedlichen Modi und Matching unterstützt, wobei deren Zusammenwirken nicht erklä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
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
201
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 für die Pflege der Integritä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.
R1
restrict
nullify
9
R2
cascade
?
R6
restrict
¼
R3
cascade
cascade
j
R4
nullify
cascade
?
R6
NULL
?
R6
NIL ???
z
R5
default
?
R6
DEFAULT
Abbildung 30: Das ‘diamond’-Problem bei der Erzwingung von foreign key constraints
Es werden zwei Wertezuweisungen für den Wert des gleichen Objekts in R1 vorgenommen ausgehend von gleichen Objekt
in R6 . Die zugehörigen foreign key constraints sind R2 ⊆ R6 , R3 ⊆ R6 , R4 ⊆ R6 , R5 ⊆ R6 , R1 ⊆ R2 , R1 ⊆ R3 , R1 ⊆
R4 , R1 ⊆ R5 , .
Mod IS
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
202
2.4 Ein Datenbank-Schema
ER besteht aus einer Menge von Typen {Ti = (UTi , ΣTi )} und globalen statischen Integritätsbedingungen ΣER .
Datenbankmodellierung und das Abstraktionsschichtenmodell
Unsere Strukturierungssprache unterstützt das Abstraktionsschichtenmodell. Es kann die Strukturierung der Daten in jeder
Schicht durch das Entity-Relationship-Modell repräsentiert werden. Wir verwenden dazu Schemata unterschiedlicher Abstraktheit und Granularitä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 Integritätsbedingungen
angegeben, das die Typen des Lastenhefts verfeinert. Die Verfeinerung findet durch Spezialisierung der Typen, Dekomposition, strukturelle Erweiterung, semantische Einschränkung, Separation von Aspekten und durch Instantiierung statt.
Zusätzlich werden weitere Typen eingeführt.
Anwendungsschema: Das Anwendungsschema repräsentiert alle Typen, die für den Anwender eine Bedeutung haben. Die
Typen stellen eine Verfeinerung der Typen des Pflichtenhefts dar oder sind neu eingeführt.
Konzeptionelles ER-Schema: Auf der konzeptionellen Schicht wird ein detailliertes HERM-Diagramm erstellt, das u.a. auch
für alle Typen des Anwendungsschemas entsprechende Verfeinerungen enthä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 üblicherweise ein objekt-relationales oder relationales Schema, aber auch eine Beschreibung als XMLSchema oder DTD-Datei (document type definition) sein.
Diese Schemata sind aufeinander abbildbar. Demzufolge kann jede Entwurfseinheit einer höheren Schicht - so wie in Bild ??
auf Seite ?? dargestellt - einer Menge von Entwurfseinheiten der folgenden Schicht direkt zugeordnet werden.
Wir merken an, daß wir über zwei unterschiedliche Methoden zur Darstellung, Repräsentation, Verarbeitung und Speicherung von Objekten verfü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
über einen Surrogat-Schlüssel, eine Markierung oder Werte zum ausgewählten Schlü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 können über diesem Graphen beliebige Ü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 für eine Objekt-Entfaltung zum Schema in Bild 6 ist folgendes XML-Dokument:
<Lehrveranstaltung ID="120201" Titel = "DB-Programmierung" Typus = "TypusID1"
Erfuellung = "gehalten">
<geplant durch="Fak.-Ref. Schenk"><Dozent Name = "beta"/><Raum = "SR1"/>
<Zeit = "AB, Mittwoch, 7.30 - 9.00"/>
<Aenderung Datum = "1.1.2000"><Vorschlag><Zeit><von>Montag</von>
<in>Mittwoch</in></Vorschlag>
</Aenderung></geplant>
<Studiengang Name ="Informatik" Phase = "Hauptstudium"/>
<Typus ID = "TypusID1"> <Art>Normalvorlesung</Art> <Umfang> 2+2+2 </Umfang> </Typus>
<Kurs Name = "Datenbanken III"><Inhalt ID ="4711"> .... </Inhalt> ... </Kurs>
<Semester>Sommersemester 2000, 10.4. 2000 - 15.7.2000</Semester>
<Verantwortlicher><Lehrveranstaltung><Dozent Name = "beta"/> <Uebung Name = "Feyer"/>
<Praktikum Name ="Vestenicky"/></Lehrveranstaltung>
<Planung><geplant durch>Fak.-Ref. Schenk</geplant durch>
Mod IS
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
203
Konzeptlandkarte
Anwendungsschicht
Vorstudie
Skizzierung
Konzept
Lastenheft: Daten
Skizze
Geschäftsprozeßschicht
Feinstudie
Darstellung
Grober Typ
Pflichtenheft: Daten
Skelett
Aktionsschicht
Entwurf
Entwurf
Anwendungstyp
Anwendungsschema
konzeptionelle
Schicht
Schema
Implementation
Transformation
Typ
ER-Schema
Implementationsschicht
Schema
logischer
Typ
logisches Schema
Abbildung 31: Die Arbeitsprodukte im Abstraktionsschichtenmodell für die Strukturierung
Mod IS
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
204
<Datum>1.4.1999, .... </Datum></Planung>
<Vorschlag ID ="08015" Von = "KK"> <Sonderwunsch><Zeit>AB, Montag, 7.30-11.00</Zeit>
<Raum><Ausstattung>Beamer, Netzanschlu&szlig;</Ausstattung><Raum>
<Nicht-Parallel>Datenbanken I</Nicht-Parallel></Sonderwunsch></Vorschlag>
</Lehrveranstaltung>
Die erste Methode wird meist für die Speicherung und Verarbeitung in relationalen und objekt-relationalen DBMS angewandt.
Die Repräsentation erfolgt auf der Grundlage von Sichten, die im Kapitel ?? ausführlich dargestellt werden. OLAP-Zugänge
verwenden oft den zweiten Zugang. Die zweite Methode wird auch bei XML-DBMS angewandt.
Die Redundanz-Beherrschung ist nach wie vor für beliebige Objektmengen wichtig. Deshalb ist der erste Zugang vorzuziehen. Wir unterstützen diesen Zugang durch Einfü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
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
205
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 0 . Integrity constraints are defined for the
schemata: ΣERS , ΣERS 0 . The set of all databases on ERS is denoted by R(ERS). Let SAT (ERS) (SAT (ERS 0 )) be the set
of all databases defined on ERS that satisfy ΣERS (respectively ΣERS 0 ). The translation Φ is a mapping from R(ERS) to
R(ERS 0 ).
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 = ({StN umber, Course, Address},
{StN umber, 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 = (X1 , ...Xn ) and the
reconstruction operator Ψ =1. Local vertical normalization on the type level is often considered to be the ultimate goal of the
database design process.
Mod IS
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
206
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 = (X1 , ..., Xn ) is called lossless if for each class RC the equality RC = πX1 (RC ) 1 ... 1 πXn (RC ) 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 = (X1 , ..., Xn ), let Σi = {X → Y |X, Y ⊂ Xi , Σ |= X → Y }.
The decomposition via d is constraint preserving if
Sn
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 0 exist in R with K ∩ K 0 6= ∅ [VS93a].
Mod IS
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
207
• Given a type R which is in 3NF according to a set Σ of functional dependencies. If all different minimal K, K 0 in
R are disjoint, i.e., K ∩ K 0 = ∅ 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 Fd via a join dependency d = (X1 , ..., Xn )
Sn
with ΣS ⊆ 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 = (S1 , ..., Sn , ΣS ) the inclusion constraints SiC [Xi ∩ Xj ] ⊆ SjC [Xi ∩ Xj ] are implied
Sn
from ΣS . Furthermore, ΣS ⊇ 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
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
208
• 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 R0 = (compon(R0 ), ΣR0 ) which is not in BCNF.
Choose a partition of compon(R0 ) into X, Y, Z such that
ΣR0 |= X → Y and
ΣR0 6|= X → {A} for each A ∈ Z.
0
0
Replace R0 = (compon(R0 ), ΣR0 ) by R10 = (compon(R0 ) ∩ XY, ΣRXY
) and R20 = (compon(R0 ) ∩ XZ, ΣRXZ
).
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
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
209
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.
Course
)
q
Section, Semester
Text
9 )
ª
R
Lecturer Time Room Grader
ª
R
Lab Material
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 , ∅ ),
Lecture0 = (Course, Semester, { Section }),
Lecture1 = (Lecture0 , { Time }),
Lecture2 = (Lecture0 , Room, ∅ ),
Lecture3 = (Lecture0 , Grader, ∅ ),
Lecture4 = (Lecture0 , Lecturer, ∅ ),
Lecture41 = (Lecture4 , Lab, ∅ ),
Lecture42 = (Lecture4 , 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
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
210
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 äquivalenten linken Seiten
.
Einige Synthesealgorithmen verzichten auf die Bildung von Äquivalenzklassen. Damit kann ggf. ein Schema entstehen, das
zwar normalisiert, aber nicht sinnvoll ist.
Es ist jedoch sinnvoll, die folgende Ergänzung vorzunehmen.
Problem
Problem dieser Vereinfachung: Es können unnö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 Äquivalenzklassen von Teilmengen von Attributmengen
eingeführt. Dann wird eine Zusammenfassung der FD’s mit äquivalenten linken Seiten vorgenommen (statt gleiche linke Seiten). Die Sammlung erfolgt dann für eine Ä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 Zusammenführung aller funktionalen Abhängigkeiten mit der gleichen rechten Seite.
Man betrachte dazu folgende Relation:
AG
AGNummer Bezeichn Institut
...
...
...
AG
AGNummer ... Lieferadr
...
...
...
WebAdr Fax Sachgebiet Sekr.Ort Sekr.Tel EmailKontakt
...
...
...
...
...
...
Besuchsadr Postadr Kostenstelle Leiter Anreisekarte ...
...
...
...
...
...
...
...
In dieser Relation ist das Attribut AGNummer ein Schlüssel, wobie durchaus andere sinnvolle Schlüssel existieren, z.B. das
Attribut Kostenstelle.
Beobachtung: Diese Relation vereinigt zuviele unterschiedliche Aspekte, die eigentlich getrennt werden sollten.
Mod IS
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
211
Eine gü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
6
Kostenstelle
- Sachgebiets-
Sachgebiet
AGNummer
Bezeichnung
WebAdr
...
Fax
Tel
Ort
¼
Arbeitsgruppe ¾
Klassifikation
?
6
K
Hauptzuordnung
-
Institut
I
Postadresse
Lieferadresse
Kontakt
Besuchsadresse
Anreisekarte
EmailKontakt
Sekretariat
6
Sekretä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
T1 , ..., Tn results in additional integrity constraints.
Pairwise inclusion constraints: In the case of vertical decomposition we introduce pairwise inclusion constraints on components compon(Ti ) of the types Ti .
Ti [compon(Ti ) u compon(Tj )]
⊆⊇
Tj [compon(Ti ) u compon(Tj )]
∀i, j(1 ≤ i < j ≤ n)
We denote by u 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
Unä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 Abhängigkeiten als (0,1)-Kardinalitäten sind dabei ausgelassen.
Mod IS
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
212
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
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
213
2.5.6 Horizontal Decomposition
Horizontal decomposition is as simple as vertical decomposition. Given a type R = (compon(R), Σ) and a dependency α on
R which does not follow logically from Σ. We can decompose the class RC into those objects which satisfy α and those which
do not. This defines a R − (R1 , R2 ) translation Φα . The inverse translation Ψα is given by the union operation. In [MR98] the
following proposition has been proven:
Proposition 1 Let α1 , α2 be obtained from α by substituting R1 , respectively R2 for R. Let RC ∈ SAT (R). Then
(i) α1 is valid in Φ∗ (RC ).
#
(ii) Φ#
α (α1 ) and Φα (¬α2 ) are tautologies.
(iii) Φα is information preserving.
#
(iv) Φ#
α (Ψα (Σ) ∪ {α1 , ¬α2 }) is equivalent to Σ.
∗
(v) Ψ is a reduction from SAT ((R1 , R2 , Σ) ∪ {α1 , ¬α2 }) to SAT (R).
(vi) Φ∗ is a reduction from SAT (R) to SAT ((R1 , R2 , Σ) ∪ {α1 , ¬α2 }) and a left inverse of Ψ∗ .
It is obvious that this approach can be extended to arbitrary selection conditions defined on the type R.
Now let us consider another normalization problem using a list of parts example. Particularly in the case of recursive
relationship types and (0,m)-cardinality constraints the possibility of overloading relationship type causes strange behavior of
the database. In Figure 34 a part-subpart relationship type is used for the illustration of problems which can be solved by
hierarchical decomposition. The Part type can be decomposed horizontally into the types Assembly and Component. In this
case, the cardinality constraints do not change. This decomposition uses the subtype relationship according to the labels of the
relationship type. This example shows that recursive relationship types can be replaced by a certain hierarchical scheme.
Part
6
Assembly 6
Component
(0,m)
(0,m)
MadeOf
Horizontal Decomposition
Hierarchical Set MadeOf
Part
µ
Assembly ¾
I
MadeOf
-Component
Abbildung 34: The Decomposition of Recursive Relationship Types.
Let us now extend the list of parts example. The list of parts of a certain product is the description of all items of which it
consists. The list of items tries to decompose the description of all items down to the lowest level of data. No further decomposition can be applied. A component can appear several times on the list and on different levels. Companies use lists of materials
a great deal, since they need to store information on their products for matters concerning billing, organization, planning and
control. The list of parts example has been discussed over a long period of time, as it illustrates disadvantages of the relational
approach. In particular, lists of parts of higher depth can be used to demonstrate one disadvantage of the classical ER model. Let
us use a modified example, presented in [CGT90]. An engine contains spark plugs, cylinders, valves and crank shafts. Cylinders
are composed of pistons and connecting rods. Valves contain gaskets and hangers. Crank shafts contain joints. Bolts and screws
are components of connecting rods, hangers and joints. Gaskets are components of pistons and valves. We want to represent the
number of elements for the composition.
This example can be represented by a general part-subpart entity type, with various entity types representing the information for
different categories of parts (screws, bolts, etc.). It is possible to represent this information by the following general part-subpart
types and elementary part entity types:
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
214
Gasket = ({ Type, Diameter, Gauge }, { Type} ),
Bolt = ( { Type, Length, Diameter, Gauge }, {Type} ),
Screw = ( { Type, Length, HeadType, Diameter }, {Type} ),
SparkPlug = ( {Type, MaxTemparature, Diameter }, {Type} ),
Part = ( { Type }, { Type } ),
GasketIsAPart = ( Gasket, Part, ∅ ),
BoltIsAPart = ( Bolt, Part, ∅ ),
ScrewIsAPart = ( Screw, Part, ∅ ),
SparkPlugIsAPart = ( SparkPlug, Part, ∅ ),
Part-Subpart = ( Part, Subpart:Part, { NoOfSubparts }).
The Is-A relationship types are simply inclusion dependencies. However, in this scheme a closure dependency [GSS89] is valid
which requires that only subparts defined as parts or bolts, screws or gaskets are used. This dependency requires computation
of a transitive closure for maintenance and cannot be computed on the basis of relational algebra. For this reason, the following
scheme representing the hierarchical structure would be more appropriate. This schema is represented in Figure 35.
Gasket = ({ Type, Diameter, Gauge }, { Type} ),
Bolt = ( {Type, Length, Diameter, Gauge }, {Type} ),
Screw = ( {Type, Length, HeadType, Diameter }, {Type} ),
SparkPlug = ( {Type, MaxTemparature, Diameter }, {Type} ),
Piston = ( Gasket, {Type, NoOfGaskets }),
ConnectingRod = ( Bolt, Screw, {Type, NoOfScrew, NoOfBolt }),
Hanger = ( Bolt, Screw, {Type, NoOfScrew, NoOfBolt }),
Joint = ( Bolt, Screw, {Type, NoOfScrew, NoOfBolt }),
Cylinder = ( Piston, ConnectingRod,
{Type, NoOfPiston, NoOfConnectingRod }),
Valve = ( Gasket, Hanger, {Type, NoOfGasket, NoOfHanger }),
Crankshaft = ( Joint, {Type, NoOfJoint }),
Engine = ( Cylinder, Valve, Crankshaft, SparkPlug,
{Type, NoOfCylinder, NoOfValve, NoOfCrankshaft,
NoOfSparkPlug }),
where entities and relationships can be identified by their corresponding Type value and components of relationship types determine the number of items necessary for this part from the component parts, i.e.,
R : R0 −→ {N oOf R0 }.
The closure dependency mentioned above is replaced by the implicit inclusion dependencies in the type definition. Therefore,
the last schema is easier to maintain and clearly arranged.
The functional dependency shows that all relationship types can be normalized. This is necessary if there are more complex
attribute sets characterized by components. Generally speaking, given the relationship type
R = (R1 , ..., Rn , {A1,1 , ..., A1,m(1) , A2,1 , ..., An,m(n) , B1 , ..., Bm })
and for all i , 1 ≤ i ≤ n the functional dependencies
R : Ri −→ {Ai,1 , ..., Ai,m(i) },
then we can decompose the type R and use new types Ri0 for i, 1 ≤ i ≤ n:
Ri0 = (Ri , {Ai,1 , ..., Ai,m(i) }) and, R = (R10 , ..., Rn0 , {B1 , ..., Bm }).
The reason for the existence of this equivalent representation is the existence of horizontal decomposition dependencies [PBGG89,
?] (or inherence axioms [SI91]). Let us analyze this example in more detail. We find that all items can be divided into the categories Sparkplug, Gasket, Bolt, Screw, ConnectingRod, Hanger, Joint, Crankshaft, Valve, Cylinder and Engine. The latter seven
categories are not directly represented but they can be included easily by adding entity types and the corresponding relationship
type Is-A to the first representation. In this case Part can be directly represented as a cluster of Sparkplug, Gasket, Bolt, Screw,
ConnectingRod, Hanger, Joint, Crankshaft, Valve, Cylinder and Engine. In this case, the first representation is equivalent to the
representation shown in Figure 36.
In this case, the Part-Subpart relationship type satisfies horizontal decomposition constraints specified by path inclusion
dependencies such as
P iston0 ← P art ← P art − Subpart [P iston0 .T ype] ⊆
P iston0 ← P art ← P art − Subpart → P art → Gasket [P iston0 .T ype].
This dependency states that pistons consists only of gaskets. Similarly, we can specify that engines consist only of sparkplugs,
cylinders, valves and crankshafts using the union of paths on the right side of the path inclusion dependency.
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
215
Engine
ª
¼
Spark plug
R
Cylinder
ª
Valve
?
R
Crankshaft
?
Connecting
Rod
Piston
j
?
Hanger
²
R
?ª
Gasket
Bolt
Joint
R
?
s Screw
Abbildung 35: Depth-Restricted Horizontal Decomposition of Part-Subpart
Sparkplug
}
Gasket
Screw
Bolt
]
O
º
>
Á
3Connecting
Rod’
Valve’ k
Crankshaft’
y
Cylinder’ ¾
Hanger’
Piston’
:
L
Engine’
- Joint’
Part
6 6
Part Subpart
Abbildung 36: The Cluster Representation of Part-Subpart
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
216
This horizontal decomposition allows the closure dependency to be broken, since in this case the recursion in the PartSubpart type is of bounded length. Therefore, the schema in Figure 35 is equivalent to the first representation.
However, with regard to the schema in Figure 35 the part-subpart relationship is of finite depth. In this case, the relationship
type MadeOf is decomposed together with the horizontal decomposition of the Part entity type. This leads to a schema with
more information and with cardinality constraints of finer granularity.
The valences concept is useful when evaluating horizontal decompositions. According to [ZB92] cardinality constraints can
be directly used for definition of relationship types. This concept can be extended directly for relationship types.
Let us assume that the type constructors ×, ∪, + (see also Chapter ??) are defined for construction of tuple types, union
and exclusive union (discrepancy). On the basis of the set of entity types E = {E1 , ..., Em } and a set of attributes U , the set of
all terms on E ∪ U can be defined as follows:
1. IE is a term for an element E from E and an interval I ⊆ N .
2. If t1 is a term and t2 is a term or an attribute from U and I, I 0 ⊆ N are intervals, then (I1 t1 × I2 t2 ), (I1 t1 ∪ I2 t2 ), (I1 t1 +
I2 t2 ), are terms.
The semantics of valences can be defined in the corresponding manner using the construction of terms. A relationship type can
then be defined by a term.
It should be noted that the valence concept cannot be used to replace the concept of cardinality constraints. It can be used
in the same way as the concept of nested hierarchical relations. This concept can be modified by also taking into account role
names [PS89].
For instance [ZB92], an ensemble could be defined by
((((({1}Dress + ({1}Blouse × {1}({1}Skirt + {1}T rousers)))
×{0, 1}Jacket) × {0, 1, 2, 3}N ecklace) × N ({2}Stocking)
×{1}({1}Right : Shoe × {1}Lef t : Shoe).
The valences concept can be used for representing horizontal decompositions.
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
217
2.5.7 Deductive Normalization
The idea of using first-order logic in clausal form as a programming language has been applied in many different fields, such
as algebraic manipulation, robotics, compilers, and natural language processing. General laws are also useful in order to avoid
redundancy and in connection with updating (trigger concepts). Normalization of relations is one of the most important approaches to database design. The concept of dependencies has proved to be useful in design and analysis of databases, for instance
for normalization. However special kinds of constraints can also be useful when reducing databases to a deductive basis. For
instance, databases which are huge, seldom modified and only sometimes queried require another approach for storage cost
minimization. Archive databases are a special kind of such databases. By using special tuple-generating dependencies, for instance, we obtain the initial database from its subset, e.g. its deductive basis. During the query phase, rules are used to generate
all possible derivations of facts and thereby make them explicit in the database again. However, before using this approach the
termination problem should be resolved since rules may lead to potentially infinite derivation paths.
We will now consider the concept of deductive normalization on the type level. This concept can also be developed on the
scheme level. However, in this case it is more complex. For instance, inclusion constraints affect the way the deductive basis is
generated. The restriction to types allows the utilization of relational arguments since our ER model uses a set semantics for all
its types.
We are given a relation scheme R = (U, Ψ) where U = {A1 , ..., An } and a template dependency
α = .(PR (x̂1 ) ∧ ... ∧ PR (x̂k ) → PR (x̂0 ))
from LR . Let RC be a relation on R.
Define the application α(RC ) of α to RC as
RC ∪ { t | a substitution S on RC exists such that
S(x̂i ) ∈ RC and S(x̂0 ) = t }.
For the set of template dependencies Σ = {α1 , ..., αs } ⊆ LR the application Σ(RC ) of Σ to RC is defined by Σ(RC ) =
α1 (α2 (...(αs (RC )...)).
Now αk (RC ) denotes the result of k applications of α to RC ,
Σk (RC ) - the result of k applications of Σ to RC ,
∗
α (RC ) - the result of many arbitrary applications of α to RC and
Σ∗ (RC ) - the result of many arbitrary applications of Σ to RC .
These definitions can be easily extended to sequences of types ERS and to general implicational dependencies
.(P1 (x̂1 ) ∧ ... ∧ Pm (x̂m ) → Q1 (ẑ1 ) ∧ ... ∧ Ql (ẑl ))
and ERS-databases.
Generally speaking, we can use the chase procedure
introduced in Section ??. For a relation RC we define the set PRC =
V
C
{PR (ĉ) | (ĉ) ∈ R } and the formula αRC = (( β∈P C β) → γ) for γ ∈ PRC .
R
Given now a set Σ of constraints, the closure by chase procedure is defined by
Chase(RC , Σ) = {(ĉ) | PRC (c) ∈ Cl(Σ, αRC )} .
The first question which needs to be answered is whether this procedure terminates in finite time frames.
Corollary 4 For schemes R = (U, Ψ), a set of template dependencies Σ and a relation RC on R, a number k, k ≤| RC ||U |
exists such that Σ∗ (RC ) = Σk (RC ).
Corollary 5 For a relation scheme R = (U, Ψ), a set of template dependencies Σ from LR and a relation RC , the following
are equivalent:
(1)
|=C Σ ;
(2)
(3)
R
Σ∗ (RC ) = RC ;
Ψ |= Σ .
Take a scheme R = (U, Ψ), a set Σ of template dependencies and a relation RC with |=C Σ . A subset RC of RC is called
R
an Σ-deductive subset if Σ(RC+ ) = RC .
In relation to Σ the deductive subset contains relative to Σ the same information as the original set. Therefore, we can use the
deductive subset together with a set of formulas instead of the original set. Minimal deductive subsets are of particular interest.
A Σ-deductive subset RC which is minimal, i.e., there is no proper subset RC++ of RC+ such that Σ(RC++ ) = RC , is
called a Σ-deductive basis of RC .
For R = (U, Ψ) and the set Σ = {α | Ψ |= α, α - template dependency} any Σ-deductive basis is called deductive basis of
RC .
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
218
Corollary 4 restricts the set of iterations to a boundary which is dependent on the relation. Since the size can be very large,
we are interested in those schemes in which the computation of closure is less complex.
A template dependency α ∈ LR (or a set of template dependencies Σ ⊆ LR is bounded if a number k exists such that for
any relation RC on R α∗ (RC ) = αk (RC ) (or Σ∗ (RC ) = Σk (RC )). The smallest k for this property is called the limit of α
(resp. Σ).
Let us consider the following relational schema R = ({A1 , A2 , A3 }, ∅) ,
α = .(P (x1 , x2 , x03 ) ∧ P (x1 x02 , x3 ) → P (x1 , x2 , x3 )), and the relation
RC = {(0, 0, 0), (0, 1, 1), (0, 1, 0), (0, 0, 1), (1, 0, 0)}. The subsets
RC+ = {(0, 0, 0), (0, 1, 1), (1, 0, 0)} and RC++ = {(0, 0, 1), (0, 1, 0), (1, 0, 0)} are α-deductive bases of RC . It can be shown
that the limit of α is 1.
The deductive bases of a relation can also be considered as a deductive normal form.
These normal forms can be more effective, according to the storage requirements, than the known classical normal forms.
Let RC be a relation on R = (U, Ψ). For a multivalued dependency α |=C α. Let d = (X, Y ) be the binary join dependency
R
corresponding to α. Thus RC = RC [X]∗ RC [Y ].
We can now introduce a simple complexity measure: k RC k=| r | · | U | , i.e., length of tuples multiplied by number of tuples.
Let RC+ be the α-deductive basis of RC . Thus we get k RC+ k≤ k RC k . Examples exist for which decomposition
using the join dependency α is more effective than the deductive normal form. However, these examples assume the case that
k RC [X] k¿k RC [Y ] k . On the other hand, for the set of relations with balanced decompositions (i.e., k RC [X] k≈k RC [Y ] k
), deductive normal forms are more effective than vertically decomposed normal forms.
There are two main problems:
1. Take a Σ-deductive basis RC of a relation Σ∗ (RC ). How many steps are required to evaluate Σ∗ (RC ) ? What is the limit of
Σ estimated to be ?
2. Take RC and Σ . How can a Σ-deductive basis of RC be constructed ?
With regard to the second problem there are recognized algorithms [CGT90, Das92, Tha90]. The first problem is more
complicated. If the set Σ is unlimited, then the use of Σ-deductive bases is pointless.
Corollary 6 Sets of multivalued dependencies are unlimited in general (respectively also: sets of (binary) join dependencies).
Template dependencies are also unlimited in general.
We can use the following example in order to prove the corollary .
Given, for example, R = (U = {A1 , A2 , A3 , A4 }, Ψ) and
α1 =
.(P (x, y, z, u0 ) ∧ P (x, y, z 0 , u) → P (x, y, z, u)), ,
α2 =
.(P (x0 , y, z, u) ∧ P (x, y 0 , z, u) → P (x, y, z, u)) ,
Σ = {α1 , α2 }
t1 = (0, 0, 0, 0) and for i, 1 ≤ i ,
t2i [{A1 , A2 , A3 }] = t2i−1 [{A1 , A2 , A3 }] , t2i (A4 ) = t2i−1 (A4 ) + 1 ,
t02i [{A1 , A2 , A4 }] = t02i−1 [{A1 , A2 , A4 }] , t2i (A3 ) = t2i−1 (A3 ) + 1 ,
t2i+1 [{A1 , A3 , A4 }] = t2i [{A1 , A3 , A4 }] , t2i+1 (A2 ) = t2i (A2 ) + 1 ,
t02i+1 [{A2 , A3 , A4 }] = t2i [{A2 , A3 , A4 }] , t02i+1 (A1 ) = t2i (A1 ) + 1 .
C
\ {ti−1 } ∪ {ti , t0i }, i.e., for example
If R1C = {t1 } and i ≥ 2, then RiC = Ri−1
R1C
0000
R2C
0100
1000
R3C
0101
0110
1000
R4C
0201
2101
0110
1000
R5C
0202
0221
2101
0110
1000
R6C
0302
3202
0221
2101
0110
1000
R7C
0303
0332
3202
0221
2101
0110
1000
C
C
C
C
then it is true that (0, 0, 0, 0) ∈ Σi (Ri+1
) and (0, 0, 0, 0) 6∈ Σi−1 (Ri+1
) for i ≥ 1, i.e., Σi (Ri+1
) 6= Σi−1 (Ri+1
) . Therefore Σ
is unlimited. For α =
.(P (x, y 0 , z, u0 ) ∧ P (x0 , y, z, u0 ) ∧ P (x, y 0 , z 0 , u) ∧ P (x0 , y, z 0 , u) → P (x, y, z, u)) the second statement of the corollary is
valid since it implies Σ.
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
219
Since the set of multivalued or join dependencies is already too powerful we should restrict deductive normal forms either
to singleton constraint sets, simple constraint sets or to less powerful constraint classes. Since the latter is not practical we now
need conditions on constraint sets.
A set of decomposition dependencies Σ (or join dependencies) is called a Sheffer-set if there is a decomposition dependency
αΣ where Σ |= αΣ and {αΣ } |= Σ . Decomposition dependencies are first-order predicate logic representations of join dependencies.
It is important to bear in mind that any finite set of template dependencies has this property. Therefore, the extension of Sheffersets to template dependencies is pointless.
Corollary 7 If Σ is a Sheffer-set whereby Σ |= αΣ and {αΣ } |= Σ for a decomposition dependency αΣ , then for any relation
∗
(RC ) = Σ∗ (RC ).
RC on R it is true that αΣ
Theorem 2 [Tha85] Any Sheffer-set Σ of decomposition dependencies is limited. For any relation RC on R it is true that
αΣ (RC ) = Σ∗ (RC ) .
This theorem shows that ER schemes which have a Sheffer-set of join dependencies can be deductively normalized. Furthermore,
a join dependency which is equivalent to a Sheffer-set can evaluate the normal form in one step.
In order to prove this we use the approach of [MN83] for recursive axioms. Take a template dependency α with the set Var(α)
y1
y2
yk
k
of variables and a subset V of Var(α) . A substitution σxy11 ...y
...xk = σx1 (σx2 (...(σxk )...)) of old variables xi and corresponding new
variables yi is said to be safe (with regard to α and V ) if {y1 , ..., yk } ∩ Var(α) = ∅ and {x1 , ..., xk } ∩ V =
∅.
Take two sets of formulas Σ1 = {β1 , ..., βp } and Σ2 = {π1 , ..., πq } with the set V of variables in Σ1 and Σ2 and
the set V2 of variables used in Σ2 . The set Σ2 subsumes Σ1 with regard to V if there is a safe substitution σ with regard to
(π1 ∧ ... ∧ πq , V2 ) such that C1 ⊆ {σ(π1 ), ..., σ(πq )} .
We will now define a particular sequence ωi (Σ, P (x̂)) for a set Σ of template dependencies and a formula P (x̂):
ω0 (Σ, P (x̂)) = {P (x̂)} ;
ωi+1 (Σ, P (x̂)) = ωi (Σ, P (x̂)) \ {P (ŷ)} ∪ {P (ŷ1 ), ..., P (ŷs )}
for P (ŷ) ∈ ωi (Σ, P (x̂)) and .(P (ẑ1 ) ∧ ... ∧ P (ẑs ) → P (ẑ)) ∈ Σ if there is a safe substitution σ with σ(P (ẑ)) = P (ŷ) , and
σ(P (ẑi )) = P (ŷi ) .
Any such sequence ω0 (Σ, P (x̂)), ω1 (Σ, P (x̂)), ..., ωi (Σ, P (x̂)) corresponds to the generation of a new element in Σi (RC ) and
vice versa.
Obviously the following is applicable [CL73]:
Lemma 2.1 Take a sequence ω0 (Σ, P (x̂)), ω1 (Σ, P (x̂)), ..., ωi (Σ, P (x̂)), ...
If for j ωj (Σ, P (x̂)) subsumes ωj−1 (Σ, P (x̂)) then the sequence is equivalent
to ω0 (Σ, P (x̂)), ω1 (Σ, P (x̂)), ..., ωj−1 (Σ, P (x̂)) .
Proof of Theorem 2: Take a decomposition dependency α. Any sequence
ω0 (Σ, P (x̂)), ω1 (Σ, P (x̂)), ..., ωi (Σ, P (x̂)), ... is equivalent to
ω0 (Σ, P (x̂)), ω1 (Σ, P (x̂))
since for
α = .(P (x̂1 ) ∧ ... ∧ P (x̂k ) → P (x̂0 )) , ω1 (Σ, P (x̂)) = {P (ŷ1 ), ..., P (ŷk )} and
ω2 (Σ, P (x̂)) = {P (ŷ1 ), ..., P (ŷi−1 ), P (ŷi+1 ), ..., P (ŷk ), P (ẑ1 ), ..., P (ẑk )},
a safe substitution σ exists for P (ẑ1 ), ..., P (ẑk ) such that ω2 (Σ, P (x̂)) subsumes ω1 (Σ, P (x̂)).
Lemma 2.1 gives us the assertion of Theorem 2.
The next problem is to characterize Sheffer-sets of decomposition dependencies or of the corresponding join dependencies.
A characterization of Sheffer-sets of binary join dependencies can be given for full hierarchical dependencies using results on
hierarchical dependencies [?].
Theorem 3 [Tha85] Let K be a set of full hierarchical dependencies, i.e., a set of join dependencies with the property Xi ∩Xj =
Xi ∩ Xk , 1 ≤ i ≤ m, 1 ≤ j ≤ k ≤ m, i 6= j, i 6= k for (X1 , ..., Xm ) ∈ K.
K is a Sheffer-set iff for any (X1 , ..., Xk ) ∈ K
the property K |= (X1 , ..., Xi−1 , Y, Xi+1 , ..., Xk ) implies that
K |= (X1 , ..., Xi−1 , Xi ∩ Y, Xi+1 , ..., Xk ).
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
220
2.6 HERM Normal Form of Relational Database Schemata
Relational schemata can be directly retranslated to HERM schemata under certain conditions. In order to express this we introduce the HERM normal form of relational schemata, which generalizes and modifies the ER normal form discussed in [MR92].
Let DB = (R1 , ..., Rm , Σ) be a schema of a relational database. The integrity constraints in Σ contain inclusion constraints.
In inclusion constraint S[X] ⊆ T [Y ] ‘enters’ T and ‘leaves’ S. Let S[X1 ] ⊆ T1 [Y1 ], S[X2 ] ⊆ T2 [Y2 ], ..., S[Xm ] ⊆ Tm [Ym ]
be the set of inclusion constraints leaving S which are implied by Σ. Furthermore, let S1 [X1 ] ⊆ T [Z1 ], S2 [X2 ] ⊆ T [Z2 ], ...,
Sm [Xk ] ⊆ T [Zk ] be the set of inclusion constraints entering T which are implied by Σ. Then we define
Sk
enterC (T ) = S i=1 Zi , enterT (T ) = {S1 , ..., Sk },
m
leaveC (S) = i=1 Xi , leaveT (S) = {T1 , ..., Tk }.
Inclusion constraints can be pairing constraints, i.e., S[X] ⊆ T [Y ] and S[X] ⊇ T [Y ] are both valid. We can now layer the
relation schemata:
• A relation schema R is of depth 0 if it satisfies the following conditions:
• R has no entering inclusion constraints which are not paired.
• R has at least one leaving inclusion constraint. The left hand sides of leaving inclusion dependencies are pair-wise
disjoint.
• The components used for leaving inclusion constraints leaveC (R) form a key of R.
• A relation schema R is of depth i if it satisfies the following conditions:
• R has no entering unpaired inclusion constraints from schemata which are of depth less than i.
• R has a leaving inclusion constraint to a type of depth i − 1. R has no entering or leaving inclusion constraints to
or from schemata of depth i.
• The left hand sides of leaving inclusion dependencies are pairwise disjoint and the components used for leaving
inclusion constraints leaveC (R) form a key of R.
The relational database schema DB is in HERM normal form if it can be layered, all relation schemata are in BCNF with
respect to the functional and inclusion dependencies implied by Σ, the inclusion constraints are key-based and the set of inclusion
constraints is acyclic according to the layers.
The key condition can be weakened. In this case we obtain extended HERM schemata whose relationship types have keys
consisting of their components and attributes.
Proposition 4 Let DB be a relational database schema. There exists a HERM schema R such that DB is a maximal schema
included into R if and only if DB is in HERM normal form. If none of the relational schemata has pairing inclusion constraints
with a schema of the same depth then DB is equivalent to R.
The proof is completely similar to the proof given in [MR92]. It is somewhat involved but the construction behind the proof
is rather straightforward. If only one maximal relational database schema DB exists for a HERM schema R then the schema
DB is equivalent to the schema R. The existence of several maximal database schemata for a HERM schema is caused by
the loss of semantics during translation. Pairing inclusion constraints cannot be resolved after translation. Subtyping is not
expressible in relational database languages. For instance, in SQL we use referential integrity in order to express key-based
inclusion dependencies.
We use the layering in order to derive a HERM pre-schema. The types S, T which are on the same layer with S ∈ enterT (T )
and S ∈ leave(T ) can be in any order. They are of the same depth but of different order. The solution should take into account
the application.
Let us consider the following example:
Person = ({ PID, Name }, {{ PID → Name }}),
MarriedPerson = ({ PID }, { key = { PID }}),
Spouse = ({ PID, WithPID, Since }, { key = { PID, WithPID }),
Σ = { MarriedPerson[PID] ⊆ Spouse[PID] ,
MarriedPerson[WithPID] ⊆ Spouse[PID],
MarriedPerson[PID] ⊇ Spouse[PID] ,
MarriedPerson[WithPID] ⊇ Spouse[PID],
MarriedPerson[PID] ⊇ Person[PID] }.
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
221
The schema (Person, MarriedPerson, Spouse, Σ) can be layered as follows:
Person is of depth 0.
MarriedPerson is of depth 1.
Spouse is of depth 2.
The corresponding HERM schema consists of the types:
Spouse = (MarriedPerson, With : MarriedPerson, { Since }),
MarriedPerson = (Person, ∅),
Person = ({ PID, Name }, {{ PID → Name }}).
The resolution is unique for depth. However there might be cases for which this resolution does not exist. Thus we must
decide which resolution is the correct one.
Let us consider the relational database schema
Person = ({ PID, Name }, {{ PID → Name }}),
Player = ({ PID }, { key = { PID }}),
Inhabitant = ({ PID }, { key = { PID }}),
Rents = ({ PID, FID }, { key = { PID }}),
Flat = ({ FID, Address }, { key = { PID }}),
Σ = { Person[PID] ⊆ Player[PID] , Player[PID] ⊆ Person[PID],
Person[PID] ⊆ Inhabitant[PID] , Inhabitant[PID] ⊆ Person[PID],
Rents[FID] ⊇ Flat[FID] , Flat[FID] ⊇ Rents[FID],
Rents[PID] ⊇ Inhabitant[FID] }.
Then we derive that Rents is of depth 0, Flat of depth 1, Inhabitant, Player and Person are of depth 1. Which schema should
be represented by which HERM type depends on the resolution. The following HERM schema seems to be the natural one:
Person = ({ PID, Name }, {{ PID → Name }}),
Player = (Person, ∅),
Inhabitant = (Person, ∅),
Rents = (Inhabitant, Flat, ∅),
Flat = ({ FID, Address }, { key = { PID }}).
If the schema Person is absent then the following two HERM schemata are candidates:
Solution A: Player = ({ PID }, { key = { PID }}),
Inhabitant = (Player, ∅),
Rents = (Inhabitant, Flat, ∅),
Flat = ({ FID, Address }, { key = { PID }}).
Solution B: Inhabitant = ({ PID }, { key = { PID }}),
Player = (Inhabitant, ∅),
Rents = (Inhabitant, Flat, ∅),
Flat = ({ FID, Address }, { key = { PID }}).
The same problem arises regarding cluster inclusion constraints. In the relational database model generalization and specialization cannot be distinguished. This applies to HERM but not to ER model. If the relational schema contains the class
constraints
Person ⊆ Student + Professor,
Student ⊆ Person, Professor ⊆ Person
then the corresponding HERM schema has either the type Person as a generalization of Professor and Student or the types
Professor and Student are a specialization (e.g. roles) of Person.
Schema A displayed in Figure ?? has path constraints on components of the type flies
flies : { Flight.#, GateSchedule.Time.Day } −→ { Pilot.# }
and
flies : { Flight.#, GateSchedule.Time.Day } −→
{ GateSchedule.Gate.# } .
The schema is translated into a relational database schema. The two relationship types are merged into one type flies. We omit
the relational schemata which have only one attribute and use attribute name, truncating in the case of uniqueness. Further, the
equality constraint on Hour is used for attribute truncation.
Flight = ({ Flight.#, Destination, Hour },
and
{ { Flight.# } −→ { Destination, Hour }})
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
222
flies = ({ Flight.#, Pilot.#, Day, Hour, Gate.# },
{ { Day, Hour, Gate.# } −→ { Flight.#, Pilot.# },
{ Flight.#, Day } −→ { Pilot.# },
{ Flight.#, Day } −→ { Gate.# } } ).
Furthermore, the following inclusion constraints are generated:
{ flies[Flight.#, Hour] ⊆⊇ Flight[Flight.#, Hour] }.
The relational database schema is not in BCNF but in third normal form. It cannot be decomposed although transitive functional
dependencies exist.
A similar observation can be made for solution B in Figure ??.
Solutions C and D, presented in Figure ??, did not lose any of the functional dependencies. However, they are translated into
relational database schemata which have inclusion constraints that are key-based but not key-based with a minimal key. For
instance, we obtain the inclusion constraints
{ GateSchedule[Flight.#, Day, Hour] ⊆⊇
PilotSchedule[Flight.#, Day, Hour] }
for solution C. These inclusion constraints use the key
{ Flight.#, Day, Hour }
which is not minimal due to the functional dependency
{ Flight.# } −→ { Hour }.
Solution E, presented in Figure ??, does not have a translation into relational database schemata which are in BCNF. However, the direct translation generates a relational database schema which is in the domain/key normal form (DKNF) [Fag81].
A relational database schema is in DKNF if all constraints are a consequence of key dependencies and domain dependencies.
The DKNF is considered to be the ultimate normal form and can be easily maintained. An algorithm that will always create the
DKNF solution given a set of constraints is not yet known. Although the relational database schema is not in BCNF all functional
dependencies are maintained at least in one of the relational schemata. There might exist functional dependencies in a schema
which are not key-based. An example is the dependency
Schedule : { Flight } −→ { Hour }.
This dependency is maintained in the relational database schemata through the constraints:
Schedule [Flight Hour] ⊆ FlightAt [Flight Hour],
FlightAt : { Flight } −→ { Hour }.
The pullback rule for systems of functional and inclusion dependencies allows the derivation of
Schedule : { Flight } −→ { Hour }
from the given two constraints.
Based on Propositions 4 and ??, we can derive, however, the following corollary which shows that the DKNF can be generated directly on the basis of HERM schemata. We extend the DKNF notion slightly to the notion of the β-NF:
A relational database schema is in β-NF if all constraints can be expressed on the basis of domain dependencies, key dependencies, key-based inclusion dependencies and key-based exclusion dependencies.
A HERM schema is in β-NF if all constraints used for the definition of the schema are:
• Cardinality constraints, which use cardinality restrictions (0, 1), (0, .),
(1, 1), (1, .).
• General cardinality constraints comp(R, e), which use cardinality restrictions
(0, 1), (0, .), (1, 1), (1, .) and have expressions e which are projection expressions that are key-based, i.e., for any component e∗ of e and the projection expression e∗ = p.R0 [e0 ] components e00 of R0 which are disjoint from e0 , the general
cardinality constraint comp(R, e00 ) = (0, 1) is implied by the constraints of the schema.
• Class exclusion dependencies, i.e., exclusion constraints dependencies which are defined on key components of the types
used for the definition.
• Functional dependencies defined on local types. The local types are in BCNF according to their local functional dependencies.
An example of a schema which is in β-NF is displayed in Figure ??. The constraints
comp(Schedule, Pilot Day At[Hour] ) = (0,1)
comp(Schedule, Gate Day At[Hour] ) = (0,1)
are key-based because the type at consists of two components and obeys the cardinality constraint
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
223
comp(at, Flight) = (1,1).
We observe that the corresponding translated relational database schema is in β-NF.
A schema which is in β-NF is in strong β-NF if no exclusion constraints are used.
Corollary 8 Any HERM schema in (strong) β-NF can be translated to an equivalent relational database schema in (strong)
β-NF.
Restructuring of HERM schemata in order to obtain a β-NF is still an open problem. A complete solution cannot exist due to
the non-axiomatizability of the class of functional and inclusion dependencies. However, we can use graph grammar rules such
as the rules discussed in the next chapter for the presentation of restructuring rules. An example is the restructuring rules used in
[MR92] for the generation of HERM normal form schemata. Suppose we are given a functional dependency R : X → Y on a
type R consisting of disjoint component sets X, Y, Z and inclusion dependencies P [V ] ⊆ R[W ] or R[W ] ⊆ S[V ] entering
or leaving R.
For the case of the first inclusion dependency three cases arise when R is to be decomposed into R1 and R2 according to the
functional dependency:
• If W ⊆ XY then the inclusion dependency is inherited by the first type R1 .
If W ⊆ XZ then the inclusion dependency is inherited by the second type R2 .
• If W ∩ Y 6= ∅ and W ∩ Z 6= ∅ and W 6= X ∪ Y ∪ Z then a new type T on W is created and the inclusion dependency
is replaced by P [V ] ⊆ T [W ] , T [W u XY ] ⊆ R1 [W u XY ] and T [W u XZ] ⊆ R2 [W u XZ] where W u XY are
those components which correspond to W ∩ XY and maintain the order.
• If W ∩ Y 6= ∅ and W ∩ Z 6= ∅ and W = X ∪ Y ∪ Z then the inclusion dependency is replaced by P [V u XY ] ⊆
R1 [W u XY ] and P [V u XZ] ⊆ R2 [W u X] .
For the case of the second inclusion dependency three cases arise similar to the case above:
• If W ⊆ XY then the inclusion dependency is inherited by the first type R1 .
If W ⊆ XZ then the inclusion dependency is inherited by the second type R2 .
• If W ∩ Y 6= ∅ and W ∩ Z 6= ∅ and W 6= X ∪ Y ∪ Z then a new type T on W is created and the inclusion dependency
is replaced by T [W ] ⊆ S[V ] , T [W u XY ] ⊇ R1 [W u XY ] and T [W u XZ] ⊇ R2 [W u XZ] .
• If W u Y 6= ∅ and W u Z 6= ∅ and W = X ∪ Y ∪ Z then the inclusion dependency is replaced by S[V u XY ] ⊇
R1 [W u XY ] and S[V u XZ] ⊇ R2 [W u XZ] .
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
224
2.6.1 Vertical Normalization Revisited
BCNF cannot be achieved in any case for a given type and a given set of functional dependencies. 3NF can be achieved in any
case. However, the negative statement on BCNF normalization is not true if splitting of attributes is allowed. Let us consider the
approach proposed by [MR98].
In the literature the following type is often discussed which does not allow a dependency preserving decomposition into a
BCNF:
Address = ({ City, Street, ZIP } ,
{{ City, Street} −→ { ZIP },
{ ZIP} −→ { City }} ) .
It is however reasonable to assume that the zip code can be decomposed into two parts:
A segment representing the city code CityZIP
and
a segment for the neighborhood code NeighbZIP.
Now the type Address allows a representation by the type
Address’ = ({ City, Street, CityZIP, NeighbZIP } ,
{{ City, Street} −→ { NeighbZIP },
{ City } −→ { CityZIP }
{ CityZIP } −→ { City }} ) .
This type can be decomposed into two types:
Address1 = ({ City, CityZIP } ,
{{ City } −→ { CityZIP } ,
{ CityZIP } −→ { City }} )
and
Address2 = ({ City, Street, NeighbZIP } ,
{{ City, Street} −→ { NeighbZIP }} ) .
From the structural point of view the type Address is similar to the following example:
Schedule = ({ Lecturer, Hour, Course } ,
{ Lecturer, Hour } −→ { Course },
{{ Course } −→ { Lecturer }} ) .
Practical considerations differ considerably. A splitting does not exist per se for Course. However, if courses are split into classes and a lecturer is responsible for one class then a similar decomposition exists. In this case we split the attribute Course to
Course(Field,No). The following functional dependencies are derived for the schema after the split:
{ Lecturer, Hour } −→ { Course.No },
{ Course.Field } ←→ { Lecturer } .
The following set is equivalent to the new set:
{ Lecturer, Hour } −→ { Course.No },
{ Course.Field } ←→ { Lecturer } .
The new dependencies define meaningful units. Thus, the schema
Lecturer = ({ Name, Course.Field } ,
{{ Course.Field } ←→ { Name }} ) ,
CourseSlot = ({ Hour, } , Key = {Hour } ) ,
Assignment = ( Lecturer, CourseSlot , { Course.No } )
comp(Assignment, Lecturer) = (1,n),
comp(Assignment, CourseSlot) = (1,n)
is a natural reification of the first schema.
Splitting of attributes or components cannot always be done if a natural interpretation of the split is required. In this case, artificial splitting can be an appropriate strategy.
The following example shows that splitting may increase the size and the complexity of the schema.
R = ( { A, B, C, D, E, F, G, H, I },
{{ A, B } −→ { C, D } , { C, D } −→ { E, F } ,
{ E } −→ { G } , { F } −→ { H } ,
{ H, I } −→ { B } , { G, I } −→ { A }} ) .
The type R is in 3NF and has 10 minimal keys:
{ A,B,I }, { A,H,I }, { G,B,I },{ G,H,I },{ C,D,I },{ G,D,I },
{ C,H,I },{ E,F,I },{ G,F,I },{ E,H,I } .
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
225
All attributes are key attributes. For this reason, none of the conditions for 2NF or 3NF fails. However, the structure of the
functional dependencies is highly circular. We can split the attributes G, H, I . Since I is used in two dependencies it is split to
I1 , I2 , I3 , I4 (in dependence whether or not it interacts with G and H, i.e., I1 with both G and H, I2 with G only, I3 with H only
and I4 with none of them). The attributes H and G are split to H1 , H2 , G1 , G2 . After the split we obtain the type
R∗ = ( { A, B, C, D, E, F, G1 , G2 , H1 , H2 , I1 , I2 , I3 , I4 } ,
{{ A, B } −→ { C, D } , { C, D } −→ { E, F } ,
{ E } −→ { G2 } , { F } −→ { H2 } , { H1 , I1 , I3 } ←→ { B } ,
{ G1 , I1 , I2 } ←→ { A }} ) .
The type R∗ can be decomposed according to the last two dependencies to the type R1 , R2 cutting out G1 , H1 , I1 , I2 , I3 using A
and B. The remaining type is
R∗0 = ( { A, B, C, D, E, F, G2 , H2 , I4 },
{{ A, B } −→ { C, D } , { C, D } −→ { E, F } ,
{ E } −→ { G2 } , { F } −→ { H2 }} ) .
Since the unique key of the type is { A, B, I4 } and transitive dependencies form a tree the type can be decomposed to types on
the basis of the decomposition approach to the types:
R∗1 = ( { A, B, C, D }, {{ A, B } −→ { C, D }} ),
R∗2 = ( { C, D, E, F }, {{ C, D } −→ { E, F }} ) ,
R∗3 = ( { E, G2 }, {{ E } −→ { G2 }} ) ,
R∗4 = ( { F, H2 , }, {{ F } −→ { H2 }} ) .
Furthermore, since none of the obtained types contains a key of R we add the type
R∗∗ = ( { A, B, I1 , I2 , I3 , I4 } , Key = { A, B, I1 , I2 , I3 , I4 }) .
The schema consisting of the types R1 , R2 , R∗1 , R∗2 , R∗3 , R∗4 , R∗∗ forms a snowflake. All types are in BCNF.
The last example demonstrates that artificial splitting may increase the number of types.
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
226
2.7 Ausgewählte Muster von Referenzschemata
2.7.1 Werte, Beobachtungen und Messungen
The assignment of values is often not as simple as stated. Quantities must be given together with their units of measure. The
placement of quantity properties either as attribute type or as relationship type depends mainly on the usage of the property either
as characterisation or as associating property. Additionally, reuse of the same kind of representation may lead to an introduction
of a separate entity type.
Beside the assignment of values we also need to consider the conversion of units. The schema in Figure 37 shows one
possible generic representation that might be used a the general units conversion dimension.
to
¾
from
¾
Unit
Conversion
factor
-
Number
Abbildung 37: Conversion of units of measure
If many units must be converted then the physical dimension comes into play. Also, international standards such as S.I.
standards must then be considered.
Often conversion factors are dynamic, e.g. exchange rates.
Units of measure are often complex units, e.g. consumption. If we need a direct representation we might use the schema in
Figure 38.
Unit
¾
Atomar
unit
(0,1)
¾
¾
Negative
-
Positive
-
Complex
unit
(0,n)
Abbildung 38: Direct representation of complex units
Measurement and observations are typically based on a separation into the knowledge level and the activity of observing or
measuring. So we might record this activity directly as displayed in Figure 39.
Type of
phenomenon
6
Knowledge/strategic level
Temporal/tactical level
Person
¾
Measurement
-
Quantity
Abbildung 39: Activity of measuring
This picture might be more complex if we consider that measurements and most observations are subjective.
We explicitly introduce Observations in Figure 40.
Additionally, observations may be co-related (see, for instance, Figure 41).
Also, we might have to distinguish between the type of phenomenon and the phenomenon itself. So Figure 40 becomes
extended to Figure 42
The phenomenon might be bundled by a concept of perception. The information whether we perceive a category or not will
also have to recorded for certain purposes. So, we need to capture that in Figure 43. At the same time, observations might be
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
227
Type of
phenomenon
6
Person
¾
Observation
Measurement
µ
L
-
Perception
-
Quantity
-
Category
-
Quantity
-
Category
Abbildung 40: Activity of observing
¾Judgement
Observation ¾
Co-relation
Hint
Abbildung 41: Recursive relationships to for observations
¾
Phenomenon
Type of
phenomenon
6
Person
¾
Observation
Measurement
µ
L
-
Perception
Abbildung 42: Activity of measuring, observing and perceiving
IS ADD
K
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
228
classified as wrong, erroneous or rejected. Also, we might want to distinguish which type of observation is made: hypothesis,
projection, or active observation.
Type of
phenomenon
¾
6
Person
¾
L
Observation
- Concept of
perception
1
Perception ¾
k
µ
- Measurement
Negative
perception
Positive
perception
6
Active
observation
Hypothesis
Phenomenon
s
-
Type of
observation
ª
?
Rejected
observation
Quantity
3
Projection
Abbildung 43: Activity of measuring, observing and perceiving
Finally, the association of observations might be based on constructors for associating observations. So, the picture becomes
more complex and can be represented by a schema similar to the one in Figure 44.
Arguments
for selection
?
Association
function
R
-
Concept of
observation
6
Knowledge/strategic level
6
Temporal/tactical level
Associated
observation
6
-
Observation
µ
Hints
for selection
Abbildung 44: Associations and constructors for observations
Observation is still an overloaded concept. Additionally, we need to establish a recording or protocolling component with
the schema. We therefore extend the schema in Figure 43 to the schema in Figure 45. This schema omits some of the types of
the former schema
Measurement is typically based on the Factory-Method pattern. Measurement and to a certain extent observations are
based on data. So, the type Quantity is a complex type or a schema by themselves. We therefore should shuffle the state under
consideration into the schema in Figure 45.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
229
Comparison-based
measurement
method
Computed
measurement
protocol
- Computing À
¾
method
?
Protocol ¾
prototype
6
Causal
measurement
method
Type of
- phenomenon
Is For TypeOPr
]
Source
measurement
protocol
¾
6
- ObservationL
Protocol
?
Person
ª
?
Object under
observation
Phenomenon
- Concept of
perception
1
Perception
µ
*
- Measurement
-
R
R
Type of
observation
Quantity
Method of
measurement
Planning
Abbildung 45: Activity of measuring, observing and perceiving, protocolling and planning (without positive and
negative observations and perceptions)
Typically quantity is based on a a state. The explicit representation of state with different sub-states allows to apply the state
pattern to measurement processes. The state pattern allow an object to alter its behaviour when its internal state changes. Figure
46 displays the first schema draft for state representation.
The comparison operator is complex. Therefore, we shuffle the complex units schema displayed in Figure 38 into this
schema. Another shuffle schema to be incorporated into this schema is the schema for the representation of dates and moments.
2.7.2 Zeitmodellierung
Date is either based on the current calendar (for instance, finance year, study period) or on specific representation of time. Data
may be temporal and depend directly on one or more aspects of time. We distinguish three orthogonal concepts of time: temporal
data types such as instants, intervals or periods, kinds of time, and temporal statements such as current (now), sequenced (at each
instant of time) and non-sequenced (ignoring time). Kinds of time are: existence time, lifespan time, transaction time, change
time, user-defined time, validity time, and availability time. The first two kinds of time are not considered in databases since they
are integrated into modelling decisions. Temporal data are supported by specific temporal functions. These functions generalize
Allen’s time logic [All84].
2.7.3 Geometrie-Modelle
2.7.4 Interval-Modellierung
The representation of intervals is a typical task in most information systems applications. Figure 47 display a general injection
schema for interval representation.
This constructor is also applicable to the construction of complex observation types.
2.7.5 Geschichtete Modellierung
Responsibilities are typically based on the kind/type-of constructor. The schema in Figure 48 displays responsibilities in dependence on their kind and the association to parties. Organisations have a structure that is valid in certain time periods. It is
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
Comparison
operator
230
Duration
I
Date
6
*
µ
L
Observation
ª
6
- Measurement
-
State
¾
- State type
Real
state
]
Method of
measurement
-
Planned
state
?
R
R
Planning
Abbildung 46: Considering states for measurement
Object life
period
Boolean
¾Lower bound
included
¾Upper bound
included
?
Interval
Lowerbound
Upperbound
Abbildung 47: Representation of intervals
IS ADD
Value
type
Planning
of state
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
231
constructed depending on the structure type that has been chosen. This structure type is based on the regulations for construction.
Temporal
Fixed
Responsibility
type
¾
requested by
Responsibility
responsible
?
Party
?
Time
frame
Regulations
Abbildung 48: The assignment of responsibilities to parties
We notice again that such structures are typical for schemata that represent at the same time strategic information or knowledge and tactical information or data.
We can extend this pattern by associating the kinds upon which the types are based. For instance, the schema may be fold
for representation of actions or activities. At the same time, parties may be hierarchically structured.
Regulations
requested by
Responsibility
type
responsible
6
¾
Knowledge/strategic level
Party
type
6
Temporal/tactical level
-
for
?
Action
requested by
Responsibility
responsible
-
Party
(0,n)
(0,1)
?
Time
frame
Abbildung 49: The assignment of responsibilities to parties
The roles of responsibilities must be a specialisation of the roles of the corresponding responsibility type. A similar requirement may be enforced for the hierarchies.
Responsibilities may also be hierarchically structured and can be classified according to the type of hierarchy. We distinguish
between
layer-based responsibilities where the party can only be responsible for the party that is in the next lower layer and
hierarchical responsibilities that restrict the responsibility to the matching level of the parties.
The layer-based responsibility can be
general for a general responsibility of one party for an entire layer (represented by a unary relationship of responsibility for a
party) or
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
232
directed for a (binary) relationship between the parties.
Responsibilities may be shuffled with a logging facility that store the results of being responsible for the parties. Figure 50
displays one way of shuffling according to the constructor pattern of the previous subsection.
Quantity
schema
Protocolling
schema
Service
area
Product
kind
y
6
L
:
9
Service
kind
z
Resource
utilisation
-
Spatial
schema
6
Responsibility
¾
Service
Abbildung 50: Service record for responsibilities
Responsibilities may already by pre-assigned to parties. In this case we introduce another type: Position. This type may
either be generalised within the Party type or may be a unary relationship defined on Party.
2.8 Grenzen der Modellierung
2.8.1 Grenzen hierarchischer Modellierung
The higher-order entity-relationship model (HERM) [Tha00] extends the classical entity-relationship model by complex attributes (type), relationship types of higher order and cluster types. Relationship types may have only one component and represent
in this case a specialization of the its component. For instance, the relationship type Porsche in Figure 52 specializes the type
car. The type Car is a specialization of the type Product. Relationship types may have key components beyond the keys of
their components. For instance, the type Book has an additional key beyond the identification for products. It is required that any
type has a key. For this reason, the HERM schema requires that each type has either its key or a key that consists of keys from its
components and if necessary its additional key. Cluster types allow a representation of generalization hierarchies. For instance,
the Product type can be understood as a generalization of the types Car and Product. This opportunity is not represented
in our HERM schema.
Modeling typically allows to apply a number of approaches. The classical ER approach to modeling is given in the specialization schema in Figure 51. We have been choosing a compact schema that avoids Is-A relationship types and directly
uses specialization types. Extended ER modeling requires that any type has its identifying components. Identifiers may also be
attributes of the relationship type. Typically identification is inherited from components. It may however also replace identification, e.g. ISBN is the identification for the book type. Specialization may either be subtype specialization or property specialization (e.g. Porsche911GT8 for Porsche911) or both (e.g. Book for Product with value assignment for taxRate
and type specialization for the relationship type). Typically, (entity or relationship) classes are not singleton classes. The type
myPorsche911CarreraS defines a singleton class for this application.
Another representation of the same application is given in the overlay schema. This schema combines the car and book
category in the example within a schema that allows to consider the similarity of the types within the same diagram without
separating the categories into different diagrams. The model in Figure 52 uses optional attributes which may either be populated
or not. The population is constrained by null-value constraints of the following kind:
[author]0 binds the population of values for authors in the entity type Model to those models which category kind is B OOK.
[millage]0 binds the population of values for millage in the relationship type Entity to those physical entities which category
kind is C AR.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
233
maxSpeed=310km/h
maxSpeed
millage
serialNr desc
taxRate
¼
marketLaunch
Y
author
Book
listPrice
Hierarchie layer:
Product Catalog
listPrice
=91.838 serialNr=’C33333333’
myCopyOf
HarryPotter4
HarryPotter4 ¾
taxRate=15
Hierarchie layer:
Product Category
myPorsche911
CarreraS
Porsche911 ¾
CarreraS
maxSpeed
=293km/h
marketLaunch=1964
author=J.K. Rowling
¾
porsche911club=true
millage=100000
ª
Porsche911 ¾
¾
Car
Product
porsche911club
taxRate=20
listPrice=108.083
Porsche911GT3
listPrice=11.50
Hierarchie layer:
Product Brand
serialNr=’A121212’
Hierarchie layer:
Product Model
Hierarchie layer:
Product Physical Entity
Abbildung 51: Product catalog modeled with HERM specialisation types
[clubAccepted]0 binds the population of values for clubs in the relationship type Entity to those physical entities which
category kind is C AR and which brand allows club membership.
This binding is simple as long as paths have a uniqueness condition. For instance, models have at most one brand and one and
only one category. The overlay model assumes that brands and categories are orthogonal dimensions and that models have at
most one brand and have one and only one category.
ID
[marketLaunch]0
Brand
desc
ID
Catalog
¾
¾
ID
[listPrice]0
Brand
to
Model
(0,1)
Model
[club]0
[author]0
Catalog
to
Category
-
¾
Entity
6
[maxSpeed]0
(1,1)
Category
of
Model
-
[clubAccepted]0
[millage]0
serialNr
Category
taxRate
kind
ID
Abbildung 52: Product catalog modeled with HERM in the overlay modeling style
Another equivalent schema may make use of cluster types. The category type has two specialisations into Car and Book
subtypes. The general model properties bind these two subtypes into general model characterisations and use special types for
an association to specific model properties of each categories. This representation is based on horizontal decomposition of types.
This representation is therefore very similar to the m-object representation.
The schema in Figure 51 combines the object and the class model. The type myCopyOfHarryPotter represents a
singleton class consisting of one singleton book. Furthermore, the type Porsche911GT3 uses in the class name a description
of the objects in the corresponding class. If we use an overlay schema then this implicit description must be made explicit. The
attribute kind is therefore added to the entity type Category in Figure 52.
2.8.2 Fallen anderer Modelle: Identification
The representation of object and thing identities is one of the main source for errors in schemata. It is surprising that many
textbooks still follow the direct representation approach through object identities that are assigned by the system. Object identity
is rather a concept at the logical layer of database operating. This approach looks very convenient. The user does not have any
chance to interfere with the object identity generation.
The paper [BT99] (see also [ST98]) shows that object identification must either be given by (weak) value identification
[ST93] or will cause many computational problems. Otherwise a rather complex complex logical theory must be developed.
[Sch94] show that we need a higher-order intutionistic predicate logic. Since object-identity allows self reference the logic must
also be epistemic. The results of [BT99] and its preliminary versions e.g. [BT92], [BT95] have led the concept of object identity
constraints in [RK02]. The starting point for this theory have been the reports [Tha91b] and [AFT92].
Consider, for instance, the schemata in Figures 53 and 55.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
o1
234
s
o4
- o5
K
s0
?
s
o2
®
s0 *
1
s
s
s
s
Y
0
s s o3
a
°
N
- o6
s
s
N
- b
(a)
(b)
Abbildung 53: Identification in Object-Oriented Databases
The identification of the objects in Figure 54 can neither be based on structural properties nor on values. So, the user is lost
whenever an object must be accessed. The question how many object exist in the database may give a result of either 3 or 4.
Both are correct due to the limitations of represented knowledge about the objects.
s2
: o2
y
s3
6
s1 o1
s1 s1 s3
?
y s2 s3
y
z o3 9
s2
s2
z
z
o4 ¾
s1
s3
Abbildung 54: Objects which cannot be distinguished
One trick to represent object identification is to use a tree representation. The schema in Figure 55 displays a tree representation.
o1
s
¼
o2
s
o2
s0
?
! o3
j
1
s
¼
o3
s
s0
?
! o1
oj
o3
j
1
s
¼
o1
s
s0
?
! o2
j
s
¼
s
s0
?
j
1 oj+1 mod 3 !oj+2 mod 3 1
Abbildung 55: Trees of of depth 1 for o1 , o2 , o3
Extended entity-relationship models explicitly define two constructs which can be implicitly used in nested relational database models:
• Relationship types express the association among types. This association can be used for identification as well.
• The differentiation among types allows to distinguish concepts which are defined by a certain construction and concepts
which are using a certain construct. Thus, relationship types are based on entity types. Their identification mechanism is
based on the identification mechanism of component types.
Weak entity types, i.e. types whose identification is defined through associations, use the first extension. An entity type is defined
as nested relational type. Its semantics, however can be based on other types as well. Let as consider the example pictured in
figure 56.
We can use pathes for the identification. The dot is used for component declaration, i.e. moving downwards. The exclamation mark is used for moving upwards. For example, the attribute Number can be reached from Town using the path
Town!SInT.Street!HInS.House
and is denoted by
Town!SInT.Street!HInS.House.Number.
Thus we can use pathes for identification of objects and the extension of the notion of a key as well. In the example the key of
the type House is the set
{ House!HInS.Street!SInT.Town.Name, House!HInS.Street!SInT.Town.Area, House!HInS.Street.Name, Number } .
This identification mechanism can be displayed by trees or forests in the general case.
IS ADD
CAU zu Kiel, IfI, ISE, β
House
2. Strukturierung von IS
(1,1)
¾
-
HInS
ab SS 2012
Street
235
(1,1)
¾
-
SInT
Name
Number
Town
Name Area
Abbildung 56: Address defined by weak entity types
(1,m)
¾
Multiset
MNumber
-
HasMember
Element
OccurNr
Value
Abbildung 57: Complex Identification through Relationship Types
There can be defined other identification mechanisms. The second new construct of entity-relationship databases extends
the identification concept as well. Let us consider the example in figure 57.
Multisets are identical if they have the same elements with the same occurrence number.
This condition can be expressed by generalizing the notion of key dependencies. A key dependency is a functional dependency
s −→ R
for a substructure s of R.
This dependency can be expressed also by a first-order predicate formula
R0
R
∀v, v 0 (PR (v) ∧ PR (v 0 ) ∧ v = v 0 −→ v = v )
.
In the relational model at the external level keys are used to represent identification and existence. This idea directs to another
formula which is equivalent to the above key constraint:
∀v1 |R00 , v2 |R00 ( ∀v |R0 ( PR (v |R0 1 v1 |R00 ) ←→ PR (v |R0 1 v1 |R00 ) )
where R00 is the “difference” of R and R0 .
−→
R00
v1 = v2 )
Based on this re-definition we express now the key constraints for multisets by the formula
∀m, m0 ( ( ∀e, o ( PHasM ember (m, e, o) ←→ PHasM ember (m0 , e, o) ) −→ m = m0 )
.
Notice that this notion is the indiscernability relation introduced by Leibniz [Lei60].
Integrity constraints can be used for identifiability as well. They can impose distinguishability or indistinguishability of
objects.
one-author-book
Samuel Clemens ¾
Mark Twain
¾
name
name
6
o2
o1
- Huckleberry Finn
j
o3
brother
6
brother
?
o4
Abbildung 58: Integrity constraints influence identifiability
Let us consider the objects in Figure 58.
It is known that the relation ‘brother’ is irreflexive. For this reason we find that o3 6= o4 although there is no possibility
to identify one of the objects. Thus, distinguishability of objects is weaker than identifiability of objects. It can be possible to
distinguish objects which cannot be identified. If objects are identifiable then the objects can be distinguished.
From the other side, since the book Huckleberry Finn was written by one author the objects o1 and o2 can be identified.
The identification concept is based in these cases on integrity constraints. We consider different classes of integrity constraints and the treatment of identification based on our concepts. We use the relational notation since this notation can be easily
extended to other models.
• Equality generating dependencies are constraints of the following form:
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
236
∀(x1,1 , ..., xm,n )
(PR (x1,1 , ..., x1,n ) ∧ ... ∧ PR (xm,1 , ..., xm,n ) ∧ F (x1,1 , ..., xm,n ) →
G(x1,1 , ..., xm,n ))
where F (x1,1 , ..., xm,n ), G(x1,1 , ..., xm,n ) are conjunctions of equalities of the form xi,j = xi0 ,j 0 and P is the predicate
symbol associated with R.
Based on the transformation of the constraint to the equivalent formula
∀(x1,1 , ..., xm,n )
(PR (x1,1 , ..., x1,n ) ∧ ... ∧ PR (xm,1 , ..., xm,n ) ∧ ¬G(x1,1 , ..., xm,n ) →
¬F (x1,1 , ..., xm,n ))
we can use the inequality set IE in order to extend the deductive system DVIE . Thus, we can express the identification
properties on the basis of value-distinguishabability or equational logic in the case of equality generating dependencies.
Identification extended by equality-generating dependencies can be expressed by V-identifiability.
Notice, that functional dependencies and generalized functional dependencies are special equality generating dependencies.
• An exclusion dependency is an expression of the form
R[R.A1 , ...., R.An ] k S[S.B1 , ..., S.Bn ] .
The property specified by the exclusion dependency can be directly translated to inequalities among objects.
A generalized inclusion dependency is an expression of the form
R1 [X1 ] ∩ ... ∩ Rn [Xn ] ⊆ S1 [Y1 ] ∪ ... ∪ Sm [Ym ]
for compatible sequences Xi , Yj .
Similarily to equality-generating dependencies, generalized inclusion dependencies can be transformed to negated formulas. These formulas are the basis for the extension of the deductive system DVIE .
Identification extended by generalized inclusion dependencies and exclusion dependencies can be expressed by V-identifiability.
• Disjunctive existence constraints X ⇒ Y1 , Y2 , ..., Yn specify that if a tuple is completely defined on X then it is completely defined on Yi for some i. There is an axiomatization for disjunctive existence constraints. They can be represented
by monotone Boolean functions.
Since the existence has been treated explicitly in the definition of value-identifiability we conclude directly:
Identification extended by existence dependencies can be expressed by V-identifiability.
V-identifiability and E-identifiability are equivalent for generalized inclusion, exclusion, existence and equality-generating dependencies.
These results extend the results of [KR97] where functional dependencies, special cases of inclusion and exclusion constraints have been considered and which summarized the results in [Tha91b], [BT92] and [BT95].
Constraints can be easily used for value identification. We can use constraints also for extending the identification on the basis of
queries. However this extension has to be changed whenever the inequality set is changed. Thus, integrity constraints cannot be
incorporated into the computation of identifying queries. The same argument is valid for homomorphisms and automorphisms.
Thus, the use of integrity constraints leads to another hierarchy in our identification mechanisms.
It is possible to characterize an object without denoting it. For this purpose, queries or formulas can be used. Examples of
such identifying formulas are:
1. the current queen of England,
2. the current king of France,
3. the mother (father) of x,
4. the x for which it is valid x + y = z ,
5. the x for which it is valid x2 = y ,
6. the largest prime number,
7. the x for which for all y it is valid that x + y = y .
The first characterization identifies an entity. The second characterization is partial. The third characterization identify an object
since we know that the relation is functional. The object x can be taken as a parameter. The fourth characterization uses two
parameters. This characterization can be partial. The case 6 shows that the characterization depends on existence of objects. The
last characterization identifies one object based on the properties of the function +.
Characterization can be based on formulas α(x, y1 , ..., yn ) which depend on x and on n parameters y1 , ..., yn .
The formula is a characterization formula if ∃ ! x α(x) or resp. ∀y1 ∀yn ∃ ! x α(x, y1 , ..., yn ) is valid where by ∃ ! x we
denote the unique existence of x. The characterization formula α is called essential if n = 0 and non-essential otherwise.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
237
Whether such characterizations can be used depends on the provability of unique existence of such objects and on the
properties of the used logical language. We notice that a special cases of unique existence are equality generating dependencies
and functional dependencies.
If we use integrity constraints then identification may depend also on axiomatizability of constraints defined for the database.
Since there are classes of constraints which are not axiomatizable, identification may be not computable. For example, equalitygenerating dependencies and inclusion dependencies are not finitely axiomatizable.
Names as identification.
Many languages explicitly use names for identification of objects. Often names are confused with the thing they denote. The
name “Stuttgart” may refer to very different objects such as the city of Stuttgart, the entry point traffic sign for Stuttgart. Names
may denote references, e.g. the word “Karajan” may denote a piece of music as well as a person. L.J.J. Wittgenstein [Wit58]
uses the ‘language games’ instead of the mapping from names to denotations. In general this notion is based on the mapping
from names to denotations that is additionally dependent on the utilisation context, culture and the user. If we use a name 16GL
for a car then we are denoting some of the properties of the car, i.e. the motor and the comfort. The mapping may be a referential
one. This ‘label usage’ may cause a number of confusions. It is only useful if the meaning can be uniquely deducted.
The meaning of a word is typically however context-dependent. It depends on the act of denoting. This act of denoting should
be embedded into the complete situation (language life form). The meaning requires uniqueness or clarity of the interpretation.
It typically requires preliminary knowledge and a well-assigned context. Naming is therefore related to the function units,
especially the use in dependence of the function. Word denote things. Denotation is an activity. The meaning of a word is the
set of denoted things under consideration.
A name must have at least the three properties:
• It must reliable assign the notion to the thing under consideration.
• The reference must be stable.
• The reference is invertible.
The assignment of a name may be based on a name space. Sometime we use additionally an identification schema or a coding
for the names. The identification schema may be implicit or explicit.
Object ¾
appearance
Identification
schema
appearance
alias
former usage
6
Object
equivalence
-
?
Object
-
¾
Name
++
-
Name
space
Abbildung 59: The explicit representation of names
Amalgamation of identification.
Object have their own history. They may be copied, replaced, updated and deleted. If we are interested in maintaining the
original object whenever the object obtains new properties then we need either an explicit representation of the history of objects
or an explicit replacement mechanism. The simplest replacement mechanism is the introduction of aliasing schemata. The most
rigid replacement schema is the liquidation of the older identification. We might also use the data type Alias or Former usage in
Figure 59 that explicitly stores all name changes.
The same problem appears if we can observe the same thing in various beings and appearances. Observations are typically
made by people who might classify the same thing in a different way. Therefore we can additionally introduce the appearance into
the schema. This appearance notion is based on the sponsor-selector pattern that separates the three fundamentally different
responsibilities: recommending a resource, selecting among resources, and using a resource.
Furthermore, objects observed may be equivalent to each other based on a notion of equivalence. This notion should be
stored whenever complex evaluations are going to be made. The equivalence schema is important for almost all aggregations
if we are interested in well-founded statistics. We can use the mediator pattern for an explicit annotation of the equivalence
notion.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
238
2.8.3 The Classical ER Modelling Language is Incomplete
Lakoff introduces six basic schemata of cognitive semantics without stating that this list of schemata is complete.
• The container schema define the distinction between in and out. They have an interior, a boundary and an exterior.
• The part-whole schema define an internal structuring and uses whole, part and configuration as construction units.
• The link schema connects thing of interest. It uses various kinds of links for associating or un-associating things.
• The center-periphery schema is based on some notion of a center. Peripherical elements are not as important than those
in the center.
• The source-path-goal schema uses source (or starting point), destination, path, and direction. It allows also to discuss
main and side tracks.
• Typical ordering schemata are the up-down, front-back and the linear ordering schema. They use spatial and temporal
associations.
We call a modelling language cognition-complete if these six schemata can be represented.
The classical ER modelling language suffers from a number of restrictions. It uses the container and the link schemata. It
allows to mimic the part-whole schema via special links (called IsA). This work-around is however badly misunderstood. In order
to become cognition-complete integrity constraints must be used. Their cognitive complexity is however beyond surveyability
of humans. A typical flaw of the classical ER model is the use of monster types that integrate stabile - almost not changing properties and transient - often changing - properties. Objects are then taken as a whole. Unary relationship types easily resolve
this problem if higher-order types are permitted.
Extended ER modelling languages are however also not cognitive complete. The center-periphery schema can only be emulated. The source-path-goal schema can be represented by higher-order relationship types. The part-whole schema is supported
by the specialisation via unary relationship types and by generalisation via cluster types. Ordering schemata can be defined using
the order types and bulk types.
2.9 Conceptual Modelling in the Large
see ER 2010 tutorial
IS ADD
CAU zu Kiel, IfI, ISE, β
Code
2. Strukturierung von IS
ab SS 2012
239
Description
Dimension
Type
6
ID
Dimension
OfType
-
Dimension
K
Brand
Name
Other
Characteristic
Color
6
¸
I
Product
Type
Product
Quality
Product ¼
Characteristic
y
may be
converted in
Converted
6
Conversion
Factor
[Reason]
Product
Obsolesence
R
AReplacementNeededFor
SuperceededBy
FromDate
Product
ThruDate
[Quantity] Substitute
UsedAs
By
[Comment]
j
-
¾
Id
Identification
TypeCode
Description
PhysicalInventoryDate
Item
Variant
Reason
Item
Shrinkage
Overages
R
Id
Party
Address
?
Product
[ThruDate]
6
=9
From
PrefTypeCode
Item
¾
Producer
Of
zation
Name
?
FromDate
[ThruDate]
¾
Market
Interest
Comment
Description
SerialNumber
QuantityOnHand
Id
?
Party
Type
Service
StorageFor
Id
¾
6
Product
Category
6
PhysicalOccurenceOf
Container
Description
^
- Organi-
FromDate
[ThruDate]
[Comment]
PrimaryFlag
Finished
Good
[ReorderQuantity]
[ReorderLevel]
Item
L
Code
- Container
Type
Code
Product
Supplier
Preference
Prod
Category
Class
Raw
Material
Description
Abbildung 60: Pattern for Products
IS ADD
Description
Product
Supplier
- RatingType
R °
ª
?
¾
Cost
RatingTypeCode
Costed
By
Product
[Comment]
Supplier
AvailableTruDate
FromDate
WorkIn
Progress
- Inventory
)
Estimated
FromDate
Product
Cost [ThruDate]
R
6
WarehousedAt
[Comment]
[ThruDate]
[Percent]
Code
Quantity
: Boundary
OptionalComponent
µ
Name
DependentOn
Product
Characterized
MadeUpOf ProdCode
Name
[Comment]
[Instruction]
[IntroductionDate]
[SalesDiscontinuationDate]
Consists
[Comment]
[SupportDiscontinuationDate] [ManufSuggestRetailPrice]
Of
[QuantityUsed]
UsedIn
ThruDate
Type
Geographic
Location
UsedToDefine
Priced
By
Description
GeoAreaCode
Supplier
jR
FromDate
Additional Identifier
(ManifacturerID |
StockKeepingUnit |
UniversalProductCode
(American UPCA | European UPCE) |
IntStandBookNumb ISBN))
Additional
Item
Identification
>
Purchaser
Of
[Price]
Price
Component
FromDate
Surcharge
Component
Description
Party
Type
Description
[Comment]
Specified
For
Code
¸
U
^ Product
º
L
6
Discount
Level
PriceSequenceNum
¾
Price
Component
Type
Used To
Define
Discount
Component
y
UOM
UnitOf
Measure
[ThruQuantity]
PartyTypeCode
?
Quantity
Break
Base
Product
Price
k
CompTypeCode
FromQuantity
Description
[TaxIdNum]
UsedTo
Define
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
240
2.10 Transformation von Schemata in andere Modelle
Man kann für die Übersetzung zwei verschiedene Zugänge unterscheiden:
Interpretation: Typen des Ausgangschemas werden in einer bestimmten Reihenfolge in Konstrukte der Zielsprache überführt.
Compilierung: Eine Transformation kann zu Schemata führen, die ein ungünstiges Verhalten haben. Deshalb wird oft von
einem Entwerfer erwartet, daß er nach einer Übersetzung das Zielschema ‘glättet’. Ein Compilierungszugang dagegen4
berücksichtigt Eigenschaften der Zielsprache bei der Übersetzung mit. Übersetzer kö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 können bereits in diesem Schritt angewandt werden. Da wir uns hier jedoch vollstä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 Verständnis der folgenden Schritte. Erst im letzten Schritt wenden wir
eine Transformation an. Dadurch wird gesichert, daß sich der Entwerfer nur mit einem Modell beschäftigen muß. Er kann die
Transformation am Ende als vollständig automatisierbares Verfahren anwenden, ohne gezwungen zu sein, das physische oder
das logische Schema im Detail zu betrachten. Spätere Änderungen oder Anpassungen sind dadurch stets auf konzeptionellen
Niveau darzustellen. Dieser Vorteil rechtfertigt das Verschieben der Transformation auf den letzten Schritt.
Grundkenntnisse.
Übersetzungstechniken kann man analog zu den Ansä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 Integritätsbedingungen: Ein Schema hat implizite und explizite Integritätsbedingungen. Übersetzungstechniken verwenden oft nur einen Teil der entwickelten semantischen Bedingungen.
Prozeßunterstützung: Einige erweiterte Entity-Relationship-Modelle lassen das explizite Modellieren von Prozessen z.B.
durch Transaktionen zu. Andere dagegen erlauben keine Operationen. Aufgrund der Integritätserzwingungsmechanismen, die in Kapitel ?? bereits entwicklet wurden, sind generische Operationen bereits modelliert. Darüber hinausgehende
Mechanismen können angewandt werden.
Entwerferinteraktion: Einige Transformationstechniken sind nichtdeterministisch und lassen eine direkte Interaktion mit dem
Entwerfer zu.
Übersetzungsvoraussetzungen: Oft setzen Übersetzungen spezifische Normalformen voraus. Weiterhin werden oft Metaannahmen (unique-name-assumption u.a.) vorausgesetzt.
Erhaltung der gesamten Entwurfsinformation: Es ist möglich, die gesamte Entwurfsinformation in das logische Zielmodell
zu transformieren. Meist fehlt aber eine Umsetzung in ein physischen Modell, so daß darauf auch für physische Modelle
verzichtet werden muß.
Qualität des Zielschemas: Durch eine Reihe von Zugängen kann ein minimales, normalisiertes oder nichtredundantes Schema fü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 Veröffentlichung zuruückgezogen worden. Wir verwenden diesen Ansatz aufgrund seiner
Richtigkeit jedoch im weiteren.
Mod IS
IS ADD
WebIS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
241
2.10.1 Interpreter-Zugang
Interpretation von ER-Konstrukten durch relationale Konstrukte.
Fast alle Bücher und auch die entsprechenden Vorlesungen bieten nur den interpretierenden Zugang an!!!
Mehrschrittverfahren wobei Semantik und Funktionalität mit übertragen werden muß
Schlüssel und funktionale Abhängigkeiten in Schlüssel, funktionale und mehrwertige Abhängigkeiten
implizite Komponenten in Inklusionsabhängigkeiten
Exklusionsabhängigkeiten in Exklusionsabhängigkeiten
Kardinalitätsbedingungen in funktionale, Inklusions- und No-null-Abhängigkeiten
1. Herstellen der ersten Normalform (Tupelattribute durch Verkettungsregel, Mengenattribute entweder über Wiederholung
in Tupeln oder durch eigene Relation); Neuberechnung der Schlüssel (bei Mengenattributen, die bislang im Schlüssel
vorkamen, wird dann eine mehrwertige Abhängigkeit generiert und der Schlüssel verändert sich stark)
2. Flache Entity-Typen werden in Relationenschema überführt
3. Schwache flache Entity-Typen werden in Relationenschema übersetzt, wobei die Attributmenge um die Schlüssel der
identifizierenden Schemas erweitert werden.
4. Hierarchien von Typen sind in einem der folgenden Zugänge überfü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 überführt
• Binäre 1:1-Relationship-Typen :
Mehrere Optionen:
• Einbetten in vorhandenes Relationenschema (möglichst der ‘mandatory’-Seite; d.h. bei (1,1):(0,1)-Typen in
ersten Typ) des Primärschls̈sels des anderen Typen, sowie der Attribute des Relationship-Typen (Einfügen
eines Fremdschlüssels)
• Definieren eines separaten Relationenschemas mit Primärschlüssel der Komponenten und Attributen des RelationshipTypen
• Zusammenfügen der beiden Relationenschemas unter Beifügung der entsprechenden Relationship-Typ-Attribute
falls Attribute keine Nullwerte enthalten dürfen, dann nur bei (1,1):(1,1)-Typen
• N-äre 1:...-Relationship-Typen (n > 2):
Mehrere Optionen:
• Einbetten in vorhandenes Relationenschema (möglichst der ‘mandatory’-Seite; d.h. bei (1,1):(0,1)...-Typen in
ersten Typ) des Primärschls̈sels des anderen Typen, sowie der Attribute des Relationship-Typen (Einfügen
eines Fremdschlüssels)
• Definieren eines separaten Relationenschemas mit Primärschlüssel der Komponenten und Attributen des RelationshipTypen
• Zusammenfügen der beiden Relationenschemas unter Beifügung der entsprechenden Relationship-Typ-Attribute
falls Attribute keine Nullwerte enthalten dürfen, dann nur bei (1,1):(1,1)-Typen
• Binäre 1:n-Relationship-Typen :
Mehrere Optionen:
• Einbetten in vorhandenes Relationenschema (möglichst der ‘mandatory’-Seite; d.h. bei (1,1):(0,1)-Typen in
ersten Typ) des Primärschls̈sels des anderen Typen, sowie der Attribute des Relationship-Typen (Einfügen
eines Fremdschlüssels)
• Definieren eines separaten Relationenschemas mit Primärschlüssel der Komponenten und Attributen des RelationshipTypen
Mod IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
242
• N-äre 1:n...-Relationship-Typen (n > 2):
Mehrere Optionen:
• Einbetten in vorhandenes Relationenschema (möglichst der ‘mandatory’-Seite; d.h. bei (1,1):(0,1)...-Typen in
ersten Typ) des Primärschls̈sels des anderen Typen, sowie der Attribute des Relationship-Typen (Einfügen
eines Fremdschlüssels)
• Definieren eines separaten Relationenschemas mit Primärschlüssel der Komponenten und Attributen des RelationshipTypen
• n:m -Relationship-Typen
Definieren eines separaten Relationenschemas mit Primärschlüssel der Komponenten und Attributen des RelationshipTypen
• Rekursive Relationship-Typen
wier normale Relationship-Typen aber unter Beibehaltung der Rollennamen
• Is-A-Relationship-Typen
• Einbetten in vorhandenes Relationenschema (möglichst der ‘mandatory’-Seite; d.h. bei (1,1):(0,1)-Typen in
ersten Typ) des Primärschls̈sels des anderen Typen, sowie der Attribute des Relationship-Typen (Einfügen
eines Fremdschlüssels)
• Definieren eines separaten Relationenschemas mit Primärschlüssel der Komponenten und Attributen des RelationshipTypen
• Zusammenfügen der beiden Relationenschemas unter Beifügung der entsprechenden Relationship-Typ-Attribute
falls Attribute keine Nullwerte enthalten dürfen, dann nur bei (1,1):(1,1)-Typen
• Cluster
Mehrere Optionen:
• Definieren eines separaten Relationenschemas mit Primärschlüssel der Komponenten und Attributen des RelationshipTypen unter Einbeziehung der Rollennamen
• Einbetten in vorhandenes Relationenschema (möglichst der ‘mandatory’-Seite) des Primärschls̈sels des anderen Typen (Einfügen eines Fremdschlüssels) unter Beibehaltung der Rollennamen
• Einführen eines virtuellen Clusters durch Nutzung der Indexisierung
CREATE CLUSTER
und damit eines Typs, der nur die Schlüssel vereinigt!
Interpretation durch XML-Modelle (DTD).
Nach Lipeck/Kleiner [KL02]
Mod IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
Der Algorithmus nach Lipeck/Kleiner:
Mod IS
ab SS 2012
243
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
Übersetzung von HERM in XML-Bäume.
HERM ist besser geeignet als einfache ER-Modelle
• Typen bereits genestete Struktur
• Typen höherer Ordnung
• unäre Kardinalitätsbeschrä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 Einschränkung von HERM
• XML Schema und XForms geeignet für hierarchische Extrakte von HERM
• HERM-Spezialisierung entspricht Schema-Typen-Spezialisierung
• einelementige Kardinalitäten
ansonsten clustering mit pivoting
• Varianten von I-Objekten über XDNL-Zugang
• XML - objekt-orientiertes hierarchisches Datenmodell
• Mehrfach-Szenarien werden mit XDNL-Varianten verbunden
damit ist Übertragung von HERM-Schemata in XML Schemata determiniert
Übersetzung
Mod IS
244
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
245
• Objektifizierung mit Master-Slave-Mirror
für Auflösung mit ID’s
alle Typen, auf die verwiesen wird
unter Beachtung der Exklusionsabhängigkeiten
• starke Aggregationen sind exklusiv (Komponente gehört zu genau einem Supertyp)
• schwache (nicht-exklusive) Aggregationen werden in (evt. auch künstliche) Mirror-Beziehung abgebildet
evt. mit Varianten je nach Interaktion un Szenarien
• schrittweise Übersetzung von HERM-Typen von 0. Ordnung bis zu i. Ordnung
Entity-Typen werden direkt übertragen
Attributtypen sind auch in HERM exklusiv, gehören zu ER-Typen
Cluster-Typen werden in Varianten übertragen
Relationship-Typen werden ggf. auch kolladiert ((1, 1)(1, 1)-Typen) bzw. objektifiziert
Hierarchien müssen nicht aufgelöst werden, sondern werden direkt als Subtypen realisiert
• Sichten werden als Anfragen in XML-QL formuliert, falls nicht bereits in Schema-Definition eingegangen
• Integritätsbedingungen der Datenbank für XML-Interaktion müssen spezifisch behandelt werden
• Translationsmechanismus wird analog für die Datenbank mit HERM-Reengineering-Zugang erweitert
damit ist dann Direktanbindung der Datenbank möglich
Interpretation durch Netzwerk- und hierarchische Modelle.
Netzwerkmodell
Zwei Konstrukte: Recordtyp, Settyp
stark implmentationsabhä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 können auch mehrere Membertypen haben, meist wird jedoch Zweistelligkeit der Beziehung hervorgehoben
und nur jeweils ein Membertyp zugelassen; damit dann graphische Repräsentation durch Bachman-Diagramme
Settyp ist kein Mengentyp !! Codasyl empfiehlt Liste !!
Professor
Mod IS
hält Vorlesung
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
246
Ein Pfeil wird von A nach B gezeichnet, wenn eine partielle Funktion von B C nach AC 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 eingefügt
• oder next/prior: Einfügen jeweils vor bzw. nach laufendem Pointer (z.B. letzte Anfrag)
• oder System Default: wird durch System übernommen
• oder Sortiert: nach Werten vorgegebener Attribute
Einschränkungen :
jeder Record - Member in höchstens einer Occurrence eines gegebenen Settyps
Member-Record kann nicht im gleichen Settyp Owner sein
erlaubt ist jedoch zusätzlich:
ein Record kann mehrfach Owner-Record verschiedener Settypen sein
ein Record kann gleichzeitig Member-Record verschiedener Settypen sein
es können gleichzeitig mehrere Settypen zwischen gleichen Paaren von Recordtypen gebildet werden
Abfederung der Inflexibilität durch:
Set-Insertion-Option Einfügen eines neuen Member-Records vom Typ R
• Automatisch: falls R Membertyp in Settyp S, dann neuer Record auch in S eingefügt
• Manual: Einfügen in S ist Programmierersache
Set-Retention-Option Member-Record vom Typ R in S lö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
Übersetzung von ER-Schemata in Netzwerkdiagramme
Verschiedene Strukturen müssen aufgelöst werden:
• Relationship-Typen höherer Ordnung (> 1) bzw. Arität (> 2)
• Relationship-Typen mit eigenen Attributen
• rekursive Relationship-Typen
• IsA-Relationship-Typen
• z.T. 1-1-Beziehungen
• Cluster
Mod IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
247
Folgende Strukturen können im wesentlichen erhalten bleiben:
• Entity-Typen mit genesteten Attributen
• attributlose, binäre 1:n Relationshiptypen
Übersetzung der Problemfälle
• 1-1-Beziehungen ohne Attribute: entweder Zusammenfassen zu einem Typ oder Bildung eines Settyps für einen
der beiden Typen
• m-n-Beziehungen bzw. nicht-binaäre Beziehungen: Einführen mehrerer Settypen und eines Membertyps (KettTyp) 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ß über DML gelöst werden
• Rekursive Typen: Duplizierung des Recordtyps mit Umbenennung oder Einbeziehung eines Dummy-MemberTyps
Person
?
IsA
IsA
Professor
hält
ª betreut
ª
R
Vorlesung
Student
wird-besucht
besucht
R
ª
Stud-Vorles
Vorlesung
setzt
voraus
?
IsA
?
Dummy
Vorlesung
6
wird vorausgesetzt von
IsA
?
Vorausges
Vorlesung
Vorlesung
6
wird vorausgesetzt von
6
IsA
Vorausges
Vorlesung
Optimierung der Übersetzung durch entsprechende ER-Normalisierung
Ersetzung der genesteten Strukturen durch flache:
Mengennestung wird durch Einführung eines neuen Kett-Typs aufgehoben mit entsprechender Set-Typen-Einführung
Mod IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
248
Tupelnestung wird verflacht
Integritätsbedingungen sind Programmiereraufgabe bis auf:
Domain-Bedingungen: mit CHECK-Klausel
Intrarecord-Bedingung: duplicates are not allowed for < Attribut >
ist aber keine Schlüsselbedingung
Interrecord-Bedingung: gleichbenannte Attribute können über CHECK getestet werden (damit referentielle Integrität
mö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
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
249
2.10.2 Intelligente Übersetung durch Beachtung der Spezifika von HERM-Schemata
Spezifika der Struktur-Übersetzung von HERM-Schemata.
Beobachtung 2.
Es können komplexe Attribute auch eine harmonisierte Übersetzung anderer komplexer Attribute erfordern.
Beispiel:
Name(Vornamen(...), Familienname, [Geburtsname] ,...)
Adresse(PlzBezirk ◦ Zustellamt, Ort, ...)
erfordert Harmonisierung der Übertragung beider Attribute, da diese über Primärschlüssel gekoppelt sind
Beobachtung 3.
Die bisherigen Übersetzungsregeln sind nur Interpretationsregeln, die induktiv über dem Schemaaufbau definiert
sind und nicht die Möglichkeiten von SQL92 und SQL:1999 unterstützen.
Ein compilierender Zugang wird i.a. besser sein.
Übersetzungsregeln in SQL:1999 nach S. Schoradt:
1. Datensammelnde Regeln
Für die Transformation eines Typen werden Informationen benötigt, die am Typen direkt anliegen, sich aus den
Verbindungen zu anderen Typen ergeben oder aber aus anderen Typen bezogen werden müssen.
Da die Übersetzungsregeln, der Übersichtlichkeit halber, nur lokal auf einem Typen des Schemagraphen wirken
sollen, werden durch Regeln zur Datensammlung die notwendigen Daten zur Tranformation der Typen zusammengetragen. Dies können z. B. die Notwendigkeit der Erstellung eines Surrogatschlüssels zu einer Entitytypen
oder das Hinzufügen von Integritätsbedingungen zu einem Typen sein.
(a) Erstellen von Surrogatschlüsseln
Das Erstellen von Surrogatschlüsseln ermöglicht es Objekte, die in der konzeptionellen Sicht nur auf
sehr komplexe Art zu identifizieren sind, in einem DBMS zu verwalten. Hierzu wird zu dem Objekt ein
atomares Attribut hinzugefügt, das als neuer Schlüssel für das Objekt fungiert. Die existierende Schlüsselbeziehung wird weiterhin mitgeführt und gepflegt, dient aber nicht mehr der Identifikation der Instanzen
des Objektes. Der Surrogatschlüssel zu einem Objekt sollte vom DBMS gepflegt werden, so das die
darüberliegende Applikation diese technische Veränderung des Schemas nicht beachten muss.
Dies kann durch Mittel des DBMS zum generieren eindeutiger Objektschlüssel geschehen oder aber durch
die Erzeugung eines Schlüssels in einem Trigger zum Objekt.
Durch diese Regel wird zu jeder Entity-Typen oder Relationship-Typen, die Komponente einer Relation
oder eines Clusters ist, ein Surrogatschlüssel angelegt. Mittels diesem wird im Weiteren die Implementation der Relation und die Pflege der damit verbundenen Integritätsbedingungen realisiert.
(b) Optimierung der Schemastruktur
Bei der Übersetzung von Schemata kann es notwendig sein das Schema strukturell zu verändern, um ein
optimales Ergebnis zu erzielen. Eine häufig genutzte Optimierungsvariante ist das Auflösen von Relationen mit der Kardinalitätsbeschränkung (1, 1) oder (0,1).
Über den Controller wird festgelegt, ob für (1,1)-(0,1)-Relationship-Typen condense zu einem zusammenhängenden Typen, reference oder stay alone angestoßen wird.
(c) Integritätsbedingungen
Oftmals sind Integritätsbedingungen indirekt im konzeptionellen Schema kodiert. Um diese bei der Transformation zu beachten, müssen sie zur Menge der Integritätsbedingungen eines Typen hinzugefügt werden.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
250
Diese Regeln weisen zum Einen die Komponenten einer Relation als Schlüssel aus, falls noch nicht
geschehen und vergeben für alle Relationen deren Kardinalität nicht spezifi- ziert ist die Kardinalitätsbeschränkung (0,n).
2. Elementare Transformationen
An dieser Stelle sollen für die einzelnen Schemaelemente elementare Übersetzungsregeln angegeben werden.
Diese Wandeln einen Typen in eine SQL Anweisung oder einen Anweisungsteil um.
Die Transformationen, die in diesen Regeln verwandt werden, stammen grösstenteils aus [Tha00] und wurden
an die Möglichkeiten von SQL:1999 und den entworfenen Übersetzungsprozess angepasst.
(a) Regeln für Domaintypen
Jeder Domaintyp im Schemagraph repräsentiert eine Domäne aus dem HER Schema. Diese sind durch die
Menge aller erlaubten Elemente beschrieben und müssen durch die Transformation auf die vorhandenen
SQL Datentypen abgebildet werden.
SQL:1999 kennt Datentypen der Kategorien:
•
•
•
•
Zeichendaten
numerische Daten
Wahrheitswerte
Datumswerte
Die richtige Transformation der Domains in SQL Datentypen wird durch die Kombination von Transformationsregel und Bewertungsfunktion erreicht.
(b) Regeln zur Behandlung von Attributtypen
Bei den AttributTypen hängt die Anwendung einer Regel von ihrem Konstruktor und den globalen Parametern für die Attributtransformation ab.
Für die komplexen Attribute sind mehrere Möglichkeiten für die Transformation vorhanden:
• verflachen des Attributs durch Transformation in eine Zeichenkette mit Trennzeichen
• einführen von Blattattributen, z. B. wird ein Tupelattribut Name(vname,nname) in die Attribute Name.vname und Name.vname transformiert
• erstellen eines eigenen Subschemas
• als komplexes Attribut belassen
In SQL:1999 ergibt sich weiterhin die Möglichkeit komplexe Attribute in komplexe Datentypen zu transformieren.
Diese Option wurde soweit möglich verfolgt, um die Möglichkeiten von SQL:1999 auszunutzen.
Bei der Transformation von Tupeltypen, kann als Implementation ein ROW Typ verwandt werden.
Mengentypen werden rekursiv, anhand ihrer Struktur, transformiert. Es existieren mehrere Möglichkeiten
Mengen in einer Datenbank zu repräsentieren, hier soll dies durch das Erstellen einer Tabelle zu jeder
Menge geschehen. Zur Transformation eines mengenwertigen Attributs muss zuerst der Inhalt der Menge
transformiert werden und danach das Attribut in eine Tabelle und eine Referenz in die Mengentabelle
transformiert werden.
(c) Transformation der Entity-Typen
Die Transformation eines Entity-Typen kann erfolgen wenn alle enthaltenen Attribut-Typen transformiert
wurden.
(d) Transformation von Relationship-Typen
Die Transformation eines Relationship-Typen kann erfolgen wenn alle Attribute und alle enthaltenen
Objekte transformiert wurden.
Hierzu müssen die enthaltenen Relationen und Entityen in Fremdschlüsselbeziehungen umgewandelt
werden. Die enthaltenen Attribute werden analog zur Transformation eines Entity-Typen behandelt.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
251
(e) Transformation von Cluster-Typen
Ein Cluster-Typ wird transformiert nachdem alle enthaltenen Relationen bzw. Entityen transformiert wurden.
Der Cluster C = R1 + R2 + . . . + Rn wird in eine Referenz auf die Surrogatschlüssel der enthaltenen
Relationen transformiert, ohne aber mittels einer Fremdschlüsselbeziehung abgesichert zu werden.
Spezifika der Semantik-Übersetzung von HERM-Schemata.
Beobachtung 4.
Weder SQL’92 noch SQL:1999 erlauben eine vollständige direkte Übertragung von Integritätbedingungen.
Es können Integritätsbedingungen auf unterschiedliche Art übertragen werden:
• Restrukturierung des Schemas bis eine vollständige Übertragung unterstützt wird.
• Deklarative Spezifikation der Integritätsbedingungen.
• Prozedurale Spezifikation der Integritätsbedingungen.
• Abbildung der Integritätsbedingungen in eine Wirtssprache
• Zusätzliche integritätsbedingungssichernde Maßnahmen
• Sicherstellung durch Benutzungsschnittstellen
• Sicherstellung durch Ausnahmebehandlung
• Generierung und Benutzung von sicheren integritätspflegenden Funktionen anstelle der nicht invarianten
Funktionen
• Verwaltung von Integritätsverletzungen durch das System
• Transaktionssysteme
• ...
MATCH-Bedingungen.
SQL-92 erlaubt unterschiedliche MATCH-Bedingungen:
• einfach als nicht spezifiziertes “default” und Anwendung auf alle Tupel t über Attributliste X mit t[X]!, d.h.
über Teilmenge {t ∈ RC | ∀A ∈ X : t(A) 6= NULL} ,
d.h. z.B. für R[X] ⊆ S[Y ], X = A1 ...Ak , und Y = B1 ...Bk wird die Bedingung
∀t ∈ RC ( (∃i(1≤i≤k) t(Ai ) = NULL) ∨ ∃s ∈ S C (t[X] = s[Y ]))
• FULL wird angewandt auf alle Tupel, die nicht das NULL-Tupel sind, wobei dann Nullwerte nicht erlaubt sind,
d.h. z.B. für R[X] ⊆ S[Y ], X = A1 ...Ak , und Y = B1 ...Bk wird die Bedingung
∀t ∈ RC ( ∀i(1≤i≤k) (t(Ai ) = NULL)
∨
(∀i(1≤i≤k) (t(Ai ) 6= NULL) ∧ ∃s ∈ S C (t[X] = s[Y ])))
• PARTIAL wird angewandt auf alle Tupel t, deren X-Wert nicht das NULL-Tupel ist, wobei in der Kontrollmenge eine Gleichheit bis auf Nullwerte in t[X] besteht,
d.h. z.B. für R[X] ⊆ S[Y ], X = A1 ...Ak , und Y = B1 ...Bk wird die Bedingung
∀t ∈ RC ( ∀i(1≤i≤k) (t(Ai ) = NULL)
∨
C
∃s ∈ S (∀i(1≤i≤k) (t(Ai ) = NULL ∨ t(Ai ) = s(Bi ))))
wobei diese Bedingung äquivalent ist zu
∀t ∈ RC (∃s ∈ S C (∀i(1≤i≤k) (t(Ai ) = NULL ∨ t(Ai ) = s(Bi )))) .
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
252
FULL kann auch direkt ausgedrückt werden durch:
CHECK (
(A1 IS NULL AND ... AND Ak IS NULL)
OR
( A1 IS NOT NULL AND ... AND Ak IS NOT NULL
AND A1,...,Ak
IN SELECT B1 ... Bk FROM S ))
PARTIAL ist auch darstellbar durch eine Fallunterscheidung je nach vorkommenden Nullwert im referenzierendem Tupel:
CHECK (
(A1 IS NULL AND ... AND Ak IS NULL)
OR
( A1 NULL AND A2 IS NOT NULL ... AND AK IS NOT NULL
AND A2,...,Ak
IN SELECT B2 ... Bk FROM S )
OR ... OR
( A1 IS NOT NULL ... AND A(k-1) IS NOT NULL AND AK IS NULL
AND A1,...,A(k-1)
IN SELECT B1 ... B(k-1) FROM S )
OR ... OR
( A1 IS NULL AND ... A(k-1) IS NULL AND AK IS NOT NULL
AND Ak
IN SELECT Bk FROM S )
)
Ausführungsmodi.
SQL-92 hat bereits Asuführungsmodi eingeführt:
DEFERRED
IMMEDIATE
kann.
erlaubt das Aufschieben eine Kontrolle der Integritätsbedingungen bis zum Ende einer Transaktion.
fordert die Kontrolle einer Integritätsbedingung für jede Anweisung, mit der diese verletzt werden
Diese Ausführungsmodi können gesetzt werden auf einen initialen Modus, der dann auch ggf. überschrieben werden
kann. Damit erhalten wir:
INITIALLY IMMEDIATE NOT DEFERABLE ist die default-Bedingung für Integritätsbedingungen.
Diese Bedingung kann auch durch NOT DEFERABLE INITIALLY IMMEDIATE deklariert werden.
INITIALLY DEFERRED NOT DEFERABLE Diese Bedingung kann auch durch NOT DEFERABLE INITIALLY
DEFERRED deklariert werden.
INITIALLY DEFERRED DEFERABLE Diese Bedingung kann auch durch DEFERABLE INITIALLY DEFERRED
deklariert werden.
INITIALLY IMMEDIATE DEFERABLE sollte stets für alle Bedingungen deklariert werden, die mit Transaktionen ggf. verletzt werden können. Diese Bedingung kann auch durch DEFERABLE INITIALLY IMMEDIATE
deklariert werden.
Der Ausführungsmodus kann umgesetzt werden mit
SET CONSTRAINTS
name list
IMMEDIATE
bzw.
IS ADD
CAU zu Kiel, IfI, ISE, β
SET CONSTRAINTS
2. Strukturierung von IS
name list
ab SS 2012
253
DEFERRED
bzw.
SET CONSTRAINTS
ALL
IMMEDIATE
bzw.
SET CONSTRAINTS
ALL
DEFERRED
Deklarative Spezifikation mit CHECK-Bedingungen.
CHECK-Bedingungen werden definiert
• auf Attributniveau zu den Werten dieses Attributes,
• auf Tabellenniveau für jedes einzelne Tupel der Relation, wobei hier auch subselect erlaubt sind und
• über den Umweg der Defintion mit Assertions.
Deklarative Spezifikation mit ASSERTION.
ASSERTION ist eine Schema-Bedingung. Sie ist jedoch relativ selten realisiert. Oracle erlaubt z.B. nicht die
Spezifikation.
CREATE ASSERTION Institut
CHECK (Bedingung);
Sie wird immer dann aktiviert, wenn die Klassen zu den verwendeten Tabellen modifiziert werden.
CREATE TABLE Fakultaet (
...
Nummer
FakNr PRIMARY KEY,
.. );
CREATE ASSERTION AssignFakultaet
CHECK (NOT EXISTS (
SELECT *
FROM Institut
WHERE FakNr IS NULL)
);
CREATE ASSERTION AnzahlInstZuFak
CHECK (
(SELECT COUNT(*) FROM Fakultaet) <=
(SELECT COUNT(*) FROM Institut)
);
Die erste der beiden Assertionen wird kontrolliert bei jder Veränderung zu Institut. Die zweite wird kontrolliert bei jeder Veränderung sowohl von Institut als auch von Fakultaet.
Prozedurale Spezifikation mit Triggern.
Trigger sind mit den Event-Condition-Action-Paradigma entworfen (kurz ECA). Damit gewähren Trigger anderen Möglichkeiten als die anderen SQL-Konstrukte.
So kann z.B. mit Oracle folgender Trigger spezifiziert werden.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
254
CREATE OR REPLACE TRIGGER TriggInstitutFakult
AFTER INSERT ON Institut
FOR EACH ROW
WHEN (new.Fakultaet NOT IN
(SELECT Nummer FROM Fakulataet))
BEGIN
INSERT INTO Fakultaet (Nummer)
VALUES (:new.Fakultaet);
END;
.
run
Folgende Besonderheiten sollten beachtet werden:
•
•
OR REPLACE kann auch nicht spezifiziert werden. Sollte jedoch bereits ein Trigger existieren, dann ist dies
ein Fehler.
AFTER kann auch ersetzt werden durch BEFORE .
• Wird der Trigger für eine Sicht spezifiziert, dann kann auch anstelle von AFTER der Ersatz durch INSTEAD OF be
nutzt werden. Damit kann auch eine Sicht modifiziert werden.
• Anstelle von INSERT kann auch DELETE oder UPDATE OF <attribute> verwendet werden.
•
FOR EACH ROW kann man auch weglassen. In diesem Fall wird der Trigger nur einmal für jede Modifikationsmenge zur Relation angewandt.
• Die Variablen new und old repräsentieren den Zustand nach bzw. vor Anwendung der Modifikationsoperation. Bei Verwendung der Variablen in Anfragen ist der Doppelpunkt erfoderlich ( :new.Fakulataet ).
• Die Aktionen sind Anweisungen des Systemes. Mitunter sind sie verschieden in verschiedenen Systemen.
• Durch den Punkt wird die Triggerdefinition abgelegt mit einem run .
• Oracle erlaubt keine Veränderung einer Relation, deren Trigger feuert, sowie auch von assoziierten Relationen
(z.B. über Fremdschlüssel).
Trigger in Sybase
Eine Integritätsbedingung als Sybase-Trigger in unserem Beispiel wird z.B. wie folgt beschrieben
create trigger tI_eingeschriebenIn on eingeschriebenIn for INSERT as
begin
declare @numrows int,
@nullcnt int,
@validcnt int,
@errno
int,
@errmsg varchar(255)
select @numrows = @@rowcount
if
update(MatrNr)
begin
select @nullcnt = 0
select @validcnt = count(*)
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
255
from inserted,Student
where
inserted.MatrNr = Student.MatrNr
if @validcnt + @nullcnt != @numrows
begin
select @errno = 30002,
@errmsg = ’Cannot INSERT eingeschriebenIn because Student does not exist.’
goto error
end
end
return
error:
raiserror @errno @errmsg
rollback transaction
end
go
Trigger in Oracle
Analog wird ein Trigger mit Oracle deklariert, mit dem ein Update in anderen Relationen erzwungen wird:
create trigger tI_eingeschriebenIn
after INSERT
on EingeschriebenIn
for each row
declare numrows INTEGER;
begin
/* ON CHILD INSERT CASCADE */
insert into Student (MatrNr)
select MatrNr
from EingeschriebenIn
where
not exists (
select * from Student
where
:new.MatrNr = Student.MatrNr
);
end;
/
create trigger tD_EingeschriebenIn
after DELETE
on EingeschriebenIn
for each row
declare numrows INTEGER;
begin
/* ON CHILD DELETE RESTRICT */
select count(*) into numrows from Student
where
:old.MatrNr = Student.MatrNr;
if (numrows > 0)
then
raise_application_error(
-20010,
’Cannot DELETE EingeschriebenIn because Student exists.’
);
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
256
end if;
end;
/
create trigger tU_EingeschreibenIn
after UPDATE
on EingeschriebenIn
for each row
declare numrows INTEGER;
begin
/* ON CHILD UPDATE RESTRICT */
select count(*) into numrows
from StarkerTyp
where
:new.MatrNr = Student.MatrNr;
if (
numrows = 0
)
then
raise_application_error(
-20007,
’Cannot UPDATE EingeschriebenIn because Student does not exist.’
);
end if;
end;
/
create trigger tD_Student
after DELETE
on Student
for each row
declare numrows INTEGER;
begin
/* ON PARENT DELETE RESTRICT */
select count(*) into numrows
from einfachabhangig
where
EingeschriebenIn.MatrNr = :old.key;
if (numrows > 0)
then
raise_application_error(
-20001,
’Cannot DELETE Student because EingeschriebenIn exists.’
);
end if;
end;
/
/* Student ON PARENT UPDATE CASCADE */
/* Student ON CHILD DELETE RESTRICT */
/* Student ON CHILD INSERT CASCADE */
/* Student ON CHILD UPDATE RESTRICT */
Trigger in PostgreSQL
Trigger könne in PostgreSQL durch Funktionen realisiert werden, die die neue RECORD Variable nutzen:
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
257
• Es wird die Funktion deklariert.
• Der Trigger benutzt die Funktion.
Funktionendefinition:
CREATE FUNCTION trigger_insert_update_relName()
RETURNS opaque
AS
’BEGIN
IF ...
THEN RAISE EXCEPTION ’’Mitteilung an alle’’;
END IF;
RETURN new;
END;’
LANGUAGE ’plpgsql’;
Damit kann nun der Trigger spezifiziert werden:
CREATE TRIGGER tr_relName
BEFORE INSERT OR UPDATE
ON relName
FROR EACH ROW
EXECUTE PROCEDURE
trigger_insert_update_relName()
;
Zusammenfassende Übersicht.
Art
Primary
key, domain
constraints
Unique
constraints
Referential
constraints
CheckBedingungen
Assertions
Entry Level
immer sofort
SQL-92
Intermediate Level
immer sofort
NOT NULL, immer
sofort
MATCH wird nicht
unterstützt
ohne subquery
MATCH wird nicht
unterstützt
ohne subquery
nicht unterstützt
nicht unterstützt
SQL-99
Full Level
2.10.3 Allgemeine Grundlagen der Erzwingung von Integritätsbedingungen
In SQL 99 bestehen mehrere Möglichkeiten Integritätsbedingungen auszudrücken und zu erzwingen. Diese sind
• Tabellenbedingungen, wie PRIMARY KEY, UNIQUE oder CHECK Beschränkungen
• Ausnahmen (Assertion), die einen unerwünschten Zustand in der Datenbank verhindern
• Trigger, die ermöglichen auf Datenbankoperationen zu reagieren
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
258
Tabellenbedingungen, wie PRIMARY KEY, UNIQUE oder CHECK können nur über den Daten einer Tabelle formuliert werden. Dies macht sie für die meisten der benötigten Integritätsbedingungen nur bedingt nutzbar.
Komplexere Bedingungen können mittels Ausnahmen (Assertions) oder Trigger beschrieben werden.
Bei einer Ausnahme, wird ein erwünschter Datenbankzustand beschrieben, und es wird von der Datenbank nach
jeder datenverändernden Aktion garantiert, das dieser noch erfüllt wird. Wird der Zustand nicht erfüllt, so wird die
Aktion abgelehnt. Durch Trigger kann nach einer datenverändernden Aktion individuell reagiert werden.
Schlüsselbedingungen: Die Behandlung von HER Schlüsselbedingungen kann auf zwei Arten erfolgen. Zum einen
durch eine statische UNIQUE Bedingung über den Schlüsselfeldern der erstellten Tabelle oder aber durch eine
Ausnahmebehandlung mittels ASSERTION.
Die Auswahl des geeigneten Mittels hängt von der Komplexität des Schlüssels ab. Schlüssel im HER Ansatz
werden als generalisierte Untermengen [Tha91, S. 7] der Attributmenge eines Entity-Typs beschrieben. Diese
können nur auf die Schlüsselbedingungen in SQL abgebildet werden, wenn die Untermenge nur aus atomaren
Attributen des Entity-Typen besteht.
Ist diese Bedingung für den Schlüssel nicht erfüllt, so muss dieser in eine ASSERTION transformiert werden.
Stehen keine Ausnahmen zur Verfügung, kann ebenfalls ein Trigger, der bei Verletzung der noch zu definierenden Schlüsselbedingung key condition ein Rollback der letzten Datenbankaktion auslöst, verwandt werden.
Solch ein Trigger müsste zu allen des Objekt E betreffenden Tabellen in der Datenbank erstellt werden.
Aus diesem Grunde stellt eine Ausnahme die vorzuziehende Alternative dar.
Um die Schlüsselbedingung zu garantieren darf es keine zwei verschiedenen Datensätze in E geben, bei denen alle atomaren Schlüsselattribute und die aus den mengenwertigen Schlüsselattributen ableitbaren Mengen gleich sind. Da Mengen in SQL nicht auf kanonische Weise vergleichbar sind, wird der Zusammenhang
M1 = M2 ⇔ M1 ∪ M2 \ M1 ∩ M2 = ∅ für den Vergleich zweier Mengen verwandt. Dieser lässt sich mittels
UNION, INTERSECTION und EXCEPT in SQL ausdrücken. Anhand dieser Betrachtungen wurde die Abfrage
key condition abgeleitet:
SELECT COUNT(_) FROM E e1, E e2
WHERE e1.s1 = e2.s1 AND . . . AND e1.sk = e2.sk
AND NOT EXISTS
(
(
( SELECT i1 FROM set m1 WHERE set id = e1.k1.m1
UNION
( SELECT i1 FROM set m1 WHERE set id = e2.k1.m1
) EXCEPT (
( SELECT i1 FROM set m1 WHERE set id = e1.k1.m1
INTERSECT
( SELECT i1 FROM set m1 WHERE set id = e2.k1.m1
)
)
. . .
AND NOT EXISTS
(
(
( SELECT il FROM set ml WHERE set id = e1.kl.ml )
UNION
( SELECT il FROM set ml WHERE set id = e2.kl.ml )
)
EXCEPT
(
( SELECT il FROM set ml WHERE set id = e1.kl.ml )
INTERSECT
IS ADD
)
)
)
)
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
259
( SELECT il FROM set ml WHERE set id = e2.kl.ml )
)
)
AND e1. E id <> e2. E id
Wertebereichsbeschränkungen sollen den Wertebereich direkt spezifizieren. Diese können entweder durch einen
extra spezifizierten Wertebereich dargestellt werden (die bessere Variante) oder durch eine Bedingung in der
Tabellendefinition.
CREATE TABLE Institut (
...
Fakultaet
char(1) NOT NULL
CHECK VALUE IN (’1’, ’2’, ’3’, ’4’),
.. );
Besser ist die Definition eines Wertebereiches
CREATE DOMAIN FakNr CHAR(1) CHECK VALUE IN (’1’, ’2’, ’3’, ’4’);
und die Benutzung dieses Wertebereiches mit
CREATE TABLE Institut (
...
Fakultaet
.. );
FakNr NOT NULL,
Hierarchiebedingungen: Oft werden Hierarchien abgebildet im Vereinigungszugang. So kann z.B. due Hierarchie
Person, Professor in einen Typ abgebildet werden:
CREATE TABLE Person (
Name
Gebdatum
Geburtsort
Adresse
Spezialisierung
InIName
char[40]
date
char[20],
char[60]
varchar[50]
char[15]
Primary Key,
Primary Key,
CHECK ((InIName IS NULL
AND Spezialisierung IS NULL)
OR (InIName IS NOT NULL
AND Spezialisierung IS NOT NULL))
CHECK ((InIName IS NULL
AND Spezialisierung IS NULL)
OR (InIName IS NOT NULL
AND Spezialisierung IS NOT NULL))
);
Kardinalitätsbedingungen: Die Transformation der Kardinalitätsbeschränkungen, benötigt einige Vorbetrachtungen, die es uns im späteren ermöglichen einigen Problemen bei der Behandlung dieser zu umgehen.
Kardinalitätsbeschränkungen beschreiben die Beziehungen zwischen Relationen und ihren Komponenten in
einem HER Schema.
Bei der Betrachtung einer Menge von Kardinalitätsbeschränkungen ist schnell ersichtlich, das bei schlechtem
Design Konstellationen entstehen können, die nach der Transformation auf eine Datenbank in dieser unerwartete Effekte erzeugen können, z.B. zu unerfüllbaren Datenbankschemata führen.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
260
In [Tha00] wird die Nichterfüllbarkeit eines Systems von Kardinaliträtsbeschränkungen auf die Existenz eines
kritischen Pfades im System reduziert. Unter Nutzung des dort beschriebenen Tests auf Nichterfüllbarkeit und
der Möglichkeiten zur Korrektur der Kardinalitätsbeschränkungen eines Schemas kann die Menge der Kardinalitätsbeschränkungen soweit möglich in einen konsistenten Zustand gebracht werden, so das die Transformation
auf das Datenbankniveau keine unerwarteten Effekte erzeugt.
Die Transformation der Kardinalitätsbeschränkung kann analog zu den Schlüsselbeschränkungen in einen Trigger oder eine Ausnahme erfolgen. Es ist aber auch unter speziellen Bedingungen möglich, Kardinalitätsbedingungen durch eine Transformation des Ergebnissschemas auszudrücken. So kann bei Kardinalitätsbedingungen
der Form comp(R, Ri ) = (n, 1) , mit n ∈ {0, 1} auf einer binären Relation R, die Relation R aufgelöst werden und in die Relation Ri hineingezogen werden. Das bewirkt das alle Attribute aus R zu Attributen von Ri
werden.
Gilt n = 0 wird der Spaltendefinition noch eine NULL Definition hinzugefügt.
Handelt es sich nicht um eine Kardinalitätsbeschränkung der obigen Art, so ist die Transformation in einen
Trigger der Ausnahme vorzuziehen, da individuell auf die Verletzung der Bedingung reagiert werden kann.
Zu jeder Kardinalitätsbeschränkung ist die zu triggernden Aktionen bei Veränderung oder Löschen des referenzierten Datensatzes als Transformationsparameter zu beachten. Die Transformation der Kardinalitätsbeschränkung comp(R, Ri ) = (m, n) führt zu einer Veränderung der Relation und zu mehreren Triggern. Für
die Kardinalitätsbedingung sind die Aktionen
• Einfügen von Elementen in Ri
• Verändern der Identifikationsspalte (hier des Surrogatschlüssels) von Ri. Dieser Fall sollte nicht auftreten,
ist aber aus Stabilitätsgründen trotzdem zu behandeln.
• Einfügen von Elementen in R. Es können hier die Beschränkungen von 26 überschritten werden.
• Verändern der Ri Spalte von R. Hier sind die unteren und oberen Grenzen der Kardinalitätsbedingungen
zu überprüfen.
• Löschen von Elementen von R. Hier ist die untere Grenze der Bedingung zu prüfen. zu überwachen.
Werden durch eine dieser Aktionen die Bedingungen verletzt, so wird die auslösende Aktion zurückgenommen.
Hierbei ist im Zusammenhang mit dem Hintergrund der Datenpflege zu beachten das bestimmte Integritätsbedingungen erst nach dem Ende einer Transaktion gepflegt werden dürfen, da sonst ihre Erfüllung praktisch
ünmöglich ist. Dies ist z. B. bei Kardinalitätsbeschränkungen der Form comp(R, E) = (1, n) der Fall. Beim
Einfügen eines Datensatzes in E muss auch ein Eintrag in der Relation R erfolgen. Dies kann praktisch durch
eine Transaktion geschehen, in der erst der Datensatz in E angelegt wird und daraufhin der Datensatz in R.
Für die Transformation einer Kardinalitätsbeschränkung werden auch Trigger erzeugt, durch die die Einhaltung der Kardinalitätsbedingung comp(R, Ri ) = (m, n) erreicht wird. Sie verhindern jede datenverändernde
Aktion (Insert, Update oder Delete), durch die die Kardinalitätsbedingung verletzt werden könnte. Da die Kardinalitätsbedingung per Definition in der leeren Datenbank erfüllt ist, so ist sie es auch in jeden Folgezustand.
Wir können Kardinalitaätsbedingungen in zwei Klassen von Integritätsbedingungen aufspleißen:
1. Unäre tupelgenerierende Bedingungen
LHS vminimal multiplicity RHS bzw. card(RHS, LHS) = (a, .)
• Insertion in LHS: Kaskadierend in RHS oder Verbot für LHS (wenn IC ungültig, RESTRICT (als
harte Bedingung: wird sofort vor allen anderen kontrolliert) oder NO ACTION (als weiche Bedingung: wird nach allen anderen IC kontrolliert)) oder Benutzung von Ersatzwerten (DEFAULT oder
NULL)[wobei diese Optionen nur in Ausnahmefällen sinnvoll sind] in RHS oder bewußte Verletzung
(REFERENCES ARE NOT CHECKED, SKIP)
Default-Strategie für fast alle Systeme: REJECT
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
261
• Insertion in RHS: keine Auswirkungen
• Delete in RHS: CASCADE in LHS oder RESTRICT (in SQL-92: Default-Regel; wenn nicht deklarierts) bzw. NO ACTION in RHS oder SET DEFAULT bzw. SET NULL in LHS oder bewußte
Verletzung (SKIP)
• Delete in LHS: keine Auswirkungen
• Update in LHS: CASCADE in RHS oder RESTRICT bzw. NO ACTION in LHS oder SET DEFAULT
bzw. SET NULL in RHS [wobei diese Optionen nur in Ausnahmefällen sinnvoll sind] oder bewußte
Verletzung (SKIP)
Default-Strategie für fast alle Systeme: REJECT
• Update in RHS: CASCADE in LHS oder RESTRICT bzw. NO ACTION in RHS oder SET DEFAULT
bzw. SET NULL in LHS oder bewußte Verletzung (SKIP)
Erzwingungsmodus als Hexatupel (iLHS , λ, λ, dRHS , uLHS , uRHS )
ausreichend ist bereits Quadrupel (iLHS , dRHS , uLHS , uRHS )
z.B. card(EingeschriebenIn, Student) = (1, .) erfordert (iStud =C,λ,λ,dEing =R,uStud =R,uEing =R)
bzw. (iStud =C,dEing =R,uStud =R,uEing =R)
Realisierung:
• RESTRICT für Insert und Update bei card(RHS, LHS) = (1, .) bei EingeschriebenIn
:
ALTER TABLE Student ADD CONSTRAINT
CHECK(EXISTS(SELECT * FROM EingeschriebenIn
WHERE EingeschriebenIn.StudMatrNr = MatrNr));
Alternativ kann auch bei einigen Systemen die RESTRICT-Regel direkt den Attributen zugeordnet
werden:
CREATE TABLE EingeschriebenIn (
StudMatrNr
char[7]
CHECK(
StudMatrNr IN (SELECT MatrNr FROM Student)
),
...
Bis
date
CHECK ( Von < Bis )
PRIMARY KEY (SName, StudMatrNr)
);
Die Möglichkeit wird z.Z. nur rudimentär unterstützt. Z.B. Oracle erlaubt keine Subqueries in Bedingungen. Die CHECK-Bedingung ist weniger restriktiv, da eine Veränderung in Student nicht
auf EingeschriebenIn durchgegeben wird! Sie wird nur kontrolliert, wenn das entsprechende
Attribut sich in EingeschriebenIn ändert (d.h. bei Update und Insert).
Analog für RESTRICT für Insert und Update bei card(RHS, LHS) = (3, .)
ALTER TABLE Student ADD CONSTRAINT
CHECK(EXISTS(
SELECT * FROM EingeschriebenIn E1,
WHERE E1.StudMatrNr = MatrNr
AND EXISTS(
SELECT * FROM EingeschriebenIn E2
WHERE MatrNr = E2.StudMatrNr
AND E1.SName <> E2.SName
AND EXISTS(
SELECT * FROM EingeschriebenIn E3
WHERE E3.StudMatrNr = MatrNr
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
262
AND E1.SName <> E3.SName
AND E2.SName <> E3.SName))));
• Modi für Delete und Update für Komponentenabhängigkeiten R[S] ⊆ S
z.B. EingeschriebenIn[Student] ⊆ Student bei Student
wird durch Nebenbedingung für den Fremdschlüssel mit bewältigt:
CREATE TABLE EingeschriebenIn (
StudMatrNr
char[7]
FOREIGN KEY
REFERENCES Student(MatrNr)
ON DELETE CASCADE
ON UPDATE RESTRICT,
...
Bis
date
CHECK ( Von < Bis )
PRIMARY KEY (SName, StudMatrNr)
);
ALTER TABLE Student ADD CONSTRAINT
CHECK(EXISTS(SELECT * FROM EingeschriebenIn
WHERE EingeschriebenIn.StudMatrNr = MatrNr));
Damit erhalten wir die folgende Auflösung für den Fall R1 [X] v(1,.) R2 [Y ]
Schlüssel von R2 ist:
CASCADE
RESTRICT
NO ACTION
insertR1
deleteR1
–
–
–
updateR1
insertR2
–
–
–
deleteR2
foreign key
foreign key
foreign key
updateR2
foreign key
foreign key
foreign key
für den Fall, daß Y ein
NULL/DEFAULT
–
–
foreign key
foreign key
Im allgemeinen Fall erhalten wir die folgende Auflösung für den Fall R1 [X] v(a,.) R2 [Y ] :
CASCADE
RESTRICT
NO ACTION
NULL/DEFAULT
insertR1
stored procedure
CHECK
CHECK DEFERRED
deleteR1
–
–
–
–
updateR1
trigger
CHECK
CHECK DEFERRED
insertR2
–
–
–
–
deleteR2
updateR2
2. Numerische Beschränkungen card(RHS, LHS) = (0, b)
• Insertion in LHS: kein Effekt
• Insertion in RHS: CASCADE in RHS (Bereinigung (DELETE von Konkurrenten)) oder RESTRICT bzw. NO
ACTION in RHS oder bewußte Verletzung (SKIP)
• Delete in LHS: keine Auswirkungen (bzw. positive Auswirkungen)
• Delete in RHS: keine Auswirkungen
• Update in LHS: CASCADE in RHS oder RESTRICT bzw. NO ACTION in LHS oder bewußte Verletzung
(SKIP)
• Update in RHS: CASCADE in RHS (Bereinigung (DELETE von Konkurrenten)) oder RESTRICT bzw. NO
ACTION in RHS oder bewußte Verletzung (SKIP)
Erzwingungsmodus als Hexatupel (λ, iRHS , λ, λ, uLHS , uRHS )
ausreichend ist bereits Tripel (iRHS , uLHS , uRHS )
z.B. card(EingeschriebenIn, Student) = (0, 3) erfordert (iEing =R,uStudent =C,uEing =R) .
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
263
Spezielle numerische Beschränkungen sind funktionale Abhängigkeiten. Diese können wie card(RHS, LHS) =
(0, 1)-Abhängigkeiten behandelt werden.
• Primärschlüsselabhängigkeiten werden sowohl im Entry als auch Intermediate Level von SQL’92
sofort erzwungen. Es wird die “Entity-Integrität” gefordert (keine Nullwerte in diesen Attributen),
d.h. es wird gefordert ∀t ∈ RC (t[K]!).
• Sekundarschlüsselabhängigkeiten erlauben einen variablen Erzwingungsmodus: immediate oder deferred. Im Entry Level von SQL’92 ist noch die “Entity-Integrität” gefordert. Der Nullwert wird wie
ein Wert in der Ungleichung t(A) 6= t0 (A) behandelt.
Die DBMS haben ggf. hier eine abweichende Behandlung:
• SQL-99 fordert bei UNIQUE-Bedingungen den Vergleich nur bei gleichzeitig voll definierten
Teiltupeln:
∀t∀t0 (t[X]! ∧ t0 [X]! → t[X] 6= t0 [X]).
• ORACLE erzwingt UNIQUE nur für vollständig definierte Teiltupel, d.h.
∀t∀t0 (t[X] = NULL ∨ t0 [X] = N U LL ∨
((∃A∈X (t[A]! ∨ t[A]!)) → t[X] 6= t0 [X]).
• DB2, Informix, Sybase, MS SQL, Ingres, SybaseAnywhere definieren dagegen
∀t∀t0 (t[X] 6= t0 [X]) .
Realisierung:
• RESTRICT für Insert und Update bei card(RHS, LHS) = (0, 2) in der Relation EingeschriebenIn
ALTER TABLE EingeschriebenIn ADD CONSTRAINT
CHECK(NOT EXISTS(
SELECT * FROM EingeschriebenIn E1,
WHERE EXISTS(
SELECT * FROM EingeschriebenIn E2
WHERE E1.StudMatrNr = E2.StudMatrNr
AND E1.SName <> E2.SName
AND EXISTS(
SELECT * FROM EingeschriebenIn E3
WHERE E3.StudMatrNr = E2.StudMatrNr
AND E1.SName <> E3.SName
AND E2.SName <> E3.SName))));
Analog mit Schachtelung der Tiefe b + 1 für card(RHS, LHS) = (0, b).
Besser ist in diesem Fall sogar die Einführung eines Surrogat-Schlüssels für die Relation
EingeschriebenIn, weil bei komplexeren Schlüsseln die Bedingungen E1.SName <> E3.SName
dann um den gesamten Schlüssel von EingeschriebenIn erweitert werden müssen.
Relationale Integritätsbedingungen: Relationale Integritätsbedingungen werden auf der Basis der relationalen Algebra formuliert.
Unter der Menge der möglichen relationalen Integritätsbedingungen sind zwei Klassen besonders zu beachten,
da sie in der Modellierungspraxis recht häufig benötigt werden:
Inklusionsbeziehungen: Durch Inklusionsbeziehungen werden statische Beziehungen zwischen Objekten in
der Datenbank beschrieben. Ihre Transformation kann, wie in den vorherigen Fällen, in Trigger oder Ausnahmen erfolgen. Da die beiden Transformationen ineinander überführbar sind, wird hier im folgenden
nur die Transformation in eine Ausnahme betrachtet.
CREATE ASSERTION R inc S
CHECK (
NOT EXISTS (
SELECT * FROM R
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
264
WHERE NOT EXISTS (
SELECT S id
FROM S
WHERE S.Y1 = R.X1, . . . , S.Yk = R.Xk
)
)
)
Bei mehreren Inklusionsabhängigkeiten zwischen R und S muss der Name der Ausnahme mittels einer
Nummer erweitert werden.
Es sollen u.a. Bedingungen der Daten untereinander abgebildet werden. Typische Beispiele sind Beschränkungen über Kalenderdaten oder referentielle Integritätsbedingungen wie z.B.
CREATE TABLE EingeschriebenIn (
StudMatrNr
char[7]
CHECK(
StudMatrNr IN (SELECT MatrNr FROM Student)
),
...
Bis
date
CHECK ( Von < Bis )
PRIMARY KEY (SName, StudMatrNr)
);
Exklusionsbeziehungen: Die Exklusionsbeziehungen werden analog zu den Inklusionsbeziehungen in eine
Ausnahme transformiert. Hierzu ist zu prüfen, das es kein Element in R gibt, zu dem ein passendes
Element in S existiert. Dies wird durch den SQL Ausdruck
CREATE ASSERTION R_exclus_S
CHECK (
NOT EXISTS (
SELECT * FROM R
WHERE EXISTS (
SELECT S id
FROM S
WHERE S.Y1 = R.X1, . . . , S.Yk = R.Xk
)
)
)
comp(R, Ri ) = (m, n)
CREATE TRIGGER comp_R_i_R_insert
AFTER INSERT ON R_i
REFERENCING NEW TABLE inserted
WHEN ( ( SELECT COUNT(*) FROM R, inserted
WHERE R.R i = inserted.R_i_id ) < m ) OR
( SELECT COUNT(*) FROM R, inserted
WHERE R.R_i = inserted. R_i_id ) > n ) )
ROLLBACK TRANSACTION
CREATE TRIGGER comp_R_i_R_update
AFTER UPDATE OF R_i id ON R_i
REFERENCING NEW TABLE inserted
REFERENCING OLD TABLE deleted
WHEN ( ( SELECT COUNT(*) FROM R, deleted
WHERE R.R_i = inserted.R_i_id ) < m ) OR
( SELECT COUNT(*) FROM R, inserted
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
WHERE R.R_i = inserted. R_i_id ) > n ) )
ROLLBACK TRANSACTION
CREATE TRIGGER comp R_R_i_insert
AFTER INSERT ON R
REFERENCING NEW TABLE inserted
WHEN ( ( SELECT COUNT(*) FROM R_i, inserted
WHERE inserted.R_i = R_i. R_i_id ) < m ) OR
( SELECT COUNT(*) FROM R, inserted
WHERE inserted.R_i = R_i. R_i_id ) > n ) )
ROLLBACK TRANSACTION
CREATE TRIGGER comp_R_R_i_update
AFTER UPDATE OF R_i ON R
REFERENCING NEW TABLE inserted
REFERENCING OLD TABLE deleted
WHEN ( ( SELECT COUNT(*) FROM R_i, deleted
WHERE deleted.R_i = R_i.R_i_id ) < m ) OR
( SELECT COUNT(*) FROM R_i, inserted
WHERE inserted.R_i = R_i. R_i_id ) > n ) )
ROLLBACK TRANSACTION
CREATE TRIGGER comp_R_R_i_delete
AFTER DELETE ON R
REFERENCING OLD TABLE deleted
WHEN ( ( SELECT COUNT(*) FROM R_i, deleted
WHERE deleted.R_i = R_i.R_i_id ) < m ) )
ROLLBACK TRANSACTION
2.10.4 Compiler-Zugang
Abbildung 61: Übersetzungsphasen eines Mehrpaßcompilers
Die Umgebung eines Compilers.
IS ADD
265
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
266
Präprozessor: Der Präprozessor wird vom Compiler aufgerufen und hat die Aufgabe Makros5 zu ersetzen. Falls
das Programm aus mehreren Quelltexten besteht, ist er außerdem dafür zuständig, die verschiedenen Teile
zusammenzusetzen.
Compiler: Der Compiler erhält seine Eingabe, den Quellcode, vom Präprozessor und übersetzt diesen Code in eine
Zielsprache: Assembler- oder Maschinencode. Auf die Arbeitsweise des Compilers wird später genau eingegangen.
Assembler: Es gibt Compiler, die Assemblercode ausgeben und an den Assembler weitergeben. Dieser erzeugt
dann einen verschiebbaren Maschinencode, indem er Assemblerbefehle in Maschinenbefehle transformiert,
symbolischen Namen (z.B. Labels) Maschinenadressen zuweist und ein Objektprogramm6 erzeugt.
Binder: Der Binder hat die Aufgabe, Objektprogramme aus verschiedenen Dateien (aus verschiedenen Übersetzungen oder systemeigene Bibliotheksdateien) in verschiebbarem Maschinencode zu einem Programm zusammenzufassen und die Querverweise7 und externen Referenzen8 aufzulösen.
Lader: Der Lader fordert entsprechend der Größe des Programms Speicherbereich vom Betriebssystem an. Anschließend lädt er das Programm in diesen Bereich im Arbeitsspeicher, ersetzt die verschiebbaren Adressen
durch nicht verschiebbare absolute Adressen und startet das Programm. Häufig sind Binder und Lader zu einem sogenannten Bindelader zusammengefasst, der dann sowohl die Aufgaben des Binders als auch des Laders
übernimmt.
Abbildung 62: Übersetzungsphasen eines Mehrpaßcompilers
Compilerarten.
Die Mächtigkeiten von Quell- und Zielsprache können unterschiedlich sein, daher werden Compiler wie folgt klassifiziert:
Compiler: Die Quellsprache ist mächtiger als die Zielsprache, z.B. der Compiler gcc, welcher einen C-Quelltext in
Maschinensprache übersetzt.
5
Makro: Zusammenfassung von Befehlen zu einer mit einem Befehl ansprechbaren Einheit
Objektprogramm: maschinenunabhängiger Zwischencode, in dem unter anderem vorbesetzte Bibliotheken vorliegen
7
Querverweise - hier: symbolische Verweise, die in anderen Programmteilen definiert sind
8
externe Referenz - hier: noch nicht aufgelöste Bezeichner, die z.B. in Bibliotheken definiert sind
6
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
267
Decompiler: Die Zielsprache ist mächtiger als die Quellsprache.
Präcompiler: Quell- und Zielsprache haben etwa die gleiche Mächtigkeit, deshalb wird ein Präcompiler auch 1-1Compiler genannt, z.B. der Präprozessor vom gcc Compiler unterscheiden sich nicht nur in Mächtigkeit von
Quell- und Zielsprache sondern auch in Konstruktion und Verwendungszweck:
Ein-Pass-Compiler: Er benötigt nur einen Arbeitsgang, um den Quelltext in den Zielcode zu übersetzen.
Mehr-Pass-Compiler: Zunächst wird der Quellcode von einem Präcompiler bearbeitet und anschließend vom Compiler in die Zielsprache übersetzt. Hier sind folglich mehrere Arbeitsgänge für die Übersetzung erforderlich.
Compiler-Compiler: Ein Compiler-Compiler erhält die Beschreibungen für zwei Programmiersprachen und gibt
anschließend einen Übersetzer (Compiler) von der einen in die andere Sprache aus. Er wird auch Compilergenerator genannt
optimierender Compiler: Dieser Compiler optimiert ein Programm bezüglich Laufzeit und Speicherbedarf, er verändert
jedoch nicht den Inhalt des Programms.
Native-Code-Compiler: Der erzeugte Code ist auf dem System lauffähig, auf dem auch der Compiler das Programm
übersetzt hat.
Cross-Compiler: Soll das Programm auf einem Rechner B ausgeführt werden, kann aber nicht auf B compiliert
werden (z.B. Mikrocomputer), benötigt man einen Cross-Compiler, der auf einer anderen Maschine A das
Programm übersetzt. Cross-Compiler ermöglichen also die Übersetzung für andere Rechnerarchitekturen.
Just-In-Time-Compiler: Von einem Compiler wird zuerst aus dem Quellcode ein plattformunabhängiger Zwischencode erstellt. Dieser wird dann zur Laufzeit des Programms von einem Just-in-Time-Compiler Stück für Stück
umgewandelt, prozessorspezifisch optimiert und ausgeführt. Eine aufwendige Optimierung hätte allerdings
eine negative Auswirkung auf die Ausführungszeit. Der Zwischencode wird also nicht interpretiert sondern
unmittelbar vor seiner Ausführung compiliert, dadurch ist der Just-in-Time-Compiler sehr schnell.
Übersetzungsphasen eines Compilers.
Während der Übersetzung durchläuft ein Quelltext verschiedene Phasen des Compilers: die lexikalische, syntaktische9 und semantische10 Analyse, die Zwischencodeerzeugung, die Codeoptimierung und schließlich die Codegenerierung. Diese Phasen lassen sich unterschiedlich zusammenfassen. Zum Einen in die Analysephase und die
Synthesephase (s. Abb.), zum Anderen in Front-End und Back-End. Das Front-End besteht aus den Phasen, die von
der Quellsprache und nicht von der Zielsprache abhängen, also aus der Analysephase, Zwischencodeerzeugung und
teilweise der Optimierung. Zum Back-End gehören die Phasen, die sich auf die Zielmaschine beziehen, wie teilweise
die Codeoptimierung und die Code-Erzeugung.
Oft entfällt die Synthesephase und der vom Compiler nach der Analyse erzeugte Zwischencode wird von einem
Laufzeitsystem11 , das eigene Datenstrukturen verwaltet, direkt interpretiert.
• Analysephase
• Lexikalische Analyse
Die lexikalische Analyse wird vom sogenannten Scanner durchgeführt, ist für die Bearbeitung des Quelltextes zuständig und liefert dem Parser einen Strom von Token. Bei der Bearbeitung des Quelltextes filtert der Scanner Leerzeichen, Leerzeilen und Kommentare heraus, wertet die Konstanten aus, überprüft,
9
Syntax: Festlegung, welche Zeichenfolgen als Programme zugelassen sind
Semantik: Festlegung, welche Auswirkung die Ausführung des Programms auf einem Rechner hat
11
Laufzeitsystem: System, das alle zur Ausführung eines Programms nötigen Routinen zur Verfügung stellt, wie Speicheranforderung,
Fehlerroutinen, Interaktion mit dem Betriebssystem
10
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
268
Abbildung 63: Analysephase eines Mehrpaßcompilers
ob alle Zeichen aus dem Zeichenvorrat der Quellsprache sind und erkennt Grundsymbole und Token.
Des weiteren ist das Nachladen weiterer Source-Dateien, die in C zum Beispiel über die #includeAnweisung angegeben werden, eine Aufgabe der lexikalischen Analyse. Der Scanner arbeitet auf der
Basis eines deterministischen Automaten
Erkennt der Scanner ein gelesenes Symbol bzw. eine Symbolteilfolge, wird anhand einer Symboltabelle
festgestellt, ob dieses Lexem11 irgendwann schon einmal vorkam. Ist dies nicht der Fall, so wird ein
neuer Symboltabelleneintrag erzeugt und dem Symbol als Attribut einen Verweis auf den entsprechenden
Eintrag in der Symboltabelle angefügt.
• Syntaktische Analyse
Die syntaktische Analyse wird vom Parser12 durchgeführt. Seine Aufgaben sind es, die syntaktische
Struktur des Programms entsprechend der Grammatik der Programmiersprache zu erkennen, Syntaxfehler zu entdecken und den Ableitungsbaum zu erstellen. Letzterer wird aus den grammatikalischen Grundkomponenten erstellt, deren Beziehung untereinander durch die Verbindungen der einzelnen Knoten im
Baum dargestellt werden. Grundsätzlich gibt es zwei verschiedene Arten von Parsern, die Top-downParser und die Bottom-up-Parser. Der Top-down-Parser betrachtet zuerst das Programm als Ganzes und
zerlegt dieses dann bis in seine grammatikalischen Grundkomponenten. Der Bottom-up-Parser beginnt
mit der Analyse der grammatikalischen Grundkomponenten und baut hieraus das Programm auf. In jeder
Programmiersprache gibt es Regeln wie z.B. eine Schleife, eine Bedingung oder eine Zuweisung aufgebaut sein müssen, ob Variablen vor ihrem ersten Zugriff deklariert werden müssen usw. Wird gegen eine
dieser Regeln verstoßen, startet der Parser eine Fehlerbehandlung. Um bei einem Compiler-Durchlauf
möglichst viele Fehler entdecken und melden zu können, bricht der Parser nach einem Fehler seine Analyse nicht ab, sondern überliest die nachfolgenden Zeichen bis zu einem synchronisierenden13 Symbol
und setzt seine Arbeit dort fort. Der Parser arbeitet auf Basis eines Kellerautomaten, dessen Aufgabe
es ist, Anfang und Ende von geschachtelten Konstruktionen zu erkennen. Dieser Automat hat endlich
viele Zustände und besitzt als Speicher für die einzelnen Zeichen einen stack. Abhängig vom Eingabezeichen, vom aktuellen Zustand und vom obersten Kellersymbol wechselt der Automat seinen Zustand und
verändert die Kellerspitze.
• Semantische Analyse
Die semantische Analyse baut auf den Ergebnissen der syntaktischen Analyse auf. Im Wesentlichen finden drei Überprüfungen statt, nämlich die Typ-, die Eindeutigkeits- und die Gültigkeitsprüfung. Die Typprüfung basiert dabei auf dem Typ-System der Quellsprache, welches definiert, wie bestimmte Typen
12
engl. to parse: zerlegen
synchronisierendes Symbol: abschließendes Zeichen von grammatikalischen Komponenten (wie Deklarationen und Anweisungen), Beispiel: ; in C
13
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
269
in Ausdrücken verwendet werden dürfen und welchen Typs das Resultat zu sein hat. In C würde eine
arithmetische Verknüpfung zweier int-Variablen zum Beispiel ein Ergebnis wiederum vom Typ int zur
Folge haben. Die statische Typprüfung wird während des Kompilierens durchgeführt, kann jedoch nicht
garantieren, dass es zur Laufzeit nicht zu Typfehlern kommt.
Prinzipiell ist aber, falls Typ und Wert eines Elements auch in der Zielsprache bekannt sind, die sogenannte dynamische Typprüfung ausreichend. Sie findet zur Laufzeit des Programms statt. Die semantische
Analyse überprüft jedoch nicht nur die Typen sondern sammelt auch Typinformationen, um mit ihnen sowohl die Symboltabelle als auch den Ableitungsbaum aus der syntaktischen Analyse durch Attribute zu
erweitern. Erste Ergebnisse der semantischen Analyse sind also ein attributierter Ableitungsbaum sowie
eine erweiterte Symboltabelle. Im attributierten Ableitungsbaum werden die syntaktischen Komponenten von der Wurzel bis zu den Blättern, die die grammatikalischen Grundkomponenten enthalten, immer
weiter verfeinert. Die dann folgenden Eindeutigkeits- und Gültigkeitsprüfungen dienen schließlich zur
Vorbereitung auf die Codeerzeugung, indem beim Durchlaufen des Ableitungsbaumes den Variablen und
Konstanten bereits relative Adressen zugewiesen werden und des weiteren die eigentliche semantische
Richtigkeit überprüft wird. Darunter fällt zum Beispiel die Überprüfung von Indexgrößen, von Argumentenanzahl und -typ bei Funktionsaufrufen sowie von Typkonformität beiderseits einer Anweisung. Auch
hier wird, wie bei den vorigen Phasen, im Fehlerfall die Analyse nicht abgebrochen, damit die Fehlerausgabe am Ende des Compiliervorgangs möglichst vollständig ist.
Attributierte Grammatiken A = (G, V, F ) sind durch eine kontextfreie Grammatik G, Attribute V und Attributzuweisungen F bestimmt. So kann z.B. für die kontextfreie Grammatik mit den Regeln
N → S 00 .00 S
S → SB
S → B
B → 00 000
B → 00 100
eine Ergänzung um den Scale-Faktor f , den Wert v und die Länge l vorgenommen werden, so daß dann für
eine Werteweitergabe nach unten ↓ bzw. nach oben ↑ im Baum die folgende attributierte Grammatik entsteht:
[v = v1 + v2 ; f1 = 1; f2 = 2−l2 ]
N ↑ v → S ↓ f1 ↑ v1 ↑ l1 00 .00 S ↓ f2 ↑ v2 ↑ l2
S ↓ f ↑ v ↑ l → S ↓ f1 ↑ v1 ↑ l1 B ↓ f2 ↑ v2
[v = f1 · v1 + f2 · v2 ; f1 = 2f ; f2 = f ; l = l1 + 1]
S ↓f ↑v↑l → B ↓f ↑v
[l = 1]
B ↓ f ↑ v → 00 000
[v = 1]
B ↓ f ↑ v → 00 100
[v = 1]
Wir erhalten damit für die Ableitung von 11.01 = 3 14 den folgenden Ableitungsbaum:
N
S; l=2
S; l=2
S; l=1
B
S; l=1
B; l=1
1
B
1
N; v = 3 14
N
0
B
1
S; f = 1
S; f =
S; f=2 B; f=1 S; f =
B; f=2
1
1
B; f =
0
IS ADD
1
2
1
2
S; v=3
1
4
B; f =
1
1
4
S; v =
S; v=2 B; v=1 S; v=0
B; v=1
1
1
B; v=0
0
1
4
B; v=1
1
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
270
• Synthesephase
• Zwischencodeerzeugung
Nach der Analyse und somit als Ende des Front-Ends wird eine maschineneunabhängige Form des Quellprogramms aus den Zwischendarstellungen der vorherigen Phasen erzeugt. Dies ist vorteilhaft, falls das
Programm auf eine andere Maschine portiert wird, denn dann muss ausgehend vom Zwischencode lediglich die Codeerzeugungsphase erneut ausgeführt werden. Ein Zwischencode erleichtert also die Weiternutzung für ähnliche Zielsprachen. Voraussetzung ist allerdings, dass die Zwischensprache leicht erzeugt
werden kann und ebenso leicht in die eigentliche Zielsprache übersetzbar ist. Häufig bietet sich dazu der
sogenannte Drei-Adress-Code an. Nach einer eventuell notwendigen Aufteilung in Teilanweisungen wird
das gesamte Programm in diesem Code in Instruktionen implementiert, die jeweils eine Zuweisung sind,
außer dem Zuweisungsoperator höchstens einen weiteren Operator enthalten dürfen und insgesamt aus
maximal 3 Operanden bestehen. Gegebenfalls werden dazu zusätzliche, temporäre Variablen erzeugt.
• Codeoptimierung
Die Codeoptimierung bildet nicht immer eine eigene Phase, da sie meistens in die letzte Phase, die Codegenerierung, integriert ist. Es können jedoch immer zwei Arten der Codeoptimierung unterschieden
werden, nämlich zum Einen die maschinenabhängige und zum Anderen die maschinenunabhängige. Die
maschinenabhängige Codeoptimierung konzentriert sich, wie schon der Name sagt, auf eine Verbesserung des Zielcodes hinsichtlich der Zielmaschine. Es wird versucht, Eigenschaften der Zielmaschine
auszunutzen, so dass zum Beispiel eine ganzzahlige Multiplikation mit 2 durch Shift-Operationen realisiert, bestimmte Befehle der Zielmaschine genutzt oder auch die Nutzung von Registern hinsichtlich
weniger Rechenzeit verbessert werden. Die maschinenunabhängige Codeoptimierung hingegen lässt die
Eigenschaften der Zielmaschine außen vor und ist dafür zuständig, die Qualität des Zwischencodes zu
verbessern, dabei aber die Funktionalität zu erhalten. In diesem Zusammenhang kann wieder eine Unterscheidung statt finden und zwar die der Übersetzungs- und der Codeoptimierung an sich. Erstere bemüht
sich die Übersetzungszeit möglichst gering zu halten, dabei aber trotzdem eine umfangreiche Fehlerprüfung durchzuführen. Die Codeoptimierung erstellt derweil ein Zielprogramm, das wenig Rechenzeit
sowie wenig Speicherplatz in Anspruch nimmt. Dazu wird zum Beispiel “passiver” oder ”nicht erreichbarer” Code entfernt , Operationskosten eingespart, indem “teure” Operatoren durch “günstige” ersetzt
werden, oder konstanter Code aus Schleifen herausgezogen.
Typische Schritte bei der Codeoptimierung sind:
• einfache Optimierung z.B. algebraische Vereinfachungen, Konstantenfaltung, Unterdrücken von Laufzeitprüfungen
• Entfernen gemeinsamer Teilausdrücke
• Fortpflanzung von Zuweisungen
• Schleifeninvarianter Code
• Befehlsanordnung
• Registerzuordnung
• Codegenerierung
Im letzten Schritt wird aus dem vorher optimierten Zwischencode der entgültige Zielcode erzeugt, der
meistens aus verschiebbarem Maschinen- oder seltener aus Assemblercode besteht. Es werden nun also
ëchte”Befehle erzeugt, was bedeutet, dass jede Zwischencodeanweisung in eine gleichwertige Folge von
Maschinenbefehlen übersetzt wird und den Programmvariablen verschiebbarer Speicherplatz zugeordnet
wird.
Typische Schritte bei der Codegenerierung sind:
• Erhebung der Eigenschaften der Zielmascheine
• Coderzeugung für Ausdrücke
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
271
• Coderzeugung für Anweisungen
• Coderzeugung für Prozeduren
• Objektdatei, die durch den Binder später zusammengeführt werden kann
Verfahren der Compilerentwicklung (Wie baut man einen Compiler?) .
Das Bootstrapping-Verfahren Ein Compiler ist nicht nur durch Quell- und Zielsprache gekennzeichnet, sondern
auch noch durch die Implementierungssprache des Compilers, das ist die Programmiersprache, in der der
Compiler geschrieben wurde und wird deshalb auch Basissprache des Compilers genannt. Diese drei Sprachen werden in einem sogenannten T-Diagramm dargestellt.
Abbildung 64: Bootstrapping Verfahren eines Mehrpaßcompilers
Compiler haben zwei für den Compilerbau wichtige Eigenschaften:
1. Wie viel Speicherplatz braucht der Compiler und wie schnell ist er?
2. Wie schnell sind die durch den Compiler erzeugten Programme und wie viel Speicherplatz brauchen sie?
In einem T-Diagramm wird dann an der entsprechenden Stelle je nach Eigenschaft ein Plus- oder ein MinusZeichen notiert.
Abbildung 65: T-Diagramm des Bootstrapping-Verfahren
Compilerbau-Werkzeuge: Für eine Programmiersprache kann es verschiedene Compiler geben, wie für C zum Beispiel den Borland Compiler, den gcc usw. Für ein und dieselbe Programmiersprache müssen alle Scanner und
Parser der Compiler immer nach den gleichen Regeln arbeiten. Deshalb ist es nützlich Scanner und Parser beim
Compilerbau nicht immer neu generieren zu müssen, sondern Funktionen zur Verfügung zu haben, die die Implementierung dieser Routineaufgaben erleichtern. In diesem Zusammenhang sind besonders die kostenlosen
Tools Lex als ein Scanner-Generator und Yacc als ein Parser-Generator zu nennen. Sie finden sowohl unter
UNIX/Linux als auch unter Windows Verwendung und können Scanner und Parser für C/C++, Java, Pascal
usw. generieren.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
272
Fehlerbehandlung.
Lexikalische Fehler werden durch Verletzungen der Syntax hervorgerufen. Die Fehlerart wird zusammen mit der
Position des fehlerhaften Symbols gemeldet. Die fehlerhaften Symbole werden trotzdem an den Syntaxanlysator weitergegeben.
Fehlerbehandlung in der Syntaxanalyse analog zum recovery realisierbar
Verfahren
Panikmodus für rekursiven Abstieg: Die Syntaxanalyse wird abgebrochen.
Wiederaufsatz mit allgemeinen Fangsymbolen für rekrsiven Abstieg: Tritt ein Syntaxfehler auf, wird der Symbolstrom solange überlesen, bis ein Symbol auftritt, das an der Fehlerstelle erwartet wurde oder das
Nachfolger eines in Arbeit befindlichen Nichtterminalsymboles ist. Mit diesem Symbol wird die Analyse fortgesetzt.
Wiederaufsatz mit speziellen Fangsymbolen für rekrsiven Abstieg: Es werden spezielle Symbole ausgezeichnet, mit denen ein Wiederanfahren oder eine Fortsetzung einfach möglich ist.
Fehlerbehandlung bei tabellengesteuerter Top-Down-Analyse: meist durch allgemeine Fangsymbole
Fehlerbehandlung bei tabellengesteuerter Bottom-Up-Analyse: meist durch allgemeine Fangsymbole
Fehlerbehandlung in der Semantikverarbeitung:
Fehlerbehandlung während der Optimierung:
Fehlerbehandlung während der Codeerzeugung:
Qualitätskriterien.
Sowohl für die Transformation als auch die Compilierung wird strukturelle, semantische und funktionelle Korrektheit
gefordert. Die Korrektheit muß auch beweisbar sein. Dies ist jedoch selbst für einfache Klassen von Integritätsbedingungen wie die Menge der Kardinalitätsbedingungen {(0, 1), (1, 1), (1, n), (0, n)} bereits nicht mehr gegeben, da
damit auch Inklusions- und funktionale Abhängigkeiten ausgedrückt werden können. Diese Menge ist jedoch nicht
axiomatisierbar. Damit kann auch die semantische Korrektheit von Transformationen nicht bewiesen werden. Deshalb
ist eine Compilierung für Datenbankschema nur in Teilfällen möglich. Damit ist unser Ziel eine Transformationstechnik, die sowohl den Korrektheitsforderungen genügt als auch Optimierungstechniken einschließt (Optimierender
Transformer). Einen Teilschritt haben wir bereits mit der Normalisierung von Schemata in HERM-Normalform vorgenommen.
Die hier vorgestellten Transformationstechniken sollten Qualitätkriterien genügen:
• Der Transformationsprozeß sollte einfach sein.
• Der Transformationsprozeß sollte die Strukturen im wesentlichen erhalten.
• Der Transformationsprozeß sollte die Eigenschaften der unterlegten Implementationstechnologie unterstützen.
Insbesondere im Falle des relationalen Modelles als logisches Modell sollte durch die Transformation die
Einfachheit, Pruduktivität und Flexibilität erhalten bleiben.
• Der Transformationsprozeß sollte weitestgehend unabhängig vom gewählten Datenbank-Management-System
sein. Das bedeutet nicht, daß die gewählte Plattform eine Berücksichtigung finden sollte. Da mit einer Änderung
von Versionen stets zu rechnen ist, sollte man die Transformation und damit auch das physische Schema nicht
zu stark an die Version koppeln.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
273
• Der Transformation sollte daten-orientiert und weniger prozeß-orientiert angelegt sein. Eine Reihe von Tuningtechniken lassen sich konzeptionalisieren wie im folgenden gezeigt wird. Darauf aufbauend können die
Performanzprobleme direkt in den Entwurf einbezogen werden.
2.10.5 Compilation von HERM-Schemata
Vorsicht: Vorgriff auf Funktionalität aufgrund der notwendigen Optimierung
Schwierigkeiten und Fallen:
1. Man muß den Unterschied zwischen Primärschlüssel, Primärindex und primärer Zugriffsmechanismus klar
herausstellen. Der Primärschlüssel ist ein Instrument zur Pflege der Integrität von Daten. Es werden die
beiden anderen Begriffe nicht impliziert. Der Primärindex kann verschiedenste Verwirklichungen haben.
Noch unterschiedlicher ist der Zugriffsmechanismus. Er ist der meist aus Performanzgründen favorisierte Zugriffsmechanismus. Er kann auf dem Primärschlüssel beruhen, kann aber auch auf einen anderen
Schlüssel oder sogar auf einen künstlichen Schlüssel wie dem Tupelidentifikator beruhen.
2. Mit nullwertigen Attributtypen sind nicht alle Auswertungsoperationen mit der gleichen Semantik versehen. Da der Vergleich von Daten in diesem Fall zum Wert wahr, falsch oder unbekannt führen kann,
sind für Nullwerte zusätzlich die Auswertungsoperationen (z.B. Operationen der relationalen Algebra oder
Aggregationsoperationen) zu betrachten. Hinzu kommt, daß verschiedene Plattformen mit Nullwerten auf
unterschiedliche Art und Weise umgehen. Eine zusätzliche Programmierung von weiteren Operatoren kann
nur eine teilweise Lösung bieten.
Begründung der Notwendigkeit.
• Verlust des Zusammenhanges zum konzeptuellen Schema nach Transformation im klassischen Zugang, insbesondere nach Denormalisierung
• zu uniforme Übersetzung, jeder Typ muß eigentlich mit seiner Option laufen, dies ist aber zu schrecklich zum
Spezifizieren, erfordert dann Handarbeit
• Trigger-Generierung geht meist schief, muß dann per Hand nachgearbeitet werden; wer beherrscht diese Aufgabe?
• ohne Berücksichtigung der Funktionen
Wissenschaftlicher Hintergrund: Der ETL-Prozeß.
ETL: Extract-Transform-Load
• anstatt des klaasischen Interpreter-Zuganges
• mit Integration des Profiles und des Portfolio
• sowie ERzwingungsprofil für Integritätsbedigungen
einschließlich der berücksichtigung des diamond problems
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
274
Abbildung 66: The Kiel approach to performance forecasting: Parameter zur Erhebung der DBMS-Performanz
c1 c2 {Si (c̄, p̄)|1 ≤ i ≤ m}
...
cn 6
p1 6
p2
...
o1 o2 ...
om -
6
pl
Abbildung 67: The general model for performance forecasting
Abbildung 68: The Kiel approach to performance forecasting: Der Synergetik-Zugang
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
275
Abbildung 69: The Kiel approach to performance forecasting: Auswahloberfläche des Prototyps
Abbildung 70: The Kiel approach to performance forecasting: Auswahl der CPU-Analyse
Abbildung 71: Comparing the prediction with the real behaviour
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
276
Erfahrungs: Explizite Berücksichtigung des Performanz-Profiles und -Portfolio.
Beispiel von ETL: Beyond SQL Querying (Not trapped into the SQL trap).
-
??
user
in thehelp !!
help !!
DBMS trap
Tina Musterfrau,
casual
user
6
6
?
Search
request
topic
: welt
concepts
?
search
concept
?
result
concept
parametric
HERM
expressions
?
relational
database
schema
?
?
- query
- SQL ¾
-answer
SQL query ¾
set
form
form
?
? )
answer
for search
query
interface
query
data
base
q
DBS
DBMS query
representation
Abbildung 72: Concept-Based Query Processing Instead Of Direct SQL Querying
Three-Step Approach to SQL Query Generation
The Cottbus Intelligent NL Request Transformer
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
277
Generation of SQL query candidates based on full information
Ontology / WordNet /
thesaurus
Relational
database
content
NL
utterance
Database schema
in extended
ER model
z
?
z
? 9
z
?
Proper name
candidates
Enriched syntax
tree
Translation style
used for compilation
of relational schemata
from HERM schemata
Priority-ordered paths
in the extended ER schema
z
9
priority-ordered set of SQL query candidates
Abbildung 73: Three-step Approach to SQL Query Generation
Query
Liquefaction
W ORD
N ET
O NTO LOGY
R
RADD
DB Design
Tool
Syntactical
Analysis
? µ
NL query
¾
Syntax
tree
?
6
DB
Schema
Manager
R
*
Intelligent
Path
Extractor
?
(e)ER
Schema
Paths in
ER Schema
?
ER2R
Translation
Style
Relational
Query
Melting-Pot
-
- Paths and
SQL queries
-
6 I
DBMain
DB Design
Tool
Web Input
?
DB
Thesaurus
Manager
?
ISL
¾
Web
Presenter
...
Database
Database
¾
- Managem. ¾
System
DB2Web
System
¾
-
Abbildung 74: The Cottbus Intelligent NL Request Transformer
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
Abbildung 75:
ab SS 2012
Das Vorlesungsplanungsbeispiel zur Illustration
IS ADD
278
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
Which lectures are given by Vierhaus and Thalheim?
IS ADD
279
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
280
The Trick Behind the Curtain: Media Types for Specification of Content
• Raw media types = (cont(M ), sup(M ), view(M ), op(M ))
content type cont(M ), set of supertypes sup(M ),
view(M ) = Q (Sinp , Soutp )
generic functions op(M ) for changing the database
• Attached operations: (signature, selection type, body)
selection type - supertype of cont(M )
e.g. generalization/specialization, reordering, browsing, linking, surveying, searching, join
• Media type: raw media type + unit extension
+ order extension + cohesion/adhesion + hierarchical versions
• Usage modeling: usage dimensions, scales, user profiles, user kind
• Container = (cont(C), layout(C), kind(C))
for shipping and representation
IS ADD
HERM view
CAU zu Kiel, IfI, ISE, β
HERM-Compiler 0.
2. Strukturierung von IS
ab SS 2012
281
Konfiguration des HERM-Übersetzers.
Kanonische Spezifikation von Typen
T
relationaler Typ
R attr(R) keySyst(R)
....
...
• “abgebogene”
Constraints
comp(T)
....
HERM-Typ
keySyst(T)
...
integr(T) ΣT
...
Listen-Typ
XML multilist(L)
....
ΣR
...
keySyst(L)
...
integr(T) ΣL
...
• ΣL als refStructure mit expliziter variabler Listensemantik
innere
• hier auch expliziter Stil
eg., “Russian doll” oder auch “Venetian
blind” oder auch “Salami slice”
• domain constraints
• constrained references
DBMS-Profil z.B. 80er Jahre
• atomare Attribute
• primary key - entity integrity rule / assumption
• rudimentäre domain constraints
• domain-key-NF als die präferierte NF
wobei auch viele Einschränkungen hinzukommen z.B. INT4 als Typ
• Index-Strukturen
oder auch DBMS der 90er
• domains als UDT’s
• automatische ID als TID
oder auch XML oder semistructured DBMS
• rationale Bäume mit expliziter Führung der Referenzen
• semantically meaningful units # overlay structure with units
Architektur des Systemes mit einigen expliziten Annahmen z.B.
• Integritätspflege über Schnittstellen z.T.
• nur über stored procedures werden interfaces gefildet
• ...
Unterstützung der Integritätspflege
Typensystem ist
• mengenbasiert
• multimengenbasiert
• listenbasiert
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
282
Complex attributes mit Default-Einstellung
• Flattening z.B. zum String-Datentyp
• Wurzel-Attribute
• Separates Schema
• Listen-Type
Hierarchies entweder mit dem event-separation oder dem union oder der Universal-Relationen-Annahme
Null value support je anch DBMS
Strong or weak semantics
Weak support as the normal case
Cluster mit/ohne Harmonisierung der Identifikation oder verallgemeinerter, angereicherter Integrität [Wan98]
Treatment of cardinality constraints
Inherent constraints
Controlled redundancy
Naming conventions
Abbreviation rules z.B. bei Erzeugung von .-Notationen
Portfolio-Aufnahme der Anwendung.
(DB − Schema, F unctionality, Support − Schema) mit
Functionality umfaßt auch: access portfolio und modification portfolio
modelliert am einfachsten als Überlagerungsschema
schema
× f unction
→
P(schema)
y.B. auch S × Q → query − subschema
mit DBschema × q → (DB − sub − schema, result − schema)
oder auch DBschema ∪ views × q → (DB − sub − schema, result − schema)
wobei auch Anfrageformen und Antwortformen verwendet werden können
Abgeleitete Übersetzungsoptionen.
analog zu den compiler directives (C, C++)
1. Hierarchien-Behandlung
2. kontrolleirte Redundanz
3. NULL support
4. Constraint enforcement insbesondere für
• ID und Integration
• cardinality constraints
• inherent constraints
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
siehe auch das vorgestellte enforcement profile and portfolio
nach den Jaakkola-Thalheim-Rahmenwerk
5. naming conventions
6. !!! Schattentypen
7. Mengen oder Pointer- oder hybride Semantik
8. explizite abgeleitete Attribute mit refresh-Funktion (Trigger, stored procedures, ...)
9. Separation der Integritätspflege
interface-basiert
TA-basiert
maintenance-based
10. orthogonale Schemata separat oder eingefaltet (z.B. Währung, Adresse mit PLZ,...)
11. Referenztypus: schlüsselbasiert oder reference based
12. identifier based treatment
Resultierendes Preprocessing.
1. Trennung von Defintions- und Nutzungsbaum
optional normalisiertes HERM-Schema mit IC-Anreicherung
Trick: Attribut-Graph-Schema
2. Pivoting von Nutzungstypen
siehe Vorlesungsbeispiel: inserted by ist separierbar
3. Reduktion ableitbarer Typen
4. explizite Injektion von impliziten ER-IC
uses constraints (based-on types)
5. Bereitstellung von Hilfskonstrukten
Transformationsobligationen Typus
...
...
HERM-Compiler 1.
Obligation
...
Lexikalische Analyse.
Resultat: Syntaxbaum und aufgelöste Token
als Beispiel: β-Schema nach Embley-Beispiel im Handbook, Kapitel 5, Bild 5.2.
ggf. auch mit bereits erfaßten interface-gepflegten IC
Aufteilung in Sinneinheiten
1. Ableitung eines kanonischen HERM-Schemas
Definitionstypen unabhängig in der Existenz, hin zu Kern-Entity-Typen
ER-Schema mit expliziten Existenzabhängigkeiten
2. FD-Umgebung eines Typen
auch unter Einbeziehung der Subtypen
i.a. nur erste Stufe erfoderlich
EnvF1 D = {T1 (...), .Tp (.....)}
IS ADD
283
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
284
3. Aufbau eiens Token-Waldes
Entfernung der Redundanz unter den Zeichen
Entfernung von Pragmas (processing directives)
HERM-Compiler 2.
Syntaktische Analyse.
Resultat: erweiterter Syntaxbaum, Baum der Integritätsbedingung
ggf. auch mit bereits erfaßten interface-gepflegten IC
Zusammenfassung zu Einheiten (Abletungsmechanismen dazu, auch unter Berücksichtigung der hierarchischen
Struktur)
d.h. von
T comp(T) keySyst(T) integr(T) ΣT
mit Env(T) = ∅
....
...
...
zu
T ∪ env(T) comp(T) ∪ foeignKeys(T) keySyst(T) integr(T) ΣT ∪ foreignKeyConstraints(T)
....
...
...
beachte auch mit Erzwingungsform
damit
1. Env(T)-Ermittlung
2. Auflösung der Compiler-Directives
• Hierarchien-Behandlung (union, root entity type, new attribute for each specilisation, cluster)
• redundancy
• NULL support
• enforcement style
• naming and binding
• shadow, set semantics, derived notions
• orthogonale Schemata, reference type, ID
HERM-Compiler 3.
Semantische Analyse.
Resultat: Schema korrekt, Schema erfüllbar
Ermittlung und Überprüfung der semantischen Eigenschaften
Verbesserung der Schemata
Typensystem für Dom(S) ggf. mit Überprüfungsmechanismen und Ableitung
Optionen für Optimierer
Steeg-Beispiel
Ableitung einer attributierten Grammatik
eiinschließlich azyklischer Attributierung
1. Ableitung der IC
2. Control of IC
3. Coherence of IC, e.g., diamond property
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
HERM-Compiler 4.
Zwischencodeerzeugung.
285
Resultat: Schema in der Zielsprache als logisches Schema
anhand von HERM Regeln
1. Auflösung der komplexen Attribut-Typen (Menge, Liste, Multimenge, Tupel, ...) zu (STRING, RECORD, separates Schema, Kodierung, Einmbettung in anderes Attribut)
2. mit expliziter Umgebungsintegration
von
T comp(T) keySyst(T) integr(T) ΣT env(T)
....
...
...
...
zu
T comp(T) ∪ primKey(T) keySyst(T) integr(T) ΣT ∪ foreignKeys(T)
....
...
...
Damit dann direkte Zwischencodeerzeugung
1. Ableitung von Hilfsstrukturen
Indizes, views, Schlüssel, ID-Types
2. Preschema
einschließlich der Mengengerüste, nullable attributes, default values
3. view derivation
4. index derivation
5. precedural components, trigger, stored procedures
Girokontokarte
¾
(1,1)
nutzt
L
-
berechtigt
^
Girokonto
¾
(1,1)
?
besitzt
R
-
Kunde
Abbildung 76: Ein einfache Bankanwendung mit alternativer relationaler Wiederspiegelung des Clustertypen
wird durch die explizite Einführung der Art der Girokontenkarte anstatt einer Einführung eines weiteren Relationentyps, mit dem die Kundenkarte des Berechtigten von der Kundenkarte des Inhabers unterschieden wird (Vorteil:
damit sind Kontobewegungen mit der Karte direkt der Karte zugeordnet)
Kunde KundenNr
Konto KontoNr KundenNr
IS ADD
CAU zu Kiel, IfI, ISE, β
Berechtigter
2. Strukturierung von IS
KundenNr
ab SS 2012
KontoNr
286
Kundenkarte
KartenNr
KontoNr
Art
Berechtigter[KundenNr] ⊆ Kunde[KundenNr]
Berechtigter[KontoNr,KundenNr] || Konto[KontoNr,KundenNr]
σArt=“direkt00 (Kundenkarte[KontoNr,KundenNr]) ⊆ Konto[KontoNr,KundenNr]
σArt=“berechtigt00 (Kundenkarte[KontoNr,KundenNr]) ⊆ Berechtigter[KontoNr,KundenNr]
Durch ein derartiges Herangehen kann dann auch aufNormalform-Garantien (siehe Embley spüter, translate &
normalise (im compiler) versus normalise & translate (im Preprocessor)) orientiert werden.
HERM-Compiler 5.
Vorbereitung zur Schema-Optimierung.
Ziel: Vermeidung überflüssiger oder schelchter Berechnungen
Ersetzung von Berechnungen durch billigere
Anpassung an die Hardware und Architektur
1. post normalisation
2. view optimisation
index optimisation
3. materialisation options
4. process separation into database phases
initialisation phase
production phase
archive phase
...
5. query etc. hints
Vorbereitung auf Performanzbetrachtungen
1. Kernentitytypen
Kernentitytypen stellen unabhängig voneinander existierende Klassen von Objekten dar. Ausgehend von Kernentitytypen werden Spezialisierungs- und Generalisierungshierarchien dargestellt. Damit wird festgelegt, welcher der Transformationszugänge (event-separation, event-nonseparation, union, weak-universal-relation) für
Hierarchien benutzt werden.
Die Reihenfolge der Attributtypen kann aus Performanzgründen verändert werden. Häufig benutzte bzw. Typen
mit Wertebereichen fester Länge sollten zuerst entworfen werden. Die Reihefolge hängt von der beabsichtigten
Plattform ab, deren Eigenschaften nun zu integrieren sind.
Attributtypen
Pragmatik:
Die Zuordnung der Transformationszugänge kann durch eine Betrachtung der Inklusionsabhängigkeiten vereinfacht werden. Liegen echte Inklusionsabhängigkeiten vor und keine ‘Geschwister’typen, dann liegt eine
Spezialiserungshierarchie für diesen Kerntypen vor.
Im Beispiel können wir die Typen Lehrstuhlinhaber, Dekan, Person und Angestellter betrachten. Es gilt keine Exklusionsbeziehung der ersten beiden Typen, aber eine Exklusionsabhängigkeit dieser beiden Typen zum
letzten Typen. Somit sind entweder die Typen Lehrstuhlinhaber, Dekan einem gemeinsamen Supertypen zugeordnet, der mit dem Typen Angestellter einen Kerntypen bildet, oder der Typ Person ist ein Kerntyp.
Analog sind zusätzliche Attribute ein Hinweis auf eine Eigenständigkeit der Teiltypen.
Hierarchien können kompakter gestaltet werden, sobald entsprechende Komplexitätsbeschränkungen comp(R, R0 ) =
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
287
(1, 1) gelten. In diesem Fall ist zu prüfen, ob eine Eigenständigkeit beibehalten werden muß aufgrund der Anwendung.
Da in der Modellierung aus bestimmten Gründen Entitytypen auseinander gehalten wurden, bleibt auch bei
einer automatischen Übersetzung diese Differenzierung erhalten. Sollte davon abgegangen werden für das physische oder logische Schema, dann liegt ein Modellierungsfehler auf der HERM-Ebene vor.
Für die spätere Übersetzung verwenden wir den Typennamen, die Typenbeschreibung, den Entwerfernamen,
Synonymbeziehungen, die Quelle (falls Daten durch Algorithmen generiert werden), die Häufigkeiten und andere quantitative Charakteristika. Daneben können die Behandlung von Backup und Wiedergewinnung, Reorganisationsparameter, Monitoringanforderungen, Sicherheitsbeschränkungen, Eliminationsbedingungen und
andere Parameter der Umgebung und der Plattform von Bedeutung sein. Ist dies noch nicht erfaßt oder kann
nicht aus den bereits entworfenen Informationen erschlossen werden, dann sind diese Informationen für die
entsprechenden Typen zu erfassen.
Da Plattformen meist beliebige Reihenfolgen von Attributen nicht unterstützen, ist die Reihenfolge explizit
festzulegen. Speicherblöcke, Fragmentierungszugänge können eine andere Reihenfolge implizieren.
2. Anpassung an die Plattform
Wir unterscheiden relationale, hierarchische und Netzwerkplattformen. Weiterhin können Plattformen nach ihrer Hardware (PC, Workstation, Mainframe) und der Architektur (Client/Server etc.) unterschieden werden.
Eine Transformation legt auch die Speicherzuordnung (Primärspeicher, Sekundärspecher, freier Speicher) für
Klassen fest. Durch die Kardinalität der Entitytypen wird diese Zuordnung mit bestimmt. Sie ist damit an die
Eigenschaften der Plattform gebunden, die nun explizit zu berücksichtigen ist. Ein Zugriff im Sekundärspeicher
ist meist weniger effizient. Deshalb sollte ausreichend Primärspeicher vorgesehen werden können. Ansonsten
ist eine horizontale Dekomposition vorzusehen.
Die Affinität von verschiedenen Entitytypen bedingt oft auch einen gemeinsamen Zugriff bzw. eine gemeinsame Modifikation. Sieht eine Plattform nur relativ kleine Teile einer Datenbank zur gemeinsamen Abspeicherung vor, dann ist durch die Affinität bereits eine Abspeicherungsstrategie determiniert. Für solche Plattformen
ist die Affinität mit zu modellieren.
Analog ist der parallele Zugriff verschiedener Benutzergruppen zu behandeln. In diesem Fall ist das gemeinsame Benutzen von Daten mit darzustellen.
Pragmatik:
Meist sind die Regeln für eine Plattform nur sehr schwer aus den Begleitdokumentationen abzuleiten. Eine
Abhilfe kann dann eine Benutzung von entsprechenden Entwurfshinweisen für die gewählte Plattform sein. Es
werden die Entwurfshinweise mit unserem liberaleren Zugang verglichen und die Unterschiede auf Implementationsbeschhränkungen untersucht.
3. Erzwingungsregeln für Entitytypen
Einige Plattformen erlauben nur eine Erzwingung über Primärschlüsseln. In diesem Fall sind die Schlüssel, die
vererbt werden, an die Erzwingungsregeln anzupassen. Weiterhin erlauben einige Plattformen für Primärschlüssel
keine Nullwerte. Dann sind auch Nullwerte auszuschließen oder entsprechende Identifikatoren einzuführen.
Die Komplexität der Erzwingungsregeln kann für verschiedene Plattformen unterschiedlich sein. Deshalb ist
diese Komplexität bei der Beurteilung der Erzwingungsregeln mit einzubeziehen.
Pragmatik:
Obwohl das Einschränken der Schlüssel auf Primärschlüssel unserer Entwurfsphilosophie widerspricht, erhöht
dieses Einbeziehen die Transparenz der Übersetzung des Schemas für den Benutzer. Deshalb wurde in diesem
Schritt diese Einschränkung mit eingeschlossen, sobald die Plattform nur diese Behandlung zuläßt. Zugleich
wird aber diese Einschränkung auch zu einer relativ harten Einschränkung für die modellierten Schemata. Ein
Mittelweg ist das explizite Darstellen der Implementationseinschränkungen für eine spätere Berücksichtigung
während des Transformationsprozesses.
Werden Wertebereiche für die Erzwingungsregeln benutzt, dann entsteht in vielen Fällen ein nur für diesen
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
288
Wertebereich zugeschnittener Code. Damit wird eine spätere Modifikation des Schemas nicht mehr unterstützt.
Deshalb ist es besser nach einer optimalen Erzwingungsregel zu suchen. Wird durch eine Plattform diese Suche
nicht unterstützt, dann kann auch die Plattform falsch gewählt sein.
Eine Reihe von DBMS unterstützen nicht mehrere Schlüssel oder auch nicht komplexere Schlüssel. In diesem
Fall sind die Erzwingungsmechanismen anzupassen. Das Schema bedarf keiner Änderung.
4. Regeln für Relationshiptypen
Auf analoge Art werden Erzwingungsregeln für Relationshiptypen auf ihre Umsetzung und Umsetzbarkeit für
die gewählte Plattform untersucht.
Die bereits entworfenen Erzwingungsregeln sind für einen Benutzer transparent. Sie können direkt in den
meisten DBMS umgesetzt werden. Ist dies nicht für die gewählte Plattform möglich, sind entsprechende Maßnahmen zu ergreifen.
Pragmatik:
Oft steht für Erzwingungsregeln nur die referentielle Integrität zur Verfügung Deshalb können solche Erzwingungsregeln entweder durch Zurückführung auf die Erzwingungsregeln oder durch entsprechende Anwendungsprogramme unterstützt werden.
5. Erzwingungsregeln für Attributtypen
Es wird für die gewählte Plattform überprüft, inwieweit die entworfenen Datentypen, die Formate, die Wertebedingungen, die Eindeutigkeit, Nullwerte und Defaultwerte unterstützt werden können. Ist dies nicht der Fall,
dann sind evt. Kompromisse ausreichend oder es sind entsprechende Veränderungen am Schema oder an der
Plattform vorzunehmen.
Nullwerte sollten anhand der Eigenschaften der Plattform nochmals auf Notwendigkeit untersucht werden.
Man kann oft eher auf Defaultwerte ausweichen. In diesem Fall sind automatisch generierte Defaultwerte einsetzbar.
Im Falle der Verletzung der Integritätsbedingungen können Standardfunktionen zur Mitteilung an den Benutzer
oder den Datenbank-Administrator entwickelt werden.
Pragmatik:
Welche der Veränderungsoptionen genutzt wird im Falle eines Konfliktes zwischen Attributtyp und der Darstellbarkeit durch die Plattform, hängt von den Möglichkeiten der Plattform, den Kosten und Schwierigkeiten
einer Integritätserzwingung und der Unterstützung durch Anwendungsprogramme ab. Eine Schlüsseleigenschaft kann meist entweder durch entsprechende Datenwörterbücher der Plattform oder durch eindeutige Indizes unterstützt werden. Die Eigenschaft, daß ein Schlüssel minimal ist (d.h. keine echte Teilmenge von diesem
Schlüssel ist wiederum ein Schlüssel) wird sehr selten unterstützt. Ein Ausweg aus der Nichtdarstellbarkeit
kann auch die Entwicklung einer Menge von Standardprozeduren für die Pflege der Semantik einer Datenbank
sein. Damit werden jedoch die Implementationsmechanismen für den Benutzer evt. etwas schwieriger nachvollziehbar. Es wird eine zusätzliche Programmierung erforderlich. Dieser Zugang ist jedoch einfacher als die
direkte Benutzergesteuerte Pflege.
Werden Defaultwerte anstatt von Nullwerten eingesetzt, dann sind die Erzwingungsregeln zu überarbeiten.
Insbesondere Aggregationsoperationen können zu inkorrekten Werten führen. Werden zusätzlich Standardfunktionen eingesetzt, dann sind die generischen Funktionen und die Retrievaloperationen zu kontrollieren und
gegebenenfalls zu programmieren. Damit werden die Standardoperationen abhängig vom jeweiligen Typ.
Da ein ständiges Berichten über Integritätsverletzungen nicht nur die Performanz verschlechtert, sondern auch
dem Benutzer lästig werden kann, sind eher akkumulierende Funktionen sinnvoll, die zu einem festgelegten
Zeitpunkt die Verletzung von Integritätsbedingungen anmelden. Damit wird jedoch auch das Verhalten von
Transaktionen verändert, da diese erst mit dem Abarbeiten der Verletzungsliste zuende geführt werden können.
6. Regeln für die Funktionalität
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
289
Alle Anfragen sind auf ihre Unabhängigkeit von anderen Modifikationen zu überprüfen.
Für Updateoperationen muß genügend freier Speicher zur Verfügung stehen. Damit ist nach einer umfangreichen Modifikationsoperation eine Neuorganisation des Speichers vorzusehen.
Aus Sicherheitsgründen kann die Weitergabe von Klarnamen an Benutzer nicht erlaubt sein. In diesem Fall
ist ein Standard für die Namenbehandlung über eine Synonymbeziehung für die ensprechenden Namen mitzuführen.
Locking-Mechanismen werden benutzt, um eine konsistente Verwaltung konkurrierender Operationen verschiedener Benutzer zu ermöglichen. Diese Mechanismen sind durch die Größe der zu blockierenden Datenbankteile, durch den Lock-Modus und durch die Lock-Dauer zu unterstützen. Diese Spezifikation ist wiederum
von der gewählten Plattform abhängig.
Pragmatik:
Vorbereitete Anfragen, die Attributnamen nicht näher eingrenzen, sollten möglichst nur in Ausnahmefällen
verwendet werden. Sie sind für jeder Modifikation des Schemas wieder zuu überprüfen. Damit sind solche Anfragen kontextsensitiv.
Für Lock-Mechanismen ist es sinnvoll, den allgemeinsten Mechanismus auszuwählen. Für die Auswahl der
entsprechenden Lock-Mechanismen sind bei verschiedenen DBMS die Zuordnung der logischen Tabelle zur
physischen Speicherstruktur, das physische Layout der Elemente von Klassen, die Bedeutung des Wortes ‘Datenbank’ im Rahmen der Plattform und die Herausschälung der Lock-Parameter, die vom Entwerfer wirklich
beeinflußt werden können.
HERM-Compiler 6.
Schema-Tuning (Operationale Optimierung durch Tuningtechniken).
Aufgabe: Tuning des Zugriffs und Spezifikation von Indizes
Tuningtechniken und ihre konzeptionelle Wiederspiegelung
Weder für das relationale, noch das hierarchische oder Netzwerkmodell gibt es inhärente Probleme, die zu einer
schlechten Performanz, insbesondere beim Retrieval führen. Die Implementation dieser Konzepte führt erst zu den
Performanzproblemen. Um das Tuning einer Anwendung zu ermöglichen können folgende Charakteristika betrachtet
werden:
1. Es werden Eigenschaften des Anwendungsszenarios betrachtet:
(a) Art der Berechnung
i. erforderliche Operationen
ii. Art der Selektionskriterien
iii. Datenvolumen (Anzahl der durchmusterten Objekte und der berechneten Resultatsobjekte)
(b) Sichtbarkeit
i. Organisationsniveau der Benutzer
ii. Häufigkeit der Operationen
iii. Beziehung zum Geschäftsprozeß und seinen Implikationen
(c) Berechnungsmodi
i.
ii.
iii.
iv.
online (voraussichtlich)
batch (voraussichtlich)
interaktiv (ad hoc)
Berechnung während oder außerhalb von Spitzenzeiten
(d) Performanzerwartungen
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
290
i. Ausführungszeit (im online- oder batch-Betrieb, während interaktiver Anfragen bzw. die Zeit bis zur
Auslieferung von batch-Jobs)
ii. Durchlaßfähigkeit (Transaktions-/Anfrageraten, Modifikationsraten)
iii. Priorität der Operationen
2. Es werden Benutzer, die kritische Anforderungen an die Performanz haben, analysiert. Damit können entsprechende Bewertungen (Priorität) für deren Operationen gefunden werden und in das Anwendungsszenario mit
einfließen.
3. Kritische Transaktionen, Anfragen, batch-Prozesse, die eine Herausforderung für die Performanz darstellen,
werden besonders angemerkt.
4. Kritische Prozesse werden mit ihrem Berechnungs- und Zugriffsmechanismus modelliert. Man kann z.B. spezifische Zugriffspattern für die Darstellung auf konzeptionellen Niveau nutzen ohne die genauen Zugriffsmechanismen oder Berechnungsalgorithmen zu kennen oder weiter vergröbernd nur die involvierten Typen als
solche kennzeichnen.
5. Es werden verschiedene Entwurfsalternativen für kritische Teile von Schemata betrachtet.
Im weiteren werden verschiedene Tuningmechanismen im Detail betrachtet. Die Reihenfolge ist dabei durch die
Erhaltung der Schemaqualität (Korrektheit, Konsistenz, Stabilität, Natürlichkeit) determiniert. Tuningmechanismen,
die sich nicht auf konzeptionellen Niveau widerspiegeln, werden im weiteren nur angezeigt, nicht aber ausführlich
erörtert.
Tuningtechniken für Zugriffsmechanismen
Zugriffsmechanismen beeinflussen die Performanz in starkem Maße. Es gibt verschiedene Speicherungsmethoden und darauf aufbauend sehr verschiedene Zugriffsmethoden (Durchmustern, Gruppieren, Benutzung von HashFunktionen). Damit wird auch eine Speichermethode auszuwählen sein, die von der gewählten Plattform zu unterstützen ist. Darauf aufbauend können entsprechende Algorithmen für den Zugriff ausgewählt werden. Ein weiterer
Schritt zur Steigerung der Effizienz ist die Einführung von Indizes.
Zugriffspfade werden gewöhnlich durch den Optimierer generiert. Der Optimierer benutzt dazu als Eingabedaten
Statistiken der Datenbankbenutzung (I/O-Raten, Speicherverbrauch, CPU-Zeit usw.). Es werden allerdings durch
den Optimierer nur die endgültigen Zugriffspfade ausgewählt. Durch die Angabe von Zugriffspfaden kann jedoch
ein Entwerfer den Zugriffsmechanismus determinieren. Damit ist eine Spezifikation zum einem abhängig von der
gewählten Plattform und dem Stand der Technologie, zum anderen aber von der Anwendung, insbesondere den
Prozessen und somit typische Zugriffsmuster.
Voraussetzung zur Spezifikation der Zugriffspfade sind damit
Zugriffsmechanismen, die durch die Plattform unterstützt werden können,
Auswahlmechanismen, die die Plattform für die Auswahl einer spezifischen Zugriffsmethode benutzt
und die
kritischen Prozeßanforderungen der Anwendung.
Man kann und soll sich nicht auf eine Auswahl genau einer Zugriffsmethode konzentrieren, sondern eher auf die
Auswahl einer optimalen Menge von Zugriffsmechanismen. Damit sind die folgenden Problemstellungen von
Interesse:
· Welcher Zugriffsmechanismus kann am besten die verschiedenen Anforderungen der Anwendung befriedigen?
· Welche Zugriffsmechanismen werden zusätzlich benötigt? Kann evt. die Einführung eines zusätzlichen Index Abhilfe schaffen? Kann eine Sortierung den Zugriff erleichern?
· Welche Zugriffsmechanismen sind zu komplex? Kann z.B. eine Gruppierung den Zugriff erleichtern ohne daß durch
das schlechtere Updateverhalten die Performanz sinkt?
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
291
Diese Fragestellungen sehen nur auf den ersten Blick sehr maschinennah aus. In Wirklichkeit kann aber gerade
durch eine Strukturierung bereits ein besseres Verhalten erreicht werden. Damit werden aber zumindest das konzeptionelle Modell, mitunter sogar die eine oder andere Sicht einer Veränderung unterworfen. Im allgemeinen ist die
Auswahl des besten Zugriffspfades ein trickreiches Verfahren. Dazu müssen auch nicht nur die Plattform oder das
DBMS, sondern auch die Version und Konfiguration des Systemes berücksichtigt werden. Es gibt jedoch einige allgemeine Prinzipien, die direkt aus der Anwendung ableitbar sind, auch wenn durch eine relationale Transformation
bereits aufgrund von Forderungen wie 1. Normalform vorhandenes Wissen nicht direkt dargestellt wird.
In diesem Schritt wird eine interne Repräsentationsstruktur abgeleitet bzw. es werden Strukturen entsprechend
dem Verhalten restrukturiert. Zuerst werden dabei Zugriffsmethoden betrachtet (Speicherorganisation, Indexiserungsmethoden). In nächsten Schritt werden wir die Forderung nach Redundanzarmut aufweichen entsprechend den Verhaltensanforderungen. Damit wird die Struktur in den Sichten und des konzeptionellen Schemas nochmals verändert.
Oft unterstützen Werkzeuge das Abschätzen der Performanz einer Anwendung. Solche Werkzeuge verlangen
jedoch ebenfalls eine Abschätzung der CPU-Zeit, der I/O-Zeit, der Durchmusterungszeit und -rate, sowie weitere
Parameter. Es gibt bereits eine kommerzielle Animationswerkzeuge, mit deren Hilfe die Performanz durchgespielt
werden kann.
Hinzufügen von Indexierungsmechanismen
Indizes können zu jeder Klasse hinzugefügt werden für jeden Identifikationsmechanismus. Da ein Index bei einer
Modifikation gepflegt werden muß, wählt man nur einige Identifikationsmechanismen aus, für die ein Index angelegt
und gepflegt wird.
Wir unterscheiden Gruppierungsindizes, die das Durchmustern unterstützen und auf einer Gruppierung basieren,
und geordnete Indizes, die auf einer Ordnung der Wertebereiche basieren.
Außerdem werden Indizes zur Unterstützung der Operationen angelegt. Somit impliziert die entworfene Funktionalität auch das Anlegen entsprechender Indizes für die verschiedenen Typen.
1. Durchmusterungsprozesse
Für welche Typen ist ein Durchmustern noch ausreichend effizient, für welche nicht? Damit kann für die
letzteren Typen nach anderen Zugriffsmechanismen gesucht werden. Die Effizienz wird durch die Häufigkeit
der Modifikationen, durch die Durchmusterungsrate für Anfragen entsprechend den Dialogobjekten, durch die
Größe der Klassen und das Anwendungsszenario bestimmt.
Durch Gruppierung, Projektion und Partitionierung kann Durchmustern noch effizienter werden. Deshalb ist
für die interne Darstellung eine vertikale oder horizontale Dekomposition, eine Verfeinerung der Teiltypenhierarchie oder eine Gruppierung sinnvoll. Dabei sind jedoch alle Prozesse im Komplex zu betrachten. Diese
interne Repräsentation kann den jeweiligen Typen zugeordnet werden. Die konzeptionelle Darstellung wird
dadurch jedoch nicht verändert.
Dagegen sollten Klassen mit gleicher Struktur nicht den gleichen Speicherraum zugeordnet werden, weil dadurch Durchmustern ineffizienter wird.
Pragmatik:
Sequentiell Durchmustern kann heute jedes System. Es ist z.B. bei relationalen Plattformen der Defaultsuchmechanismus. Damit muß nur verstanden werden, wann Durchmustern effizient und wann es ineffizient ist.
Durchmustern ist für kleine Klassen, die nicht zu komplex strukturiert sind (z.B. nicht mehr als 6 physische
Blöcke für die Daten ihrer Objekte benötigen), für Klassen, für die Anfragen oft einen größeren Teil (mindestens ein Fünftel, je nach Plattform) der gesamten Klasse liefern, und für Klassen, über denen nur Anfragen
einer niedrigen Priorität berechnet werden, eine Alternative. Damit wird die Pflege eines Index nicht mehr
notwendig. Klassen dieser Form mit häufigen Modifikationen sind deshalb noch effizienter.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
292
Viele Plattformen unterstützen eine Segmentierung. Damit kann eine horizontale Dekomposition, die mit der
Struktur der Antworten auf Anfragen korrespondiert, Durchmustern zur effizienten Suchmethode werden lassen.
Analog kann durch eine Führung von Tupelidentifikatoren und eine Partitionierung bzw. Projektion das Durchmustern effizienter werden. Klassen, deren Anfragen nicht zusammenhängen, die aber gleiche Speicherräume
benutzen, lassen Durchmustern ineffizient werden. Der Verbund von Klassen kann jedoch durch Durchmustern
unter gewissen Umständen auch effizient werden.
Die Effizienz von Durchmustern hängt auch von der Plattform ab. Wird z.B. paralleles Durchmustern unterstützt, werden Hochgeschwindigkeitsmedien und Techniken wie das Puffern oder andere Ressourcen verwandt, dann ist Durchmustern effizient sogar für größere Klassen.
2. Möglichkeiten von Gruppierungen
Typen, die häufig auf die gleiche Art durchmustert werden, deren Anfrageoperationen strukturiert (insbesondere durch analoge Selektionskriterien) sind und analoge Durchmusterungsreihenfolgen erfordern, können,
insbesondere falls Modifikationen durch die generischen Operationen eine Gruppierung nicht verändern, entsprechend den Operationen gruppiert werden. Neben der Gruppierung kann auch eine Sortierung (Darstellung
durch eine Liste) die Performanz steigern.
Bei einer Gruppierung sind die Auswirkungen auf parallele Anfragen mit zu betrachten. Lock-Techniken
können dadurch vereinfacht werden oder komplexer werden. Wird das Verhalten verschlechtert, dann ist eine Gruppierung nicht angebracht.
Eine Gruppierung ist für Relationshiptypen oft eine geeignete Methode zur Vereinfachung der Operationen
über solchen Typen. Eine Gruppierung der Komponententypen nach ihren auf den Relationshiptypen vererbten
Identifikationsmechanismus ist dann sinnvoll, wenn keine verschiedenenartigen Identifikationsmechanismen
für verschiedene Relationshiptypen erforderlich sind.
Pragmatik:
Eine allgemeine universelle Optimierungsmethode existiert nicht. Man muß deshalb Gruppierungen und Ordnungen gegen die Komplexitiät der Operationen abwägen. Wird eine Klasse häufig modifiziert und ist die Modifikation durch die Gruppierung oder die Sortierung so erschwert, daß sich das Gesamtverhalten verschlechtert,
dann wird man von einer Veränderung Abstand nehmen. Weiterhin wird bei manchen Plattformen eine Modifikation auch das Verschieben ganzer Teilklassen oder eine Neusegmentierung erfordern. Solche Plattformen
sollten nur mit einfachen Strukturen benutzt werden.
Kleine Klassen erfordern keine Gruppierung. Für solche ist ein Durchmustern stets effizienter.
In relationalen Systemen wird die Gruppierung durch O RDER B Y, G ROUP B Y, U NION , D ISTINCT, verschiedene Arten von Verbunden und Selektionen unterstützt. Damit kann eine entsprechende Repräsentationsstruktur
angegeben werden.
Die Gruppierung der Identifikationsmechanismen ist eine einfache und effiziente Methode, solange nicht zu
viele verschiedene Identifikationsmechanismen für den gleichen Typ geführt werden müssen. Sind Modifikationen nicht so häufig, die Trefferquoten für Anfragen relativ niedrig, dann kann eine Indexierung günstiger sein.
Gruppierungen können auch durch Werkzeuge einiger DBMS für den Optimierer generiert werden. Solche
Werkzeuge können auch benutzt werden, um freien Speicherplatz für zukünftige Modifikationen zuzuweisen.
Diese Vorgehensweise liegt jedoch außerhalb unseres Zuganges zur Modellierung von Datenbanken.
Die Komplexität der Sortierung ist abhängig von der gewählten Plattform.
In unserem Beispiel kann z.B. ein Reiseverlauf dargestellt werden durch einen Typ, der Abfahrtsort und -zeit,
sowie Ankunftsort und -zeit darstellt. Eine alternative Form ist die Verwendung einer Liste mit Listenelementen, die den Ort und die Zeit darstellen. Mit der letzten Form werden Konsitenzüberprüfungen zum Reiseverlauf
einfacher.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
293
3. Möglichkeiten von Hashmechanismen
Da der Hashzugriff besonders schnell ist, sollte für Abfragen in großen Klassen, die einen Zugriff auf Objekte in zufälliger Ordnung benötigen und relativ wenig Modifikationen erfahren, ein Hash-‘Schlüssel’ benutzt
werden können. Hashzugriffe können insbesondere für Komponenten vorgesehen werden, die vielen Anfragen
gemeinsam sind. Kann eine Hashfunktion benutzt werden, dann ist die Verteilung der Daten zu spezifizieren,
sowie eine Strategie für Konfliktfälle, in denen der Zugriff auf mehrere Objekte erfolgt, die dann weiterselektiert werden.
Pragmatik:
Mit einer Angabe der Verteilung der Daten der Objekte in einer Klasse kann meist auch eine Hash-Funktion
automatisch generiert werden. Da Hash-Funktionen Objekte nicht eindeutig identifizieren müssen, ist vorzusorgen für diese Nichteindeutigkeit. Konflikte von Hashwerten, d.h. eine Hash-Funktion generiert gleiche Werte
für verschiedene Objekte, sollten beschränkt bleiben. Hashing ist nicht anzustreben, wenn die Wertebereiche
nicht ausreichend genau spezifiziert sind, wenn die Werte nicht gleichverteilt vorkommen, wenn die verwendeten Komponenten nicht einfach zu einem Schlüssel ergänzt werden können, wenn die Selektionskriterien
von Anfragen den Hash-‘Schlüssel’ nicht enthalten oder der Zugriff selbst nicht zufällig erfolgen kann. HashTechniken sind als Ergänzung zu anderen Zugriffstechniken anzusehen. Hash-Techniken können in verteilten
DBMS meist nur für einen Ort angewandt werden.
Häufig benutzte Kombinationen von Komponenten in Selektionskriterien eignen sich besonders dann für Hashfunktionen, wenn diese Komponenten nicht zu häufig modifiziert werden. Werden jedoch Teilmengen von den
Hashfunktionen zugrundegelegten Komponenten in Selektionskriterien benutzt, dann können diese Hashfunktionen nicht benutzt werden.
Die Auswahl einer geeigneten Hashfunktionen ist keine Aufgabe des Entwurfes. Sie wird für einige DBMS
durch Werkzeuge unterstützt, in einigen DBMS werdenn Hashfunktionen sogar automatisch generiert.
4. Auswahl von Schlüsseln
Indizes werden für große Klassen angelegt, für die Anfragen eine relativ kleine Teilmenge auswählen und für
die Anfragen über relativ wenige Komponenten reichen. Schlüssel bzw. Identifikationsmechanismen mit diesen
Eigenschaften werden gekennzeichnet mit entsprechenden Indizes.
Es ist bei der Auszeichnung eines Schlüssels für einen Index die Verschlechterung der Performanz möglich.
Deshalb muß das Anlegen von Indizes abgewogen werden.
Pragmatik:
Beim Anlegen von Indizes können Gruppierungsindizes oder geordnete Indizes angelegt werden. Für die meisten Plattformen sind Gruppierungsindizierungsmechanismen vorhanden. Kann man eine Ordnung angeben,
die mit der Ordnung einer Anwendung oder einer Reihe von Anfragen korrespondiert, dann ist ein geordneter
Index mit der Angabe der Ordnung besser.
Können verschiedene Klassen im gleichen Speicher abgelegt werden, dann können Indizes benutzt werden, um
diese Klassen voneinander zu trennen. Damit kann ein Mehrklassendurchmustern vermieden werden.
Das Anlegen und die Pflege von Indizes erfordern zusätzliche Funktionen. Deshalb ist eine Betrachtung der
Performanz notwendig. Dazu werden Speicherplatzabschätzungen, der Einfluß der generischen Operationen
insert, delete und update, die Folgen für das Laden der Datenbank, die Reorganisationserfordernisse, die
Wiederanlaufs- bzw. Rücksetzungszeit und die Sicherungsmechanismen betrachtet. Indizes über kleinen Klassen bringen keine Verbesserung der Performanz.
Indizes über häufig modifizierten Komponenten bringen eine Verschlechterung der Performanz. Diese sind nur
in Ausnahmesitutationen (keine andere Möglichkeit) zu benutzen.
Falls die Daten von zu indizierenden Komponenten nicht in regelmäßiger Form verteilt sind, dann ist entweder
die Verteilung in die Definition mit einzubeziehen oder ein anderer Zugriffsmechanismus zu wählen. Die erste
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
294
Möglichkeit wird nur von wenigen DBMS unterstützt.
Kürzeste Schlüssel, d.h. solche die sich unter der Menge der minimalen Schlüssel durch die kleinste Speicherdarstellung bzw. die die kleinste Anzahl von Attributen besitzen, sind oft effizienter als andere minimale
Schlüssel.
Das dynamische Verändern von Indizes kann vor Perioden von intensiven Modifikationen vermieden werden,
indem der Index vorher entfernt wird und danach wieder neu aufgebaut wird. Indizes, die zur Integritätspflege
erforderlich sind, können nicht entfernt werden.
Die Namen der Typen und ihrer Indizes sollten aufeinander auf der Grundlage eines Namensstandards abgeglichen sein.
5. Unterstützung von Operationen
Operationen, insbesondere Anfragen, die häufiger ausgeführt werden, können durch Indizes unterstützt werden.
Selektionskriterien, Verbunde von Klassen, Ordnungen (G ROUP B Y, O RDER BY) und Mengenoperationen wie
z.B. Vereinigungen (U NION , D ISTINCT) können durch Indizes unterstützt werden.
Schlüssel oder Identifikationsmechanismen, die für Komponenten in Relationshiptypen verwendet werden,
sollten durch Indizes unterstützt werden.
Werden Indizes verwendet, dann kann eine Blockierung anderer Zugriffsmechanismen sinnvoll werden, sobald
diese weniger effizient sind als die Indizierung.
Pragmatik:
Werden Indizes zur Unterstützung von Operationen angelegt, dann sollten diese effizienter sein als das Durchmustern. Deshalb sollte die Trefferquote niedrig sein.
Built-in-Funktionen, inbesondere Aggregationsfunktionen, die häufig in Anfragen benutzt werden, sollten durch
entsprechende Indizes gestützt werden.
Kann ein geordneter Index mit mehreren Komponenten benutzt werden, dann ist die Reihenfolge der Komponenten so zu entwerfen, daß der Zugriff im Mittel schnell erfolgt. Mitunter ist es günstiger mehrere Indizes in
parallel für jede einzelne Komponente zu benutzen und nicht einen Index, der alle Komponenten erfaßt.
6. Adaption an die Plattform
In diesem Schritt können wir verschiedene Implementationsbeschränkungen in den Entwurf einbeziehen. Da
sich diese nicht direkt auf den konzeptionellen Entwurf auswirken und nur für die Transformation notwendig
sind, verwenden wir diese Beschränkungen hier nicht für die Entwicklung von Tuningmechanismen.
Pragmatik:
Plattformen unterstützen Operationen auf verschiedene Weise. Z.T. werden für bestimmte Operationen auch
Indizes automatisch angelegt. Die Performanz hängt in diesem Fall auch von den Sortieralgorithmen ab.
Eine Blockierung anderer Zugriffsmechanismen wird nicht von jeder Plattform unterstützt. Dazu muß auch der
Optimierer des DBMS angepaßt sein.
Eine Plattform kann die Verfügbarkeit von Indizes einschränken. Deshalb sollte in diesem Fall bereits eine
Spezifikation auf Realisierbarkeit insbesondere für parallele Zugriffe geprüft werden.
Erlaubt eine Plattform eine Verteilung von Klassen und Indizes auf verschiedene Speichermedien, dann sollte
diese Verteilung aus Zugriffsgründen angestrebt werden. Eine Indexblockierung kann aufgrund der Klassengröße eintreten. Deshalb sind die maximalen Klassengrößen mit einzubeziehen.
Werden durch die Plattform verschiedene Arten von Indizes (eindeutig, nicht-eindeutig; gruppiert, ungruppiert; partitioniert, unpartitioniert; verschiedene Speicherstrukturen (B-Bäume etc.)) unterstützt, dann ist eine
feinere Unterscheidung auch für konzeptionelle Entwürfe sinnvoll. Da die meisten DBMS keine umfangreichen
Möglichkeiten besitzen, verzichten wir hier auf eine Untersetzung.
IS ADD
CAU zu Kiel, IfI, ISE, β
HERM-Compiler 7.
2. Strukturierung von IS
ab SS 2012
295
Einführung gesteuerter Redundanz.
Gesteuerte Redundanz
Unser Ziel ist eine Verbesserung des Verhaltens. Dabei versuchen wir, die Sichten beizubehalten und höchstens
das konzeptionelle Schema zu verändern. Durch Operationen kann jedoch auch eine Veränderung des konzeptionellen
Schemas notwendig werden. Ein Performanzengpaß ist z.B. der Zugriff auf mehrere Klassen, die durch Dekomposition entstanden sind. Oft wird deshalb eine strenge Denormalisierung empfohlen. Besser ist eine gesteuerte Denormalisierung. Diese orientiert sich an den Prozeßanforderungen und den unterstützenden Algorithmen. Operationen
des DBMS wie Verbund, Vereinigung und äußerer Verbund verursachen oft diese Ineffizienz. Eine andere Ursache
sind Hierarchien, die eine gemeinsame Bearbeitung verschiedener Klassen erfordern.
Redundante Abspeicherung sollte jedoch erst dann vorgesehen werden, wenn andere Tuningmechanismen nicht weiterführen. Eine redundante Datenbank erfordert zusätzliche Mechanismen zur Integritätspflege. Oft werden diese
jedoch durch DBMS nicht mit angeboten.
Vor einer Einführung von redundanten Strukturen sind deshalb
· alternative Schemata zu untersuchen, inwieweit dadurch entstehende Probleme besser bewältigt werden können,
· alternative Programmiermethoden oder Algorithmen Probleme besser lösen oder
· eine Revision des Schemas weiterhilft.
1. Einführung von Komponentenkopien
Werden durch Operationen verschiedene durch Normalisierung entstandene Typen wieder verbunden, dann
kann durch eine Kopie der Komponenten bereits ein Verbesserung der Performanz erreicht werden. Insbesondere kann auch eine Kopie von Nichtschlüsselattributen für einen Teiltyp einen Verbund von Supertyp und
Teiltyp unnötig machen. Analog kann in Generalisierungshierarchien vorgegangen werden.
Relationshiptypen können eingeführt worden sein, um eine Eigenschaft einer Klasse darzustellen. Durch explizites redundantens Mitführen dieser Eigenschaft kann der Relationshiptyp für die Berechnung von Operationen
unnötig werden.
Pragmatik:
Werden Komponenten und insbesondere Attribute in anderen Typen kopiert, dann ist durch eine entsprechende
Namenskonvention eine Ableitung anzeigbar.
Jede Einführung von redundanten Komponenten erfordert entsprechende Pflegemechanismen. Deshalb sollte
eine Einführung auf konzeptionellen Niveau auch mit einer Spezifikation der Pflegemechanismen verbunden
werden. Außerdem ist der zusätzliche Speicherbedarf mit ins Kalkül zu ziehen.
Die Wertebereiche und die Semantik der kopierten Komponenten muß im neuen Schema mit dargestellt werden.
2. Einführung abgeleiteter Daten
Abgeleitete Daten können die Effizienz von verschiedenen Operationen, insbesondere der kritischen oder häufigen Operationen, die einen Verbund von mehreren Klassen erfordern, verbessern.
Pragmatik:
Werden abgeleitete Daten mitgeführt, dann ist analog zu abgeleiteten Attributen ein Pflegemechanismus für die
generischen Operationen auf dem Ursprungstyp mitzuführen.
Erlaubt die Plattform Dämonen, dann kann auch mit einer verzögerten Anpassung der Daten eine Verbesserung erreicht werden.
Spezielle Namenskonventionen erleichtern das Rekapitulieren der Einführung redundanter, abgeleiteter Daten.
Synonyme sind damit entsprechend einzuführen.
Durch ein Vermeiden oder Blockieren von Modifikationen auf den abgeleiteten Komponenten kann eine Inkonsistenz zusätzlich vermieden werden.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
296
Da die abgeleiteten Daten nicht wieder zur Ableitung verwendet werden, ist in diesem Fall der Triggermechanismus sicher. Deshalb können über Trigger diese Daten nachgeführt werden.
3. Einführung von Wiederholgruppen
Durch Operationen mit hoher Priorität oder mit hoher Frequenz können Gruppenberechnungen erforderlich
sein. Überwiegen diese Operationen, dann kann eine Einführung einer Wiederholgruppe unter Umständen eine
Verbesserung der Performanz bringen.
Durch eine mehrwertige Abhängigkeit kann eine vertikale Dekomposition erforderlich werden. Ist jedoch die
Wiederholrate begrenzbar, dann kann eine redundate Abspeicherung eine bessere Option sein.
Ist eine Kardinalität für eine wiederholte Darstellung der Daten abzuschätzen, dann kann durch eine nochmalige Einführung der gleichen Komponenten (mit Kennzeichnung der Kopienummer) eine Wiederholgruppe
simuliert werden. Weiterhin können die Konstruktoren zu einer Verbesserung der Struktur benutzt werden.
Pragmatik:
Mehrwertige Abhängigkeiten können auch Ausnahmen der Gültigkeit von funktionalen Abhängigkeiten spezifizieren. Dann sind wiederholende Werte eher eine Ausnahme. In diesem Fall ist eine redundante Abspeicherung
auch begrenzbar.
Eine andere Begrenzung der Wiederholrate kann man durch Betrachtungen für den mittleren Fall gewinnen.
Werden Komponenten mehrmals geführt, dann muß eine Verwaltung von Nullwerten explizit geführt werden
können.
Im Beispiel kann z.B., falls Dienstreisen von nicht mehr als zwei Antragstellern, meist sogar von zwei durchgeführt wird, eine Reise im Relationshiptyp beantragt mit zwei Komponenten Antragsteller1 und Antragsteller2
geführt werden, wobei die letztere evt. noch optional sein kann. Diese Einführung entspricht der Einführung
eines Mengenkonstruktors im allgemeinen Fall für die Komponente Antragsteller im Typ beantragt.
4. Einführung von Abstrakta
Abstrakta haben keine Bedeutung für die Anwendung. Sie können bei langen Schlüsseln, die relativ viel Speicher erfordern, eingeführt werden, falls eine Zugriffsmethode für diese Abstrakta existiert.
Abstrakta können auch durch eine Vielzahl von Beziehungen erforderlich werden. Damit sind dann z.B. gleichzeitig benutzte Objekte (shared objects) in Beziehungen besser aufzufinden.
Vor der Einführung von Abstrakta sind alle Schlüssel zu untersuchen. Ist ein Schlüssel einfacher, dann kann
dieser Schlüssel anstatt des ursprünglichen benutzt werden.
Pragmatik:
Die Einführung von Abstrakta entspricht der Einführung von Objektidentifikatoren. Diese kann durch die plattform bereits vorgegeben sein oder durch den Entwerfer explizit eingeführt werden. Verschiedene relationale
Plattformen erlauben die Benutzung von Tupelidentifikatoren. Diese Alternative ist äquivalent zur Einführung
von Abstrakta.
5. Einführung von Objektkopien
Es können Objekte direkt kopiert werden oder Objekte aus Objekten abgeleitet oder zusammengesetzt werden.
Eine Einführung einer Objektkopie erfordert entsprechende Pflegemechanismen.
Pragmatik:
Kopien des gleichen Objektes in der gleichen Klasse sind nicht erlaubt. Analog sollten abgeleitete Objekte in
der gleichen Klasse vermieden werden, weil damit die Identifikationseigenschaft zerstört wird.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
297
6. Einführung von äußeren Verbunden
Durch den äußeren Verbund werden auch nicht über den Verbundkomponenten übereinstimmende Objekte
gewonnen. Damit kann eine Vereinigung von Klassen gewonnen werden. Damit sind Operationen auch auf
andere Weise darstellbar. Man kann diese Darstellung wählen, wenn dieser Verbund unterstützt wird und die
Performanz verbessert wird.
Pragmatik:
HERM-Compiler 8.
Redefinition und Revision von Typen.
Eine Restrukturierung kann auf logischen oder konzeptionellen Niveau ohne Probleme für die Benutzer durchgeführt
werden. Damit kann oft eine effizientere Datenbank entworfen werden, ohne daß ein Benutzer die Restrukturierung
nachvollziehen muß. Wir haben bereits entsprechende Optimierungsschritte auf den Sichten in früheren Schritten
durchgeführt. Sollte trotzdem in diesem Schritt eine Restrukturierung der Sicht notwendig werden, dann liegt ein
Modellierungsfehler vor.
1. Bewertung speicherintensiver Komponenten
Lange Textfelder und andere komplexe Wertebereiche sind für Schlüssel und den Zugriff nicht geeignet. Deshalb sehen wir im konzeptionellen Schema abstrakte Komponenten vor, die die Daten der Komponentenobjekte
in verkürzter Darstellung verwenden. Kommen komplexe Daten mehrfach vor, dann werden spezifische Typen
neu definiert.
Pragmatik:
Speicherintensive Komponenten ziehen meist auch komplexere (Text-)Verarbeitungsfunktionen nach sich. Deshalb sollten auch diese Funktionen bei der Revision mit verwendet werden.
2. Schrittweise Revision von Komponentenschlüsseln
Alle Komponenten werden anhand der Dialogobjekte nochmals auf ihre vererbten Identifikationsmechanismen
überprüft.
Pragmatik:
Oft werden die Primäridentifikationsmechanismen für die Definition von Komponenten in Relationshiptypen
herangezogen, obwohl durch die Anwendung andere Identifikationsmechanismen benötigt werden. Deshalb
kann selbst in der entsprechenden Sicht eine Modifikation notwendig werden. Dabei muß die Semantik auch
weiterhin pflegbar sein.
3. Elimination von Typen
Typen, die keine neue Information hinzufügen, und Typen, die durch keine Anwendungsoperation benötigt
werden, können entfernt werden. Vor einer Entfernung ist die Gültigkeit der Entfernungsbedingung zu prüfen.
Analog können Komponenten, die in keinem Dialogobjekt benutzt werden, entfernt werden, falls sie für die
Anwendung keine Bedeutung besitzen.
Pragmatik:
Redundante Typen existieren auch in Hierarchien, in denen Supertypen nur eine Vereinigung der Subtypen sind
ohne eigenständige, außerhalb der Identifizierung exisitierende Komponenten zu besitzen.
Analog kann die Kontraktion von Typen genutzt werden.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
298
Im Beispiel kann das Teilschema
Antragsteller = ...
Fahrkarte = ( { Firma, Preis }, { Firma, Preis } )
bestellt = ( Antragsteller, Fahrkarte, { Zeitraum } )
Route = ( { Name } , { Name } )
möglichT = ( Fahrkarte, Route, ∅ )
aufgrund der Gültigkeit von Komplexitätsbedingungen
comp(bestellt, Fahrkarte) = (1, 1),
comp(bestellt, Antragsteller) = (0, n)
comp(möglichT, Fahrkarte = (1, n) ,
comp(möglichT, Route) = (1, 1)
kontrahiert werden zu den Typen
Antragsteller = ...
RoutenFahrkarte = ( { Firma, Preis, Route.Name }, { Firma, Preis, Route.Name } )
benutzt = ( Antragsteller, RoutenFahrkarte, { Zeitraum } ) ,
ohne Verlust von Semantik.
4. Hinzufügen von Duplikattypen
Aufgrund häufiger Anfragen kann auch ein abgeleiteter Typ aus einem Typ durch Projektion, Selektion und
andere Operationen der Algebra hergeleitet und explizit zur Erleichterung dieser Operationen benutzt werden.
Pragmatik:
Auch ad-hoc-Anfragen können durch Duplikattypen erleichtert werden. Analoges gilt für Aggregationsanfragen, die kritisch sind. Mit einer Duplizierung ist eine Pflege der Integrität notwendig.
5. Segmentierung von Typen
Pragmatik:
Durch vertikale oder horizontale Dekomposition kann das Verhalten der Datenbank verbessert werden, insbesondere dann wenn die Operationen Datenmengen erfordern, die nicht im Hauptspeicher gehalten werden
können aber durch Dekomposition geladen werden können.
6. Kombination von Typen
Pragmatik:
1:1-Relationshiptypen können durch Einlagerung nicht nur kompakter dargestellt werden, sondern auch zu
einer Verbesserung der Performanz führen. Verbinden die kritischen Operationen mehrere Typen, sind diese
Typen weniger separat in Operationen von Interesse, dann kann auch ein kombinierter Typ anstelle dieser Typen zu einer Verbesserung der Performanz führen. Auch in Hierarchien kann eine zusätzliche Generalisierung
oder eine Zusammenführung von Super- und Subtyp Operationen besser unterstützen.
Analoges gilt für 1:n-Relationshiptypen und n-äre Relationshiptypen.
7. Kombination durch äußeren Verbund
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
299
Pragmatik:
HERM-Compiler 9.
Betrachtungen für sehr große Datenbanken.
Große Datenbanken sind heute keine Seltenheit mehr. Insbesondere in klassischen Anwendungen wie der Versicherungsbranche, bei Banken, bei Telefongesellschaften und Vermarkungsgesellschaften sind bereits Datenbestände im
Terabytebereich zu verwalten.
In neueren Anwendungen zur Erderkundung, in der Molekularbiologie und der Kartographie werden von Anfang an sehr große Datenmengen anfallen. Für diese Datenmengen ist eine sehr sorgfältige Planung der Performanz
erforderlich.
Schritte
1. Performanz der Retrieval
Das Retrieval von Daten kann durch lange Durchmusterungsprozesse und Sortieroperationen z.T. stark verlangsamt werden. Deshalb ist bei der Implementation durch verschiedene Tuningschritte die Performanz des
Retrieval zu verbessern.
Auswahl von Zugriffsmechanismen;
Implementation von Beispieltabellen zur Erprobung;
Implementation von Auswertungsrelationen auf der Grundlage von Beispieltabellen.
Pragmatik:
2. Durchlaßfähigkeit
Hohe Transaktionsraten stellen nach wie vor ein Problem für DBMS dar. Deshalb sollte für große Datenbanken
die Durchlaßfähigkeit zusätzlich gesondert optimiert, da die Größe der Datenbank und die Anzahl der Transaktionen eine doppelte Herausforderung darstellen. Typische Beispiele dieser Art sind Bankenanwendungen,
in denen die Anzahl der Kunden und der Datenumfang eine größere Anzahl von Transaktionen hervorruft.
Deshalb wird die Durchlaßfähigkeit gesondert nach folgenden Kriterien optimiert:
Auswahl der Locking-Mechanismen: Kleine Locking-Granularität erhöht die Parallelisierungsmöglichkeiten.
Andererseits kann Locking auf Tabellenniveau, insbesondere bei read-only-Locks, die zusätzliche Verarbeitungskapazität, die durch Locking-Mechanismen erforderlich sind, minimieren. Deshalb ist für große
Tabellen ein anderer Abgleich erforderlich. Eventuell sind für diese Lösung zusätzlich ‘dummy’-Tupel
notwendig.
Gruppierung: Günstig sind Transaktionen, die Gruppen von Daten erfordern. In diesem Fall kann durch eine
Gruppierung die Transaktionsrate verbessert werden.
Partitionierung und Segmentierung: Eine noch günstige Optimierungsmethode ist die Partitionierung und
die Segmentierung der Daten in Abhängigkeit von den Transaktionen. Damit kann die Abhäsion der
Daten mit in die Optimierung einbezogen werden.
Commit-Processing: Durch ein spätes Commit wird die zusätzliche Kapazität, die die Verarbeitung von Commits erfordert, minimiert. Sind jedoch die Tabellen sehr groß, dann ist mit einem Abort jedoch ein höherer
Berechnungsaufwand erforderlich. Deshalb sind für sehr große Relationen frühe Commits günstiger.
Segmentierung der Updates: Werden die Manipulationsoperationen für größere Datenströme angewandt, dann
verursachen die seitenweise Verarbeitung, das Identifikationsmanagement etc. einen Performanzverlust.
Günstiger ist dagegen, die Partitionierung und Segmentierung der Datenströme.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
300
Pragmatik:
3. Insert-/Delete-Prozesse
Die Insert- und Deleteoperationen können für größere Datenmengen einen erhöhten Aufwand durch Logging,
Locking, Commit-Processing, Indexveränderungen etc. erfordern. Deshalb sollte die Insertoperation optimiert
werden durch Nutzung folgender Systemroutinen:
Ladewerkzeuge: Gewöhnlich wird die Insertoperation als eine Ein-Tupeloperation behandelt. Einige Systeme
erlauben jedoch auch ein ‘Refresh’ oder ‘Replace’ von Tabellen. Außerdem wird oft ein Insert durch
Anfügen an eine Tabelle implementiert. Günstiger ist - wie in den großen Systemen unterstützt - eine
vorhergehende Suche nach freiem Speicherplatz in entsprechenden Seiten.
Temporäres Aufheben des Loggings: Für größere Datenströme kann ein Logging zu aufwendig sein. Kann
man die Insertoperation wiederholen bzw. die Fehlerbehandlung verzögern, dann ist ein zeitweiliges Unterbrechen des Loggings laufzeitgünstiger.
Temporäres Verändern der Indizes: Da das Verändern von Indizes aufwendig sein kann, ist für große Datenströme eine Neuberechnung von Indizes bzw. eine Berechnung eines Inputindexes mit anschließendem
Mischen günstiger.
Analog kann ein Massendelete durch Partitionierung und Segmentierung besser unterstützt werden. In unserem Beispiel kann z.B. durch eine Partitionierung auf Dienstreisejahre ein Delete vermeiden, das dann einem
Streichen einer ganzen Relation entspricht.
Pragmatik:
4. Checkpoints und Wiederanlauf
Für große Datenbanken wirkt sich die Benutzung von Sicherungspunkten performanzverschlechternd aus. Dies
trifft insbesondere auf lange Transaktionen zu. Deshalb ist diesen Transaktionen besondere Aufmerksamkeit zu
widmen. Sind Transaktionen zerlegbar in Folgen kürzerer Transaktionen, dann sollte eine Zerlegung angestrebt
werden, falls die zusätzliche Zeit, die für die Verbindung der einzelnen Teile erforderlich ist, nicht zu stark ins
Gewicht fällt.
Pragmatik:
5. Adminstration, Scheduling und Werkzeuge
erfordert meist einen zusätzlichen Aufwand. Ist dieser nur linear vom Umfang der Daten abhängig, dann ist
eine Benutzung der Tools eher sinnvoll als bei höherer Komplexität. Im letzteren Falle kann Abhilfe durch
folgende Lösungen geschaffen werden:
Ausnutzung der Parallelisierung: Bei nichtlinearer Komplexität von Werkzeugen kann durch eine zielgerichtete Parallelisierung eine Verbesserung erreichen.
Benutzung von partiellen Funktionen anstelle von totalen: Ein Beispiel sind Backupfunktionen. Werden Backups
regelmäßig durchgeführt, dann kann auch ein partielles Backup für die Änderungen seit dem letzten
Backup effizienter sein.
Geringere Benutzung der statistischen Funktionen: Sind die Änderungen minimal verglichen mit der Größe
der Relationen, dann kann auch auf Statistiken, die die Verwaltung der Datenbank vergleichen, verzichtet
werden.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
301
Betrachtung der Fehlerbehandlungszeit: Für große Datenbanken kann die Fehlerbehandlung auch zu groß
werden. Durch unterschiedliche Fehlerbehandlungskonzepte kann die Zeit minimiert werden.
Pragmatik:
HERM-Compiler 10.
Vorbereitung für Veränderungen der Datenbanksysteme.
Datenbanken sind für viele Anwendungen auch in der Struktur nicht statisch. Sowohl die Struktur als auch die Semantik und insbesondere die Funktionalität unterliegen einer häufigen Veränderung. Viele Veränderungen können
durch relationale DBMS aufgefangen werden. Einige Veränderungen wirken sich jedoch stark auf vorhandene Funktionen aus. In der relationalen Technologie wird zwischen der Delete- und der Dropoperation unterschieden. Letztere
Operation erlaubt neben dem Streichen eines Objektes auch das Streichen der zugehörigen Struktur. Analoge Auswirkungen kann die Insertoperation haben.
Syntax:
Pragmatik: Eine Modifikation, das Streichen und das Hinzufügen von Tabellen kann die Arbeit der Datenbank in
wesentlichen Teilen stark verändern. Deshalb ist es sinnvoll, den gesamten Modifikationsprozeß in die Datenbankentwurfsgeschichte einzuarbeiten.
Vor Veränderungen der Datenbank ist es sinnvoll, ein Veränderungsszenario zu entwickeln. Dieses Szenario
schließt auch eine Betrachtung der Risiken von Veränderungen mit ein.
Schwierigkeiten und Fallen:
Schritte
1. Streichen von Schema-Objekten
Veränderungen in der Datenbankstruktur können in einigen Systemen nur durch ein vollständiges Entfernen
der Tabellen und anschließenden Neuaufbau bewerkstelligt werden. Dazu gehören Änderungen des Datentypen, das Verbot von Nullwerten, das Streichen einer Spalte, die Änderung von Defaultwerten, Partitionierung, Segmentierung und Kombination von Tabellen, Änderungen des Hashmechanismus, Änderungen in der
Gruppierung und Veränderungen der Abspeicherung. Einige Systeme blockieren während der Dropoperationen andere Benutzer. Sind mit den Relationen, die verändert werden zusätzlich noch andere Relationen, z.B.
durch Trigger verbunden, dann kann die Dropoperation weitreichende Auswirkungen in der Datenbank haben. Das Streichen einer Sicht zieht auch das Streichen aller darauf basierenden Sichten, insbesondere auch
der Sicherheitssichten, nach sich. Sicherer sind deshalb eingeschränkte Dropoperationen, die nur ein Streichen
erlauben, wenn keine anderen abhängigen Relationen existieren. Dann sind jedoch Veränderungen in der Datenbankstruktur nur schwer möglich.
Moderne Systeme generieren deshalb als Antwort auf eine Dropinformation eine Reihe von Warnungen über
die Implikationen der Dropoperation. Erst bei Bestätigung der Auswirkungen als gewünschte Auswirkungen
wird dann die Dropoperation ausgeführt.
Deshalb sollte vor dem Streichen von Relationen der Effekt dieser Operation auf alle Objekte der Datenbank
untersucht werden. Dabei sind alle expliziten und impliziten Integritätsbedingungen besonders zu untersuchen.
Wird eine Streichoperation ausgeführt, dann ist es sinnvoll alle Benutzer von dieser Veränderung zu informieren.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
302
In Systemen, in denen eine Dropoperation automatisch kaskadiert wird, sollten extra Mechanismen vor den
unerwünschten Effekten dieser Operation warnen oder durch eine Rückführung der implizierten Reaktionen
auf eine Dropoperation die Wiederherstellung des korrekten Zustandes ermöglichen.
Pragmatik:
2. Hinzufügen von Schema-Objekten
Das Hinzufügen ist im allgemeinen eine einfache Operation. Implizite Annahmen der Datenbank können jedoch auch davon beeinflußt werden. Dazu gehören Namenskonventionen, Sicherungsmechanismen, Sicherheitsmechanismen und die Authorisierung. Außerdem können die Speichermechanismen davon betroffen sein.
Wird eine Relation hinzugefügt, dann ist auch die Integrität gesondert zu betrachten. Dazu gehören auch Integritätsbedingungen und Erzwingungsregeln.
Pragmatik:
3. Modifikation von Schema-Objekten
Die Modifikation von Relationen kann um ein Vielfaches komplizierter sein als das Hinzufügen. Es kann
sowohl die physische als auch die logische Struktur geändert werden. Änderungen in der physischen Struktur sind z.B. Veränderungen der Speicherzuordnung, von Indexierungen, von Locking- und Pufferstrategien.
Veränderungen in der logischen Struktur sind meist Veränderungen, die sich in der konzeptionellen Struktur
auch wiederspiegeln. Die Modifikation sollte die normale Arbeit mit der Datenbank so wenig wie möglich
beeinflussen. Deshalb erfordert eine Modifikation oft auch die Betrachtung der gesamten Entwurfsgeschichte.
Auswirkungen der Modifikation der Struktur können oft durch entsprechende Sichten verbessert werden. Eine
andere Methode basiert auf der Einführung von Synonymen. Damit wird zwar auch die Performanz der Datenbank beeinflußt, nicht aber die Weiterverwendbarkeit. Dabei ist jedoch auf die Identifizierbarkeit über diese
Sichten zu achten, um eine Modifikation von Daten über Sichten zu erlauben.
Das RENAME und das ALTER Kommando von SQL sollte mit entsprechender Vorsicht angewandt werden.
Werden z.B. Spalten angefügt, die keine Nullwerte oder Defaultwerte enthalten können, dann ist die exisiterende Relation zu modifizieren. Prozesse, die auf einem SELECT * basieren sind in diesem Fall ebenso
zu modifizieren. Weiterhin sind auch entsprechende Performanzbetrachtungen und Speicherstrategien in die
Modifikation einzubeziehen.
Portierbarkeit, Änderungen der Plattform.
Da DBMS bereits sehr komplexe Softwaresysteme sind und sich trotz der Standardisierung von SQL in ihrer Funktionalität stark unterscheiden können ist eine Weiterentwicklung von Systemen kaum vorauszusehen. Einige Schwachpunkte von existierenden Systemen werden in den nächsten Jahren behoben werden.
Datenbanksysteme erfahren eine Erweiterung hin zur Integration objekt-relationaler Technologie. Damit werden
komplexere Typensysteme direkt unterstützt. Mit einer Veränderung der Technologie ist oft eine Veränderung großer
Teile der Implementation erforderlich. Deshalb sollten auch solche Informationen im Entwurf berücksichtigt werden,
die z.Z. noch nicht implementiert werden können. Damit kann eine Verbesserung der Funktionalität von DBMS direkt
aufgenommen werden.
Typische Änderungen sind z.B.:
• Die Integritätsbedingungen werden von Version zu Version immer besser unterstützt.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
303
• Die Optimierer werden mit umfangreicheren Möglichkeiten zur Berücksichtung von Erkenntnissen des konzeptionellen Entwurfs ausgerüstet sein.
• Einschränkungen von Funktionen werden verschwinden.
• Durch Verbesserung der Hardware und der Software wie verbesserte Ein- und Ausgabe wird auch die Funktionalität von DBMS erweitert werden können.
• Die Datenwörterbücher können mehr semantische und funktionelle Information aufnehmen und verarbeiten.
• Es werden verteilte Systeme, offene Systeme und föderierte Systeme geschaffen werden.
Syntax:
Pragmatik:
Schwierigkeiten und Fallen:
Schritte
1. Neue semantische Regeln
Pragmatik:
2. Neue Operationen
Pragmatik:
3. Höhere Performanz
Pragmatik:
HERM-Compiler 11.
Diensteverwaltungssystem.
HERM-Compiler 12.
Erzeugung des Schemas in der Zielsprache.
2.10.6 Besonderheiten der Abbildung auf UML-Strukturen bzw. XML-Strukturen
Entfaltung durch Objekt-Schalen, ggf. mit kontrollierter Schalen-Redundanz
Basis-Schale meist genutzt zur direkten Identifikation
Objekt-Schale mit Objektentfaltung, optionalen Komponenten, Default-Ergänzungen
Sharing-Modell zur gemeinsamen, redundanten Benutzung gemeinsamer Komponenten ggf. mit Vertragsmodell,
Injektionsmodell, Modifikationsstrategie, Notifikationsdienst bei Veränderung
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
304
Inductive and Abstraction Layered Typed Modelling Constructs.
Typically, a model is defined in a certain language. A model language L for a model uses some signature S and
a set of constructors C that allows to build a set of all possible expressions in this language. Typically constructors
are defined by structural recursion [Tha00]. The set of constructors may allow to build expressions that do not fulfill
certain quality or more generally integrity conditions. Therefore we introduce a set ΣS,C well-formedness conditions.
Well-formedness conditions separate ‘normal’ expressions from ‘abnormal’ ones. The later can be separated into
construction abnormality and semantic abnormality. We may allow such abnormalities that are corrigible to normal
expressions. The avoidance of abnormality is still research in progress. Kinds of abnormality that should be handled
within a theory of conceptual modelling are pleonasm (e.g., redundancy), semantic clashes (e.g., contradictions),
Zeugma (e.g., overloading of constructs, combining separable semantic units into one concept), and improbability
(e.g., almost empty classes).
Well-formedness restrictions influence the modelling style [Kle07].
• The Strong Venetian style rigidly separates basic constructs and builds a fully compositional structuring. ER
schemata and UML class diagrams are typically based on this style.
• The Weak Venetian style separates constructs to same degree but not more than it is necessary. Performancetuned physical relational schemata are typically based on this style.
• The Strong Russian Doll style is based on a full expansion of objects, i.e. objects in a database are potentially
expandable through navigational sub-structures.
• The Weak Russian Doll style uses a layered representation similar to tree languages.
ER modelling is typically based on the Salami slice style whereas XML modelling typically uses the strong Russian
doll (DTD style) or the weak Venetian or weak Russian doll (XML schema) style. The weak Venetian blind style is
also the basis for component-based development of models since amalgams constructs as small models of coexisting
and co-evolving facets of objects.
2.10.7 Das regelbasierte Verfahren nach D.W. Embley und O. Sörensen
2.11 Spezielle Modellierungsmethoden für Spezialanwendungen
2.11.1 Besonderheiten verteilter Informationssysteme
Syntax:
Pragmatik: Da die Modellierung der Verteilung eine orthogonale Aufgabe ist, bedarf die Verflechtung der Modellierung von Verteilung und der anderen Modellierungsaufgaben einiger Tricks:
•
•
Schwierigkeiten und Fallen : in der Modellierung bereiten insbesondere folgende Probleme:
1. Die Replikation, die Partitionierung und die Allokation beruhen in diesem Entwurfsstadium meist auf
Schätzungen. Damit sind auch die Resultate in diesem Schritt eher als Näherungen zu betrachten.
Eine Optimalität kann auf diese Art und Weise kaum erreicht werden.
2. Oft wird eine gleichmäßige Auslastung der Rechnerknoten angestrebt. Damit können zwar lokale
Engpässe gut umgangen werden. Aber auch dieser Parameter beruht auf Schätzungen.
Schritte
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
305
1. Analyse der Anforderungen
Es werden Qualitätsparameter wie Datenumfang, Rechtzeitigkeit, einfacher Zugriff, Datenort, Datenzuverlässigkeit, Erreichbarkeit der Daten, bevorzugte Lokalisierung und einfache Pflege der Integrität der Daten analysiert.
Auf der Grundlage dieser Daten kann entschieden werden über die folgenden technischen Strategien:
Qualitätsparameter
Datenumfang
Rechtzeitigkeit
einfacher Zugriff
Datenort
Datenzuverlässigkeit
Erreichbarkeit
Pflege der Daten
Information für Entwurfsschritt
Auswahl der Technologie
Replikationsstrategien
Strukturen
Eigentümer-/Besitzer-/Nutzerstrategien
Eigentümer-/Besitzer-/Nutzerstrategien
Datenermittlung
Backup-/Wiederanlaufprozesse
Unterstützungstrategien
Pflegestrategien
Eigentümer-/Nutzerstrategien
Pragmatik:
Die verschiedenen Qualitätsparameter können benutzt werden, um Entwurfsentscheidungen eventuell einer Revision zu unterziehen. Meist begrenzen diese Parameter jedoch die Wahl der Plattform.
Eine pragmatische und zugleich praktikable Methode zur Beherrschung der Verteilung ist eine Trennung von
Benutzern und Besitzern von Daten. Damit kann Benutzern ein read-only-Zugriff auf einfache Art ermöglicht
werden. Sind mehrere Benutzer Besitzer von Daten und können sie die Daten simultan ändern, dann ist diese
Möglichkeit explizit vorzusehen. Im weiteren ordnen wir den Daten die Besitzer und die Benutzer zu.
Ist der Umfang der Daten zu hoch und werden keine Forderungen nach einer zentralen Verarbeitung erhoben,
dann kann aus der Größe der Datenbank bereits eine minimale Serverkonfiguration abgeleitet werden.
Die Aktualität der Daten beeinflußt direkt die Replikationsfunktionen. Wird eine hohe Aktualität gefordert, dann
kann nur mit einer komplexen Updatefunktion die Aktualität gesichert werden.
Für viele Anwendungen ist ein einfacher und schneller Zugriff für einen Teil der Daten benutzerabhängig unbedingt erforderlich. Deshalb sind die kritischen Anwendungen direkt zu erfassen. Ein Zugriff wird insbesondere
auch durch Namenskonventionen für die Sichten erleichtert. Tuningstrategien sollten sich auf die Anwendungen der einzelnen Knoten beschränken und weniger auf das allgemeine konzeptionelle Schema der gesamten
Anwendung über alle Knoten hinweg. Müssen allen Benutzern alle Daten zur Verfügung stehen, dann wird
dadurch die Sharingstrategie und die Replikationsstrategie beeinflußt.
Da die gleichen Zugriffe nicht an verschiedenen Standorten zur gleichen Zeit parallel ausgeführt werden sollen, werden durch die erwartete Funktionalität der Knoten auch die Datenermittlung, die Anfrageverarbeitung
und die Modifikationsprozeduren beeinflußt. Je mehr Funktionen an allen Standorten zur gleichen Zeit benötigt
werden, umso sorgfältiger muß die Verteilung entworfen werden.
Um einen Wiederanlauf und eine Backup-Funktionalität zu unterstützen, werden diese Funktionen beim Entwurf der Knoten mit berücksichtigt. Treten Zuverlässigkeitskonflikte auf, dann sind sowohl der Besitzer als
auch die Benutzer zu informieren.
Die Verfügbarkeit von Daten auf verschiedenen Knoten kann durch häufige Anforderungen von anderen Knoten
mit beeinflußt werden. Deshalb kann auch eine Veränderung der Netzarchitektur notwendig werden.
Die Integrität von Daten ist einfacher zu pflegen, wenn nur ein Knoten über Modifikationsrechte verfügt. Um
die Integrität zu pflegen, können Trigger, stored procedures und die referentielle Integrität auf logischem Niveau
entworfen werden. Dabei ist jedoch zu sichern, daß keine Zyklen auftreten können. Diese Information liegt bereits für das konzeptionelle Schema vor. Eine Betrachtung des logischen Schemas ist deshalb nicht notwendig.
Die vorliegende Information ist deshalb zu nutzen, um einen einfachen Mechanismus zur Pflege der Integrität
abzuleiten. Um unnötige Modifikationen zu vermeiden, sobald Daten nicht mehr auf einem Knoten benötigt
werden, ist eine explizite Operation zum Entfernen aller Daten sinnvoll.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
306
2. Analyse der Architektur des Netzes
In diesem Schritt werden die Funktionen der einzelnen Knoten analysiert. Dazu werden die einzelnen Dialogobjekte, Sichten und Funktionen der Knoten auf ihre Realisierbarkeit untersucht. In Abhängigkeit von diesen
Funktionen ist das Schema zu optimieren. Bei der Optimierung werden sowohl die Anforderungen der Benutzer
für die jeweiligen Knoten analysiert, als auch die Möglichkeiten zur Bereitstellung von aktuellen Informationen
für die jeweiligen Knoten.
Jedem Benutzer werden seine Knoten zugeordnet. Dabei werden sowohl die funktionalen Anforderungen als
auch die Anforderungen an die Sichten berücksichtigt.
In diesem Schritt wird auch eine allgemeine Replikationsstrategie entwickelt. Falls eine Pflege der Replikate
durch ein paralleles Verschicken aller Modifikationstransaktionen erfolgt, dann wird jede Modifikation nachgezogen. Es kann auch ein Schnappschuß der modifizierten Daten an die Replikate versandt werden, deren Daten
in den Knoten modifiziert werden. Ist eine Charakterisierung der durch das Replikat benötigten Daten möglich,
dann kann die versandte Menge weiter eingeschränkt werden. Kann man für Klassen deduktive Normalformen
einführen, dann kann die Menge der versandten Objekte weiter eingeschränkt werden.
Für die einzelnen Knoten sind entsprechende load, unload und send Funktionen zu entwickeln.
In analoger Form ist eine cancel Funktion zu entwickeln.
Pragmatik:
Bei der Analyse der Anforderungen in den einzelnen Knoten kann nach folgendem Schema für jede einzelne
Klasse vorgegangen werden:
(a) Es wird die Granularität für das Datensharing analysiert. Dabei werden auch die beizubehaltenden Daten
(ankernde Daten) und die Beziehungen der Daten (Identifikationsbeziehungen etc.) analysiert.
(b) Es wird das Verhalten der Benutzergruppe modelliert, die für die Modifikation und die Bereitstellung
der Daten verantwortlich ist. Dabei werden die entsprechenden Prozesse bzw. Funktionen dieser Benutzergruppe zugeordnet. Falls eine bereits normalisierte Klasse unterschiedlichen Benutzern aus dieser
Gruppe zugeordnet wird, dann ist das gemeinsame Benutzen der Daten zu spezifizieren. Gegebenenfalls
ist eine horizontale Dekomposition die Lösung. Die Benutzergruppe ist den einzelnen Knoten zuzuordnen.
Falls verschiedene Benutzer unterschiedliche Daten einbringen, dann kann ebenfalls durch horizontale
Dekomposition eine einfachere Pflege möglich sein.
(c) Es wird das Verhalten der Benutzergruppe analysiert, die die Daten im Wesentlichen für Anfragen benutzt.
Dazu werden deren Prozesse, Funktionen, Sichten und Dialogobjekte betrachtet sowie die Knotenzuordnung. Außerdem wird für jede Klasse analysiert, inwieweit ein Benutzer die gesamte Klasse benötigt.
3. Entwicklung einer Architektur (Partitionierung , Replikation der Daten)
Auf der Grundlage der nun bekannten Information können nun die Operationen für die Entwicklung einer
Verteilung herangezogen werden. Für jede Operation wird die Knotenmenge berechnet, die für diese Operation
herangezogen werden muß. Es werden die horizontalen, vertikalen und gemischten Partitionierungen für die
verschiedenen Anwendungen betrachtet.
Vertikale
Partitionierung
vs.
horizontale
vs.
gemischte
Pragmatik:
Sowohl für die horizontale, als die vertikale oder gemischte Partitionierung können verschiedene Operationen herangezogen werden. Zu jeder Operation werden die benötigten Klassen und deren Verbindungen (z. B.
über Relationshiptypen) explizit dargestellt. Darauf aufbauend kann für eine Klasse die Teilmenge bestimmt
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
307
werden, die für eine statistisch homogene Auslastung der Teilmengen innerhalb der betrachteten Operationen
und für die Existenz unterschiedlicher Anwendungen für mindestens zwei verschiedene Partitionen sorgen. Eine Klasse wird so in Teilmengen zerlegt, daß jede von ihnen ausreichend für eine entsprechende Operation
ist. Damit ist eine horizontale Partitionierung ableitbar. Oft ist dies nur bei Anwendung der 80/20%-Regel
möglich. Um eine feinere Granularität zu erreichen, können auch die Klassen- bzw. Teilmengengröße, die Zugriffshäufigkeit und die mittlere Trefferrate mit einbezogen werden. Damit kann auch eine Betrachtung der
Relevanz einer Klasse für einen Knoten erfolgen. Die Relevanz ist definiert über die Proportion der Trefferquote zur ‘Nicht’trefferquote.
Analog kann für den Fall der abgeleiteten horizontalen Partitionierung vorgegangen werden. Da der EquiVerbund für eine Darstellung von Hierarchien günstig ist, kann in diesem Falle auch eine Hierarchie unterstützt
werden.
Sind mehrere horizontale Partitionierungen gleich günstig, dann wird man die Partitionierung mit den wenigstens Verbunden bzw. die für eine größere Anzahl von Anwendungen benötigte wählen. Der Verbundgraph kann
in diesem Fall herangezogen werden.
Die vertikalen Partitionierung erfordert eine genaue Betrachtung der Integritätsbedingungen. Die Vielfalt ist
wesentlich höher. Durch Gruppierung und Splittung kann die kombinatorische Vielfalt etwas eingedämmt werden. Für eine vertikale Dekomposition wird die Affinität der Komponenten betrachtet. Für Komponenten, die
nicht zur (primären) Identifikation benötigt werden, wird eine Bewertung der diese Komponenten verwendenden Operationen vorgenommen (Benutzungswert). Analog wird berechnet, inwieweit für Paare von Komponenten entsprechende Operationen existieren (Affinität). Darauf aufbauend kann eine Affinitätsmatrix entwickelt
werden. Diese Matrix wird auf separierbare Teile untersucht. Kann eine Gruppierung in der Matrix vorgenommen werden, dann kann auch das Schema in dieser Form gruppiert werden. Gruppierungen können nach
verschiedenen Algorithmen (bond-Algorithmus; Algorithmen, die die Masse von Komponenten einbeziehen)
abgeleitet werden. Auf dieser Grundlage wird ein allgemeines Affinitätsmaß entwickelt. Mit jeder Modifikation
der Datenbank ist dann ein entsprechender Netzbeitrag zur Komplexität abschätzbar. Auf dieser Grundlage
werden Typen separiert.
Analog kann im Falle der vermischten Partitionierung vorgegangen werden.
Die abgeleiteten Partitionierung werden auf ihre Korrektheit geprüft (Vollständigkeit, Rekonstruierbarkeit, Disjunktheit).
4. Allokation der Daten und Prozesse
Für eine Menge von Partitionen F = {F1 , ..., Fn }, ein Netz mit den Knoten S = {S1 , ..., Sm } und eine Menge
von Anwendungen Q = {q1 , ..., qq } wird nun eine optimale Verteilung von F auf S gesucht.
Die optimale Verteilung wird bestimmt durch
(a) die minimalen Kosten und
(b) die Performanz.
Dabei werden die Kosten bestimmt aus
Speicherkosten für das Speichern von Fi auf Sj ,
Anfragekosten für das Berechnen einer Anfrage über Fi auf Sj ,
Modifikationskosten für die Modifikation von Fi auf allen Knoten und
Kommunikationskosten.
Es gibt bislang kein allgemeines Kostenmodell. Ein einfaches Modell kann wie folgt entwickelt werden für
eine Partition Q1 und Q2 von Q nach retrieval-only-Anfragen und Modifikationsanfragen:
Für ein Partition Fk betrachten wir die folgenden Kosten
retrieval-only-Verkehr für die Knoten
Tk = {t1 , ..., tm } ,
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
308
update-Verkehr für die Knoten
Uk = {u1 , ..., um },
Kommunikationsosten für retrieval
C(Tk ) = {c12 , c13 , ..., c1m , ..., cm−1,m }
Kommunikationsosten für update
C 0 (Uk ) = {c012 , c013 , ..., c01m , ..., c0m−1,m }
Speicherkosten für die Partition
D = {d1 , ..., dm }
unter der Voraussetzung, daß keine weiteren Kapazitätsbeschränkungen gelten.
Dann kann für die Booleschen Plazierungsvariablen xj mit
½
1 falls Fk in Sj
xj =
0 falls Fk nicht in Sj
optimiert werden nach der folgenden Formel für Teilmengen I von S, in denen Fk gespeichert wird:




m
X
X
X

.
xj dj 
min 
xj uj c0ij + tj min cij  +
i=1
j|Sj ∈I
j|Sj ∈I
j|Sj ∈I
Diese Optimierung ist trotz der starken Vereinfachung NP-vollständig. Sie stellt nur ein Näherung dar, weil
Partitionen stärker strukturiert sind, der Zugriff zu einfach dargestellt wird, die Kosten für die Erzwingung der
Integrität nicht erfaßt wurden und die Kosten für parallele Zugriffe nicht berücksichtigt sind. Deshalb wählen
wir im weiteren ein Modell, das auf folgenden Informationen zur Anwendung und zur Modellierung beruht:
Datenbankinformationen: Selektivität seli (Fj ) einer Partition Fj für eine einzelne Anfrage qi und
die approximative Größe der Partition size(Fj ) ;
Anwendungsinformation: Anzahl der Lesezugriffe RRij für Anfragen qi über einer Partition Fj
Anzahl der Updatezugriffe U Rij für Anfragen qi über einem Partition Fj
½
1 falls Anfrage qi modifiziert Fk
uij =
0 falls Anfrage qi modifiziert Fk nicht
½
1 falls Anfrage qi liest Fk
Rij =
0 falls Anfrage qi liest Fk nicht
O = {o1 , ..., oq }
für jede Anfrage eine maximal tolerierbare Antwortszeit
oi Ausgangspunkt von qi
Knoteninformation: Speicher- U SCk und Berechnungskapazität LP Ck
Netzinformationen: Kommunikationskosten gij pro Kommunikationseinheit
Kanalkapazität, Abstände zwischen den Knoten, Protokolloverhead usw.
Auf dieser Grundlage kann ein allgemeines Kostenmodell unter Berücksichtigung der Beschränkungen für die
Antwortzeit, die Speicherzeit und die Berechnungszeiten erstellt werden.
Pragmatik:
Das allgemeine Kostenmodell kann oft zu komplex sein. Deshalb kann man für den Grobentwurf der Verteilung
auch auf die folgende Art vorgehen.
• Es wird für die Daten nach einer ‘Server/Client’-Verteilung der Daten - wie bereits oben mit dem Besitzer/BenutzerModell eingeführt - anhand der Lokalisierung der Besitzer und Benutzer eine optimale Topologie ermittelt, die untersucht, welche der folgenden Varianten günstiger ist:
•
•
•
•
Zentralisierung der Daten,
Verteilung der Daten nach Besitzern,
Verteilung der Daten nach Benutzern,
Verteilung der Daten nach Besitzern und Benutzern,
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
309
• Abwägen der Vor- und Nachteile eines zentralen Managements.
• Es werden technische Strategien abgeleitet, mit deren Hilfe den Anforderungen der Anwendung in hinreichend kurzer Zeit genügt werden kann und die die entwickelte Partitionierung und Replikation hinreichend gut unterstützen.
• Darauf aufbauend wird ein Pflichtenheft für den Netzentwickler abgeleitet.
Bewertung der Resultate.
Mit dieser einfachen Methodik kann die Verteilung einer Datenbank für diese Phase des konzeptionellen
Entwurfes hinreichend genau spezifiziert werden. Genauere Anpassungen müssen vorgenommen werden, sobald die
Plattformen hinreichend genau bekannt sind. Dazu können entsprechende Werkzeuge benutzt werden.
2.11.2 Modellierung von Datenbank-Farmen
Datenbank- und Informationssysteme sind meist in einer integrierten Form verfügbar. In unserer Universitätsanwendung kann z.B. neben dem Informationssystem zur Stundenplanung auch ein Informationssystem zur Verwaltung von
Studentendaten geführt werden. Ein Bestandteil eines solchen Informationssystemes ist z.B. die Erfassung zu Daten
zu erworbenen Scheinen und zur erfolgreichen Teilnahme an Lehrveranstaltungen. Deshalb wird eine Archivierungssicht auf das Informationssystem zu den Lehrverantaltungen benutzt, um diese Daten in die Studenten-Datenbank
einzupflegen. Diese Archivsicht ist in Bild ?? dargestellt.
Eine Datenbank-Farm verwendet die Architektur in Bild 77.
Play-InSystem
Play-OutSystem
DatenbankWarenhausSystem
SpeicherMaschine
Abbildung 77: Die Architektur von Systemen von Datenbank-Farmen als verallgemeinertes Datenbank-Warenhaus
2.11.3 Besonderheiten bei der Modellierung von inkrementellen Datenbanksystemen
Bereits für die Entwicklung der Funktionalität haben wir die induktive Definition von Relationship-Typen genutzt.
Für Relationship-Typen sind über eine versteckte Annahme für das Verändern und Einfügen von Komponenten Modifikationsoperationen nur in eingeschränkter Form definiert. Analoge Annahmen können wir in der Sichtenkooperation
von Datenbank-Farmen machen. Es wird ein System oder eine Sicht entweder Zentral-System, in dem alle Operationen uneingeschränkt definiert sind, oder abhängiges System, das einen Teil seiner Daten aus einem anderen
System bezieht und deshalb diese Daten nur in Zusammenarbeit mit dem anderen System ändern kann.
Incremental evolution is thus supported by star and snowflake sub-schemata by:
Injection forms enable to inject data into another database. The forms are supported by views and view cooperation
approaches. Data injected into another database cannot be changed by the importing database system. The
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
310
auxiliary
database
auxiliary
database
auxiliary
database
auxiliary
database
injected
?
DBS
(S p , ΣS p , Op , ΣOp )
injected
?
DBS
(S c , ΣS c , Oc , ΣOc )
injected
?
DBS
(S r , ΣS r , Or , ΣOr )
injected
?
DBS
(S m , ΣS m , Om , ΣOm )
insert
inject
modifiable
-
insert
-
inject
injected
planning
phase DBS
modifiable
-
insert
-
inject
injected
construction
phase DBS
modifiable
-
injected
realization
phase DBS
maintenance
phase DBS
Abbildung 78: The General Architecture of Incremental Evolution of Database Systems
structuring (S inject , ΣS ) of the views of the exporting database system is entirely embedded into the structuring
0
(S , ΣS 0 ) of the importing database system. The functionality (Oinject , ΣO ) of the views of the exporting
0
database system is partially embedded into the functionality (O , ΣO0 ) of the importing database system by
removing all modification operations on the injected data. These data can only be used for retrieval purposes.
Insertion forms enable in insertion data from the exporting database into the importing database. These data can
be modified. The structuring (S insert , ΣS ) and the functionality (Oinsert , ΣO ) of the views of the exporting
0
0
database system are entirely embedded into the structuring (S , ΣS 0 ) and the functionality (O , ΣO0 ) of the
importing database system.
2.11.4 Besonderheiten der Entwicklung von Datenbank-Warenhäusern
Units generator
Unit, applet,
data provider
OLTP
data
Foreign
Data
Legacy
Data
Purger
Storage
Workspace
Gate
User profiles
Payment
manager
Active acquisition
Data suites
Access, history
manager
-
Micro-data
- import
export
- tools
-
Content
management
system
OLAP/DW System
Macro-data
- extractors
database
mining
-Anonymous
user
- Business
unit user
- EIS/DSS
user
Abbildung 79: Data Warehouse Architecture of the DaMiT System
Typisches Beispiel: Document systems should be supported by a specific data warehouse architecture:
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
311
Play-out servers present, store and protect released content. The play-out of documents depends on their usage.
Typical widely used documents are documents used in logistics:
• Bills have their own numbering and their own format. They serve also as an contract of carriage between
shipper and carrier.
• Certificate on the content and the origin of the contents are used for statistical research, and for accessing
duties, particularly under trade agreements.
• Invoices declare against which payment is made. They are used for clearing documents.
• Dock receipts are issued by the forwarder on experter’s behalf. They include shipment description, physical details, and shipping information.
• Bills of lading are used as contracts between carrier and shipper, spell out legal responsibilities and liability limits for all parties to the shipment.
• Packing lists provide details on the packing procedure of the container.
• Sight, time drafts instruct the buyer’s bank to collect payment.
Production servers have controlled access to documents and host dockets.
Specific docket servers manage trusted content exchange between the servers.
Generic docket servers communicate and encapsulate value-adding services.
Für die drei Komponenten ergibt sich bei der Entwicklung das folgende Aufgabenspektrum:
Akquisition
Speicher
Zugriff
Lösungsentwicklung
Datenidentifikation
Daten-Sourcing
Daten-Sourcing
Validierung der Integration
Validierung der Integrität
Synchronisation
Synchronisation
Entwicklung f. Rückkoppl.
Speicherarchitektur
Speicherarchitektur
Transform.-abbildungen
Transform.-abbildungen Transform.-abbildungen
Qualitätsprüf.
Qualitätsprüfung
Qualitätsprüfung
DB-Modellierung
DB-Entwurf
Dabei können wir anhand der bislang betrachteten Entwurfsmethode folgende Regeln beim Entwurf betrachten:
1. Akquisition, Speicherung und Zugriff bilden eine Einheit.
2. Aufgrund der Komplexität ist die Dekomposition von Geschäftsprozessen notwendig.
3. Die Anwendungen sollten voneinander separiert werden.
4. Autonome Anwendungen können auch parallel entwickelt werden.
Damit kann auch das Aufgabenspektrum während der einzelnen Entwicklungsschritte für die unterschiedlichen Gruppen, die im Entwicklungsprozeß teilnehmen, abgeleitet werden:
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
312
Schritt
Exporteure
Benutzer Programmierer
1. Lösungsentwicklung
stark
mittel
2. Datenidentifikation
mittel
stark
3. Daten-Sourcing
stark
leicht
mittel
4. Validierung der Integrität
leicht
mittel
stark
5. Synchronisation
leicht
stark
6. Entwicklung f. Rückkopplung stark
stark
7. Speicherarchitektur
stark
8. Transformationsabbildungen
stark
9. Qualitätsprüfung
leicht
leicht
stark
10. DB-Modellierung
leicht
stark
11. DB-Entwurf
stark
In analoger Form können die Komponenten, auf die sich die Entwicklungsschritte konzentrieren, herausgestellt werden:
Schritt
Akquisition
Speicher Zugriff
1. Lösungsentwicklung
stark
2. Datenidentifikation
stark
3. Daten-Sourcing
stark
leicht
4. Validierung der Integrität
stark
leicht
5. Synchronisation
stark
leicht
6. Entwicklung f. Rückkopplung stark
7. Speicherarchitektur
stark
mittel
8. Transformationsabbildungen
stark
stark
stark
9. Qualitätsprüfung
stark
stark
stark
10. DB-Modellierung
stark
11. DB-Entwurf
stark
Mit diesen Aufgaben ergeben sich im Einzelnen für die Schritte die folgenden Aufgaben:
1. Lösungsentwicklung: Es wird eine software-technologische Analyse durchgeführt, die zu einer Spezifikation
der Anforderungen im Rahmen eines Pflichtenhefts führt und die klärt, inwieweit durch eine Warenhausanwendung die derzeitige Situation verbessert wird.
2. Datenidentifikation: Es werden die benötigten Daten und darauf aufbauend die benötigten Datenbestände identifiziert.
3. Daten-Sourcing: Es werden die Charakteristika der benötigten Datenbestände erfaßt und mit den Anforderungen verglichen.
4. Validierung der Integrität: Es wird die Semantik der ausgewählten Datenbestände erfaßt (Identifikation, Population (Formate, Vollständigkeit, ...), Verletzungen, Pflegeroutinen, etc.).
5. Synchronisation: Die Datenbestände müssen für das Warenhaus im Rahmen einer Synchronisationsphase vereinheitlicht oder integriert werden oder zumindest in ihren Beziehungen beschrieben werden. Es werden referentielle Integrität (Benutzungsabhängigkeiten, Standardisierung der Population, Standardisierung der Beziehungen der Datenbanken untereinander) erfaßt, Zeitbeschränkungen (Zeit der Gewinnung der Daten, letzte
schreibende Transaktionen auf den Daten, Erfrischungen der Daten), Zugänge zur Korrektur der Verletzungen
der Integrität und Routinen, die zur Benutzung der Datenbestände erforderlich sind. Außerdem werden die
Identifikation auf Redundanz geprüft, entsprechende Hierarchien entwickelt, etc.
6. Entwicklung f. Rückkopplung: Für die Entwicklung von Durchgriffsmöglichkeiten stehen eine Reihe von Mechanismen aus der Technologie reaktiver Systeme zur Verfügung.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
313
7. Speicherarchitektur: Es existieren eine Reihe von unterschiedlichen Herangehensweisen für die Speicherarchitektur wie:
• Tabellen der relationalen Technologie,
• Verweistabellen auf die Quellensysteme,
• kodierte Tabellen,
• assoziative Verbundtabellen (bridge/cross-reference table),
• gemischte Tabellen,
• Teilmengen-Tabellen,
• aggregierte Tabellen (summarization roll-up tables) und
• historische Tabellen.
Dabei muß für eine effiziente Hauptspeicherverwaltung eine Lösung wie im Falle großer Datenbanken gefunden werden.
8. Transformationsabbildungen: Nun kann die eigentliche Integrationsaufgabe in Angriff genommen werden. Die
Datenstrukturen werden analysiert und die Transformationsabbildungen werden entwickelt.
• Wie im Datenbankentwurf werden zuerst die Identifikationsprobleme gelöst.
• Es wird ein Abhängigkeitsgraph der Sourcedaten und ihrer Funktionen erstellt.
• Es wird eine Liste der Transformations- und Reinigungsschritte erstellt.
• Darauf aufbauend werden die Transformationsprogramme entwickelt, die auch eine Reinigung der Daten,
ein Mischen der Daten, ein Restrukturieren der Daten je nach Bedarf mit einschließen.
• Es wird schrittweise ein Datenwörterbuch erstellt, das auch Synonyme, Homonyme und Namenskonzepte
mit erfaßt. Darauf aufbauend wird ein Speicherplan erstellt.
• Für die Transformationen wird ein Diagramm erstellt.
9. Qualitätsprüfung: Dazu sind eine Reihe von Daten zu erfassen.
• Benutzungsschätzungen: Es werden Schätzungen
für die Anzahl der Benutzer,
für die Häufigkeit und Art ihrer Zugriffe,
für den Arbeitsraum, den die Benutzer benötigen,
für die Plattformen der Benutzer und
für die Performanzanforderungen entwickelt.
• Umfang der Daten: Umfangreiche Datenbanken sind ein Gewinn für das Warenhaus, können aber aufgrund ihrer Performanzanforderungen die Rechenpotenzen von Superrechnern erfordern. Es kann notwendig werden, leistungstarke symmetrische Multiprozessorsysteme (SMP) oder massiv-parallele Systeme (MPP) einzusetzen. Sowohl zur Aufbereitung der Sourcedaten als auch zur Bearbeitung von Anforderungen kann bereits eine solche Datenmenge anfallen, die SMP oder MPP benötigt.
• Zugriffsraten und Prozeßabschätzungen: Darauf basierend werden die Prozeßanforderungen abgeleitet.
Auf der Grundlage dieser Daten kann analog zu Methoden des Benchmarkings eine Bewertung der Qualität
erfolgen.
Abschließend sollte ein Vergleich mit den Möglichkeiten anderer Systemlösungen erfolgen.
10. DB-Modellierung: Der Datenbank-Modellierungsprozeß entspricht dem Vorgehen für ‘normale’ Datenbanken.
• Es werden alle Datenstrukturen der Sourcedaten und der Warenhausdaten erfaßt.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
314
• Es werden die Prozesse zur Transformation und die Prozesse für die Auswertung der Daten erfaßt.
• Es werden die Drehbücher für die Benutzung erstellt.
• Es werden die Sichten der Benutzer und die Prozesse mit den Dialogen abgeglichen.
Damit entsteht ein komplexes Vorschema der Daten, Prozesse, Handlungen und Sichten auf das Warenhaus.
11. DB-Entwurf: Nunmehr kann auch der konzeptionelle, logische und physische Entwurf angeschlossen werden.
Das Datenbank-Warenhaus verwendet auch die Lösung eines alten Integrationsproblemes: Anstatt für eine Anwendung
µ ¶
n
2
verschiedene Schnittstellen zwischen den Anwendungen zu entwickeln, wird eine lose Integration - in unserem Fall
eine Reduktion und anschließende Integration - vorgenommen.
2.12 Modellierung von Sicherheitsmechanismen
2.12.1 Design-By-Units und lokale komponentenbasierte Sicherung
Im Design-by-units-Zugang unterscheiden wir zwischen dem Retrieval und Manipulationsanforderungen.
die folgende Skizze schematisiert den Zugang.
Informationseinheiten
Container
Manipulationsanforderungen
Im erweiterten ER-Modell können spezifische Sicherheitsarchitekturen ebenso spezifiziert werden:
Autorisierte Operation (
< Akteur >
< Sicht >
< zugelassene Operationen >
)
< Korrektheitsbedingung >
Diese Form ist relativ einfach als Sicherheitkonzept sowohl durch Sichten als auch durch Funktionalität unterstützbar.
2.12.2 Sicherheitsarchitekturen
Sichten zur Unterstützung von Sicherheit.
Im allgemeinen wird oft eine dreistufige Architektur bevorzugt:
Basisrelationen
Sicherheitssichten Sicherheitssichten für Retrieval
Sicherheitssichten für Manipulationsanforderungen
Arbeitsssichten Arbeitssichten für das Retrieval
Arbbeitssichtensichten für Manipulationsanforderungen
Benutzergruppen-orientierte Sichten sind die direkten Arbeitssichten der Benutzer.
Retrieval-Sichten
Sichten für Manipulationsanforderungen
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
315
Nutzung der Daten-Warenhaus-Architektur als Sicherheitskonzept.
LEHRBRIEF
Modellierung und Konzipierung von Sicherheitskonzepten.
Syntax:
Pragmatik:
Schwierigkeiten und Fallen:
Schritte
1. Abschottung durch Sichten
Mit diesem Hintergrund können wir folgende Schritte entwerfen:
Zugriff erfolgt nur über die Sichten: Die gesamte Dialogstruktur sollte nur auf Sichten aufsetzen. Ein direkter Zugriff auf die Datenstrukturen sollte vermieden werden. Deshalb werden die Sichten direkt mit den
einzelnen Dialogschritten gekoppelt.
Da Sichten auch zur Herstellung der Unabhängigkeit von Daten dienen, sollte die gesamte Oberfläche auf
Sichten abgestellt werden. Damit werden die folgenden Ziele verwirklicht:
Vereinfachter Zugriff für den Endbenutzer. Durch Sichten können auch komplexere Manipulations- bzw.
Zugriffsoperationen modularisiert dargestellt werden. Damit wird für den Endbenutzer die Arbeit mit
der Datenbank erleichtert.
Verbesserung der Produktivität für den Benutzer und den Programmierer. Durch die Einführung von
Sichten werden auch von verschiedenen Dialogen benötigte Proozesse im Rahmen einer Lokalisierungsabstraktion miteinander wiederbenutzbar verwoben.
Benutzung von Synonymen für Typen und abgeleitete Daten. Synonyme können die Transparenz der
unterlegten Datenbankstrukturen und die Anwendungsbezogenheit von Namen verbessern.
Zugriffs- und Authorisierungsbeschränkungen. Der Zugriff und die Authorisierung wird an die spezifische Sicht angepaßt und erlaubt wie bei abstrakten Datentypen nur den Zugriff auf diese Sichten,
nicht aber auf die anderen Sichten.
Integration bzw. Kombination über zentrale Sichten: Durch zentrale Sichten kann die Behandlung der unterschiedlichen Aspekte der Anwendung, deren Behandlung die Sichten dienen, vereinheitlicht und mit
einem einfacheren Prozeßmanagement versehen werden. Damit entsteht eine Abbildungsstruktur zwischen verschiedenen Sichten wie im Bild 98.
Da die zentralen Sichten auch an das integrierte Schema angepaßt werden können, haben diese Sichten
keine update-Beschränkungen. Sie sind damit für die Programmierung einfacher zu handhaben.
Zugriffssichten für den read-only-Zugriff: Sichten können eine komplexe Syntax, die eine Vielzahl von
Fällen wiederspiegeln muß, vermeiden. Solche Sichten können auch benutzt werden, um den Zugriff
einzuschränken.
Integritätspflege über zentrale Sichten: Statt die Integritätspflge nur über das zentrale Schema zu definieren, können die zentralen Sichten aufgrund der Nichtbeschänkung des Zugriffs und der update-Operationen
eher für die Pflegeoperationen benutzt werden.
IS ADD
CAU zu Kiel, IfI, ISE, β
Beantragungssicht
Genehmigungssicht1
2. Strukturierung von IS
Genehmigungssicht2
Abrechnungssicht
ab SS 2012
VerGenehmiGenehmigungsgungsbuchungssicht3
sicht4
sicht1
R Zentrale
? ª
316
Verrechnungssicht1
R Zentrale
? ª
Beantragungssicht
Verbuchungssicht
...
Verrechnungssicht4
R Zentrale
? ª
Verrechnungssicht
¼
z
U
?
Integriertes Datenbankschema zum Dienstreiseantrag
Abbildung 80: Sichtenintegration in unserer Anwendung
Einbettung der Sichten in die Dokumentation: Zur Sichtendefinition gehört neben der Strukturdefinition,
der Verbindung zu den Dialogen und der Definition der Beziehung zu Prozessen auch eine Information
über den Entwerfer bzw. Besitzer, Synonymen, zum Status (wie z.B. Test, Version, Kopie), zur Verbindung mit den zentralen Sichten, zur Pflege und Monitoring.
Definition von Sicherungsmechanismen über zentrale Sichten: Sichten sind günstig, um den Zugriff zu
beschränken, aber sie sind nicht ausreichend, um die Datensicherheit zu gewährleisten. Meist kann man
die Sicherheit auch durch die zentralen Sichten pflegen. Oft ist dies aber nicht ausreichend. Deshalb kann
man den zentralen Sichten auch Sicherheitssichten zur Gewährleistung der Sicherheit beiordnen. Damit
ergibt sich eine Hierarchie in den Sichten wie in Bild 99.
Benutzersichten
zur Vereinfachung
des Zugriffs
Beantragungssicht
Genehmigungssicht1
?
?
Zugriffsbeschr.
Genehmigungssicht1
Zugriffsbeschr.
Beantragungssicht
Sicherheitssichten
zur Kontrolle
des Zugriffs
Zentrale
Sichten
zur Darstellung
der Unabhängigkeit
Integriertes
Schema
zur Darstellung
der Speicherung
Genehmigungssicht2
...
?
Zugriffsbeschr.
Genehmigungssicht2
?
ª
Zentrale
Beantragungssicht
...
R
...
z
Integriertes Datenbankschema zum Dienstreiseantrag
Abbildung 81: Ausschnitt aus der Sichtenarchitektur mit Sicherheitssichten
Damit sind die Sichten der Blätter nach wie vor sichtbar für jedermann. Zugleich wird damit aber der
weitere unbefugte Einblick verwehrt.
Damit kann für die Sicherheitssichten die Anbindung an die Aktoren und deren rollen erfolgen. Nach
außen ist aber durch ein
GRANT ALL ON benutzersichten TO PUBLIC
die Sicht einheitlich frei.
Definition einer Authorisierungstabelle zur Kontrolle des Zugriffs: Die Authorisierungstabelle stellt den
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
317
Zusammenhang zwischen den Sichten, einzelnen Dialogschritten und den Aktoren her. Aktoren können
ihre Rechte bedingt oder bedingungslos weitergeben.
Bevorzugung der Standardprozeduren zur Integritätspflege: Die durch ein DBMS vorgegebenen updateKommandos schließen eine Pflege der Integrität nicht ein. Deshalb sollten diese Kommandos zugunsten
der bereits entworfenen Routinen zur Integritätspflege verboten werden. Die Routinen zur Integritätspflege können jedoch der Definition der Sicherheitsanforderungen zuwider laufen. Deshalb ist die Konsistenz
dieser beiden unterschiedlichen Anforderungen zu überprüfen.
Unterbindung des Zugriffs auf physische Strukturen: Die Veränderung der Standardprozeduren zur Integritätspflege sollte den Systemadminstratoren vorbehalten bleiben. Haben Benutzer eigene Mechanismen entwickelt, dann sollten die neuen Pflegemechanismen diesen Benutzer vorbehalten bleiben. Einige
DBMS erlauben nicht die Beschränkung der Rechte auf einen Zugriff von der Beschränkung der Rechte
auf Spaltennamen zu unterscheiden. Damit ist auch einem Benutzer die Veränderung der Tabellenstruktur
möglich. Diese Rechte sollten speziell eingeschränkt werden.
Pragmatik:
Zugriff erfolgt nur über die Sichten: Durch eine Vielzahl von Sichten, unterschiedliche Zugriffsmechanismen etc. können jedoch auch eine Reihe von Problemen entstehen. Insbesondere ist die Vielfalt der Sichten
zu verwalten, wodurch ein overhead entsteht.
Wildwuchs von Sichten: Werden insbesondere Dialoge verfeinert, die Rechte und Rollen der Benutzer
verändert, dann entstehen oft weitere Sichten, die einer Verwaltung durch das System bedürfen.
Wildwuchs von Namen: Durch eine Vielfalt von Namen kann auch der semantische Zusammenhang
zwischen diesen Namen verloren gehen. Dies kann durch die Benutzung von guidelines und Synonymwörterbüchern vermieden werden.
Wildwuchs von Programmen: Der Zusammenhang zwischen den Sichten muß sich auch in einem Zusammenhang zwischen den Sichten wiederspiegeln. Die einfachste Methode, Wildwuchs zu vermeiden, ist ein Verbot der Benutzung kombinierter Sichten.
Funktionelle Beschränkungen im Zusammenhang mit speziellen Sichten: Da insbesondere Updates über
Sichten kritisch sind, werden verschiedene Operationen über den Sichten nicht erlaubt sein. Dieser
Umstand kann für die einzelnen Benutzer nicht mehr nachvollziehbar sein.
Integration bzw. Kombination über zentrale Sichten: Die Kombinationsregeln und die Integrationsregeln
sollten im Rahmen der Entwurfsdokumentation explizit niedergelegt werden.
Zugriffssichten für den read-only-Zugriff: Durch ein striktes ‘hiding’ wird evt. auch zuviel an Information dem Benutzer vorenthalten. Deshalb ist auch in diesem Schritt die Dialogmenge mit in die Betrachtung
einzubeziehen.
Integritätspflege über zentrale Sichten: Durch eine sichtenorientierte Integritätspflege können die Pflegemechanismen auch in modularer Form entwickelt werden. Damit sind Überschneidungen, die auch Zyklen
hervorrufen können, eher zu vermeiden.
Einbettung der Sichten in die Beschreibung: Bezeichner sollten für den Benutzer einfach mit dem Inhalt
verknüpfbar sein. Zentrale Sichten können im Namen bereits auch einen Hinweis auf den Integrationsmechanismus geben. Im integrierten Schema kann die Wahl der Bezeichner bereits anhand der gewünschten
Transformation in das logische Modell erfolgen.
Definition von Sicherungsmechanismen über zentralen Sichten: Die Trennung von Zugriff und Sicherung bringt einen overhead mit sich, denn man in die operationale Optimierung mit einbeziehen muß.
In unserem Beispiel soollten jedoch unbefugten Personen, die nicht im Genehmigungsprozeß bzw. Verbuchungsprozeß einbezogen und nicht Besitzer des entsprechenden Dokumentes sind, der Zugriff verwehrt
bleiben.
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
318
Definition einer Authorisierungstabelle zur Kontrolle des Zugriffs: Oft wird empfohlen, jedem Aktor für
jede seiner Rollen eine spezifische Sicht zuzuordnen. Damit wird der Entwurf übermäßig komplex. Die
Programme sind dann meist nicht mehr zu pflegen. Aus diesem Grund ist eine Authorisierungstabelle meist
der sinnvollere Ausweg. Dann kann durch einen Verbund der Authorisierungstabelle mit den zentralen
Sichten die jeweilige Arbeitssicht direkt gewonnen werden.
Wird diese Darstellung zu komplex, dann kann man durch Techniken der Denormalisierung einfachere
Sichten gewinnen, wobei in diesem Fall die Redundanz erplizit gepflegt werden muß.
Ist eine direkte Compilierung der Sicherheitsroutinen in die Programme möglich, dann kann auch dieser
Weg gewählt werden.
Damit erhalten wir die folgenden Pragmatiken.
Sicherheitsanforderungen
Read-Zugriff auf alle Objekte
und Komponenten
Read-Zugriff auf alle Objekte
und einige Komponenten
Read-Zugriff auf einige Objekte
und alle Komponenten
Benutzung von Sichten
Zentrale Sichten
Sicherheitssichten
Sicherheitsichten
GRANT Kommandos
GRANT Read-Zugriff ON Sicht
TO alle Benutzer bzw. Gruppen
GRANT Read-Zugriff ON Sicht
TO alle Benutzer bzw. Gruppen
GRANT Read-Zugriff ON Sicht
TO alle Benutzer bzw. Gruppen
oder
Zentrale Sichten mit
Authorisierungstabelle mit
Read-Zugriff auf einige Objekte
und einige Komponenten
Authorisierungssicht über
Verbund und SELECT
WHERE Attr = USER
bzw.
Authorisierungssicht über
Subquery und SELECT
WHERE Attr = USER
bzw.
Duplikatspalten in einer
Tabelle mit Authorisier.-sicht
SELECT WHERE Attr = USER
bzw.
Authorisierungsprogramm mit
Inhalt SELECT WHERE ...
Kombination der vorherigen
Zugänge
GRANT Read-Zugriff ON Authorisierungssicht
TO PUBLIC
oder
GRANT execution ON Authorisierungsprogramm
TO PUBLIC
Bevorzugung der Standardprozeduren zur Integritätspflege: Die Integritätspflege kann auch durch benutzer umgangen werden. Dies trifft insbesondere auf Makros, die zur Pflege der Integrität entwickelt
wurden, zu. Anstelle dieser kann man durch entsprechende ‘exit’s oder entsprechenden Programmkode
die Umgehung verhindern.
Ein pragmatischer Zugang wird in der folgenden Tabelle vorgestellt.
IS ADD
CAU zu Kiel, IfI, ISE, β
Sicherh.-anford.
Update-Zugriff auf
alle Objekte und
alle Komponenten
2. Strukturierung von IS
Benutzung von
Sichten
Zentrale Sichten
ab SS 2012
Normale Update-Operationen
versus Standard-Prozeduren
mit DML-Kommandos
mit Standard-Pflege-Prozeduren
Update-Zugriff auf
alle Objekte und
einige Komponenten
Update-Zugriff auf
einige Objekte und
alle Komponenten
Zentrale Sichten
über Standard-Pflege-Prozed.
(erforderlich hier)
Sicherheitssichten
mit DML-Kommandos
Zentrale Sichten
Sicherheitssichten
über Standard-Pflege-Prozed.
bei Separierung der Routinen für
jede Sicht (eine Routine; verschiedene kompilierte Versionen für
jede Sicht oder dynamische Bindung
der Routinen an die Sichten)
mit Standard-Pflege-Prozeduren
(erforderlich hier)
mit DML-Kommandos
mit Standard-Pflege-Programmen
Update-Zugriff auf
einige Objekte und
einige Komponenten
Zentrale Sichten,
zentrale Authorisierungssichten,
Authorisierungssicht zur
Verbindung dieser
mit DML-Kommandos
Zentrale Sichten,
zentrale Authori- ,
sierungssichten,
aber DBMS erlaubt keine
updates über join/subquery-Sichten beider
mit Standard-Pflege-Programmen
(erforderlich hier), die
(erforderlich hier), die
Zugriffsauthorisierung über
SELECT WHERE
Attr = USER verfizieren
mit Standard-Pflege-Programmen
319
GRANT Kommandos
GRANT updates
ON Sicht
TO alle Ben./Gruppen
Verbot der DML-updates
über Sichten
GRANT execution
ON Maintenance-Routinen
TO alle Ben./Gruppen
Verbot der DML-updates
über Sichten
GRANT execution
ON Maintenance-Routinen
TO alle Ben./Gruppen
GRANT execution
ON Maintenance-Routinen
TO alle Ben./Gruppen
Verbot der DML-Kommandos
GRANT execution
ON Maintenance-Routinen
TO alle Ben./Gruppen
Verbot der DML-Kommandos
GRANT execution
ON Maintenance-Routinen
TO alle Ben./Gruppen
GRANT execution
ON Maintenance-Routinen
TO alle Ben./Gruppen
GRANT execution
ON Maintenance-Routinen
TO alle Ben./Gruppen
GRANT execution
ON Maintenance-Routinen
TO alle Ben./Gruppen
Verbot der DML-Kommandos
GRANT execution
ON Maintenance-Routinen
TO alle Ben./Gruppen
Verbot der DML-Kommandos
GRANT execution
ON Maintenance-Routinen
TO alle Ben./Gruppen
Kombination der beiden
obigen Verfahren
Unterbindung des Zugriffs auf physische Strukturen: Eine einfache Methode zur Kontrolle der Modifikationsmöglichkeiten der Benutzer ist die zentrale Kontrolle der Aufgaben, die eine größere Sicherheitsrelevanz oder auch größere Auswirkungen auf die Arbeit der Datenbanken haben (Neudefinition von
Datenbanken, Speicheroptionen, konkurrierender Zugriff zu Tabellen vieler Benutzer). Andere Aufgaben
können einem breiteren Benutzerkreis geöffnet sein. Damit sind Benutzer auch für ihre eigene Sicherheit
selbst verantwortlich.
2.13 Design by schema pattern
nach den beiden Modellierungsfibeln
People and organization
Products
Ordering products
IS ADD
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
Order delivery and invoicing
Work effort
Accounting and budgeting
Human resources
siehe 2000 und 2001 Preprints zu Pattern und Stars
IS ADD
320
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
321
2.14 Ein Beispiel
2.14.1 Ein HERM-Beispiel
2.14.2 Die relationale Transformation des Beispieles
Annahmen für die Transformation im Vorlesungsbeispiel:
• volle ID-Entfaltung
• rigides Nullwerte-Management
• Separation von Schemadefintion und Integritätsbedingungen
• minimale Indexunterstützung (nur Schls̈sel (Primär- und Fremd-))
• minimale Menge von Wertebereichen
• vollständige Verflachung
• Auflösung aller Cluster-Typen
• Event-Nonseparation mit Surrogat-Auflösung
• Einbettung von (0,1)-*-Beziehungen
• Namensgenerierung mit Präfixerweiterung und vorgegebener Prä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));
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
322
Name(First,Fam,{Title})
Person
Adr(Zip,Town,Street(Name,Nr))
Person’s number
>
K
I
Supervisor
Since
Major
¼
Student
StudNr
j
ª
s
I
3
O
Department
¾
-
In
Speciality
Professor
>
Minor
6
DName
Phones{Phone}
Primary
Investigator
Director
Member
L
Result
Time(Day,Hour)
-
Enroll
9
+
Lecture
Has
?
CNu
Room
Semester
Course
6
Year
Season
Nr
CName
?
6
Project
Building
Prerequis
Num
Begin
End
Abbildung 82: HERM-Diagram of the University Database
Mod IS
IS ADD
Web IS
PName
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
323
create table Institut (
ID_Ins char(10) not null,
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_Stu char(10) not null,
ID_Per char(10) not null,
MatrNr char(7) not null,
primary key (ID_Stu),
unique (ID_Per));
create table Professor (
ID_Pro char(10) not null,
ID_Per char(10) not null,
Spezialisierung char(1) not null,
primary key (ID_Pro),
unique (ID_Per));
create table Person (
ID_Per char(10) not null,
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 (
ID_Pro char(10) not null,
ID_Stu char(10) not null,
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,
ID_Stu char(10) not null,
von date not null,
bis date not null,
primary key (ID_Stu, E_S_ID_Stu));
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
324
create table hoert (
ID_Stu char(10) not null,
ID_Vor char(10) not null,
Resultat char(10) not null,
Note char(2),
primary key (ID_Vor, ID_Stu));
create table Projektmitarbeiter (
ID_Pro char(10) not null,
ID_Stu char(10) not null,
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_Pro char(10) 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 (
ID_Pro char(10) not null,
Seit char(1) not null,
ID_Ins char(10) not null,
primary key (ID_Pro));
create table wirkt mit (
W_P_ID_Pro char(10) not null,
ID_Pro char(10) not null,
bis date not null,
Kontraktnr char(6) not null,
von date 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));
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
325
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
foreign key (ID_Stu)
references Studiengang;
alter table eingeschrieben in add constraint FKein_Stu
foreign key (E_S_ID_Stu)
references Student;
alter table hoert add constraint FKhoer_Vor
foreign key (ID_Vor)
references Vorlesung;
alter table hoert add constraint FKhoer_Stu
foreign key (ID_Stu)
references Student;
alter table Projektmitarbeiter add constraint FKStu_Pro
foreign key (ID_Stu)
references Student;
alter table Projektmitarbeiter add constraint FKPro_Pro
foreign key (P_P_ID_Pro)
references Professor;
alter table Vorlesung add constraint FKliest
foreign key (ID_Pro)
references Professor;
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
foreign key (ID_Pro)
references Professor;
alter table In add constraint FKIn_Ins
foreign key (ID_Ins)
references Institut;
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
326
alter table wirkt mit add constraint FKwir_Pro_1
foreign key (ID_Pro)
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);
create unique index ID
on Kurs (ID_Kur);
create unique index ID
on Raum (ID_Rau);
create unique index ID
on Institut (ID_Ins);
create unique index ID
on Semester (ID_Sem);
create unique index ID
on Projekt (ID_Pro);
create unique index ID
on Student (ID_Stu);
create unique index FKPer_Stu
on Student (ID_Per);
create unique index ID
on Professor (ID_Pro);
create unique index FKPer_Pro
on Professor (ID_Per);
create unique index ID
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);
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
327
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);
create unique index ID
on Projektmitarbeiter (ID_Pro);
create unique index FKStu_Pro
on Projektmitarbeiter (ID_Stu);
create unique index FKPro_Pro
on Projektmitarbeiter (P_P_ID_Pro);
create unique index ID
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);
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
328
2.15 Schrittweise Modellierung im Co-Design an einem Beispiel
Angaben
zur Reise
Reisedaten
Reiseablaufdaten
Kostenüberweisung
Kostenabrechnungsdaten
Reisekostenanerkennung
Finanzdaten
Abbildung 83: Die Grobstruktur der Anwendung
Storyschritt
Vertreter
?
6
?
Akteur
¾
Rolle
-
Sicht
Abbildung 84: Das Akteurmodell für die Geschäftsprozeßschicht
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
329
Überweisung
Verbuchung
6
Genehmigung
Abrechnung
(1,1)
abgerechnet durch
(1,n)
?
Antragsteller
(1,n)
¾
(1,1)
-
beantragt
Dienstreise
Genehmigung
Reiseverlauf
Abbildung 85: Grobdarstellung der Struktur der Anwendung
Abrechnungssicht
Beantragungssicht
Sicht für allgemeine Verbuchung
Abbildung 86: Sichtenskizze für unsere Anwendung
Beantragung
-
Ausfüllen
-
Befürwortung
-
Genehmigung
-
Genehmigung
der Abrechnung
-
Kontrolle der
Abrechnung,
Berechnung
der Kostensätze
-
Genehmigung der
Verbuchung
-
Zuordnung zum
Abrechnungsmodus
*
j
Überweisung
Kassenbereitstellung
Rückforderung
?
Abrechnung
?
Verbuchung
?
Verrechnung
Abbildung 87: Szenarien für Behandlung des Dienstreiseantrages (Normalverfahren)
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
Antragsteller
-
Beantragung
330
Vorges. des Antragst.
-
Ausfüllen
Befürwortung
Dekan
-
Genehmigung
-
Genehmigung der
Verbuchung
? Antragsteller
Abrechnung
?
-
Verbuchung
Sachbearb. X
Dekan
Genehmigung
der Abrechnung
-
Sachbearb. X
?
-
Verrechnung
Zuordnung zum
Abrechnungsmodus
*
j
Kontrolle der
Abrechnung,
Berechnung
der Kostensätze
Sachbearb. Y
Sachbearb. X
Kassiererin
Kassenbereitstellung
Rückforderung Sachbearb. X
Überweisung
Abbildung 88: Themen und Akteuren für Behandlung des Dienstreiseantrages (Normalverfahren)
Akteur
¾
Rolle
- Dialogschritte ¾
zugeordnete
6
? Vertreter
?
-Sichtenelemente
6
?
Rechte
berechnet
durch
Abbildung
?
¾
Handlungsschritte
?
In
Abbildung 89: Das Akteurmodell für die Aktionsschicht
- Skelettelement
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
Beantragungssicht
Beantragung
-
331
Genehmigungssicht 1
-
Ausfüllen
Genehmigungssicht 2
-
Befürwortung
Genehmigung
?
Abrechnungssicht
Abrechnung
?
Verbuchungssicht 1
Genehmigungssicht 3
Verbuchung
Genehmigung
der Abrechnung
-
-
Verrechnungssicht 1
?
Verrechnung
*
j
Zuordnung zum
Abrechnungsmodus
-
Genehmigungssicht 4
Kontrolle der
Abrechnung,
Berechnung
der Kostensätze
-
Genehmigung der
Verbuchung
Verrechnungssicht 2
Verrechnungssicht 3
Kassenbereitstellung
Verrechnungssicht 4
Rückforderung
Überweisung
Abbildung 90: Skelett für den Dienstreiseantrag (Normalverfahren)
≈ (1, 10)
200 (1, n)
500 ¾
2000
Antragsteller
beantragt
≈ (1, 1)
(0, 1)
¾
≈ (1, 2)
(1, 30)
(1, 50)
?
Reise
wird
abgerechnet
(Vorschlag)
?
1000
5000
30000
100
Verbuchung 200
300
Abbildung 91: Erster Entwurf für die Beantragungssicht
System
Historie
Antragstellerdaten
Optionen Fenster
Reisedaten
Verbuchungsdaten
Name
Institut
Vorname
Lehrstuhl
Wohnort
Dienstort
Datum
Unterschrift
Vergüt.-stufe
f1 (name,vorname)
Reisek.-stufe
f2 (name,vorname)
Abbildung 92: Dialogobjekt zur Darstellung von Antragstellerdaten für Lehrstuhlanträge
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
System
Historie
Antragstellerdaten
ab SS 2012
332
Optionen Fenster
Verbuchungsdaten
Reisedaten
Name
Institut
Vorname
Lehrstuhl
Zus.hang zu
Privatreise
Beförd.-mittel
Poliz. Kennz.
bei Privat PkW
Ziel
Dauer - von
Dauer - bis
Zweck
Weitere
Teilnehmer
Abbildung 93: Dialogobjekt zur Darstellung von Reisedaten für Anträge aus Lehrstuhl
0
30
3000
Auto
6
PolKZ
≈ (1,1)
(1,2)
Name
zugeordnet
zu
Benutzt
Name
≈ (1,1)
(1,4)
≈ (1,1)
(0,4)
?
6
Wohnort≈ (1,1)
≈ (10,40)
(0,n)
Bis
Von Zweck
À
200
500
2000
Dienstort
¾≈ (0,1)
beantragt
(0,2)
Vorschuß(Höhe,Auszahlart)
q
Reiseziele
AHatV
Art
Ort
Land
0
1000
∞
¾
≈ (1,1)
(1,3)
Mögliche
Reise
-
≈ (0,n)
(0,n)
Fakultät
Nr
(1,30)
(0,4)
≈ (1,200)
(1,n)
-
≈ (2,5)
(0,n)
In
Kostenstelle
Ver- 100
200
buchung
300
AntrDatum
Privatzweck≈ (1,2)
Titel
¾≈ (1,10)
(1,n)
≈ (1,1)
Lehr- 20
90 ¾
stuhl 150 (1,2)
6
Vorname
Antragsteller
-
≈ (20,80)
(0,n)
Beförderungsmittel
1
3
8
Art
?
Ver1
gütungs- 3 Reisekostenstufe
gruppe 4
Abbildung 94: Beantragung einer Dienstreise mit Verbuchung über den Lehrstuhl
1
5
5
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
6
PolKZ
≈ (1,1)
(1,2)
Name
zugeordnet
zu
Benutzt
≈ (1,1)
(1,4)
≈ (1,1)
(0,4)
?
6
200
500
2000
Dienstort
¾≈ (0,1)
beantragt
(0,2)
Vorschuß(Höhe,Auszahlart)
q
Reiseziele
AHatV
Art
Ort
Land
0
1000
∞
¾≈ (1,1)
(1,3)
Mögliche
Beförderungsmittel
-
≈ (0,n)
(0,n)
Fakultät
Nr
(1,30)
(0,4)
≈ (1,200)
(1,n)
-
≈ (2,5)
(0,n)
In
Kostenstelle
Ver- 100
200
buchung
300
AntrDatum
Privatzweck≈ (1,2)
Titel
¾≈ (1,10)
(1,n)
≈ (1,1)
Lehr- 20
90 ¾
stuhl 150 (1,2)
≈ (10,40)
(0,n)
Bis
Von Zweck
À
Antragsteller
-
≈ (20,80)
(0,n)
6
Vorname
Wohnort≈ (1,1)
333
0
30
3000
Auto
Name
ab SS 2012
Beförderungsmittel
1
3
8
Art
?
Ver1
gütungs- 3 Reisekostenstufe
gruppe 4
Abbildung 95: Beantragung einer Dienstreise mit Verbuchung über den Lehrstuhl
1
5
5
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
6
PolKZ
≈ (1,1)
(1,2)
Name
zugeordnet
zu
Benutzt
≈ (1,1)
(1,4)
≈ (1,1)
(0,4)
Vorname
?
Wohnort≈ (1,1)
200
500
2000
≈ (1,1)
Lehr- 20
90 ¾
stuhl 150 (1,2)
-
≈ (20,80)
(0,n)
¾≈ (1,10)
(1,n)
Dienstort
¾
beantragt
≈ (0,1)
(0,2)
AntrDatum
Privatzweck≈ (1,2)
q
Reiseziele
AHatV
Art
Ort
Land
0
1000
∞
¾≈ (1,1)
(1,3)
Mögliche
Beförderungsmittel
-
≈ (0,n)
(0,n)
Fakultät
6
≈ (10,40)
(0,n)
Vorschuß
(Höhe,Auszahlart)
(1,30)
(0,4)
≈ (1,200)
(1,n)
-
≈ (2,5)
(0,n)
In
Kostenstelle
Bis
Von Zweck
À
Antragsteller
6
334
0
30
3000
Auto
Name
ab SS 2012
Beförderungsmittel
1
3
8
Art
?
Ver1
gütungs- 3 Reisekostenstufe
gruppe 4
Abbildung 96: Beantragung einer Dienstreise mit Verbuchung über die Fakultät
Nr
Ver- 100
200
buchung 300
Titel
1
5
5
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
335
-LehrstGenehm
DekanBestät
DekGenehm
?
¾
Person
6
Antragsteller¾
6
beantragt y¾
?
LBefürw
LVerbuch
6
?
ArbeitetAn
?
Reise
?
LehrstFonds
FVerbuch
*
?
- Lehrstuhl ¾
leitet
LHatFond
6
FakVonL
-
DekanVonF
Fakultät
?
¾
FakHatFond
- FakFonds
Abbildung 97: Genehmigungen und Bestätigungen der Anträge durch Lehrstuhl bzw. Dekanat - erste Sichten
Beantragungssicht
Genehmigungssicht1
R
Genehmigungssicht2
?
ª
Zentrale
Beantragungssicht
Abrechnungssicht
Verbuchungssicht1
Genehmigungssicht3
Genehmigungssicht4
Verrechnungssicht1
R
?
ª
Zentrale
Verbuchungssicht
z
U
?
Integriertes Datenbankschema zum Dienstreiseantrag
Abbildung 98: Sichtenintegration in unserer Anwendung
...
R
Verrechnungssicht4
?
ª
Zentrale
Verrechnungssicht
¼
CAU zu Kiel, IfI, ISE, β
Benutzersichten
zur Vereinfachung
des Zugriffs
2. Strukturierung von IS
Beantragungssicht
Zentrale
Sichten
zur Darstellung
der Unabhängigkeit
Integriertes
Schema
zur Darstellung
der Speicherung
?
R
?
...
?
Zugriffsbeschr.
Genehmigungssicht1
Zugriffsbeschr.
Beantragungssicht
336
Genehmigungssicht2
Genehmigungssicht1
?
Sicherheitssichten
zur Kontrolle
des Zugriffs
ab SS 2012
Zugriffsbeschr.
Genehmigungssicht2
...
ª
Zentrale
Beantragungssicht
...
z
Integriertes Datenbankschema zum Dienstreiseantrag
Abbildung 99: Ausschnitt aus der Sichtenarchitektur mit Sicherheitssichten
2.15.1 HERM und OLAP bzw. Data Warehouses
siehe Bild 103, 104
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
337
V1
V2
Reisen{(Ort, Land, Zweck, Von, Bis) }
Reisezeitraum (Von, Bis)
Reisende{ (Name, Vorname) }
Dienstreisender
Name Vorname
Dienstreisen
Ort
Land
Zweck
V3
Dienstreisender
¾
Von
führt
durch
-
Bis
Name Vorname
Ort
Dienstreise
Land
Zweck
Abbildung 100: Zwei verschiedene Sichten auf eine Dienstreise und eine integrierte Sicht
Vergütungsgruppe
Auto
6
6
Benutzt
Person
6
AHatV
?
j
Antragsteller ¾
¾
6
- LehrstGenehm
DekanBestät
DekGenehm
?
beantragt
¾
y
?
LBefürw
LVerbuch
6
?
Mögliche
Reise
ArbeitetAn
?
?
LehrstFonds
FVerbuch
*
R
?
leitet
-
Lehrstuhl
Reiseziele
¾
LHatFond
^
6
FakVonL
Beförderungsmittel
?
Fakultät
DekanVonF
-
¾
FakHatFond
-
FakFonds
Abbildung 101: Integration der Beantragungs- und Genehmigungssichten bei Verbuchung über den Lehrstuhl bzw.
die Fakultät
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
z
j
Hauptmenü
ab SS 2012
338
Antragsteller
*
:
Reisedaten
- Verbuchungsvorschlag
z
Befürwortung
j
Genehmigung
Beantragungsmenü
...
...
Abbildung 102: Die Organisation der Menüs für die Beantragung
Person
OtherData
Person
POBox
Person
Postal
q
1
Person
EmailURL
?
Person
Basic
Data
6
Person
SMTP
)
i
Person
PhoneFax
Abbildung 103: HERM Representation of the Star Type Person
C UBE A: PARTICIPANTS PER L ECTURE AND DAY
Lectures ¾
HeldOn
-
C UBE B: U SAGE OF ROOMS PER DAY
Day
Room
¾
#Participants
Usage
-
Day
#TotalUsage
S CHEDULING S CHEMA ON U NIVERSITY AND E VENING L ECTURES
Room#
Room#
University ¾
Lecture
Room
IsA
-
Room
¾
IsA
6
?
University ¾
Lectures
HeldOn
#Participants
General
Purpose
Room
- Working
Day
6
IsA
Room#
6
-
Day
¾
Organized
On
#Participants
Abbildung 104: Scheduling Views on Lectures Given in a University
Title
-
Evening
Lectures
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
2.16 Beispiele aus dem HERM-Buch
.
ab SS 2012
339
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
340
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]
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.
[BDK92]
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.
[Bis95]
J. Biskup. Foundations of information systems. Vieweg, Wiesbaden, 1995. In German.
[BM97]
E. Börger, , and L. Mearelli. Integrating ASM into the software development life cycle. J. Universal
Computer Science, 3(5):603–665, 1997.
[BS00]
E. Börger and W. Schulte. Architecture Design and Validation Methods, chapter Modular design for the
Java virtual machine architecture, pages 297–357. Springer, Berlin, 2000.
[BS03]
E. Börger and R. Stä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]
C. Beeri and B. Thalheim. Identification as a primitive of database models. In Proc. FoMLaDO’98, pages
19–36. Kluwer, London, 1999.
[Cad76]
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, Gdańsk,
1976. Springer, Berlin.
[CCN80]
P. P. Chen, I. Chung, and F. Nakamura. Entity-relationship normal forms. unpublished manuscript, 1980.
[Cel95]
J. Celko. Joe Celko’s SQL for smarties - Advanced SQL programming. Morgan Kaufmann, San Francisco,
1995.
[CGT90]
S. Ceri, G. Gottloba, and L. Tanca. Logic programming and databases. Springer, Heidelberg/New York,
1990.
[CL73]
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.
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
341
[DMT07] 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.
[EN89]
R. Elmasri and S. B. Navathe. Fundamentals of database systems. Benjamin/Cummings, Redwood City,
1989.
[EWH85] R. Elmasri, J. Weeldreyer, and A. Hevner. The category concept: An extension to the entity-relationship
model. DKE, 1(1):75–116, 1985.
[Fag81]
R. Fagin. A normal form for relational data bases that is based on domains and keys. ACM TODS,
6(3):387–415, 1981.
[Fownn]
M. Fowler. Analysemuster. Addison-Wesley, 1999, Bonn.
[Gog94]
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, Visegrád, Hungary, Jun 26 - 30, 1989, 1989. Springer, Berlin.
[Hal95]
T. A. Halpin. Conceptual schema and relational database design. Prentice-Hall, Sydney, 1995.
[HL07]
S. Hartmann and S. Link. English sentence structures and eer modeling. In APCCM, volume 67 of
CRPIT, pages 27–35. Australian Computer Society, 2007.
[HLM93] W. L. Hü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.
[Hoh93]
U. Hohenstein. Formale Semantik eines erweiterten Entity-Relationship-Modells. Teubner, Stuttgart,
1993.
[KL02]
Carsten Kleiner and Udo W. Lipeck. Automatische Erzeugung von XML DTDs aus konzeptuellen Datenbankschemata. Datenbankspektrum, 1(2):14–22, 2002.
[Kle07]
M. Klettke. Modellierung, Bewertung und Evolution von XML-Dokumentkollektionen. Advanced PhD
(Habilitation Thesis), Rostock University, Faculty for Computer Science and Electronics, 2007.
[KR97]
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. Räihä. The design of relational databases. Addison-Wesley, Wokingham, England,
1992.
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
[MR98]
2. Strukturierung von IS
ab SS 2012
342
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]
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.
[RK02]
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]
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.
[SI91]
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]
K.-D. Schewe and B. Thalheim. Fundamental concepts of object oriented databases. Acta Cybernetica,
11(4):49–81, 1993.
[ST98]
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. Abhä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.
Mod IS
IS ADD
Web IS
CAU zu Kiel, IfI, ISE, β
2. Strukturierung von IS
ab SS 2012
343
[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]
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.
[Wan98]
G. Wanner. Entwurf eines objektorientierten Datenbankmodells für relationale Datenbanksysteme. DISBIS 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.
Mod IS
IS ADD
Web IS