Mehrbenutzerkontrolle in Nicht-Standard-Datenbanksystemen

184 Pages·1991·9.32 MB·German

by  Ulrich Herrmann (auth.)

Informatik-Fachberichte 265
Herausgeber: W. Brauer
im Auftrag der Gesellschaft fOr Informatik (GI)
Ulrich Herrmann
Mehrbenutzerkontrolle
in Nicht-Standard
Daten ban ksystemen
Springer-Verlag
Berlin Heidelberg New York London
Paris Tokyo Hong Kong Barcelona
Autor
Ulrich Herrmann
IBM Deutschland GmbH, Geschaftsstelle Frankfurt
Industrie und Verkehr
Lyoner Str. 13 a, Postfach 710453, W-6000 Frankfurt 71
CR Subject Classification (1987): H.2.4, H.2.8, H.2.1-3
ISBN-13 :978-3-540-53576-8 e-ISBN-13 :978-3-642-76360-1
001: 10.1007/978-3-642-76360-1
Dieses Werk ist urheberrechtlich geschOtzt. Die dadurch begrOndeten Rechte, insbesondere
die der Obersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Ta
bellen, der Funksendung, der Mikroverfilmung oder derVervielf1lltigung auf anderen Wegen und
der Speicherung in Datenverarbeitungsanlagen, bleiben, bei auch nur auszugsweiser Verwer
tung, vorbehalten. Eine Vervielfilltigung dieses Werkes oder von Teilen dieses Werkes ist auch
im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes
der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung
zul1lssig. Sie ist grunds1ltzlich vergotungspflichtig. Zuwiderhandlungen unterliegen den Straf
bestimmungen des Urheberrechtsgesetzes.
© Springer-Verlag Berlin Heidelberg 1991
2145/3140-543210 -Gedruck1 auf s!\urefreiem Papier
Vorwort
In der vorliegenden Arbeit wird ein Synchronisationsverfahren vorgeschlagen, das den besonderen An
forderungen von Nicht-Standard-Anwendungen an ein Datenbanksystem, wie etwa der Unterstiitzung
komplexer Objekte, langer Transaktionen und benutzerdefinierter Datentypen und Funktionen, Rech
nung tragt. Dariiber hinaus wird aufgezeigt, wie ein soIches Verfahren effizient realisiert werden kann.
Das vorgeschlagene Sperrverfahren, das eine Weiterentwicklung des traditionellen DAG-Sperrprotokolls
darstellt, basiert auf der Verwendung angepaBter Sperrgranulate innerhalb der Hierarchie beliebig
strukturierter komplexer Objekte. Mit Hilfe semantischer Analysen von Anfragen wird vor einer eigent
lichen Anfrageausfilhrung bestimmt, weIche Granulate wahrend der Anfrageausfilhrung in weIchen Modi
gesperrt werden sollen. Diese Vorgehensweise dient u.a. dazu, so viele Sperreskalationen wie moglich
vorwegzunehmen und "dadurch einen hohen Durchsatz eines Datenbanksystems zu erreichen. Beriihrt
eine Anfrage gemeinsame Daten, werden die betroffenen Daten durch das vorgeschlagene Verfahren in
einer Weise gesperrt, die einen hohen Durchsatz bei akzeptablem Aufwand erwarten laBt. Benutzerdefi
nierte Datentypen und Funktionen sind genau wie Indexe in das diskutierte Synchronisationsverfahren
integriert. Weiterhin werden in dieser Arbeit zusatzliche Konsistenzebenen vorgeschlagen, die ein Da
tenbanksystem filr Nicht-Standard-Anwendungen zur Verfilgung stellen sollte, und es wird erlautert, wie
diese Konsistenzebenen intern durch entsprechendes Sperren garantierf werden konnen. Besondere Be
achtung wird dabei einer effizienten Verhinderung von Phantomen geschenkt. Vorschlage zur Freigabe
von Sperren und eine kurze Diskussion spezieller Sperrmodi filr Nicht-Standard-Anwendungen sind
ebenfalls in dieser Arbeit enthalten. Das vorgeschlagene Sperrverfahren wird qualitativ und quantitativ
bewertet.
Nachdem das Sperrverfahren eingefilhrt wurde, wird ausfilhrlich diskutiert, wie ein soIches Verfahren
implementiert und in die Architektur eines Datenbanksystems filr Nicht-Standard-Anwendungen inte
griert werden kann. Eine Zusammenfassung, eine Abgrenzung zu anderen Arbeiten und ein Ausblick
schlieBen das Buch abo
Die vorliegende Arbeit ging aus einer Kooperation zwischen der Abteilung "Advanced Information
Management" (AIM) des Wissenschaftlichen Zentrums Heidelberg der IBM Deutschland GmbH und
dem Lehrstuhl "Praktische Informatik I" des Fachbereichs "Mathematik und Informatik" der FernUni
versitat Hagen hervor. 1m Rahmen dieser Kooperation war ich als Wissenschaftlicher Mitarbeiter an der
FernUniversitat Hagen angestellt, hatte meinen standigen Arbeitsplatz jedoch in der Abteilung "AIM"
in Heidelberg.
Mein besonderer Dank gilt der IBM Deutschland GmbH, die durch die Gewahrung eines Promotionssti
pendiums die vorliegende Arbeit iiberhaupt erst ermoglicht hat, und Herrn Prof Dr. G. Schlageter, der
durch zahlreiche wertvolle Hinweise und Anregungen wesentlich zum Gelingen der Arbeit seines "Fern
doktoranden" beigetragen hat. Fiir die Ubernahme des Korreferats mochte ich Herrn Prof Dr. R. H.
Gi1ting danken. Dariiber hinaus bin ich allen Mitarbeitern der Abteilung "AIM" filr die stets gute Zu
sammenarbeit zu groBem Dank verpflichtet. Herauszuheben sind dabei Herr Dr. P. Dadam, der die ent
scheidenden Im{5ulse filr die Anfertigung dieser Arbeit gab, und Herr Dr. K. Ki1spert, der jederzeit bereit
VI
war, tiber meine Arbeit zu diskutieren, und der diese Dissertation und andere, vorausgegangene Arbeiten
kritisch und sehr sorgfaltig durchgesehen hat. AuBerdem hat Herr Dr. Ktispert die Aufgabe des Dritt
gutachters tibernommen.
An dieser Stelle m6chte ich mich auch bei meinen Eltern herzlich bedanken, die mir die Schulbildung,
das Studium und damit diese Dissertation erm6glicht haben.
Heidelberg, im Oktober 1990 Ulrich Herrmann
Inhaltsverzeichnis
1.0 Einleitung . . . . . . .
2.0 Grundlagen der Synchronisation. 5
2.1 Verwendete Terminologie .... 5
2.2 Existierende Synchronisationsverfahren . 8
2.2.1 Pessimistische Verfahren 8
2.2.2 Optimistische Verfahren 14
2.2.3 Sonstige Verfahren . . . 15
3.0 Anforderungen von Nicht-Standard-Anwendungen an ein Datenbanksystem 17
3.1 Workstation-Server-Umgebungen mit langen Transaktionen 17
3.2 Modellierung und Implementierung komplexer Objekte . 18
3.2.1 Modellierungsaspekte komplexer Objekte ... 18
3.2.2 Implementierungsaspekte komplexer Objekte 25
3.3 Indexe in komplexen Relationen . 30
3.4 Benutzerdefrnierte Erweiterungen . . . . . . . 34
4.0 Traditionelle Synchronisationsverfahren in Nicht-Standard-Anwendungen 39
4.1 Anwendung traditioneller Synchronisationsverfahren 39
4.1.1 Pessimistische Verfahren 39
4.1.2 Optimistische Verfahren 41
4.1.3 Sonstige Verfahren .. . 42
4.1.4 SchluBfolgerungen .. . 42
4.2 Probleme mit traditionellen Sperrverfahren . 42
4.2.1 Granulatorientierte Probleme ... 43
4.2.2 Protokollorientierte Probleme . . . 44
4.2.3 Autorisierungsorientierte Probleme 45
4.2.4 Indexorientierte Probleme . . . . . 45
4.2.5 Konsistenzorientierte Probleme .. 47
4.2.6 Erweiterbarkeitsorientierte Probleme 50
4.2.7 Sperranforderungs- und -freigabeorientierte Probleme . 51
5.0 Spezielle Sperrtechniken rur Nicht-Standard-Anwendungen . 55
5.1 Sperrtechnik rur komplexe Objekte . . . . . . . . . 55
5.1.1 Disjunkte, nicht-rekursive komplexe Objekte . . . . 56
5.1.2 Nicht-disjunkte, nicht-rekursive komplexe Objekte 69
5.1.3 Disjunkte, rekursive komplexe Objekte . . . . . . . 79
5.1.4 Nicht-disjunkte, rekursive komplexe Objekte . . . . 84
5.2 Synchronisation von benutzerdefinierten Erweiterungen 88
5.2.1 Benutzerdefrnierte Datentypen . . . . . . . . . . . . . . . 89
VIII
5.2.2 Benutzerdefinierte Funktionen . . . . . . . . . 89
5.3 Integration von Indexen in die Synchronisation 94
5.3.1 Allgemeiner und objektspezifischer Sperrgraph . 94
5.3.2 Regeln flir das explizite Anfordern von Sperren in Indexen 95
5.3.3 Bestimmung von "optimalen" Sperranforderungen .... . 98
5.3.4 Anfragespezifischer Sperrgraph ............. . . 102
5.4 Unterstlitzung konsistenter Sichten auf Daten durch die Synchronisation 103
5.4.1 Auswertung von WHERE-Bedingungen ... . 103
5.4.2 Verhinderung von Phantomen .......... . 104
5.4.3 Unterstiltzung verschiedener Konsistenzebenen . III
5.4.4 Bestimmung von" optimalen" Sperranforderungen 116
5.4.5 Anfragespezifischer Sperrgraph . . . . . . . . 1I8
5.5 Freigabe von Sperren . . . . . . . . . . . . . . 1I9
5.6 Sperrmodi flir Nicht-Standard-Anwendungen 125
5.7 Diskussion implementierungsnaher Aspekte . 127
5.7.1 Beziehung zwischen logischen Sperrgranulaten und Speicherungseinheiten 128
5.7.2 Sperren in Speicherungsstrukturen .... . 131
5.7.3 Kurzzeitsperren auf Seiten und in Indexen ........... . 134
5.7.4 Betrachtung von Recovery-Gesichtspunkten . . . . . . . . . . . 135
5.7.5 Integrierte versus aufgesetzte Unterstlitzung komplexer Objekte 136
5.8 Bewertung des vorgeschlagenen Sperrverfahrens 137
5.8.1 Qualitative Bewertung . . . . . . . . . . . . . . . . . . . . . . . 137
5.8.2 Quantitative Bewertung ..................... . 141
5.8.3 Untersuchungen im Hinblick auf die Durchflihrung von Simulationen . 146
6.0 Synchronisationskomponente in der Architektur eines Nicht-Standard-Datenbanksystems 149
6.1 Basisarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
6.2 Integration einer Synchronisationskomponente in die Basisarchitektur ..... . 151
6.2.1 Synchronisationskomponente flir disjunkte komplexe Objekte . . . . . . . . . . . 151
6.2.2 Synchronisationskomponente flir disjunkte und nicht-disjunkte komplexe Objekte 155
7.0 Zusammenfassung, Abgrenzung und Ausblick 161
Literaturverzeichnis 167
Index ....... . 179
1.0 Einleitung
Herkorrunliche Datenbanksysteme sind in erster Linie flir den Einsatz im administrativ-betriebswirt
schaftlichen Bereich, d.h. in sogenannten traditionellen oder Standard-Anwendungen, ausgelegt. In den
letzten lahren geht die Entwicklung im Datenbankbereich jedoch immer mehr dahin, daB Datenbank
systeme auch sogenannte Nicht-Standard-Anwendungen wie CAD/CAM, Robotik, KUnstliche Intelligenz
usw. unterstUtzen sollen [BIPi85, ScSc87, Ditt88, Lutt88). Datenbanksysteme, die auf die BedUrfnisse von
Nicht-Standard-Anwendungen zugeschnitten sind, werden im folgenden als Nicht-Standard-Datenbank
systeme bezeichnet. Die Benutzung von Datenbanksystemen im Bereich der Nicht-Standard-Anwendun
gen flihrt zu zahlreichen neuen Anforderungen. Zu den wichtigsten zahlen die Verwaltung (beliebig
strukturierter) kompLexer Objekte, die Untersttitzung von Workstation-Server-Umgebungen mit Langen
Transaktionen und die UnterstUtzung benutzerdejinierter Datentypen und Funktionen [HaLo82, LoP183,
BaBu84, Lori85, KDG87, HHMM88, Linn88, KUGU89).
Das Konzept der kompLexen Objekte erlaubt es Benutzern eines Datenbanksystems, viele "flache", d.h.
einfach strukturierte Objekte (meist als Tupel' bezeichnet) als eine Einheit mit einer bestimmten Struk
tur zu betrachten und als Ganzes zu bearbeiten. Verschiedene komplexe Objekte mUssen nicht notwen
digerweise disjunkt sein. Gerade in Nicht-Standard-Anwendungen ist es sehr vorteilhaft, wenn verschie
dene komplexe Objekte gemeinsame Daten besitzen konnen. Beispiele flir soIche Falle sind etwa Bau
teilbibliotheken oder Normteilkataloge. Weiterhin ist es moglich, daB komplexe Objekte rekursiv defi
niert sind. Diese rekursiven komplexen Objekte sind insbesondere flir die Modellierung von StUcklisten
problemen geeignet. Durch das Konzept der komplexen Objekte und deren Realisierung im Daten
banksystem wird die Verarbeitung der flir Nicht-Standard-Anwendungen typischen Objekte (komplex
strukturierte Konstruktionsdaten im CAD/CAM-Bereich usw.) aus Benutzersicht wesentlich vereinfacht
und auch systemseitig beschleunigt, da sich dem Datenbanksystem interne Optimierungsmoglichkeiten
verschiedenster Art eroffnen [BaBu84, Hard88).
Die Diskussion in der vorliegenden Arbeit basiert auf einem Datenmodell, das alle (vier) Kombinationen
von disjunkten/nicht-disjunkten sowie rekursiven/nicht-rekursiven komplexen Objekten untersttitzt. Bei
spiele flir soIche Datenmodelle sind das erweiterte NP-Datenmodell [PiAn86, ScSc86) mit einem zu
satzlichen Konzept flir Referenzen [PiDa89), das MolekUl-Atom-Datenmodell (MAD) von Prima
[HMMS87) und das Design-Object-Data-Model (DODM) von Damokles [Rehm88). 1m folgenden wird
zur Beschreibung komplexer Objekte das erweiterte NP-Datenmodell mit einem zusiilzlichen Referen
zenkonzepl verwendet.
Herkorrunliche Datenbanksysteme verfligen Uber eine bestimmte Menge von (atomaren) Dalentypen, wie
z.B. "character", und eingebauten Funklionen, wie z.B. "MAX" zur Bestimmung maximaler Attributwerte.
AIle Auspragungen von Datentypen, die ein Datenbanksystem nicht direkt untersttitzt, konnen in einer
Datenbank nur als "Bytestring" abgelegt werden. Zur Interpretation soIcher Bytestrings mUssen Benutzer
spezielle Anwendungsprogramme schreiben. Analog dazu mUssen Benutzer Funktionen, die nicht von
einem Datenbanksystem direkt zur Verfligung gestellt werden, selbst mit u.U. hohem Aufwand imple
mentieren. Weder Erweiterungen in Form von Bytestrings noch in Form von Anwendungsprogrammen
stellen integrale Bestandteile eines Datenmodells und der zugehorigen Anfragesprache dar. In Nicht-
2
Standard-Anwendungen haben beide Arten der Erweiterung jedoch eine groBe praktische Bedeutung:
Ingenieure mochten beispielsweise Matrizen in einer Datenbank ablegen und verschiedene Matrizen auf
einfache Weise miteinander multiplizieren konnen. Ein Nicht-Standard-Datenbanksystem sollte also
Benutzern die Moglichkeit bieten, selbst ohne groBen Aufwand neue Datentypen und Funktionen defi
nieren zu konnen (benutzerdeJinierte Datentypen und Funktionen).
Transaktionen stellen im administrativ-betriebswirtschaftlichen Bereich die Einheit fUr die Konsistenzer
haltung der Daten dar. In diesem Bereich sind Transaktionen Ld.R. kurz, d.h. ihre Dauer liegt in der
GroBenordnung von Sekunden oder maximal Minuten. Transaktionen in Nicht-Standard-Anwendungen,
z.B. bei der Konstruktion von Bauteilen oder dem DesignprozeB von Chips, konnen dagegen u.U. Tage
oder Wochen dauem. Diese Transaktionen werden lange Transaktionen genannt [KLMP84, KSUW85].
Sie mOssen u.a. SystemzusammenbrOche aller Art und Systemabschaltungen Oberleben. Das klassische
Transaktionskonzept stoBt in diesen Umgebungen an seine Grenzen [HaRe83a]. Besser geeignet als der
Begriff der klassischen Transaktion ist der des Benutzers oder der Conversational Transaction [LoPI83].
Falls es sich urn klassische Transaktionen in einer zentralen Datenbank handelt, wird in der vorliegenden
Arbeit von kurzen Transaktionen gesprochen, und falls Benutzer auf Arbeitsplatzrechnem gemeint sind,
von langen Transaktionen. Auch im Bereich der Nicht-Standard-Anwendungen haben neben den vor
herrschenden langen Transaktionen nach wie vor kurze Transaktionen ihre Existenzberechtigung. Sie
dienen z.B. zum Ad-hoc-Zugriff auf einzelne Daten oder fUr statistische Auswertungen. 1m folgenden
wird angenommen, daB in einem Nicht-Standard-Datenbanksystem Transaktionslasten mit beJiebigen
Anteilen an kurzen und langen Transaktionen vorkommen konnen.
Wenn in der vorliegenden Arbeit von" Benutzern" oder "Benutzergruppen" gesprochert wird, sind nicht
notwendigerweise die unrnittelbaren Endbenutzer eines Datenbanksystems gemeint. Vielmehr kann es
sich dabei auch urn Anwendungssysteme wie z.B. CAD- oder Lagerverwaltungssysteme handeln, die zur
Datenhaltung ein Datenbanksystem verwenden. Insbesondere solche ~nwendungssysteme konnen die in
dieser Arbeit vorgeschlagenen Mechanismen zur Optimierung der Mehrbenutzerkontrolle ausnutzen.
In Nicht-Standard-Anwendungen ist es oft von Vorteil, wenn verschiedene Benutzer oder Benutzer
gruppen die Moglichkeit haben, komplexe Objekte aus einer zentralen Datenbank auf Arbeitsplatzrech
ner, d.h. Workstations, auszulagern ("Check-Out"). Die ausgelagerten Daten konnen zumindest vor
Obergehend als private, lokale Datenbanken betrachtet werden. Daten, die auf einem Arbeitsplatzrechner
geandert werden, konnen wieder in eine zentrale Datenbank eingebracht werden ("Check-In"). Bei einem
Datenbanksystem, das die Auslagerung von Daten auf Arbeitsplatzrechner zulaBt, handelt es sich
NICHT unbedingt urn ein verteiltes Datenbanksystem; die Konzepte "Workstation-Server-Datenbank
system" und "verteiltes Datenbanksystem" sind vielmehr als orthogonal anzusehen.
Heutzutage arbeiten oft, z.B. in der Automobilindustrie, verschiedene Arbeitsgruppen unabhangig von
einander mit ausgelagerten Daten, d.h. privaten Datenbanken. Mit Hilfe geeigneter MaBnahmen muB
sichergestellt werden, daB sich die privaten Datenbanken untereinander und irn Vergleich zur entspre
chenden zentralen Datenbank immer in einem konsistenten oder zumindest wohldefmierten Zustand
befinden. Insbesondere im Hinblick auf die Synchronisation langer Transaktionen auf (nicht-disjunkten)
komplexen Objekten, die Synchronisation benutzerdefinierter Erweiterungen und die UnterstOtzung
konsistenter Sichten auf Daten durch die Synchronisation treten jedoch bei traditionellen Synchronisa
tionsverfahren gravierende Schwiichen zutage.
Die optimistischen Synchronisationsverfahren [KuR081] scheiden von vornherein fUr die Verwendung in
Workstation-Server-Umgebungen mit langen Transaktionen aus, da bei diesen Verfahren Zugriffskon
flikte erst am Transaktionsende erkannt werden und es sich von selbst verbietet, im Faile eines Zu
griffskonflikts die Arbeit von vielleicht einigen Wochen durch RUcksetzen der Transaktion zunichte zu
3
machen. Bei Sperrverfahren [GLP75, GLPT76] wird bei einem Zugriff auf Daten dagegen sofort gepruft,
ob der entsprechende Zugriff erlaubt ist oder nicht. Die Erkennung von Konflikten erfolgt somit erheb
lich frUher als bei optirnistischen Verfahren. Aus diesem Grund werden in der vorliegenden Arbeit aus
schlieBlich Synchronisationsverfahren untersucht, die auf der Verwendung von (transaktionsorientierten)
Sperren basieren.
Ein Datenbanksystem, das komplexe Objekte unterstiltzt, sollte -z.B. bei der Bearbeitung von komple
xen Konstruktionsdaten - auch die Synchronisation von Zugriffen auf Teile von komplexen Objekten
zulassen. Die Synchronisation solcher Zugriffe fUhrt bei Anwendung der klassischen Sperrtechniken je
doch zu unbefriedigenden Ergebnissen. Dies gilt insbesondere fUr komplexe Objekte mit gemeinsamen
Daten. Wenn komplexe Objekte einschlieBlich ggf. vorhandener gemeinsamer Daten nur als Ganzes als
Sperrgranulat verwendet werden konnen, reduziert dies die Parallelitat unnotig stark, da moglicherweise
sehr viele Daten ohne Grund lange Zeit blockiert werden. Auf der anderen Seite fUhren einzelne Tupel,
also die Basiselemente von komplexen Objekten, als Sperrgranulat zu einem groBen Aufwand im Hin
blick auf die Verwaltung der Sperren und die Konflikttests. Die genannten Nachteile fallen bei langen
Transaktionen mit ihren langen Sperren besonders stark ins Gewicht.
Daruber hinaus spielt das Protokoll, nach dem auf gemeinsamen Daten Sperren angefordert werden, flir
die Leistungsllihigkeit eines Sperrverfahrens eine groBe Rolle: Das traditionelle DAG-Sperrprotokoll
[GLP75, GLPT76] veriangt, daB aile Eiternknoten eines Knotens geeignet gesperrt sein mUssen, bevor
ein Knoten so gesperrt werden kann, daB die entsprechenden Daten geandert werden dUrfen. Das Be
stimmen und Sperren aller Elternknoten eines Knotens in gemeinsamen Daten ist jedoch i.d.R. sehr
aufwendig.
Eine weitere Steigerung der moglichen Parallelitat kann erreicht werden, indem fUr Transaktionen auf
gemeinsamen Daten nur Sperren gesetzt werden, die genau so viele Rechte gewahren, wie dieser Trans
aktion bzw. dem entsprechendem Benutzer aufgrund ihrer Autorisierung Uberhaupt zustehen. Haben
beispielsweise Transaktionen nicht das Recht, Normteilkataloge zu andern, benotigen diese Transaktio
nen auch niemals Sperren auf diesen Daten, die ihnen das Recht auf Anderung zugestehen.
1m Hinblick auf Indexe bereitet das traditionelle DAG-Sperrverfahren beim Sperren von Daten f1ir An
derungen ahnliche Probleme wie bei gemeinsamen Daten. Nichtsdestotrotz mUssen gerade in Nicht
Standard-Anwendungen mit groBen komplexen Objekten und entsprechenden Indexen diese Indexe in
ein effIzientes Sperrverfahren integriert sein.
Da die Granulate und Modi, die zur Einhaltung von bestimmten Konsistenzebenen benotigt werden,
insbesondere im Hinblick auf Phantome die erreichbare Parallelitat in hohem MaBe beeinflussen, sollte
eine Transaktion in Nicht-Standard-Datenbanksystemen die Moglichkeit haben, neben der Einhaltung
der in traditionellen Datenbanksystemen verfUgbaren die Einhaltung zusatzlicher Konsistenzebenen
fordern zu konnen. DarUber hinaus sollten diese Konsistenzebenen beliebigen Verarbeitungseinheiten,
z.B. ganzen Transaktionen oder einzelnen Anfragen, zugeordnet werden konnen.
Zugriffe auf Auspragungen benutzerdeJinierter Datentypen miissen genau wie Zugriffe auf Daten tiber
benutzerdeJinierten Funktionen korrekt und effIzient synchronisiert werden.
Letztlich bestimmt werden der Sperraufwand und die mogliche Parallelitat davon, welche Granulate in
welchen Modi gesperrt sind. Die gesperrten Granulate sollen so klein wie moglich, aber auch nur so klein
wie notig sein. Daruber hinaus soil der Modus, in dem Daten gesperrt werden, so wenig restriktiv wie
moglich sein. Die Sperren miissen dabei so gesetzt werden, daB die geforderten Konsistenzebenen ein
gehalten werden. Als "optimale" Sperranforderungen werden im folgenden die Sperranforderungen be
zeichnet, die den groBten Durchsatz eines Nicht-Standard-Datenbanksystems erwarten lassen. Die Be-