Leseprobe - Beck-Shop

Oracle Database 11g - Die umfassende Referenz
von
Hans Hajer, Kevin Loney
1. Auflage
Hanser München 2009
Verlag C.H. Beck im Internet:
www.beck.de
ISBN 978 3 446 41864 6
Zu Inhaltsverzeichnis
schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG
Leseprobe
Kevin Loney
Oracle Database 11g - Die umfassende Referenz
Übersetzt von Hans Hajer
ISBN: 978-3-446-41864-6
Weitere Informationen oder Bestellungen unter
http://www.hanser.de/978-3-446-41864-6
sowie im Buchhandel.
© Carl Hanser Verlag, München
4
4
Oracle-Applikationen planen –
Konzepte, Risiken und Standards
Um eine Oracle-Applikation zu erstellen, die sich schnell und effektiv einsetzen lässt, müssen
Benutzer und Entwickler dieselbe Sprache sprechen, und sowohl die Geschäftsanwendungen
als auch die Oracle-Tools kennen. In den letzen Kapiteln stellten wir Ihnen die Oracle-Produkte und die dazugehörigen Installations-/Upgrade-Schritte vor. Nachdem die Software installiert ist, können Sie Anwendungen entwickeln, in die die gemeinsamen Erfahrungen von
Anwendern und Programmierern einfließen.
Früher studierten die Systemanalytiker die Anforderungen und konzipierten die Applikation
entsprechend, um die gestellten Aufgaben zu erfüllen. Der Benutzer wurde nur bei der Beschreibung der Geschäftsvorgänge eingebunden, und durfte später vielleicht noch bei der Prüfung der Funktionalitäten mitwirken.
Mit den neuen Konzepten und Werkzeugen lassen sich, insbesondere mit Oracle, die Applikationen so programmieren, dass sie den Anforderungen und Arbeitsgewohnheiten der Anwender sehr viel besser gerecht werden – allerdings nur, wenn die Beteiligten über dieselben
Grundlagen verfügen.
Erklärtes Ziel dieses Buchs ist, genau dieses Wissen aufzubauen, und sowohl Entwicklern als
auch Anwendern alles dazu Notwendige zur Verfügung zu stellen. Denn nur so kann man die
volle Leistungsfähigkeit von Oracle nutzen. Der Endanwender kennt Einzelheiten über Geschäftsabläufe, die der Entwickler nicht versteht. Der Entwickler kennt andererseits die internen Funktionen und Leistungsmerkmale von Oracle und der DV-Umgebung, die für den Endanwender zu technisch oder zu komplex sind. Aber dieses spezielle Wissen kann
vernachlässigt werden, wenn man die Möglichkeiten betrachtet, die Endanwender und Entwickler beim Einsatz von Oracle erzielen können.
Es ist kein Geheimnis, dass zwischen Anwendern und Systemleuten über Jahrzehnte hinweg
ein gespanntes Verhältnis bestand. Die Gründe dafür resultierten aus der Unterschiedlichkeit
von Kenntnisstand, Kultur, Berufsinteressen und Zielen, und aus einer „Entfremdung“, die
oftmals einfach das Ergebnis der räumlichen Trennung zwischen Gruppen ist. Fairerweise
32
4
Oracle-Applikationen planen – Konzepte, Risiken und Standards
muss man allerdings anmerken, dass dieses Phänomen keine spezielle Eigenheit des IT-Bereichs ist. Dasselbe kann man in jeder Abteilung beobachten, nachdem Gruppen aufgeteilt
und in unterschiedlichen Stockwerken, Gebäuden oder Städten untergebracht wurden. In solchen Fällen nehmen die Beziehungen zwischen den Mitgliedern der verschiedenen Gruppen
sehr formale Züge an. Künstliche Barrieren und Abläufe, die eine Folge der Isolierung sind,
schleifen sich ein und fördern diese Entwicklung.
Soweit, so gut, könnte man einwenden, das mag für Soziologen interessant sein – aber was hat
das eigentlich mit Oracle zu tun?
Da Oracle nicht mit Fachbegriffen agiert, die nur für Systemexperten verständlich sind, verändert
Oracle auch von Grund auf die Beziehungen zwischen Anwendern und Experten. Jeder kann das
Produkt verstehen. Jeder kann es anwenden. Informationen, die zuvor solange im Computer
versteckt waren, bis irgendjemand einen neuen Report schrieb und sie freigab, sind nun für
den Anwender sofort verfügbar – das Eingeben einer einfachen Abfrage genügt. Und das ändert die Spielregeln.
Überall wo Oracle eingesetzt wird, hat sich das Verhältnis zwischen den oben angesprochenen
Gruppen entscheidend verbessert. Man lernte einander besser kennen, was zu einer Normalisierung der Beziehungen beitrug und zu besseren Anwendungen führte.
Seit der ersten Version stützt sich Oracle auf das leicht verständliche relationale Modell, sodass
auch Nicht-Programmierer ohne Weiteres verstehen können, was Oracle macht und wie es
passiert. Das macht den Umgang mit diesem Programm einfach und unspektakulär.
Manche haben das noch nicht verstanden, akzeptiert oder machen sich nicht klar, wie wichtig
es ist, dass die überkommenen und künstlichen Schranken zwischen „Anwendern“ und „Systemen“ weiter abgebaut werden. Doch die kooperative Entwicklung wird Anwendungen und
ihre Nützlichkeit tief greifend beeinflussen.
Allerdings sind viele Entwickler bei Oracle offensichtlich in eine Falle gelaufen: Sie setzten bei
ihren Systementwürfen weiterhin auf wenig hilfreiche Methoden aus der Vergangenheit. Hier
muss erst viel „verlernt“ werden. Zahlreiche Techniken (und Einschränkungen), die bei älteren
Systemgenerationen unverzichtbar waren, sind bei Entwürfen mit Oracle nicht nur unnötig,
sondern eindeutig kontraproduktiv. Um für die Zukunft gerüstet zu sein, müssen alte Gewohnheiten und Konzepte aufgegeben werden. Stattdessen stehen erfrischend neue Möglichkeiten
zur Verfügung.
In diesem Buch versuchen wir, Oracle möglichst einfach zu erklären und Begriffe zu verwenden, die sowohl Anwender als auch Entwickler verstehen. Veraltete oder unpassende Designund Managementtechniken werden kurz erläutert und durch neue Ansätze ersetzt.
4.1
Das kooperative Konzept
Oracle ist eine objektrelationale Datenbank. Eine relationale Datenbank bietet einen extrem
einfachen Weg, über Daten und deren Verwaltung in einem Unternehmen nachzudenken. Es
handelt sich im Prinzip um nichts anderes als eine Ansammlung von Tabellen. Wir haben es
jeden Tag mit Tabellen zu tun: Wetterberichte, Aktienkurse, Sportergebnisse. Das alles sind
Tabellen, die mit einer Tabellenüberschrift und den dazugehörigen Informationsspalten ganz
einfach dargestellt werden. Dennoch kann der relationale Ansatz sehr ausgefeilt und leistungs-
4.2
Jeder besitzt „Daten“
fähig genug sein, um in einem Unternehmen selbst die komplexesten Dinge abzubilden. Eine
objektrelationale Datenbank unterstützt alle Leistungsmerkmale einer relationalen Datenbank, und gleichzeitig die objektorientierten Konzepte und Funktionen. So können Sie Oracle
entweder als relationales Datenbank-Managementsystem (RDBMS) einsetzen oder die Vorteile der objektorientierten Leistungsmerkmale nutzen.
Leider verstehen genau diejenigen, die von den Vorteilen einer relationalen Datenbank am
meisten profitieren könnten – also die Geschäftsleute – dieses Konzept am wenigsten. Die Entwickler haben oftmals Schwierigkeiten, die relationalen Konzepte mit einfachen Worten zu erklären. Damit dieser kooperative Ansatz tatsächlich funktioniert, benötigt man eine gemeinsame Sprache.
Die beiden ersten Teile dieses Buchs erklären mit einfachen Begriffen, was eine relationale Datenbank ist und wie man sie in einem Unternehmen effektiv einsetzt. Es könnte der Eindruck
entstehen, dass diese Diskussion nur dem „Anwender“ zugutekommt. Und ein erfahrener
Entwickler könnte dazu neigen, diese Kapitel zu überspringen und das Buch in erster Linie als
Oracle-Referenz zu nutzen. Obwohl ein Großteil dieses Materials wie eine Aufarbeitung der
Grundlagen wirkt, bietet es jedem Anwendungsentwickler die Möglichkeit, sich eine klare,
konsistente und arbeitsfähige Terminologie zu erarbeiten. Mithilfe dieser Terminologie kann
man mit den Anwendern die Anforderungen erörtern und klären, wie sich diese Anforderungen schnell umsetzen lassen. Zudem kann die Diskussion dazu beitragen, dass Ihnen als Entwickler einige unsinnige, und vielleicht unbewusste Designgewohnheiten vor Augen geführt
werden. Es ist wichtig sich deutlich zu machen, dass selbst die Leistungsfähigkeit von Oracle
durch Designmethoden, die man nur im Bereich der nicht-relationalen Datenbanken einsetzt,
beträchtlich sinken kann.
Wenn Sie ein Endanwender sind, hilft Ihnen das Verständnis der grundlegenden Konzepte für
objektrelationale Datenbanken bei der Formulierung Ihrer Bedürfnisse gegenüber den Entwicklern, und zu begreifen, wie man diesen Anforderungen gerecht werden kann. Jeder kann
so in kurzer Zeit vom Anfänger zum Experten werden. Mit Oracle haben Sie die Möglichkeit,
Informationen zu gewinnen und einzusetzen, Sie haben die direkte Kontrolle über Reports
und Daten, und wissen ganz genau, was die Applikation macht und wie sie funktioniert.
Zudem entlasten Sie die Programmierer von ihrer unangenehmsten Aufgabe: dem Schreiben
neuer Reports. Da Sie diese Aufgabe jetzt selbst in einigen Minuten erledigen können, werden
Sie an der neuen Verantwortung Ihre Freude haben.
4.2
Jeder besitzt „Daten“
Eine Bibliothek führt Listen über ihre Mitglieder, Bücher und Gebühren. Der Besitzer einer
Fußballkartensammlung behält die Namen der Spieler, deren Daten und den Wert der Karten
im Auge. In jedem Unternehmen müssen bestimmte Informationen über Kunden, Produkte,
Finanzstatus usw. gespeichert werden. Diese bruchstückhaften Informationen nennt man
„Daten“.
Informationstheoretiker meinen, dass Daten solange bloß Daten sind, bis sie sinnvoll organisiert werden – erst in diesem Moment werden sie zu „Informationen“. Wenn das stimmt, ist
auch Oracle eine Möglichkeit, um Daten auf einfache Weise in Informationen zu verwandeln.
Oracle sortiert und manipuliert Daten, um verborgene Erkenntnisse zu gewinnen – z. B. Sum-
33
34
4
Oracle-Applikationen planen – Konzepte, Risiken und Standards
men, Kauftrends oder andere Beziehungen – die bisher unentdeckt blieben. Sie werden lernen,
wie man solche Entdeckungen macht. Das Wichtigste an dieser Stelle ist, das Sie über Daten
verfügen und damit drei grundlegende Funktionen ausführen: beschaffen, speichern und abrufen.
Sobald Sie über die Grundlagen verfügen, können Sie mit den Daten Berechnungen anstellen,
sie an andere Standorte verschieben oder ändern. Diese Operationen bezeichnet man als Verarbeiten. Diese Verarbeitung umfasst prinzipiell dieselben drei Schritte, die Einfluss auf die
Organisation der Daten haben.
Natürlich könnten Sie alles auch mithilfe einer Zigarrenkiste, einem Stift und einem Blatt Papier bewältigen. Doch sobald die Datenmenge wächst, werden Sie Ihre Werkzeuge wahrscheinlich wechseln. Sie können bei Ordnern, Taschenrechnern, Stiften und Papier bleiben. Auch
wenn es ab einem bestimmten Zeitpunkt sinnvoll ist, den Sprung zum Computer zu wagen,
Ihre Aufgaben bleiben dieselben.
Ein Relationales Datenbank Management System (kurz RDBMS genannt) wie Oracle gibt Ihnen die Möglichkeit, solche Aufgaben auf verständliche, nachvollziehbare und unkomplizierte Weise zu erledigen. Oracle macht im Prinzip drei Dinge (siehe Abbildung 4-1):
■ Es lässt Sie Daten eingeben.
■ Es hält die Daten vor.
■ Es lässt Sie die Daten abrufen und damit arbeiten.
raus
rein
vorhalten
Abbildung 4-1: Ein einfacher Prozess.
Oracle unterstützt diesen Ansatz von Eingabe-Speichern-Ausgabe und stellt intelligente
Werkzeuge zur Verfügung, mit deren Hilfe Sie auf hohem Niveau festlegen, wie die Daten erfasst, bearbeitet, verändert und eingebracht werden; wie Sie die Daten sicher aufbewahren;
und wie Sie die Daten wieder herausbekommen, um sie zu manipulieren oder zu einem Report
zusammenzustellen.
4.3
35
Die Sprache von Oracle
4.3
Die Sprache von Oracle
Oracle speichert Information in Tabellen – ganz ähnlich wie in der Wettertabelle einer Tageszeitung (siehe Abbildung 4-2).
WEATHER
City
Athens.......
Chicago......
Lima.........
Manchester...
Paris........
Sparta.......
Sydney.......
Temperature
97
66
45
66
81
74
69
Humidity
89
88
79
98
62
63
99
Condition
Sunny
Rain
Rain
Fog
Cloudy
Cloudy
Snow
Abbildung 4-2: Die Wettertabelle aus einer Tageszeitung.
Diese Tabelle umfasst vier Spalten: City, Temperature, Humidity und Condition. Außerdem
enthält sie für jede Stadt von Athen bis Sydney eine Zeile. Und schließlich hat die Tabelle einen
Namen: WHEATHER.
Dies sind die drei wichtigsten Charakteristiken der meisten Tabellen, die Sie zu sehen bekommen: Spalten, Zeilen und ein Name. Das gilt auch für die relationalen Datenbanken. Jeder kann
die Wörter und Ideen verstehen, die sie repräsentieren, da die Begriffe, mit denen die Elemente
einer Tabelle in der Oracle-Datenbank beschrieben werden, denen in der Umgangssprache
entsprechen. Die Wörter haben keine spezielle oder abweichende Bedeutung. Was Sie sehen,
bekommen Sie auch.
4.3.1
Die Informationstabellen
Oracle speichert Informationen in Tabellen (siehe Abbildung 4-3). Jede der gezeigten Tabellen
besitzt eine oder mehrere Spalten. Die Überschriften, wie City, Temperature, Humidity und
Condition, beschreiben die Art der Information, die in den Spalten vorgehalten wird. Die Informationen sind Zeile für Zeile und Stadt für Stadt abgespeichert. Jede Zeile besteht aus einem eindeutigen Datensatz, wie der Temperatur, der Luftfeuchtigkeit und der Witterung für
Manchester.
Oracle vermeidet eine spezielle akademische Terminologie, um damit das Produkt besser zugänglich zu machen. In Forschungsunterlagen zur relationalen Theorie werden Spalten als „Attribute“, Zeilen als „Tupel“ und Tabellen als „Entitäten“ bezeichnet. Für den Endanwender sind
diese Begriffe jedoch verwirrend. Darüber hinaus ist es eine völlig unnötige Umbenennung von
Dingen, für die es in der Umgangssprache bereits allgemein verständliche Begriffe gibt. Wenn
Oracle den Vorteil dieser allgemein verständlichen Sprache nutzt, sollten Entwickler dasselbe
tun. Ein unnötig technischer Jargon errichtet sinnlose Hürden. Deshalb verwenden wir, ähnlich
wie Oracle, in diesem Buch Begriffe wie „Tabellen“, „Spalten“ und „Zeilen“.
36
4
Oracle-Applikationen planen – Konzepte, Risiken und Standards
Tabellenname
Eine Spalte
City
---------ATHENS
CHICAGO
LIMA
MANCHESTER
PARIS
SPARTA
SYDNEY
WEATHER
Temperature
----------97
66
45
66
81
74
69
Humidity
-------89
88
79
98
62
63
99
Condition
--------SUNNY
RAIN
RAIN
FOG
CLOUDY
CLOUDY
SNOW
Eine Zeile
Abbildung 4-3: Eine Wettertabelle von Oracle.
4.3.2
Strukturierte Abfragesprache
Oracle war das erste Unternehmen mit einem Produkt, das die englisch-basierte Structured
Query Language oder SQL einsetzte. Damit können Endanwender die Informationen selbst extrahieren, ohne gleich für jeden kleinen Report die Systemtruppe bemühen zu müssen.
Oracles Abfragesprache hat, wie jede normale Sprache, eine bestimmte Struktur. Sie besitzt
Regeln für Grammatik und Syntax, die aber im Prinzip den Regeln der englischen Sprache entsprechen und daher leicht verständlich sind.
SQL wird entweder „sequell“ oder „S-Q-L“ ausgesprochen und ist, wie Sie noch sehen werden,
ein erstaunlich leistungsfähiges Werkzeug. Der Einsatz der Sprache setzt keine Programmierkenntnisse voraus.
Nachfolgend sehen Sie ein kleines Beispiel für den Einsatz von SQL. Wenn jemand Sie bittet,
die Stadt aus der Tabelle herauszusuchen, bei der die Luftfeuchtigkeit 89 Prozent beträgt, würden Sie schnell „Athen“ sagen. Wenn Sie gebeten werden, alle Städte auszuwählen, bei denen
die Temperatur 66 Grad Fahrenheit beträgt, würden Sie mit „Chicago“ und „Manchester“ antworten.
Oracle kann die gleichen Fragen fast genauso einfach beantworten. Die Abfrage ist simpel und
sieht fast wie die von Ihnen gestellte Frage aus. Die Schlüsselwörter in einer Oracle-Abfrage
sind select, from, where und order by. Diese Schlüsselwörter sind für Oracle Anhaltspunkte,
damit die Abfrage richtig verstanden und die korrekte Antwort ausgegeben wird.
4.3.3
Eine einfache Oracle-Abfrage
Wenn Oracle die WEATHER-Tabelle in der Datenbank hat, könnte Ihre erste Abfrage wie
folgt aussehen (das Semikolon teilt Oracle mit, dass der Befehl auszuführen ist):
select City from WEATHER where Humidity = 89 ;
Die Antwort von Oracle lautet:
4.3
Die Sprache von Oracle
City
---------ATHENS
Die zweite Abfrage wäre wie folgt:
select City from WEATHER where Temperature = 66 ;
Darauf antwortet Oracle mit:
City
----------MANCHESTER
CHICAGO
Und wie steht es mit order by? Angenommen, Sie möchten alle Städte über die Temperatur
sortieren lassen. Dazu geben Sie einfach Folgendes ein:
select City, Temperature from WEATHER
order by Temperature ;
Oracle antwortet mit folgender Aufstellung:
City
Temperature
----------- ----------LIMA
45
MANCHESTER
66
CHICAGO
66
SYDNEY
69
SPARTA
74
PARIS
81
ATHENS
97
Oracle hat Ihre Tabelle schnell über die Temperatur sortiert. (Diese Tabelle führt die niedrigsten Temperaturen als Erstes auf; im nächsten Kapitel erfahren Sie, wie man angibt, dass zuerst
die niedrigeren oder höheren Zahlenwerte stehen).
Mit Oracles Abfragefunktion können Sie noch viele weitere Fragen stellen. Doch diese Beispiele zeigen, wie man die gewünschten Informationen ohne großen Aufwand aus einer OracleDatenbank in einer Form extrahiert, die genau Ihren Vorstellungen entspricht. Sie können aus
einfachen Elementen komplizierte Abfragen zusammenstellen, die eingesetzten Methoden
stellen jedoch sicher, dass alles verständlich bleibt. So können Sie beispielsweise die Schlüsselwörter where und order by kombinieren und Oracle anweisen, alle Städte zu selektieren, deren
Temperatur über 80 Grad Fahrenheit liegt, und die Städte aufsteigend nach der Temperatur
sortieren lassen. Dazu geben Sie Folgendes ein
select City, Temperature from WEATHER
where Temperature > 80
order by Temperature ;
und Oracle antwortet sofort mit:
City
Temperature
----------- ----------PARIS
81
ATHENS
97
37
38
4
Oracle-Applikationen planen – Konzepte, Risiken und Standards
Oder, noch spezieller, könnten Sie alle Städte erfragen, bei denen die Temperatur über 80 Grad
Fahrenheit und die Luftfeuchtigkeit unter 70 Prozent liegt:
select
where
and
order
City, Temperature, Humidity from WEATHER
Temperature > 80
Humidity < 70
by Temperature ;
Die Antwort von Oracle sieht wie folgt aus:
City
Temperature Humidity
----------- ----------- -------PARIS
81
62
4.3.4
Warum heißt sie „relational“?
Beachten Sie, dass die WEATHER-Tabelle Städte aus verschiedenen Ländern enthält, und für
einige Länder mehr als eine Stadt auflistet. Angenommen, Sie möchten wissen, in welchem
Land eine bestimmte Stadt liegt. Dazu können Sie eine separate LOCATION-Tabelle anlegen,
in der die Städte und die dazugehörigen Länder aufgeführt sind (siehe Abbildung 4-4).
LOCATION
WEATHER
City
---------ATHENS
CHICAGO
LIMA
MANCHESTER
PARIS
SPARTA
SYDNEY
Temperature
----------97
66
45
66
81
74
69
Humidity
-------89
88
79
98
62
63
99
Condition
--------SUNNY
RAIN
RAIN
FOG
CLOUDY
CLOUDY
SUNNY
City
----------ATHENS
CHICAGO
CONAKRY
LIMA
MADRAS
MADRID
MANCHESTER
MOSCOW
PARIS
ROME
SHENYANG
SPARTA
SYDNEY
TOKYO
Country
------GREECE
UNITED STATES
GUINEA
PERU
INDIA
SPAIN
ENGLAND
RUSSIA
FRANCE
ITALY
CHINA
GREECE
AUSTRALIA
JAPAN
Abbildung 4-4: Die WEATHER- und die LOCATION-Tabellen.
Für jede in der WEATHER-Tabelle aufgeführte Stadt sehen Sie einfach in der LOCATION-Tabelle nach: Der Name steht in der City-Spalte, Sie lesen in der gleichen Zeile weiter und finden
den entsprechenden Ländernamen in der Country-Spalte.
Dies sind zwei völlig unterschiedliche und unabhängige Tabellen. Jede Spalte und jede Zeile
enthält ihre eigenen Informationen. Ein signifikantes Element ist bei beiden Tabellen gleich: die
City-Spalte. Für jede Stadt in der WEATHER-Tabelle gibt es einen identischen Städtenamen in
der LOCATION-Tabelle.
Wie sehen z. B. die aktuelle Temperatur, die Luftfeuchtigkeit und die Wetterbedingungen in
einer australischen Stadt aus? Sehen Sie sich die beiden Tabellen an, stellen Sie sich das Ganze
vor und überdenken Sie beim Durchlesen alles noch einmal.
4.4
39
Praxisbezogene Beispiele
Wie haben Sie das Problem gelöst? In der LOCATION-Tabelle fanden Sie in der CountrySpalte nur einen AUSTRALIA-Eintrag. Gleich nebenan, in der City-Spalte, stand auch der
Name der Stadt: SYDNEY. Danach suchten Sie in der City-Spalte der WEATHER-Tabelle
nach dem gleichen Eintrag. Nachdem Sie ihn gefunden hatten, gingen Sie in der Zeile weiter
und fanden dort die Temperatur, die Luftfeuchtigkeit und die Witterung: 69, 99 und SUNNY.
Obwohl die beiden Tabellen voneinander völlig unabhängig sind, können Sie leicht erkennen,
dass sie irgendwie zusammenhängen. Der Städtename in der einen Tabelle steht zu dem Städtenamen in der anderen Tabelle in Relation. Diese Beziehung ist die Grundlage für die Bezeichnung relationale Datenbank (siehe Abbildung 4-5).
LOCATION
WEATHER
City
---------ATHENS
CHICAGO
LIMA
MANCHESTER
PARIS
SPARTA
SYDNEY
Temperature
----------97
66
45
66
81
74
69
Humidity
-------89
88
79
98
62
63
99
Condition
--------SUNNY
RAIN
RAIN
FOG
CLOUDY
CLOUDY
SUNNY
City
---------ATHENS
CHICAGO
CONAKRY
LIMA
MADRAS
MADRID
MANCHESTER
MOSCOW
PARIS
ROME
SHENYANG
SPARTA
SYDNEY
TOKYO
Country
------GREECE
UNITED STATES
GUINEA
PERU
INDIA
SPAIN
ENGLAND
RUSSIA
FRANCE
ITALY
CHINA
GREECE
AUSTRALIA
JAPAN
Beziehung
Abbildung 4-5: Die Beziehung zwischen der LOCATION- und der WEATHER-Tabelle.
Diese Idee liegt einer relationalen Datenbank zugrunde (manchmal auch relationales Modell
genannt). Die Daten werden in Tabellen gespeichert. Die Tabellen besitzen Spalten, Zeilen
und Namen. Wenn jede der Tabellen eine Spalte mit einem gemeinsamen Informationstyp besitzt, können sie miteinander verbunden werden.
Das ist alles. Es ist tatsächlich so einfach, wie es den Anschein hat.
4.4
Praxisbezogene Beispiele
Haben Sie das Prinzip einer relationalen Datenbank einmal verstanden, werden Sie plötzlich
überall Tabellen, Spalten und Zeilen entdecken. Viele der Tabellen, die Sie für gewöhnlich sehen, lassen sich in Oracle abspeichern. Mithilfe dieser Tabellen kann Oracle im Handumdrehen Fragen beantworten, für deren Bearbeitung Sie sonst vergleichsweise sehr viel mehr Zeit
benötigen würden.
Ein typischer Börsenbericht in der Zeitung könnte wie in Abbildung 4-6 aussehen. Dabei handelt es sich um einen kleinen Ausschnitt aus einer alphabetisch sortierten Liste, die einige Seiten lang ist und aus verschiedenen, eng beschriebenen Spalten besteht. Welche Börse handelte
40
4
Oracle-Applikationen planen – Konzepte, Risiken und Standards
die meisten Aktien? Bei welcher Aktie war die größte prozentuale Preisänderung zu verzeichnen, sowohl positiv als auch negativ? Die Antworten auf diese Fragen liefern bei Oracle einfache Abfragen: Das Programm findet die Antworten sehr viel schneller, als Sie die Spalten auf
der Zeitungsseite jemals durchsuchen können.
Company
Ad Specialty
Apple Cannery
AT Space
August Enterprises
Brandon Ellipsis
General Entropy
Geneva Rocketry
Hayward Antiseptic
IDK
India Cosmetics
Isaiah James Storage
KDK Airlines
Kentgen Biophysics
LaVay Cosmetics
Local Development
Maxtide
MBK Communications
Memory Graphics
Micro Token
Nancy Lee Features
Northern Boreal
Ockham Systems
Oscar Coal Drayage
Robert James Apparel
Soup Sensations
Wonder Labs
Close
Yesterday
31.75
33.75
46.75
15.00
32.75
64.25
22.75
104.25
95.00
30.75
13.25
80.00
18.25
21.50
26.75
8.25
43.25
15.50
77.00
13.50
26.75
21.50
87.00
23.25
16.25
5.00
Close
Today
31.75
36.50
48.00
15.00
33.50
66.00
27.25
106.00
95.25
30.75
13.75
85.25
19.50
22.00
27.25
8.00
41.00
14.25
76.50
14.25
28.00
22.00
88.50
24.00
16.75
5.00
Shares
Traded
18,333,876
25,787,229
11,398,323
12,221,711
25,789,769
7,598,562
22,533,944
3,358,561
9,443,523
8,134,878
22,112,171
7,481,566
6,636,863
3,341,542
2,596,934
2,836,893
10,022,980
4,557,992
25,205,667
14,222,692
1,348,323
7,052,990
25,798,992
19,032,481
22,574,879
2,553,71
Abbildung 4-6: Ein Börsenbericht.
Abbildung 4-7 zeigt den Index einer Zeitung. Was ist in Abschnitt F? In welcher Reihenfolge
lesen Sie die Artikel, wenn Sie die Zeitung von vorne nach hinten durchlesen? Die Antworten
auf diese Fragen sind einfache Oracle-Abfragen. Sie werden im weiteren Verlauf des Buchs lernen, wie diese Abfragen gestellt und die Tabellen zum Abspeichern der Informationen aufgebaut werden.
Im gesamten Buch arbeiten die Beispiele mit Daten und Objekten, die uns aus dem Geschäftsleben bekannt sind. Auch die Daten für Ihre Übungen finden Sie in Ihrer unmittelbaren Umgebung. Im Folgenden werden Sie lernen, wie man Daten eingibt und wieder extrahiert.
Wie bei vielen neuen Technologien oder Erfindungen sollte man nicht nur die Vorteile, sondern auch die Kosten und Risiken bedenken. Kombiniert man, wie bei Oracle, eine relationale
Datenbank mit einer Reihe von leistungsfähigen und einfach zu bedienenden Tools, kann man
sich leicht alle möglichen Katastrophenszenarien vorstellen. Fügt man noch objekt- und weborientierte Funktionen hinzu, verschärft sich die Situation weiter. Die nachfolgenden Abschnitte zeigen mögliche Gefahren, die Benutzer und Entwickler beachten sollten.
4.5
41
Wo liegen die Risiken?
Feature
Births
Bridge
Business
Classified
Comics
Doctor's In
Editorials
Modern Life
Movies
National News
Obituaries
Sports
Television
Weather
Sections
F
B
E
F
C
F
A
B
B
A
F
D
B
C
Page
7
2
1
8
4
6
12
1
4
1
6
1
7
2
Abbildung 4-7: Eine Tabelle, die auf den Rubriken einer Zeitung basiert.
4.5
Wo liegen die Risiken?
Das größte Risiko besteht darin, dass es so leicht ist, wie behauptet wird. Das Prinzip der Tabellen, Spalten und Zeilen ist nicht schwer zu verstehen. Die Beziehung zwischen zwei Tabellen ist konzeptionell gesehen relativ einfach. Selbst die Normalisierung, also der Prozess, bei
dem die inhärenten oder „normalen“ Beziehungen zwischen den verschiedenen Elementen
von Unternehmensdaten analysiert werden, ist relativ leicht erlernbar.
Leider produziert das häufig quasi aus dem Nichts „Experten“, die zwar über viel Selbstvertrauen verfügen, aber nur wenig Erfahrung mit dem Aufbau von realen Anwendungen in Produktionsqualität haben. Bei einer kleinen Marketing-Datenbank oder einer internen Bestandsaufnahme mag dies noch keine große Rolle spielen. Die gemachten Fehler offenbaren
sich mit der Zeit, die Lektionen können gelernt und die Fehler beim nächsten Mal vermieden
werden. Bei einer wichtigen Anwendung ist das jedoch der sicherste Weg in den Abgrund. Dieser Mangel an Erfahrung steckt üblicherweise auch hinter den Presseberichten über gescheiterte Großprojekte.
Ältere Entwicklungsmethoden sind im Allgemeinen langsamer. Bei diesen Methoden gibt es
zwar einige Kontrollen und eine Qualitätssicherung, aber die grundlegenden Aufgaben – das
Codieren, Kompilieren, Linken und die Tests – laufen wesentlich langsamer ab. Insbesondere
auf einem Mainframe ist dieser Zyklus oft so ermüdend, dass Programmierer einen Großteil
der Zeit mit irgendwelchen Tests verbringen, um zu vermeiden, dass ein Codefehler einen weiteren vollen Zyklusdurchlauf verursacht.
Werkzeuge der vierten Generation verleiten Entwickler dazu, sich sofort in die Produktion zu
stürzen. Änderungen können so schnell eingebaut werden, dass den Tests nur noch wenig Beachtung geschenkt wird. Das Eliminieren praktisch aller Prüfungsmöglichkeiten kompliziert
das Problem weiter. Viele meinen, dass sich ein eventueller Fehler nachträglich noch schnell
beheben lässt. „Falls die Daten beschädigt sind, können wir das Ganze mit einer schnellen Aktualisierung beheben. Sollte das nicht schnell genug gehen, tunen wir sie eben im HauruckVerfahren. Bleiben wir im Zeitplan und zeigen denen, aus welchem Holz wir geschnitzt sind.“
42
4
Oracle-Applikationen planen – Konzepte, Risiken und Standards
Bei einer wichtigen Oracle-Applikation sollte der Testzyklus länger und sorgfältiger als bei einem herkömmlichen Projekt sein. Das gilt auch, wenn es eine ausgefeilte Projektsteuerung
gibt und erfahrene Projektmanager das Sagen haben – gerade sie neigen zu übertriebenem
Selbstvertrauen und oft zu nachlässigen Testverfahren. Die Tests müssen die Eingabebildschirme und Reports, die Datenbelastungen und Updates, die Datenintegrität und Engpässe
beachten, und sich besonders mit den Transaktions- und Speichervolumina beschäftigen, die
zu Spitzenzeiten auftreten.
Da tatsächlich alles so einfach ist wie behauptet, verläuft die Anwendungsentwicklung mit
Oracle-Werkzeugen ungemein schnell. Doch damit wird automatisch der Umfang der Tests
reduziert, die üblicherweise ein Bestandteil der Entwicklung sind. Gleichzeitig vergrößert sich
damit der nachträgliche Aufwand zum Beheben der aufgetretenen Fehler. Dieser Umstand
wird von Einsteigern meistens nicht bedacht, ist aber im Projektplan unbedingt zu berücksichtigen.
4.6
Der Stellenwert der neuen Vision
Viele von uns warten auf den Tag, an dem wir einfach eine „natürliche“ Abfrage in unserer
Sprache eingeben können, und die Antwort nach wenigen Augenblicken auf den Bildschirm
bekommen.
Wir sind diesem Ziel schon sehr viel näher, als sich die meisten von uns vorstellen. Der einschränkende Faktor ist nicht mehr die Technologie, sondern eher unsere gedankliche Strenge
beim Anwendungsdesign. Oracle kann problemlos ausgefeilte sprachorientierte Systeme erstellen, die leicht verständlich sind und auch weniger geübte Anwender bedienen können. Die Oracle-Datenbank hat das Potenzial und die Werkzeuge sind bereits vorhanden, doch nur wenige
verstehen sich darauf und setzen dies um.
Klarheit und Verständlichkeit sollten das Kennzeichen jeder Oracle-Anwendung sein. Die Anwendungen sollten für Benutzer ohne Programmiererfahrung leicht verständlich sein, und die
Informationen über einfache Abfragen zur Verfügung stellen.
Aber wie? Das oberste Ziel beim Design sollte darin bestehen, die Anwendung so verständlich
und die Bedienung so einfach wie möglich zu gestalten. Auch wenn Sie sich mal irren, sollte
diese Richtung beibehalten werden, selbst wenn dadurch mehr CPU-Zeit und Plattenplatz benötigt wird. Eine Einschränkung ist bei diesem Ansatz nur dann gegeben, wenn man eine extrem einfache Anwendung aufbaut und dafür zu komplexe Programme erstellt, die nur schwer
oder überhaupt nicht zu pflegen sind. Das wäre ein ebenso großer Fehler. Deshalb sollte ein
Gleichgewicht herrschen, und die Orientierung am Endanwender nicht für eine clevere Codierung vernachlässigt werden.
4.6.1
Umgebungen ändern sich
Die Kosten für den Betrieb eines Rechners, ausgedrückt in Millionen Instruktionen pro Sekunde (MIPS), sind in der Vergangenheit jährlich um 20 Prozent gesunken. Andererseits sind
die Arbeitskosten kontinuierlich gestiegen, was nicht nur am allgemeinen Trend liegt, sondern
auch an der Tatsache, dass die Gehälter der langjährigen Mitarbeiter ständig steigen, je länger
4.6
Der Stellenwert der neuen Vision
und erfolgreicher sie für ein Unternehmen tätig sind. Das bedeutet, dass jede Arbeit, die vom
Menschen auf die Maschine verschoben werden kann, eine kostensenkende Maßnahme ist.
Haben wir diese Erkenntnis beim Anwendungsdesign berücksichtigt? Die Antwort lautet „ein
bisschen“, und bleibt ziemlich vage. Der eigentliche Fortschritt fand in den Umgebungen statt.
Diese visionäre Aufgabe wurde zuerst bei Xerox, dann auf dem Macintosh und jetzt in X-Windows, MS-Windows, webbasierten Browsern und anderen grafikorientierten Systemen realisiert. Diese Umgebungen sind viel leichter zu bedienen und zu verstehen als die älteren, zeichenbasierten Systeme, was früher Tage dauerte, geschieht heute in Minuten. In einigen
Bereichen sind die Verbesserungen so groß, dass wir dabei aus den Augen verloren haben, wie
schwer manche Aufgaben normalerweise waren.
Leider wurde dieses Konzept einer anpassungsfähigen und freundlichen Umgebung nur von
wenigen Entwicklern aufgegriffen. Selbst wenn sie in diesen Umgebungen arbeiten, pflegen sie
alte Gewohnheiten, die nicht mehr zeitgemäß sind.
4.6.2
Codes, Abkürzungen und Benennungsstandards
Das Problem mit alten Programmiergewohnheiten drückt sich am besten in den Codes, Abkürzungen und Benennungsstandards aus, die bei der Betrachtung der Bedürfnisse der Endanwender oftmals ignoriert werden. Werden diese drei Punkte überhaupt beachtet, berücksichtigen sie meistens nur die Belange der Systemtruppe. Das mag als trockenes und
uninteressantes Problem erscheinen, kann aber den Unterschied ausmachen zwischen einem
großen Erfolg und murrender Akzeptanz, zwischen einem Quantensprung in der Produktivität und marginalen Fortschritten, zwischen effektiven und gelangweilten Anwendern, die die
Entwickler mit immer neuen Anforderungen eindecken.
Üblicherweise wurden Geschäftseintragungen in Haupt- und Rechnungsbüchern vorgenommen. Jedes Ereignis und jede Transaktion wurde niedergeschrieben, Zeile für Zeile. Im Zuge
der Applikationsentwicklung wurden die Datenwerte durch Codes ersetzt (wie „01“ für Forderungen und „02“ für Verbindlichkeiten). Die Angestellten mussten diese Codes entweder
kennen oder nachschlagen, und sie an den entsprechenden Stellen am Bildschirm eingeben.
Dies ist zwar ein extremes Beispiel, aber tatsächlich arbeiten Tausende von Anwendungen
nach diesem Prinzip, wobei die Bedeutung der Bits schwer zu verstehen oder zu erlernen ist.
Dieses Problem wurde vor allem bei der Entwicklung von großen konventionellen MainframeSystemen angesprochen. Als man dort die relationalen Datenbanksysteme einführte, wurden sie
einfach als Ersatz für die älteren Eingabe/Ausgabe-Methoden wie Virtual Storage Access Method (VSAM) und Information Management System (IMS) benutzt. Die Leistungsfähigkeit und
Funktionen der relationalen Datenbank werden bei einem solchen Einsatz praktisch vergeudet.
4.6.3
Warum Codes statt Sprache?
Warum werden überhaupt Codes eingesetzt? Hierfür werden üblicherweise zwei Argumente
angeführt:
■ Eine Kategorie enthält so viele Elemente, dass sie sich mit den Mitteln der normalen Sprache nicht darstellen lassen.
■ Um Platz auf dem Computer zu sparen.
43
44
4
Oracle-Applikationen planen – Konzepte, Risiken und Standards
Der zweite Punkt ist ein Anachronismus. Arbeitsspeicher oder Speichermedien waren einst so
teuer und die CPUs so langsam, dass die Programmierer jedes Stückchen Information auf dem
kleinst möglichen Platz unterbringen mussten. Zahlen und Zeichen belegten im Speicher des
Rechners nur halb soviel Platz wie Buchstaben, und Codes reduzierten die Anforderungen an
die Maschine noch weiter.
Weil die Rechner teuer waren, mussten die Entwickler für alles Codes einsetzen, damit überhaupt irgendetwas lief. Das war die technische Lösung für ein wirtschaftliches Problem. Die Anforderungen an die Anwender, die alle möglichen bedeutungslosen Codes erlernen mussten,
waren fürchterlich. Die Maschinen waren einfach zu teuer und zu langsam, als dass sie sich an
die Bedürfnisse der Menschen hätten anpassen können. Ergo wurden die Menschen an die Maschinen angepasst. Das war ein notwendiges Übel.
Diese wirtschaftliche Rechtfertigung für Codes ist seit Jahren überholt. Die Rechner sind heute
schnell und billig genug, um sich an den Menschen anzupassen und mit einer verständlichen
Sprache zu arbeiten. Trotzdem setzen die Entwickler, ohne darüber nachzudenken, weiterhin
auf Codes.
Der erste Punkt – dass zu viele Elemente pro Kategorie vorhanden sind – ist zwar gewichtiger,
aber bei Weitem nicht so schwerwiegend, wie es auf den ersten Blick erscheint. Eine Idee ist,
dass es viel weniger Zeit in Anspruch nimmt (und daher billiger ist), numerische Werte einzugeben statt Textstrings. Diese Rechtfertigung gilt bei Oracle allerdings nicht. Nicht nur, dass es
teuer ist, die Leute so zu schulen, dass sie die richtigen Codes für die Namen der Kunden, Produkte, Transaktionen und anderes kennen, hinzu kommen auch noch die Kosten für Fehler
(die bei codebasierten Systemen relativ häufig vorkommen). Doch vor allem bedeutet die Verwendung von Codes, dass die Leistungsfähigkeit von Oracle bei Weitem nicht ausgenutzt wird.
Oracle kann z. B. die ersten Zeichen des Begriffs erkennen und den Rest selbstständig ausfüllen.
Dasselbe gilt auch für Produktnamen, Transaktionen (ein „k“ wird automatisch durch „Kauf“,
ein „v“ durch „Verkauf“ ersetzt) und so weiter, die in einer Anwendung eingesetzt werden. Oracle gelingt dies dank einer ausgefeilten Mustererkennung.
4.6.4
Die Vorteile des Benutzer-Feedbacks
In diesem Bereich lässt sich ein unmittelbarer, zusätzlicher Nutzen ausmachen: Es gibt kaum
noch Eingabefehler, weil der Anwender ein sofortiges Feedback über die eingegebenen Geschäftsinformationen erhält. Ziffern und Codes werden nicht mehr falsch eingegeben. Und bei
Finanzanwendungen gehen Beträge seltener auf Interimskonten verloren, nur weil die Eingaben falsch waren, was wiederum signifikante Einsparungen nach sich zieht.
Auch die Anwendungen selbst werden verständlicher: Bildschirme und Reports werden aus
endlosen Zahlenreihen in leserliche und verständliche Formate transformiert. Das Ändern des
Anwendungsdesigns von der Code- zur Sprachorientierung hat nachhaltige Auswirkungen
auf das Unternehmen und seine Mitarbeiter. Für Anwender, die mit Codehandbüchern überfrachtet wurden, sind sprachorientierte Anwendungen eine große psychologische Erleichterung.
4.7
Schritte in die richtige Richtung
4.7
Schritte in die richtige Richtung
Eine andere Version der Rechtfertigung zum Thema „zu viele Elemente pro Kategorie“ lautet,
dass die Anzahl der Produkte, Kunden oder Transaktionstypen einfach zu groß sei, um zwischen den einzelnen Namen unterscheiden zu können, oder dass in einer Kategorie viele
Punkte identisch oder zumindest sehr ähnlich sind (z. B. Kundennamen wie „Hans Müller“).
Eine Kategorie kann so viele Einträge enthalten, dass die einzelnen Optionen nur schwer zu
behalten oder zu unterscheiden sind. In den meisten Fällen lässt sich das auf eine unvollständige Kategorisierung der Informationen zurückführen: Zu viele verschiedene Dinge wurden
in eine zu umfängliche Kategorie gestopft. Das Entwickeln einer Anwendung mit einer streng
sprachorientierten Ausrichtung erfordert im Gegensatz zu einer codebasierten Anwendung,
dass Entwickler und Anwender viel Zeit miteinander verbringen – Informationen werden von
geschäftlichen Abläufen getrennt, die natürlichen Beziehungen und Kategorien sind zu ermitteln, und dann kann vorsichtig eine Datenbank und ein Benennungsschema erstellt werden,
das die gewonnenen Erkenntnisse einfach und akkurat wiedergibt.
Die drei grundlegenden Schritte hierzu sind:
1. Das Normalisieren der Daten.
2. Die Auswahl von selbsterklärenden Namen für Tabellen und Spalten.
3. Die Auswahl von selbsterklärenden Namen für die Daten.
Jeder dieser Schritte wird nachfolgend erklärt. Das Ziel ist der Entwurf einer Anwendung, in
der die Daten vernünftig organisiert und in Tabellen und Spalten abgespeichert werden, deren
Namen dem Anwender vertraut sind. Die Daten sollen selbsterklärende Namen haben, keine
Codes.
4.7.1
Die Normalisierung
Die Beziehungen zwischen Ländern, zwischen den Abteilungen in einem Unternehmen oder
Anwendern und Entwicklern sind normalerweise das Ergebnis von besonderen historischen
Umständen, und können die aktuellen Beziehungen selbst dann noch definieren, wenn sich
die Bedingungen eigentlich schon lange geändert haben. Das Ergebnis können anormale, oder
neusprachlich, dysfunktionale Beziehungen sein. Die Historie und die Umstände haben in Bezug auf Daten oft die gleichen Auswirkungen – es kommt darauf an, wann sie gesammelt, organisiert und berichtet wurden. Und auch Daten können anormal, und damit dysfunktional
werden.
Normalisierung ist ein Prozess, bei dem Dinge richtiggestellt, d. h. normalisiert werden. Dieser Begriff stammt von dem lateinischen Wort norma ab, das ein Zimmermannsquadrat bezeichnete, mit dessen Hilfe der rechte Winkel ermittelt wurde. In der Geometrie bezeichnet
man eine Linie, die im rechten Winkel zu einer anderen Linie steht, als „normal“. In einer
relationalen Datenbank hat dieser Begriff auch eine spezielle mathematische Bedeutung, die
mit der Aufteilung der Datenelemente (z. B. Namen, Adressen oder Fertigkeiten) in verwandte Gruppen zutun hat, und die normalen oder „korrekten“ Beziehungen zwischen ihnen definiert.
45
46
4
Oracle-Applikationen planen – Konzepte, Risiken und Standards
Die grundlegenden Konzepte der Normalisierung werden so erläutert, dass Anwender sie in
das Design einer Anwendung miteinbeziehen oder eine bereits bestehende Applikation besser
verstehen können. Es wäre ein Fehler zu glauben, dass dieser Prozess nur beim Design einer
Datenbank oder einer Computeranwendung einsetzbar sei. Die Normalisierung resultiert aus
profunden Einblicken, welche Informationen in einem Unternehmen eingesetzt werden und
wie die verschiedenen Elemente dieser Informationen miteinander verknüpft sind.
Das logische Modell
Ein erster Schritt im Analyseprozess ist der Aufbau eines logischen Modells, das einfach ein normalisiertes Diagramm aller im Unternehmen eingesetzten Daten ist. Das Wissen darüber, wie
und warum die Daten zerlegt und getrennt werden, ist wesentlich für das Verständnis des Modells. Das Modell wiederum ist grundlegend für den Aufbau einer Anwendung, die lange genutzt wird und keine besondere Pflege benötigt.
Die Normalisierung wird üblicherweise mithilfe des Begriffs Form diskutiert: Man unterscheidet die erste, zweite und dritte Normalform, wobei die dritte Form den am höchsten normalisierten Status wiedergibt. Es existiert auch noch eine vierte und fünfte Normalform, diese
werden aber in diesem Kontext nicht behandelt.
Nehmen wir ein Buchregal: Für jedes Buch können Sie bestimmte Informationen speichern –
den Titel, den Publizisten, den Autor und verschiedene beschreibende Begriffe über den Inhalt
des Titels. Angenommen, diese buchbezogenen Daten sollen die Grundlage für das Design der
Oracle-Tabellen sein. Nennen wir die Tabelle BOOKSHELF, und die Spalten sollen Title, Publisher, Author1, Author2, Author3 sowie Category1, Category2 und Category3 heißen. Die
Anwender haben mit dieser Tabelle bereits ein Problem: In der BOOKSHELF-Tabelle können
für ein Buch höchstens drei Autoren oder Kategorien angegeben werden.
Was geschieht, wenn sich die Liste der akzeptablen Kategorien ändert? Irgendjemand müsste
sich durch alle Zeilen in der BOOKSHELF-Tabelle arbeiten und sämtliche alten Werte korrigieren. Und was passiert, wenn einer der Autoren seinen Namen ändert? Auch in diesem Fall
sind alle abhängigen Datensätze zu ändern. Und was geschieht, wenn ein vierter Autor an einem Titel mitarbeitet?
Dies sind eigentlich keine technischen oder verarbeitungsbezogenen Probleme, auch wenn sie
im Zusammenhang mit dem Entwurf einer Datenbank auftauchen. Es gibt noch weitaus mehr
grundlegende Fragen, die eine zweckmäßige und logische Strukturierung der Informationen
in einem Unternehmen betreffen. Genau mit diesen Themen setzt sich die Normalisierung
auseinander. Dazu werden die einzelnen Elemente der Daten in verwandten Gruppen reorganisiert, man beseitigt dysfunktionale Beziehungen und stellt die normalen Beziehungen her.
Die Daten normalisieren
In einem ersten Schritt bringt man die Daten in die erste Normalform. Dazu werden die Daten
in separate Tabellen verschoben, wobei die Daten in jeder Tabelle vom Typ her ähnlich sind,
und vergibt jeder Tabelle einen Primärschlüssel – ein eindeutiges Label oder einen Identifier.
Damit werden sich wiederholende Datengruppen, wie die Autoren, eliminiert.
4.7
47
Schritte in die richtige Richtung
Anstatt pro Buch nur drei Autoren zuzulassen, hinterlegt man die Daten der Autoren in einer
eigenen Tabelle, mit jeweils einer Zeile pro Name und Beschreibung. Damit erübrigt sich die
Notwendigkeit, für die BOOKSHELF-Tabelle eine variable Anzahl von Autoren zu definieren.
Zudem ist es ein besseres Design, als die BOOKSHELF-Tabelle auf drei Autoren zu beschränken.
Danach definieren Sie für jede Tabelle den Primärschlüssel: Welches Element identifiziert eine
Zeile eindeutig und erlaubt, eine Zeile mit Informationen zu extrahieren? Um das Beispiel zu
vereinfachen, nehmen wir an, die Autorennamen seien eindeutig: dann kann AuthorName der
Primärschlüssel für die AUTHOR-Tabelle sein.
Damit wurde die BOOKSHELF-Tabelle in zwei Tabellen aufgeteilt: AUTHOR mit den Spalten
AuthorName (dem Primärschlüssel) und Comments, und BOOKSHELF mit dem Primärschlüssel Title und den Spalten Publisher, Category1, Category2, Category3, Rating und RatingDescription. Eine dritte Tabelle, BOOKSHELF_AUTHOR, enthält die Verbindungen: Mehrere
Autoren können für ein einzelnes Buch, und ein Autor für viele Bücher aufgelistet werden –
eine so genannte Many-to-many-Beziehung (M:M-Beziehung). Abbildung 4-8 zeigt diese Beziehungen und die Primärschlüssel.
Primärschlüssel
Abbildung 4-8: Die Tabellen BOOKSHELF, AUTHOR und BOOKSHELF_AUTHOR.
Der nächste Schritt im Normalisierungsprozess, die zweite Normalform, trennt Daten, die nur
von einem Teil des Schlüssels abhängen. Gibt es Attribute, die nicht vom gesamten Schlüssel abhängen, sollte man diese Daten in eine neue Tabelle verschieben. In unserem Fall hängt RatingDescription nicht wirklich von Title ab – es basiert auf dem Spaltenwert Rating. Deshalb sollte
man es auch in eine separate Tabelle verschieben.
Im letzten Schritt, der dritten Normalform, wirft man alles aus den Tabellen, das nicht ausschließlich vom Primärschlüssel abhängt. In diesem Beispiel hängen die Kategorien zusammen: Sie würden einen Titel nicht gleichzeitig als „Fiction“ und „Nonfiction“ einordnen, und
unter der Kategorie „Adult“ gibt es sicher andere Unterkategorien als unter „Children“. Die
Kategorieinformationen werden deshalb in eine separate Tabelle verschoben. Abbildung 4-9
zeigt die Tabellen in der dritten Normalform.
48
4
Oracle-Applikationen planen – Konzepte, Risiken und Standards
Abbildung 4-9: BOOKSHELF und dazugehörige Tabellen.
Befinden sich die Daten in der dritten Normalform, sind sie damit automatisch schon in der
zweiten und ersten Normalform. Der gesamte Prozess lässt sich deshalb auch verkürzen, somit
muss man sich nicht von Normalform zu Normalform bewegen. Sortieren Sie die Daten so,
dass die Spalten in jeder Tabelle, bis auf den Primärschlüssel, nur vom gesamten Primärschlüssel abhängig sind. Die dritte Normalform wird auch als „der Schlüssel, der gesamte Schlüssel
und nichts als der Schlüssel“ beschrieben.
Durch die Daten navigieren
Die Bücherbord-Datenbank befindet sich nun in der dritten Normalform. Abbildung 4-10
zeigt ein Beispiel dafür, was diese Tabellen enthalten können. Es ist leicht nachvollziehbar, dass
diese Tabellen zusammengehören. Basierend auf den Schlüsseln der Tabellen gehen Sie von einer Tabelle zur anderen und holen die Informationen über einen bestimmten Autor ab. Der
Primärschlüssel in jeder Tabelle kann eine einzelne Zeile eindeutig identifizieren. Wählt man
beispielsweise Stephen Jay Gould, findet man diesen Datensatz in der AUTHOR-Tabelle, weil
AuthorName der Primärschlüssel ist.
Wenn Sie sich Harper Lee in der AuthorName-Spalte der BOOKSHELF_AUTHOR-Tabelle
ansehen, werden Sie feststellen, dass er eine Novelle mit dem Titel „To Kill A Mockingbird“ veröffentlichte. Danach können Sie für dieses Buch in der BOOKSHELF-Tabelle den Publizisten,
die Kategorie und das Rating nachschauen. Die Beschreibung für das Rating befindet sich in
der RATING-Tabelle.
Hätten Sie in der BOOKSHELF-Tabelle nach „To Kill A Mockingbird“ gesucht, würde die Suche über den Primärschlüssel der Tabelle ausgeführt. Um den Autor des Buchs zu finden,
können Sie Ihren früheren Suchpfad umdrehen: Sie suchen in BOOKSHELF_AUTHOR nach
Datensätzen, bei denen dieser Wert in der Title-Spalte steht – die „Title“-Spalte ist ein
Fremdschlüssel in der BOOKSHELF_AUTHOR-Tabelle. Erscheint der Primärschlüssel für
BOOKSHELF in einer anderen Tabelle, wie in der BOOKSHELF_AUTHOR-Tabelle, bezeichnet man das als Fremdschlüssel auf diese Tabelle.
4.7
49
Schritte in die richtige Richtung
AUTHOR
AuthorName
--------------------DIETRICH BONHOEFFER
ROBERT BRETALL
ALEXANDRA DAY
STEPHEN JAY GOULD
SOREN KIERKEGAARD
HARPER LEE
LUCY MAUD MONTGOMERY
JOHN ALLEN PAULOS
J. RODALE
RATING
Rating
---------1
2
3
4
5
Comments
------------------------------------------GERMAN THEOLOGIAN, KILLED IN A WAR CAMP
KIERKEGAARD ANTHOLOGIST
AUTHOR OF PICTURE BOOKS FOR CHILDREN
SCIENCE COLUMNIST, HARVARD PROFESSOR
DANISH PHILOSOPHER AND THEOLOGIAN
AMERICAN NOVELIST, PUBLISHED ONLY ONE NOVEL
CANADIAN NOVELIST
MATHEMATICS PROFESSOR
ORGANIC GARDENING EXPERT
RatingDescription
----------------ENTERTAINMENT
BACKGROUND INFORMATION
RECOMMENDED
STRONGLY RECOMMENDED
REQUIRED READING
CATEGORY
CategoryName
-------------ADULTREF
ADULTFIC
ADULTNF
CHILDRENPIC
CHILDRENFIC
CHILDRENNF
ParentCategory
--------------ADULT
ADULT
ADULT
CHILDREN
CHILDREN
CHILDREN
SubCategory
-----------REFERENCE
FICTION
NONFICTION
PICTURE BOOK
FICTION
NONFICTION
BOOKSHELF_AUTHOR
Title
-----------------------------TO KILL A MOCKINGBIRD
WONDERFUL LIFE
INNUMERACY
KIERKEGAARD ANTHOLOGY
KIERKEGAARD ANTHOLOGY
ANNE OF GREEN GABLES
GOOD DOG, CARL
LETTERS AND PAPERS FROM PRISON
AuthorName
--------------------HARPER LEE
STEPHEN JAY GOULD
JOHN ALLEN PAULOS
ROBERT BRETALL
SOREN KIERKEGAARD
LUCY MAUD MONTGOMERY
ALEXANDRA DAY
DIETRICH BONHOEFFER
BOOKSHELF
Title
-----------------------------TO KILL A MOCKINGBIRD
WONDERFUL LIFE
INNUMERACY
KIERKEGAARD ANTHOLOGY
ANNE OF GREEN GABLES
GOOD DOG, CARL
LETTERS AND PAPERS FROM PRISON
Publisher
--------------------HARPERCOLLINS
W.W.NORTON & CO.
VINTAGE BOOKS
PRINCETON UNIV PR
GRAMMERCY
LITTLE SIMON
SCRIBNER
Abbildung 4-10: Beispieldaten aus den BOOKSHELF-Tabellen.
CategoryName
-----------ADULTFIC
ADULTNF
ADULTNF
ADULTREF
CHILDRENFIC
CHILDRENPIC
ADULTNF
Rating
-----5
5
4
3
3
1
4
50
4
Oracle-Applikationen planen – Konzepte, Risiken und Standards
Diese Tabellen zeigen auch praxisbezogene Charakteristiken: Es gibt Ratings und Kategorien,
die von den Büchern im Bücherbord nicht verwendet werden. Da die Daten logisch organisiert
sind, können Sie Datensätze mit potenziellen Kategorien, Ratings und Autoren vorhalten, selbst
wenn keines der aktuellen Bücher diese Werte verwendet.
Das ist ein sinnvoller und logischer Weg zur Organisation von Daten, auch wenn man die „Tabellen“ nur handschriftlich auf Papier festhält. Natürlich muss noch einiges getan werden, um
dies in eine echte Datenbank zu verwandeln. So lässt sich AuthorName beispielsweise in FirstName und LastName zerlegen, und möglicherweise suchen Sie nach einem Weg, um anzeigen
zu können, welcher Autor der Hauptautor ist oder ob ein Autor gleichzeitig der Herausgeber
ist.
Diesen umfassenden Prozess nennt man Normalisierung. Komplizierter ist es nicht. Zu einem
guten Design gehören noch einige andere Punkte, aber die Grundlagen für die Analyse von
„normalen“ Beziehungen zwischen den verschiedenen Datenelementen sind genau so einfach
und gradlinig wie oben dargestellt.
Dennoch ist in einem Punkt Vorsicht geboten. Die Normalisierung gehört zum Analyseprozess,
und hat nichts mit dem Design zu tun. Das Design einer Datenbankanwendung beschäftigt sich
mit ganz anderen Aspekten, und es wäre ein grundsätzlicher Fehler anzunehmen, dass die normalisierten Tabellen des logischen Modells das „Design“ der tatsächlichen Datenbank wären.
Im weiteren Verlauf des Kapitels werden diese Fragen speziell für Entwickler weiter ausgeführt.
4.7.2
Selbsterklärende Namen für Tabellen und Spalten
Sobald die Beziehungen zwischen den verschiedenen Datenelementen in einer Anwendung
erkannt und entsprechend getrennt wurden, sind passende Namen für die Tabellen und Spalten zu wählen, in denen die Daten hinterlegt werden sollen. Diesem Aspekt widmen selbst
jene zu wenig Aufmerksamkeit, die es eigentlich besser wissen müssten. Die Tabellen- und
Spaltennamen werden oft ohne Rücksprache mit den Endanwendern entwickelt, und während der Designphase nicht mehr überprüft. Geht eine solche Anwendung in den Echtbetrieb, haben diese Versäumnisse oft schwerwiegende Konsequenzen.
Sehen wir uns beispielsweise die Tabelle in Abbildung 4-10 an. Die Tabellen- und Spaltennamen sind praktisch alle selbsterklärend. Selbst ein Endanwender, der noch nie mit den relationalen Ideen und SQL zu tun hatte, würde eine Abfrage wie die folgende relativ leicht verstehen und auch wiederholen können:
select Title, Publisher
from BOOKSHELF
order by Publisher;
Der Anwender versteht diese Abfrage, weil alle verwendeten Wörter vertraut sind. Es gibt keine unklaren oder falsch definierten Ausdrücke. Sind Tabellen mit zahlreichen Spalten zu definieren, kann die Benennung der Tabellen ein schwieriges Unterfangen sein, aber in diesem Fall
sind einige wenige Regeln recht hilfreich. Sehen wir uns die Schwierigkeiten näher an, die
durch fehlende Namenskonventionen verursacht werden können. Was wäre, wenn Sie folgende Namen gewählt hätten?
4.7
51
Schritte in die richtige Richtung
BOOKSHELF
------------title
pub
cat
rat
B_A
----------------title
aname
AUTHS
-----------anam
comms
CATEGORIES
------------cat
p_cat
s_cat
Die Benennungstechnik dieser Tabelle ist merkwürdig und leider weit verbreitet. Die Tabellen
und Spalten wurden gemäß den Konventionen (oder fehlenden Konventionen) benannt, die
einige bekannte Hersteller und Softwarehäuser einsetzen.
Die folgende Aufstellung zeigt einige der offensichtlichsten Fehler, die bei der Namensliste gemacht wurden:
■ Abkürzungen werden ohne triftigen Grund verwendet. Damit ist es praktisch unmöglich,
sich einen Tabellen- oder Spaltennamen zu merken. Die Namen könnten auch Codes
sein, weil der Anwender erst nach deren Bedeutung suchen muss.
■ Die Abkürzungen sind inkonsistent.
■ Der Zweck oder die Bedeutung einer Spalte oder Tabelle lässt sich nicht aus dem Namen ableiten. Neben dem Umstand, dass man sich die Schreibweise der Namen nur sehr schwer
merken kann, verschleiern sie zusätzlich den eigentlichen Inhalt der Daten in den Spalten
und Tabellen. Was ist z. B. „P_cat“ oder „Comms“?
■ Die Unterstriche werden inkonsistent eingesetzt. Manchmal werden sie zur Trennung von
Namen und Wörtern eingesetzt, manchmal überhaupt nicht. Wie soll sich da jemand
merken, welcher Name jetzt einen Unterstrich besitzt und welcher nicht?
■ Die Verwendung des Plurals ist inkonsistent. Heißt es CATEGORY oder CATEGORIES,
Comm oder Comms?
■ Die verwendeten Regeln haben unmittelbare Einschränkungen. Falls der erste Buchstabe des
Tabellennamens für einen Spaltennamen verwendet wird (wie in Anam), stellt sich die
Frage, was passiert, wenn man eine zweite Tabelle benötigt, die gleichfalls mit einem „A“
beginnt. Heißt die Name-Spalte in dieser Tabelle dann auch „Anam“? Warum heißt die
Spalte in diesem Fall nicht einfach „Name“?
Das sind nur einige der offensichtlichsten Schwierigkeiten. Endanwender, die mit solchen
Tabellen zu tun haben, können nicht einfach Abfragen eingeben. Diese Abfragen haben nicht
den gleichen intuitiven und vertrauten Charakter wie bei der BOOKSHELF-Tabelle. Und das
beeinträchtigt die Akzeptanz und Nützlichkeit der Anwendung.
Von den Entwicklern wird üblicherweise verlangt, dass Tabellen- und Spaltennamen maximal
sechs bis acht Zeichen lang sind. Als Ergebnis bestehen die Namen aus einem unverständlichen Mix aus Buchstaben, Zahlen und kryptischen Abkürzungen. Wie so viele andere Einschränkungen, die dem Anwender bei älteren Technologien auferlegt wurden, ist auch diese
nicht mehr länger haltbar. Oracle erlaubt Tabellen- und Spaltennamen mit einer Länge von
bis zu 30 Zeichen. Das gibt den Entwicklern genügend Raum, um vollständige, eindeutige und
selbsterklärende Benennungen zu vergeben.
52
4
Oracle-Applikationen planen – Konzepte, Risiken und Standards
Die erwähnten Schwierigkeiten implizieren auch Lösungen, wie das Vermeiden von Abkürzungen und Plural. Unterstriche sollten entweder ganz weggelassen oder konsistent verwendet werden. Diese wenigen Faustregeln werden das mögliche Chaos im Bereich der
Namensgebung beseitigen. Gleichzeitig müssen die Konventionen einfach, leicht verständlich und einprägsam sein. Im übertragenen Sinn benötigt man auch für die Namen eine Normalisierung. Genau wie bei Daten, die logisch analysiert, zweckorientiert getrennt und
normalisiert werden, sollte man auch bei den Benennungskonventionen die nötige Aufmerksamkeit walten lassen.
4.7.3
Selbsterklärende Namen für die Daten
Nachdem die wichtige Frage der Benennungskonventionen für die Tabellen und Spalten besprochen wurde, muss man sich die Daten selbst ansehen. Werden die Daten aus den Tabellen in einem Report ausgedruckt, hat die Transparenz der Daten auch Einfluss auf die
Verständlichkeit des Reports. Im BOOKSHELF-Beispiel ist Rating ein Codewert, und Category ist eine Verkettung aus mehreren Werten. Ist das eine Verbesserung? Wenn Sie jemanden nach einem Buch gefragt haben, möchten Sie dann erfahren, dass es in AdultNF als 4
eingestuft ist? Warum sollte es einer Maschine erlaubt sein, weniger klar zu sein?
Hält man die Informationen mit umgangssprachlichen Begriffen vor, gestalten sich auch die
Abfragen wesentlich einfacher. Die Abfrage sollte so umgangssprachlich wie möglich sein:
select Title, AuthorName
from BOOKSHELF_AUTHOR;
4.8
Groß- und Kleinschreibung bei Namen
und Daten
Bei Oracle kann man sich Tabellen- und Spaltennamen viel einfacher merken, weil es unerheblich ist, ob die Namen groß- oder kleingeschrieben wurden. Tabellen- und Spaltennamen
werden intern immer in Großbuchstaben abgespeichert. Wenn Sie eine Abfrage eingeben,
konvertiert Oracle die Tabellen- und Spaltennamen in Großbuchstaben und überprüft sie danach mit seinem Dictionary. Andere relationale Datenbanksysteme beachten hingegen die
Groß- und Kleinschreibung. Wenn man einen Spaltennamen als „Ability“ eingibt, der in der
Datenbank selbst als „ability“ oder „ABILITY“ hinterlegt ist, wird die Abfrage nicht verstanden.
Hinweis:
Sie können Oracle zwingen, Tabellen und Spalten mit groß- oder kleingeschriebenen
Namen anzulegen, was aber die Abfrage und die Arbeit mit den Daten erschwert.
Setzen Sie also immer die standardmäßige Großschreibung ein.
Tabellen in Groß- und Kleinschreibung anlegen zu können, wird oft als Vorteil gewertet, weil
die Entwickler mehrere Tabellen mit ähnlichen Namen anlegen können. So lässt sich beispielsweise eine WORKER-, wORrker- und eine Worker-Tabelle usw. anlegen. Wie kann sich jemand, der Entwickler eingeschlossen, diese Unterschiede überhaupt merken? Das Ganze ist
4.9
Namen normalisieren
doch kein Vorteil, sondern eher ein Rückschritt, und Oracle ist klugerweise nicht in diese Falle
gegangen.
Ähnlich liegen die Dinge bei Daten, die in einer Datenbank gespeichert sind. Es gibt Wege, Daten in einer Datenbank unabhängig von der jeweiligen Schreibweise aufzuspüren, aber diese
Methoden stellen eine unnötige und zusätzliche Belastung dar. Bis auf wenige Ausnahmen ist
es viel einfacher, die Daten in Großbuchstaben abzuspeichern. Damit werden einerseits die
Abfragen erleichtert, und andererseits sehen die Reports konsistenter aus. Falls Daten in Kleinbuchstaben oder in gemischter Schreibweise zu hinterlegen sind, stellt Oracle die entsprechenden Konversionsfunktionen zur Verfügung.
Wenn Sie sich dieses Kapitel noch einmal vergegenwärtigen, werden Sie feststellen, dass wir
dieser Praxis bisher nicht gefolgt sind. Ab sofort werden die Daten in der Datenbank, mit Ausnahme von wenigen Tabellen und einigen isolierten Instanzen, in Großbuchstaben dargestellt.
4.9
Namen normalisieren
Auf dem Markt gibt es verschiedene Werkzeuge, mit denen man umgangssprachliche Abfragen stellen kann, statt mit unsinnigen Begriffen arbeiten zu müssen. Diese Produkte bauen
eine logische Entsprechung zwischen den umgangssprachlichen Begriffen und den schwer zu
merkenden Spalten-, Tabellennamen und Codes auf. Dieses Mapping muss genau durchdacht
sein, doch wenn es einmal funktioniert, erleichtert es die Interaktion mit der Anwendung ganz
erheblich. Warum nicht von Anfang an Nägel mit Köpfen machen? Warum erst die Notwendigkeit schaffen, eine neue Ebene zu definieren, neue Produkte einzusetzen und mehr Arbeit
investieren zu müssen, wenn sich dieser Umstand durch das Einhalten von Namenskonventionen weitgehend vermeiden lässt?
Aus Performancegründen kann es notwendig sein, die Daten bestimmter Anwendungen in codierter Form vorzuhalten. Diese Codes sollten dem Anwender nicht angezeigt werden, und bei
der Dateneingabe oder bei Abfragen verborgen bleiben, was in Oracle problemlos möglich ist.
Wenn bei der Dateneingabe Codes benötigt werden, erhöhen sich auch die fehlerhaften Eingaben. Enthalten Reports anstelle von umgangssprachlichen Begriffen irgendwelche Codes,
kann es zu Fehlinterpretationen kommen. Und wenn die Benutzer neue oder Ad hoc-Reports
anlegen sollen, können Codes oder Abkürzungen dieses Unterfangen erschweren.
Bei Oracle können Benutzer in der gesamten Anwendung mit umgangssprachlichen Begriffen
arbeiten. Diese Möglichkeit zu ignorieren bedeutet, nicht die volle Leistungsfähigkeit von Oracle auszuschöpfen. Zudem erhält man im Ergebnis unverständlichere und unproduktivere
Anwendungen. Die Entwickler sollten die Gelegenheit nutzen – und die Anwender sollten dies
einfordern. Davon werden beide Gruppen enorm profitieren.
4.10
Gutes Design hat eine menschliche Seite
Sollten Sie Anfänger sein, möchten Sie vielleicht gleich mit der Arbeit in SQL beginnen. Diese
Programmiersprache wird im folgenden Kapitel behandelt. Der Rest dieses Kapitels beschäftigt sich mit Betrachtungen zu Performance, Benennung und Design.
53
54
4
Oracle-Applikationen planen – Konzepte, Risiken und Standards
Dieser Abschnitt beschäftigt sich mit der Projektentwicklung, wobei die Aufgaben im Vordergrund stehen, die Ihre Benutzer zu erfüllen haben. Das unterscheidet sich von der üblichen
Datenorientierung vieler Entwickler und Entwicklungsmethoden. Die Datennormalisierung
und die CASE-Technologie (Computer Aided Software Engi-neering) sind im Zusammenhang mit der Entwicklung von relationalen Anwendungen derart in den Mittelpunkt der Betrachtungen gerückt, dass die Fokussierung auf die Daten und die Fragen der referenziellen Integrität, Schlüssel, Normalisierung und Tabellendiagramme zu einer regelrechten Besessenheit geworden sind. Diese Punkte werden oft mit dem Design verwechselt – und sogar für das
Design gehalten – und irgendwann stellt man überrascht fest, dass es sich eigentlich um eine
Analyse handelt.
Die Normalisierung ist Analyse und kein Design. Darüber hinaus ist sie nur ein Teil der notwendigen Analyse zum Verständnis der Geschäftsabläufe und dem Aufbau einer nützlichen Anwendung. Das Ziel der Anwendungsentwicklung ist vor allem, die Geschwindigkeit und Effizienz der Unternehmensaufgaben zu erhöhen, indem die Umgebung, in der die Kollegen ihre
Arbeit erledigen, so sinnvoll und nützlich wie möglich gestaltet wird. Geben Sie den Leuten die
Kontrolle über ihre Informationen und gestalten Sie den Zugriff auf diese Informationen einfach und intuitiv: Im Ergebnis verbessert sich nicht nur die Produktivität, sondern auch das
Arbeitsumfeld. Wenn Sie die Kontrolle der Daten einer anderen Institution übergeben, und
diese Stelle die Informationen als unverständliche Codes präsentiert und wenig benutzerfreundliche Schnittstellen zur Verfügung stellt, werden Produktivität und Arbeitsklima darunter leiden – um sich das vorzustellen, muss man kein Genie sein.
Die hier vorgestellten Methoden bedeuten keine radikale Umwälzung dieses Prozesses, und
die Ihnen vertrauten Werkzeuge für die vorhandenen Datenstrukturen reichen zur Erledigung
dieser Aufgabe wahrscheinlich aus. Der vorgestellte Ansatz zielt ab auf die Entwicklung von reaktionsschnellen, angepassten und benutzerfreundlichen Anwendungen.
4.10.1 Die Aufgaben der Anwendung verstehen
Ein beim Aufbau einer Anwendung häufig vernachlässigter Aspekt ist das Verständnis für die
Aufgaben des Anwenders – also jener Arbeiten, die der Rechner automatisieren und unterstützen soll. Gründe dafür können die Spezialisierung der Anwendung sein, oder, was öfter der
Fall ist, die Datenorientierung des Designs. Bei der Analyse stehen oft folgende Fragen im Vordergrund:
■ Welche Daten werden erfasst?
■ Wie sind die Daten zu verarbeiten?
■ Wie sollen die Daten dargestellt bzw. ausgegeben werden?
Diese Fragestellungen ziehen eine Reihe weiterer Fragen nach sich, wozu Dinge wie Eingabeformulare und Codes, das Bildschirmlayout, Berechnungen, Korrekturen, Audit Trails, Speichervolumen, Verarbeitungszyklen, Verteilung und Wartung gehören. Alle angesprochenen
Elemente sind äußerst wichtige Bereiche. Die Schwierigkeit ist, dass sie sich ausschließlich auf
die Daten konzentrieren.
Die Mitarbeiter nutzen zwar Daten, erfüllen aber in erster Linie Aufgaben. Man könnte an dieser Stelle einwenden, dass dieses Argument für den normalen Angestellten, aber nicht für jene
Mitarbeiter gilt, die nur Daten von einem Formular ablesen und in den Rechner eingeben: de-
4.10
Gutes Design hat eine menschliche Seite
ren Aufgabe ist sehr datenorientiert. Diese Darstellung entspricht durchaus der Realität. Aber
ist dies eine Konsequenz der Arbeit, die tatsächlich auszuführen ist, oder ein Symptom für das
Design der Computeranwendungen? Menschen als Eingabegeräte zu benutzen, insbesondere
wenn es sich um umfangreiche Datenmengen handelt, die formatiert sind und nur wenige Varianten aufweisen (wie bei Formularen), ist teuer und überholt – und eine entwürdigende
Form der Datengewinnung.
Das mag philosophisch und idealistisch klingen, hat aber konkrete Auswirkungen auf das Anwendungsdesign. Menschen nutzen Daten, erledigen aber Aufgaben. Und die Aufgaben werden meistens nicht vollständig und auf einmal erledigt. Die Mitarbeiter erledigen gleichzeitig
verschiedene Aufgaben, die alle parallel ausgeführt werden.
Lassen sich Designer beim Analysieren und Programmieren einer Anwendung von dieser Idee
leiten, ändert sich auch die Zielsetzung signifikant. Warum waren die windowsbasierten Umgebungen so erfolgreich? Weil sie es dem Anwender ermöglichen, schnell zwischen den Aufgaben hin und her zu springen, wobei die verschiedenen Anwendungen immer aktiv sind –
und weil vor dem Start eines neuen Programms kein anderes beendet werden muss. Die windowsbasierte Umgebung kommt damit dem tatsächlichen Denken und Handeln der Menschen sehr viel näher als alle bisherigen Ansätze. Diese Lektion sollte nicht in Vergessenheit geraten, sondern Grundlage für alle weiteren Überlegungen sein.
Das Verständnis der Aufgaben, die von Anwendungen zu erledigen sind, geht weit über das
Identifizieren und Normalisieren der Datenelemente, den Aufbau von Bildschirmen, Programmen und Reports hinaus. Es bedeutet, dass man tatsächlich weiß, was der Anwender
macht und wie seine Aufgaben aussehen. Infolgedessen sollte sich die Anwendung an diesen
Anforderungen orientieren, und nicht nur die damit verbundenen Daten entgegennehmen.
Orientiert man sich nur an den Daten, unterstützt das daraus resultierende Design nicht unbedingt die Aufgaben des Anwenders, sondern führt eher zu einer Verzerrung der Aufgabe.
Wie entwirft man eine Anwendung, die sich eher an den Aufgaben als an den Daten orientiert?
Die größte Hürde ist, die Notwendigkeit dieser Neuorientierung zu akzeptieren. Doch dann
können Sie die Analyse des Unternehmens aus einer neuen Perspektive angehen.
Der erste Schritt im Analyseprozess ist, die eigentliche Aufgabe zu verstehen. Was machen die
Leute in dieser Gruppe eigentlich? Welches Produkt oder welchen Service bieten sie an? Das
mag wie eine grundsätzliche oder vereinfachte Fragestellung aussehen, doch Sie wären sicher
überrascht, wie viele Geschäftsleute mit der Beantwortung dieser Frage Probleme haben. Erstaunlich viele Firmen, vom Gesundheitswesen über Banken, das Transportwesen bis hin zu
Produzenten nahmen an, sie seien im Datenverarbeitungsgeschäft. Denn im Prinzip geben sie
Daten ein, verarbeiteten sie und stellen über diese Daten Berichte zusammen. Diese Vorstellung ist nur ein weiteres Symptom für die Datenorientierung, die unser Systemdesign in der
Vergangenheit prägte, und dazu führte, dass viele Firmen versuchten, ihr vermeintlich „reales“
Produkt, die Datenverarbeitung, zu vermarkten, was für etliche Unternehmen in einer Katastrophe endete.
Deshalb ist es wichtig, mit einer gewissen Naivität und Skepsis an Geschäftsanwendungen heranzugehen: Sie werden oft falsche Vorstellungen über das angebliche Geschäftsziel über den
Haufen werfen müssen, um herausfinden zu können, worin es tatsächlich besteht. Das ist ein
heilsamer, aber manchmal auch schwieriger Prozess.
55
56
4
Oracle-Applikationen planen – Konzepte, Risiken und Standards
Es ist genauso wichtig, dass sich Geschäftsleute zu SQL-Anwendern entwickeln und die Grundlagen des relationalen Modells verstehen, wie dass Servicedesigner begreifen, welche Aufgaben
zur Bereitstellung eines bestimmten Dienstes oder Produkts wirklich notwendig sind. Erst ein
Projektteam, in dem Anwender mit erworbenen Kenntnissen über SQL und das relationale Modell – beispielsweise durch Lektüre dieses Buchs – mit den Designern zusammenarbeiten, die die
Anforderungen der Anwender berücksichtigen und den Wert einer aufgaben- und sprachorientierten Umgebung kennen, kann außerordentlich gut funktionierende Systeme aufbauen.
Ein Ansatz in diesem Prozess besteht darin, zwei konvergierende Dokumente zu erstellen: eines für die Aufgaben und eines für die Daten. Beim Ausarbeiten des Aufgabendokuments wird
gleichzeitig das notwendige Wissen für die Anwendung erarbeitet. Das Datendokument hilft
bei der Implementierung und stellt sicher, dass gewisse Details und Regeln berücksichtigt werden. Das Aufgabendokument skizziert in erster Linie, wie die eigentliche Aufgabe aussieht.
4.10.2 Skizzieren von Aufgaben
Das Aufgabendokument ist von Anwendern und Applikationsdesignern gemeinsam zu erstellen. In diesem Papier werden die Aufgaben von oben nach unten aufgeführt. Das beginnt mit
der grundsätzlichen Beschreibung des Unternehmensziels. Diese Aussage sollte aus einem einfachen Aussagesatz von drei bis zehn Wörtern bestehen, im Aktiv formuliert sein, ohne Kommas und mit einem Minimum an Adjektiven:
„Wir verkaufen Versicherungen.“
Unglücklich ist hingegen folgende Variante:
„Amalgamated Diversified ist ein führender internationaler Anbieter von Finanzierungen,
Anwendertrainings, Informationsverarbeitung, Kommunikation und Consultingleistungen
in den verschiedenen Bereichen des Gesundheitswesens und diversen anderen Branchen.“
Die Versuchung mag groß sein, jedes kleine Detail hervorzuheben und in diesen ersten Satz
auch noch seine Träume zu projizieren. Lassen Sie das. Das Reduzieren von deskriptiven Exzessen auf einen einfachen Satz hat eine befreiende Wirkung. Wenn Sie die Aufgabe Ihres Unternehmens nicht mit zehn einfachen Wörtern beschreiben können, haben Sie die Kernaufgabe noch nicht verstanden.
Aber als Anwendungsdesigner ist es nicht allein Ihre Aufgabe, diesen Satz zu formulieren. Das
sollte gemeinsam mit den Endanwendern geschehen, und ist der erste Schritt in Richtung Dokumentation. Dieser Prozess gibt Ihnen die Möglichkeit darüber nachzudenken, was die Firma macht und wie diese Aufgabe ausgeführt wird. Dieser Prozess ist auch für die Firma selbst
sehr hilfreich, und zwar unabhängig davon, ob eine Anwendung erstellt werden soll. Sie werden auf viele Aufgaben, Teilaufgaben, Prozeduren und Regeln kommen, die sich entweder als
bedeutungslos herausstellen oder nur selten gebraucht werden. Bei diesen Artefakten handelt
es sich in der Regel um Problemlösungen aus der Vergangenheit oder um Informationen für
Manager, die schon lange nicht mehr zum Unternehmen gehören.
Witzbolde haben vorgeschlagen, einfach keine Berichte mehr zu verfassen und zu warten, ob
es überhaupt jemanden auffällt. Das sollte man aber nur als humorvolle Anekdote betrachten,
da Berichte tatsächlich ein wichtiger Bestandteil des Dokumentationsprozesses sind.
4.10
Gutes Design hat eine menschliche Seite
Bitten Sie den Anwender, seine Aufgabe ausführlich zu beschreiben und für jeden Schritt eine
Begründung abzugeben. Ist die Argumentation schwach, wie etwa „So haben wir es schon immer gemacht“, oder „Ich glaube, das braucht man noch woanders“, sollten bei Ihnen die Signallampen angehen. Sagen Sie einfach, Sie hätten die Ausführungen nicht verstanden und bitten Sie erneut um eine Erklärung. Sollte die Antwort auch in diesem Fall unbefriedigend sein,
schreiben Sie die Aufgabe und Ihre Fragen auf eine separate Liste. Einige dieser Fragen können
Leute beantworten, die sich in der Materie besser auskennen, andere Fragen müssen mit den
Vorgesetzten besprochen werden, und manche Aufgaben werden sich als völlig überflüssig herausstellen. Ein Vorteil eines guten Analyseprozesses ist die Verbesserung von bestehenden Prozeduren, unabhängig von der Implementierung einer neuen Computeranwendung.
Das allgemeine Format des Aufgabendokuments
Das Dokument mit den Aufgaben sollte üblicherweise wie folgt aussehen:
■ Ein zusammenfassender Satz mit der Beschreibung des Firmenzwecks (in drei bis zehn
Wörtern)
■ Ein zusammenfassender Satz, der die Anzahl der wichtigsten Aufgaben beschreibt (kurze
Sätze, wenig Wörter)
■ Zusätzliche Ebenen zum Detaillieren der wichtigsten Aufgaben (falls notwendig)
Normalerweise folgt dem zusammenfassenden Satz auf der jeweiligen Ebene ein beschreibender Absatz, der kurz und präzise zu formulieren ist. Wichtige Aufgaben nummeriert man üblicherweise mit 1.0, 2.0 etc., und werden deshalb auch als Aufgaben der Nullebene bezeichnet.
Darunter liegende Aufgaben werden als Unterpunkte markiert, wie 3.1. oder 3.1.14. Jede übergeordnete Aufgabe wird bis zur Ebene der atomischen Aufgaben aufgelöst – Aufgaben, für die es
keine weitere Untergliederung gibt, und die sich entweder vollständig ausführen lassen oder
komplett gelöscht werden. Atomische Aufgaben bleiben nie halb erledigt.
Das Schreiben eines Schecks ist eine atomische Aufgabe, das Ausfüllen der Eurosumme hingegen nicht. Telefonischer Kundendienst zu Repräsentationszwecken ist keine atomische Aufgabe, das Beantworten des Anrufs und die Ausführung einer Kundenanfrage hingegen ist atomisch. Atomische Aufgaben müssen sinnvoll und in sich geschlossen sein.
Die Ebene, ab der eine Aufgabe atomisch ist, lässt sich vorab festlegen. Wichtig ist nicht die
Nummerierung (die nur die Hierarchie der Aufgaben widerspiegelt), sondern die Auflösung
auf der atomischen Ebene. Die atomischen Aufgaben sind die grundlegenden Bausteine des
Geschäfts. Zwei Aufgaben können auch dann atomisch sein, wenn eine zufällig von der anderen abhängig ist. Das gilt allerdings nur dann, wenn sich beide Aufgaben unabhängig voneinander erledigen lassen. Hängen zwei Aufgaben voneinander ab, sind sie nicht atomisch – die
tatsächliche atomische Aufgabe besteht dann aus beiden.
Sie werden schnell feststellen, dass sich viele Aufgaben nicht so einfach in eine der wichtigen
Kategorien einordnen lassen, sondern mehrere Aufgaben der Ebene Null umfassen und so ein
„Netzwerk“ bilden. Diese Situation resultiert fast immer aus einer unsauberen Definition der
wichtigen Aufgaben, oder einer ungenügenden Atomisierung auf den unteren Ebenen. Das
Ziel ist, jede Aufgabe in ein konzeptionelles „Objekt“ umzuwandeln, mit einer genau definierten Vorstellung dessen, was es tun soll (dem Ziel), und welche Ressourcen (Daten, Berechnungen, Materialien etc.) es für die Ausführung benötigt.
57
58
4
Oracle-Applikationen planen – Konzepte, Risiken und Standards
Einsichten aus dem Aufgabendokument
Aus dem Aufgabendokument ergeben sich verschiedene Konsequenzen. Erstens, da sich das
Dokument weniger an den Daten als an den Aufgaben orientiert, wird sich wahrscheinlich der
Aufbau der Anwenderbildschirme wesentlich verändern. Die Ergebnisse dieses Dokuments
beeinflussen die Art und Weise, wie die Daten erfasst und dargestellt werden, wie die Hilfe implementiert ist, und wie die Benutzer von einer Anwendung zur anderen wechseln können.
Die Aufgabenorientierung stellt sicher, dass für die üblichen Sprünge zwischen den Anwendungen vonseiten des Benutzers keine besonderen Aktionen notwendig sind.
Zweitens kann die Kategorisierung der wichtigsten Aufgaben nach dem Aufdecken von Konflikten geändert werden. Dies hat wiederum Einfluss darauf, wie die Designer und die Benutzer die Geschäftsabläufe verstehen.
Drittens kann sich vielleicht sogar der Kernsatz des Dokuments ändern. Das Aufbereiten eines
Unternehmens und dessen Zerlegung in kleine, atomare Aufgaben-„Objekte“ führt zum Aussondern von Artefakten, falschen Konzeptionen und nutzlosen Abhängigkeiten, die das Unternehmen lange Zeit unnötig belastet haben.
Das ist kein ganz schmerzloser Prozess, allerdings werden die Vorteile hinsichtlich des Selbstverständnisses des Unternehmens und der Automatisierung der Aufgaben üblicherweise überwiegen.
4.11
Die Daten
Im Zusammenhang mit der Zerlegung und Beschreibung der Aufgaben werden im Aufgabendokument die notwendigen Ressourcen beschrieben, insbesondere hinsichtlich der benötigten
Daten. Das geschieht für jede einzelne Aufgabe, und die benötigten Daten werden danach in
das Datendokument aufgenommen. Dieser Ansatz unterscheidet sich konzeptionell von der
klassischen Betrachtung der Daten. Denn Sie stellen nicht einfach die aktuell genutzten Bildschirme und Formulare der einzelnen Aufgaben zusammen, und führen die dort enthaltenen
Elemente auf. Der Fehler dieses Ansatzes liegt in unserer Tendenz – auch wenn wir das nicht
gerne zugeben – alles Geschriebene und Gedruckte als wichtig oder wahr zu akzeptieren.
Bei den einzelnen Aufgaben sollten Sie sich stets die Frage stellen, welche Daten zur Ausführung der entsprechenden Aufgabe wirklich notwendig sind, und weniger darauf achten, welche Datenelemente in einem Formular für eine Aufgabe benötigt werden. Wenn man verlangt,
dass die Definition der notwendigen Daten von der Aufgabe und nicht so sehr von bestehenden Formularen oder Bildschirmen abgeleitet wird, erzwingt das eine Überprüfung des eigentlichen Zwecks der Aufgabe und der tatsächlichen Anforderungen bezüglich der Daten. Wenn
die Person, die die Aufgabe ausführt, den Zweck der verwendeten Daten nicht kennt, wird das
Element auf die Liste mit den klärungsbedürftigen Dingen gesetzt. Im Laufe dieses Prozesses
entledigt man sich so einer Menge überfälliger Daten.
Wurden die Datenelemente identifiziert, müssen sie sorgfältig untersucht werden. Numerische und Buchstabencodes sind grundsätzlich suspekt. Sie verstecken die tatsächlichen Informationen hinter wenig intuitiven und bedeutungslosen Symbolen. Es gab Zeiten, in denen die
Codes einfach und kurz sein mussten, oder wegen des Datenvolumens notwendig waren. Aber
in Ihrem endgültigen Design sollten solche Fälle selten und offensichtlich sein. Ist das nicht der
Fall, haben Sie Ihr eigentliches Ziel verfehlt.
4.11
Die Daten
Bei der Untersuchung der bestehenden Datenelemente sollte den Codes besondere Beachtung
geschenkt und ihre Notwendigkeit jeweils hinterfragt werden. Für die weitere Verwendung eines Codes muss es gute und einleuchtende Gründe geben. Die Umwandlung des Codes in die
normale Sprache ist zwar relativ einfach, bedarf allerdings der Mitwirkung aller Beteiligten. Die
Codes werden zunächst nach Datenelementen sortiert und mit der entsprechenden Bedeutung
in eine Liste aufgenommen. Diese Liste wird von den Anwendern und Designern unter die Lupe
genommen, und unterschiedliche Vorschläge für die Umbenennung können diskutiert und abgewogen werden.
Im Zuge dieser Diskussion sollten sich Designer und Anwender auf die Namen der Datenelemente einigen. Da diese Elemente in der Datenbank zu Spaltennamen werden und auch in den
Abfragen regelmäßig zum Einsatz kommen, sollten die Namen beschreibend sein (ungewöhnliche Abkürzungen sind nach Möglichkeit zu vermeiden) und im Singular stehen. Aufgrund
der engen Beziehung zwischen den Spaltennamen und den dort enthaltenen Daten sollten beide gleichzeitig definiert werden. Die sorgfältige Auswahl eines Spaltennamens erleichtert das
Erkennen der neuen Inhalte.
Alle Datenelemente, die keine Codes sind, sind genau zu analysieren. Bis zu diesem Punkt haben Sie gute Gründe anzunehmen, dass alle identifizierten Datenelemente für die Aufgaben
wichtig sind, wobei die Daten nicht unbedingt gut organisiert sein müssen. Tatsächlich können in den bestehenden Programmen verschiedene Elemente vermischt sein, woraus sich die
Notwendigkeit für die Zerlegung der Elemente ergeben kann. Namen, Adressen und Telefonnummern sind gängige Beispiele, wobei jede Anwendung ihre Besonderheit hat.
So sind beispielsweise in der AUTHOR-Tabelle die Vor- und Nachnamen miteinander vermischt. Beachten Sie, dass die AuthorName-Spalte beide Werte enthält, obwohl sich die Daten
in der dritten Normalform befinden. Das kann bei der Implementierung einer Anwendung
Probleme aufwerfen, obwohl technisch gesehen die Regeln für die Normalisierung erfüllt sind.
Um die Anwendung möglichst praktisch zu gestalten und für sprachbasierte Abfragen vorzubereiten, sollte die Name-Spalte in zwei neue Kategorien zerlegt werden: LastName und FirstName. Derselbe Kategorisierungsprozess wird bei der Rationalisierung anderer Datenelemente nötig, und ist oft unabhängig von der Normalisierung der Daten.
Der Grad der Zerlegung hängt auch von der Nutzung eines speziellen Datenelements ab. Es ist
durchaus möglich, dass man dabei zu weit geht und Kategorien weiter aufteilt, obwohl die
neuen Elemente in diesem Status eigentlich keinen zusätzlichen Nutzen haben. Die Zerlegung
der Daten hängt von der jeweiligen Anwendung ab und ist für jedes Element durchzuführen.
Danach muss man die neuen Elemente, die in der Datenbank zu Spalten werden, sinnvoll benennen und die in den Spalten vorhandenen Daten untersuchen. Textdaten, die sich in eine
definierbare Anzahl von Werten aufteilen lassen, sollte man hinsichtlich der Benennung überprüfen. Diese Spaltennamen und -werte sind, wie die für Codes, unverbindlich und vorläufig.
4.11.1 Die atomischen Datenmodelle
Jetzt beginnt der Normalisierungsprozess und der Aufbau des atomischen Datenmodells. Da es
zu diesem Thema eine Reihe ausgezeichneter Bücher und verschiedene Analyse- und Designtools gibt, möchten wir keine besondere Methode empfehlen.
Jede atomische Transaktion sollte modelliert und mit den entsprechenden Aufgabennummern versehen werden. In dem Modell werden auch die Tabellennamen, die Primär- und
59
60
4
Oracle-Applikationen planen – Konzepte, Risiken und Standards
Fremdschlüssel sowie die wichtigsten Spalten aufgeführt. Jede normalisierte Beziehung (d. h.
jede Verbindungslinie) sollte einen aussagefähigen Namen erhalten. Darüber hinaus sollten
für jede Tabelle die geschätzte Zeilenzahl und die Transaktionsraten aufgeführt sein. Zu jedem
Modell gehört eine zusätzliche Seite, in der alle Spalten und Datentypen, deren Wertebereiche,
und die Namen der Tabellen, Spalten sowie die benannten Werte in den Spalten auftauchen.
4.11.2 Das atomische Geschäftsmodell
Dieses Datendokument wird jetzt mit dem Aufgabendokument zusammengeführt. Das kombinierte Dokument ist das Unternehmens- oder Geschäftsmodell, und wird von den Anwendungsdesignern und den Anwendern auf Vollständigkeit und Richtigkeit durchgesehen.
4.11.3 Das Unternehmensmodell
An diesem Punkt sollten sowohl Anwendungsdesigner als auch Endanwender eine klare Vorstellung vom Unternehmen, seinen Aufgaben und Daten besitzen. Nach der Korrektur und
Verabschiedung des Modells beginnt der Prozess der Synthetisierung von Aufgaben- und Datenmodellen in ein übergreifendes Unternehmensmodell. Bei diesem Prozess werden die üblichen Datenelemente zwischen den Aufgaben sortiert, die Normalisierung wird im großen
Maßstab durchgeführt, und für alle Elemente werden konsistente und definitive Namen vergeben.
Bei großen Anwendungen kann das durchaus eine umfangreiche Zeichnung werden. Dazu
kommen noch die Dokumentationen mit den Aufgaben, den Datenmodellen (mit den korrekten Elementnamen, Datentypen und Inhalten) und für jede Tabelle eine Liste mit den Spaltennamen, Datentypen und den jeweiligen Inhalten. Eine letzte Prüfung gilt den Zugriffspfaden
auf die Daten im vollständigen Unternehmensmodell. So kann man feststellen, ob die für die
Transaktionen benötigten Daten (zur Selektion oder für Einfügeoperationen) tatsächlich zur
Verfügung stehen. Damit wird sichergestellt, dass bei keinem Prozess Daten fehlen, die für die
referenzielle Integrität des Modells unabdingbar sind.
Mit Ausnahme der Namensfindung für die verschiedenen Tabellen, Spalten und die üblichen
Werte fielen alle bisher ausgeführten Arbeiten in den Bereich der Analyse, nicht des Designs.
Die Absicht war, das Verständnis für das Geschäftsmodell und seine verschiedenen Komponenten zu fördern.
4.11.4 Dateneingabe
Das Bildschirmdesign wird nicht vom Unternehmensmodell abgeleitet, da es sich nicht auf die
Tabellen, sondern auf die Aufgaben konzentriert. Deshalb werden die Bildschirme so angelegt,
dass sie die Aufgabenorientierung unterstützten und das Wechseln zwischen den Teilaufgaben
ermöglichen. Praktisch gesehen ist das oftmals mit der Zuordnung zu Tabellen verbunden, die
sich entweder auf Werte abfragen lassen oder beim Zugriff auf die Primärtabelle aktualisiert
werden.
Es kann aber auch vorkommen, dass keine Haupttabelle vorhanden ist, und es stattdessen eine
Vielzahl von zusammengehörigen Tabellen gibt, die zur Unterstützung der Aufgabe entweder
Daten zur Verfügung stellen oder empfangen. Diese Bildschirme sehen ein wenig anders aus,
4.11
Die Daten
und ihr Verhalten weicht auch von den typischen tabellenorientierten Bildschirmen ab, die für
die meisten Anwendungen programmiert werden. Dennoch verbessern sie die Effektivität der
Benutzer ganz erheblich und erhöhen damit den Beitrag zum Unternehmenserfolg, was auch
Sinn und Zweck dieses Ansatzes ist.
Die Interaktion des Benutzers mit der Maschine ist wichtig: Die Eingabe- und Abfragebildschirme sollten konsequent aufgabenorientiert und selbsterklärend sein. Die Verwendung von
Symbolen und grafischen Schnittstellen spielt natürlich auch eine wichtige Rolle. Die Bildschirme müssen wiedergeben, wie die Arbeit tatsächlich erledigt wird, und in der branchenüblichen Sprache bzw. Terminologie gehalten sein.
4.11.5 Abfragen und Reports
Wenn es etwas gibt, das den relationalen Ansatz konsequent umsetzt, so ist es SQL. Diese Sprache ist leicht erlernbar und ermöglicht dem Endanwender das Erstellen und Ausführen von Ad
hoc-Abfragen. Diese Abfragen gehören üblicherweise nicht zu den Standardabfragen, die zusammen mit dem Anwendungscode zur Verfügung gestellt werden.
Mit SQL*Plus (und anderen Reporting-Tools) erhalten die Anwender eine beispiellose Kontrolle über ihre Daten. Davon profitieren sowohl Entwickler als auch Anwender: Die Benutzer,
weil sie Reports erstellen, Daten analysieren, die Abfragen verändern und innerhalb weniger
Minuten erneut ausführen können. Und die Entwickler, weil sie nicht dauernd mit irgendwelchen Anforderungen für neue Reports behelligt werden.
Die Benutzer erhalten das Recht, ihre Daten anzusehen, zu analysieren und in einer Geschwindigkeit und Genauigkeit zu antworten, die vor einigen Jahren noch unvorstellbar war. Diese
Produktivitätssteigerung lässt sich noch verbessern, wenn die Tabellen, Spalten und Datenwerte in der jeweiligen Landessprache vorliegen; denn werden die Benennungskonventionen
nicht eingehalten, und verwässern bedeutungslose Codes und Abkürzungen das Design, führt
das zu einer geringeren Produktivität. Die Zeit, die man in das Design und die konsistente und
beschreibende Benennung der Objekte investiert, zahlt sich in kurzer Zeit für die Benutzer,
und damit auch für das Unternehmen aus.
Manche Leute befürchten, dass das Überantworten der Abfragewerkzeuge an den Endanwender die Rechner negativ beeinträchtigen könnte, auf denen diese Werkzeuge laufen. Sie befürchten, dass Benutzer ineffiziente Abfragen erstellen, die zu viele CPU-Zyklen benötigen
und damit unnötig Ressourcen vergeuden, was zu einer Verlängerung der Antwortzeiten für
alle Benutzer führt. Die Erfahrung zeigt, dass diese Aussage im Normalfall nicht richtig ist. Die
Benutzer wissen bald, welche Abfragen schnell laufen und welche nicht. Außerdem lassen sich
mithilfe der heute verfügbaren Werkzeuge die Abfragezeiten abschätzen, und der Zugang für
große Abfragen kann (nach Benutzer, Tageszeit oder beidem) eingeschränkt werden. Das wiederum bringt die Anwender dazu, sich die notwendigen Qualifikationen anzueignen, und die
Abfragen so schnell und effizient wie möglich zu gestalten. Mit diesen Qualifikationen verringert sich auch die Belastung der Maschinen. Verschieben Sie eine Belastung vom Menschen
auf die Maschine, sparen Sie praktisch immer Geld.
Das eigentliche Ziel des Designs ist, die Anforderungen an das Geschäft und die Anwender zu
klären und zufriedenzustellen. Den Vorzug sollten stets die Dinge bekommen, die die Anwendung verständlicher und besser handhabbar machen. Das kann zulasten von CPU oder Plattenplatz gehen, was sich aber auszahlt. Kontraproduktiv ist, wenn sich dadurch die interne
61
62
4
Oracle-Applikationen planen – Konzepte, Risiken und Standards
Komplexität so erhöht, dass sich Wartungsarbeiten und Änderungen nur schwierig und langsam ausführen lassen.
4.12
Das Normalisieren von Objektnamen
Bei der Benennung von Objekten geht es darum, aussagefähige, leicht verständliche und beschreibende Namen zu finden, Abkürzungen zu vermeiden und die Unterstriche konsistent
oder überhaupt nicht zu verwenden. In einer großen Anwendung bestehen die Namen von
Tabellen, Spalten und Daten oft aus mehreren Wörtern (wie ReversedSuspenseAccount oder
Last_GL_Close_Date). Das Ziel dieser Benennungsmethode ist die einfache Handhabung der
Daten: Die Namen müssen gut zu merken sein und Regeln folgen, die man leicht verstehen
und anwenden kann. Auf den folgenden Seiten wird ein eher rigoroser Ansatz vorgestellt, der
der Entwicklung eines formalen Prozesses zur Normalisierung von Objektnamen dienen soll.
4.12.1 Die ebenenbezogene Namensintegrität
In einem relationalen Datenbanksystem reicht die Hierarchie von der Datenbank über die Tabelleneigentümer bis hin zu Tabellen, Spalten und Datenwerten. In sehr großen Systemen
können auch mehrere Datenbanken vorhanden und auf verschiedene Standorte verteilt sein.
Um die Darstellung möglichst kurz zu halten, werden die oberen Ebenen hier ignoriert, aber
die Ausführungen gelten für diese Elemente ebenfalls.
In dieser Hierarchie ist jede Ebene in der darüber liegenden Ebene definiert, und auf jeder Ebene sollten nur ebenenspezifisch gültige Namen vergeben werden, d. h. keine Namen aus anderen Ebenen aufgenommen werden. Beispielsweise darf eine Tabelle keinesfalls zwei Spalten
namens „Name“ enthalten, und der Account namens George kann nicht zwei Tabellen namens AUTHOR besitzen.
Es gibt keine Anforderung, die besagt, dass die Namen von Georges Tabellen innerhalb der
gesamten Datenbank eindeutig sein müssen. Auch andere Eigentümer können eine AUTHOR-Tabelle besitzen. Selbst wenn George auf diese Tabellen innerhalb der gesamten Datenbank eindeutig sein müssen. Auch andere Eigentümer können eine AUTHOR-Tabelle
besitzen. Selbst wenn George auf diese Tabellen zugreifen darf, gibt es kein Durcheinander,
da sich die Tabellen über den Eigentümer immer eindeutig identifizieren lassen. Wenn George seine WORKER-Tabelle mit der von Dietrich kombiniert, muss die Name-Spalte in der select-Klausel die vollständige Kennung enthalten: Dietrich.AUTHOR.Name. Es wäre logisch
inkonsistent, wenn man Georges Namen in die Namen seiner Tabellen einbinden würde (wie
GEOAUTHOR, GEO-BOOKSHELF usw.). Damit werden die Namen nur unnötig komplex
und führen letztlich zu einer Verletzung der ebenenbezogenen Namensintegrität.
Die Kürze sollte niemals den Vorzug vor der Übersichtlichkeit erhalten. Die Einbindung von
Teilen der Tabellen- in die Spaltennamen ist insofern eine schlechte Technik, als man damit
die logische Idee der Ebenen und die damit verbundene ebenenbezogene Namensintegrität
verletzt. Darüber hinaus sind solche Konstruktionen unklar und führen dazu, dass man bei
fast jeder Abfrage die Spaltennamen überprüfen muss. Die Objektnamen müssen eindeutig
sein, wobei peinlich darauf zu achten ist, dass man für das Objekt ausschließlich die Namen
der entsprechenden Ebene einsetzt.
4.12
Das Normalisieren von Objektnamen
Die Unterstützung für abstrakte Datentypen stärkt Ihre Möglichkeiten zur Vergabe von konsistenten Attributnamen. Legen Sie beispielsweise einen Datentyp namens ADDRESS_TY an,
hat er bei jeder Nutzung die gleichen Attribute. Jedes Attribut hat einen konsistenten Namen,
Datentyp und Länge, was die Implementierung im gesamten Unternehmen konsistent macht.
Der Einsatz von abstrakten Datentypen erfordert Folgendes:
■ Definieren Sie die Datentypen von Anfang an korrekt. Damit vermeiden Sie, die Datentypen später nochmals ändern zu müssen.
■ Unterstützen Sie die Syntaxanforderungen der abstrakten Datentypen.
4.12.2 Fremdschlüssel
Ein Problem bei diesem Ansatz ist das gelegentliche Auftreten eines Fremdschlüssels in einer
Tabelle, in der eine andere Spalte denselben Namen wie die Fremdschlüsselspalte in der Ursprungstabelle besitzt. Eine mögliche Lösung besteht darin, dass bei der Benennung der
Fremdschlüssel, einschließlich des Tabellennamens in der Ursprungstabelle, als Spaltenname
in der lokalen Tabelle mit aufgenommen wird (wie BOOKSHELF.Title als Spaltenname).
Die praktischen Anforderungen zur Lösung von Problemen im Zusammenhang mit gleich benannten Spalten erfordern eine der folgenden Aktionen:
■ Wählen Sie einen Namen, bei dem der Fremdschlüssel der Ursprungstabelle ohne den
Punkt eingebunden wird (verwenden Sie beispielsweise einen Unterstrich).
■ Wählen Sie einen Namen, der eine Abkürzung der Ursprungstabelle des Fremdschlüssels
enthält.
■ Wählen Sie einen Namen, der von dem in der Ursprungstabelle abweicht.
■ Ändern Sie die Namen der Spalten, bei denen solche Konflikte auftreten.
Keiner dieser Vorschläge ist besonders attraktiv. Wenn Sie aber Probleme mit gleichen Namen
vermeiden möchten, müssen Sie sich für eine der vorgestellten Aktionen entscheiden.
4.12.3 Singularität
Ein Bereich, in dem es immer wieder zu Inkonsistenzen kommt, betrifft die Frage, ob die Objektnamen in der Einzahl oder der Mehrzahl gehalten werden sollen. Soll die Tabelle AUTHOR oder AUTHORS, die Spalte Name oder Names heißen?
Zu diesem Problem gibt es zwei hilfreiche Vorgehensweisen. Sehen Sie sich zuerst einige Spalten an, die in beinahe jeder Datenbank vorkommen: Name, Adresse, Stadt, Land und Postleitzahl. Käme es jemandem, außer bei der ersten Spalte, in den Sinn, die Namen in die Mehrzahl
zu setzen? Es ist offensichtlich, dass diese Namen den Inhalt einer einzelnen Zeile, d. h. eines
Datensatzes beschreiben. Obwohl die relationalen Datenbanken „mengenorientiert“ sind, ist
die grundlegende Einheit einer Menge ein Datensatz, und die Inhalte dieses Datensatzes werden über Spaltennamen beschrieben, die in der Einzahl gehalten sind. Soll ein Bildschirm, an
dem die Adresse einer Person eingetragen wird, wie folgt aussehen?
63
64
4
Oracle-Applikationen planen – Konzepte, Risiken und Standards
Namen: _______________________________________________________
Adressen: ___________________________________________________
Städte: ____________________________ Länder __ PLZ _____-____
Oder halten Sie die Namen dieser Spalten am Bildschirm im Singular, weil Sie jedes Mal nur
einen Namen und eine Adresse eingeben, aber dem Benutzer wird mitgeteilt, dass die Spaltennamen bei Abfragen im Plural verwendet werden müssen? Deshalb ist es einfacher und intuitiver, sich bei der Vergabe der Spaltennamen auf den Singular zu beschränken.
Werden alle Objekte konsistent benannt, gibt es für die Benutzer keinen Grund, darüber nachzudenken, ob der jeweilige Name im Singular oder im Plural steht. Der Vorteil dieses Ansatzes
ist einfach und überzeugend. Angenommen, wir möchten alle Objekte zukünftig im Plural
halten, und damit steht am Ende jedes Objektnamens ein „s“, „e“ oder „en“. Welchen Vorteil
bringen diese zusätzlichen Buchstaben am Ende eines Worts? Sind die Namen einfacher zu
handhaben, leichter zu verstehen oder leichter zu merken? Wohl kaum.
Deshalb sieht die beste Lösung wie folgt aus: Alle Objektnamen stehen immer im Singular. Die
einzige Ausnahme von dieser Regel bilden Begriffe, die im täglichen Sprachgebrauch im Plural
verwendet werden.
4.12.4 In der Kürze ...
Wie bereits erwähnt, sollte die Übersichtlichkeit nicht der Kürze geopfert werden. Wenn aber
zwei gleich aussagefähige, leicht zu merkende und beschreibende Namen zur Auswahl stehen,
sollten Sie stets den kürzeren wählen. Während der Anwendungsentwicklung sollten Sie nach
Möglichkeit mehrere Namen vorschlagen, diese entweder von einigen Benutzern oder den
Entwicklern bewerten lassen, und aufgrund der gemachten Aussagen den eindeutigsten Namen auswählen. In einem Projektteam, das sich der Entwicklung von produktiven Anwendungen widmet, sollte jeder Mitarbeiter als Grundausstattung einen Thesaurus und ein Wörterbuch erhalten, und immer wieder daran erinnert werden, wie wichtig eine sorgfältige
Benennung der Objekte ist.
4.12.5 Ein Thesaurus für Objektnamen
Eine relationale Datenbank sollte mit der gleichen Selbstverständlichkeit einen Thesaurus für
die Objektnamen besitzen wie ein Data Dictionary. Dieser Thesaurus hilft bei der Durchsetzung der firmeninternen Benennungsstandards und sichert bei den verwendeten Abkürzungen und den ausgewählten Namen die gewünschte Konsistenz.
Solche Standards können die Verwendung von Unterstrichen in Objektnamen verlangen, was
das Zerlegen der Namen in Komponenten wesentlich vereinfacht. Gleichzeitig wird damit ein
Standard für den Einsatz von Unterstrichen erzwungen.
4.13
Intelligente Schlüssel- und Spaltenwerte
Falls Sie direkt mit öffentlichen Auftraggebern oder großen Firmen zusammenarbeiten, haben
diese vielleicht bereits Standards für die Objektbenennung gesetzt. Die Benennungsstandards
großer Unternehmen wurden im Laufe der Zeit Allgemeingut und könnten auch als Grundlage für Ihre Standards dienen. Wenn nicht, entwickeln Sie Ihre eigenen Standards, um mit jenen Basisstandards und den weiteren Richtlinien in diesem Kapitel konsistent zu sein.
4.13
Intelligente Schlüssel- und Spaltenwerte
Intelligente Schlüssel heißen so, weil sie komplexe Kombinationen von Informationen enthalten. Dieser Begriff ist irreführend, weil man damit etwas Positives oder Gehaltvolles verbindet.
Zutreffender wäre der Ausdruck „überladene“ Schlüssel. Produktcodes fallen oftmals in diese
Kategorie und kämpfen mit denselben Schwierigkeiten wie andere Codes. Darüber hinaus lassen sich die Schwierigkeiten, die bei intelligenten oder überladenen Schlüsseln auftreten, auch
bei Nicht-Schlüsselspalten feststellen, bei denen mehr als ein Informationselement hinterlegt
wurde.
Ein typisches Beispiel für einen überladenen Schlüssel ist die folgende Beschreibung: „Das erste Zeichen ist der Code für die Region. Die nächsten vier Zeichen sind die Katalognummer.
Die letzten Zeichen sind der Code für die Kostenstelle. Wenn es sich um ein wichtiges Teil
handelt, befindet sich am Ende der Zahl ein „I“. Falls es sich um einen Artikel mit großen
Stückzahlen (wie Schrauben) handelt, werden nur drei Zahlen für die Katalognummer verwendet, und der Code für die Region ist HD.“
Für ein gutes relationales Design müssen die überladenen Schlüssel und Spaltenwerte eliminiert werden. Die Abhängigkeiten, die auf Teile dieses Schlüssels gesetzt wurden (gewöhnlich
Fremdschlüssel auf andere Tabellen), stellen beim Verwalten der Struktur ein beträchtliches
Risiko dar. Leider gibt es in vielen Anwendungsbereichen überladene Schlüssel, die über Jahre
hinweg verwendet wurden und tief in die Geschäftsaufgaben hineinreichen. Dem sofortigen
Beseitigen der überladenen Schlüssel können manchmal praktische Erwägungen im Wege stehen, und damit gestaltet sich der Aufbau einer neuen, relationalen Anwendung viel schwieriger.
Die Lösung für dieses Problem besteht im Aufbau von neuen Schlüsseln (sowohl Primär- als
auch Fremdschlüsseln), die die Daten korrekt normalisieren. Danach sollten Sie sicherstellen,
dass man nur über diese neuen Schlüssel auf die Tabellen zugreifen kann. Der überladene
Schlüssel wird in einer zusätzlichen, einzelnen Tabellenspalte vorgehalten. Der Zugang ist
dann nur noch mit historischen Methoden möglich (z. B. bei der Suche nach einer Übereinstimmung innerhalb einer Abfrage), wobei die neu strukturierten Schlüssel die bevorzugte Zugriffsmethode darstellen sollten. Unter Umständen können die überladenen Schlüssel (und
andere überladene Spaltenwerte) auch einfach ausgeNULLt oder aus der Tabelle gelöscht werden.
Falls es nicht gelingt, die überladenen Schlüssel und Werte zu eliminieren, kann sich das Extrahieren der Daten aus der Datenbank, das Validieren der Werte, das Sicherstellen der Datenintegrität und ein Modifizieren der Struktur extrem schwierig und kostenintensiv gestalten.
65
66
4
4.14
Oracle-Applikationen planen – Konzepte, Risiken und Standards
Die Empfehlungen
Alle wichtigen Fragen zum produktiven Design wurden nun diskutiert. Am Ende des Kapitels
möchten wir sie nochmals zusammenfassen – in Form von „Empfehlungen“. Das sind zwar
keine direkten Handlungsanweisungen, sie sollen Ihnen aber bei Ihren Überlegungen eine
wichtige Entscheidungshilfe bieten. Auf jeden Fall können Sie von den Erfahrungen anderer
profitieren, die vor ähnlichen Problemen standen. Das Ziel ist an dieser Stelle nicht die Beschreibung des Entwicklungszyklus, sondern eher, jener Entwicklung den Vorzug zu geben,
die das „Look and Feel“ entscheidend verändert, und damit auch den Einsatz. Berücksichtigt
man diese Ideen, lässt sich die Produktivität und Zufriedenheit der Anwender wesentlich verbessern.
Die zehn Empfehlungen für ein benutzerorientiertes Design:
1. Binden Sie die Benutzer ein. Nehmen Sie die Anwender in das Projektteam auf, und vermitteln Sie ihnen das relationale Modell und SQL.
2. Benennen Sie die Tabellen, Spalten und Daten gemeinsam mit den Benutzern. Entwickeln
Sie einen Thesaurus, über den sich die Konsistenz der Namen sicherstellen lässt.
3. Verwenden Sie umgangssprachliche Wörter, die aussagefähig, leicht zu merken, beschreibend, kurz und eindeutig sind. Verwenden Sie Unterstriche entweder konsistent oder
überhaupt nicht.
4. Vermischen Sie beim Benennen nicht die Ebenen.
5. Vermeiden Sie Codes und Abkürzungen.
6. Verwenden Sie nach Möglichkeit aussagefähige Schlüssel.
7. Zerlegen Sie überladene Schlüssel.
8. Bauen Sie die Analyse und das Design auf den Aufgaben auf, und nicht nur auf den Daten.
Denken Sie daran, dass die Normalisierung mit dem Design nichts zu tun hat.
9. Verschieben Sie die Aufgaben vom Benutzer auf die Maschine. Es ist durchaus profitabel,
Rechenzyklen und Speicher zu opfern, wenn damit die Bedienung erleichtert wird.
10. Nehmen Sie sich für Entwicklung, Analyse, Design, Tests und das Tuning die notwendige
Zeit.
Es gibt einen Grund, warum dieses Kapitel den Ausführungen zu den Befehlen und Funktionen vorangestellt wurde – fehlt es am Design, wird Ihre Applikation stets den Anforderungen
hinterherhinken. Planen Sie die Funktionalität, die Performance, die Wiederherstellbarkeit,
die Sicherheit und Verfügbarkeit. Planen Sie den Erfolg!