Tabelle sinnvoll normalisieren

[b2907377]

Hallo

Bereits seit längerem versuche ich eine Tabelle, in der ich Immobilienobjekte speichere, zu normalisieren und weiss einfach noch nicht ganz wie ich dies am Besten bewerkstelligen soll. Derzeit enthält die Tabelle etwa 60 Felder, was wohl zu viele sind. Ich nutze bereits viele andere Tabellen, die eine Referenz bzw. Verknüpfung zu einer anderen herstellen, damit in der Tabelle wo die Objekte sind nur noch per ID referenziert wird. Also z.B. Objektart und Objekttype etc..

Also. Die Tabelle für Immobilienobjekte gilt es nun zu normalisieren, bzw. aufzuteilen. Dort sind unteranderem Felder wie "Titel, Strasse, Nr., PLZ, Ort, Land-ID, einige Referenz IDs (in dessen Tabellen Werte dann die ID referenzieren), zahlreiche Preisfelder (Verkaufspreis, Miete, Kaution, etc.), Flächenfelder (Wohnfläche, Nutzbare Fläche, Grundstücksfläche, etc.), Felder für numerische Werte (z.B. Anzahl Zimmer, Anzahl Toiletten, Anzahl Schlafzimmer, etc.), dann noch Textfelder für Beschreibungen und weitere Datenfelder.

Mir wurde nun klar das man, auch wenn ich alles rundherum was die Verbindung mit den Objekten angeht (Referenzwerte wie Objektart etc., Objekt-Dateien, Ausstattungen, Distanzen, usw.) bereits normalisiert habe (etwa 20 Untertabellen gibt es dafür schon) - ich nun auch die Immobilien-Tabelle selbst normalisieren sollte bzw. muss. Für mich stellt sich nun aber die ernste Frage: Wie genau sollte ich es tun um den besten und sinnvollsten Weg zu gehen?

Ich dachte mir nun ich normalisiere die Immobilien Tabelle wie folgt und erzeuge einzelne Tabellen:

REFERENZ-TABELLEN
(Diese Tabellen enthalten jeweils nur die Referenzwerte der eigentlichen Datentabellen. Also die Werte, wo man später dann sieht was die Datenwerte repräsentieren, wie z.B. Verkaufsfläche, etc.)
- Preisangaben (Verkaufspreis, Miete, Kaution, etc.)
- Flächenangaben (Wohnfläche, Nutzbare Fläche, Grundstücksfläche, etc.)
- Einheiten (m2, m3, m, cm)
- Numerische Angaben (Anzahl Zimmer, Anzahl Toiletten, Anzahl Schlafzimmer, etc.)
- Texte (Beschreibung des Objektes, Beschreibung der Innenausstattung, Beschreibung der Aussenausstattung, Sonstiges, etc.)

DATEN-TABELLEN
(Diese Tabellen enthalten dann mit Referenz zum Objekt (Objekt-id) und den REFERENZ-TABELLEN (per ID), die eigentlichen Daten. Also z.B. Zahlenwerte bei den Preisangaben, Flächenangaben und Strings bei den Texten etc.)
- Preisangaben
- Flächenangaben
- Numerische Angaben
- Texte


Da es meiner Meinung nach zwei Arten der Tabellenkonstruktion gibt, nämlich:

a) Statische echte Felder, deren Name Programm ist und...
b) Dynamische Felder repräsentiert werden, indem man zwei echte Felder benutzt wobei das erste Feld eine ID zur Referenz-Tabelle benutzt und das zweite Feld den Wert dafür. Dies führt dann dazu das jede Zeile exakt ein Attribut wiederspiegelt (dynamisch), also anders als die statische Version von a), da dort bereits eine Zeile alle möglichen Attribute miteinbezieht, wobei aber nicht alle gezwungenermassen benutzt sein müssen.

Nun meine Fragen:

1) Klingt das alles ganz gut was ich hier schreibe und kann ich dies so umsetzen, oder sollte ich komplett anders ansetzen?
2) Gibt es bei den bereits vorgenommenen Normalisierungen (siehe oben) etwas zu bemängeln?
3) Welche Variante der Tabellenkonstruktion (a oder b) ist sinnvoller? Leider weiss ich nicht wie man diese beiden Varianten im Fachausdruck nennt. Ich tendiere aber bei meinem Vorhaben zur dynamischen Variante, weil es meiner Meinung nach sinnlos ist, statische Felder in einer Tabelle zu setzen (z.B. in Flächen), wenn gar nicht klar ist, welche Flächen davon genutzt werden. So macht es für mich mehr sinn, dafür zwar mehrere Zeilen für ein einziges Objekt in einer dynamischen Tabelle zu halten, dafür aber explizit mit den Daten die genutzt werden.

Weitere Fragen folgen dann, sobald ich weiss wie ich endlich weitermachen soll :). Vielen Dank schon mal!

[thomas_w]

Zitat von b2907377

Nun meine Fragen:

1) Klingt das alles ganz gut was ich hier schreibe und kann ich dies so umsetzen, oder sollte ich komplett anders ansetzen?
2) Gibt es bei den bereits vorgenommenen Normalisierungen (siehe oben) etwas zu bemängeln?
3) Welche Variante der Tabellenkonstruktion (a oder b) ist sinnvoller? Leider weiss ich nicht wie man diese beiden Varianten im Fachausdruck nennt. Ich tendiere aber bei meinem Vorhaben zur dynamischen Variante, weil es meiner Meinung nach sinnlos ist, statische Felder in einer Tabelle zu setzen (z.B. in Flächen), wenn gar nicht klar ist, welche Flächen davon genutzt werden. So macht es für mich mehr sinn, dafür zwar mehrere Zeilen für ein einziges Objekt in einer dynamischen Tabelle zu halten, dafür aber explizit mit den Daten die genutzt werden.

Weitere Fragen folgen dann, sobald ich weiss wie ich endlich weitermachen soll :). Vielen Dank schon mal!

Ohne sich intensiv mit dem Projekt zu beschäftigen, kann ich Dir die Fragen im Speziellen nicht beantworten, deshalb etwas allgemeiner:

- 60 Spalten pro Tabelle sind etwas viel, dass stimmt schon
- Normalisierung bedeutet aber auch Performanceverlust beim (UPDATE, INSERT, DELETE)
- Soll die Tabelle(n) beim Lesen oder Schreiben schnell sein, beides geht nicht.
- Dein Beispiel REFERENZ-Tabellen sieht etwas nach "Star-Design" und DataWarehouse aus. Das wäre dann Lese- und Auswertungsoptimiert.
- allgemein geht auch eine Normalisierung mit Hilfe von 1:1 verknüpften Tabellen. Dann werden die Spalten verschiedene Datengruppen aufgeteilt (z.B. Adresse der Immobilie, Interessenten, technische Daten)

Soweit mal ein paar Gedanken dazu.

Grüße
Thomas

[Ckaos]

Hi

Zitat von b2907377

Derzeit enthält die Tabelle etwa 60 Felder, was wohl zu viele sind.

Sagt dir wer?
Ich denke das ist ansichtssache. Ich finde >100 viel. Es gibt nunmal
Situationen wo es zu einem Datensatz soviele Attribute gibt. Ich denke
da aber nicht an Immobilien ;)

Wie und ob deine Datenbank normalisiert werden soll / muss, kann meiner
Meinung nach nur deine Anforderung an diese entscheiden, sprich die
spätere Verwendung. Einzubeziehen sind ebenso Administrative Anforderungen. siehe thomas_w

Normalisierung bedeutet aber auch Performanceverlust beim (UPDATE, INSERT, DELETE)

Bsp.

Zimmeranzahl deiner Objekte soll in einer schnellsuche verarbeitet werden
genauso wie die Gesamtqm. Bei einer Suche auf den ganzen Datenbestand (vielleicht 100.000 objekte) würde diese mit Normalisierter
Tabelle einen JOIN vorraussetzen (Zimmertabelle mit Attributen Objektid,Name,qm usw). Denormalisiert nur 2 indexe auf Zimmeranzahl und Gesamtqm.

Das ist eine Optimierungen im milisekundenbereich aber abhängig von
deiner Anforderung.

mfg

CKaos

[b2907377]

Hallo und danke für eure Beiträge. Ich habe nun ein Diagram erstellt um zu verdeutlichen was ich genau vorhabe. Vielleicht könnt ihr mir dann sagen ob das so Sinn macht und wenn nein, warum nicht. Das Bild gibt es hier

[thomas_w]

Auf den ersten Blick fällt mir folgendes auf:

- Tabellen mit einer Spalte sind nicht oder wenig sinnvoll
- Spalten wie "Preisangabe" und VARCHAR als Datentyp sind massiv fehleranfällig (eher DEC(10,2) ..)

Grüße
Thomas

[b2907377]

Hallo thomas_w und danke für Dein Posting. Wahrscheinlich ist es Dir nicht aufgefallen, aber die Referenz-Tabellen haben explizit diesen Zweck, das Sie mit VARCHAR die id Werte von den Daten-Tabellen ersetzen. Deswegen ist der eigentliche DECIMAL Wert mit ein-Wert-pro-Zeile in der Daten-Tabelle "Preis-Daten" inkl. referenz zur Immobilien-Tabelle (objekt-id). Verstehst? Deswegen haben die Referenz-Tabellen meist auch nur eine Spalte, weil dort nur der Verknüpfungswert zur Daten-Tabelle drin steht. So wie bei einer Settings-Referenz Tabelle dann z.B. "Shop-Name:, Seiten-Name:, Name:" usw. In den Daten-Tabellen werden dann die INSERT, UPDATE UND DELETE Statements angewendet und mit SELECT werden die Referenz-Tabellen mit den Daten-Tabellen verknüpft (also joined).

[thomas_w]

So richtig verstanden habe ich es nicht. Meiner Meinung nach willst Du zu tief normalisieren.

In Deinen JOINs werden dann später verschiedene Datentypen zugewiesen.

..
x.int_feld = y.varchar_feld
..

Das ist nicht performant und wird probleme machen. Weiterhin ist es fehleranfällig ein DEC-Wert in einen VARCHAR zu formatieren.

Sortier mal folgende "varchar" Werte, was ist größer ?

20,10
100,10

Am Besten Du baust Dir eine kleine Testdatenbank auf und spielst die verschiedenen Abfragen durch.

Grüße
Thomas

[b2907377]

In Deinem String Beispiel wäre in der Tat wie auch im Dezimalen Wert, 100,10 grösser, weil der String hier länger (6 bytes) ist als 20,10 (5 Bytes). Ich denke aber das Du es genau umgekehrt formulieren wolltest ;). Anyway, wir reden aber trotzdem noch aneinander vorbei. Schau: Ich konvertiere da keine Werte, sondern referenziere (in der Programmierung würde man dies als Zeiger und Dereferenzierung verstehen) auf diese. Es gibt eine Daten Tabelle, wo die Preiswerte drin stehen und jeweils ein Integer Wert, der dann aus der Referenz Tabelle den VARCHAR verknüpft, damit man später auch nachvollziehen kann, wofür die Preiswerte in der Daten Tabelle überhaupt stehen. In einem SELECT könnte das so ausschauen:

SELECT pref.preisangabe, pdat.wert FROM Preis-Daten AS pdat
JOIN Preis-Referenzen AS pref ON pref.id = pdat.preis-ref-id
WHERE pdat.objekt-id = '123456'
GROUP BY pdat.objekt-id

RESULTAT FÜR OBJEKT 123456:

preisangabe wert
Verkaufspreis 150000.00

So weiss man also später das 150000.00 ein Verkaufspreis ist und dies dank der Preis-Referenz Tabelle. Ich hoffe das es nun verständlich ist. In diesem SELECT wird natürlich die Immobilien-Daten Tabelle als Haupt Source benutzt und dann über JOINs kommen die Preisangaben mit Referenzen dazu, Distanzangaben mit Referenzen dazu, usw.

Das wäre eben die zweite Variante, wie man daten sichern könnte, was ich ganz am Afnag beschrieben habe. Die erste Variante wäre nun gänzlich auf eine Referenztabelle zu verzichten und nur eine Datentabelle verwenden, wo gleich alle Felder statisch vorhanden sind, die man verwenden könnte. Also verkaufspreis, mietpreis, kaution, etc. Dies finde ich aber trotz der Normalisierung (bzw. Aufteilung) schlecht, weil es Objektarten gibt die niemals auf alle anderen Felder zurückgreifen werden und deswegen habe ich mich für die zweite Variante entschieden, weil ich der Meinung bin, Dynamik schadet in diesem Fall-Beispiel nicht. So hat zwar jedes Objekt in den unterteilten Tabellen gleich mehrere Zeilen Daten um die Werte zu repräsentieren, dafür aber ist explizit jede Zeile von Bedeutung, soll also heissen das exakt das was für ein Objekt verwendet wird, auch dort vorhanden ist und keine leeren Felder wie in der statischen Version. Comprende? :-)

[thomas_w]

Zitat von b2907377

In Deinem String Beispiel wäre in der Tat wie auch im Dezimalen Wert, 100,10 grösser, weil der String hier länger (6 bytes) ist als 20,10 (5 Bytes). Ich denke aber das Du es genau umgekehrt formulieren wolltest ;).

Nein, ich habe es genau so formuliert, wie ich es wollte. Aber wir sollten noch schnell definieren, was "größer" ist. Was ich gemeint habe ist folgendes und dies betriff die Sortierung und da werden Dezimalzahlen in VARCHAR formatiert nun mal unerwartet sortiert, wenn nicht alle Werte exakt identisch formatiert sind (Vornullen etc.).

	
	
CREATE TABLE test_varchar (
 dec_wert VARCHAR(20) NOT NULL
);

INSERT INTO test_varchar VALUES
( '20,10'),
( '100,10');

SELECT dec_wert FROM test_varchar
ORDER BY dec_wert;
+----------+
| dec_wert |
+----------+
| 100,10   |
| 20,10    |
+----------+
2 rows in set (0.05 sec)

Wie Du sehen kannst, wird "20,10" als größer sortiert, obwohl der Wert kleiner als "100,10" ist.

Den Rest Deiner Mail muss ist erst mal lesen/verstehen.

Bis dann..

Grüße
Thomas

[thomas_w]

Soweit ich es jetzt verstanden habe, meinst Du unter Dynamik folgendes:
Pro Immobilie gibt es verschiedene "Preise", aber nicht alle sind bei allen Immobilien vorhanden. Um jetzt keine leeren (NULL) Spalten zu verwalten, soll jede "Objekt-Preis-Eigenschaft" der Immobilie getrennt verwaltet werden.

Das könnte (auf die Schnelle ohne FOREIGN KEY etc.) so aussehen:

CREATE TABLE immobilie (
 id INT NOT NULL,
 ort VARCHAR(50),
 PRIMARY KEY (id)
);

CREATE TABLE preis_art (
 id INT NOT NULL,
 bezeichnung VARCHAR(50) NOT NULL,
 PRIMARY KEY (id)
);

CREATE TABLE preise (
 id INT NOT NULL,
 immobilie_id INT NOT NULL,
 preis_art_id INT NOT NULL,
 preis DEC(10,2) NOT NULL,
 PRIMARY KEY (id)
);



INSERT INTO immobilie VALUES 
( 1, 'hier');

INSERT INTO preis_art VALUES 
( 1, 'verkaufspreis'),
( 2, 'mietpreis'),
( 3, 'kaution');

INSERT INTO preise VALUES
( 1, 1, 2, 900),
( 2, 1, 3, 2700);

SELECT i.*, pa.bezeichnung, p.preis
  FROM immobilie i
  JOIN preise p
    ON p.immobilie_id = i.id
  JOIN preis_art pa
    ON pa.id = p.preis_art_id
ORDER BY pa.bezeichnung;
+----+------+-------------+---------+
| id | ort  | bezeichnung | preis   |
+----+------+-------------+---------+
|  1 | hier | kaution     | 2700.00 |
|  1 | hier | mietpreis   |  900.00 |
+----+------+-------------+---------+
2 rows in set (0.01 sec)

mysql>

Dies halte ich generell für eine gute Lösung, aber nur, wenn die Anzahl der "Objekt-Preis-Eigenschaften" (Tabelle preise, preis_art) mehr als drei wie in diesem Beispiel ist. So ab zehn Eigenschaften wäre es bestimmt sinnvoll, insbesondere da schnell eine neue "Objekt-Preis-Eigenschaft" hinzugefügt werden kann.

D.h. diese Methode ist flexibler (dynamisch in deiner Sprache), allerdings sind die SQL-Abfragen durch die "vielen" JOINS immer etwas komplexer bzw. etwas langsamer als wenn alles in einer Tabelle ist. Ich denke, die Vorteile des auftrennens (Normalisieren) in diese "Objekt-Preis-Eigenschaft" überwiegen.

Letztlich bleibe ich dabei: Am Besten Du baust Dir eine kleine Testdatenbank auf und spielst die verschiedenen Abfragen durch. Ein früher Lasttest (mit vielen Testdaten) erspart später so manche Zusatzkosten, wenn dann Performance-Engpässe mit dicker Hardware erschlagen werden müssen.

Grüße
Thomas