Eine Frage des Designs

Um auf dein Problem zurück zu kommen:
Du musst die Merkmale, die bestimmen ob eine natürliche Person ein Musiker, Schauspieler oder dein persönlicher Kontakt ist, in der DB ablegen. Da gibt es verschiedene Möglichkeiten, z.B. BIT Spalten für jede Kategorie wenn dein Datenmodell starr ist und keine Kategorien hinzukommen können. Deine Benutzeroberfläche öffnet dann die zugehörige Maske, je nachdem welches BIT gesetzt wurde. Sind mehrere BITs gesetzt, musst du bestimmen, welche vorrangig geöffnet wird, diese eventuell wechselbar machen oder eine vorgelagerte Auswahlmaske bauen.

Wenn du flexibel sein willst dann gliederst du die Kategorie Information in eine 1:n Tabelle aus, dort kannst du beliebige Kategorien erstellen und auch Zeiträume festlegen. Überhaupt würde ich nicht mit einem Tool wie DIA irgendwelche Masken bauen und dann die Tabellen dazu sondern den Weg der Normalisierung gehen oder zumindest mit einem ERD beginnen.
 
Zuletzt bearbeitet von einem Moderator:
Werbung:
@ukulele: Frage: Was ist eine natürliche Person? Gibt es unnatürliche Personen? :) Falls du glaubst, ich bin geistig gestört, und denke mir Personen aus, kann ich dich wirklich beruhigen :p Spaß beiseite: Dein Ansatz ist schon mal interessant. Ich bin gerade dabei mein Adressbuch zu modellieren. Wenn ich damit fertig bin, dann kann ich dieses Problem wieder angehen. Aber dennoch möchte ich zu deinem Lösungsansatz etwas sagen. Darf ich fragen für was BIT steht?

Das mit der Kategorie ist interessant. Mal sehen, ob ich das richtig verstanden habe. Die Personen sollen zunächst neutral angelegt werden. Stell es dir eher wie Stammdaten vor. Stammdaten sind ja dazu da, dass man immer wieder darauf zurückgreifen kann. Jetzt lege ich eine Person an, die - sagen wir mal - Jennifer Aniston an. Zunächst einmal ist erst einmal unwichtig zu wissen, ob diese Person meine Frau, meine Freundin, meine Schwester oder gar nur eine Schauspielerin oder Musiker oder ein Buchautor ist. Völlig unwichtig. Keine Merkmale, keine Kategorie etc. Da man in meinem Programm unter anderem Bücher, Filme und was weiß der Geier verwalten kann, gehe ich jetzt dazu über und lege einen Film an. Jetzt lege ich den Film Meine erfundene Ehefrau an. In diesem Zuge komme ich neben den technischen Angaben zu dem Film auch an dem Punkt, wo Personen, die an dem Film beteiligt sind/waren, hinzuzufügen. Und da ist die gute Frau wieder, die Jennifer Aniston. Wunderbar. Bis hierher alles kein Problem. Jetzt hat die Person das Merkmal "Schauspielerin". Eines Abends gehe ich spazieren, treffe diese Frau und sie gibt mir gleich mal ihre persönliche E-Mail-Adresse, und flüstert mir ihre Mobilnummer ins Ohr. Juhu, jetzt kann ich ein Adressbuch anlegen, greife wieder auf die Person-Stammdaten zu, suche Jennifer Aniston heraus, und füge die Daten hinzu, die ich eben bekommen habe, und speichere ab. Jetzt hat sie ein weitere Merkmal - Schauspieler und Adressbuch. Und weil die Frau so hochbegabt ist, schreibt sie noch ein Buch, sagen wir mal - Harry Potters Sohn und der trottelige Nachbar. Also lege ich ein Buch an, und mache den gleichen Vorgang wie beim Anlegen eines Filmes. So meinst du das, richtig?

Zu dem Programm DIA. Die Benutzeroberfläche gestalte ich neben meiner Programmierung. Sie existiert also schon wirklich. Ich male sie nicht mit DIA. Ich versuche mit DIA nur grafisch darzustellen, wie ich mir meine Datenbank vorstelle. Als würde ich Block und Bleistift nehmen und dort malen. Und das mit dem ERD. Du meinst diese grafische Darstellung?
702px-Er-diagramm.svg.png
Erlaube mir meine Wortwahl, aber das sieht für mich einfach grauenhaft und schrecklich aus. Für mich ist das überhaupt kein Genuss. Da vergeht mir ja schon die Lust beim Anblick.
 
Mit BIT meine ich eine Spalte die nur zwei Werte haben kann, 0 oder 1. Du kannst also eine Spalte ist_Author oder ist_Angestellter nutzen und diese auf 1 setzen, das erleichtert dir eine Suche. Allerdings wäre diese Information in deinem Modell redundant, was auch Probleme mit sich bringt.

In deinem skizierten Modell sind Angestellter und Autor eigentlich eine Tabelle mit natürlichen Personen. Sie haben alle die gleichen Eigenschaften (Atribute) bilden also eine Entität. Die Beziehungen "leitet" und "verfasst" definieren, wer was ist. Jede Person, die einen Eintrag in "verfasst" hat ist Author, jede Person mit Fremdschlüssel in "Projekt" ist ein Leiter.
 
@Walter: Viele danke.

@ukulele: Du hast dich von der Skizze irritieren lassen, richtig? Die Skizze sollte nur als Beispiel dafür dienen, dass ich diese Darstellungen einfach grauenhaft finde. Denn du schriebst was vom ERD, und da musste ich gleich an dieses Modell bzw. an diese grafische Darstellung denken. Und das ist auch der Grund, wieso ich lieber mit DIA zeichne. Es gibt ein weiteres Programm, welches mir sogar gefällt, dass ist das Programm Toad Data Modeler 5.2 nur kannst du in der kostenlosen Version 25 Tabellen bearbeiten. Wenn es mehr werden soll, wird es kostenpflichtig. Und da ich kein Profi-Datenbank-Entwickler bin, wie ihr es seid, sondern nur gerne mit der Programmiersprache Python programmiere und die Datenbank eher dazu nutze, dass Datensätze in die Datenbank gespeichert werden, sehe ich es nicht ein das Programm zu kaufen. Daher sehe ich DIA als eine gute Alternative. Kurzum: Die grafische Darstellung entspricht nicht meinem Inhalt, denn ich werde keine Angestellten verwalten :cool:
 
Das ERD ist aber, ob du es schön findest oder nicht, sehr übersichtlich und gut verständlich. Screenshots von Eingabemasken lassen zwar Spekulationen über die Tabellenstrukur zu, können aber auch ganz anders funktionieren. ERD Tools gibt es wie Sand am Meer, einige können die Tabellenstruktur auch direkt auslesen und sind für den privaten Gebrauch kostenlos.

Dein Fall und das Beispiel ERD behandeln im Prinzip die gleiche Struktur. Ob Angestellter und Autor oder Schauspieler und Adressbuchkontakt ist erstmal egal, eine einheitliche Tabelle für natürliche Personen macht meiner Meinung nach immer Sinn.
 
@ukulele: Lassen wir mal die grafische Darstellung der Eingabemaske meines Programm beiseite, Was ist an meiner grafischen Darstellung meiner Modellierung zu grauenhaft? Ich finde diese Chen-Notationen einfach... BÄÄÄÄH - KRISE - BOAH - AARRGGG - PFUI. Und was man nun wirklich nicht mag, muss man sich auch nicht reinziehen. Zum Glück gibt es auf der Welt immer Alternativen, und nicht nur ERD. :) Und dies ist hoffentlich nicht einheitlich bzw. wird in der DB-Entwicklung tatsächlich standardmäßig genutzt. Ich als Laie sehe in meiner Form mehr Struktur als in dieser - nahezu kindliche - Darstellung keines. Wenn du aber möchtest, kann ich mir der UML-Objekte in DIA bedienen. Das wäre eher mein Kompromiss :)
 
Werbung:
@ukulele: Ich vermute, das kann ich dir erst beantworten, wenn ich mein Adressbuch fertig modelliert habe. Ich war hier etwas vorschnell. Ich dachte, man könne diese Frage angehen, auch ohne dass man mit der Modellierung eines Adressbuches begonnen hat. Daher kann ich es noch nicht ganz beantworten. Aber bis jetzt hast du mir schon sehr weit geholfen.
 
Zurück
Oben