Datenbankstrukur - Minitabellen

[Xelanja]

Die Tabelle wäre "Gebäude" mit einer Typspalte, Werte wären eben Wohnhaus, Gartenhaus, Mühle, ..

Das habe ich in der Exceltabelle so gemacht. Allerdings ergab sich dabei ein hässliches Problem. Erstens kann sich die Nutzung eines Gebäudes im Laufe der Zeit wandeln oder aber eine (wichtige) Mehrfachnutzung nachgewiesen sein. Beispiel Mühle ist gut. Beispiel: Das Gut/Flurstück 196 in Oelsnitz Erzg. besaß ursprünglich eine, nur selten erwähnte, Mühle, die Teichmühle. Es ist wichtig das und die Quelle dazu zu erhalten, denn in modernen Publikationen ist diese Mühle verloren gegangen, weil sie im Jahr 1760 bei einem (wetterbedingten) Brand abbrannte. Das Gut selbst wurde aber wieder aufgebaut und blieb als Pferdefrongut erhalten. Probleme: 1. Die Mühle ist kein eigenes Grundstück. Sie hat keine eigene ID, sondern gehörte zum Grundstück 196. 2. Sie wurde getrennt gehandelt (es gibt einen Beleg, dass sie 1621 getauscht wurde gegen ein Gartengrundstück, von wem und zu welchem Preis). Nehme ich also eine Tabelle db.house_typ und füttere sie mit allen Grundstückstypen, was kein Problem darstellt, brauche ich bei den Grundstücken jeweils x Spalten Nutzung-Jahr und müsste alle 500 Häuser durchsuchen, wieviele Nutzungswechsel und gleichzeitige Nutzungen das Maximum wäre oder ich füge in der Eingabeprogrammierung hinzu, dass die Anzahl der Nutzungen abgefragt und, sollte für einen neuen Eintrag keine Spalte existieren, eine hinzugefügt werden müsste. Ja, ich weiß wie das geht ;-).

 

[ukulele]

Also Veränderungen in der Nutzung eines Gebäudes sind kein Grund für verschiedene Tabellen für verschiedene Nutzungsformen, eher im Gegenteil. Du hast ein Gebäude, das ist die Entität und Tabelle. Du hast einen Gebäudetyp oder eine Nutzung, in diesem Fall Mühle, das ist zunächst einmal ein Attribut. Wenn sich das Attribut ändern kann gibt es mehrere Möglichkeiten, zwei sinnvolle wären:

a) Du legst bei jeder Änderung eines Attributes einen kompletten, neuen Datensatz an, beide Datensätze haben dann zeitliche Grenzen oder
b) du gliederst das Attribut aus in eine eigene Entität, Gebäudenutzung, eine Tabelle mit n:1 Beziehung zu Gebäude. Dann wird diese zwei Einträge mit zeitlichen Grenzen habe.

A geht mit redundanten Informationen einher, alle anderen Attribute sind ja in beiden Datensätzen gleich. A ist in diesem konkreten Fall aber eine Option, weil das ganze nicht sehr häufig passiert. Es ist ein recht flaches Datenmodell weil eben keine weitere Tabelle dazu kommt, und es ist damit relativ leicht verständlich und zu handhaben.

B ist sauber normalisiert. B kann auch Gebäude abbilden, bei denen die Nutzung über einen Zeitraum unbekannt ist, das ergibt von der Sache her Sinn. Man kann jedem Eintrag in der Nutzungstabelle auch eine Quelle hinzufügen und damit dann die Information über die Nutzung z.B. nur am Zeitpunkt der Quelle fest machen. Einen Tag später könnte sich die Nutzung geändert haben und man weiß das aber gar nicht mehr so genau.

Du kannst alle deine Daten exakt abbilden. Das wie entscheidet aber stark über den Arbeitsaufwand. Wenn ich mir deine Beispielinformationen ansehe und du solche Szenarien wirklich gemäß 3ter Normalform so abbilden willst könnten es aber schnell sehr sehr viele Tabellen werden. Das ist kein Problem, das ist auch nicht falsch. Aber eventuell ist der Ansatz nicht der richtige, siehe meine vorherige Idee.

 

[dabadepdu]

..brauche ich bei den Grundstücken jeweils x Spalten Nutzung-Jahr und müsste alle 500 Häuser durchsuchen..

Das klingt wieder sehr nach Excel-Welt. Tatsächlich beschreibst Du in dem Satz gleichzeitig ein (Excel)typisches Vorgehen und die daraus resultierenden Probleme. Du musst Dich gedanklich davon verabschieden, wenn Du ein ordentliches Datenmodell bekommen willst.
In Excel ist es zunächst ein Kinderspiel irgendwo die 2., 3., x. Spalte dranzunageln. Man kann irgendwie Daten unterbringen und irgendwie Bezüge „erhalten“.
In Datenbanken ist es anders, Du definierst eine relativ statische Struktur, wo immer gleichförmige Informationen in Listen(Tabellen) gespeichert werden. Diese Tabellen sind dann gemäßt der Natur einer relationalen Datenbank zwar beliebig in der Struktur, aber zu einem gegebenen Nutzungszeitpunkt nicht adhoc erweiterbar, nicht derart, dass man on-the-fly einfach noch eine Spalte anbringt, die dann auch spontan für den Endanwender verfügbar ist und in allen Queries, Formularen und Reports durchschlägt. Geht alles, aber eben halt in der nächsten Version.
Die natürliche Form der "Erweiterung" einer Tabelle ist ein neuer Datensatz, nicht eine neue Spalte.

Die Vorschläge von @ukulele sind dazu genau richtig.
Eine Historisierung von Daten (neuer Datensatz bei Änderung des Nutzungstyp für einen Zeitraum) ist genau in diesem Anwendungsfall sehr hilfreich und bietet einen großen Nutzen. Wenn Du eine Suche auf einen bestimmten Zeitraum einschränkst, findest du dann eben auch genau die Daten, die in dem Zeitraum gültig waren. In der Modellierung kannst Du dafür vielleicht auch eine JSON Spalte nehmen, die das abbildet.

Dieses Muster lässt sich vermutlich auch auf viele andere Bereiche übertragen. Beispiel Städtenamen oder Straßennamen in Ost- und Westdeutschland. Karl-Marx-Stadt, Mohrengasse, usw. dann diverse Denkmäler, die aufgebaut und wieder abgerissen werden. Zentrale Plätze, die entsprechend umbenannt werden. Alles mit zeitlich begrenzter Gültigkeit.
Alle diese Namen sind irgendwann mal in Taufregister usw. eingetragen worden und sind schwer auffindbar, wenn es gar nicht oder nicht zeitlich korrekt eingetragen ist. Dann noch Änderungen von Schreibweisen, Hochdeutsch, Dialekte, bei historischen Betrachtungen / Recherche kommt man auch hier um zeitliche Eingrenzbarkeit nicht herum, ein Muster.
Aber auch nochmal der Hinweis auf die Grenzen der Modellierung. Ob nun eine Mühle als eigenständiges Gut oder Teil eines Grundstücks geführt wurde, ich weiß nicht, wie nah man der Realität / Vergangenheit kommen will oder muss. Man muss auch einen Kompromiss zwischen Aufwand und Nutzen finden. Statt der Abbildung von Besitzverhältnissen wäre zur Zuordnung u.U. auch der Standort (Geolocation) geeignet. Auch dabei ist es hilfreich, die Möglichkeiten zu kennen, die es technisch gibt. Volltextindizierung bswp., noSQL Erweiterungen einer relationalen DB, JSON, Arrays, EAV oder Geometrie Daten, es gibt einen Haufen Möglichkeiten. Man muss/kann nicht die Wirklichkeit 1:1 in einem relationalen Modell abbilden, deswegen nennt man es vermutlich Modell.