Datenbankentwurf

• Beispiel Literatur-Datenbank:

  Author	Title	Pages	Year	Publication	Keyword
  Chow	Parallel DEVS: A parallel, hierarchical, modular modeling formalism and its distributed simulator	14	1996	Trans Soc Comp Sim	simulation, discrete events
  Zimmer, Cellier	The Modelica Multi-bond Graph Library	10	2006	5th Intl Modelica Conf	simulation, bond graphs
  Junglas, Pawletta	Non-standard Queuing Policies: Definition of ARGESIM Benchmark C22	5	2019	SNE	simulation, discrete events, benchmark
  Jammer, Pawletta, Kunert, Pawletta	Beschleunigung eines Reinforcement-Learning-Algorithmus durch Parallelverarbeitung für Robotikanwendungen	4	2019	8. Workshop STS/GMMS	parallel computing, robotics, artificial intelligence
  Jammer, Junglas, Pawletta, Pawletta	Implementing Standard Examples with NSA-DEVS	8	2022	SNE	simulation, discrete events
  Zimmer, Meißner, Weber	The DLR ThermoFluid Stream Library	21	2022	Electronics	simulation, thermofluid
  Jammer, Junglas, Pawletta	Solving ARGESIM Benchmark CP2 ’Parallel and Distributed Simulation’ with Open MPI and Matlab PCT – Lattice Boltzmann Simulation	8	2023	SNE	benchmark, parallel computing

• Probleme mit der Tabelle:
  • Felder mit mehreren Einträgen (Author, Keyword)
    • → kann nicht nach einzelnem Autor oder Schlagwort durchsucht werden
  • hohe Redundanz
    • gleiche Begriffe an mehreren Stellen (Keyword, Author, Publication)
    • → vergrößerter Speicherbedarf
    • → Gefahr von Inkonsistenzen (z.B. durch Schreibfehler)
  • Datenbanken brauchen klaren Entwurf!
• Entity-Relationship-Modell (ERM):
  • Verfahren zum systematischen Entwurf von Datenbanken
  • Entity
    • eindeutig identifizierbares Objekt
    • beschrieben durch eine Menge von Attributen
    • Typ des Objekts = Liste der Attributsnamen und -typen
    • Entitäten ergeben Tabellen
  • Vergleich mit objektorientierter Programmierung
    • Tabelle ≙ Klasse
    • Attribut ≙ Datenfeld
    • Datensatz ≙ Objekt
  • Relationship
    • Beziehung zwischen Entitäten
    • kann selbst Eigenschaften (Attribute) haben
    • kann zwei oder mehr verschiedene Arten von Entitäten verknüpfen
    • kann verschiedene Vielfachheiten haben, z.B.

      1:1	ein Objekt A mit einem Objekt B
      1:N	ein Objekt A mit mehreren Objekten B
      N:M	ein A mit mehreren B und ein B mit mehreren A

    • ein Objekt möglicherweise mit keinem anderen verknüpft
    • Notation z.B.
    • 1:0..* = ein Objekt A mit gar keinem, einem oder mehreren B verknüpft
  • graphische Darstellung z.B. als Klassendiagramm (UML-Diagramm)
    
• Anwendung auf Beispiel:
  • Entitäten sind
    • Paper
    • Author
    • Publication
    • Keyword
  • Attribute
    
  • Beziehungen zwischen den Entitäten
    
  • z.B. Beziehung zwischen Paper und Publication
    • ein Paper hat genau eine Publication (1)
    • ein Publication hat ein oder mehrere Paper (1..*)
  • einige Designentscheidungen
    • nur Autoren aufgeführt, für die Paper in der Datenbank existieren
    • zu einem Keyword kann evtl. noch kein Buch vorhanden sein
    • Publication type (z.B. Journal, Proceedings, Thesis, Manual, Technical Report) nicht ausgegliedert
• Umsetzung der Relationen:
  • unterschiedlich nach Grundtypen 1:1, 1:N, N:M
  • bei 1:N
    • Schlüssel der 1-Seite als Attribut zur Tabelle der N-Seite hinzufügen (Fremdschlüssel)
    • im Beispiel: Tabelle Paper bekommt Attribut publicationId
  • bei 1:1
    • gelegentlich für Spezialisierungen (z.B. allgemeine Daten in Person, Spezialdaten in Employee oder in Customer
    • zwei Tabellen oder beide Tabellen zu einer mit allen Attributen zusammenfassen
    • häufig durch Hinzufügen der Attribute einer Tabelle zur anderen (z.B. Telefon-Nr. zu Author)
  • bei N:M
    • neue Tabelle für die Relation einführen (Verbindungsentität)
    • enthält Fremdschlüssel beider Partner
    • Primärschlüssel ist häufig Paar der Fremdschlüssel
    • enthält manchmal weitere Attribute
  • im Beispiel:
    • neue Tabelle PaperAuthor
    • Attribute paperId und authorId
    • bilden zusammen Primärschlüssel
    • anlegen mit PRIMARY KEY(paperId, authorId)
    • einen Eintrag für jede Author/Paper-Kombination
    • analog für PaperKeyword
• Fertige Bücher-Datenbank:
  • als Klassendiagramm
    • 
  • Problem
    
    • Reihenfolge der Autoren in einem Paper wichtig
    • Info als Attribut position abspeichern, aber wo?
    • passt nicht in Author (ein Autor hat mehrere Paper mit verschiedenen Positionen)
    • passt nicht in Paper (ein Paper hat mehrere Autoren mit verschiedenen Positionen)
    • gehört in PaperAuthor
    • 
  • Tabellen mit Beispieldaten
• Aufgaben
  • Aufgabe 17