[opengeodb] nur deutschland

[Robert Böck]

Martin Trautmann wrote:
> Robert Böck wrote:
>> Stephan S wrote:
>>
>>> Du hast hier schon mehrfach behauptet, bei der gegenwärtigen Datenbank-Struktur
>>> wäre von Normalisierung keine Spur, mich würde dazu mal interessieren, gegen
>>> welche Normalform Deiner Meinung nach verstoßen wird?
>>
>> geodb_textdata ist nicht atomar. Andere Tabellen auch nicht.
> 
> 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)

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). Ich bin mir
ziemlich sicher, dass man die Performance auch deutlich verbessern
würde. Und die Datenmenge könnte wahrscheinlich ebenfalls reduziert werden.

> 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;

Die check-Constraints habe ich mal weggelassen, damit es übersichtlicher
ist.

Es geht schon mal damit los, dass die Tabelle keinen primary key hat.
loc_id ist ein foreign key.

Dann ist da alles mögliche drin, was gar nicht zusammengehört (also
Postleitzahlen, Ortsnamen in verschiedenen Schreibweisen, Bundesländer,
Regiertungsbezirke, etc.) Die Tabelle enthält Daten (text_val) und
Metadaten (text_type) gleichermaßen. Alles wild durcheinander wie Kraut
und Rüben.

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.

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.

Selbstverständlich erfordert das einiges an Gehirnschmalz und Zeit, eine
entsprechende Datenstruktur zu definieren.

cu, Robo :)