„Benutzer:Dokumentarix/Erweiterte NF2-Relationen“ – Versionsunterschied

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
Zum nächsten Versionsunterschied →
Inhalt gelöscht Inhalt hinzugefügt
VisuellWikitext
Dokumentarix (Diskussion | Beiträge)
361 Bearbeitungen
Links auf AIM-P-Seite hinzugefügt
(kein Unterschied)

Version vom 19. Dezember 2022, 15:53 Uhr

Erweiterte NF2-Relationen, abgekürzt eNF2-Relationen, sind eine (erhebliche) Verallgemeinerung der NF2-Relationen. Die eNF2-Relationen haben national international viele Forschungsarbeiten inspiriert, sei es mit direktem Bezug zu NF2 [1][2][3], für anspruchsvolle Anwendungen [4][5][6] oder für die semantische Datenmodellierung [7][8]. Sie haben Eingang in Lehrbücher im Bereich Datenbanksysteme [9][10][11] gefunden und sind fester Bestandteil vieler Datenbankvorlesungen an Universitäten und Hochschulen. Sie spielten Anfang der 1990er Jahre auch eine wichtige Rolle in der Diskussion im ISO-SQL-Gremium über die Erweiterungen von SQL in der nächsten Version des SQL-Standards.

Die eNF2-Relationen wurden in den 1980er Jahren am Wissenschaftlichen Zentrum der IBM in Heidelberg (WZH) im Rahmen des Projekts "Advanced Information Management Prototype" (AIM-P) [12][13] entwickelt. In diesem Projekt wurden viele technisch-wissenschaftliche sowie andere Anwendungen im Hinblick auf deren Anforderungen an Datenstrukturen untersucht, die ein "Next-Generation"-Datenbanksystem anbieten sollte, um Anwendungen der jeweiligen Art adäquat zu unterstützen. - Für die Anfragebeispiele wird im Folgenden die für das eNF2-Relationenmodell am WZH entwickelte Datenbanksprache HDBL ("Heidelberg Database Language") [12][14][15] verwendet.

Schwächen des NF2-Relationen-Modells

Wie im Beitrag Wikipedia-Eintrag "NF2-Relationen" am Beispiel einer Roboter-Anwendung gezeigt wurde, stellen NF2-Relationen im Vergleich zu den klassischen Relationen, deren Attributwerte wegen der 1. Normalform stets atomar sein müssen (im Folgenden als "1 NF-Relationen" oder "flache Relationen" bezeichnet), bereits eine erhebliche Verbesserung dar wenn es darum geht, komplexe Datenobjekte zu speichern und als Anfrageergebnisse auszugeben.  

Abb. 1: Modelllierung eines Roboters (vereinfacht)
Abb. 2: Roboter-Objekte als Tupel einer NF2-Relation

NF2-Relationen haben allerdings dasselbe Problem wie 1NF-Relationen: Sie handhaben 'Mengen von Tupeln' und Mengen haben - wie in der Mathematik - keine feste Reihenfolge ihrer Elemente. Sowohl bei 1NF- als auch bei NF2-Relationen muss man in Anfragen daher Sortieroperationen einfügen, um das Resultat in der gewünschten Reihenfolge ausgeben zu können. Dies ist bei kleinen Datenmengen noch hinnehmbar, wird allerdings bei großen Datenmengen zum Problem. Nehmen wir der Einfachheit halber an, wir haben bei vielen Objekten eine Liste von bis zu 10.000 Integerwerten (z.B. als Messergebnisse eines Sensors) zu speichern. Da deren Reihenfolge natürlich relevant ist, müssen wir die Werte als 2-stelliges Tupel für die Aufnahme des Werte und dessen Position in der Liste speichern; und beim Auslesen müssen wir diese Tupelmenge dann auch noch nach der Positionsnummer sortieren. Andere Beispiele dieser Art treten z.B. beim Hinterlegen von Bahnkurven auf, welche etwa mittels Polygonzügen die Bewegung der Endpunkte eines Roboterarms für die Durchführung einer bestimmten Aufgabe im Zeitverlauf beschreiben und z.B. für die Kollisionserkennung verwendet werden. Hier sind die Einträge dann z.B. Tupel der Form [ zeitpunkt, x, y, z ]. Auch diese Listen können, je nach geforderter Genauigkeit der Approximation der realen Bahnkurve, ebenfalls sehr lang werden. - Diese Beispiele legen nahe, dass das Datenmodell eines "Next-Generation"-Datenbanksystems neben Mengen von Tupeln zumindest auch 'Listen von Tupeln' sowie 'Listen von atomaren Werten' unterstützen sollte.

Aber Listen von Tupeln und Listen von atomaren Werten sind auch noch nicht ausreichend. Betrachten wir hierzu die NF2-Relation in Abb. 2. Das mengenwertige Attribut DH_Matrix ist eine mögliche Speicherung einer 4x4-Matrix. Nehmen wir an, wir möchten auf das Element (3,2), d.h. in der 3-ten Zeile und der 2-ten Spalte dieser Matrix von Roboter 'Rob1' im Arm 'A1' und Achse 1 zugreifen. Dann müssen wir in der Sub-Anfrage für das Attribut DH_Matrix eine SELECT-Anweisung etwa der folgenden Art (in HDBL-Syntax) verwenden, was spätestens bei höherdimensionalen Matrizen sehr unschön wird.

HDBL-Bsp. 1

Wesentich einfacher wird es, wenn das Datenmodell auch Listen von Listen von Tupeln oder atomaren Werten unterstützt, wie in der folgenden Abbildung für das Roboter-Objekt dargestellt. In diesem Beispiel sind 'Axes' und 'DH_Matrix' als listenwertige Attribute realisiert, was durch die Klammern "< ...>" angezeigt wird.

Abb. 3: Roboter-Objekte als Tupel einer eNF2-Relation

Der in Anfrage 1 beschriebene Zugriff auf das Matrix-Element (3,2) könnte in HDBL in der Sub-Anfrage für das Attribut DH_Matrix wie folgt formuliert werden:

HDBL-Bsp. 2

Auch die Forderung, dass das Anfrageergebnis immer eine Menge von ... oder eine Liste von ... sein muss, ist nicht immer problem-adäquat. Es gibt im jeweils betrachteten Kontext oftmals eine ganze Reihe von singulären Datenobjekten, wie z.B. das eigene Unternehmen (als ein komplex strukturiertes Datenobjekt), die höchste bereits vergebene Rechnungsnummer (lange, positive Ganzzahl) usw. - Wie im nächsten Abschnitt ausgeführt, gibt es aber noch viel gewichtigere Gründe, auch atomare Werte als "Top-Level"-Datenbankobjekte zuzulassen.

Das eNF2-Relationen-Modell

Zielsetzung

Das Ziel beim Entwurf des eNF2-Datenmodells war, das NF2-Datenmodell so zu erweitern, dass

  1. es alle als relevant identifzierten Datenstrukturen anbietet
  2. dafür eine adäquate SQL-ähnliche Hochsprache geschaffen werden kann
  3. das Ergebnis jeder Anfrage wieder ein legales Objekt dieses Datenmodells zurück liefert

Das dritte Teilziel ist wichtig, damit jedes solches "Resultat-Objekt" sowohl als Zwischenergebnis in geschachtelten Anfrageausdrücken auftreten als auch "as is" als legales Datenobjekt wieder in der Datenbank gespeichert werden kann.

Das Ergebnis dieser Untersuchungen und Überlegungen führen zu dem nachstehend illustrierten eNF2-Datenmodell. Abb. 4 veranschaulicht die Evolution des relationalen Datenmodells von 1NF via NF2 zu eNF2.

Abb. 4: Evolution der relationalen Datenmodelle

Im eNF2-Datenmodell können alle Konstruktoren (list, set, tuple) und atomaren Werte sowie alle Kombinationen von diesen sowohl als singuläre Objekte, als Top-Level-Objekte oder als Attributwerte oder Elemente von Mengen oder Listen auftreten.[15]

Die folgende Tabelle zeigt im Detail die Unterschiede der strukturellen Ausdruckmächtigkeit der drei relationalen Datenmodelle. Die Einträge in der Spalte 'Toplevel-Typ' zeigen an, welcher Objekttyp z.B. mit CREATE object ... erzeugt werden kann. Die 1NF- und NF2-Relationen kennen nur die Menge ("Relation") als Toplevel-Typ, während bei eNF2 alle Typen zugelassen sind. Die Spalten im Bereich 'kann enthalten' zeigen an, mit welchen Typen der in Spalte 'Typ' stehende Typ kombiniert werden kann. Bei 1NF und NF2 kommt nur der Toplevel-Typ 'Menge' in Frage und der kann in beiden Fällen nur mit 'Tupel'" kombiniert werden. Beim 'Tupel'-Typ tun sich dann die Unterschiede auf: Bei 1NF kommt nur 'Atom' in Frage, während bei NF2 'Atom' und 'Menge' möglich sind und eNF2 alle Kombinationen erlaubt.

kann enthalten
Toplevel-Typ Typ Menge Liste Tupel Atom
1NF + Menge - - + -
NF2 + + - + -
eNF2 + + + + +
1NF - Liste - - - -
NF2 - - - - -
eNF2 + + + + +
1NF - Tupel - - - +
NF2 - + - - +
eNF2 + + + + +
1NF - Atom - - - -
NF2 -
eNF2 +
Abb. 5: 1NF-, NF2- und eNF2-Strukuren im Vergleich

Typ-Konstruktoren, -Konversionen und typbezogene Operationen von HDBL (Auswahl)

Art für Syntax Wirkung / Anmerkung
Konstruktor Tupel [ elem1, elem2, ..., elemn ] 1..n homogene oder heterogene Elemente
Menge { elem1, elem2, ..., elemn } 0..n homogene Elemente
Liste < elem1, elem2, ..., elemn > 0..n homogene Elemente
Typumwandlung Menge → Liste MLIST( menge )
Liste → Menge ELEMS( liste )
Abb. 6: Konstruktoren und Typumwandlungen (für Objektdeklarationen und in Anfragen)
anwendbar auf Art der Operation Operator (Syntax) Resultat-Typ
Menge, Liste Iteratoren (zum Zugriff auf Elemente) FOR_EACH … IN … DO ... wie Input
Menge, Liste Löschen eines Elements DELETE element -
Menge Vereinigung menge1 UNION menge2 Menge
Menge Durchschnitt menge1 INTERSECT menge2 Menge
Menge Differenz menge1 MINUS menge2 Menge
Menge Einfügen INSERT menge1 INTO menge2 Menge
Menge Ermitteln Kardinalität CARD( menge ) Zahl
Liste Konkatenation liste1 || liste2 Liste
Liste Positioniertes Einfügen EXTEND liste1 WITH liste2 { BEFORE | AFTER } pos Liste
Liste Zugriff auf Teillisten SUBLIST( startpos, anzElemente, liste ) Liste
Liste Ermitteln Länge LEN ( liste ) Zahl
Liste Sortierung ORDER x IN liste BY x { ASC | DESC } Liste
Menge, Liste Gruppierung GROUP x IN { menge | liste } BY x { Menge von Mengen | Liste von Listen }
Menge, Liste Duplikateliminierung UNIQUE ( { menge | liste } ) wie Input
Abb. 7: Operationen auf eNF2-Objekten

Die Semantik der meisten dieser Operationen dürfte intuitiv klar sein. Bei Sortierung, Gruppierung und Duplikateleminierung können (ggf. auch geschachtelte Mengen oder Listen) als "Vergleichsobjekte" auftreten (wie z.B.: Ist { 1,3,8 } größer oder kleiner als { 2,4,5,6 } ?) , so dass eine präzise Festlegung und Beschreibung der Semantik dieser Operationen bei Einsatz in einem Datenbanksystem erforderlich ist. [16][17]

Daten- und Anwendungsbeispiele

Da die reinen NF2-Strukturen des eNF2-Datenmodells bereits ausführlich im Betrag zu den NF2-Relationen behandelt werden, beschränken sich die folgenden Beispiele auf die zusätzlichen Eigenschaften, die das eNF2-Datenmodell mit sich bringt.

Beispiele für CREATE-Anweisungen für Objekte

  • Erzeugen einzelnes (flaches) Tupel als Datenbank-Objekt
    HDBL-Bsp. 3
     
  • Erzeugen einzelnen Integerwert als Datenbank-Objekt
    HDBL-Bsp. 4
     
  • Erzeugen einzelne Liste von Integer-Werten als Datenbank-Objekt
    HDBL-Bsp. 5
     
  • Erzeugen Robot_eNF2-Objekt
    HDBL-Bsp. 6

Beispiele für SELECT-Anweisungen

  • Ausgabe der kompletten Robot_eNF2-Relation
    HDBL-Bsp. 7 + 8
  • Ausgabe aller Roboter, die mindestens 2 Arme haben
    HDBL-Bsp. 9
  • wie HDBL-Bsp. 9 + Greifer 'GR800' muss anschließbar sein
    HDBL-Bsp. 10
  • Ausgbe der RobID aller Roboter, die im 4. Element jeder 3. Matrixzeile den Wert 40 aufweisen
    HDBL-Bsp. 11
  • Wie HDBL-Bsp. 11, jedoch sollen zudem noch die Menge der ArmIDs ausgeben werden, deren Matrizen diese Bedingung erfüllen
    HDBL-Bsp. 12
    Erläuterung zu HDBL-Bsp. 12: In der äußeren WHERE-Bedingung (1) werden alle Toplevel-Tupel in Roboter-eNF2 ausgewählt, bei denen mindestens ein Roboter-Arm diese Bedingung erfüllt. Die innere WHERE-Bedingung (2) regelt, welche Arme von diesen Robotern die Anfragebedingung erfüllen und nur deren ArmID wird ausgewählt und ausgegeben.

Beispiele für Einfüge-Anweisungen

  • Ein neuer Roboter 'Rob4' soll eingefügt werden
    HDBL-Bsp. 13
  • Roboter 'Rob2' soll weitere Endeffektoren erhalten
    HDBL-Bsp. 14

Beispiele für Änderungs-Anweisungen

  • Die Funktionsbeschreibung des Sensors SN200 von 'Rob1' soll geändert werden
    HDBL-Bsp. 15
    Anmerkung: Wenn die Eff_ID eindeutig ist, kann man die obere WHERE-Bedingung "… WHERE r.RobID = 'Rob1' " weglassen.
  • Ersetzen der kompletten Endeffektor-Menge von 'Rob4'
    HDBL-Bsp. 16
  • Zuweisung an das singuläre Objekt 'Mitarbeiter_Heinze' (siehe oben)
    HDBL-Bsp. 17
  • Zuweisungen an das singuläre Listenobjekt 'MessreiheEinzeln' (siehe oben)
    • Komplettes Ersetzen des Inhalts
      HDBL-Bsp. 18
    • Hinzufügen am Ende
      HDBL-Bsp. 19
    • Einfügen am Anfang
      HDBL-Bsp. 20

Beispiele für Lösch-Anweisungen

  • Screw Driver 'SD200' steht 'Rob1' nicht mehr zur Verfügung
    HDBL-Bsp. 21
  • Die Einträge des singulären Objekts 'Mitarbeiter_Heinze' sollen gelöscht werden
    HDBL-Bsp. 22

Abschließende Bemerkungen

Insbesondere für technisch-wissenschaftliche Datenobjekte reicht es nicht aus, für diese nur geeignete Speicherstrukturen bereitzustellen, sondern man benötigt in der Regel auch objekt-spezifische Funktionen um die Datenobjekte (oder Teile davon) zu erstellen, zu verändern und evtl. auch für ihre graphische Visualisierung. Im Rahmen des oben erwähnten AIM-P-Projektes wurde HDBL daher durch benutzerdefinierte Datentypen und Funktionen' erweitert.[12] - Eine ausführliche Beschreibung hierzu findet sich im Wikipedia-Beitrag 'Advanced Information Management Prototype (AIM-P)' im Kapitel 'AIM-P - Weiterentwicklung und Erprobung im R2D2-Projekt'.

Wie eingangs erwähnt, waren die eNF2-Relationen Anfang der 1990er Jahre in der Diskussion im ISO-SQL-Gremium über die Erweiterungen von SQL in der nächsten Version des SQL-Standards. Wie diese Diskussion verlief und warum man sich am Ende dann doch für einen anderen (und im Nachhinein gesehen falschen) Ansatz entschieden hat, ist in diesem Wikipedia-Beitrag zu AIM-P ebenfalls beschrieben, und zwar im Kapitel 'NF2, eNF2, AIM-P und die Entwicklung des SQL-Standards'.

Referenzen

  1. ↑ L. Wegner, M. Paul, R. Colomb: Variants and Recursive Types in the eNF2 Data Model. In: Technical Report, Dept. of Computer Science, Univ. of Queensland, Brisbane, Australia. Band 233, Juni 1992 (researchgate.net [PDF]).
  2. ↑ N. Lachmann: Operationen auf komplexen Objekten in ORDBMS: Analyse, Vergleich und Optimierung. In: M. Samia, S. Conrad (Hrsg.): Tagungsband zum 16. GI-Workshop Grundlagen von Datenbanken, Mohnheim. Juni 2004, S. 83–87 (uni-duesseldorf.de [PDF]).
  3. ↑ Gunter Saake, Ralf Jungclaus, Cristina Sernadas: Abstract data type semantics for many-sorted object query algebras. In: MFDBS 91. Band 495. Springer Berlin Heidelberg, Berlin, Heidelberg 1991, ISBN 978-3-540-54009-0, S. 291–307, doi:10.1007/3-540-54009-1_21 (springer.com [abgerufen am 20. Oktober 2022]).
  4. ↑ Manfred Gärtner: Die Eignung relationaler und erweiterter relationaler Datenmodelle für das Data Warehouse. In: Das Data Warehouse-Konzept. Gabler Verlag, Wiesbaden 1998, ISBN 978-3-409-32216-4, S. 195–217, doi:10.1007/978-3-322-99372-4_6 (springer.com [abgerufen am 20. Oktober 2022]).
  5. ↑ Eitel von Maur: Object Warehouse - Konzeption der Basis objektorientierter Management Support Systems am Beispiel von Smalltalk und dem ERP Baan. In: Fachbereich Wirtschaftswissenschaften, Universität Osnabrück, Dissertation. Mai 2000 (uni-osnabrueck.de [PDF]).
  6. ↑ Alfons Kemper, Mechtild Wallrath: An analysis of geometric modeling in database systems. In: ACM Computing Surveys. Band 19, Nr. 1, März 1987, ISSN 0360-0300, S. 47–91, doi:10.1145/28865.28866 (acm.org [abgerufen am 20. Oktober 2022]).
  7. ↑ S. Thelemann: Semantische Anreicherung eines Datenmodells für komplexe Objekte. Dissertation, Fachbereich Mathematik/Informatik der Universität Gesamthochschule Kassel, Mai 1996 (uni-kassel.de [PDF]).
  8. ↑ Saulius Gudas, Andrius Valatavicius: Normalization of Domain Modeling in Enterprise Software Development. In: Baltic Journal of Modern Computing. Band 5, Nr. 4, Dezember 2017, doi:10.22364/bjmc.2017.5.4.01 (lu.lv [PDF; abgerufen am 20. Oktober 2022]).
  9. ↑ Stefan M. Lang, Peter C. Lockemann: Das NF2-Modell. In: Datenbankeinsatz. Springer Berlin Heidelberg, Berlin, Heidelberg 1995, ISBN 978-3-642-63353-9, S. 97–118, doi:10.1007/978-3-642-57782-6_5 (springer.com [abgerufen am 20. Oktober 2022]).
  10. ↑ Andreas Heuer, Gunter Saake, Kai-Uwe Sattler: Datenbanken - Konzepte und Sprachen Buch, 6. Auflage. mitp, 2018, ISBN 978-3-95845-776-8 (vdoc.pub).
  11. ↑ Gunter Saake, Ingo Schmitt, Can Türker: Objektdatenbanken - Konzepte, Sprachen, Architekturen. 2003 (uni-magdeburg.de [PDF]).
  12. ↑ a b c Peter Pistor, Peter Dadam: The advanced information management prototype. In: Nested Relations and Complex Objects in Databases. Band 361. Springer Berlin Heidelberg, Berlin, Heidelberg 1989, ISBN 978-3-540-51171-7, S. 1–26, doi:10.1007/3-540-51171-7_18 (springer.com [abgerufen am 20. Oktober 2022]).
  13. ↑ P. Dadam, K. Kuespert, F. Andersen, H. Blanken, R. Erbe: A DBMS prototype to support extended NF2 relations: an integrated view on flat tables and hierarchies. In: ACM SIGMOD Record. Band 15, Nr. 2, 15. Juni 1986, ISSN 0163-5808, S. 356–367, doi:10.1145/16856.16889 (acm.org [abgerufen am 20. Oktober 2022]).
  14. ↑ Peter Pistor, Flemming Andersen: Designing A Generalized NF2 Model with an SQL-Type Language Interface. In: Proc. VLDB'86, 12th International Conference on Very Large Data Bases, Kyoto, Japan. 1968, S. 278–285 (researchgate.net).
  15. ↑ a b P. Pistor, R. Traunmueller: A database language for sets, lists and tables. In: Information Systems. Band 11, Nr. 4, Januar 1986, S. 323–336, doi:10.1016/0306-4379(86)90012-8 (elsevier.com [abgerufen am 29. Oktober 2022]).
  16. ↑ G. Saake, V. Linnemann, P. Pistor, L. Wegner: Sorting, Grouping and Duplicate Elimination in the Advanced Information Management Prototype. In: VLDB '89: Proc. 15th Int. Conf. on Very Large Data Bases, Amsterdem. 1989 (acm.org).
  17. ↑ K. Küspert, G. Saake, L. Wegner: Duplicate detection and deletion in the extended NF2 data model. In: Foundations of Data Organization and Algorithms. Band 367. Springer Berlin Heidelberg, Berlin, Heidelberg 1989, ISBN 978-3-540-51295-0, S. 83–100, doi:10.1007/3-540-51295-0_120 (springer.com [abgerufen am 21. Oktober 2022]).
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Benutzer:Dokumentarix/Erweiterte_NF2-Relationen&oldid=228999496“