Office: Dummydatensatz oder Verzicht auf ref.Int.

Ach Mensch, ein bisschen off topic muss auch mal sein *biggrin.gif*

Auch wenn ich die #7 nicht gelesen habe, ist das nicht so schlimm.
Ich habe das immer so eingestellt, dass der Fremschlüssel dann einen Nullwert hat, statt 0. So lässt sich dann auch die referenzielle Integrität herstellen, auch wenn für eine Fahrt gar kein Fahrgast eingetragen ist.
Andere Möglichkeit ist, dass du allen, denen du jetzt eine 6 gegeben hast, vielleicht doch noch mal ein paar Sekunden an Bedenkzeit schenkst. Denn statt einer m:n Relation wäre hier auch eine 1:1-verknüpfte Tabelle angebracht. Schlüssel wäre dann hier wieder deine Fahrt und der Fahrgast wäre nur Fremdschlüssel.

Wo ich gerade Atrus Beitrag gelesen habe: Und schon liegt die Antwort auf die Frage wieder in der Sache der Natur. Ein Praxisbesuch hat immer nur einen Patienten, daran wird sich nicht so schnell etwas ändern, wie an dem Umstand, dass eine Fahrt nur mit einem Fahrgast gemacht werden kann.

 

Hallo,

Hoffentlich für die "MOF-Polizei" nicht zu sehr OT, aber diese wichtige Information in #7 hätte in deine Fragestellung gehört.

my 2Cent
Andreas

 

Ok, ich greife noch mal ein anderes Beispiel auf um den Problemkern deutlicher zu machen.
Bitte löst euch von dem Fahrgastbeispiel!

Ein Physiotherapeut hat einen festen gerasterten Terminplan
Alle 20 Minuten einen Termin.
In diesem Terminraster legt er Patiententermine an
D.h. in der tbl_Termine stehen z.B.
Datum | Uhrzeit | Patienten_ID_FK ...

Jetzt will er einzelne Termine blocken.
z.B. mit einem Eintrag "Organisation" d.h. zu diesem Terminzeitpunkt kann er keinen Patienten behandeln, da er z.B. dringende Telefonate erledigen muss.

Besteht zw. tbl_Patienten und tbl_Termine RI für die Patienten_ID so muss "Organisation" auch als System- bzw. Dummypatient angelegt werden.

Ich wollte gerne Alternativen Diskutieren, da "Organisation" z.B. keinen Geburtstag hat, wie "echte" Patienten.

Lagert man "Organisation" in eine andere Tabelle aus, kann man die RI zw. tbl_Patienten und tbl_Termine nicht beibehalten.

Ich hoffe, der Kern der Aufgabe ist nun deutlicher geworden.

[EDIT]

Klar, und hat - wie man an deinem Schriftbild erkennen kann - sogar genutzt *wink.gif*

@andreas
OT:

Bin ich befördert worden? *cool.gif*
/OT

Du hast recht, manchmal erkennt man jedoch erst an der Reaktion in den Beiträgen, dass die erste Fragestellung nicht für alle eindeutig zu lesen ist.
Auf der anderen Seite ist es aber auch von Vorteil außer der Eingangsfragestellung die weiteren Beiträge zu beachten *wink.gif*
[/Edit]

 

Hallo Marsu,

warum löschst Du nicht den Datensatz aus tbl_Termine, der nicht von einem Patienten belegt werden kann?

 

Naja, vielleicht hast du jetzt auch meinen Beitrag überlesen *eek.gif* *biggrin.gif*

 

Dann gibt es also:
Slots (soll heißen definierte Zeiträume)
Patienten
Tätigkeiten (Pateint behandeln, Mittagspause, telefonieren)

Dementsprechend
Stamm-Tabellen:
Slots
Patienten
Tätigkeiten

Zuordnungstabellen:
Slot zu Tätigkeit
Tätigkeit zu Patient

Jede Tätigkeit, der ein Patient zugeordnet ist, gehört also zum eigentlichen Geschäft des Therapeuten; jede Tätigkeit, der kein Patient zugeordnet ist, gehört zu den Verwaltungsarbeiten und Pausen.

 

ich war noch mit der Formulierung des letzten Beitrags/Änderung beschäftigt.

Die Möglichkeit mit den Nullwerten kam mir auch in den Sinn.
Problematisch ist, dass dann anhand der tbl_Termine unterschiedliche Dummytermine wie "Organisation" und "Aufholzeit" nicht unterschieden werden können.

Ansonsten sind dass genau die Vorschläge, die ich mir gewünscht hatte.
(ich streich deine sechs aus dem roten Buch *wink.gif*)

 

Die Antwort war schon zu verstehen.
=> Ein besseres Beispiel muss noch nicht gut sein und kann vom eigentlichen Problem ablenken. Sichtbar ist, dass es allgemein das Bestreben gibt, Dummydatensätze durch eine bessere Datenmodellierung vermeiden. Der Hinweis von Ingo in #5 (zusätzliche Lookuptabelle) zählt auch dazu.
Datenmodellierung hängt nun aber von konkreten Umständen ab.

Um den Fall auf die eingangs genannte 1:n-Beziehung fest zu zurren: Kein Fahrgast wäre eine echte Information und gleichwertig zu Fahrgast_X. Da würde ich dann die Bezeichnung Dummy für irreführend halten, und die Information gehört in die n-Tabelle (Fall B).
Das wäre auch schon ein Gebot der Einfachheit, man sollte da auch die nachfolgende Verarbeitbarkeit im Auge haben. Falls man dann später "richtige" Abfragen bauen muss, wird man einen einfachen Aufbau zu schätzen wissen.

Neue Aufgabenstellung (in meinen Augen):

Du bist noch bei 1:n-Beziehung? Dann wäre für mich die Termintabelle die Masterseite (jeden Termin gibt es nur einmal), und ob man einem Termin einen Kunden zuordnet, wäre beliebig (kein Problem für RI).
Für belegbare oder freizuhaltende Termine könnte man in der Termintabelle ein Merkmal hinterlegen.

 

\@Maxel

Es werden nur Datensätze angelegt, die mit Patienten oder Fremdaufgaben belegt sind. Sonst müsste ich rel. viele Datensätze anlegen, die nicht genutzt werden.

@Eberhard
Kein Fahrgast kann unterschiedliche Gründe haben "Rückruf", "Fahrtabbruch" ... für jede dieser Möglichkeiten muss ein SYSTEM-Fahrgast vorhanden sein.

Daher ist die Aufgabenstellung im Kern die gleiche:

Beim letzten Beispiel geht es um die folgende Konstelation.
Patiententabelle (Master) => jeder Patient kann mehrere Einträge in Termine haben => 1:n zwischen Patienten und Termine
Will ich diese RI aufrecht erhalten, müssen auch Terminblockierungen wie "Aufholzeit" und "Organisation" als SYSTEM-Patienten in der Patiententabelle vorhanden sein.

 

Wie ebs17 es schon angesprochen hat, hast du ja noch die Möglichkeit ein weiteres Merkmal in deiner Termin-Tabelle zu führen. Nur wäre dann hier eine Abhängigkeit zwischen zwischen zwei Feldern (bei Organisation/Ausgleich kann Patient leer sein, bei Behandlung nicht) Um dann mit den Regeln der Normalisierung konform zu sein, müsste der Patient dann wieder in eine andere Tabelle (1:1-Relation zwischen Termin und PatientenTermin) ausgelagert werden.
Persönlich halte ich das allerdings gerade bei dem Fall für übertrieben.

 

Hallo,
nun möchte ich mich auch daran beteiligen. Schließlich geht dieser Thread auf mein Anliegen zurück.

In meiner Datenbank habe ich zwei, ich nenn' sie mal, Haupttabellen (tblJornal, tblPatientendaten)

tblJournal enthält alle einsatzrelevanten Daten und tblPatientendaten enthält alle Daten des Patienten, wie Name Vorname Geburtsdatum usw.

Daneben gibt es noch weitere Detail- bzw. Datentabellen.

In meinem Modell stehen alle Detail- bzw. Datentabellen, die mit sich auf den Einsatz beziehen, z.b. Fahrzeuge, links von der Tabelle Journal und alle Daten die mit den Patientendaten zu tun haben auf der rechten Seite.

Da es nun Einsätze gibt, zu denen es keine Daten gibt, die mit der Tabelle Patientendaten in Verbindung stehen, war nun die Frage auf gekommen, wo gehört welcher Fremdschlüssel hin und wie stehen die Tabellen miteinander in Beziehung.

Ich habe in der Tabelle Patientendaten den Fremdschlüssel aus der Tabelle Journal stehen, da es zu jedem Datensatz in der Tabelle Patientendaten einen Datensatz in der Tabelle Journal gibt, aber nicht umgekehrt. Das heißt, das es Datensätze in der Tabelle Journal gibt, zu denen es keine weiteren Daten in der Tabelle Patientendaten, in den Tabellen rechts gibt.

Von Dummys halte ich persönlich nicht viel, irgendwie muss es noch eine andere Lösung geben.

Wichtig ist auch, das wenn noch keine Patientendaten zur Verfügung stehen, der Einsatz, also die reinen Einsatzdaten trotzdem vollständig eingetragen werden können.

Erschwerend kam noch hinzu, das es eine weitere Tabelle (Dauerpatienten) mit Patientendaten gibt, die identisch ist mit der Tabelle Patientendaten. Diese enthält Patientendaten, die u.U. noch nicht befördert wurden also nicht in der Tabelle Patientendaten enthalten sind. Diese ist auch in einem gewissen Fluss, d.h. es kommen ständig welche hinzu bzw. nicht mehr aktuelle werden gelöscht. Diese habe ich noch nirgends zugeordnet.

Ich habe mal das Datenbankmodel, die Beziehungen, ausgedruckt und im Anhang beigefügt sowie eine Testdatenbank.
Ich habe nicht alle Tabellen mit in den Anhang eingefügt und auch in dem Beziehungsausdruck sind nicht alle enthalten.

Ich könnt ja mal schauen was ihr davon halten und wo ich ggf. einen Gedankenfehler gemacht habe.

Gruß
Christoph

 

Na, dann misch ich mich auch noch mal ein.
Im ersten Beispiel von Marsu gibt es die zwei Tabellen Fahrten und Fahrgäste.
Dazwischen gehört eine m:n Relation (mehrere Fahrgäste in einer Fahrt).
In einer 'Systemfahrt' ohne Fahrgast wird kein Satz in dieser Tabelle angelegt.
Und eventuell ist es sinnvoll, in einer weiteren 1:n Relation von Fahrten zu Fahrtzwecken diese zu speichern.

Einen Therapeuten mit seinen Terminen würde ich ähnlich handhaben.
Vielleicht gibt's auch Gruppentermine? Jedenfalls gehören die Fremdschlüssel der Patienten (analog zu den Passagieren) nicht direkt in die Termine (Fahrten) sondern in eine weitere Relation.

 

Hallo,

In meiner Tabelle gibt es zu jedem Datensatz in der Tabelle Journal nur max. einen Datensatz in der Tabelle Patienten oder gar keinen.

Sollten mal mehrere Patienten transportiert werden, gibt es, bisher, zwei Identische Datensätze in der Tabelle Journal aber mit unterschiedlicher Fahrtberichts-Nr. (FbNr2) -Primärschlüssel-

Christoph

 

Hallo Christoph!

Hmm, deine Problembeschreibung ist jetzt aber so speziell, dass die eigentlich in einen eigenen Thread gehören sollte.
Vieleicht verschiebt einer der Moderatoren Christophs Beitrag und meine Antwort in einen neuen Thread?

Zunächst mal zu den Dauerpatienten: Die gehören zusammen mit den anderen Patienten auch in eine Tabelle und erhalten ein zusätzliches Kennzeichen Dauerpatient Ja/Nein.
Es kann aber auch sein, dass es einen Patienten gibt, der für einen bestimmten Zeitraum Dauerpatient ist und dann wieder nicht. Dann wäre ein Zeitraum von-bis erforderlich und eine m:n Beziehung hilfreich. Ein Patient kann ja auch mehrmals Dauerpatient sein.

Was ist denn, wenn ein Patient mehrmals transportiert wird? Wird der dann mehrmals in der Patiententabelle angelegt oder wird der bereits vorhandene Datensatz wieder verwendet? Letzteres wäre dann eine m:n Beziehung.

Die Einsatzart kann dann um die erforderlichen Leerfahrten problemlos erweitert werden. Das kann man dann über ein Eingabeformular steuern. Wenn Leerfahrt können keine Patientendaten erfasst werden.

Die beiden PersonenIDs im Journal sind zum Darstellen der "Besatzungsmitglieder" des Rettungswagens gedacht? Auch hier würde ich eine m:n Beziehung zwischen Journal und "Besatzungsmiglied" herstellen. Dann können beliebig viele eingetragen werden.

In der Beziehungsanzeige deiner DB sind einige Verknüpfungstypen nicht Typ 1. Ich würde die alle auf Typ 1 ändern. Die anderen machen keinen Sinn. Die Darstellung was angezeigt werden soll erfolgt dann in Abfragen und in den Formularen.

In einem anderen Thread hat Hans-Christian geschrieben: Trenne Bewegungsdaten von Stammdaten. Ich denke, dass gilt auch hier. Schreibe dir auf, was die Stammdaten sind (Rettungswache, Rettungsfahrzeug, Einsatzarten, Patientendaten...) und was die Bewegungsdaten sind (Fahrten...).

Warum gibt es zwischen Rettungswachen - Rettungsmittel - Journal noch eine Beziehung Rettungswachen - DieseRw - Journal? Mit der ersten Beziehung kennst du über die IDFz die zugehörige Rettungswache und das Rettungsfahrzeug. Die letzte Beziehung wäre dann unnötig.

Grüße
Ingo

 

Das widerspricht doch schon eigentlich wieder der Beschreibung der Realität, dass es nur eine Fahrt gibt. Mit einer m:n-Tabelle zwischen Journal und PatientenDaten liegst du wohl besser. Vor allem, weil du ja jetzt gesagt hast, dass es mehrere Patienten pro Fahrt geben kann. Wenn es eine Leerfahrt gibt, dann kannst du das im Journal als Artenmerkmal aufnehmen, bei dem dann keine Personen aufgenommen werden können. Bei normalen Fahrten kannst du auch auch zu einem späteren Zeitpunkt eine oder meherere Personen aufnehmen.

@Claypool: Das Thema ist hier schon ganz richtig aufgehoben.

Ach ja: Auch Dauerpatienten sind Patienten. D.h. die gehören beide in eine Tabelle