[opengeodb] nur deutschland

[Robert Böck]

Martin Trautmann wrote:r

>>> Was würde eine Normalisierung für praktische Vorteile mit sich bringen?
>>> Wofür braucht man sie, was hilft sie?
>>
>> Kann man sehr schön bei Wikipedia nachlesen:
>>
>> http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)
> 
> Aha - und welche Normalform willst du?

Da möchte ich mich jetzt nicht festlegen.

>> Die Vorteile speziell für die Opengeodb wären, dass die SQL-Statements,
>> um Daten abzufragen, bei weitem nicht so komplex wären, wie sie jetzt
>> sind (momentan muss man u. a. ganz exzessiv mit Selbstbezügen arbeiten,
>> um der Datenbank bestimmte Datensätze zu entlocken).
> 
> fuer bestimmte ja - aber gerade normalisiert ergeben sich 
> moeglicherweise mehr Bezuege als wenn man alles in eine einzige Tabelle 
> reinpfropft.

In der Praxis werden sich für Abfragen weniger Bezüge ergeben, eben weil
nicht alles in eine Tabelle reingestopft ist und somit schon die Bezüge
für die Datenart (text_type) wegfallen.

>> Ich bin mir
>> ziemlich sicher, dass man die Performance auch deutlich verbessern
>> würde. Und die Datenmenge könnte wahrscheinlich ebenfalls reduziert werden.
> 
> Ich bin mir sicher, dass man Performance dann verbessern kann, wenn man 
> rauswirft, was man nicht braucht und Hilfstabellen dafuer anlegt, was 
> man haeufig braucht.
> 
> Das eine verringert die Datenmenge, das andere vergroessert sie.

Wenn man das, was jetzt in geodb_textdata drinsteckt,
auseinanderklamüsert, dann reduziert es einerseits die Datenmenge, weil
text_type wegfallen kann, andererseits vereinfacht es die Abfragen, weil
ich keinen text_type dafür herziehen muss, nur um festzulegen, welche
Art von Daten (PLZ, Ort, etc.) ich haben will.

>>> Und wie sähe sie als konkretes Beispiel aus?
>>
>> Nehmen wir mal die bereits erwähnte geodb_textdata:
>>
>> create table geodb_textdata (
>>    loc_id               integer not null references geodb_locations,
>>    text_val             varchar(255) not null,
>>    text_type            integer not null,
>>    text_locale          varchar(5),
>>    is_native_lang       smallint(1),
>>    is_default_name      smallint(1),
>>    valid_since          date,
>>    date_type_since      integer,
>>    valid_until          date not null,
>>    date_type_until      integer not null,
>> ) TYPE=InnoDB CHARACTER SET utf8;
> 
> 
>> Es geht schon mal damit los, dass die Tabelle keinen primary key hat.
>> loc_id ist ein foreign key.
> 
> Wie kommst du darauf, die loc_id waere kein primary key? Sie wird also 
> solcher verwendet.

Weil die loc_id in der Tabelle geodb_locations der Primärschlüssel ist.
Wenn ich nun geodb_locations.loc_id mit geodb_textdata.loc_id verknüpfe,
folgt daraus, dass geodb_textdata.loc_id ein Fremdschlüssel ist.

>> Dann ist da alles mögliche drin, was gar nicht zusammengehört (also
>> Postleitzahlen, Ortsnamen in verschiedenen Schreibweisen, Bundesländer,
>> Regiertungsbezirke, etc.)
> 
> Das gehoert nicht zusammen, glaubst du? Seltsam.

Genauso wie Äpfel, Birnen und Tomaten nicht zusammengehören. Die gehören
auch in getrennte Kisten.

>> Die Tabelle enthält Daten (text_val) und
>> Metadaten (text_type) gleichermaßen. Alles wild durcheinander wie Kraut
>> und Rüben.
> 
> Das hat mit Normalisierung aber wohl nichts mehr zu tun?

Meiner Meinung nach schon. Weil text_type redundant ist. Wenn man das
alles sinnvoll zerlegt, wird text_type überflüssig.

>> Und nun zu einem konkreten Beispiel. Ich greife mal die Postleitzahlen
>> heraus:
>>
>> create table geodb_plz (
>>    id    integer not null primary key,
>>    plz   varchar(255) not null
>> );
>>
>> Das nenne ich atomar.

> Und was ist deine id? 

Ein Integer. Steht doch da.

> Woher weiss nun ein Ort, welche PLZ zu ihm gehoert?

Indem er mit der PLZ verknüpft wird.

> Woher weiss die PLZ, seit wann sie gueltig ist?

Wenn sie das wissen muss, kann man ihr diese Information ja noch mitgeben.

> Woher weiss die 
> PLZ, ob das nun zu einem einzigen Ort gehoert, zu welchen seiner 
> Ortsteile, zu welchen anderen Orten, zu welchem PLZ-Gebiet, zu welchen 
> Koordinaten?

Das muss die PLZ doch gar nicht wissen, weil das in einer anderen
Relation drinsteht.

> Was soll dieses einsame Atom, so ganz allein ohne Molekülverbindungen? 
> Langweilt es sich dann nicht?

Mit den ganzen anderen Relationen sicher nicht.

>> Für andere Daten muss das entsprechend gemacht werden. Und dann braucht
>> man eben Tabellen, die die Relationen herstellen, z. B. zwischen einer
>> PLZ und einem Ort, oder zwischen einer PLZ und einer Koordinate, etc.
> 
> Ah, du willst die Atome über Tabellen verbinden, statt die Atome gleich 
> in der Tabelle drin zu haben - und das spart Platz, ist verständlicher 
> und erhöht die Geschwindigkeit?

Ja selbstverständlich. Weil in jeder "Kiste" nur noch gleichartige
"Atome" drin sind. Das spart Metadaten und somit Platz, ist
verständlicher und erhöht auch die Geschwindigkeit, weil ich keine
Metadaten mehr heranziehen muss, um zu wissen, mit was für einer Art von
Daten ich es überhaupt zu tun habe.

>> Selbstverständlich erfordert das einiges an Gehirnschmalz und Zeit, eine
>> entsprechende Datenstruktur zu definieren.
> 
> Im Moment sehe ich nur eine Verkomplizierung, weil weitere Tabellen zur 
> Verknüpfung erforderlich sind.

Nein, JETZT ist es kompliziert, weil verschiedenartige Daten in einer
Tabelle drinstecken und ich zusätzliche Verknüpfungen brauche, um
festzulegen, welche Art von Daten ich zur Abfrage heranziehen will.

> Wer das zur Performance-Optimierung 
> braucht, der sollte diese IMHO selbst anlegen - denn für mich sieht das 
> nach redundanten Daten aus.

Mitnichten. Eine vernünftige, normalisierte Datenstruktur vermeidet ja
gerade Redundanzen.

cu, Robo :)