2 oder 3 Tabellen....Performancegründe?

[Dickus]

Ahoi vonner Küste,
habe mal eine Frage bezüglich der Modellierung von Datenbanken.

Sorry, es wird sehr viel Text werden.

Ich entwickel meine DBs nach Möglichkeit immer zunächst im ERM/ERD
und erstelle daraus das relationale Modell.

Mir sind 6 Regeln bekannt, die eindeutig festlegen, bei welchen Beziehungen
es wie viel Tabellen geben sollte.

Aber vor Kurzem hatte ich ein Gespräch (ja fast schon ein Streitgespräch) über
folgenden Sachverhalt:

Es existieren drei Autofahrer und drei Autos. Allerdings fährt nicht jeder ein Auto
und somit wird auch nicht jedes Auto gefahren (z.B. wegen Werkstattaufenthalt)

Code: Alles auswählen

Dirk----------BMW Z4
Hans          Porsche 911
Franz---------Audi A6

Hans fährt kein Auto und der Porsche wird nicht gefahren.


In der ERM/ERD Schreibweise arbeite ich nicht nur mit der Chen-Notation (1:1 usw.)
sondern auch mit der Min-/Max Notation.

Code: Alles auswählen

---------- [0,1]          [0,1] ---------
| Fahrer |----------/\----------| Autos |
----------          \/          ---------
                   1:1


Also, ein Fahrer fährt mindestens KEIN Auto. Hans ist hier derjenige, der kein Auto fahren kann.
Maximal kann aber von einem Fahrer nur EIN Auto gefahren werden. Deswegen links oben: [0,1]
0 ist das Minimum und 1 das Maximum
Auf der rechten Seite ist das Minimum ebefalls 0, weil das Auto nicht zwingend gefahren werden
muss. Wenn aber ein Auto gefahren wird, dann von genau einem Fahrer.
Hier sind also beide Seiten optional bzw. nicht-obligatorisch.

Trotz dieser Situation handelt es sich immer noch um eine 1:1 Beziehung.

In dieser Konstellation können Leerfelder in den Tabellen entstehen. Wenn man nur mit zwei
Tabellen arbeitet, ist es sogar völlig egal welche PK als FK in der anderen Tabelle untergebracht
wird. Es entstehen definitiv Leerfelder.
Nur wenn man die Zuordnung in einer dritten Tabelle herstellt, gibt es keine Leerfelder und der
Entwurf sollte korrekt sein.

Code: Alles auswählen

Zunächst die beiden Tabellen

---------------          ---------------
| Fahrer (PK) |          | Autos (PK)  |
---------------          ---------------
| Dirk        |          | BMW Z4      |
| Hans        |          | Porsche 911 |
| Franz       |          | Audi A6     |
---------------          ---------------


Code: Alles auswählen

Nun lasse ich z.B. den PK der rechten Seite als FK auf die linke Seite wandern.
Man sieht, dass ein Leerfeld entsteht, weil Hans kein Auto fährt:
-----------------------------          ---------------
| Fahrer (PK) | Autos (FK)  |          | Autos (PK)  |
-----------------------------          ---------------
| Dirk        | BMW Z4      |          | BMW Z4      |
| Hans        |             |          | Porsche 911 |
| Franz       | Audi A6     |          | Audi A6     |
-----------------------------          ---------------


Code: Alles auswählen

Lasse ich hingegen den PK der linken Seite als FK auf die rechte Seite wandern, passiert
im Prinzip das selbe. Man sieht, dass ein Leerfeld entsteht, weil der Porsche 911 nicht
gefahren wird:
---------------          -----------------------------
| Fahrer (PK) |          | Autos (PK)  | Fahrer (FK) |
---------------          -----------------------------
| Dirk        |          | BMW Z4      | Dirk        |
| Hans        |          | Porsche 911 |             |
| Franz       |          | Audi A6     | Franz       |
---------------          -----------------------------


Erst wenn ich in einer dritten Tabelle die beiden PKs als FKs hineinehme und damit
die entsprechende Zuordnung treffe, kann ich die Leerfelder verhindern:

Code: Alles auswählen

---------------          -----------------------------          ---------------
| Fahrer (PK) |          | Fahrer (FK) | Autos (FK)  |          | Autos (PK)  |
---------------          -----------------------------          ---------------
| Dirk        |          | Dirk        | BMW Z4      |          | BMW Z4      |
| Hans        |          | Franz       | Audi A6     |          | Porsche 911 |
| Franz       |          -----------------------------          | Audi A6     |
---------------                                                 ---------------

Nachtrag. Hier habe ich in meiner dritten Tabelle (also die in der Mitte) den PK vergessen.
Da eine Spalte beide Attribute, nämlich FK UND PK annehmen kann, seien hier die FKs
auch gleichzeitig die PKs. In diesem Fall reicht sogar nur eine FK-Spalte als PK aus. ;-)


Nun ist u.a. das Problem der Leerfelder gelöst. Die Referentielle Integrität sollte auch
hergestellt sein, aber jetzt natürlich die Frage: LOHNT SICH DAS?
Sind Leerfelder egal?
Wie sieht es mit der Performance in der DB aus? (Wie kann man das messen?)
Ein Leerfeld benöigt Speicherplatz...eine neue Tabelle aber auch.
Lohnt sich dieser Ansatz erst ab 1000de von Einträgen?

Womit begründe ich im Kern den Einsatz von drei Tabellen?

Danke für Eure Geduld
Dickus

[SQL-BOSS]

Hi Dickus,

danke für deinen interessanten Beitrag. Ich habe selber in meinem Studium den Schwerpunkt auf DB gelegt.

Ich hab mir das gerade in Ruhe durchgelesen. Klar, die dritte Tabelle würde das Problem lösen und ich hielt es zuerst auch für schlüssig. Aber dann, ja, warum eigentlich keine Leerfelder? Man hat doch oft Tabellen, in denen Leerfelder vorkommen, weil zu einem Datensatz halt nicht alle Attributwerte vorhanden sind. Das sind dann halt NULL-Werte.

Ich kann dir nicht sagen, wie sich das auf die Performance auswirkt, ich habe selber noch nicht mit extrem großen Datenbeständen gearbeitet. Aber ich kann mir nciht vorstellen, dass es irgendwelche Auswirkungen hast, wenn du unter ein paar Tausend Datensätzen bleibst.

Wie gesagt, auch nur Vermutungen, technisch begründen kann ich es nicht. Und wie du schon sagst, die dritte Tabelle benötigt auch Speichersplatz. Und rein von der Logik her ja mehr Speicherplatz, als wenn Nullwerte gedulded werden.

Gruß,
SQL - Boss

[Dickus]

Hi SQL-Boss,
vielen Dank für die schnelle Antwort.
Eben habe ich meinen Eintrag noch ein bissel übersichtlicher gestaltet.
Scrollen in den Code-Ansichten ist nun nicht mehr nötig und bei den
drei Tabelle habe ich einen Hinweis bezüglich der PKs hinzugefügt.

Ja, wie Du schon sagst..warum, eigentlich nicht Leerfelder zulassen?
Ich halte das für eine höchst interessante Frage und werde nach weiteren
Informationen Ausschau halten.

[OFF]
Vielleicht ist es ähnlich wie mit Schriftarten. Die eine Seite sagt, dass auf
Internetseiten eine Serifen-Schrift (z.B. Times) eingesetzt werden sollte,
wobei hingegen in gedruckter Form grundsätzlich eine serifenlose Schrift
(z.B. Arial) benutzt werden sollte.
Ich glaube, dass das mittlerweile sogar der allgemeine Standard ist. Aber
auch heute gibt es eben auch dazu unterschiedliche Meinungen.
[/OFF]

Dickus

[SQL-BOSS]

Hi Dickus,

habe mir gerade nochmals deinen Beitrag durchgelesen, eine fundierte, begründete Position kann ich immer noch nicht einnehmen
Aber wie hast du dich denn jetzt entschieden?
Diese Datenbanktheorie kann einen ja auch zum Wahnsinn treiben

Gruß, SQL-Boss

[Dickus]

Moinsen,
also ich für meinen Teil bleibe bei drei Tabellen.
Die nächsten Tage werde ich beginnen, ein Beispiel
zu entwickeln, das sehr viele Datensätze enthält.
Dann schauen wir mal, wie schnell die verschiedenen
Variationen sind.

Vielleicht könnt Ihr ja auch mal einen Prof. um Rat
fragen. Mir ist das nämich erst kürzlich bekannt, dass
es da geteilte Meinungen gibt.

Dickus

[SQL-BOSS]

Hi,

halt mich mal aufm Laufenden
Meinen DB-Prof kann ich gerne mal fragen, allerings sind zur Zeit Semesterferien. Geht erst Ende März wieder los.

Gruß,
SQL-Boss

[Dickus]

Hört sich doch schon einmal gut an.
Vielleicht kann der Prof. da ein wenig
Aufklärung betreiben. ;-.)

Ach ja, das Beispiel, das ich entwickel
bezieht sich dann auf eine 1:1 Beziehung,
so wie hier auch gepostet.

Nachtrag: Ich werde mich auch noch einmal
mit Anomalien (Update-, Löschanomalie)
beschäftigen. Das könnte auch einer der
Gründe für drei Tabellen sein...mal sehen...

DIckus