Datenbank - Deutschland abbilden

  • Hi,

    ich arbeite gerade an einer Datenbankstruktur mit der ich verschiedene Staaten hierarchisch unterteilen kann bis hin zur Postleitzahl. Dazu hab ich für jeden Staat einen eigenen Table.

    Erster Schritt ist es, die Staaten in ihre Verwaltungseinheiten zu zerlegen. Bei Deutschland steh ich jetzt aber an. Wikipedia zeigt mir folgende Grafik:

    Spoiler anzeigen




    Ich hab bis jetzt die Ebenen:
    Bundesland, Regierungsbezirk, Landkreis - aber ich überleg mir grad inwiefern man Deutschland überhaupt einheitlich unterteilen kann, da es ja Kreisfreie Städte etc. gibt.

    Aber 1. bin ich nicht aus Deutschland und weiß nicht inwieweit sich die verschiedenen Bundesländer in ihrer Verwaltung unterscheiden und es daher sinnvoll ist alle Ebenen in der Datenbank abzubilden.

    Und 2. hoff ich dass jemand schonmal so eine Unterteilung gemacht/gesehen hat und mir hier weiterhelfen kann.


    Das ganze soll in einem Userinterface Verwendung finden, in dem man sich durch die verschiedenen Ebenen durchklickt und die Anzahl der Datensätze pro Stufe sieht. Die Hierarchie selbst wird auch noch einmal abgebildet, hier geht es aber nur mal um die Erfassung der Ebenen.

    ps:
    wer auch Lektüre zur Abbildung von Hierarchien (auch n-Dimensionale Hierarchien) in relationalen Datenbanken im I-Net anzubieten hat immer her damit [Blockierte Grafik: http://board.gulli.com/images/smilies/smile.gif]

    "Unkenntnis blendet und lässt uns in die Irre gehn.
    Oh, ihr elenden Sterblichen, öffnet die Augen!"

    L. Da-Vinci

  • ich arbeite gerade an einer Datenbankstruktur mit der ich verschiedene Staaten hierarchisch unterteilen kann bis hin zur Postleitzahl. Dazu hab ich für jeden Staat einen eigenen Table.


    ich muss sagen, hier hab ich aufgehört zu lesen ... für jeden Staat eine eigene Tabelle? Wozu denn das bitte?

    Ganz auf die schnelle ohne großartig darüber nachzudenken: Ich würde eine EINZIGE Tabelle für alle Staaten/Regionen machen. Eine Spalte mit der ID, eine Spalte "parent_region" (NULL erlaubt, foreign key auf sich selbst) + weitere notwendige Attribute.

    *** Make it idiot proof, and someone will build a better idiot. ***


  • Ganz auf die schnelle ohne großartig darüber nachzudenken: Ich würde eine EINZIGE Tabelle für alle Staaten/Regionen machen. Eine Spalte mit der ID, eine Spalte "parent_region" (NULL erlaubt, foreign key auf sich selbst) + weitere notwendige Attribute.

    Der Ansatz ist mir klar, nur befürchte ich, dass er an seine Grenzen stößt, sobald es mehrere Staaten mit parallelen Organisationstrukturen gibt.

    Beispiel Deutschland: Nielsen Gebiete.
    Zu der oben gezeigten Struktur der den Staat in Bundesländer, Bezirke etc. gliedert gibt es noch eine andere Einteilung, nämlich der Nielsen Gebiete welche ich auch unbedingt berücksichtigen muss. Durch den Foreignkey auf sich selbst kann ich jeder Hierarchiestufe eine "parent_region" zuweisen.

    Da jedes Nielsen-Gebiet nur vollständige Bundesländer enthält, könnte ich dieses als Parent von Bundesländer definieren, und Parent von Nielsen wäre Deutschland. Das bedeutet aber, dass ich die Ordnung der Länder nach Nielsen- Gebiete nicht optional verwenden kann, sondern immer den weg über Nielsen machen muss um auf ein Bundesland zu kommen.

    Ok ich gebe zu der Aufwand diesen kleinen Umweg in einem Userinterface zu umgehen wäre sehr gering. Was aber wenn sich in anderen Ländern weitere parallele Ordnungsstrukturen auf einer unteren Hierarchiestufe zeigt. Ein Beispiel dazu wäre der Hinweis im obigen Wikipedia - Artikel:

    "Eine Zuordnung zu Nielsen-Gebieten über die fünfstelligen Postleitzahlen ist nicht vollständig automatisch möglich, da es einige Postleitbereiche gibt, die bundesländerübergreifend vergeben wurden."

    Hier gibts dann mit dem einen Verfügbaren Foreign-Key Probleme, da ein Postleitbereich mehrer Bundesländer besitzt - obwohl ich noch nicht rausgefunden habe welche Postleitbereiche hier gemeint sind.


    Außerdem finde ich, dass die Haltung der Adressdaten in ausschließlich dieser Form einige Nachteile hat:

    • Änderungen an den Attributen betreffen immer alle Staaten, auch wenns nur einen betreffen sollte
    • Wartung der Datensätze stell ich mir ziemlich aufwendig vor, da aus dem Datenmodell der Inhalt nicht ersichtlich ist
    • Extraktion von Informationen macht immer ein vollständiges durchsuchen des Tables notwendig. z.b. finden des Obersten Knoten: select * from bla where parent is null;

    "Unkenntnis blendet und lässt uns in die Irre gehn.
    Oh, ihr elenden Sterblichen, öffnet die Augen!"

    L. Da-Vinci

  • ok ... wie wär's dann mit einer Tabelle für alle Regionen ohne Relationen unter einander, und einer zweiten Tabelle, die alle Relationen speichert. Als attribut einer Relation kannst Du auch den Typ der Relation (PLZ, extra-würstel-nielsen, etc.) angeben. Die Liste der Relationtypen würde ich aber in einer Extratabelle speichern.

    Auf jeden Fall würde ich sehr vehement davon abraten Tabellen pro Land anzulegen. Falls Du das für die Uni brauchst, wäre das definitiv ein glatter 5er für mich.

    *** Make it idiot proof, and someone will build a better idiot. ***

  • na, eigentlich für ein produktivsystem :P hab im netz inzwischen auch literatur zu dem thema gefunden und soweit ich das auf den ersten blick sehen konnte (hatte keine zeit bis jetzt genauer nachzulesen) decken sich die lösungvorschläge dort mit deinem :)

    ich weiß ist eine etwas zusammenhangslose frage, aber kann mir jemand etwas zum thema n-dimensionale hierarchien erzählen bzw. lektür-vorschläge geben? hab grad leider keine zeit breit den zusammenhang zu erklären, aber ich hols bei bedarf gern nach :shinner:

    "Unkenntnis blendet und lässt uns in die Irre gehn.
    Oh, ihr elenden Sterblichen, öffnet die Augen!"

    L. Da-Vinci

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!