Neuigkeiten:

Ist euer Problem gelöst, dann bitte den Knopf "Thema gelöst" drücken!

Mobiles Hauptmenü

Index und Normalisierung

Begonnen von crystal, Dezember 14, 2016, 13:30:37

⏪ vorheriges - nächstes ⏩

crystal

Hallo liebe Spezialisten,

nehmen wir eine Tabelle an, die u.a. eine Spalte mit einem numerischen Wert (long integer) aufweist. Bei 100.000 Datensätzen in der Tabelle finden wir z.B. 1000 unterschiedliche Werte in der betr. Spalte, die Kardinaltät beträgt also 1000 von 100.000.

Ist es nun richtiger, diese Werte zu normalisieren, indem ich sie in eine separate Tabelle auslagere, auf die wiederum mit einem numerischen Schlüssel (long integer) verwiesen wird
oder
wäre hier ein einfacher Index nicht ebenso geeignet, denn ein Index ist ja intern auch nichts anderes als eine Tabelle mit Verweisen.

Ist also letztlich die Definition eines Index auch ein Mittel der Normalisierung?

Wenn ich im Beispiel die long-integer-Spaltenwerte auslagere und dann wieder mit einem long-integer-Schlüssel referenziere, habe ich gegenüber einem Index doch nichts gewonnen, sondern im Gegenteil nur eine neue Tabelle erstellt, die eigentlich nicht viel bringt - oder?

Naja - eher eine akademische Frage. Es würde mich aber prinzipiell interessieren, wie hier die "Lehrmeinung" lautet.

lg
crystal
Wer Fehler in meinen Antworten findet, darf sie behalten, muss sie aber kommentieren. ;-)
Dies ist keineswegs arrogant gemeint, sondern soll nur unterstreichen, dass meine Antworten - natürlich - nicht immer fehlerfrei sind und sein können.
Devise: bitte immer erst selbst probieren!

Aus gesundheitlichen Gründen nur noch selten dabei...

PhilS

#1
Zitat von: crystal am Dezember 14, 2016, 13:30:37nehmen wir eine Tabelle an, die u.a. eine Spalte mit einem numerischen Wert (long integer) aufweist. Bei 100.000 Datensätzen in der Tabelle finden wir z.B. 1000 unterschiedliche Werte in der betr. Spalte, die Kardinaltät beträgt also 1000 von 100.000.

Ist es nun richtiger, diese Werte zu normalisieren, indem ich sie in eine separate Tabelle auslagere, auf die wiederum mit einem numerischen Schlüssel (long integer) verwiesen wird
Die essenzielle Frage in diesem Zusammenhang ist: Gibt es weitere Attribute in der Tabelle, die von deinem numerischen Wert abhängig sind?
Wenn ja, dann verlangen die grundlegenden Normalisierungsregeln (3.NF), dass diese abhängigen Attribute in eine weitere Tabelle ausgelagert werden und nur der Schlüssel in der ursprünglichen Tabelle verbleibt.

Wenn ich dich richtig verstanden habe, ist das aber hier nicht der Fall, sondern der numerische Wert steht für sich allein ohne jegliche Abhängigkeiten.

In diesem Fall gibt es meines Wissens keinerlei Regeln, die eine weitere "Normalisierung" vorschreiben.  - Meiner Meinung ist das in diesem Fall gar keine solche!

In der Praxis wäre das in diesem Fall sogar schädlich, weil ein Join auf eine weitere Tabelle immer teurer (=weniger performant) ist, als die erforderlichen Werte direkt aus der Haupttabelle zu lesen.

Zitat von: crystal am Dezember 14, 2016, 13:30:37oder
wäre hier ein einfacher Index nicht ebenso geeignet, denn ein Index ist ja intern auch nichts anderes als eine Tabelle mit Verweisen.
Ein Index ist kein Normalisierungswerkzeug. Was ein Index genau ist, ist von seiner internen Implementierung im jeweiligen DBMS abhängig. Im wesentlichen hast du zwar recht, aber es gibt durchaus Index-Typen (Bitmap, ColumnStore) die nicht der traditionellen Vorstellung eines (B-Tree)-Index entsprechen.
Du darfst nicht interne DBMS-Strukturen, deren genauer Aufbau ausserhalb deiner Kontrolle liegt, als Mittel des Datenbankmodellierung verwenden, wenn du dich dabei nicht auf dokumentierte, explizite Funktionalität beschränkst.

Zitat von: crystal am Dezember 14, 2016, 13:30:37Ist also letztlich die Definition eines Index auch ein Mittel der Normalisierung?
Meiner Meinung nach nein. Der Zweck von Normalisierung ist es u.A. (direkte oder indirekte) Abhängigkeiten im Datenmodell aufzulösen. Dies kann ein Index nicht leisten.
Neue Videoserie: Windows API in VBA

Klassische CommandBars visuell bearbeiten: Access DevTools CommandBar Editor