Häuserchonik - Ahnenstammbaum - Datenbankprogramm

[Hemaris fuciformis]

Hallo zusammen,

ich habe jetzt dieses Thema nur überflogen und bin sicher kein Spezialist für Programme - aber spaßeshalber könntet Ihr Euch mal die folgende Seite anschauen, da sind auch Häuser-Chroniken und Stammbäume in einem zu finden.

http://www.genealogie-kiening.de/

Viel Erfolg wünscht
Christine

[Waltschrat]

Warum es nicht so leicht ist

Grüß Gott,

leider ist es scheinbar doch nicht so leicht, wie es hier anklingt.

Wenn ich einmal die Beiträge kategorisiere, dann finde ich

1. Ja, das will ich auch haben. Was natürlich wenig zielführend ist.
2. Ich blicke in die glänzenden Augen von Fitsch, der durch dieses Brainstorming auf immer neue Ideen kommt, was man noch machen kann.
3. Viele Beiträge behaupten, dass alles doch ganz easy mit den bestehenden Werkzeugen sein. Man muss sie nur zusammenwürfeln.
4. Offensichtlich gibt es aber keinen Programmierer oder kein Software-Haus, das sich hiermit eine goldene Nase verdienen will. Wobei ich davon ausgehe, dass das Projekt einen vier- bis fünfstelligen Betrag kosten würde.

Ich versuche nun einfach meine Sicht auf die Dinge darzulegen, auch wenn ich vielleicht damit anecke. Als Aufhänger nehme ich den Beitrag vom 02.03.2016 17:51 und die zusätzliche Verstärkung "Der Datenbankentwurf ist das absolut Entscheidende!" Richtig, aber wie sieht er aus?.

Es genügen hiernach mal schnell vier Dateien (Person, Ort, Haus, Grab) zusammenzustöpseln, um ein Hausbuch zu realisieren. Das geht so nicht. Allein die Tabelle Grab ist fraglich.

Sollen wirklich einzelne Gräber erfasst werden? Dann müssten in Mehrfamilienhäusern auch die Wohnungen, auf Höfen die Austrag- und Gesindehäuser usw. unterschieden werden.
Es existiert eine halbwegs stabile Hierarchie:

Orte haben Friedhöfe (entspricht einem Haus/Platz)
Friedhöfe bestehen aus Gräbern

Aber schon das wackelt. Es gibt Seegräber, Friedwälder, das Verstreuen von Asche (Schweiz) auf Bergwiesen usw. usw.
Aber nicht nur Gräber sind "wackelig". Orte leben, werden umbenannt, zusammengelegt, eingemeindet usw.

Wie soll der Zeitfaktor berücksichtigt werden? Personen ziehen um, Wohnungen werden neu belegt, Gräber werden aufgelassen usw. Soll das auch erfasst werden?

Gräber sind eine zeitlang belegt, aber natürlich nicht überschneidend.

Bekomme ich diese Daten wirklich in einer einigermaße großen Menge zusammen oder ist das nur auf Dachbodenfunde beschränkt?

Gegenargumente: Das brauche ich nicht und jenes will ich nicht!

Aber es gibt immer einen, der es haben will und es somit besser weiß und daher laut meckert.

Wenn ich in meinem Stammbaum die Hausnummern speichere, dann heißt es sofort, wofür?
Sagen wir es offen heraus. In Waldgebieten in Nordhessen hießen alle Bewohner Müller (Name geändert). Alle 20 bis 30 Jahre kann man davon ausgehen, dass es eine Hochzeit gibt und die Braut im Allgemeinen in das Haus einzieht. Kurz darauf ist dann eine neue Maria oder ein Joseph (in Böhmen ein Wenzl) zu erwarten. Im Geburtsbuch sind dann aber bereits viele Marias und Josephs dazwischen auf die Welt gekommen.

Jetzt wird es konkret:

Bild 1 zeigt ein unvollständiges, bereits deutlich ausgedünntes Beziehungsdiagramm für das hier diskutierte Problem. Wir (besser er) können jetzt ausprobieren, ob es alle Fragen vom Fitsch erfüllt:

Beispiel:
Ich will die Weltkriegsteilnehmer erkennen?
Frage: Wo stecken die drin?
Antwort: Im Dokument. Jedes einzeln? oder doch im übergeordneten Buch oder im Schuber (Foliant)?
Erklärung: Ein Kirchenfoliant enthält mehrere Bücher (Geburt, Trauung, Indexe usw.). Ein Buch besteht aus mehreren Seiten. Eine Seite enthält mehrere Einträge. Sind auch Fitsch's Dokumente so gegliedert?

Ergebnis:
Derzeit komme ich auf 23 Dateien. Und es werden täglich mehr.

Ist der Datenbankentwurf stabil und elegant. Hierfür sind hochbezahlte Analysten am Werk. Dann geht die Knochenarbeit los. 90 % der Arbeit steckt in der Oberfläche. Halt, ich habe den Designer vergessen, der den Verkaufserfolg wesentlich beeinflusst.

Die eigentliche Datenerfassung ist dann fast vernachlässigbar, denn die Oberfläche prüft alle Daten auf Konsistenz. Die vielen, kleinen Eingeber können also gar nichts falsch machen.

Bild 2 zeigt dann, wie zu einem Ort, hier die Dokumentgalerie eines Haus aus Nordböhmen, die Dokumente erfasst sind. Das Bild muss natürlich vergrößert werden. Alle Daten im Dokument müssen in maschinenlesbare Form umgeschrieben werden usw. usw. (reine Knochenarbeit, ganz easy)

So, jetzt müssen nur noch die Personen in die Häuser. Dazu gibt es bestimmte Ereignisse, wie Geburt, Trauung, Tod wie in Bild 3, die sich in den Dokumenten niederschlagen.

Uff, Personen ziehen um, heiraten auch noch mehrmals in ihrem Leben. Weil das mit der Umzieherei so komplex ist, hat sogar Vater Staat zumindest eine Zeit lang auf die Melderegister verzichtet. Werden sich also in Zukunft die Dorfbewohner bei Fitsch an- und abmelden?

Also ist es doch nicht so ganz easy, wie es hier in einigen Beiträgen anklingt.

Euer Waltschrat, der mit dem t

[Lola38]

Friedhöfe, in diesem zusammenhang meine frage, was ist mit zugeschütteten friedhöfen? Mit zubetonierten friedhöfen? Die jetzt anliegenden gärten legen z.B. immer wieder knochenfunde frei? Es ist mir sehr um eine antwort getan. Bitte Lola38

[Waltschrat]

Liebe Lola,

Friedhöfe, in diesem zusammenhang meine frage, was ist mit zugeschütteten friedhöfen? Mit zubetonierten friedhöfen? Die jetzt anliegenden gärten legen z.B. immer wieder knochenfunde frei? Es ist mir sehr um eine antwort getan. Bitte Lola38

Die Frage hat nichts mit dem Thema des Threads zu tun, wenn sie ethisch gemeint ist. Sie muss jeweils vom Auftraggeber für den Programmierer vorgegeben werden. Niemand garantiert uns, dass wir nicht auf einem Steinzeitfriedhof wohnen.
Wie ich schon dargelegt habe, verändern sich Orte/Plätze/Häuser.
Ich selbst kämpfe in Böhmen mit Orten, die durch die Vertreibung untergegangen sind. Auch gibt es Orte, die durch die Einrichtung eines Truppenübungsplatzes oder durch den Kohletagebau untergegangen sind, wobei die Orte entweder umgesiedelt oder die Bewohner verteilt wurden.

Programmtechnisch handelt es sich um einen assoziativen Beziehungstyp. Ein Platz wird mehrfach verwendet, z. B. als Friedhof oder als Kleingartensiedlung. Erst mit der Verknüpfung von Platz und Verwendung kommt die Frage auf, von wann bis wann.

Wenn der Auftraggeber nur eine einzige Verwendung fordert, so wird dies als einen 1:m-Beziehungstyp programmiert. Andernfalls ist ein m:m-Beziehungstyp angesagt. Und mal ganz unter uns. Es gibt nichts Schlimmeres als diese Umwandlung nachträglich einzuprogrammieren. Und das wird teuer, etwa wie die Entrauchungsanlage im Berliner Flughafen.

Dein Waltschrat mit dem t

[Reisinger]

Grüß Gott,
Jetzt wird es konkret:

Bild 1 zeigt ein unvollständiges, bereits deutlich ausgedünntes Beziehungsdiagramm für das hier diskutierte Problem. Wir (besser er) können jetzt ausprobieren, ob es alle Fragen vom Fitsch erfüllt:

Beispiel:
Ich will die Weltkriegsteilnehmer erkennen?
Frage: Wo stecken die drin?
Antwort: Im Dokument. Jedes einzeln? oder doch im übergeordneten Buch oder im Schuber (Foliant)?
Erklärung: Ein Kirchenfoliant enthält mehrere Bücher (Geburt, Trauung, Indexe usw.). Ein Buch besteht aus mehreren Seiten. Eine Seite enthält mehrere Einträge. Sind auch Fitsch's Dokumente so gegliedert?

Ergebnis:
Derzeit komme ich auf 23 Dateien. Und es werden täglich mehr.

Ist der Datenbankentwurf stabil und elegant. Hierfür sind hochbezahlte Analysten am Werk. Dann geht die Knochenarbeit los. 90 % der Arbeit steckt in der Oberfläche. Halt, ich habe den Designer vergessen, der den Verkaufserfolg wesentlich beeinflusst.
Euer Waltschrat, der mit dem t

Hallo, auf Anregung dieses Themas habe ich mal meine Datenbank Script durchwühlt. Hab mir auch schon eine Struktur überlegt. kurz einige Komments zu Bild 1: mehr als die Hälte ist eine Quelle? Mit Handy Nr wirkt es etwas aufgebläht. Veränderliche Daten (Wohnung) sollte in eine eigene Tabelle; Normalformen würde das ganze sehr abspecken... Ich würde mich mehr an den Gedcom Standard halten. Weiters finde ich den GRAMPS Ansatz mit Personen, Erreignissen, Orte und Quellen sehr gut. Leider betrachtet kaum jemand, dass die Orte das Beständigste sind. Sie ändern max. den Namen und die Bestimmung, bleiben aber, solange die Plattendektonik nicht schneller wird, am selben Platz.

[Waltschrat]

Datenbank und Normalformen

Grüß Gott, lieber Reisinger,

Hallo, auf Anregung dieses Themas habe ich mal meine Datenbank Script durchwühlt. Hab mir auch schon eine Struktur überlegt. kurz einige Komments zu Bild 1: mehr als die Hälte ist eine Quelle?

Verstehe ich leider nicht. Was ist eine Quelle, was ist Hälfte? Zur Erläuterung. Eine Quelle wird als dreistufige 1:m-Hierachie abgelegt. Genau genommen müsste ich sie sogar als Weak-Entity konstruieren, so dass das Einzeldokument einen Dreifachschlüssel hat. Das kann man aber über die Oberflächengestaltung eleganter lösen, indem kein Dokument ohne Buch und ohne Schuber (Foliant, Mappe) eingegeben kann.
Wenn ich also einen neuen Kirchenbuchfolianten öffne (ein Buch ist es ja nicht), dann besteht dieser aus bis zu drei Einzelbüchern (Geburt, Trauung, Tod) und möglicherweise drei Indexen dazu. Letztere werden oft in physikalischen getrennten Kladden geführt.
Das sieht wie in Bild 1 aus.

Mit Handy Nr wirkt es etwas aufgebläht.

Kostet fast nichts und ich kann allen meinen Kindern sagen, wann der XYZ Geburtstag hat, wie alt er ist und welche Geschenke für ihn geeignet sind.
Vielleicht zur Erklärung: Für mich ist ein Stammbaum die Abbildung der realen Welt. Die Historie ist ein natürliches Abfallprodukt. Mein Schwerpunkt liegt auf Bilderserien der noch Lebenden. Schau Dir einfach einmal

http://forum.ahnenforschung.net/showthread.php?t=137212&highlight=Scheibls

an. Bild 2. In 100 Jahren sind wir dann die Ahnen.

Veränderliche Daten (Wohnung) sollte in eine eigene Tabelle; Normalformen würde das ganze sehr abspecken...

Huch, eine Wohnung gehört in ein Haus, ein Grab auf einen Friedhof usw. Wer kann heute noch feststellen, wann wer wo gewohnt und umgezogen ist (siehe Handy-Anmerkung). Warum also eine Wohnungstabelle? Die gehört als Folgetabelle an das Haus. Hier gibt es nichts zum Abspecken!!!!
Der Wohnort einer Person ist veränderlich, die Wohnung nicht. Ergo ist das ein m:m-Beziehungstyp und wird im Relationalen Datenmodell mit einer Zwischentabelle realisiert, genauer einem assoziativem Beziehungstyp, da zu den beiden Primärschlüsseln noch der Zeitraum der Wohnungsbelegung hinzu kommt. Wenn also der Auftraggeber (hier unser Themenstarter) das für richtig ansieht, dann muss es realisiert werden. Ich habe im Bild 1 derzeit nur die einfache Variante, da in den "alten Zeiten" zumindest die Bauern und Handwerker selten umgezogen sind, also nur ein Wohnort. Da ich so gut wie keine Wohnungsinformationen habe, verzichte ich auf eine Erweiterung (wie unsere Einwohnermeldeämter).
Aber sicher hast Du entdeckt, das Personen beliebig oft heiraten können. Daher ist diese Zwischentabelle notwendig. Bild 3
Wie Du erkennst, leiste ich mir den Luxus gleichgeschlechtlicher, eingetragnerer Partnerschaften.

Normalformen? Der Entwurf ist redundanfrei und erfüllt alle Kriterien bis zur 3. NF. Solltest Du einen Fehler sehen, dann bitte ich, diesen konkret zu benennen.

Ich würde mich mehr an den Gedcom Standard halten.

Ok, wo finde ich den? Bisher war Gedcom für mich nur die Linearisierung von komplexen Beziehungstypen durch beleibig viele Redundanzen in jedem Block, so dass ich darauf warte, dass es eine XML-Variante geben wird. Gedcom und XML sind keine Datenbanken!! Schon die Multiuserfähigkeiten fehlen völlig. Das ist eine Austauschformat.

Konkret: Wo ist der Gedcom Standard verständlich beschrieben?

Weiters finde ich den GRAMPS Ansatz mit Personen, Erreignissen, Orte und Quellen sehr gut.

Ist das möglicherweise ein Lob?
Ich habe in vielen Programmen die Dokumentverwaltung (Quellen) vermisst. Es gibt immer wieder Anlässe, nachzuschauen, ob eine Information stimmt.

Nehmen wir die Suche nach den ältesten Vorfahren. Sie endet im allgemeinen an Personen, von denen man nur den Namen kennt und die anderen Daten (Geburt, Tod) ahnt. Bei den "Eheweibern", wie es in den alten Kirchenbüchern heißt, ist außer dem Vornamen nichts mehr dabei.
Diese Informationen befinden sich aber nicht an den Personen selbst, sondern an ihren Kindern (Geburtsbuch). Wenn ich also ein Datum habe, dann muss ich nachschauen, ob es real belegt oder geschätzt ist.

Also her mit Deinem normalisierten Ansatz, damit ich ihn bewerten kann.

Das Bessere ist der Feind des Guten.

Das soll erst einmal reichen. Bitte keine Kritik an Dingen, die man nicht voll überblickt.

Dein Waltschrat, der mit dem t