Beziehung über mehrere Entitäten?

K

kolom

Benutzer
Beiträge
21
Guten Morgen,
ich probiere mich gerade ein wenig mit Access / SQL und dergleich aus und bin auf ein Problem gestoßen, bei dem ich hoffe, hier eine Antwort zu erhalten :)

Ich möchte mir die Kosten für die Betreuung eines Kindes anzeigen lassen. Diese Kosten sind von dem Betreuungsumfang und dem Bereich abhängig.
Den Betreuugsumfang kann ich direkt dem Kind zuordnen.
Das Kind wird jedoch zunächst in einer Gruppe betreut, welche wiederum einem Bereich zugeordnet ist. Die Beziehung von Kind zu Kosten ist also nicht unmittelbar.

Ist das möglich, so wie ich es mir gedacht habe? Access zeigt mir nur den join aus allen Möglichkeiten an. Zur Verdeutlichung noch einmal der Screenshot meiner Beziehungen. Wo liegt mein Fehler?

Vielen Dank für Rückmeldungen
 

Anhänge

  • Screenshot 2021-11-02 070214.png
    Screenshot 2021-11-02 070214.png
    39,6 KB · Aufrufe: 6
Werbung:
kolom schrieb:
Ist das möglich, so wie ich es mir gedacht habe? Access zeigt mir nur den join aus allen Möglichkeiten an.
Zum Vergrößern anklicken....

Das kann man schon so machen, man kann ja über mehrere Tabellen joinen. Mag sein, daß Access das nicht erkennt, nicht anzeigt und/oder allgemein das nicht kann. Zum SQL-lernen würde ich eh was anderes nehmen. Und zum anwenden natürlich auch.
 
Danke, also sind die Beziehungen an sich in Ordnung?

Hast du denn da Vorschläge? Ich möchte mich gerne an dem vollen Programm ausprobieren, von einem ER Diagramm über SQL Abfragen bis hin zu evtl Erstellung und Nutzung einer realen Datenbank mit mehreren NutzerRollen und entsprechenden Zugriffsberechtigungen.
 
kolom schrieb:
Danke, also sind die Beziehungen an sich in Ordnung?
Zum Vergrößern anklicken....

Grob drüber gesehen nix schlimmes gefunden. Ich kenne aber die konkreten fachlichen Anforderungen nicht, und auch nicht die angedachten Datentypen, Indexe, Constraints, ...

Hast du denn da Vorschläge? Ich möchte mich gerne an dem vollen Programm ausprobieren, von einem ER Diagramm über SQL Abfragen bis hin zu evtl Erstellung und Nutzung einer realen Datenbank mit mehreren NutzerRollen und entsprechenden Zugriffsberechtigungen.
Zum Vergrößern anklicken....

Nun - ich verwende PostgreSQL. Dazu gibt es auch Tools, die mit ER-Diagrammen umgehen können. Es sollte definitiv all Deine Wünsche abbilden - und noch viel mehr.
 
Alles klar danke - hatte Access gewählt weil es so einfach in der Handhabung wirkte und ich mich nicht mehr allzusehr in das Programm ein arbeiten musste :) Dann schaue ich mir das PostgreSQL mal an.

Eine Frage habe ich noch zu einer weiteren Beziehung (noch in Access dargestellt :) )

Ich möchte gerne die Beziehung Kind und Elternteil darstellen und möglichst alle Varianten ermöglichen.

Kind hat mindestens 1, maximal 2 Elternteile.
Ein Elternteil hat ein Kind, kann aber auch mehrere Kinder haben.

Wenn 2 Elternteile 1 Kind haben, kann eines der Elternteile möglicherweise ein anderes Kind haben, dass das jeweils andere Elternteil nicht hat.

Ist das so verständlich? :) Die ElternID 2x bei Kind hinzuzufügen (1:n) hat nicht ganz zu dem erhofften Ergebnis geführt, da es immer verlangt, dass beide Elternteile eingetragen werden. KindID bei Elternteil hinzuzufügen (1:n) ist auch nicht der richtige Weg, da ich dann nicht einem Elternteil mehrere Kinder zuordnen kann. Habe es nun mit einer n:m Beziehung versucht (hoffe ich dass man die so darstellt :) ), aber das klappt auch nicht so ganz wie ich mir das vorstelle.. Hat da noch jemand Tipps?
 

Anhänge

  • Screenshot 2021-11-03 073318.png
    Screenshot 2021-11-03 073318.png
    24,4 KB · Aufrufe: 2
Zuletzt bearbeitet:
das sollte dem nahe kommen:

Code: 
edb=# create table kinder(id int generated always as identity primary key, name text);
CREATE TABLE
edb=*# create table eltern(it int generated always as identity primary key, name text);
CREATE TABLE
edb=*# create table familie(id int generated always as identity primary key, name text, eltern1 int references eltern unique, eltern2 int references eltern unique, check(coalesce(eltern1,eltern2) is not null));
CREATE TABLE
edb=*# create table eltern_kind(id int generated always as identity primary key, eltern int references eltern, kind int references kinder);
CREATE TABLE
edb=*#

tabelle familie definiert, daß eine Familie aus mind. 1, max. aus 2 Elternteilen besteht (check-constraint). Jedes Elternteil darf in dieser Tabelle nur 1 mal vorkommen (unique constraint). Tabelle eltern_kind bring jede Eltern dann mit beliebig vielen Kindern zusammen.

Ich hoffe, ich hab nichts übersehen...
 
Ich habe mich nun nochmal ein wenig an mein ER Modell gesetzt, bevor ich mich konkret dran mache, die Tabellen und dann hoffentlich mal ein paar SQL Abfragen zu erstellen. Mag da mal jemand drüber schauen, ob alles Sinn ergibt? Da wäre ich sehr dankbar :)
Unsicher bin ich mir noch bei folgenden Punkten:
  • Die Eltern - Kind Beziehung habe ich in dem Fall einfach zu einer n:m Beziehung gewählt. Damit sollten doch eigtl erstmal alle Patchwork Möglichkeiten abgebildet werden?
  • Die Betreuungskosten errechnen sich aus dem Betreuungsumfang und dem Bereich in dem ein Kind betreut wird. Dafür hat jeder Bereich (Ü3, KiGa, Hort) eine Entität und bildet gemeinsam mit Kind und Betreuung jeweils ein "Entitäten Dreieck". Kann man das so erstmal abbilden? Für die beiden Relationen die von der Entität "Betreuung" abgehen ist mir noch kein Name eingefallen - braucht jede Relation einen Namen?
  • In der Kita arbeiten mehrere Mitarbeiter, ein Mitarbeiter leitet die Kita. Daher habe ich 2 Relationen die die Entitäten Kindertagesstätte und Mitarbeiter verbindet. Kann das so gemacht werden? Bzw. kann ich im Falle eines Leitungsduos (stellv. Leitung) die Relation "leitet" auch zu einer 1:n Beziehung machen?
Das waren erstmal so meine Fragen dazu - ich hoffe es ist verständlich und ihr könnt mir weiterhelfen :) Vielen Dank schon einmal.
 

Anhänge

Also ich habe mal einen Blick rein geworfen, auf Anhieb verstehe ich Deine Notation nicht.
Beispiel: KiGa Gruppe
Name 1:1
Max.Anzahl 1:n
Was soll mir das sagen?

Jede Gruppe hat einen Namen, ok, das wäre m.E. ein Attribut der Entität "KiGa Gruppe", keine 1:1 Relation. Oder willst Du den Namen in einer separaten Tabelle führen?! Wahrscheinlich nicht.
Dann MaxAnzahl, die nun 1:n, eine Gruppe hat verschiedene Maximale Anzahlen von Kindern (in einer separaten Tabelle)? Seltsam.

Dann nur mal weiter zum "Hort", das gleiche in Grün. Mir sind nun die Unterschiede zwischen Hort und KigaGruppe weder in der Realität noch in dem Modell wirklich klar. Deswegen liege ich mit der Anmerkung vielleicht falsch. Doch reicht es nicht, (Kiga)Gruppe mit einem Attribut zu versehen, welche Ausprägung diese Gruppe hat (Was dann im Programm zu unterschiedlicher Behandlung, Darstellung, ..) führt?

Generelle Anmerkungen:
Ich finde es gut, wenn Du Dich mit diesen Dingen genau auseinander setzt. Es besteht aber die Gefahr, sich zu verzetteln. Statt einen großen Wurf zu modellieren, fange mit einem kleinen Modell an und ziehe klare Grenzen, nicht jeden Aspekt der Wirklichkeit, kann, muss, soll man abbilden. Orientiere Dich z.B. an der wichtigsten Funktion, die Du umsetzen willst. Was ist minimal zur Bearbeitung an Infos, Parametern, Attributen notwendig?
Was die Beschreibung / Erklärung der Modellierung angeht, ist es zumindest hier eher ratsam, einfach die betroffenen Tabellendefinitionen zu posten. Also Create Statements.
Wenn man den Schritt von einem logischen zu einem physischen Modell macht, sollte man trotz der nicht ganz neuen Erfindung von Unicode und entsprechenden Objektnamen lieber im Bereich der ANSI Buchstaben ohne Umlaute, Leerzeichen und anderen Firlefanz bleiben. Es erspart viel Rauschen und ärgerliche Fehler. U.a. ist damit garantiert die nervige Klammernotation in Access Feld Bezeichnern obsolet.
Dann sei die Frage gestattet, warum es Access werden soll. Ein nicht kostenloses, proprietäres System, dessen Funktionen man auch weitgehend kostenlos haben kann.

P.S: "Entitäten Dreiecke" sagt mir nichts. Wenn ich auf solch ein Diagramm schaue und die gleichen Begriffe tauchen immer wieder auf, stimmt etwas nicht.
Doppelleitung: An solchen Stellen wie gesagt auf Kosten/Nutzen eines aufwändigen Modells achten. Vielleicht tuts auch ein flexibles JSON Feld, wo selten gebrauchte "Restinformationen" rein kommen. JSON ist geduldig, mindestens bis zum nächsten Release.
 
Zuletzt bearbeitet:
Erst einmal vielen Dank für deine Mühe. Ich habe es befürchtet dass das ganze noch nicht so korrekt wirkt - in der Theorie wirkt alles immer so plausibel, das selber mal zu machen klappt dann noch nicht so ganz..

Bezogen auf dein Beispiel:
Die Kindertagesstätte besteht aus mehreren Gruppen (im U3- Bereich, im KiGa- Bereich, im Hort- Bereich; je nach Alter sind die Kinder un den unterschiedlichen Bereichen betreut). Jede Gruppe hat einen Namen und eine maximale Anzahl an zu betreuuenden Kindern. Aber du hast recht, da stimmt etwas nicht in der Notation. Vermutlich ist es umgekehrt sinnvoller (die "blaue Gruppe" kann in mehreren Kitas vorkommen, aber eine KiGa Gruppe hat immer eine max Anzahl an zu betreuuenden Kindern von 25 Kinder).

Ursprünglich hatte ich auch lediglich die Entität Gruppe mit Attributen U3, KiGa und Hort. Hatte dann aber Probleme die Betreuungskosten sinnvoll darzustellen. Die Kosten sind abhängig von dem Bereich (U3, KiGa oder Hort) sowie dem Betreuungsumfang (wie lange ist das Kind täglich in Betreuung). Dadurch hatte ich mir erhofft die Kosten einfacher darzustellen.


Danke auch für die Anmerkungen. Ich habe hier versucht mir ein Projekt vorzustellen und das nun mit Literatur von Beginn an zu lösen :) Vllt denke ich da aktuell tatsächlich ein wenig zu groß.. Access habe ich aus dem bequemen Grund gewählt, da es in meiner Office Lizenz auf der Arbeit inbegriffen ist und ich es angenehm fand, das ganze mal lokal zu testen. Zum Ausprobieren habe ich es als hilfreich empfunden, einfache SQL Abfragen erstmal bildhaft zu erstellen, in dem ich einzelne Werte so hinzufüge und dann nachschauen zu können, welchen SQL Befehl Access daraus erstellt um dann damit herumzuspielen. Muss aber auch gestehen, dass ich mich noch wenig mit alternativen Programmen auseinander gesetzt. Ich bin nicht an Access gebunden, es war einfach die erste und bequemste Wahl :)
 
kolom schrieb:
es war einfach die erste und bequemste Wahl
Zum Vergrößern anklicken....
Das ist ja der Trick.

Es reicht eine kostenlose DB wie Postgres oder sogar das Internet für den Anfang:
Postgres 14 | db<>fiddle

Ich habe hier mal die Beziehung zwischen Kita und Kostenstelle / Bereich angelegt und dabei verschiedene Techniken eingesetzt, die nicht unbedingt so gemacht werden müssen, z.B. Feldbenennung, ID Erzeugung, ..
Das ist nur ein Ausschnitt Deiner Idee, 2 Tabellen, eine Beziehung, paar Attribute.

Als Beispiel habe ich auch einen View angelegt.
 
Auch wenn ich wirklich kein Access Fan bin, Du kannst wahrscheinlich alle Schritte aus dem DBFIDDLE Link auch in Access starten.
An einigen Stellen müsstest Du sicher die Syntax etwas umbauen. An anderen Stellen (z.B. Sequence) andere Verfahren also konkret einen anderen Feldtyp für Autoincrement wählen, aber es sollte gehen. Vielleicht kommst Du so besser rein.

Zu Deinem Modell noch:
Ich würde vielleicht nur ein reines Entity Relationship Modell machen, das wie der Name sagt, Entitäten (Tabellen) und Beziehungen darstellt, ganz ohne Attribute. Oder aber mindestens die Attribute in Deinem Modell innerhalb der Entity aufführen und ohne die Relationsangaben, die m.E. dort keinen Sinn machen.
Wenn es Dir wichtig ist, so eine formale Darstellung (Bauplan) zu haben, dann such Dir vielleicht noch ein Tutorial und ein geeignetes Tool raus.
Ich vermute, ein modernes Access kann aus bestehenden Tabellen auch ein Modell Diagramm anlegen oder mehr. Es gibt natürlich auch andere Werkzeuge, die das können und zwar unabhängig von der verweneten DB und auch kostenlos.
Am Ende tut es auch ein Blatt Kästchenpapier und ein Bleistift oder ein Spreadsheet Programm für die reinen Datenangaben. Daraus könnte man auch rohe Skripte generieren.
 
Danke für die Hinweise. Access hatte ich lediglich aus Bequemlichkeit genutzt, ich bin nicht daran gebunden. Es lag für mich nahe, da in der graphischen Oberfläche die Tabellen einfach zu erstellen und zu füllen waren und ich mir da dachte, dann spare ich mir die Befehle dafür auch noch zu lernen :) Setze mich gerade ein wenig mit PostgreSQL in Verbindung mit pgAdmin auseinander.

Ich hätte das ER-Modell schon ganz gerne fertig gebaut, da ich es immer wieder hinzuziehe und mir beim DB aufbauen in Verbindung mit dem ERD immer wieder ein paar neue Sachen klar werden.. bei der Recherche bin ich auf verschiedene Schreibweisen des ERM gestoßen und habe mich, ohne wirkliche Gründe für diese Form (nach Chen) entschieden. Meinst du, eine andere Darstellung wäre sinnvoller?
 
Werbung:
Ich habe mich bei Deinem Diagramm hauptsächlich an den Relationsangaben zwischen Entität und Attribut gestört.
Vielleicht ist das nach Chen, aber vielleicht auch eher nicht.
Ich arbeite schon länger nicht mehr mit sowas, aber wenn es Dir wichtig ist, nimm ein Tool, das das Ganze etwas "begleitet", also kein reines Malprogramm, mit dem man beliebige Sachen malen kann.
kolom schrieb:
dann spare ich mir die Befehle dafür auch noch zu lernen
Zum Vergrößern anklicken....
Vielleicht sparst Du da an der falschen Stelle, aber das musst Du selbst entscheiden. Ich eigene mir lieber Grundlagen im Sinne von Standard an, als die "bequeme" Bedienung irgendeines Tools.
Vielleicht hat hier jemand einen Tipp für ein nrauchbares (und freies) ER Tool, ich kenne aus dem Ärmel keines.
Postgres ist jedenfalls sehr mächtig und vielseitig. Formulare oder Clientprogramme (GUI) musst Du dann anders erstellen. (Wenn ein normales SQL Tool nicht reicht). Programmieren kannst Du in Postgres auch, die Verarbeitungslogik.
 
Zurück
Oben