Tabellenfrage

[spearmint]

Sehr geehrte Damen und Herren!

Ich bin bei Access noch sehr unerfahren und muss eine Datenbank für ein Physiotherapie-zentrum erstellen. Ich beginne mal mit den Tabellen. Was würdet ihr hier noch ergänzen? Und was kann ich hier in Sachen Hilfstabellen einschieben, damit die Beziehungen passen?

Bis jetzt hab ich mir folgendes ausgedacht:

Mitarbeiter
Behandlung
Patient
Raum
Inventar

eventuell noch:

Lieferanten (für meine Ausstattung)
Rechnung
Rechnungsposition

Mit freundlichen Grüßen

Thomas

[Beaker s.a.]

Hallo Thomas,

Ich beginne mal mit den Tabellen. Was würdet ihr hier noch ergänzen? Und was kann ich hier in Sachen Hilfstabellen einschieben, damit die Beziehungen passen?

Schwer zu sagen, da Du nicht schreibst, was in den angegebenen Tabellen gespeichert werden soll.
Spontan:
Mitarbeiter und Patienten haben sicher mehrere Kontaktmöglichkeiten (Tel., Email usw.), also tblKontakte, evtl. eine Hilfs-/Nachschlage Tabelle mit den KontaktArten. Falls es auch mehrere Adressen geben kann, noch eine tblAdressen. Beide stehen dann jeweils in einer 1:n Beziehung zu Mitarbeiter/Patienten (Unterscheidung per Kennzeichen).
Behandlungen musst Du aus fachlicher Sicht auf weitere Entitäten betrachten, oder mal hier aufschreiben, was da rein soll.
Raum und Inventar würde ich als 1:n Beziehung sehen (in einem Raum können n Gegenstände sein).
Inventar und Lieferanten bräuchten wohl eine Zwischentabelle (n:m; ein Gegenstand kann mehrere Lieferanten haben, und ein Lieferant kann mehrere Gegenstände liefern).
Rechnungen und Positionen ist eine klassische 1:n Beziehung. Aber da könnte es auch noch Zusatztabellen wie Zahlungsbedingungen o.ä. erfordern. Und sicher eine Tabelle in der die zu berechneten Produkte/Dienstleistungen (Preise u.a.) gespeichert sind.
Für Weiteres wäre eine nähere Beschreibung Deines Vorhabens hilfreich.
hth
gruss ekkehard

[spearmint]

hallo!

fangen wir mal mit den 3 Tabellen an. Was soll ich da noch ergänzen, Wie soll ich die verknüpfen?

Ich kann mir das Szenario selbst zusammenstellen. Nehmen wir an ein Arzt hat mehrere Patienten. Und ein Arzt kann verschiedene Behandlungsmethoden durchführen. Ein Patient kann auch verschiedene Behandlungen erhalten.


Tabelle Patienten:
*SV_Nummer als Primärschlüssel
Vorname
Nachname
Geburtsdatum
Straße
Wohnort
PLZ
E-Mail
Telefonnummer

Tabelle Behandlung:
*BehandlungsID
Behandlungsmethode
Behandlunsdauer
Behandlungskosten (Studensatz)

Mitarbeiter:
*MitarbeiterID
Tätigkeit
Vorname
Nachname
Geburtsdatum
Straße
Wohnort
PLZ



mfg Thomas

[normalos]

So wird es ein Chaos. Wir haben einige Anwendungen erstellt und wissen, dass es ohne Planung nicht funktioniert. Zunächst muss eine Orgastruktur (Ablaufplan der einzelnen
Arbeitsschritte). Danach kann ein Datenflußplan erstellt werden, bzw. festgelegt werden wer wie auf welche Daten
zugreifen soll und wie wem welche Daten zur Verfügung stehen sollen bzw. welche Auswertungen wo benötigt werden.
Des weiteren muss noch festgelegt werden wie und wo die Daten gespeichert werden sollen. Wie diese Daten gesichert
werden und wie diese wieder, und das auf Dauer, wieder hergestellt werden können.
Auch wenn es aufwendig erscheint, erst den Plan dann der Aufbau. Zumal sich aus dem Ergebnis neue Erkenntnisse
ergeben die in Zukunft das Programm erweitern sollen. Diese Möglichkeiten müssen berücksichtigt werden.
Die Frage nach den Tabellen erübrigt sich, wenn die Struktur vorher durchdacht wurde. Evtl. mit Mitarbeiter abklären
wie die zukünftige Datenverarbeitung den Arbeitsablauf erleichtern kann.

[Beaker s.a.]

Hallo spearmint,

fangen wir mal mit den 3 Tabellen an. Was soll ich da noch ergänzen, Wie soll ich die verknüpfen?

Ich kann mir das Szenario selbst zusammenstellen. Nehmen wir an ein Arzt hat mehrere Patienten. Und ein Arzt kann verschiedene Behandlungsmethoden durchführen. Ein Patient kann auch verschiedene Behandlungen erhalten.

Eine Personen-Verwaltung könnte aussehen wie in anliegendem Beziehungsfester dargestellt. Benamsungen entsprechen nicht den hier des Öfteren zu recht verfochtenen Regeln. Welche Felder Du wirklich brauchst musst Du Deinen Planungsunterlagen entnehmen. 

Du bräuchtest noch eine tblBehandlungsmethoden, und Deine tblBehandlungen
müsste dann etwa so aussehen:
BehandlungsID (PK)
PatientenID (FK)
AerzteID (FK)
Behandlungsmethode (FK)
.
.

Bei Dauer und Kosten bin ich nicht sicher, ob die in diese Tabelle müssen/sollen/dürfen, oder ob die berechnet werden können, bzw. ob das Berechnungsgrundlagen sind.
Verknüpfungen ergeben sich aus den Schlüsselfeldern.
hth
gruss ekkehard

[Anhang gelöscht durch Administrator]

[DF6GL]

Hallo,

sind Personen,Patienten, Aerzte, Mitarbeiter  nicht irgendwie seltsam aufgebaut und miteinander verknüpft 

[Beaker s.a.]

Hallo Franz,

sind Personen,Patienten, Aerzte, Mitarbeiter  nicht irgendwie seltsam aufgebaut und miteinander verknüpft

Aufbau ist rudimentär; ich habe da auf die Schnelle meinen Aufbau (da geht's um Kunden, Lieferanten, Mitarbeiter + Vertreter) zusammen gestrichen (und dabei leider vergessen einige Feldnamen zu ändern/löschen), da der OP ja wohl andere Eigenschaften haben wird. Vor allem auch Felder mit weiteren Fremdschlüsseln zu Nachschlagetabellen wie Zahlungsbedingungen o.ä., die ich da auch weg gelassen habe.

Das Seltsame an den Verknüpfungen kommt wohl von der Grafik; da habe ich nicht gut aufgepasst, und die Verknüpfungslinien alle auf eine Höhe geschoben. Die vier Tabellen der oberen Reihe sind alle einzeln 1:1 an die Tabelle Personen (heisst im Original "Konten") gebunden.
Der Normalisierungs-Gedanke dahinter ist der, dass die einzelnen Personengruppen z.T. unterschiedliche Eigenschaften haben. Wenn ich die alle in eine Tabelle (Personen) packe, habe ich da z.T. Felder, die in fast allen DS leer sind. Z.B. Tabelle Vertreter Feld Provision wäre in allen anderen leer.
Ich lasse mich aber gerne belehren, was da besser zu machen geht.
Was für das Modell des OP noch wichtig wäre, und in meinem Vorschlag schändlicherweise fehlt, ist eine Zwischentabelle Patienten-Aerzte. Mit der könnte er dann in seiner tblBehandlungen sogar die Patienten- und AerzteID rausschmeissen und durch den PK aus der Zwischentabelle ersetzen; - glaube ich jedenfalls 

gruss
ekkehard

[DF6GL]

Hallo,

ich will niemand "belehren"   


"...z.T. Felder, die in fast allen DS leer sind..."


spielt doch keine Rolle...   Je nach "Typ" der Person könnten solche nicht verwendeten Felder (im Formular/Bericht ein/ausgeblendet werden.  Auch mit 1:1-Tabellen müssen alle Felder vorhanden sein (z. B. in einem Unterfomular oder auch als Abfrage über die betroffenen Tabellen in der Datenherkunft. Man steht immer vor der Entscheidung, welcher "Personentyp" gerade bearbeitet werden soll, so dass eine solche"Kennung" auf irgendeine Art und Weise immer nötig ist.


Im Fall einer Tabelle kann das mit Hilfe eines Tabellenfeldes geschehen, bei 1:1-Tabellen eigentlich nur durch programmatische Methoden.

[spearmint]

hallo!

Hab noch ne Frage zur Beziehung Inventar und Raum.

In einem Raum können mehrere Gegenstände sein. Ein spezieller Gegentand zb. Tisch mit der Nr 1 kann aber nur in einem Raum sein. Was ergibt dies dann später für eine Beziehung?

mfg Thomas

[DF6GL]

Hallo,

das kommt darauf an, wie und in welchem Umfang "Räume" verwaltet werden sollen.
Im Fall einer Tabelle ("tblRaeume") in der alle vorhandenen Räume als solche definiert werden, ergäbe sich ein n:1-Beziehung zwischen "tblGegenstaende" und "tblRaeume" über die Felder "GS_RaumID"  (FK in "tblGegenstaende") und "RaumID"  (PK in "tblRaeume").


Wenn die Räume als solches nicht weiter behandelt werden müssen/sollen, dann gibt es auch keine Tabelle "tblRaeume" und es reicht die Eingabe der Raumnummer in Feld "GS_RaumID", das aber jetzt sinnvollerweise "GS_RaumNr" heißen sollte.

[Beaker s.a.]

Hallo Franz,

ich will niemand "belehren"

Deshalb bin ich aber hier, um mich belehren zu lassen 

spielt doch keine Rolle...

Im Prinzip nicht, die Datenmenge bleibt die gleiche, aber

Je nach "Typ" der Person könnten solche nicht verwendeten Felder (im Formular/Bericht ein/ausgeblendet werden.

sieht das IMO nicht gerade gut aus. Die Anforderungen der einzelnen Personentypen sind doch zu unterschiedlich; Kunden haben z.B. keine direkte Verbindung zu Artikeln, nur indirekt über die Ausgangsbelege, Lieferanten dagegen sehr direkt. Kunden und Lieferanten sind auch unterschiedliche Belege zugeordnet (Ausgang/Eingang). Da ich auch sehr viel mit Registern arbeite, die ich dann auch noch ein- und ausblenden müsste, habe ich mir lieber für jeden Personentyp ein eigenes Form gebastelt.

Auch mit 1:1-Tabellen müssen alle Felder vorhanden sein (z. B. in einem Unterfomular oder auch als Abfrage über die betroffenen Tabellen in der Datenherkunft.

Schon klar, hab' ich ja auch. Für jeden Personentyp eine Abfrage über die tblPersonen und der entsprechenden :1 Tabelle; - die sind dann Datensatzherkunft der Forms.

Man steht immer vor der Entscheidung, welcher "Personentyp" gerade bearbeitet werden soll, so dass eine solche"Kennung" auf irgendeine Art und Weise immer nötig ist.
Im Fall einer Tabelle kann das mit Hilfe eines Tabellenfeldes geschehen, bei 1:1-Tabellen eigentlich nur durch programmatische Methoden.

Kennung ist ja in tblPersonen vorhanden, und die wird im Form per Standardwert gesetzt; - nix mit Code 

Für weitere Belehrungen immer offen.

gruss ekkehard

[DF6GL]

Hallo,

wieder ein bisschen OT, denke ich...


Wenn jemand das so umsetzen will, dann soll er das tun. Es führen in der Regel viele Wege nach Rom, Hautpsache, man strauchelt dabei nicht.   

Oft ist aber der 1:1-Weg steiniger als nur eine Tabelle zu verwenden.

[Beaker s.a.]

Hallo Franz,

Wenn jemand das so umsetzen will, dann soll er das tun.

Soll heissen, dass es nicht prinzipiell verkehrt ist ?

man strauchelt dabei nicht.   
Oft ist aber der 1:1-Weg steiniger als nur eine Tabelle zu verwenden.

Wo siehst Du da die Stolpersteine?
Bis jetzt musste ich mit dieser Struktur noch keine Klimmzüge machen.

gruss ekkehard

P.S. Wegen OT, wenn sich diese Diskussion in die Länge zieht, können wir dass auch gerne in einem neuen Thread fortsetzen, weiss aber nicht wie das geht.