Riesige(?) Datenbank splitten in 1:1 Beziehungen oder nicht?

[dille999]

Hallo,

erstmal vielen Dank für die ganzen Posts. Nachdem bei der Telekom eine Platine durchgebrannt war und ich einer von 64 Teilnehmern meines Ortes wurde, die kein Internet mehr hatten (und da sag nochmal einer, die TK behebt Probleme schnell >1Monat) und ich danach mit einer Lungenentzündung völlig brach lag, melde ich mich erst jetzt.

Für mein eigentliches Problem einfach runter zum ABER. Zunächst aber möchte ich auf meine Poster eingehen:

Zunächst zu Uli:
Der Tipp war Gold wert (auch wenn ich wegen fehlenden DSL den Tipp nicht mehr lesen konnte, habe ich zu genau diesem zwischen den Jahren gegriffen). Ich kann dieses Buch jeden Anfänger wärmstens empfehlen. Liest sich wirklich schnell und gut und ist dabei sehr verständlich (sage ich nur, weil es vielleicht auch andere Leser dieses Posts gibt).

Dann zu MzKlMu:
Ja. Das ist wirklich eine total elegante Lösung. Kurz, effizient und extrem kompakt. Aber für einen wie mich auf "Access-Level 1" ist eine Datenbank auf "Access-Level Ultimate-Unbelievable-Eternal-999" relativ überfordernd. Im momentanen Zustand geht dies noch, aber wenn die erst einmal voll ist, suche ich mir nur noch einen Wolf nach Zahlen, falls was ist.
Dieser modulare Ansatz (nenne ich jetzt mal so) ist sicherlich sehr effizient und total durchnormalisiert, aber ein Punkt der mir wichtig ist, wird nicht erfüllt: Dass die einzelnen AEDLs nicht getrennt sind: Bei diesem Ansatz kann bspw. bei Patient x das Attribut Sehvermögen gleich mehrfach eingetragen werden, während andere Attribute erst gar nicht erscheinen:
Das wäre vergleichbar einer Kundendatenbank, in der manche Kunden mehrere Straßen haben, aber keinen Wohnort, andere wiederum einen Ort, ober ohne Straße und andere Straße und Ort, aber keinen Namen...
Nichtsdestotrotz ist dies ein unglaublich tolles Datenbankdesign (HUT AB!), von dem ich trotz des o.g. Buches nochmal einiges gelernt habe.
Ich weiß gar nicht was ich sagen soll, weil Du Dir so viel Mühe und Aufwand gemacht hast...

Jedenfalls habe ich lange hin und her überlegt, deine Datenbank "nachprogrammiert" (damit ich als Anfänger das ganze so halbwegs verstehe) obschon ich in der internetlosen Zeit einen funktionierenden Okolyt erstellt habe (jenseits von allem was man Durchnormalisiert nennen würde), aber letztlich entschieden, dass dieser Ansatz Zukunftsmusik ist. Nach diesem Projekt werde ich mich vielleicht 1,2 und mehr Jahre nicht mehr mit Access beschäftigen, und danach eine Datenbank zu erweitern, die einen Anfänger ohnehin schon an seine Grenzen bringt, ...

Lange Rede kurzer Sinn: Ich habe mich mit dem Buch beschäftigt und nochmals neu angefangen.
Ich muss zugeben, dass ich ein total schlechtes Gewissen habe, weil Du MzKlMu dir so viel Mühe gegeben hast, aber ich muss da meinen Weg selber gehen. Und der beginnt bekanntlich am Anfang, nicht am Ende...

Mein Einstiegsfehler mit den 1:1 Beziehungen hatte ich ad Acta gelegt und alles über 1:n Beziehungen angelegt. Damit funktionierte mein Ansatz wirklich besser. Kurioserweise wollte ich auf Nummer sicher gehen und dafür sorgen, dass die Benutzer der Datenbank (die noch viel weniger Ahnung haben als ich und wirklich alles hinkriegen, was sie nicht sollen) keine doppelten Datensätze anlegen können (also dass ein Patient 3x verschiedene AEDL01 besitzt). Da habe ich den Eintrag "ohne Duplikate" gefunden.
Was soll ich sagen? Die Datenbank funktioniert weiterhin aber Access machte mir aus allen Beziehungen nun 1:1, wie ich anfangs vor hatte...

So bin ich relativ zufrieden. Einzig die Organisation von Ärzten und Angehörigen will ich noch umschreiben, weil mir da der Ansatz von MzKlMu ziemlich gut gefällt und mir das als der nächste Schritt meines Fortkommens erscheint.


ABER:

Dummerweise habe ich momentan alles über Nachschlagefelder eingerichtet. Eigentlich funktionieren diese sehr gut, aber es gibt ja genug Stellen im Internet (die ich nicht lesen konnte als ich dran saß), die einem genau davon abraten.
Also dachte ich mir, das ganze umzuschreiben. Einerseits, weil Nachschlagefelder offensichtlich Problembehaftet sind, andererseits, weil ich bei Abfragen als Kriterium einfacher angeben kann "=1" und somit alle Felder angezeigt werden, die Problemlos sind, bzw. mit <>1 alle Felder, die Problembehaftet sind.
Mit den Nachschlagefeldern habe ich eigentlich kein Problem: Die Inhalte der Felder tauchen als Text in meinem Bericht bzw. meiner Abfrage auf.
Wenn ich diese allerdings umstelle, erscheinen nun die Zahlen (was nicht verwunderlich ist). Wie komme ich nun aber von den Zahlen an die eigentlich Info?

Ich habe also eine Tabelle AEDL01, mit Sehvermögen, Sprachvermögen, Verständigung und Hörvermögen. Eine Tabelle tblSkala1, die die Werte in der Spalte Skala "ungestört", "mäßig", "schwer" und "Ausfall" besitzt.

Sehvermögen ist eine Zahl mit n:1 Beziehung zu SkalaID von tblSkala1.

Bei einer Abfrage funktioniert dies gut, so lange nur ein -vermögen der Tabelle AEDL01 in Beziehung steht. Wenn die Beziehungen Sehvermögen bis Hörvermögen alle mit der Tabelle tblSkala1 gesetzt sind, funktioniert das ganze nicht mehr, außer die Werte sind gleich (bspw. alle mäßig oder alle ungestört).
Die Beispiele finden sich in Abfrage 3 und 4.
Oder muss ich hier über n:m arbeiten, wie DF6Gl (Amateurfunker?) geschrieben hat?

Vielen Dank für eure Antworten und entschuldigt für die lange Postpause

Dirk

PS: Sorry mit der Datenbank, gesplittete zips nimmt das Forum leider nicht (beide .zip entfernen und dann dekomprimieren)

[MzKlMu]

Hallo,

Bei diesem Ansatz kann bspw. bei Patient x das Attribut Sehvermögen gleich mehrfach eingetragen werden,

dazu legt man einen zusammengesetzten eindeutigen Index an, dann ist das nicht mehr möglich.

während andere Attribute erst gar nicht erscheinen:

das ist eine Frage der Verknüpfungen in den Abfragen. Statt INNER JOIN ist da RIGHT JOIN oder LEFT JOIN zu verwenden.

Wenn ich diese allerdings umstelle, erscheinen nun die Zahlen (was nicht verwunderlich ist). Wie komme ich nun aber von den Zahlen an die eigentlich Info?

auch das ist sehr einfach, nämlich über eine Abfrage mit den relevanten Tabellen (und der Verknüpfung). Du hast dann alle Felder aus allen Tabellen zur Anzeige zur Verfügung und somit auch die eigentliche Info. Völlig problemlos.

[DF6GL]

Hallo,

neben meinen (DF6GL --> Funkamateur) vorher beschriebenen Maßnahmen führe folgende dringend aus:

1) Keine Sonder- und Leerzeichen in Namen verwenden !!!
2) Feld- (hier "ID") und Tabellennamen eindeutig und (auch alle anderen) sinnvoll benamsen ("ID"--> PatID,  in Tabelle "Patienten", und diese z. B. in "tblPatienten" umbenennen)
3)Das "Pflegeziel-Tabellengrab" ( und "Skala"-Tabellen) wegwerfen. Dafür  eine(!) Tabelle mit folgendem Aufbau:

tblPflegeziele

PZID (PK, Autowert)
PZ_Attribut (Text)
PZ_Wert (Text, evtl Memo)

PZID   PZ_Attribut         PZ_Wert
1         Sehvermögen     außerordentlich
2         Sehvermögen     miserabel
3         SehvermögenPZ  80% Sehschärfe
4         SehvermögenPZ  50% Sehschärfe
5         SehvermögenPZ  10% Sehschärfe
6         SehvermögenPZ  10% Sehschärfe
7         VerständigungPZ  Worterkennung
.
.
.

4) 1:1-Beziehungen treten auf, wenn Beziehungen über die Primärschlüsselfelder und nicht über PK zu FK hergestellt werden.

5) An die "eigentlichen Infos" kommst Du, indem eine verknüpfende Abfrage über die beteiligten Tabellen erstellt und ausgeführt wird. Dabei ist aber eine Abfrageergebnis-Ansicht NICHT für den normalem DB-Betrieb und den Anwender gedacht. (Und nochmal:  Nachschlagefelder haben in Tabellen nichts zu suchen).

[dille999]

Hallo,

ja, Sonderzeichen und Benennung ist richtig. Wie gesagt: Erstes Projekt.
Warum habe ich das Pflegeziel-Tabellengrab? Nun erstens gibt es zu jedem Attribut ganz verschiedene Pflegeziele: Das Pflegeziel "Trichter ins Ohr stecken" passt nur zum Hörvermögen aber nicht zum Sehvermögen. Darum habe ich eine Tabelle für jedes Pflegeziel angelegt. Momentan sind die noch leer, aber die Anwender können mittels Kombinationsfeld das richtige Feld auswählen und sollte es nicht vorhanden sein, einen neuen Datensatz in der jeweiligen Tabelle einfügen (nehmt einen Patienten, öffnet AEDL und jedes Kombifeld Pflegeziel hat den Eintrag " " (falls das Attribut Problemlos ist) und "Neuen Eintrag". Mit neuen Eintrag kann man dann ein neues Pflegeziel eingeben und dann auswählen. Das heißt mit der Zeit werden die einzelnen Pflegezieltabellen mit 10 bis 30 Einträgen wachsen.)

Nun zu deiner Tabelle:
Wie muss hierbei die Beziehung zu den anderen Tabellen aussehen?
Diese eine Tabelle benötigt doch auch dann mehrere Beziehungen.
In der Abfrage 3 funktioniert das. In der Abfrage 4, bei der meine Skalatabelle in Beziehung zu zwei Feldern steht nicht mehr. Warum?

Und zu deinem Punkt 5: Ja, ich habs verstanden: ich mache das ganze ja, um von den Abfragefeldern wegzukommen, wenns denn funktionieren würde...

Grüße

Dirk
PS: Ich würde dich ja anfunken, aber ich weiß schon gar nicht mehr wo meine Handquetsche ist und über 2m ohne große Antenne mit 5w an den Bodensee... ;o)

[DF6GL]

Hallo,

"Pflegeziel-Tabellengrab":  Ich weiß schon, was damit gemacht werden soll.  Genau das ist eben mit diesen "Grab" eher Unsinn.

"tblPlegeziele":  Dafür braucht es im Grunde gar keine Beziehungen (im Beziehungsfenster). Die Tabelle dient lediglich als Nachschlage-Tabelle.

Die Anzeige und Auswahl der einzelnen "PZ_Werte" geschieht über Kombifelder mit passendem SQL-Select-String.

(Select PZ_ID,PZ_Wert from tblPflegeziele where PZ_Attribut ="Sehvermögen" order by PZ_Wert     für das Feld "Sehvermögen" in der Tabelle. Für die anderen Felder entsprechend angepasst)

"wenns denn funktionieren würde..."  dann mußt Du halt beschreiben, was Du machst und was dabei nicht geht....