Oracle Database 11g - Die umfassende Referenz - Hajer ... · PDF fileOracle Database 11g - Die umfassende Referenz von Hans Hajer, Kevin Loney 1. Auflage ... Si e haben die direkte

Oracle Database 11g - Die umfassende Referenz

vonHans Hajer, Kevin Loney

1. Auflage

Oracle Database 11g - Die umfassende Referenz – Hajer / Loney

schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG

Hanser München 2009

Verlag C.H. Beck im Internet:www.beck.de

ISBN 978 3 446 41864 6

Inhaltsverzeichnis: Oracle Database 11g - Die umfassende Referenz – Hajer / Loney

http://www.beck-shop.de/Loney-Oracle-Database-11g-umfassende-Referenz/productview.aspx?product=120677&utm_source=pdf&utm_medium=clickthru_lp&utm_campaign=pdf_120677&campaign=pdf/120677

http://www.beck-shop.de/Loney-Oracle-Database-11g-umfassende-Referenz/productview.aspx?product=120677&utm_source=pdf&utm_medium=clickthru_lp&utm_campaign=pdf_120677&campaign=pdf/120677

http://www.beck-shop.de?utm_source=pdf&utm_medium=clickthru_lp&utm_campaign=pdf_120677&campaign=pdf/120677

http://www.beck.de

http://www.beck-shop.de/fachbuch/inhaltsverzeichnis/9783446418646_TOC_001.pdf

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

44

Oracle-Applikationen planen –Konzepte, Risiken und Standards

Um eine Oracle-Applikation zu erstellen, die sich schnell und effektiv einsetzen lässt, müssenBenutzer und Entwickler dieselbe Sprache sprechen, und sowohl die Geschäftsanwendungenals auch die Oracle-Tools kennen. In den letzen Kapiteln stellten wir Ihnen die Oracle-Pro-dukte und die dazugehörigen Installations-/Upgrade-Schritte vor. Nachdem die Software in-stalliert ist, können Sie Anwendungen entwickeln, in die die gemeinsamen Erfahrungen vonAnwendern und Programmierern einfließen.

Früher studierten die Systemanalytiker die Anforderungen und konzipierten die Applikationentsprechend, um die gestellten Aufgaben zu erfüllen. Der Benutzer wurde nur bei der Be-schreibung 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 Applika-tionen so programmieren, dass sie den Anforderungen und Arbeitsgewohnheiten der Anwen-der sehr viel besser gerecht werden – allerdings nur, wenn die Beteiligten über dieselbenGrundlagen verfügen.

Erklärtes Ziel dieses Buchs ist, genau dieses Wissen aufzubauen, und sowohl Entwicklern alsauch Anwendern alles dazu Notwendige zur Verfügung zu stellen. Denn nur so kann man dievolle Leistungsfähigkeit von Oracle nutzen. Der Endanwender kennt Einzelheiten über Ge-schäftsabläufe, die der Entwickler nicht versteht. Der Entwickler kennt andererseits die inter-nen Funktionen und Leistungsmerkmale von Oracle und der DV-Umgebung, die für den En-danwender zu technisch oder zu komplex sind. Aber dieses spezielle Wissen kannvernachlässigt werden, wenn man die Möglichkeiten betrachtet, die Endanwender und Ent-wickler beim Einsatz von Oracle erzielen können.

Es ist kein Geheimnis, dass zwischen Anwendern und Systemleuten über Jahrzehnte hinwegein gespanntes Verhältnis bestand. Die Gründe dafür resultierten aus der Unterschiedlichkeitvon Kenntnisstand, Kultur, Berufsinteressen und Zielen, und aus einer „Entfremdung“, dieoftmals 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-Be-reichs ist. Dasselbe kann man in jeder Abteilung beobachten, nachdem Gruppen aufgeteiltund in unterschiedlichen Stockwerken, Gebäuden oder Städten untergebracht wurden. In sol-chen Fällen nehmen die Beziehungen zwischen den Mitgliedern der verschiedenen Gruppensehr 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 hatdas eigentlich mit Oracle zu tun?

Da Oracle nicht mit Fachbegriffen agiert, die nur für Systemexperten verständlich sind, verändertOracle auch von Grund auf die Beziehungen zwischen Anwendern und Experten. Jeder kann dasProdukt verstehen. Jeder kann es anwenden. Informationen, die zuvor solange im Computerversteckt waren, bis irgendjemand einen neuen Report schrieb und sie freigab, sind nun fürden Anwender sofort verfügbar – das Eingeben einer einfachen Abfrage genügt. Und das än-dert die Spielregeln.

Überall wo Oracle eingesetzt wird, hat sich das Verhältnis zwischen den oben angesprochenenGruppen entscheidend verbessert. Man lernte einander besser kennen, was zu einer Normali-sierung der Beziehungen beitrug und zu besseren Anwendungen führte.

Seit der ersten Version stützt sich Oracle auf das leicht verständliche relationale Modell, sodassauch Nicht-Programmierer ohne Weiteres verstehen können, was Oracle macht und wie espassiert. Das macht den Umgang mit diesem Programm einfach und unspektakulär.

Manche haben das noch nicht verstanden, akzeptiert oder machen sich nicht klar, wie wichtiges ist, dass die überkommenen und künstlichen Schranken zwischen „Anwendern“ und „Sys-temen“ weiter abgebaut werden. Doch die kooperative Entwicklung wird Anwendungen undihre Nützlichkeit tief greifend beeinflussen.

Allerdings sind viele Entwickler bei Oracle offensichtlich in eine Falle gelaufen: Sie setzten beiihren Systementwürfen weiterhin auf wenig hilfreiche Methoden aus der Vergangenheit. Hiermuss erst viel „verlernt“ werden. Zahlreiche Techniken (und Einschränkungen), die bei älterenSystemgenerationen 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 Gewohn-heiten und Konzepte aufgegeben werden. Stattdessen stehen erfrischend neue Möglichkeitenzur Verfügung.

In diesem Buch versuchen wir, Oracle möglichst einfach zu erklären und Begriffe zu verwen-den, die sowohl Anwender als auch Entwickler verstehen. Veraltete oder unpassende Design-und Managementtechniken werden kurz erläutert und durch neue Ansätze ersetzt.

4.1 Das kooperative KonzeptOracle ist eine objektrelationale Datenbank. Eine relationale Datenbank bietet einen extremeinfachen Weg, über Daten und deren Verwaltung in einem Unternehmen nachzudenken. Eshandelt sich im Prinzip um nichts anderes als eine Ansammlung von Tabellen. Wir haben esjeden Tag mit Tabellen zu tun: Wetterberichte, Aktienkurse, Sportergebnisse. Das alles sindTabellen, die mit einer Tabellenüberschrift und den dazugehörigen Informationsspalten ganzeinfach dargestellt werden. Dennoch kann der relationale Ansatz sehr ausgefeilt und leistungs-

4.2 Jeder besitzt „Daten“ 33

fähig genug sein, um in einem Unternehmen selbst die komplexesten Dinge abzubilden. Eineobjektrelationale Datenbank unterstützt alle Leistungsmerkmale einer relationalen Daten-bank, und gleichzeitig die objektorientierten Konzepte und Funktionen. So können Sie Oracleentweder als relationales Datenbank-Managementsystem (RDBMS) einsetzen oder die Vor-teile der objektorientierten Leistungsmerkmale nutzen.

Leider verstehen genau diejenigen, die von den Vorteilen einer relationalen Datenbank ammeisten profitieren könnten – also die Geschäftsleute – dieses Konzept am wenigsten. Die Ent-wickler haben oftmals Schwierigkeiten, die relationalen Konzepte mit einfachen Worten zu er-klären. Damit dieser kooperative Ansatz tatsächlich funktioniert, benötigt man eine gemein-same Sprache.

Die beiden ersten Teile dieses Buchs erklären mit einfachen Begriffen, was eine relationale Da-tenbank ist und wie man sie in einem Unternehmen effektiv einsetzt. Es könnte der Eindruckentstehen, dass diese Diskussion nur dem „Anwender“ zugutekommt. Und ein erfahrenerEntwickler könnte dazu neigen, diese Kapitel zu überspringen und das Buch in erster Linie alsOracle-Referenz zu nutzen. Obwohl ein Großteil dieses Materials wie eine Aufarbeitung derGrundlagen wirkt, bietet es jedem Anwendungsentwickler die Möglichkeit, sich eine klare,konsistente und arbeitsfähige Terminologie zu erarbeiten. Mithilfe dieser Terminologie kannman mit den Anwendern die Anforderungen erörtern und klären, wie sich diese Anforderun-gen schnell umsetzen lassen. Zudem kann die Diskussion dazu beitragen, dass Ihnen als Ent-wickler einige unsinnige, und vielleicht unbewusste Designgewohnheiten vor Augen geführtwerden. Es ist wichtig sich deutlich zu machen, dass selbst die Leistungsfähigkeit von Oracledurch 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ürobjektrelationale Datenbanken bei der Formulierung Ihrer Bedürfnisse gegenüber den Ent-wicklern, und zu begreifen, wie man diesen Anforderungen gerecht werden kann. Jeder kannso 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 Reportsund Daten, und wissen ganz genau, was die Applikation macht und wie sie funktioniert.

Zudem entlasten Sie die Programmierer von ihrer unangenehmsten Aufgabe: dem Schreibenneuer Reports. Da Sie diese Aufgabe jetzt selbst in einigen Minuten erledigen können, werdenSie 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 einerFußballkartensammlung behält die Namen der Spieler, deren Daten und den Wert der Kartenim 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 organi-siert werden – erst in diesem Moment werden sie zu „Informationen“. Wenn das stimmt, istauch 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-


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 Datenverfügen und damit drei grundlegende Funktionen ausführen: beschaffen, speichern und ab-rufen.

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 Ver-arbeiten. Diese Verarbeitung umfasst prinzipiell dieselben drei Schritte, die Einfluss auf dieOrganisation der Daten haben.

Natürlich könnten Sie alles auch mithilfe einer Zigarrenkiste, einem Stift und einem Blatt Pa-pier bewältigen. Doch sobald die Datenmenge wächst, werden Sie Ihre Werkzeuge wahrschein-lich wechseln. Sie können bei Ordnern, Taschenrechnern, Stiften und Papier bleiben. Auchwenn 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 Ih-nen die Möglichkeit, solche Aufgaben auf verständliche, nachvollziehbare und unkomplizier-te 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.

Abbildung 4-1: Ein einfacher Prozess.

Oracle unterstützt diesen Ansatz von Eingabe-Speichern-Ausgabe und stellt intelligenteWerkzeuge zur Verfügung, mit deren Hilfe Sie auf hohem Niveau festlegen, wie die Daten er-fasst, 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 Reportzusammenzustellen.

reinraus

vorhalten

4.3 Die Sprache von Oracle 35

4.3 Die Sprache von OracleOracle speichert Information in Tabellen – ganz ähnlich wie in der Wettertabelle einer Tages-zeitung (siehe Abbildung 4-2).

Abbildung 4-2: Die Wettertabelle aus einer Tageszeitung.

Diese Tabelle umfasst vier Spalten: City, Temperature, Humidity und Condition. Außerdementhält sie für jede Stadt von Athen bis Sydney eine Zeile. Und schließlich hat die Tabelle einenNamen: WHEATHER.

Dies sind die drei wichtigsten Charakteristiken der meisten Tabellen, die Sie zu sehen bekom-men: Spalten, Zeilen und ein Name. Das gilt auch für die relationalen Datenbanken. Jeder kanndie Wörter und Ideen verstehen, die sie repräsentieren, da die Begriffe, mit denen die Elementeeiner Tabelle in der Oracle-Datenbank beschrieben werden, denen in der Umgangsspracheentsprechen. 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 Tabellenbesitzt eine oder mehrere Spalten. Die Überschriften, wie City, Temperature, Humidity undCondition, beschreiben die Art der Information, die in den Spalten vorgehalten wird. Die In-formationen sind Zeile für Zeile und Stadt für Stadt abgespeichert. Jede Zeile besteht aus ei-nem eindeutigen Datensatz, wie der Temperatur, der Luftfeuchtigkeit und der Witterung fürManchester.

Oracle vermeidet eine spezielle akademische Terminologie, um damit das Produkt besser zu-gänglich zu machen. In Forschungsunterlagen zur relationalen Theorie werden Spalten als „At-tribute“, Zeilen als „Tupel“ und Tabellen als „Entitäten“ bezeichnet. Für den Endanwender sinddiese Begriffe jedoch verwirrend. Darüber hinaus ist es eine völlig unnötige Umbenennung vonDingen, für die es in der Umgangssprache bereits allgemein verständliche Begriffe gibt. WennOracle den Vorteil dieser allgemein verständlichen Sprache nutzt, sollten Entwickler dasselbetun. Ein unnötig technischer Jargon errichtet sinnlose Hürden. Deshalb verwenden wir, ähnlichwie Oracle, in diesem Buch Begriffe wie „Tabellen“, „Spalten“ und „Zeilen“.

WEATHER

City Temperature Humidity ConditionAthens....... 97 89 SunnyChicago...... 66 88 RainLima......... 45 79 RainManchester... 66 98 FogParis........ 81 62 CloudySparta....... 74 63 CloudySydney....... 69 99 Snow


Abbildung 4-3: Eine Wettertabelle von Oracle.

4.3.2 Strukturierte Abfragesprache

Oracle war das erste Unternehmen mit einem Produkt, das die englisch-basierte StructuredQuery Language oder SQL einsetzte. Damit können Endanwender die Informationen selbst ex-trahieren, 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 besitztRegeln für Grammatik und Syntax, die aber im Prinzip den Regeln der englischen Sprache ent-sprechen 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 Programmier-kenntnisse 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ür-den Sie schnell „Athen“ sagen. Wenn Sie gebeten werden, alle Städte auszuwählen, bei denendie Temperatur 66 Grad Fahrenheit beträgt, würden Sie mit „Chicago“ und „Manchester“ ant-worten.

Oracle kann die gleichen Fragen fast genauso einfach beantworten. Die Abfrage ist simpel undsieht fast wie die von Ihnen gestellte Frage aus. Die Schlüsselwörter in einer Oracle-Abfragesind 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 wiefolgt aussehen (das Semikolon teilt Oracle mit, dass der Befehl auszuführen ist):

select City from WEATHER where Humidity = 89 ;

Die Antwort von Oracle lautet:

WEATHER

City Temperature Humidity Condition---------- ----------- -------- ---------ATHENS 97 89 SUNNYCHICAGO 66 88 RAINLIMA 45 79 RAINMANCHESTER 66 98 FOGPARIS 81 62 CLOUDYSPARTA 74 63 CLOUDYSYDNEY 69 99 SNOW

Eine Spalte

Tabellenname

Eine Zeile

4.3 Die Sprache von Oracle 37

City----------ATHENS

Die zweite Abfrage wäre wie folgt:

select City from WEATHER where Temperature = 66 ;

Darauf antwortet Oracle mit:

City-----------MANCHESTERCHICAGO

Und wie steht es mit order by? Angenommen, Sie möchten alle Städte über die Temperatursortieren lassen. Dazu geben Sie einfach Folgendes ein:

select City, Temperature from WEATHER order by Temperature ;

Oracle antwortet mit folgender Aufstellung:

City Temperature----------- -----------LIMA 45MANCHESTER 66CHICAGO 66SYDNEY 69SPARTA 74PARIS 81ATHENS 97

Oracle hat Ihre Tabelle schnell über die Temperatur sortiert. (Diese Tabelle führt die niedrigs-ten Temperaturen als Erstes auf; im nächsten Kapitel erfahren Sie, wie man angibt, dass zuerstdie niedrigeren oder höheren Zahlenwerte stehen).

Mit Oracles Abfragefunktion können Sie noch viele weitere Fragen stellen. Doch diese Beispie-le zeigen, wie man die gewünschten Informationen ohne großen Aufwand aus einer Oracle-Datenbank in einer Form extrahiert, die genau Ihren Vorstellungen entspricht. Sie können auseinfachen Elementen komplizierte Abfragen zusammenstellen, die eingesetzten Methodenstellen jedoch sicher, dass alles verständlich bleibt. So können Sie beispielsweise die Schlüssel-wörter where und order by kombinieren und Oracle anweisen, alle Städte zu selektieren, derenTemperatur über 80 Grad Fahrenheit liegt, und die Städte aufsteigend nach der Temperatursortieren 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 81ATHENS 97


Oder, noch spezieller, könnten Sie alle Städte erfragen, bei denen die Temperatur über 80 GradFahrenheit und die Luftfeuchtigkeit unter 70 Prozent liegt:

select City, Temperature, Humidity from WEATHER where Temperature > 80 and Humidity < 70 order 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üreinige Länder mehr als eine Stadt auflistet. Angenommen, Sie möchten wissen, in welchemLand 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).

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-Ta-belle nach: Der Name steht in der City-Spalte, Sie lesen in der gleichen Zeile weiter und findenden entsprechenden Ländernamen in der Country-Spalte.

Dies sind zwei völlig unterschiedliche und unabhängige Tabellen. Jede Spalte und jede Zeileenthält ihre eigenen Informationen. Ein signifikantes Element ist bei beiden Tabellen gleich: dieCity-Spalte. Für jede Stadt in der WEATHER-Tabelle gibt es einen identischen Städtenamen inder LOCATION-Tabelle.

Wie sehen z. B. die aktuelle Temperatur, die Luftfeuchtigkeit und die Wetterbedingungen ineiner australischen Stadt aus? Sehen Sie sich die beiden Tabellen an, stellen Sie sich das Ganzevor und überdenken Sie beim Durchlesen alles noch einmal.

LOCATION

City Country WEATHER ----------- ------- ATHENS GREECE CHICAGO UNITED STATESCity Temperature Humidity Condition CONAKRY GUINEA---------- ----------- -------- --------- LIMA PERUATHENS 97 89 SUNNY MADRAS INDIACHICAGO 66 88 RAIN MADRID SPAINLIMA 45 79 RAIN MANCHESTER ENGLANDMANCHESTER 66 98 FOG MOSCOW RUSSIAPARIS 81 62 CLOUDY PARIS FRANCESPARTA 74 63 CLOUDY ROME ITALYSYDNEY 69 99 SUNNY SHENYANG CHINA SPARTA GREECE SYDNEY AUSTRALIA TOKYO JAPAN

4.4 Praxisbezogene Beispiele 39

Wie haben Sie das Problem gelöst? In der LOCATION-Tabelle fanden Sie in der Country-Spalte nur einen AUSTRALIA-Eintrag. Gleich nebenan, in der City-Spalte, stand auch derName der Stadt: SYDNEY. Danach suchten Sie in der City-Spalte der WEATHER-Tabellenach dem gleichen Eintrag. Nachdem Sie ihn gefunden hatten, gingen Sie in der Zeile weiterund 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äd-tenamen in der anderen Tabelle in Relation. Diese Beziehung ist die Grundlage für die Bezeich-nung relationale Datenbank (siehe Abbildung 4-5).

Abbildung 4-5: Die Beziehung zwischen der LOCATION- und der WEATHER-Tabelle.

Diese Idee liegt einer relationalen Datenbank zugrunde (manchmal auch relationales Modellgenannt). Die Daten werden in Tabellen gespeichert. Die Tabellen besitzen Spalten, Zeilenund Namen. Wenn jede der Tabellen eine Spalte mit einem gemeinsamen Informationstyp be-sitzt, können sie miteinander verbunden werden.

Das ist alles. Es ist tatsächlich so einfach, wie es den Anschein hat.

4.4 Praxisbezogene BeispieleHaben 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 se-hen, lassen sich in Oracle abspeichern. Mithilfe dieser Tabellen kann Oracle im Handumdre-hen Fragen beantworten, für deren Bearbeitung Sie sonst vergleichsweise sehr viel mehr Zeitbenötigen würden.

Ein typischer Börsenbericht in der Zeitung könnte wie in Abbildung 4-6 aussehen. Dabei han-delt es sich um einen kleinen Ausschnitt aus einer alphabetisch sortierten Liste, die einige Sei-ten lang ist und aus verschiedenen, eng beschriebenen Spalten besteht. Welche Börse handelte

LOCATION

City Country WEATHER ---------- ------- ATHENS GREECE CHICAGO UNITED STATES City Temperature Humidity Condition CONAKRY GUINEA ---------- ----------- -------- --------- LIMA PERU ATHENS 97 89 SUNNY MADRAS INDIA CHICAGO 66 88 RAIN MADRID SPAIN LIMA 45 79 RAIN MANCHESTER ENGLAND MANCHESTER 66 98 FOG MOSCOW RUSSIA PARIS 81 62 CLOUDY PARIS FRANCE SPARTA 74 63 CLOUDY ROME ITALY SYDNEY 69 99 SUNNY SHENYANG CHINA SPARTA GREECE SYDNEY AUSTRALIA TOKYO JAPAN

Beziehung


die meisten Aktien? Bei welcher Aktie war die größte prozentuale Preisänderung zu verzeich-nen, sowohl positiv als auch negativ? Die Antworten auf diese Fragen liefern bei Oracle einfa-che Abfragen: Das Programm findet die Antworten sehr viel schneller, als Sie die Spalten aufder Zeitungsseite jemals durchsuchen können.

Abbildung 4-6: Ein Börsenbericht.

Abbildung 4-7 zeigt den Index einer Zeitung. Was ist in Abschnitt F? In welcher Reihenfolgelesen Sie die Artikel, wenn Sie die Zeitung von vorne nach hinten durchlesen? Die Antwortenauf diese Fragen sind einfache Oracle-Abfragen. Sie werden im weiteren Verlauf des Buchs ler-nen, wie diese Abfragen gestellt und die Tabellen zum Abspeichern der Informationen aufge-baut werden.

Im gesamten Buch arbeiten die Beispiele mit Daten und Objekten, die uns aus dem Geschäfts-leben bekannt sind. Auch die Daten für Ihre Übungen finden Sie in Ihrer unmittelbaren Um-gebung. 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, son-dern auch die Kosten und Risiken bedenken. Kombiniert man, wie bei Oracle, eine relationaleDatenbank mit einer Reihe von leistungsfähigen und einfach zu bedienenden Tools, kann mansich leicht alle möglichen Katastrophenszenarien vorstellen. Fügt man noch objekt- und web-orientierte Funktionen hinzu, verschärft sich die Situation weiter. Die nachfolgenden Ab-schnitte zeigen mögliche Gefahren, die Benutzer und Entwickler beachten sollten.

Close Close SharesCompany Yesterday Today TradedAd Specialty 31.75 31.75 18,333,876Apple Cannery 33.75 36.50 25,787,229AT Space 46.75 48.00 11,398,323August Enterprises 15.00 15.00 12,221,711Brandon Ellipsis 32.75 33.50 25,789,769General Entropy 64.25 66.00 7,598,562Geneva Rocketry 22.75 27.25 22,533,944Hayward Antiseptic 104.25 106.00 3,358,561IDK 95.00 95.25 9,443,523India Cosmetics 30.75 30.75 8,134,878Isaiah James Storage 13.25 13.75 22,112,171KDK Airlines 80.00 85.25 7,481,566Kentgen Biophysics 18.25 19.50 6,636,863LaVay Cosmetics 21.50 22.00 3,341,542Local Development 26.75 27.25 2,596,934Maxtide 8.25 8.00 2,836,893MBK Communications 43.25 41.00 10,022,980Memory Graphics 15.50 14.25 4,557,992Micro Token 77.00 76.50 25,205,667Nancy Lee Features 13.50 14.25 14,222,692Northern Boreal 26.75 28.00 1,348,323Ockham Systems 21.50 22.00 7,052,990Oscar Coal Drayage 87.00 88.50 25,798,992Robert James Apparel 23.25 24.00 19,032,481Soup Sensations 16.25 16.75 22,574,879Wonder Labs 5.00 5.00 2,553,71

4.5 Wo liegen die Risiken? 41

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 Ta-bellen, Spalten und Zeilen ist nicht schwer zu verstehen. Die Beziehung zwischen zwei Tabel-len ist konzeptionell gesehen relativ einfach. Selbst die Normalisierung, also der Prozess, beidem die inhärenten oder „normalen“ Beziehungen zwischen den verschiedenen Elementenvon Unternehmensdaten analysiert werden, ist relativ leicht erlernbar.

Leider produziert das häufig quasi aus dem Nichts „Experten“, die zwar über viel Selbstver-trauen verfügen, aber nur wenig Erfahrung mit dem Aufbau von realen Anwendungen in Pro-duktionsqualität haben. Bei einer kleinen Marketing-Datenbank oder einer internen Be-standsaufnahme mag dies noch keine große Rolle spielen. Die gemachten Fehler offenbarensich mit der Zeit, die Lektionen können gelernt und die Fehler beim nächsten Mal vermiedenwerden. Bei einer wichtigen Anwendung ist das jedoch der sicherste Weg in den Abgrund. Die-ser Mangel an Erfahrung steckt üblicherweise auch hinter den Presseberichten über geschei-terte Großprojekte.

Ältere Entwicklungsmethoden sind im Allgemeinen langsamer. Bei diesen Methoden gibt eszwar einige Kontrollen und eine Qualitätssicherung, aber die grundlegenden Aufgaben – dasCodieren, Kompilieren, Linken und die Tests – laufen wesentlich langsamer ab. Insbesondereauf einem Mainframe ist dieser Zyklus oft so ermüdend, dass Programmierer einen Großteilder Zeit mit irgendwelchen Tests verbringen, um zu vermeiden, dass ein Codefehler einen wei-teren vollen Zyklusdurchlauf verursacht.

Werkzeuge der vierten Generation verleiten Entwickler dazu, sich sofort in die Produktion zustürzen. Änderungen können so schnell eingebaut werden, dass den Tests nur noch wenig Be-achtung geschenkt wird. Das Eliminieren praktisch aller Prüfungsmöglichkeiten kompliziertdas Problem weiter. Viele meinen, dass sich ein eventueller Fehler nachträglich noch schnellbeheben lässt. „Falls die Daten beschädigt sind, können wir das Ganze mit einer schnellen Ak-tualisierung beheben. Sollte das nicht schnell genug gehen, tunen wir sie eben im Hauruck-Verfahren. Bleiben wir im Zeitplan und zeigen denen, aus welchem Holz wir geschnitzt sind.“

Feature Sections PageBirths F 7Bridge B 2Business E 1Classified F 8Comics C 4Doctor's In F 6Editorials A 12Modern Life B 1Movies B 4National News A 1Obituaries F 6Sports D 1Television B 7Weather C 2


Bei einer wichtigen Oracle-Applikation sollte der Testzyklus länger und sorgfältiger als bei ei-nem herkömmlichen Projekt sein. Das gilt auch, wenn es eine ausgefeilte Projektsteuerunggibt und erfahrene Projektmanager das Sagen haben – gerade sie neigen zu übertriebenemSelbstvertrauen und oft zu nachlässigen Testverfahren. Die Tests müssen die Eingabebild-schirme und Reports, die Datenbelastungen und Updates, die Datenintegrität und Engpässebeachten, und sich besonders mit den Transaktions- und Speichervolumina beschäftigen, diezu Spitzenzeiten auftreten.

Da tatsächlich alles so einfach ist wie behauptet, verläuft die Anwendungsentwicklung mitOracle-Werkzeugen ungemein schnell. Doch damit wird automatisch der Umfang der Testsreduziert, die üblicherweise ein Bestandteil der Entwicklung sind. Gleichzeitig vergrößert sichdamit der nachträgliche Aufwand zum Beheben der aufgetretenen Fehler. Dieser Umstandwird von Einsteigern meistens nicht bedacht, ist aber im Projektplan unbedingt zu berücksich-tigen.

4.6 Der Stellenwert der neuen VisionViele von uns warten auf den Tag, an dem wir einfach eine „natürliche“ Abfrage in unsererSprache eingeben können, und die Antwort nach wenigen Augenblicken auf den Bildschirmbekommen.

Wir sind diesem Ziel schon sehr viel näher, als sich die meisten von uns vorstellen. Der ein-schränkende Faktor ist nicht mehr die Technologie, sondern eher unsere gedankliche Strengebeim Anwendungsdesign. Oracle kann problemlos ausgefeilte sprachorientierte Systeme erstel-len, die leicht verständlich sind und auch weniger geübte Anwender bedienen können. Die Ora-cle-Datenbank hat das Potenzial und die Werkzeuge sind bereits vorhanden, doch nur wenigeverstehen sich darauf und setzen dies um.

Klarheit und Verständlichkeit sollten das Kennzeichen jeder Oracle-Anwendung sein. Die An-wendungen sollten für Benutzer ohne Programmiererfahrung leicht verständlich sein, und dieInformationen über einfache Abfragen zur Verfügung stellen.

Aber wie? Das oberste Ziel beim Design sollte darin bestehen, die Anwendung so verständlichund die Bedienung so einfach wie möglich zu gestalten. Auch wenn Sie sich mal irren, solltediese Richtung beibehalten werden, selbst wenn dadurch mehr CPU-Zeit und Plattenplatz be-nötigt wird. Eine Einschränkung ist bei diesem Ansatz nur dann gegeben, wenn man eine ex-trem einfache Anwendung aufbaut und dafür zu komplexe Programme erstellt, die nur schweroder überhaupt nicht zu pflegen sind. Das wäre ein ebenso großer Fehler. Deshalb sollte einGleichgewicht herrschen, und die Orientierung am Endanwender nicht für eine clevere Codie-rung vernachlässigt werden.

4.6.1 Umgebungen ändern sich

Die Kosten für den Betrieb eines Rechners, ausgedrückt in Millionen Instruktionen pro Se-kunde (MIPS), sind in der Vergangenheit jährlich um 20 Prozent gesunken. Andererseits sinddie Arbeitskosten kontinuierlich gestiegen, was nicht nur am allgemeinen Trend liegt, sondernauch an der Tatsache, dass die Gehälter der langjährigen Mitarbeiter ständig steigen, je länger

4.6 Der Stellenwert der neuen Vision 43

und erfolgreicher sie für ein Unternehmen tätig sind. Das bedeutet, dass jede Arbeit, die vomMenschen auf die Maschine verschoben werden kann, eine kostensenkende Maßnahme ist.

Haben wir diese Erkenntnis beim Anwendungsdesign berücksichtigt? Die Antwort lautet „einbisschen“, 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-Win-dows, MS-Windows, webbasierten Browsern und anderen grafikorientierten Systemen reali-siert. Diese Umgebungen sind viel leichter zu bedienen und zu verstehen als die älteren, zei-chenbasierten Systeme, was früher Tage dauerte, geschieht heute in Minuten. In einigenBereichen sind die Verbesserungen so groß, dass wir dabei aus den Augen verloren haben, wieschwer manche Aufgaben normalerweise waren.

Leider wurde dieses Konzept einer anpassungsfähigen und freundlichen Umgebung nur vonwenigen Entwicklern aufgegriffen. Selbst wenn sie in diesen Umgebungen arbeiten, pflegen siealte 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, Ab-kürzungen und Benennungsstandards aus, die bei der Betrachtung der Bedürfnisse der Endan-wender oftmals ignoriert werden. Werden diese drei Punkte überhaupt beachtet, berücksich-tigen sie meistens nur die Belange der Systemtruppe. Das mag als trockenes unduninteressantes Problem erscheinen, kann aber den Unterschied ausmachen zwischen einemgroßen Erfolg und murrender Akzeptanz, zwischen einem Quantensprung in der Produktivi-tät und marginalen Fortschritten, zwischen effektiven und gelangweilten Anwendern, die dieEntwickler mit immer neuen Anforderungen eindecken.

Üblicherweise wurden Geschäftseintragungen in Haupt- und Rechnungsbüchern vorgenom-men. Jedes Ereignis und jede Transaktion wurde niedergeschrieben, Zeile für Zeile. Im Zugeder Applikationsentwicklung wurden die Datenwerte durch Codes ersetzt (wie „01“ für For-derungen und „02“ für Verbindlichkeiten). Die Angestellten mussten diese Codes entwederkennen oder nachschlagen, und sie an den entsprechenden Stellen am Bildschirm eingeben.Dies ist zwar ein extremes Beispiel, aber tatsächlich arbeiten Tausende von Anwendungennach 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 Mainframe-Systemen angesprochen. Als man dort die relationalen Datenbanksysteme einführte, wurden sieeinfach als Ersatz für die älteren Eingabe/Ausgabe-Methoden wie Virtual Storage Access Me-thod (VSAM) und Information Management System (IMS) benutzt. Die Leistungsfähigkeit undFunktionen 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 Argumenteangeführt:

■ Eine Kategorie enthält so viele Elemente, dass sie sich mit den Mitteln der normalen Spra-che nicht darstellen lassen.

■ Um Platz auf dem Computer zu sparen.


Der zweite Punkt ist ein Anachronismus. Arbeitsspeicher oder Speichermedien waren einst soteuer und die CPUs so langsam, dass die Programmierer jedes Stückchen Information auf demkleinst möglichen Platz unterbringen mussten. Zahlen und Zeichen belegten im Speicher desRechners nur halb soviel Platz wie Buchstaben, und Codes reduzierten die Anforderungen andie Maschine noch weiter.

Weil die Rechner teuer waren, mussten die Entwickler für alles Codes einsetzen, damit über-haupt irgendetwas lief. Das war die technische Lösung für ein wirtschaftliches Problem. Die An-forderungen 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 andie Bedürfnisse der Menschen hätten anpassen können. Ergo wurden die Menschen an die Ma-schinen angepasst. Das war ein notwendiges Übel.

Diese wirtschaftliche Rechtfertigung für Codes ist seit Jahren überholt. Die Rechner sind heuteschnell und billig genug, um sich an den Menschen anzupassen und mit einer verständlichenSprache zu arbeiten. Trotzdem setzen die Entwickler, ohne darüber nachzudenken, weiterhinauf 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 einzu-geben statt Textstrings. Diese Rechtfertigung gilt bei Oracle allerdings nicht. Nicht nur, dass esteuer ist, die Leute so zu schulen, dass sie die richtigen Codes für die Namen der Kunden, Pro-dukte, 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 Ver-wendung 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. Ora-cle 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 kaumnoch Eingabefehler, weil der Anwender ein sofortiges Feedback über die eingegebenen Ge-schäftsinformationen erhält. Ziffern und Codes werden nicht mehr falsch eingegeben. Und beiFinanzanwendungen gehen Beträge seltener auf Interimskonten verloren, nur weil die Einga-ben falsch waren, was wiederum signifikante Einsparungen nach sich zieht.

Auch die Anwendungen selbst werden verständlicher: Bildschirme und Reports werden ausendlosen Zahlenreihen in leserliche und verständliche Formate transformiert. Das Ändern desAnwendungsdesigns von der Code- zur Sprachorientierung hat nachhaltige Auswirkungenauf das Unternehmen und seine Mitarbeiter. Für Anwender, die mit Codehandbüchern über-frachtet wurden, sind sprachorientierte Anwendungen eine große psychologische Erleichte-rung.

4.7 Schritte in die richtige Richtung 45

4.7 Schritte in die richtige RichtungEine 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 zwi-schen den einzelnen Namen unterscheiden zu können, oder dass in einer Kategorie vielePunkte 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 zubehalten oder zu unterscheiden sind. In den meisten Fällen lässt sich das auf eine unvollstän-dige Kategorisierung der Informationen zurückführen: Zu viele verschiedene Dinge wurdenin eine zu umfängliche Kategorie gestopft. Das Entwickeln einer Anwendung mit einer strengsprachorientierten Ausrichtung erfordert im Gegensatz zu einer codebasierten Anwendung,dass Entwickler und Anwender viel Zeit miteinander verbringen – Informationen werden vongeschäftlichen Abläufen getrennt, die natürlichen Beziehungen und Kategorien sind zu ermit-teln, 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, inder die Daten vernünftig organisiert und in Tabellen und Spalten abgespeichert werden, derenNamen dem Anwender vertraut sind. Die Daten sollen selbsterklärende Namen haben, keineCodes.

4.7.1 Die Normalisierung

Die Beziehungen zwischen Ländern, zwischen den Abteilungen in einem Unternehmen oderAnwendern und Entwicklern sind normalerweise das Ergebnis von besonderen historischenUmständen, und können die aktuellen Beziehungen selbst dann noch definieren, wenn sichdie Bedingungen eigentlich schon lange geändert haben. Das Ergebnis können anormale, oderneusprachlich, dysfunktionale Beziehungen sein. Die Historie und die Umstände haben in Be-zug auf Daten oft die gleichen Auswirkungen – es kommt darauf an, wann sie gesammelt, or-ganisiert und berichtet wurden. Und auch Daten können anormal, und damit dysfunktionalwerden.

Normalisierung ist ein Prozess, bei dem Dinge richtiggestellt, d. h. normalisiert werden. Die-ser Begriff stammt von dem lateinischen Wort norma ab, das ein Zimmermannsquadrat be-zeichnete, mit dessen Hilfe der rechte Winkel ermittelt wurde. In der Geometrie bezeichnetman eine Linie, die im rechten Winkel zu einer anderen Linie steht, als „normal“. In einerrelationalen Datenbank hat dieser Begriff auch eine spezielle mathematische Bedeutung, diemit der Aufteilung der Datenelemente (z. B. Namen, Adressen oder Fertigkeiten) in verwand-te Gruppen zutun hat, und die normalen oder „korrekten“ Beziehungen zwischen ihnen de-finiert.


Die grundlegenden Konzepte der Normalisierung werden so erläutert, dass Anwender sie indas Design einer Anwendung miteinbeziehen oder eine bereits bestehende Applikation besserverstehen können. Es wäre ein Fehler zu glauben, dass dieser Prozess nur beim Design einerDatenbank oder einer Computeranwendung einsetzbar sei. Die Normalisierung resultiert ausprofunden Einblicken, welche Informationen in einem Unternehmen eingesetzt werden undwie die verschiedenen Elemente dieser Informationen miteinander verknüpft sind.

Das logische ModellEin erster Schritt im Analyseprozess ist der Aufbau eines logischen Modells, das einfach ein nor-malisiertes Diagramm aller im Unternehmen eingesetzten Daten ist. Das Wissen darüber, wieund warum die Daten zerlegt und getrennt werden, ist wesentlich für das Verständnis des Mo-dells. Das Modell wiederum ist grundlegend für den Aufbau einer Anwendung, die lange ge-nutzt wird und keine besondere Pflege benötigt.

Die Normalisierung wird üblicherweise mithilfe des Begriffs Form diskutiert: Man unterschei-det die erste, zweite und dritte Normalform, wobei die dritte Form den am höchsten norma-lisierten Status wiedergibt. Es existiert auch noch eine vierte und fünfte Normalform, diesewerden 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 Inhaltdes Titels. Angenommen, diese buchbezogenen Daten sollen die Grundlage für das Design derOracle-Tabellen sein. Nennen wir die Tabelle BOOKSHELF, und die Spalten sollen Title, Pu-blisher, Author1, Author2, Author3 sowie Category1, Category2 und Category3 heißen. DieAnwender haben mit dieser Tabelle bereits ein Problem: In der BOOKSHELF-Tabelle könnenfür ein Buch höchstens drei Autoren oder Kategorien angegeben werden.

Was geschieht, wenn sich die Liste der akzeptablen Kategorien ändert? Irgendjemand müsstesich durch alle Zeilen in der BOOKSHELF-Tabelle arbeiten und sämtliche alten Werte korri-gieren. Und was passiert, wenn einer der Autoren seinen Namen ändert? Auch in diesem Fallsind alle abhängigen Datensätze zu ändern. Und was geschieht, wenn ein vierter Autor an ei-nem Titel mitarbeitet?

Dies sind eigentlich keine technischen oder verarbeitungsbezogenen Probleme, auch wenn sieim Zusammenhang mit dem Entwurf einer Datenbank auftauchen. Es gibt noch weitaus mehrgrundlegende Fragen, die eine zweckmäßige und logische Strukturierung der Informationenin einem Unternehmen betreffen. Genau mit diesen Themen setzt sich die Normalisierungauseinander. Dazu werden die einzelnen Elemente der Daten in verwandten Gruppen reorga-nisiert, man beseitigt dysfunktionale Beziehungen und stellt die normalen Beziehungen her.

Die Daten normalisierenIn einem ersten Schritt bringt man die Daten in die erste Normalform. Dazu werden die Datenin 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.


Anstatt pro Buch nur drei Autoren zuzulassen, hinterlegt man die Daten der Autoren in einereigenen Tabelle, mit jeweils einer Zeile pro Name und Beschreibung. Damit erübrigt sich dieNotwendigkeit, 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än-ken.

Danach definieren Sie für jede Tabelle den Primärschlüssel: Welches Element identifiziert eineZeile eindeutig und erlaubt, eine Zeile mit Informationen zu extrahieren? Um das Beispiel zuvereinfachen, nehmen wir an, die Autorennamen seien eindeutig: dann kann AuthorName derPrimärschlüssel für die AUTHOR-Tabelle sein.

Damit wurde die BOOKSHELF-Tabelle in zwei Tabellen aufgeteilt: AUTHOR mit den SpaltenAuthorName (dem Primärschlüssel) und Comments, und BOOKSHELF mit dem Primär-schlüssel Title und den Spalten Publisher, Category1, Category2, Category3, Rating und Rating-Description. Eine dritte Tabelle, BOOKSHELF_AUTHOR, enthält die Verbindungen: MehrereAutoren 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 Be-ziehungen und die 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 nurvon einem Teil des Schlüssels abhängen. Gibt es Attribute, die nicht vom gesamten Schlüssel ab-hängen, sollte man diese Daten in eine neue Tabelle verschieben. In unserem Fall hängt Rating-Description nicht wirklich von Title ab – es basiert auf dem Spaltenwert Rating. Deshalb sollteman es auch in eine separate Tabelle verschieben.

Im letzten Schritt, der dritten Normalform, wirft man alles aus den Tabellen, das nicht aus-schließlich vom Primärschlüssel abhängt. In diesem Beispiel hängen die Kategorien zusam-men: Sie würden einen Titel nicht gleichzeitig als „Fiction“ und „Nonfiction“ einordnen, undunter der Kategorie „Adult“ gibt es sicher andere Unterkategorien als unter „Children“. DieKategorieinformationen werden deshalb in eine separate Tabelle verschoben. Abbildung 4-9zeigt die Tabellen in der dritten Normalform.

Primärschlüssel


Abbildung 4-9: BOOKSHELF und dazugehörige Tabellen.

Befinden sich die Daten in der dritten Normalform, sind sie damit automatisch schon in derzweiten und ersten Normalform. Der gesamte Prozess lässt sich deshalb auch verkürzen, somitmuss 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üs-sel abhängig sind. Die dritte Normalform wird auch als „der Schlüssel, der gesamte Schlüsselund nichts als der Schlüssel“ beschrieben.

Durch die Daten navigierenDie Bücherbord-Datenbank befindet sich nun in der dritten Normalform. Abbildung 4-10zeigt ein Beispiel dafür, was diese Tabellen enthalten können. Es ist leicht nachvollziehbar, dassdiese Tabellen zusammengehören. Basierend auf den Schlüsseln der Tabellen gehen Sie von ei-ner Tabelle zur anderen und holen die Informationen über einen bestimmten Autor ab. DerPrimärschlüssel in jeder Tabelle kann eine einzelne Zeile eindeutig identifizieren. Wählt manbeispielsweise Stephen Jay Gould, findet man diesen Datensatz in der AUTHOR-Tabelle, weilAuthorName der Primärschlüssel ist.

Wenn Sie sich Harper Lee in der AuthorName-Spalte der BOOKSHELF_AUTHOR-Tabelleansehen, 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 inder RATING-Tabelle.

Hätten Sie in der BOOKSHELF-Tabelle nach „To Kill A Mockingbird“ gesucht, würde die Su-che ü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 nachDatensätzen, bei denen dieser Wert in der Title-Spalte steht – die „Title“-Spalte ist einFremdschlüssel in der BOOKSHELF_AUTHOR-Tabelle. Erscheint der Primärschlüssel fürBOOKSHELF in einer anderen Tabelle, wie in der BOOKSHELF_AUTHOR-Tabelle, be-zeichnet man das als Fremdschlüssel auf diese Tabelle.


Abbildung 4-10: Beispieldaten aus den BOOKSHELF-Tabellen.

AUTHORAuthorName Comments--------------------- -------------------------------------------DIETRICH BONHOEFFER GERMAN THEOLOGIAN, KILLED IN A WAR CAMPROBERT BRETALL KIERKEGAARD ANTHOLOGISTALEXANDRA DAY AUTHOR OF PICTURE BOOKS FOR CHILDRENSTEPHEN JAY GOULD SCIENCE COLUMNIST, HARVARD PROFESSORSOREN KIERKEGAARD DANISH PHILOSOPHER AND THEOLOGIANHARPER LEE AMERICAN NOVELIST, PUBLISHED ONLY ONE NOVELLUCY MAUD MONTGOMERY CANADIAN NOVELISTJOHN ALLEN PAULOS MATHEMATICS PROFESSORJ. RODALE ORGANIC GARDENING EXPERT

RATINGRating RatingDescription---------- -----------------1 ENTERTAINMENT2 BACKGROUND INFORMATION3 RECOMMENDED4 STRONGLY RECOMMENDED5 REQUIRED READING

CATEGORYCategoryName ParentCategory SubCategory-------------- --------------- ------------ADULTREF ADULT REFERENCEADULTFIC ADULT FICTIONADULTNF ADULT NONFICTIONCHILDRENPIC CHILDREN PICTURE BOOKCHILDRENFIC CHILDREN FICTIONCHILDRENNF CHILDREN NONFICTION

BOOKSHELF_AUTHORTitle AuthorName------------------------------ ---------------------TO KILL A MOCKINGBIRD HARPER LEEWONDERFUL LIFE STEPHEN JAY GOULDINNUMERACY JOHN ALLEN PAULOSKIERKEGAARD ANTHOLOGY ROBERT BRETALLKIERKEGAARD ANTHOLOGY SOREN KIERKEGAARDANNE OF GREEN GABLES LUCY MAUD MONTGOMERYGOOD DOG, CARL ALEXANDRA DAYLETTERS AND PAPERS FROM PRISON DIETRICH BONHOEFFER

BOOKSHELFTitle Publisher CategoryName Rating------------------------------ --------------------- ------------ ------TO KILL A MOCKINGBIRD HARPERCOLLINS ADULTFIC 5WONDERFUL LIFE W.W.NORTON & CO. ADULTNF 5INNUMERACY VINTAGE BOOKS ADULTNF 4KIERKEGAARD ANTHOLOGY PRINCETON UNIV PR ADULTREF 3ANNE OF GREEN GABLES GRAMMERCY CHILDRENFIC 3GOOD DOG, CARL LITTLE SIMON CHILDRENPIC 1LETTERS AND PAPERS FROM PRISON SCRIBNER ADULTNF 4


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 organisiertsind, können Sie Datensätze mit potenziellen Kategorien, Ratings und Autoren vorhalten, selbstwenn keines der aktuellen Bücher diese Werte verwendet.

Das ist ein sinnvoller und logischer Weg zur Organisation von Daten, auch wenn man die „Ta-bellen“ nur handschriftlich auf Papier festhält. Natürlich muss noch einiges getan werden, umdies in eine echte Datenbank zu verwandeln. So lässt sich AuthorName beispielsweise in First-Name und LastName zerlegen, und möglicherweise suchen Sie nach einem Weg, um anzeigenzu können, welcher Autor der Hauptautor ist oder ob ein Autor gleichzeitig der Herausgeberist.

Diesen umfassenden Prozess nennt man Normalisierung. Komplizierter ist es nicht. Zu einemguten Design gehören noch einige andere Punkte, aber die Grundlagen für die Analyse von„normalen“ Beziehungen zwischen den verschiedenen Datenelementen sind genau so einfachund 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 sichmit ganz anderen Aspekten, und es wäre ein grundsätzlicher Fehler anzunehmen, dass die nor-malisierten 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 Anwendungerkannt und entsprechend getrennt wurden, sind passende Namen für die Tabellen und Spal-ten zu wählen, in denen die Daten hinterlegt werden sollen. Diesem Aspekt widmen selbstjene zu wenig Aufmerksamkeit, die es eigentlich besser wissen müssten. Die Tabellen- undSpaltennamen werden oft ohne Rücksprache mit den Endanwendern entwickelt, und wäh-rend der Designphase nicht mehr überprüft. Geht eine solche Anwendung in den Echtbe-trieb, haben diese Versäumnisse oft schwerwiegende Konsequenzen.

Sehen wir uns beispielsweise die Tabelle in Abbildung 4-10 an. Die Tabellen- und Spaltenna-men sind praktisch alle selbsterklärend. Selbst ein Endanwender, der noch nie mit den relati-onalen Ideen und SQL zu tun hatte, würde eine Abfrage wie die folgende relativ leicht verste-hen 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 kei-ne unklaren oder falsch definierten Ausdrücke. Sind Tabellen mit zahlreichen Spalten zu defi-nieren, kann die Benennung der Tabellen ein schwieriges Unterfangen sein, aber in diesem Fallsind einige wenige Regeln recht hilfreich. Sehen wir uns die Schwierigkeiten näher an, diedurch fehlende Namenskonventionen verursacht werden können. Was wäre, wenn Sie folgen-de Namen gewählt hätten?


BOOKSHELF B_A AUTHS CATEGORIES------------- ----------------- ------------ -------------title title anam catpub aname comms p_catcat s_catrat

Die Benennungstechnik dieser Tabelle ist merkwürdig und leider weit verbreitet. Die Tabellenund Spalten wurden gemäß den Konventionen (oder fehlenden Konventionen) benannt, dieeinige bekannte Hersteller und Softwarehäuser einsetzen.

Die folgende Aufstellung zeigt einige der offensichtlichsten Fehler, die bei der Namensliste ge-macht 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 ab-leiten. 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 solchenTabellen zu tun haben, können nicht einfach Abfragen eingeben. Diese Abfragen haben nichtden gleichen intuitiven und vertrauten Charakter wie bei der BOOKSHELF-Tabelle. Und dasbeeinträchtigt die Akzeptanz und Nützlichkeit der Anwendung.

Von den Entwicklern wird üblicherweise verlangt, dass Tabellen- und Spaltennamen maximalsechs bis acht Zeichen lang sind. Als Ergebnis bestehen die Namen aus einem unverständli-chen Mix aus Buchstaben, Zahlen und kryptischen Abkürzungen. Wie so viele andere Ein-schränkungen, die dem Anwender bei älteren Technologien auferlegt wurden, ist auch diesenicht mehr länger haltbar. Oracle erlaubt Tabellen- und Spaltennamen mit einer Länge vonbis zu 30 Zeichen. Das gibt den Entwicklern genügend Raum, um vollständige, eindeutige undselbsterklärende Benennungen zu vergeben.


Die erwähnten Schwierigkeiten implizieren auch Lösungen, wie das Vermeiden von Abkür-zungen und Plural. Unterstriche sollten entweder ganz weggelassen oder konsistent verwen-det werden. Diese wenigen Faustregeln werden das mögliche Chaos im Bereich derNamensgebung beseitigen. Gleichzeitig müssen die Konventionen einfach, leicht verständ-lich und einprägsam sein. Im übertragenen Sinn benötigt man auch für die Namen eine Nor-malisierung. Genau wie bei Daten, die logisch analysiert, zweckorientiert getrennt undnormalisiert werden, sollte man auch bei den Benennungskonventionen die nötige Aufmerk-samkeit walten lassen.

4.7.3 Selbsterklärende Namen für die Daten

Nachdem die wichtige Frage der Benennungskonventionen für die Tabellen und Spalten be-sprochen wurde, muss man sich die Daten selbst ansehen. Werden die Daten aus den Tabel-len in einem Report ausgedruckt, hat die Transparenz der Daten auch Einfluss auf dieVerständlichkeit des Reports. Im BOOKSHELF-Beispiel ist Rating ein Codewert, und Cate-gory ist eine Verkettung aus mehreren Werten. Ist das eine Verbesserung? Wenn Sie jeman-den nach einem Buch gefragt haben, möchten Sie dann erfahren, dass es in AdultNF als 4eingestuft ist? Warum sollte es einer Maschine erlaubt sein, weniger klar zu sein?

Hält man die Informationen mit umgangssprachlichen Begriffen vor, gestalten sich auch dieAbfragen 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 uner-heblich ist, ob die Namen groß- oder kleingeschrieben wurden. Tabellen- und Spaltennamenwerden intern immer in Großbuchstaben abgespeichert. Wenn Sie eine Abfrage eingeben,konvertiert Oracle die Tabellen- und Spaltennamen in Großbuchstaben und überprüft sie da-nach mit seinem Dictionary. Andere relationale Datenbanksysteme beachten hingegen dieGroß- und Kleinschreibung. Wenn man einen Spaltennamen als „Ability“ eingibt, der in derDatenbank selbst als „ability“ oder „ABILITY“ hinterlegt ist, wird die Abfrage nicht verstan-den.

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, weildie Entwickler mehrere Tabellen mit ähnlichen Namen anlegen können. So lässt sich beispiels-weise eine WORKER-, wORrker- und eine Worker-Tabelle usw. anlegen. Wie kann sich je-mand, der Entwickler eingeschlossen, diese Unterschiede überhaupt merken? Das Ganze ist

4.9 Namen normalisieren 53

doch kein Vorteil, sondern eher ein Rückschritt, und Oracle ist klugerweise nicht in diese Fallegegangen.

Ähnlich liegen die Dinge bei Daten, die in einer Datenbank gespeichert sind. Es gibt Wege, Da-ten in einer Datenbank unabhängig von der jeweiligen Schreibweise aufzuspüren, aber dieseMethoden stellen eine unnötige und zusätzliche Belastung dar. Bis auf wenige Ausnahmen istes viel einfacher, die Daten in Großbuchstaben abzuspeichern. Damit werden einerseits dieAbfragen erleichtert, und andererseits sehen die Reports konsistenter aus. Falls Daten in Klein-buchstaben oder in gemischter Schreibweise zu hinterlegen sind, stellt Oracle die entsprechen-den Konversionsfunktionen zur Verfügung.

Wenn Sie sich dieses Kapitel noch einmal vergegenwärtigen, werden Sie feststellen, dass wirdieser Praxis bisher nicht gefolgt sind. Ab sofort werden die Daten in der Datenbank, mit Aus-nahme von wenigen Tabellen und einigen isolierten Instanzen, in Großbuchstaben dargestellt.

4.9 Namen normalisierenAuf dem Markt gibt es verschiedene Werkzeuge, mit denen man umgangssprachliche Abfra-gen stellen kann, statt mit unsinnigen Begriffen arbeiten zu müssen. Diese Produkte baueneine logische Entsprechung zwischen den umgangssprachlichen Begriffen und den schwer zumerkenden Spalten-, Tabellennamen und Codes auf. Dieses Mapping muss genau durchdachtsein, doch wenn es einmal funktioniert, erleichtert es die Interaktion mit der Anwendung ganzerheblich. Warum nicht von Anfang an Nägel mit Köpfen machen? Warum erst die Notwen-digkeit schaffen, eine neue Ebene zu definieren, neue Produkte einzusetzen und mehr Arbeitinvestieren zu müssen, wenn sich dieser Umstand durch das Einhalten von Namenskonventi-onen weitgehend vermeiden lässt?

Aus Performancegründen kann es notwendig sein, die Daten bestimmter Anwendungen in co-dierter Form vorzuhalten. Diese Codes sollten dem Anwender nicht angezeigt werden, und beider 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 Ein-gaben. Enthalten Reports anstelle von umgangssprachlichen Begriffen irgendwelche Codes,kann es zu Fehlinterpretationen kommen. Und wenn die Benutzer neue oder Ad hoc-Reportsanlegen sollen, können Codes oder Abkürzungen dieses Unterfangen erschweren.

Bei Oracle können Benutzer in der gesamten Anwendung mit umgangssprachlichen Begriffenarbeiten. Diese Möglichkeit zu ignorieren bedeutet, nicht die volle Leistungsfähigkeit von Ora-cle auszuschöpfen. Zudem erhält man im Ergebnis unverständlichere und unproduktivereAnwendungen. Die Entwickler sollten die Gelegenheit nutzen – und die Anwender sollten dieseinfordern. Davon werden beide Gruppen enorm profitieren.

4.10 Gutes Design hat eine menschliche SeiteSollten Sie Anfänger sein, möchten Sie vielleicht gleich mit der Arbeit in SQL beginnen. DieseProgrammiersprache wird im folgenden Kapitel behandelt. Der Rest dieses Kapitels beschäf-tigt sich mit Betrachtungen zu Performance, Benennung und Design.


Dieser Abschnitt beschäftigt sich mit der Projektentwicklung, wobei die Aufgaben im Vorder-grund stehen, die Ihre Benutzer zu erfüllen haben. Das unterscheidet sich von der üblichenDatenorientierung vieler Entwickler und Entwicklungsmethoden. Die Datennormalisierungund die CASE-Technologie (Computer Aided Software Engi-neering) sind im Zusammen-hang mit der Entwicklung von relationalen Anwendungen derart in den Mittelpunkt der Be-trachtungen gerückt, dass die Fokussierung auf die Daten und die Fragen der referenziellen In-tegrität, Schlüssel, Normalisierung und Tabellendiagramme zu einer regelrechten Besessen-heit geworden sind. Diese Punkte werden oft mit dem Design verwechselt – und sogar für dasDesign gehalten – und irgendwann stellt man überrascht fest, dass es sich eigentlich um eineAnalyse handelt.

Die Normalisierung ist Analyse und kein Design. Darüber hinaus ist sie nur ein Teil der notwen-digen Analyse zum Verständnis der Geschäftsabläufe und dem Aufbau einer nützlichen An-wendung. Das Ziel der Anwendungsentwicklung ist vor allem, die Geschwindigkeit und Effi-zienz der Unternehmensaufgaben zu erhöhen, indem die Umgebung, in der die Kollegen ihreArbeit erledigen, so sinnvoll und nützlich wie möglich gestaltet wird. Geben Sie den Leuten dieKontrolle über ihre Informationen und gestalten Sie den Zugriff auf diese Informationen ein-fach und intuitiv: Im Ergebnis verbessert sich nicht nur die Produktivität, sondern auch dasArbeitsumfeld. Wenn Sie die Kontrolle der Daten einer anderen Institution übergeben, unddiese Stelle die Informationen als unverständliche Codes präsentiert und wenig benutzer-freundliche Schnittstellen zur Verfügung stellt, werden Produktivität und Arbeitsklima darun-ter leiden – um sich das vorzustellen, muss man kein Genie sein.

Die hier vorgestellten Methoden bedeuten keine radikale Umwälzung dieses Prozesses, unddie Ihnen vertrauten Werkzeuge für die vorhandenen Datenstrukturen reichen zur Erledigungdieser Aufgabe wahrscheinlich aus. Der vorgestellte Ansatz zielt ab auf die Entwicklung von re-aktionsschnellen, 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 dieAufgaben des Anwenders – also jener Arbeiten, die der Rechner automatisieren und unterstüt-zen soll. Gründe dafür können die Spezialisierung der Anwendung sein, oder, was öfter derFall ist, die Datenorientierung des Designs. Bei der Analyse stehen oft folgende Fragen im Vor-dergrund:

■ 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 Eingabe-formulare und Codes, das Bildschirmlayout, Berechnungen, Korrekturen, Audit Trails, Spei-chervolumen, Verarbeitungszyklen, Verteilung und Wartung gehören. Alle angesprochenenElemente sind äußerst wichtige Bereiche. Die Schwierigkeit ist, dass sie sich ausschließlich aufdie Daten konzentrieren.

Die Mitarbeiter nutzen zwar Daten, erfüllen aber in erster Linie Aufgaben. Man könnte an die-ser Stelle einwenden, dass dieses Argument für den normalen Angestellten, aber nicht für jeneMitarbeiter gilt, die nur Daten von einem Formular ablesen und in den Rechner eingeben: de-

4.10 Gutes Design hat eine menschliche Seite 55

ren Aufgabe ist sehr datenorientiert. Diese Darstellung entspricht durchaus der Realität. Aberist dies eine Konsequenz der Arbeit, die tatsächlich auszuführen ist, oder ein Symptom für dasDesign der Computeranwendungen? Menschen als Eingabegeräte zu benutzen, insbesonderewenn es sich um umfangreiche Datenmengen handelt, die formatiert sind und nur wenige Va-rianten aufweisen (wie bei Formularen), ist teuer und überholt – und eine entwürdigendeForm der Datengewinnung.

Das mag philosophisch und idealistisch klingen, hat aber konkrete Auswirkungen auf das An-wendungsdesign. Menschen nutzen Daten, erledigen aber Aufgaben. Und die Aufgaben wer-den meistens nicht vollständig und auf einmal erledigt. Die Mitarbeiter erledigen gleichzeitigverschiedene Aufgaben, die alle parallel ausgeführt werden.

Lassen sich Designer beim Analysieren und Programmieren einer Anwendung von dieser Ideeleiten, ändert sich auch die Zielsetzung signifikant. Warum waren die windowsbasierten Um-gebungen so erfolgreich? Weil sie es dem Anwender ermöglichen, schnell zwischen den Auf-gaben 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 win-dowsbasierte Umgebung kommt damit dem tatsächlichen Denken und Handeln der Men-schen sehr viel näher als alle bisherigen Ansätze. Diese Lektion sollte nicht in Vergessenheit ge-raten, sondern Grundlage für alle weiteren Überlegungen sein.

Das Verständnis der Aufgaben, die von Anwendungen zu erledigen sind, geht weit über dasIdentifizieren und Normalisieren der Datenelemente, den Aufbau von Bildschirmen, Pro-grammen und Reports hinaus. Es bedeutet, dass man tatsächlich weiß, was der Anwendermacht und wie seine Aufgaben aussehen. Infolgedessen sollte sich die Anwendung an diesenAnforderungen orientieren, und nicht nur die damit verbundenen Daten entgegennehmen.Orientiert man sich nur an den Daten, unterstützt das daraus resultierende Design nicht un-bedingt 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 dannkönnen Sie die Analyse des Unternehmens aus einer neuen Perspektive angehen.

Der erste Schritt im Analyseprozess ist, die eigentliche Aufgabe zu verstehen. Was machen dieLeute in dieser Gruppe eigentlich? Welches Produkt oder welchen Service bieten sie an? Dasmag 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. Er-staunlich viele Firmen, vom Gesundheitswesen über Banken, das Transportwesen bis hin zuProduzenten nahmen an, sie seien im Datenverarbeitungsgeschäft. Denn im Prinzip geben sieDaten ein, verarbeiteten sie und stellen über diese Daten Berichte zusammen. Diese Vorstel-lung ist nur ein weiteres Symptom für die Datenorientierung, die unser Systemdesign in derVergangenheit 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 Kata-strophe endete.

Deshalb ist es wichtig, mit einer gewissen Naivität und Skepsis an Geschäftsanwendungen he-ranzugehen: Sie werden oft falsche Vorstellungen über das angebliche Geschäftsziel über denHaufen werfen müssen, um herausfinden zu können, worin es tatsächlich besteht. Das ist einheilsamer, aber manchmal auch schwieriger Prozess.


Es ist genauso wichtig, dass sich Geschäftsleute zu SQL-Anwendern entwickeln und die Grund-lagen des relationalen Modells verstehen, wie dass Servicedesigner begreifen, welche Aufgabenzur Bereitstellung eines bestimmten Dienstes oder Produkts wirklich notwendig sind. Erst einProjektteam, in dem Anwender mit erworbenen Kenntnissen über SQL und das relationale Mo-dell – beispielsweise durch Lektüre dieses Buchs – mit den Designern zusammenarbeiten, die dieAnforderungen der Anwender berücksichtigen und den Wert einer aufgaben- und sprachorien-tierten Umgebung kennen, kann außerordentlich gut funktionierende Systeme aufbauen.

Ein Ansatz in diesem Prozess besteht darin, zwei konvergierende Dokumente zu erstellen: ei-nes für die Aufgaben und eines für die Daten. Beim Ausarbeiten des Aufgabendokuments wirdgleichzeitig das notwendige Wissen für die Anwendung erarbeitet. Das Datendokument hilftbei der Implementierung und stellt sicher, dass gewisse Details und Regeln berücksichtigt wer-den. 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 erstel-len. In diesem Papier werden die Aufgaben von oben nach unten aufgeführt. Das beginnt mitder grundsätzlichen Beschreibung des Unternehmensziels. Diese Aussage sollte aus einem ein-fachen Aussagesatz von drei bis zehn Wörtern bestehen, im Aktiv formuliert sein, ohne Kom-mas 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 Consultingleistungenin den verschiedenen Bereichen des Gesundheitswesens und diversen anderen Branchen.“

Die Versuchung mag groß sein, jedes kleine Detail hervorzuheben und in diesen ersten Satzauch noch seine Träume zu projizieren. Lassen Sie das. Das Reduzieren von deskriptiven Ex-zessen auf einen einfachen Satz hat eine befreiende Wirkung. Wenn Sie die Aufgabe Ihres Un-ternehmens nicht mit zehn einfachen Wörtern beschreiben können, haben Sie die Kernaufga-be noch nicht verstanden.

Aber als Anwendungsdesigner ist es nicht allein Ihre Aufgabe, diesen Satz zu formulieren. Dassollte gemeinsam mit den Endanwendern geschehen, und ist der erste Schritt in Richtung Do-kumentation. Dieser Prozess gibt Ihnen die Möglichkeit darüber nachzudenken, was die Fir-ma macht und wie diese Aufgabe ausgeführt wird. Dieser Prozess ist auch für die Firma selbstsehr hilfreich, und zwar unabhängig davon, ob eine Anwendung erstellt werden soll. Sie wer-den auf viele Aufgaben, Teilaufgaben, Prozeduren und Regeln kommen, die sich entweder alsbedeutungslos herausstellen oder nur selten gebraucht werden. Bei diesen Artefakten handeltes sich in der Regel um Problemlösungen aus der Vergangenheit oder um Informationen fürManager, die schon lange nicht mehr zum Unternehmen gehören.

Witzbolde haben vorgeschlagen, einfach keine Berichte mehr zu verfassen und zu warten, obes ü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 57

Bitten Sie den Anwender, seine Aufgabe ausführlich zu beschreiben und für jeden Schritt eineBegründung abzugeben. Ist die Argumentation schwach, wie etwa „So haben wir es schon im-mer gemacht“, oder „Ich glaube, das braucht man noch woanders“, sollten bei Ihnen die Sig-nallampen angehen. Sagen Sie einfach, Sie hätten die Ausführungen nicht verstanden und bit-ten 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önnenLeute beantworten, die sich in der Materie besser auskennen, andere Fragen müssen mit denVorgesetzten besprochen werden, und manche Aufgaben werden sich als völlig überflüssig he-rausstellen. Ein Vorteil eines guten Analyseprozesses ist die Verbesserung von bestehenden Pro-zeduren, unabhängig von der Implementierung einer neuen Computeranwendung.

Das allgemeine Format des AufgabendokumentsDas 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 beschreiben-der Absatz, der kurz und präzise zu formulieren ist. Wichtige Aufgaben nummeriert man übli-cherweise 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 über-geordnete Aufgabe wird bis zur Ebene der atomischen Aufgaben aufgelöst – Aufgaben, für die eskeine weitere Untergliederung gibt, und die sich entweder vollständig ausführen lassen oderkomplett gelöscht werden. Atomische Aufgaben bleiben nie halb erledigt.

Das Schreiben eines Schecks ist eine atomische Aufgabe, das Ausfüllen der Eurosumme hinge-gen nicht. Telefonischer Kundendienst zu Repräsentationszwecken ist keine atomische Aufga-be, das Beantworten des Anrufs und die Ausführung einer Kundenanfrage hingegen ist ato-misch. 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 dieNummerierung (die nur die Hierarchie der Aufgaben widerspiegelt), sondern die Auflösungauf der atomischen Ebene. Die atomischen Aufgaben sind die grundlegenden Bausteine desGeschäfts. Zwei Aufgaben können auch dann atomisch sein, wenn eine zufällig von der ande-ren abhängig ist. Das gilt allerdings nur dann, wenn sich beide Aufgaben unabhängig vonein-ander erledigen lassen. Hängen zwei Aufgaben voneinander ab, sind sie nicht atomisch – dietatsächliche atomische Aufgabe besteht dann aus beiden.

Sie werden schnell feststellen, dass sich viele Aufgaben nicht so einfach in eine der wichtigenKategorien einordnen lassen, sondern mehrere Aufgaben der Ebene Null umfassen und so ein„Netzwerk“ bilden. Diese Situation resultiert fast immer aus einer unsauberen Definition derwichtigen Aufgaben, oder einer ungenügenden Atomisierung auf den unteren Ebenen. DasZiel ist, jede Aufgabe in ein konzeptionelles „Objekt“ umzuwandeln, mit einer genau definier-ten Vorstellung dessen, was es tun soll (dem Ziel), und welche Ressourcen (Daten, Berechnun-gen, Materialien etc.) es für die Ausführung benötigt.


Einsichten aus dem AufgabendokumentAus dem Aufgabendokument ergeben sich verschiedene Konsequenzen. Erstens, da sich dasDokument weniger an den Daten als an den Aufgaben orientiert, wird sich wahrscheinlich derAufbau der Anwenderbildschirme wesentlich verändern. Die Ergebnisse dieses Dokumentsbeeinflussen die Art und Weise, wie die Daten erfasst und dargestellt werden, wie die Hilfe im-plementiert 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 Anwen-dungen vonseiten des Benutzers keine besonderen Aktionen notwendig sind.

Zweitens kann die Kategorisierung der wichtigsten Aufgaben nach dem Aufdecken von Kon-flikten geändert werden. Dies hat wiederum Einfluss darauf, wie die Designer und die Benut-zer die Geschäftsabläufe verstehen.

Drittens kann sich vielleicht sogar der Kernsatz des Dokuments ändern. Das Aufbereiten einesUnternehmens und dessen Zerlegung in kleine, atomare Aufgaben-„Objekte“ führt zum Aus-sondern von Artefakten, falschen Konzeptionen und nutzlosen Abhängigkeiten, die das Un-ternehmen lange Zeit unnötig belastet haben.

Das ist kein ganz schmerzloser Prozess, allerdings werden die Vorteile hinsichtlich des Selbst-verständnisses des Unternehmens und der Automatisierung der Aufgaben üblicherweise über-wiegen.

4.11 Die DatenIm Zusammenhang mit der Zerlegung und Beschreibung der Aufgaben werden im Aufgaben-dokument die notwendigen Ressourcen beschrieben, insbesondere hinsichtlich der benötigtenDaten. Das geschieht für jede einzelne Aufgabe, und die benötigten Daten werden danach indas Datendokument aufgenommen. Dieser Ansatz unterscheidet sich konzeptionell von derklassischen Betrachtung der Daten. Denn Sie stellen nicht einfach die aktuell genutzten Bild-schirme und Formulare der einzelnen Aufgaben zusammen, und führen die dort enthaltenenElemente auf. Der Fehler dieses Ansatzes liegt in unserer Tendenz – auch wenn wir das nichtgerne 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üh-rung der entsprechenden Aufgabe wirklich notwendig sind, und weniger darauf achten, wel-che 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 bestehen-den Formularen oder Bildschirmen abgeleitet wird, erzwingt das eine Überprüfung des eigent-lichen Zwecks der Aufgabe und der tatsächlichen Anforderungen bezüglich der Daten. Wenndie Person, die die Aufgabe ausführt, den Zweck der verwendeten Daten nicht kennt, wird dasElement auf die Liste mit den klärungsbedürftigen Dingen gesetzt. Im Laufe dieses Prozessesentledigt man sich so einer Menge überfälliger Daten.

Wurden die Datenelemente identifiziert, müssen sie sorgfältig untersucht werden. Numeri-sche und Buchstabencodes sind grundsätzlich suspekt. Sie verstecken die tatsächlichen Infor-mationen hinter wenig intuitiven und bedeutungslosen Symbolen. Es gab Zeiten, in denen dieCodes einfach und kurz sein mussten, oder wegen des Datenvolumens notwendig waren. Aberin Ihrem endgültigen Design sollten solche Fälle selten und offensichtlich sein. Ist das nicht derFall, haben Sie Ihr eigentliches Ziel verfehlt.

4.11 Die Daten 59

Bei der Untersuchung der bestehenden Datenelemente sollte den Codes besondere Beachtunggeschenkt und ihre Notwendigkeit jeweils hinterfragt werden. Für die weitere Verwendung ei-nes Codes muss es gute und einleuchtende Gründe geben. Die Umwandlung des Codes in dienormale Sprache ist zwar relativ einfach, bedarf allerdings der Mitwirkung aller Beteiligten. DieCodes werden zunächst nach Datenelementen sortiert und mit der entsprechenden Bedeutungin eine Liste aufgenommen. Diese Liste wird von den Anwendern und Designern unter die Lupegenommen, und unterschiedliche Vorschläge für die Umbenennung können diskutiert und ab-gewogen werden.

Im Zuge dieser Diskussion sollten sich Designer und Anwender auf die Namen der Datenele-mente einigen. Da diese Elemente in der Datenbank zu Spaltennamen werden und auch in denAbfragen regelmäßig zum Einsatz kommen, sollten die Namen beschreibend sein (ungewöhn-liche Abkürzungen sind nach Möglichkeit zu vermeiden) und im Singular stehen. Aufgrundder engen Beziehung zwischen den Spaltennamen und den dort enthaltenen Daten sollten bei-de gleichzeitig definiert werden. Die sorgfältige Auswahl eines Spaltennamens erleichtert dasErkennen der neuen Inhalte.

Alle Datenelemente, die keine Codes sind, sind genau zu analysieren. Bis zu diesem Punkt ha-ben Sie gute Gründe anzunehmen, dass alle identifizierten Datenelemente für die Aufgabenwichtig sind, wobei die Daten nicht unbedingt gut organisiert sein müssen. Tatsächlich kön-nen in den bestehenden Programmen verschiedene Elemente vermischt sein, woraus sich dieNotwendigkeit für die Zerlegung der Elemente ergeben kann. Namen, Adressen und Telefon-nummern sind gängige Beispiele, wobei jede Anwendung ihre Besonderheit hat.

So sind beispielsweise in der AUTHOR-Tabelle die Vor- und Nachnamen miteinander ver-mischt. Beachten Sie, dass die AuthorName-Spalte beide Werte enthält, obwohl sich die Datenin der dritten Normalform befinden. Das kann bei der Implementierung einer AnwendungProbleme 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 vorzu-bereiten, sollte die Name-Spalte in zwei neue Kategorien zerlegt werden: LastName und First-Name. Derselbe Kategorisierungsprozess wird bei der Rationalisierung anderer Datenelemen-te 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 istdurchaus möglich, dass man dabei zu weit geht und Kategorien weiter aufteilt, obwohl dieneuen Elemente in diesem Status eigentlich keinen zusätzlichen Nutzen haben. Die Zerlegungder 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 be-nennen und die in den Spalten vorhandenen Daten untersuchen. Textdaten, die sich in einedefinierbare Anzahl von Werten aufteilen lassen, sollte man hinsichtlich der Benennung über-prü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 eszu diesem Thema eine Reihe ausgezeichneter Bücher und verschiedene Analyse- und Design-tools gibt, möchten wir keine besondere Methode empfehlen.

Jede atomische Transaktion sollte modelliert und mit den entsprechenden Aufgabennum-mern versehen werden. In dem Modell werden auch die Tabellennamen, die Primär- und


Fremdschlüssel sowie die wichtigsten Spalten aufgeführt. Jede normalisierte Beziehung (d. h.jede Verbindungslinie) sollte einen aussagefähigen Namen erhalten. Darüber hinaus solltenfür jede Tabelle die geschätzte Zeilenzahl und die Transaktionsraten aufgeführt sein. Zu jedemModell 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 kom-binierte Dokument ist das Unternehmens- oder Geschäftsmodell, und wird von den Anwen-dungsdesignern 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 Vor-stellung vom Unternehmen, seinen Aufgaben und Daten besitzen. Nach der Korrektur undVerabschiedung des Modells beginnt der Prozess der Synthetisierung von Aufgaben- und Da-tenmodellen in ein übergreifendes Unternehmensmodell. Bei diesem Prozess werden die üb-lichen Datenelemente zwischen den Aufgaben sortiert, die Normalisierung wird im großenMaßstab durchgeführt, und für alle Elemente werden konsistente und definitive Namen ver-geben.

Bei großen Anwendungen kann das durchaus eine umfangreiche Zeichnung werden. Dazukommen noch die Dokumentationen mit den Aufgaben, den Datenmodellen (mit den korrek-ten Elementnamen, Datentypen und Inhalten) und für jede Tabelle eine Liste mit den Spalten-namen, Datentypen und den jeweiligen Inhalten. Eine letzte Prüfung gilt den Zugriffspfadenauf die Daten im vollständigen Unternehmensmodell. So kann man feststellen, ob die für dieTransaktionen benötigten Daten (zur Selektion oder für Einfügeoperationen) tatsächlich zurVerfügung stehen. Damit wird sichergestellt, dass bei keinem Prozess Daten fehlen, die für diereferenzielle Integrität des Modells unabdingbar sind.

Mit Ausnahme der Namensfindung für die verschiedenen Tabellen, Spalten und die üblichenWerte 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 Kompo-nenten zu fördern.

4.11.4 Dateneingabe

Das Bildschirmdesign wird nicht vom Unternehmensmodell abgeleitet, da es sich nicht auf dieTabellen, sondern auf die Aufgaben konzentriert. Deshalb werden die Bildschirme so angelegt,dass sie die Aufgabenorientierung unterstützten und das Wechseln zwischen den Teilaufgabenermöglichen. Praktisch gesehen ist das oftmals mit der Zuordnung zu Tabellen verbunden, diesich entweder auf Werte abfragen lassen oder beim Zugriff auf die Primärtabelle aktualisiertwerden.

Es kann aber auch vorkommen, dass keine Haupttabelle vorhanden ist, und es stattdessen eineVielzahl von zusammengehörigen Tabellen gibt, die zur Unterstützung der Aufgabe entwederDaten zur Verfügung stellen oder empfangen. Diese Bildschirme sehen ein wenig anders aus,

4.11 Die Daten 61

und ihr Verhalten weicht auch von den typischen tabellenorientierten Bildschirmen ab, die fürdie meisten Anwendungen programmiert werden. Dennoch verbessern sie die Effektivität derBenutzer ganz erheblich und erhöhen damit den Beitrag zum Unternehmenserfolg, was auchSinn und Zweck dieses Ansatzes ist.

Die Interaktion des Benutzers mit der Maschine ist wichtig: Die Eingabe- und Abfragebild-schirme sollten konsequent aufgabenorientiert und selbsterklärend sein. Die Verwendung vonSymbolen und grafischen Schnittstellen spielt natürlich auch eine wichtige Rolle. Die Bild-schirme müssen wiedergeben, wie die Arbeit tatsächlich erledigt wird, und in der branchenüb-lichen 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 Spra-che ist leicht erlernbar und ermöglicht dem Endanwender das Erstellen und Ausführen von Adhoc-Abfragen. Diese Abfragen gehören üblicherweise nicht zu den Standardabfragen, die zu-sammen mit dem Anwendungscode zur Verfügung gestellt werden.

Mit SQL*Plus (und anderen Reporting-Tools) erhalten die Anwender eine beispiellose Kon-trolle über ihre Daten. Davon profitieren sowohl Entwickler als auch Anwender: Die Benutzer,weil sie Reports erstellen, Daten analysieren, die Abfragen verändern und innerhalb wenigerMinuten erneut ausführen können. Und die Entwickler, weil sie nicht dauernd mit irgendwel-chen Anforderungen für neue Reports behelligt werden.

Die Benutzer erhalten das Recht, ihre Daten anzusehen, zu analysieren und in einer Geschwin-digkeit und Genauigkeit zu antworten, die vor einigen Jahren noch unvorstellbar war. DieseProduktivitätssteigerung lässt sich noch verbessern, wenn die Tabellen, Spalten und Daten-werte in der jeweiligen Landessprache vorliegen; denn werden die Benennungskonventionennicht eingehalten, und verwässern bedeutungslose Codes und Abkürzungen das Design, führtdas zu einer geringeren Produktivität. Die Zeit, die man in das Design und die konsistente undbeschreibende 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 Endanwen-der die Rechner negativ beeinträchtigen könnte, auf denen diese Werkzeuge laufen. Sie be-fürchten, dass Benutzer ineffiziente Abfragen erstellen, die zu viele CPU-Zyklen benötigenund damit unnötig Ressourcen vergeuden, was zu einer Verlängerung der Antwortzeiten füralle Benutzer führt. Die Erfahrung zeigt, dass diese Aussage im Normalfall nicht richtig ist. DieBenutzer wissen bald, welche Abfragen schnell laufen und welche nicht. Außerdem lassen sichmithilfe der heute verfügbaren Werkzeuge die Abfragezeiten abschätzen, und der Zugang fürgroße Abfragen kann (nach Benutzer, Tageszeit oder beidem) eingeschränkt werden. Das wie-derum bringt die Anwender dazu, sich die notwendigen Qualifikationen anzueignen, und dieAbfragen so schnell und effizient wie möglich zu gestalten. Mit diesen Qualifikationen verrin-gert sich auch die Belastung der Maschinen. Verschieben Sie eine Belastung vom Menschenauf die Maschine, sparen Sie praktisch immer Geld.

Das eigentliche Ziel des Designs ist, die Anforderungen an das Geschäft und die Anwender zuklären und zufriedenzustellen. Den Vorzug sollten stets die Dinge bekommen, die die Anwen-dung verständlicher und besser handhabbar machen. Das kann zulasten von CPU oder Plat-tenplatz gehen, was sich aber auszahlt. Kontraproduktiv ist, wenn sich dadurch die interne


Komplexität so erhöht, dass sich Wartungsarbeiten und Änderungen nur schwierig und lang-sam ausführen lassen.

4.12 Das Normalisieren von ObjektnamenBei der Benennung von Objekten geht es darum, aussagefähige, leicht verständliche und be-schreibende Namen zu finden, Abkürzungen zu vermeiden und die Unterstriche konsistentoder überhaupt nicht zu verwenden. In einer großen Anwendung bestehen die Namen vonTabellen, Spalten und Daten oft aus mehreren Wörtern (wie ReversedSuspenseAccount oderLast_GL_Close_Date). Das Ziel dieser Benennungsmethode ist die einfache Handhabung derDaten: Die Namen müssen gut zu merken sein und Regeln folgen, die man leicht verstehenund anwenden kann. Auf den folgenden Seiten wird ein eher rigoroser Ansatz vorgestellt, derder 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 Ta-belleneigentümer bis hin zu Tabellen, Spalten und Datenwerten. In sehr großen Systemenkö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, aberdie Ausführungen gelten für diese Elemente ebenfalls.

In dieser Hierarchie ist jede Ebene in der darüber liegenden Ebene definiert, und auf jeder Ebe-ne sollten nur ebenenspezifisch gültige Namen vergeben werden, d. h. keine Namen aus ande-ren Ebenen aufgenommen werden. Beispielsweise darf eine Tabelle keinesfalls zwei Spaltennamens „Name“ enthalten, und der Account namens George kann nicht zwei Tabellen na-mens AUTHOR besitzen.

Es gibt keine Anforderung, die besagt, dass die Namen von Georges Tabellen innerhalb dergesamten Datenbank eindeutig sein müssen. Auch andere Eigentümer können eine AU-THOR-Tabelle besitzen. Selbst wenn George auf diese Tabellen innerhalb der gesamten Da-tenbank eindeutig sein müssen. Auch andere Eigentümer können eine AUTHOR-Tabellebesitzen. 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 Geor-ge seine WORKER-Tabelle mit der von Dietrich kombiniert, muss die Name-Spalte in der se-lect-Klausel die vollständige Kennung enthalten: Dietrich.AUTHOR.Name. Es wäre logischinkonsistent, wenn man Georges Namen in die Namen seiner Tabellen einbinden würde (wieGEOAUTHOR, GEO-BOOKSHELF usw.). Damit werden die Namen nur unnötig komplexund führen letztlich zu einer Verletzung der ebenenbezogenen Namensintegrität.

Die Kürze sollte niemals den Vorzug vor der Übersichtlichkeit erhalten. Die Einbindung vonTeilen der Tabellen- in die Spaltennamen ist insofern eine schlechte Technik, als man damitdie logische Idee der Ebenen und die damit verbundene ebenenbezogene Namensintegritätverletzt. Darüber hinaus sind solche Konstruktionen unklar und führen dazu, dass man beifast jeder Abfrage die Spaltennamen überprüfen muss. Die Objektnamen müssen eindeutigsein, wobei peinlich darauf zu achten ist, dass man für das Objekt ausschließlich die Namender entsprechenden Ebene einsetzt.

4.12 Das Normalisieren von Objektnamen 63

Die Unterstützung für abstrakte Datentypen stärkt Ihre Möglichkeiten zur Vergabe von kon-sistenten 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 Datenty-pen 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 einerTabelle, in der eine andere Spalte denselben Namen wie die Fremdschlüsselspalte in der Ur-sprungstabelle besitzt. Eine mögliche Lösung besteht darin, dass bei der Benennung derFremdschlüssel, einschließlich des Tabellennamens in der Ursprungstabelle, als Spaltennamein der lokalen Tabelle mit aufgenommen wird (wie BOOKSHELF.Title als Spaltenname).

Die praktischen Anforderungen zur Lösung von Problemen im Zusammenhang mit gleich be-nannten 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 Namenvermeiden 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 Ob-jektnamen in der Einzahl oder der Mehrzahl gehalten werden sollen. Soll die Tabelle AU-THOR oder AUTHORS, die Spalte Name oder Names heißen?

Zu diesem Problem gibt es zwei hilfreiche Vorgehensweisen. Sehen Sie sich zuerst einige Spal-ten an, die in beinahe jeder Datenbank vorkommen: Name, Adresse, Stadt, Land und Postleit-zahl. Käme es jemandem, außer bei der ersten Spalte, in den Sinn, die Namen in die Mehrzahlzu setzen? Es ist offensichtlich, dass diese Namen den Inhalt einer einzelnen Zeile, d. h. einesDatensatzes beschreiben. Obwohl die relationalen Datenbanken „mengenorientiert“ sind, istdie grundlegende Einheit einer Menge ein Datensatz, und die Inhalte dieses Datensatzes wer-den über Spaltennamen beschrieben, die in der Einzahl gehalten sind. Soll ein Bildschirm, andem die Adresse einer Person eingetragen wird, wie folgt aussehen?


Namen: _______________________________________________________

Adressen: ___________________________________________________

Städte: ____________________________ Länder __ PLZ _____-____

Oder halten Sie die Namen dieser Spalten am Bildschirm im Singular, weil Sie jedes Mal nureinen Namen und eine Adresse eingeben, aber dem Benutzer wird mitgeteilt, dass die Spalten-namen bei Abfragen im Plural verwendet werden müssen? Deshalb ist es einfacher und intui-tiver, 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 nach-zudenken, ob der jeweilige Name im Singular oder im Plural steht. Der Vorteil dieses Ansatzesist einfach und überzeugend. Angenommen, wir möchten alle Objekte zukünftig im Pluralhalten, und damit steht am Ende jedes Objektnamens ein „s“, „e“ oder „en“. Welchen Vorteilbringen diese zusätzlichen Buchstaben am Ende eines Worts? Sind die Namen einfacher zuhandhaben, leichter zu verstehen oder leichter zu merken? Wohl kaum.

Deshalb sieht die beste Lösung wie folgt aus: Alle Objektnamen stehen immer im Singular. Dieeinzige Ausnahme von dieser Regel bilden Begriffe, die im täglichen Sprachgebrauch im Pluralverwendet werden.

4.12.4 In der Kürze ...

Wie bereits erwähnt, sollte die Übersichtlichkeit nicht der Kürze geopfert werden. Wenn aberzwei 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 nachMöglichkeit mehrere Namen vorschlagen, diese entweder von einigen Benutzern oder denEntwicklern bewerten lassen, und aufgrund der gemachten Aussagen den eindeutigsten Na-men auswählen. In einem Projektteam, das sich der Entwicklung von produktiven Anwen-dungen widmet, sollte jeder Mitarbeiter als Grundausstattung einen Thesaurus und ein Wör-terbuch erhalten, und immer wieder daran erinnert werden, wie wichtig eine sorgfältigeBenennung der Objekte ist.

4.12.5 Ein Thesaurus für Objektnamen

Eine relationale Datenbank sollte mit der gleichen Selbstverständlichkeit einen Thesaurus fürdie Objektnamen besitzen wie ein Data Dictionary. Dieser Thesaurus hilft bei der Durchset-zung der firmeninternen Benennungsstandards und sichert bei den verwendeten Abkürzun-gen und den ausgewählten Namen die gewünschte Konsistenz.

Solche Standards können die Verwendung von Unterstrichen in Objektnamen verlangen, wasdas Zerlegen der Namen in Komponenten wesentlich vereinfacht. Gleichzeitig wird damit einStandard für den Einsatz von Unterstrichen erzwungen.

4.13 Intelligente Schlüssel- und Spaltenwerte 65

Falls Sie direkt mit öffentlichen Auftraggebern oder großen Firmen zusammenarbeiten, habendiese vielleicht bereits Standards für die Objektbenennung gesetzt. Die Benennungsstandardsgroßer Unternehmen wurden im Laufe der Zeit Allgemeingut und könnten auch als Grundla-ge für Ihre Standards dienen. Wenn nicht, entwickeln Sie Ihre eigenen Standards, um mit je-nen Basisstandards und den weiteren Richtlinien in diesem Kapitel konsistent zu sein.

4.13 Intelligente Schlüssel- und SpaltenwerteIntelligente Schlüssel heißen so, weil sie komplexe Kombinationen von Informationen enthal-ten. 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 dieseKategorie und kämpfen mit denselben Schwierigkeiten wie andere Codes. Darüber hinaus las-sen sich die Schwierigkeiten, die bei intelligenten oder überladenen Schlüsseln auftreten, auchbei Nicht-Schlüsselspalten feststellen, bei denen mehr als ein Informationselement hinterlegtwurde.

Ein typisches Beispiel für einen überladenen Schlüssel ist die folgende Beschreibung: „Das ers-te 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 Teilhandelt, befindet sich am Ende der Zahl ein „I“. Falls es sich um einen Artikel mit großenStückzahlen (wie Schrauben) handelt, werden nur drei Zahlen für die Katalognummer ver-wendet, und der Code für die Region ist HD.“

Für ein gutes relationales Design müssen die überladenen Schlüssel und Spaltenwerte elimi-niert werden. Die Abhängigkeiten, die auf Teile dieses Schlüssels gesetzt wurden (gewöhnlichFremdschlüssel auf andere Tabellen), stellen beim Verwalten der Struktur ein beträchtlichesRisiko dar. Leider gibt es in vielen Anwendungsbereichen überladene Schlüssel, die über Jahrehinweg verwendet wurden und tief in die Geschäftsaufgaben hineinreichen. Dem sofortigenBeseitigen der überladenen Schlüssel können manchmal praktische Erwägungen im Wege ste-hen, und damit gestaltet sich der Aufbau einer neuen, relationalen Anwendung viel schwieri-ger.

Die Lösung für dieses Problem besteht im Aufbau von neuen Schlüsseln (sowohl Primär- alsauch 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 überladeneSchlüssel wird in einer zusätzlichen, einzelnen Tabellenspalte vorgehalten. Der Zugang istdann nur noch mit historischen Methoden möglich (z. B. bei der Suche nach einer Überein-stimmung innerhalb einer Abfrage), wobei die neu strukturierten Schlüssel die bevorzugte Zu-griffsmethode darstellen sollten. Unter Umständen können die überladenen Schlüssel (undandere überladene Spaltenwerte) auch einfach ausgeNULLt oder aus der Tabelle gelöscht wer-den.

Falls es nicht gelingt, die überladenen Schlüssel und Werte zu eliminieren, kann sich das Ex-trahieren der Daten aus der Datenbank, das Validieren der Werte, das Sicherstellen der Daten-integrität und ein Modifizieren der Struktur extrem schwierig und kostenintensiv gestalten.


4.14 Die EmpfehlungenAlle wichtigen Fragen zum produktiven Design wurden nun diskutiert. Am Ende des Kapitelsmöchten wir sie nochmals zusammenfassen – in Form von „Empfehlungen“. Das sind zwarkeine direkten Handlungsanweisungen, sie sollen Ihnen aber bei Ihren Überlegungen einewichtige Entscheidungshilfe bieten. Auf jeden Fall können Sie von den Erfahrungen andererprofitieren, die vor ähnlichen Problemen standen. Das Ziel ist an dieser Stelle nicht die Be-schreibung des Entwicklungszyklus, sondern eher, jener Entwicklung den Vorzug zu geben,die das „Look and Feel“ entscheidend verändert, und damit auch den Einsatz. Berücksichtigtman diese Ideen, lässt sich die Produktivität und Zufriedenheit der Anwender wesentlich ver-bessern.

Die zehn Empfehlungen für ein benutzerorientiertes Design:

1. Binden Sie die Benutzer ein. Nehmen Sie die Anwender in das Projektteam auf, und ver-mitteln 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, beschrei-bend, 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 Funktio-nen vorangestellt wurde – fehlt es am Design, wird Ihre Applikation stets den Anforderungenhinterherhinken. Planen Sie die Funktionalität, die Performance, die Wiederherstellbarkeit,die Sicherheit und Verfügbarkeit. Planen Sie den Erfolg!

Documents

Oracle Database 11g - Die umfassende Referenz - Hajer ... · PDF fileOracle Database 11g - Die umfassende Referenz von Hans Hajer, Kevin Loney 1. Auflage ... Si e haben die direkte