Adressbuch

[Sophus]

Hallo Leute,

ich bin gerade dabei ein Adressbuch zu modellieren. Ich befürchte, dass ich gerade gedanklich mächtig festsitze. Zu den Grundrissen meines Adressbuches. In meinem Adressbuch soll eine Person (rein theoretisch) unendlich viele Mail-Adresse, Internet-Adresse, Festnetz-, Mobil, Pager und Faxnummer haben. Die Person kann so viele Wohnorte haben wie er will (In Deutschland darfst du einen Hauptwohnsitz und unendlich viele Nebenwohnsitze bzw. Zweitwohnsitze haben). Die Person darf darüber hinaus mehrere Nationalitäten/Staatszugehörigkeiten besitzen. Die Adress-Daten sollen sich In Privat und Geschäft aufteilen lassen. Es kann ja sein, dass ich von meinem Freund die Telefonnummer von seinem Arbeitsplatz habe - für den Fall eines Falles. Das sind erst einmal die Grundrisse.

Ich werde euch insgesamt drei Bilder präsentieren. Einmal das Bild meiner Modellierung, und dann zwei Bilder von meinem Programm. Ich weiß, euch interessiert das Front-Ended erst einmal wenig, aber ich bin der Meinung, dass eine visuelle Anschauung viele Dinge leichter begreiflich machen, als wenn man nur reinen, langweilige und oft unverständliche Texte schreibt. Und ihr könnt gleich erkennen, welche Vorstellung ich von meinem Programm habe. (Ich hoffe, ich muss nicht erwähnen, dass die Daten in der Benutzeroberfläche reine fiktive Daten sind )

Zuerst die Front-Ended-Bilder meines Programmes.



Nun meine bisherige Modellierung.

Wie wir sehen, bin ich noch nicht weit gekommen, der Grund ist, weil ich hier schon gedanklich feststecke. Wo ich feststecke? Werfen wir mal einen Blick auf die beiden Relationen Privat und Geschäft. Wir erinnern uns, dass die Adress-Daten sowohl Privat als auch Geschäft enthalten sollen. Wenn ich dieses Konzept weiterführen würde, zum Beispiel bei Kommunikation, dann wird das sehr schnell unübersichtlich. Denn unübersichtlich wird es ja hier schon beim Wohnsitz. Hier bin ich erst einmal bei dem Wohnorten stecken geblieben. Irgendwie habe ich das Gefühl, dass ich auf dem falschem Dampfer bin mit meiner Modellierung. Und deswegen wende ich mich Hilfe suchend an euch.

 

[Distrilec]

1. Eine gute geschriebene Beschreibung ist (zumindest mir) sehr viel mehr Wert als ein nichts-aussagendes Bild.
2. Ohne DDLs mach ich hier leider erstmal nichts... Bei kleinen Modellen kann man das ja noch ganz gut im Kopf nachvollziehen, aber bei 25 Tabellen mag ich die Constraints doch gerne schriftlich

Edit:
Zwei Tabellen für eine logische Einheit sind meistens sinnlos.
Warum möchte man das Bundesland in Geschäftlich und Privat aufteilen? Man kann auch einfach eine Tabelle nehmen und eine Spalte (Boolean, 0/1, 'Y'/'N' oder etwas ähnliches) einbauen... Reduziert die Arbeit enorm

 

[Sophus]

@Distrilec: Hier prallen gleich zwei unterschiedliche Ansichten aufeinander Ich bin eher der visuelle Typ, und habe es gern, wenn man zum Text auch eine grafische Darstellung hat. Und so absolut nichtssagend sind meine Bilder auch wieder nicht. Und was soll DDLs sein? Ich kann mit der Abkürzung nichts anfangen (wobei ich Abkürzungen unter meist gegebenen Umständen sowieso nicht leiden kann). Aber mal abgesehen von diesem ominösen DDL ging ich davon aus, dass meine Modellierung recht übersichtlich dargestellt sind. Zumal ich ja nicht möchte, dass man jetzt alle Relationen durchgeht. Das Problem war ja klar abgesteckt, und zwar die Aufteilung in Privat und Geschäft.

Zurück zu deinem Vorschlag. Wie soll ich es mir vorstellen? Ich lösche beide Relationen, also Privat und Geschäft, und setze an deren Stelle eine Relation hin? Und dann über Boolean arbeiten? Wenn ich mir die ersten beiden Front-Ended-Bilder anschaue, dann frage ich mich, wie das mit der einen Tabelle von Statten gehen soll?

 

[akretschmer]

Data Definition Language.

 

[Sophus]

@akretschmer: Danke.

 

[Distrilec]

Recht simpel...
du hast deinen Reiter "Privat" der dieses Statement hält:

Select *
From bundesland b
Where b.dein_boolean = False
And b.person_id = :person_id;

und du hast deinen zweiten Reiter der dieses Statement hält:

Select *
From bundesland b
Where b.dein_boolean = True
And b.person_id = :person_id;

Reduziert dein Modell schonmal um 5 Tabellen, wenn ich mich jetzt nicht irre.


DDLs (Also "Create Table...."-Statements) möchte ich aus folgendem Grund:
Du gehst wahrscheinlich bei deiner Modellierung hauptsächlich nach einer gewissen Normalform die du erreichen willst (so wie ich das sehe BCNF, wenn ich beim Überfliegen jetzt nichts übersehen habe).
Dieser Gedanke ist bei produktiven Modellen aber meistens nicht komplett richtig. Da es Werte geben kann die man aus Performance- oder Übersichtlichkeitsgründen auch gerne mal redundant anlegt.
Da ich hier nicht versuche eine ganz allgemein gehaltene Antwort zu geben, so wie sie jeder Hobby-Programmierer in der Schule lernt (oder auf Wikipedia nachlesen kann), sondern eine Antwort die auf dein Modell, deine Anforderungen und vor allem deine Daten abgestimmt ist, habe ich ganz gerne die Möglichkeit in meiner Datenbank selbst mit dem Modell rumzuspielen.

Und du kannst dir sicher vorstellen das ich nicht für 25 Tabellen DDLs selbst zusammenschreibe wenn du sie schon rumliegen hast

Ich kann dir natürlich auch einfach sämtliche Normalisierungsfehler aus deinem Bild aufzählen und du kannst dir dann selbst um Front-End Integration Gedanken machen

 

[Sophus]

@Distrilec: Zunächst einmal vielen Dank für deine Antwort und Anmerkungen. Ich komme gerade nach Hause, und möchte erst einmal antworten. Ich werde mich noch mal melden. Nun, was mir an diesen Boolean-Werten ganz und gar nicht gefällt, ist die Tatsache, dass man von einer Person beide Adress-Daten haben kann. Man brauche sich nur mal vorzustellen, dass einer von euren Freunden selbstständig ist und somit ein eigenes Unternehmen führt. Dann komme ich mit True/False, 0/1 auch nicht weit.

Des Weiteren muss ich eingestehen, dass ich keine SQL-Statements habe. Ich modelliere zunächst einmal nur grafisch mit dem DIA-Programm. Warum? Ich brauche für meinen Geschmack zunächst keine Statements. Erst einmal muss ich grafisch konstruieren, wie meine Datenbank aussehen soll. Und ich programmiere hier mit Python. Dort gibt es eine wunderbare und mächtige Bibliothek, wo man weitestgehend auf SQL-Statements verzichten kann. Man programmiert dann auf einen sogenannten High-Level. Mit SQL-Statements zu arbeiten heißt dann "Low-Level". Im High-Level muss der Programmier in Python nichts konkretes wissen. Das spielt alles in der Bibliothek. Die Bibliothek nimmt uns fast 95 Prozent die Arbeit ab. Aus diesem Grund möchte ich mich also nicht mit den ganzen Statements rumschlagen, da ich sie sowieso in Python nicht brauche.

Und meine letzte Anmerkung. Das nächste Mal werde ich wirklich nur den kleinsten Ausschnitt meiner Modellierung zeigen So kommt man gar nicht in Versuchung all die anderen Relationen mit einzubeziehen, sondern, sich nur auf das Problem zu konzentrieren.

Ich melde mich später nochmal.

 

[akretschmer]

Das, was bei solchen Tools oft so runten rausfällt ist für jemanden, der SQL halbwegs kann, einfach nur grauenhaft.

Das, was Du über BOOLEAN schreibst, zeigt, daß Du das auch noch nicht so ganz verstanden hast.

Egal. Ich wünsch Dir Erfolg.

 

[Sophus]

@akretschmer: Ich kenne die Kommunikation eher so, dass man erst einmal kritisiert, und dann aufklärt. Du sagst, ich habe Boolean nicht ganz verstanden. Gut, ist eine Kritik. Und weiter? Punkt? Alles? Das läuft komplett entgegen einer menschlichen Kommunikation. Dann kläre mich doch mal auf, weshalb du glaubst, ich habe das nicht ganz verstanden, und zeige dann auf, wie es richtig zu verstehen sei?

 

[Sophus]

So, ich melde mich wieder zurück. Auf Basis der Kritik seitens Distrilec habe ich nochmal (grafisch) modelliert. Mein vorläufiges Ergebnis sieht wie folgt aus:

Was mich ein wenig Kopfzerbrechen bereitet, ist die Tatsache, dass ich dass immer noch nicht ganz verinnerlicht habe. Die Relation Tabelle_ohne_Name habe ich mit Absichtlich so benannt, da ich wirklich keine Ahnung habe, wie die heißen soll. Daran erkennt man schon meine Unsicherheit. Hier soll mit Boolean-Werten gearbeitet werden. Wenn es also True ist, dann wahrscheinlich für Geschäft, und wenn False, dann für Privat? Und was ist denn, wenn ich beide Adress-Daten einer Person habe - einmal Privat und einmal Geschäft? Ich muss eingestehen, dass mir hier etwas Phantasie fehlt.

 

[Distrilec]

@Sophus was du da vorhast ist ein Graus für jeden DBA/DB-Entwickler... Du behandelst eine Datenbank wie eine Black Box... Du wirfst Daten rein und irgendwann drückst du auf einen Knopf und es kommen Daten raus... Ohne die ganzen Zusammenhänge, die sich innerhalb dieser Black Box abspielen, verstanden zu haben oder auch nur Ansatzweise zu deinem Vorteil zu nutzen.

Ich melde mich morgen Nachmittag noch einmal mit einem etwas optimierten Bild... Das dann etwas praktikabler ist...

 

[Sophus]

@Distrilec: Das meine Lösung ein Graus ist weiß ich. Wäre ich sonst hier, und würde um eure Hilfe bitten? Ich freue mich schon auf morgen Nachmittag, und bin auf deinen Lösungsansatz gespannt

 

[akretschmer]

Nun, was mir an diesen Boolean-Werten ganz und gar nicht gefällt, ist die Tatsache, dass man von einer Person beide Adress-Daten haben kann. Man brauche sich nur mal vorzustellen, dass einer von euren Freunden selbstständig ist und somit ein eigenes Unternehmen führt. Dann komme ich mit True/False, 0/1 auch nicht weit.

Genau das ist doch gezeigt worden. Adress-Tabelle mit einer Spalte die anzeigt, ob privat oder geschäftlich. Bool. Wie man das abfrage wurde Dir auch gezeigt. Wie Du erzwingst, daß es nur eine private und/oder eine geschäftliche Adresse geben kann, sag ich Dir jetzt noch: beziehe diese Spalte mit in den primary Key ein.

Mal als ganz gurzes Schnipsel DDL:

create table adressen(name text, ort text, privat bool, primary key (name, privat));

So kannst Du je name bis zu 2 Adressen definieren, aber nur eine mit privat = true und eine mit privat = false.

 

[Sophus]

Genau das ist doch gezeigt worden. Adress-Tabelle mit einer Spalte die anzeigt, ob privat oder geschäftlich. Bool.

Und jetzt habe ich dich in flagranti ertappt. Oder aber ich habe dich falsch verstanden. Ich habe dich mal zitiert und fett hervorgehoben. Du sagst ja selber, Privat ODER Geschäft. In meiner Vorstellung gibt es kein ODER. Eine Person hat nicht Privat ODER Geschäft, sondern durchaus Privat UND Geschäft. Bei dir verstehe ich eher, entweder das eine oder das andere, aber nicht beides. Aber ich bin mir ziemlich sicher, dass ich dich nur falsch verstanden habe oder es einfach nicht kapiere.

 

[akretschmer]

Warum schrieb ich einklich das DDL dazu? Dann halt noch DML:

test=# create table adressen(name text, ort text, privat bool, primary key (name, privat));
CREATE TABLE
test=*# insert into adressen values ('ich','dort',true);
INSERT 0 1
test=*# insert into adressen values ('ich','woanders',false);
INSERT 0 1
test=*#

So what?