Neuigkeiten:

Wenn ihr euch für eine gute Antwort bedanken möchtet, im entsprechenden Posting einfach den Knopf "sag Danke" drücken!

Mobiles Hauptmenü

Primärschlüssel (Autowerte) so zweckmäßig?

Begonnen von Neuling1, November 29, 2012, 18:04:16

⏪ vorheriges - nächstes ⏩

Neuling1

Hallo,
ich habe 6 miteinander verknüpfte Tabellen, dazu Untertabellen. Das Formular besteht aus 6 Registersteuerelementen. jetzt bin ich plötzlich unsicher, ob ich die Tabellen richtig gemacht habe, weil ich in den Tabellen teilweise Primärschlüssel (Autowerte) habe, deren Zweck ich nicht mehr erkennen kann.

Ich wäre sehr dankbar, wenn einer mit Ahnung sich die DB mal ansieht und kommentiert. Ich mach das so mega selten


[Anhang gelöscht durch Administrator]
Datenerhebung dient dem Nachweis, nicht der Form der Prozedur, deren Qualität mit Hilfe von Datenerhebung nachgewiesen werden soll

MzKlMu

Hallo,
ein Bild des Beziehunsfensters wäre aussagefähiger gewesen als das 3 seitige PDF. Die Beziehungen sind das entscheidende und die fehlen.

Prinzipiell ist in jeder Tabelle ein Autowert als PK schon mal richtig.
Gruß Klaus

Neuling1

Hallo,
vielen Dank, dass du es dir ansiehst. hier kommt das Beziehungsfenster.
Die Untertabellen habe ich noch nicht in Beziehung gesetzt. Die Untertabellen dienen als vorgegebene Antwortauswahl, daher brauche ich ja Kombifelder in den Formularen, die ihrerseits dann "vor Ort" die Beziehungen zu den Haupttabellen erzeugen, oder?

[Anhang gelöscht durch Administrator]
Datenerhebung dient dem Nachweis, nicht der Form der Prozedur, deren Qualität mit Hilfe von Datenerhebung nachgewiesen werden soll

MzKlMu

Hallo,
lege auch für die Untertabellen Beziehungen an und vor allen Dingen mit referentieller Integrität, für alle Beziehungen, grundsätzlich.

Da Du immer einen Autowert als PK hast und eine Zahl (long) als Fremdschlüssel sehe ich bei den Beziehungen keinen Fehler. Ob diese aber sinnvoll sind kann ich nicht beurteilen, da ich die Zusammenhänge der Tabellen nicht kenne.

PS:
Warum hast Du eigentlich exakt die gleiche Frage 2x hier eingestellt?
Gruß Klaus

Neuling1

Aha! Danke, ich hatte sie schon angelegt, dann aber wieder gelöscht, wei es im Beziehungsfenster so verworren aussah. Also nicht erst in den Kombifeldern, sondern schon im Beziehungsfenster, ja?
Datenerhebung dient dem Nachweis, nicht der Form der Prozedur, deren Qualität mit Hilfe von Datenerhebung nachgewiesen werden soll

MzKlMu

Hallo,
in den Kombifeldern kann man doch keine Beziehung einstellen, oder was meinst Du damit?
Das Erstellen eines Kombis legt ja zunächst keine Beziehung an, zumindest keine mit RI.

Hast Du den Hinweis zu RI gelesen?

Und noch ein Hinweis, vorbeugend: Keine Nachschlagefelder (Kombifelder) in den Tabellen direkt anlegen.
Gruß Klaus

Neuling1

Hallo,
mit der referentiellen Integrität gibt es Probleme. Ich habe kontrolliert und in allen Tabellen die unterschiedlichen IDs auf "indiziert, ohne Duplikate" gesetzt, trotzdem bekomme ich die Fehlermeldung, wie in angehängter Powerpointfolie zu sehen. Was stimmt nicht? Jede Pat_ID soll 1 von einer Auswahl an Komplikationen haben, dafür gibt es je eine Tabelle mit spezifischer ID und der Pat_ID. Jede Auswahl hat ihrerseits Untertabellen zur Spezifizierung der Komplikation. Wo liegt mein Fehler?
Wenn du ein Kombifeld erstellt, bildet sich ja automatisch eine Beziehung. An die referentielle Integrität hatte ich nicht gedacht. Kombifeld kommt nur ins Formular, ist schon klar. Ich hatte vor, das Feld über die ID zu verknüpfen und dann auch die Spalte mit dem Klartext anzeigen zu lassen, damit klar ist, was hinter der Zahl steckt.

[Anhang gelöscht durch Administrator]
Datenerhebung dient dem Nachweis, nicht der Form der Prozedur, deren Qualität mit Hilfe von Datenerhebung nachgewiesen werden soll

MzKlMu

Hallo,
Du solltest darauf achten, dass die Fehlermeldung nichts verdeckt, ausgerechnet der interesante Teil des Fensters zur Erstellung der Beziehung ist verdeckt. Nämlich der Beziehungstyp.

Welcher Datentyp hat denn das Feld "Ver_ID" in der Infektionstabelle?

Noch ein Tip:
Es ist äußerst zweckmäßig, dass es in einer DB keine gleichen Feldnamen gibt in der komletten DB. Daher hänge ich an die Fremdschlüsselfelder immer ein _F an, also Ver_ID_F für die FK, der PK kannst Du lassen.
Gruß Klaus

Neuling1

es werden komischerweise immer 1:1 Beziehungen! Sollten es nicht 1:n Beziehungen werden? Ich bin noch ein zweites Mal durchgegangen und habe doch noch Fehler gefunden. Alle IDs sind jetzt wie beschrieben, Warum sollten die Felder unterschiedlich benannt werden? Kommt man nicht durcheinander, wenn es unterschiedliche Namen für das gleiche Feld gibt?
Datenerhebung dient dem Nachweis, nicht der Form der Prozedur, deren Qualität mit Hilfe von Datenerhebung nachgewiesen werden soll

MzKlMu

Hallo,
wie ist der Datentyp der n-Seite?
Die Fremdschlüsselfelder müssen Duplikate zulassen, erst dann wird 1:n daraus.
ZitatKommt man nicht durcheinander, wenn es unterschiedliche Namen für das gleiche Feld gibt?
Das sehe ich ehger umgekehrt,m stelle Dir vor, Du hast in 2 tabellen geliche Namen, welchen verwendest Du dann. Bei gleichen Feldnamen musst Du in Abfragen und Formularen immer den Tabellenamen voranstellen.
Und den Fremdschlüssel immer zweifelsfrei vom Primärschlüssel unterscheiden zu können ist äußerst wichtig.
Gruß Klaus

Neuling1

Guten Morgen,
vielen Dank für den guten Tipp mit den Duplikaten, da lag mein Fehler. jetzt neu benannte IDs und alle Beziehungen 1:n und es hat geklappt.
Die DB selbst kann ich nicht anhängen ist auch gezippt zu groß, daher mal als Power Point. Darin habe ich auch das Konzept geschrieben.
Vielen Dank auch dir, Franz, aber so ganz verstanden habe ich deinen Tipp nicht. Eigentlich gibt es keine Diagnosen. Jede Komplikation ist durch eine Untersuchung mit oder ohne Intervention entstanden, daher habe ich die ID Komplikation und Untersuchung als Fremdschlüssel mit in die T_Patient genommen. Ist es besser, eine weitere Tabelle anzulegen? Wie die aussehen sollte ist mir nicht klar
Aber vielen, vielen  Dank fürs Ansehen und vielleicht kannst du mehr sagen, wenn du die DB ansiehst (mit allen Beziehungen)

[Anhang gelöscht durch Administrator]
Datenerhebung dient dem Nachweis, nicht der Form der Prozedur, deren Qualität mit Hilfe von Datenerhebung nachgewiesen werden soll

MzKlMu

Hallo,
ZitatDie DB selbst kann ich nicht anhängen ist auch gezippt zu groß,
Hast Du die DB schon mal komprimiert/repariert?
Das ist ein Access eigenes Dienstprogramm das man besonders während der Entwicklung einr DB regelmäßig nutzen sollte, erst dann die DB zippen.
Gruß Klaus

Neuling1

unglaublich, ich hätte die DB nie im Leben vor der fertigstellung komprimiert, super Erfolg.
Musste jetzt eine ganze Weile andere Sachen machen, gehe gleich erst wieder an diese Arbeit. Also es gibt jetzt natürlich Änderungen bei den Namen der Steuerelemente im Formular, das ändere ich noch alles

[Anhang gelöscht durch Administrator]
Datenerhebung dient dem Nachweis, nicht der Form der Prozedur, deren Qualität mit Hilfe von Datenerhebung nachgewiesen werden soll

Neuling1

es wird gerade diskutiert, ob eine weitere Tabelle erforderlich ist.
Der Patient kann durchaus noch irgendwann einmal eine weitere Untersuchung bekommen, bei der wieder eine Komplikation auftritt, die gemeldet werden muss.
Das Untersuchungsdatum und die Untersuchung mit der Verbindung zur Komplikation und das Komplikationsdatum liegt in der Tabelle Patienten.
Damit ist diese eine Komplikationsmeldung abgeschlossen. Hat der selbe Patient in drei Monaten eine weitere komplikationsreiche untersuchung, kann ich diese dann so nicht mehr erfassen?
Das Ziel der Datenbank ist die Erfassung von Komplikationen, die Krankengeschichte im KIS bezieht sich auf den Patienten. Ich muss hier nicht darstellen, wie viele Komplikationen dieser Patient hatte. Wir machen Qualitätsmanagement, wollen erfassen, wie hoch unsere Komplikationsrate ist und wenn, wo es Schwachstellen gibt, die wir verbessern können.
Sollte ich eine separate Tabelle mit Untersuchungsdatum und Komplikaionsdatum erstellen müssen, ist mir nicht klar, wie mein nächster Schritt sei muss
Datenerhebung dient dem Nachweis, nicht der Form der Prozedur, deren Qualität mit Hilfe von Datenerhebung nachgewiesen werden soll