Suchen
Inside Wiki
Nützliche Links




 
phpforum.de bei Facebook
 
phpforum.de bei Twitter
 

Zurück   PHP Forum: phpforum.de > phpforum.de Wiki > phpforum.de Wiki

PHP Wiki Dieses Wiki sammelt Lösungen, zu Problemen, welche immer wieder im Forum auftauchen.

 
 
Artikel-Optionen Ansicht
  #1  

Standard Datenbanknormalisierung

 

Inhalte

Datenbanknormalisierung


Vorwort


Datenbanknormalisierung ist eigentlich ein schreckliches Wort. Normalisierung, das heißt Angleichung an die Masse und das ist wahrscheinlich die schlimmste Form der Gleichmacherei. Warum also diese Gleichmacherei? Meine Anwendung ist schließlich ein Kunstwerk für sich.

Nun, es haben sich ja schon recht viele Leute mit dem Thema Erstellung relationaler Datenbanken beschäftigt. Viele sind auf Probleme und Lösungen gestoßen, und natürlich wurde vieles davon auch publiziert.

Heraus gekommen ist ein Satz von Regeln, "Best Practices", wenn Ihr so wollt, für die Erstellung von Datenlayouts in relationalen Datenbanken. Ziel dieser Regeln ist es, Redundanzen zu vermeiden und einen effizienten Zugriff auf die Daten zu ermöglichen.

Warum Redundanzen vermeiden, werdet Ihr vielleicht fragen. Gut - die Frage ist berechtigt, schließlich ist fast nichts heutzutage so preiswert zu haben, wie Speicherplatz. Trotzdem darf hier nicht nur die Kostenfrage betrachtet werden, sondern es muss auch die Frage des schnellen Zugriffs gestellt werden. Wenn sich Eure Daten in tausendfacher Form an den unterschiedlichsten Stellen befinden, dann muss für jede Suche, für jede Veränderung und für das Hinzufügen jedes neuen Datenwertes ein überdimensionaler Aufwand getrieben werden.

Auch eine anderer Aspekt darf natürlich nicht vergessen werden, und das ist die Frage nach der referentiellen Integrität. Wenn eine Information an fünf Orten steht, dann wird bei einer Änderung schnell auch nur mal einer dieser Orte verändert. Folge sind Strukturprobleme innerhalb der Vernetzung der Daten.

All das - und natürlich die Spezialisierung, die sich mittlerweile in die technische Umsetzung relationaler Datenbankmanagementsysteme eingeschlichen hat - nimmt zwar auf den ersten Blick Freiheiten, auf lange Sicht hat sich die Einhaltung diverser Best Practices aber noch immer für jedes Projekt gelohnt und der Mehraufwand hat sich bisher noch immer rentiert.

Die fünf Normalformen. Oder waren es doch sieben?


Um mit den Inhalten einer Datenbank effizient umgehen zu können, haben sich - wie schon erwähnt - einige Best Practices, namens "Normalformen" etabliert. Diese Normalformen sind allerdings keine Regeln, die alle für sich alleine stehen, sondern die einzelnen Normalformen bauen aufeinander auf. Erfüllt eine Datenstruktur/ein Datenlayout die Normalform 2, so muss sie per Definition auch die Normalform 1 erfüllen, damit alle Kriterien für NF 2 gewahrt sind.

Essentiell für das Verständnis vieler der folgenden Definitionen ist das Verständnis der Begrifflichkeiten Key oder Schlüssel und funktionale Abhängigkeit. Erstere Begriffe werden Synonym verwendet und bezeichnen eine Möglichkeit, bestimmte Datensätze eindeutig zu identifizieren, der zweite wird zur Beschreibung von Logikzusammenhängen zwischen Datenworten innerhalb eines Datensatzes genutzt.

Tipp:
Eine gute technische Erklärung zur Nutzung von Schlüsseln in relationalen Datenbankmanagementsystemen bietet dieses Online-Buch.


Historisch gehen zumindest die ersten 3.5 der im folgenden näher beschriebenen Normalformen auf den Englischen Computerwissenschaftler Edgar F. Codd zurück, die höheren auf die Arbeiten und Publikationen anderer Fachleute, die sich aber zumindest an der Arbeit von Codd orientieren.

In der Praxis relevant sind hauptsächlich die Normalformen eins bis drei, sowie die Boyce-Codd-Normalform. Ein beharren auf die letzten drei Normalformen (4, 5 und 6) ist in der Fachwelt teilweise umstritten, da ihre Anwendung teilweise zu Performance-Problemen im praktischen Einsatz führt.

Das macht die letzten Normalformen allerdings um nichts weniger wichtig. Der generelle Konsens ist wohl, dass auch diese berücksichtigt werden sollten, sofern keine explizite technische Anforderung das aktuellen Anwendungsfalles sie verhindert.

Alle anderen sprechen immer von fünf Normalformen. Warum spricht dieser Artikel von sieben?

Die Begründungen dafür sind denkbar einfach:

Eine der Normalformen - die Boyce-Codd-Normalform - liegt im Sprachgebrauch völlig außerhalb des gewöhnlichen Zählschemas, da viele in ihr einfach nur eine Erweiterung einer bestehenden Normalform sehen.

Das lässt Normalform 6 - diese gewinnt erst seit 2002 Bekanntheitsgrad. Sie kommt allerdings aus einigermaßen berufenem Munde, deshalb wird sie hier der Vollständigkeit halber mit aufgeführt. Ob sie sich in der Praxis durchsetzt? Wir werden sehen.

Nun wollen wir uns die unterschiedlichen Normalformen und Regeln mal im Detail anschauen und mit kleinen Beispielen versehen:

1. Normalform


Definition
In jede Spalte einer Tabelle kommt exakt eine Information, also etwas, das nicht sinnvoll in kleinere Teile zerlegt werden kann.
Beispiel I
Die Adresse "12345 Kleindödelhausen, Hauptstraße 123" steht in einem Textfeld "adresse" innerhalb einer Tabelle.
Zweck/Grund
Selektionen auf Teilinformationen - z.B. "alle Kunden aus Kleindödelhausen" - sind nicht mehr effizient/einfach durchführbar, wenn alle diese Informationen in einer Spalte stehen.

Nehmen wir an, wir haben eine Adresse "Stuttgarter Straße 29, 59067 Hamm" und eine Adresse "Dorfstraße 3, 70173 Stuttgart". Würden wir jetzt daraus alle Adressen in Stuttgart ermitteln wollen, so wäre das nur mit sehr großem Aufwand möglich. Eine Suche adresse LIKE '%Stuttgart%' würde offensichtlich ja auch die Adresse aus Hamm zurück liefern. Der naive Ansatz geht also nicht.
Lösung:
Die Adresse sollte in vier bis fünf Spalten abgelegt werden:
Land (Optional)PLZOrtStrasseHausnummer
Deutschland59067HammStuttgarter Straße29
Deutschland70173StuttgartDorfstraße1
Übliche Abfragen, wie die nach allen Adressen eines Ortes sind dann leicht realisierbar:
MySQL Quellcode:
SELECT
  Land,
  PLZ,
  Ort,
  Strasse,
  Hausnummer
FROM
  tabelle
WHERE
  Ort = 'Stuttgart'

Beispiel II:
Ein gern gemachter Anfängerfehler ist es, Kommaseparierte Werte in einer einzelnen Spalte der Tabelle zu platzieren. Nehmen wir an, wir wollen eine Liste von Fußballspielern, inklusive Ihrer Positionen erstellen. Häufig entsteht dabei dann so etwas hier:

Spieler
lfdNrNachnameVornamePositionen
1TorlosToniTorwart, Verteidiger
2KnochenbrecherKasimirInnenverteidiger, defensiver Mittelfeldspieler
3LeichtfußLuigirechter Verteidiger, linker Verteidiger, Innenverteidiger
Auf den ersten Blick sieht das recht schlank und übersichtlich aus. Neben der Verletzung der ersten Normalform stellt uns das ganze aber vor ein ziemliches Problem. Stellt Euch vor, alle Spieler der Bundesliga wären so in einer Tabelle abgelegt. Jetzt wollen wir von unserer Datenbank wissen, wie viele Innenverteidiger es in unserer Tabelle gibt.

Okay - gehen wir mal ganz naiv an die Sache heran:

SQL Quellcode:
SELECT
  COUNT(lfdNr) AS anzahl
FROM
  spieler
WHERE
  position LIKE '%Innenverteidiger%'


oder alternativ (und nur für das häufig genutzte MySQL):

MySQL Quellcode:
SELECT
  COUNT(lfdNr) AS anzahl
FROM
  spieler
WHERE
  FIND_IN_SET('Innenverteidiger',position)


Oder lasst uns versuchen zu Zählen, wie viele Spieler es mit zwei oder mehr unterschiedlichen Positionen es gibt:

MySQL Quellcode:
SELECT
  COUNT(lfdNr) AS anzahl
FROM
  spieler
WHERE
  (LENGTH(position)-LENGTH(REPLACE(position,',','')))>=1


Damit ist unsere Datenbank dann eine ganze Weile beschäftigt. Wenn Ihr dem Link zur technischen Realisierung von Indexes oben gefolgt seid, dann wisst Ihr jetzt auch warum. Es ist nämlich so, dass die meisten Datenbankmanagementsysteme in solchen Fällen keinen Index nutzen kann.

Ein Index - auch das wisst Ihr jetzt wahrscheinlich schon - ist eine Art Suchkatalog für Daten, der es der Datenbank erspart, jeden Datensatz einzeln anzuschauen. Stellt es Euch vor, wie in einem Lexikon - auch dort gibt es meist einen Appendix mit Inhaltsverzeichnis, der Eure Suche im Buch verschnellern kann.

Es kommt aber noch viel schlimmer. Nehmt an, die Datenbank "lebt" eine Weile. Jetzt hat Toni Torlos zwar seit fünfzehn Jahren im Tor gestanden, Verteidiger hat er aber seit er fünfzehn war nicht mehr gespielt. Wir wollen also die Verteidigerposition aus dem Datensatz des Spielers entfernen.

Spätestens an dieser aufwendigen Abfrage (am Beispiel von MySQL) werdet Ihr sehen, dass das gar nicht so einfach ist:

MySQL Quellcode:
UPDATE
  spieler
SET
  position=REPLACE( /* für Vorkommen in der Mitte und am Ende der Liste */
                    REPLACE( /* für Vorkommen am Anfang der Liste */
                             position,
                             ' Verteidiger,',
                             ''
                           ),
                    ', Verteidiger',
                    ''
                    )
WHERE
  name='Torlos'
  AND vorname='Toni'


Wir betreiben hier also einen riesigen Aufwand, sowohl zum Finden des Wertes, als auch zum Ändern des jeweiligen Datensatzes.
Lösungsansatz I zu Beispiel II

Gut - jetzt wissen wir, aggregierte Informationen innerhalb einer Spalte sind nicht die schlaueste aller Ideen. Wie sieht es also aus, wenn wir einfach ein paar durchnummerierte Spalten vorhalten und diese dann mit den einzelnen Positionen befüllen?

Spieler
lfdNrNachnameVornamePosition1Position2Position3
1TorlosToniTorwartVerteidiger
2KnochenbrecherKasimirInnenverteidigerdefensiver Mittelfeldspieler
3LeichtfußLuigirechter Verteidigerlinker VerteidigerInnenverteidiger
Das widerspricht zumindest nicht Codd's Definition der ersten Normalform. Diese Definition verlangt nur die atomizität des Attributs, also dass innerhalb einer Spalte auch nur ein Wert vorkommen kann und darf.

Auch die Normalformen entwickeln sich allerdings weiter und einige relevante Autoren (z.B. Christopher J. Date) haben diese Definition schon viel enger ausgelegt.

Wir wollen uns hier nicht mit den Gelehrten streiten, deshalb konzentrieren wir uns mal auf die technischen Hintergründe, warum der oben gezeigte Ansatz ziemlich problematisch ist und warum es - da ist sich die Fachwelt dann wieder ziemlich einig - diesen Ansatz zu vermeiden gilt.

Nehmen wir an, wir brauchen plötzlich mehr als nur die drei oben gezeigten Positionen, weil ein Spieler nun mal universeller einsetzbar ist:

Jetzt nur die Tabelle anzupassen ist einfach. Konsequenter Weise müssen wir jetzt allerdings auch ran an die Applikation und alle unsere SELECT, UPDATE und INSERT Statements anfassen. Kein schöner Arbeitsaufwand, wie ihr Euch wahrscheinlich denken könnt.

Schauen wir uns das mal an und gehen wir die oben genannten Anwendungsfälle mal Beispielhaft durch:

Anzahl aller Innenverteidiger:
SQL Quellcode:
SELECT
  COUNT(lfdNr) AS anzahl
FROM
  spieler
WHERE
  'Innenverteidiger' IN(position1,position2,position3)


Alle Spieler mit mehr als 2 Positionen:
MySQL Quellcode:
SELECT
  COUNT(lfdNr) AS anzahl
FROM
  spieler
WHERE
  IFNULL(position1,0,1)+IFNULL(position2,0,1)+IFNULL(position3,0,1)>=2


Toni Torlos ist kein Verteidiger mehr:
MySQL Quellcode:
UPDATE
  spieler
SET
  position1=IF(position1='Verteidiger', /* wenn 1. Feld zu ändern */
               position2, /* Feld 2 "nach links schieben" */
               position1  /* ansonsten Feld 1 belassen */
               ),
  position2=IF(positon1='Verteidiger'
               OR position2='Verteidiger', /* wenn 1. oder 2. Feld zu ändern */
               position3, /* Feld 3 "nach links schieben" */
               position2  /* ansonsten Feld 2 belassen */
               ),
  position3=IF(positon1='Verteidiger'
               OR position2='Verteidiger'
               OR position3='Verteidiger', /* Wenn 1., 2. oder 3. Feld zu ändern */
               null,      /* 3. Feld leeren */
               position3  /* ansonsten Feld 3 belassen */
               )
WHERE
  name='Torlos'
  AND vorname='Toni'  /* aber nur beim gesuchten Spieler */


Es sollte offensichtlich sein, dass man a) den Aufstand nicht wirklich betreiben möchte und b) dass man auch so seine Datenank ganz schön sinnlos beschäftigen kann.

Abgesehen davon: Wiederholungsgruppen verstehen sich nicht mit den Normalformen, die im weiteren Verlauf dieses Artikels erklärt werden.

Also:
Warnung:
Lasst bloß die Finger davon!
Lösungsansatz II zu Beispiel II
Zwei Tabellen, eine für die Positionen und eine für die Spieler sind hier der Weg, der keiner bekannten Definition der ersten Normalform wiederspricht:

Spieler
lfdNrNachnameVorname
1TorlosToni
2KnochenbrecherKasimir
3LeichtfußLuigi
Position
SpielerNrPosition
1Torwart
1Verteidiger
2Innenverteidiger
2defensiver Mittelfeldspieler
3rechter Verteidiger
3linker Verteidiger
3Innenverteidiger
Ganz abgesehen davon, handelt man sich auch weitaus weniger technische Probleme ein, mit diesem Datenmodell:

Anzahl aller Innenverteidiger:
SQL Quellcode:
SELECT
  COUNT(SpielerNr) AS anzahl
FROM
  Positionen
WHERE
  position='Innenverteidiger'


Anzahl aller Spieler mit mehr als 2 Positionen:
MySQL Quellcode:
SELECT
   COUNT(*)
FROM
(
  SELECT
    spielerNr,
    COUNT(position) AS anzahl
  FROM
    spieler
  GROUP BY
    spielerNr
  HAVING
    anzahl>=2
) s


Toni Torlos ist kein Verteidiger mehr:
MySQL Quellcode:
DELETE p
FROM
  spieler s INNER JOIN position p
    ON s.lfdNr=p.spielerNr
WHERE
  s.name='Torlos'
  AND s.vorname='Toni'
  AND p.position='Verteidiger'


Das sieht doch gleich viel einfacher aus, oder?

2. Normalform


Definition
Alle Daten, die nicht Teil des Keys sind, hängen von allen Key-Attributen ab.
Beispiel
In einer Tabelle mit den Spalten "KundenNr", "BestellNr", "KundenName", "KundenAlter" und "Artikel" liegt ein Key auf KundenNr und BestellNr. (Im Beispiel kursiv gekennzeichnet)

KundenNrBestellNrKundennameKundenAlterArtikel
11Hans Dampf18Brotdose
112Hans Dampf18Schnuller
223Reiner Zufall78Krückstock
223Reiner Zufall78Rollator
Damit wird die zweite NF verletzt, da "KundenName" und "KundenAlter" nur von der KundenNr abhängen, nicht aber direkt von "BestellNr".
Zweck/Grund
Es werden Datenintegritätsverletzungen durch Redundanz möglich, wie z.B. zwei Einträge mit gleicher KundenNr, aber unterschiedlichem KundenNamen oder zwei identische Kunden mit unterschiedlichem Alter.

Außerdem ist zu beachten, dass viel mehr Datensätze angefasst werden müssen, sollte sich ein Name oder Alter mal ändern. (So dann und wann passiert sowas ja durchaus mal. )
Lösung:
Alle Spalten entfernen, die nur von einem Teil des Keys abhängen und in eine eigene Tabelle auslagern. Für das Beispiel oben ergibt sich damit dieses Bild:

Kunden
KundenNrKundennameKundenAlter
1Hans Dampf18
2Reiner Zufall78
Bestellpositionen
BestellNrKundenNrArtikel
11Brotdose
121Schnuller
232Krückstock
232Rollator
Änderungen an Kundendaten können damit dann immer an einer Stelle ausgeführt werden, ohne dass alle bestellten Artikel überhaupt auch nur angesehen werden müssen.

3. Normalform


Definition
Es gibt keine transitiven ("mehrstufigen") Abhängigkeiten zwischen den Nicht-Schlüssel-Spalten einer Tabelle.
Beispiel
In einer Datenbank sollen die Gewinner des jährlich stattfindenden Sportturniere des alt-erwürdigen Klein Kleckersdorfer Hampel-, Hüpf und Springvereins verwaltet werden.

Hierzu liegt der folgende Tabellenentwurf vor:

Gewinner
TurnierJahrGewinnerGeburtsdatum
Jährliches Hüpfen2012Hans Dampf03.12.1994
Bierglasweitwurf2012Hans Dampf03.12.1994
Jährliches Hüpfen2011Reiner Zufall23.01.1934
Bierglasweitwurf2011Hans Dampf03.12.1994
Als Schlüssel wurden der Turniername und das Jahr der Austragung gewählt. Hier ist klar ersichtlich, dass auch zwischen dem Gewinner und seinem Geburtsdatum (beide nicht Teil des Schlüssels) eine Abhängigkeit besteht.

Normalform 3 lässt diese Abhängigkeit nicht zu, da allerdings alle Attribute zumindest immer auch vom vollständigen Primärschlüssel abhängen, ist Normalform 2 nicht verletzt.
Lösung
Zerlegung der o.g. Tabelle in zwei - einmal die Personen, samt ihrer Attribute, und auf der anderen Seite das Turnier, das Jahr und eine Verknüpfung zur Person:

Gewinner
TurnierJahrPersonID
Jährliches Hüpfen20121
Bierglasweitwurf20121
Jährliches Hüpfen20112
Bierglasweitwurf20111
Personen
PersonIDNameGeburtsdatum
1Hans Dampf03.12.1994
2Reiner Zufall23.01.1934
Tipp:
Ob Ihr das soweit verstanden habt, könnt Ihr z.B. anhand von diesem kleinen Online-Quiz ja mal testen.

Boyce-Codd-Normalform (BCNF)


Definition
Die Boyce-Codd-Normalform ist eine strengere Variante der 3.Normalform: jede Spalte, von der eine andere (funktional) abhängig ist, ist Teil des Keys.

Chris Date hat das mal wie folgt recht sprechend formuliert:
Zitat:
Each attribute must represent a fact about the key, the whole key, and nothing but the key.
damit bezieht er sich auf die Steilvorlage von Bill Kent zur 3. Normalform:

Zitat:
Every non-key attribute must provide a fact about the key, the whole key, and nothing but the key.
Der Unterschied dürfte offensichtlich sein: Während die dritte Normalform ihre Einschränkung nur für Nicht-Schlüssel definiert, gelten für die BCNF stärkere Gesetze, da sich auch die Schlüssel der genannten Anforderung beugen müssen.
Zweck/Grund
Beseitigung aller restlichen, redundanten Informationen und Ersatz durch geeignete Relationen.
Beispiel
In der Lösung zur 2. Normalform haben wir einen solchen Fall:
Kunden
KundenNrKundennameKundenAlter
1Hans Dampf18
2Reiner Zufall78
Bestellpositionen
BestellNrKundenNrArtikel
11Brotdose
121Schnuller
232Krückstock
232Rollator
Hier existiert eine Abhängigkeit von KundenNr zu BestellNr - wenn auch nicht aus dem Schema, aber aus den Daten heraus. Die dritte Normalform untersagt diese Abhängigkeit nicht, denn sie bezieht sich ausschließlich auf Attribute, die nicht Teil eines Schlüssels oder Schlüsselkandidaten sind.
Lösung
Abhängigkeiten, die nicht in der Form "Attribut hängt ab von Key" sind, in eine separate Tabelle (inkl. der abhängigen Attribute) auslagern. Also:

Kunden
KundenNrKundennameKundenAlter
1Hans Dampf18
2Reiner Zufall78
Bestellungen
BestellNrKundenNr
11
121
232
Bestellpositionen
lfdNrBestellNrArtikel
11Brotdose
212Schnuller
323Krückstock
423Rollator

4. Normalform


Definition
Alle voneinander vollständig unabhängigen Attribute werden in getrennten Tabellen gehalten.

Diese Normalform geht auf Ronald Fagin zurück. Hier findet Ihr seine Einführung im Englischsprachigen Original..
Beispiel:

Familien
FamilieVornameKindWohnort
DampfHansHamm
ZufallReinerStuttgart
verletzt diese Regel, da es nicht möglich ist, ein Kind anzulegen, ohne einen (neuen?) Ort einzutragen.
Lösung:
Aufteilung in
Kinder
FamilieVornameKind
DampfHans
ZufallReiner
und
Wohnorte
FamilieWohnort
DampfHamm
ZufallStuttgart

5. Normalform


Definition
Keine Relation läßt sich in (noch) einfachere Relationen zerteilen, ohne Informationen zu verlieren.

Anders formuliert: es werden nicht mehrere Abhängigkeiten in einer Tabelle erfaßt, wodurch konkrete (mehrstufige) Zuordnungen entstehen. Statt dessen werden alle Relationen in eigene Tabellen zerteilt, wodurch sich teilweise Optionen ergeben, die vorher nicht in der konkret erfaßten Datenstruktur abgebildet waren.

Es wird hier also klar auf die Maximierung der durch die Relationen definierten Optionen gezielt.

Und jetzt? Muss das wirklich alles sein?


Das war evtl. etwas schwer verständlich, hier ist eine ausführlichere Variante, die aber auch noch ziemlich akademisch ist. Und Nein, natürlich muss das nicht alles sein. Das geschriebene sind "Best Practices", von denen man in konkreten Fällen manchmal durchaus auch abweichen kann und muss. Trotzdem hat sich etabliert, zumindest die ersten drei der o.g. Normalformen als Qualitätsmaßstab für ein Datenlayout zu interpretieren. Sollte Deine eigene Datenstruktur also eine dieser Regeln verletzen, dann ist es spätestens jetzt an der Zeit, etwas dagegen zu tun.

Zum besseren Verständnis der Materie sei Euch insbesondere das Anfänger freundliche Kapitel Datenbanken entwickeln aus DSP: Datenbank, MySQL und PHP von Christoph Reeg und Jens Hatlak, sowie der oben schon einmal angesprochene Wikipedia-Artikel zum Thema Normalisierung von Datenbanken ans Herz gelegt. Ebenfalls gut zu lesen sind die Ausführungen von Prof. Dr. Staud von der HS Weingarten zum Thema Relationale Datenmodellierung.

Auch ganz unterhaltsamer Lesestoff - wenn auch teilweise nicht grade für Laien geschrieben - ist Codd's Buch The Relational Model for Database Management (ISBN 0-201-14192-2). Immer wieder stolpert man auch über Temporal Data & the Relational Model von C.J. Date, Hugh Darwen und Nikos Lorentzos (ISBN 1-55860-855-9), zu dessen Qualität der Autor dieses Tutorials allerdings nicht viel erhellendes von sich geben kann.

Jetzt komm ich aber viel schwerer an meine Daten wieder ran!


Tja, der liebe Zugriff...

Natürlich ist es auf den ersten Blick einfacher, wenn alle Daten in einer Tabelle stehen und man mit einem einfachen SELECT ohne viel Fachkenntnisse auf diese Zugreifen kann. Andererseits sind die heutigen relationalen Datenbankmanagementsysteme aber auf genau die in den Normalformen beschriebenen strukturiert verteilten Informationen ausgelegt und können damit für gewöhnlich sehr gut um.

Um dem DBMS jetzt allerdings begreiflich machen zu können, welche Daten in welcher Form abgefragt oder verändert werden sollen, bedarf es ein bisschen Kenntnissen in SQL.

Zumindest mit ein bisschen relationaler Algebra und mit der Theorie von SQL Joins werdet Ihr Euch auseinander setzen müssen, wenn das ganze funktionieren soll.

Wenn Ihr das allerdings hinter Euch habt, dann werdet Ihr schnell merken, dass viele Dinge unter Berücksichtigung der oben beschriebenen Prinzipien nicht nur einfacher, sondern auch bei weitem weniger Fehleranfällig umsetzbar sind.

Ganz abgesehen davon, seid Ihr hier ja aber auch in einem Forum. Wenn Ihr also Probleme bei der Umsetzung Eurer Abfragen auf eine normalisierte Datenstruktur habt, dann findet sich sicherlich hier auch schnell jemand, der Euch bei der Lösung hilft.

Tipp:
Weitere Informationen findet Ihr außerdem in den Tutorials A Visual Explanation of SQL Joins und SQL und relationale Algebra.


Mitwirkende: Jens Clasen, Synopsis, combie
Erstellt von Synopsis, 10.11.2011 am 09:17
Zuletzt bearbeitet von Jens Clasen, 19.04.2013 am 07:54
0 Kommentare , 33874 Betrachtungen

Dieser Text steht unter der GNU-Lizenz für freie Dokumentation


 

Lesezeichen

Artikel-Optionen
Ansicht

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.

Gehe zu

Alle Zeitangaben in WEZ +2. Es ist jetzt 05:35 Uhr.


Powered by vBulletin® Version 3.8.8 (Deutsch)
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Powered by NuWiki v1.3 RC1 Copyright ©2006-2007, NuHit, LLC