Start
Unternehmen
ERP / PPS / Prozesse
Business Intelligence
Server-Technologien
Software-Technologien
Technologie-Beratung
Individual-Software
Produkte

Comelio GmbH
Am Fischhof 3
A-1010 Wien
Österreich
Fon: +43-720-2097-97
Fax: +43-720-2097-98
info@comelio.com

Comelio GmbH (Ecos)
Stiglmaierplatz/Dachauer Str. 37
D-80335 München
Deutschland
info@comelio.com

Comelio GmbH
Rellinghauser Straße 10
D-45128 Essen
Deutschland
Fon: 0201-437517-0
Fax: 0201-437517-10
info@comelio.com

Comelio GmbH
Goethestraße 34
D-13086 Berlin
Deutschland
info@comelio.com

Comelio-Blog > Datenbanken > ERM/RDM

Vom ERM zum RDM

Während die Normalisierung bereits wenigstens von einem halbwegs modelierten Datenumfeld ausgeht, so hilft das Entity-Relationship-Modell dabei, überhaupt erst einmal eine grobe Vorstellung von der in einer relationalen Datenbank zu speichernden Daten zu erhalten. Dieser Artikel zeigt ganz beispielhaft, wie man von einem semantischem Modell, also einer sprachlichen Beschreibung eines Weltausschnitts, zu einem Entity-Relationship-Modell und damit zu einer grafischen Umsetzung kommt und wie danach ein relationales Datenmodell entwickelt wird.

Kontakt

Anrede* Herr Frau
Vorname*
Nachname*
Firma
E-Mail*
Tel-Nr.
Bereich*
Freitext

Vom ER-Modell zum RDM

Bevor man sich daranmacht, für ein Datenbankprojekt sofort Tabellen und Feldnamen mit SQL zu tippen, kann man mit Hilfe eines grafischen Modells versuchen, die zu modellierenden Objekte zu finden und sich einen Überblick über die Beziehungen zu verschaffen. Als Beispiel soll ein privates Beispiel dienen:

Eine Plattensammlung soll komplett mit Hilfe einer DB erfasst werden. Die Daten müssen am Ende so vorliegen, dass ohne Schwierigkeiten ein Überblick über die Songs und verschiedenen Versionen abgefragt werden kann. Ein weiteres Ziel könnte hier eine Informationsbörse sein, da ausschließlich ein Künstler mit allen möglichen Varianten seiner Stücke betrachtet wird. Gerade unter diesem Blickwinkel – also bei Künstlern wie Tina Turner, den Rolling Stones, Rod Stewart oder Joe Cocker – ergeben sich unterschiedliche Schwierigkeiten und die Gefahr der Datenredundanz.

  1. Entwickeln Sie ein semantisches Modell. Ein semantisches Modell versucht, die Objekte der Realität möglichst genau zu erfassen und so eine Basis für die endgültig zu erstellende Datenbank zu liefern. Im Idealfall entsteht ein Text, der bereits alle Objekte, Beziehungen und Attribute nennt. Die Entwicklung des semantischen Modells stellt die erste analytische Phase dar.
    • Tina Turner hat verschiedene Lieder in ihrem Repertoire. Ein SONG hat einen Titel, Autoren, die Musik und Text geschrieben haben und ein Erstellungsdatum, zu dem die Autoren das Lied verfasst haben.
    • SONGS existieren in verschiedenen Varianten: Die beiden großen Gruppen sind Live-Aufnahmen und Studio-Aufnahmen. Teilweise gibt es bis zu 20 verschiedene Live-Aufnahmen eines Titels aus verschiedenen Jahren und Städten. Die Studio-Aufnahmen lassen sich noch einmal unterteilen in Mixe und Versionen, die auf einer Single bzw. auf dem Album veröffentlicht wurden. Die Mixe unterscheiden sich normalerweise durch einen speziellen Namen wie „The best (extended muscle mix)“, allerdings existieren auch Mixe, die zwar auf unterschiedlichen CDs mit verschiedenen Namen veröffentlicht wurden, aber in Wirklichkeit die gleichen sind.
    • Die SONGS befinden sich auf verschiedenen DATENTRAEGERN wie 5-inch und 3-inch-CDs, Maxi- und Single-LPs, DVDs, Videos, MiniDiscs usw. Vom gleichen DATENTRAEGER existieren unter dem gleichen Titel verschiedene Ausgaben in unterschiedlichen Ländern. So gibt es bspw. vom Album „Wildest Dreams“ unterschiedliche Ausgaben aus Europa, den USA, Kanada und Japan. Zusätzlich gibt es aus Europa und Australien zwei „special tour editions“ mit einer Bonus-CD in einer Pappbox. Gleiche Titel werden auch auf verschiedenen Datenträgertypen veröffentlicht. So kann man ein Konzert aus Rio de Janeiro von 1988 auf Video, DVD (USA und Europa verschieden), LaserDisc und CD-i kaufen.
    • Sämtliche Audio- und Videoträger sollen gemeinsam erfasst werden.
    • Weitere Objekte, die zu einem späteren Zeitpunkt in der Datenbank erfasst werden sollen, sind Tourdaten und Bücher über TT.
  2. Leiten Sie aus dem semantischen Modell die benötigten Objekte ab. Offensichtlich gibt es zumindest zwei verschiedene Objekte, die in einer Datenbank erfasst werden sollen: Zum einen die einzelnen Songs und zum anderen die Datenträger. Beide erhalten eine vorläufige Liste an Attributen, die sich direkt aus dem semantischen Modell ableitet. Es ist nachher nicht weiter schwierig, sich mehr und mehr Attribute auszudenken, sodass wir uns hier auf die wichtigsten beschränken, um die Vorgehensweise besser zu verdeutlichen. Normalerweise findet man die benötigten Attribute über eine Tätigkeitsanalyse oder eine Objektanalyse.Einfache Entitäten für relationales Datenmodell
    • In einer Tätigkeits- oder Prozessanalyse durchläuft man die gesamten Tätigkeiten, die ein Objekt ausführt. Sie verlaufen teilweise auch parallel zu den Tätigkeiten anderer Objekte, die entweder schon von Anfang an bestehen oder sich erst im Prozessverlauf herausbilden. Für die Entwicklung einer Datenbank, die für die Programmierung eines Webshops eingesetzt werden soll, ist die Tätigkeitsanalyse sehr gut geeignet, Objekte und Attribute herauszufiltern.
      Als Analogie kann man zusätzlich den Einkaufsprozess in einem online vorhandenen Supermarkt vorstellen: Ein BESUCHER ruft die Seite mit dem Webshop auf und wird dadurch registriert. Dies entspricht bspw. dem Klingeln einer Glocke oder der Aufzeichnung einer Kamera, wie es bei real vorhandenen Tankstellen und Banken oft zu finden ist. Eine entsprechende eindeutige Besuchernummer und eine Zeitinformation könnten hier gespeichert werden. Der BESUCHER könnte den Laden wieder verlassen oder sich für die angebotenen PRODUKTE interessieren. Diese Produkte müssen natürlich die auch in einem realen Laden vorhandenen Attribute wie Preis, Bild, Funktionsbeschreibung oder Menge besitzen. Aus dem Angebot wählt er verschiedene PRODUKTE in seinen WARENKORB, der lediglich seine Auswahl, aber noch nicht seine Kaufentscheidung repräsentiert. Es ist weiterhin möglich, aus dem Laden zu verschwinden, ohne einen Kauf zu tätigen. Erst in dem Augenblick, wo der BESUCHER aus seinem WARENKORB bestimmte PRODUKTE auch wirklich bestellt, liegt eine BESTELLUNG vor. Um eine solche BESTELLUNG auszuführen, muss aus dem BESUCHER ein KUNDE werden, indem er alle nötigen Kontaktdaten hinterlässt. Gleichzeitig entsteht aus dieser Auswahl auch ein AUFTRAG an den Shop-Betreiber.
    • Die Objektanalyse fokussiert mehr die Beschreibung von Objekten, die real vorhanden sind. So schimmerte sie gerade bereits bei den Objekten KUNDE und PRODUKT durch die Tätigkeitsanalyse hindurch. Bei der Plattendatenbank des Beispiels in dieser Lektion ist sie dagegen die einzig sinnvolle Vorgehensweise, wie Sie bereits im semantischen Modell gesehen haben. Die Tonträger üben keine Aktivität aus, man kann ihnen nicht gedanklich folgen und Zustandsänderungen oder irgendwelche Prozessabschnitte feststellen. Stattdessen besitzen sie real vorhandenen Unterschiede, die man versuchen muss, ordentlich zu klassifizieren.
      Als Illustration können hier noch einmal die unterschiedlichen Datenträgerarten dienen, welche die Songs enthalten und somit ein wichtiges Unterscheidungsmerkmal darstellen. Der gleiche Song kann demnach auf so unterschiedlichen Trägern wie CD; DVD, LP, LaserDisc, VideoCD oder CD-i gespeichert sein. Damit ist keine Handlung verbunden, sondern ein statischer Zustand der Speicherung oder Adressierung.
  3. Erstellen Sie das Entity-Relationship-Diagramm. Seit 1976 wird das von P.P. Chen vorgeschlagene Entity-Relationship-Modell (ER-Modell oder ERM) für eine erste Annäherung verwendet, dessen Vorteile in der grafischen Darstellung und der mathematischen Verständlichkeit liegen. Es besteht aus den Elementen Entity, Entity-Typ, Relationship und Attribut. Dabei werden die einzelnen gefundenen Objekte zueinander in Beziehung gesetzt und in ein Diagramm gezeichnet. Es kann bei vielen Objekten oder Attributen oder komplexen Beziehungsstrukturen beträchtliche Größen erreichen. Wahlweise wird auch ein Name für die Beziehung vergeben, wobei das nicht mehr ganz en vogue ist. Hier tritt nämlich regelmäßig das Problem auf, dass die Beziehung durch den Namen scheinbar von einem Objekt dominiert wird.Einfache Entitäten für relationales Datenmodell mit Beziehung
    Element Bedeutung Zeichen
    Entity zu modellierendes Objekt Rechteck
    Entity-Typ Objekte mit ähnlichen Eigenschaften Rechteck
    Relationship Beziehung zwischen Objekten Raute
    Attribut Eigenschaft eines Objekts Oval
  4. Analysieren Sie die Beziehungen zwischen den Objekten. Wie das so in Einführungsbeispielen üblich ist, liegt natürlich sofort der ungünstigste aller Zustände vor. In nebenstehender Abbildung sehen Sie einen Ausschnitt aus der so genannten Universal Relation, in der alle Daten einer Datenbank in einer großen Tabelle erfasst werden.
    Diese Tabelle ist besonders ungünstig, da viele Wiederholungen innerhalb der einzelnen Zellen auftreten. Befindet sich der gleiche Song wie „The best (extended mix)“ auf verschiedenen CDs (Maxi-CD, Promo-CD für Radio-Stationen usw.), so würden die Informationen über die Autoren oder das Erstellungsdatum in jedem Datensatz auftauchen. Dies vergrößert den Speicherbedarf der ganzen Datenbank und kann nur als Ausgangsmodell für ein relationales DBS verwendet werden. Über Normalisierungstechniken, die Sie in der nächsten Lektion kennen lernen werden, kann man systematisch eine optimierte Version dieser Universal Relation erhalten und so ein relationales Datenmodell entwickeln.Beispielhafte Daten
  5. Transformieren Sie das ER-Modell in das relationale Daten-Modell:
    • Ein Objekt bildet eine eigene Tabelle.
    • Die Datensätze sind die einzelnen Zeilen einer solchen Tabelle.
    • Die Attribute stellen die Spalten (Feldnamen) dar.
    • Ein Schlüssel ist ein spezielles Attribut, das einen Datensatz eindeutig identifiziert. Oft können die übrig bleibenden Attribute bei Entfernung eines Attributes einen Datensatz nicht mehr korrekt oder eindeutig identifizieren.
    • Der Wertebereich einer Spalte entspricht der Domäne, die dem Attribut zugeordnet wurde.
    • Eine Beziehung wird entweder über Fremdschlüssel oder über eine eigene Beziehungstabelle ausgedrückt.
    Relationales DatenmodellEs dürfte nicht allzu kompliziert oder schwer verständlich sein, dass das Objekt SONG eine Tabelle namens SONGS erhält, die als Spaltennamen songtitel, autoren und jahr aufweist. Um einen Song bzw. einen Datensatz (Zeile) einer Tabelle eindeutig zu identifizieren, verwendet man eine zusätzliche Spalte für den so genannten Primärschlüssel. Dies kann eine einfache, fortlaufende Nummer wie 25 oder ein komplexer Wert sein, der sich aus bestimmten Teilen wie eine ISBN-Nummer zusammensetzt. Dies verhindert, dass Songs mit gleichen Namen wie z.B. „Don´t leave me this way“ wirklich unterschieden werden. Zwar stammen beide Songs aus verschiedenen Jahren, doch die Spalte jahr kann unter keinen Umständen als Hilfe für die Identifikation eines Datensatzes dienen, da typischerweise mehr als ein Song pro Jahr aufgenommen wurde.
    Das RDM (relationale Datenmodell) beruht auf der Überführung der einzelnen Objekte im ER-Modell in Tabellen, die über die Primärschlüssel, die in der anderen Tabelle Sekundärschlüssel sind, in Beziehung stehen. Dieses Datenmodell wurde von E.F.Codd 1970 entwickelt und bildet die Grundlage für relationale Datenbanksysteme. In diesem Zusammenhang wird ein Datenmodell mit nur einer einzigen Tabelle und sämtlichen Informationen als Universal Relation bezeichnet.
  6. Spalten Sie die Beziehungen auf.
    Interessant und vielleicht sogar ein wenig überraschend im Vergleich zum vorhergehenden Schritt ist die Lösung des Beziehungsproblems, das oben kurz erläutert wurde. Zum einen existieren viele verschiedene Versionen des gleichen Titels in Live-Aufnahmen und Mixen, zum anderen wurden diese verschiedenen Versionen mehrfach auf unterschiedlichen Datenträgern veröffentlicht.
    Dem ersten Problem wird durch die Einrichtung einer Tabelle AUFNAHMEN Rechnung getragen. Diese Tabelle sammelt die einzelnen Attribute, die eine Aufnahme annahmegemäß eindeutig klassifizieren. Dazu gehören ein Titel aufntitel und ein aufntyp. Beide Spalten sollen gleichzeitig das Phänomen beschreiben, dass ein Song sowohl in mehreren Mixen als auch in mehreren Live-Aufnahmen vorliegt. Die Beziehung zwischen diesen Tabellen wird durch die Spalte songnr gewährleistet, die als Fremdschlüssel in die Tabelle AUFNAHMEN eingebunden wird.
    Tabellen SONGS und AUFNAHMEN
    Diese Aufnahmen sind auf verschiedenen Datenträgern veröffentlicht, sodass es am einfachsten ist, eine eigene Tabelle für dieses Phänomen einzurichten, die VEROEFFENTLICHUNGEN heißt. In ihr erhält jedes einzelne Vorkommen eines Songs auf einem Datenträger eine Veröffentlichungsnummer in der Spalte veroeffnr. Die Tabelle AUFNAHMEN wird dann über die Spalte aufnnr als Fremdschlüssel in der Tabelle VEROEFFENTLICHUNGEN verbunden.
    Tabellen VEROEFFENTLICHUNGEN und AUFNAHMEN
    Zum Schluss muss noch berücksichtigt werden, dass die Datenträger diejenigen Objekte sind, die die nur aus datenbanktechnischen Gründen eingeführten irrealen Objekte der Veröffentlichungen enthalten. Da jeder Datenträger ein abgrenzbares Objekt der realen Welt ist und über hinreichend viele Attribute auch klassifiziert werden kann, enthalten die Datenträger in diesem Datenmodell keine Songs mehr, sondern Veröffentlichungen. Diese Veröffentlichungen wiederum sind mit den Aufnahmen verbunden. In der Tabelle VEROEFFENTLICHUNGEN werden die Beziehungen zu der Tabelle DATENTRAEGER über den Fremdschlüssel datnr geleistet, während sich in der Tabelle DATENTRAEGER eine Spalte veroeffnr befindet. Die entstehende Tabelle bezeichnet man schlagwortartig mit dem Begriff Beziehungstabelle, da mit ihrer Hilfe eine m:m-Beziehung in zwei 1:n-Beziehungen aufgespalten wird.Tabellen VEROEFFENTLICHUNGEN und AUFNAHMEN und DATENTRAEGER
  7. Verhindern Sie Dateninkonsistenzen.
    Bisher hat sich die Erfassung der Plattensammlung von Tina Turner als reichlich komplex erwiesen. Mit einem letzten Schritt muss nun sichergestellt werden, dass die Daten korrekt eingetragen werden. Hierbei müssen entsprechende Konventionen aus realen Gegebenheiten abgeleitet werden, um die Daten konsistent zu machen. Nur so können Sie garantieren, dass Abfragen auch tatsächlich korrekt ablaufen. Zwei typische Konzepte helfen bei diesem Ziel:
    • Wertebereiche oder Domänen: So besteht der Wertebereich für die Spalte aufntyp lediglich aus den Werten {live, nicht live}. Per Entscheidung müssen dann Live-Aufnahmen, die im Tonstudio nachbearbeitet wurden, ebenfalls zu den Live-Aufnahmen zählen, da sie ihnen näher verbunden sind als reine Studio-Aufnahmen. Ebenfalls unter den Begriff „live“ subsumiert werden Fernsehauftritte, bei denen TT live gesungen hat. Da wiederum einige Konzerte im Fernsehen übertragen wurden, könnten hier Gefahrenquellen liegen, wenn eine eindeutige Zuordnung nicht sofort einsichtig ist. Ist daher von vorneherein bekannt, dass nur diese beiden Werte in der Spalte eingetragen sind, können Abfragen der Form „Zeige alle Song mit aufntyp=live“ korrekt abgearbeitet werden. Ähnliche Wertebereiche gelten für die Spalten datart und datunterart. Während Vinyl ein Material ist, das symbolisch für alle Tonträger stehen kann, die aus diesem Material gefertigt werden, muss allerdings in der datunterart unterschieden werden zwischen {maxi, single, LP}.
    • Namensdefinitionen: Sollen die Werte suchbar bleiben, was z.B. für Titel notwendig ist, dann kann man bei Namen, die nicht von vorneherein vorgegeben werden, sondern vom DB-Benutzer eingetragen werden, sich über Namenskonventionen behelfen. Dieses Problem stellt sich in der Tabelle AUFNAHMEN in der Spalte aufntitel. Mixe haben einen eindeutigen Namen, der vom Produzenten festgelegt ist und sich meistens auf einem Datenträger befindet.
      In den seltenen Fällen, in denen ein Mix zwar laut Datenträger existiert, sich aber in Wirklichkeit gar nicht als solcher oder als ein anderer entpuppt („Missing you“ und „On silent wings“-CD-singles aus Großbritannien, 1996), müsste man sich mit einem entsprechenden Kommentar z.B. in einer Klammer behelfen. Sämtliche Live-Aufnahmen jedoch müssen vom DB-Benutzer benannt werden, da sie von der Plattenfirma nicht mit einem informativen Namen versehen wurden. Hier könnte man folgenden Wertebereich mit einer Namensdefinition vorgeben: {stadt, land; land; kontinent; unbekannt}. Im günstigsten Fall kennt man also bei einer Live-Aufnahme die Stadt und das Land: „The best“ – Amsterdam, The Netherlands. In anderen Fällen besitzt man nur Informationen über das Land oder kann nur einen Kontinent zuordnen wie bei einigen Aufnahmen vom Live-Album „Live in Europe“. Da gleichzeitig eine Radioaufnahme der BBC existiert, kann man einige Aufnahmen dem Konzert in London, Wembley Arena zuordnen, während für alle anderen nur der Kontinent als Ortsangabe übrig bleibt. Mit Hilfe eines Jokerwerts wie unbekannt kann dann auch ein Titel vergeben werden, der sich über die Konventionsrichtlinien nicht ermitteln lässt.Namensdefinitionen für Wertebereich
  8. Testen Sie das Datenmodell durch beispielhafte Einträge.
    Es empfiehlt sich zusätzlich, lieber mit schlechten als mit guten Daten einen Testlauf zu machen, damit evtl. Fehler noch früh genug gefunden werden können. Schlechte Daten in diesem Zusammenhang sind vom DB-Entwickler aus der Prozessanalyse gewonnene Beispieldaten oder solche, die der Auftraggeber / Benutzer ihm als typische übermittelt hat. In jedem Fall sind es nicht die guten Daten, die nachher im normalen Arbeitsprozess, wenn alles funktionieren sollte, eingegeben werden. Mögliche Fehler, die insbesondere durch unerfasste Ausnahmeregelungen entstehen können, können Sie mit Testeinträgen versuchen zu entdecken. In diesem Fall sollte man also einen Titel wählen, der erstens auf sehr vielen Datenträgern erscheint, zweitens in Mixen und in Live-Aufnahmen vorliegt und drittens sogar noch als Duett mit Mixen vorhanden ist. In der Tabelle SONGS wird daher der einzelne Song nur einmal erfasst, wie es ja auch geplant war:
    songnr titel autoren Jahr
    25 The best Chapman / Knight 1989

    Für die Tabelle AUFNAHMEN ergeben sich bereits einige verschiedene Varianten, wobei die jeweils in den Tabellen angegebenen noch lange nicht der Realität entsprechen. Mit Hilfe der Songnummer können einzelne Aufnahmen identifiziert werden. Interessant ist hier, dass der aufntitel für die Solo-Fassung von 1989 laut Plattenfirmen der gleiche ist wie die Duettversion aus Australien. Als Auswahl aus den verschiedenen Live-Aufnahmen unterscheiden sich die beiden Fassungen sowohl im Datum als auch im Titel. Zwar hat TT sie beide in Deutschland gesungen, aber die Städte sind verschieden.
    aufnr songnr typ aufntitel duettpartner datum
    36 25 nicht live album version   1989
    37 25 nicht live single edit Jimmy Barnes 1993
    38 25   live germany, Munich   1998
    39 25   live germany, Hamburg   1996
    40 25 nicht live single edit   1989

    In der Tabelle VEROEFFENTLICHUNGEN testet man nun den komplizierten Fall der australischen Ausgabe des Albums „Simply the best“, das als Doppel-CD erschienen ist und zwei verschiedene Versionen von „The best“ enthält: Zum einen die single-edit-Version, die auch auf die europäische und amerikanische CD gepresst wurde, und zum anderen das Duett mit Jimmy Barnes. Alle Versionen existieren zusätzlich in gleicher Form auf CD-Singles, die hier nicht betrachtet werden.
    vnr aufnr datnr
    12 37 89
    13 36 90

    Zum Schluss führt die Tabelle DATENTRAEGER für beide Versionen zur richtigen CD. Da sowohl eine von der Plattenfirma vergebene Nummer für das CD-Paket als auch eine Nummer für jede einzelne CD vorliegt, wird die Reihenfolge der CDs durch die Spalte teil festgelegt. Das gesamte Paket kann man über die gleiche Packnummer abrufen.
    datnr vnr titel art unterart verlagnr Packnr Teil
    89 12 Simply The Best cd 5-inch TVD 93359 (TVD 53359) CDP 7979612 2 / 2
    90 13 Simply The Best cd 5-inch TVD 93349 (RMD 53349) CDP 7979612 1 / 2
    91 14 The best cd 3-inch CDP 506 (2034983)   1/ 1
    Comelio GmbH Datenbanken: Entity Relationship Modell Relationale Datenbanken Datenmodellierung Datenkonzeption SQL Anleitung Tutorial DBMS Datenbank Handbuch Relationale _Comelio GmbH Datenbanken: Entity Relationship Modell Relationale Datenbanken Datenmodellierung Datenkonzeption SQL Anleitung Tutorial DBMS Datenbank Handbuch Relationale _Comelio GmbH Datenbanken: Entity Relationship Modell Relationale Datenbanken Datenmodellierung Datenkonzeption SQL Anleitung Tutorial DBMS Datenbank Handbuch Relationale _Comelio GmbH Datenbanken: Entity Relationship Modell Relationale Datenbanken Datenmodellierung Datenkonzeption SQL Anleitung Tutorial DBMS Datenbank Handbuch Relationale _Comelio GmbH Datenbanken: Entity Relationship Modell Relationale Datenbanken Datenmodellierung Datenkonzeption SQL Anleitung Tutorial DBMS Datenbank Handbuch Relationale _Comelio GmbH Datenbanken: Entity Relationship Modell Relationale Datenbanken Datenmodellierung Datenkonzeption SQL Anleitung Tutorial DBMS Datenbank Handbuch Relationale _Comelio GmbH Datenbanken: Entity Relationship Modell Relationale Datenbanken Datenmodellierung Datenkonzeption SQL Anleitung Tutorial DBMS Datenbank Handbuch Relationale _Comelio GmbH Datenbanken: Entity Relationship Modell Relationale Datenbanken Datenmodellierung Datenkonzeption SQL Anleitung Tutorial DBMS Datenbank Handbuch Relationale _Comelio GmbH Datenbanken: Entity Relationship Modell Relationale Datenbanken Datenmodellierung Datenkonzeption SQL Anleitung Tutorial DBMS Datenbank Handbuch Relationale _
Seminare