ER-Modell

EnXan

Benutzer
Beiträge
6
Hallo,
ich habe aktuell die Aufgabe in meinem Informatikkurs in der Schule eine komplette Datenbank zu einem bestimmten Thema zu erstellen.
Hier die Informationen:

"Die Wohnungspreise steigen und es gibt immer mehr MieterInnen, die gegen ihre VermieterInnen gerichtlich vorgehen möchten. Der gemeinnützige Verein Wohnen für Alle von AnwältInnen für MieterInnenschutz ist stärker gefragt als je zuvor und möchte ein Datenbanksystem zur Verwaltung seiner MandantInnendaten aufgebaut bekommen. Dazu gehören neben den Stammdaten der MandantInnen auch die Erfassung der einzelnen Fälle, deren Termine und die Daten der MitarbeiterInnen welche die Fälle betreuen. Fälle können vor Gericht kommen, können aber auch außergerichtlich geregelt werden, wenn es zur Einigung zwischen MandantIn und ProzessgegnerIn kommt. Da es sich um einen gemeinnützigen Verein handelt, welcher auch von mittellosen Menschen genutzt werden kann, basiert die Finanzierung auf einem Bezahlsystem, welches sich am Einkommen orientiert. Je nach Einkommensklasse wird ein Beitragsbereich angegeben, innerhalb dessen der Beitrag frei zu wählen ist. Lediglich bei einer vorhandenen Rechtsschutzversicherung der MandantInnen wird der Höchstbetrag gefordert. Die Mandantendaten umfassen sensible personenbezogene Daten; insofern sind Anforderungen an den Datenschutz gestellt. Aus Gründen der Datensicherheit ist das System vor unbefugter Nutzung zu schützen."

Da ich nicht wirklich weiter komme, wollte ich hier nach Hilfe fragen. Ich habe schon einen Ansatz bin mir aber sehr unsicher, ob dieser richtig ist.
Ich hoffe ihr könnt mir weiterhelfen.
1638619236796.png
 
Werbung:
Das sieht doch relativ okay aus.
Wo kommst Du nicht weiter?

Bezahlt Mandant den Mitarbeiter oder vielleicht den Fall?
Was sind die Schlüssel in Deinem Modell?
Wie sehen die Beziehungsgrade (Kardinalitäten) aus?

Gibt es Lernstoff zum Thema "unbefugter Zugriff"? Ich würde sagen, das ist in einem Datenmodell nicht so ohne weiteres unterzubringen.
 
Du kannst das (mit modernen Datenbanken) noch weiter aufschlüsseln. In Deinem Fall könnte man z.B. für jeden Fall den Mandanten und den Mitarbeiter definieren und dann sagen: auf diesen Fall haben nur der passende Mandant und der bearbeitende Mitarbeiter Zugriff. Nennt sich RLS, was für Row Level Security steht. Davon ist in Deinem PDF keine Rede, aber wenn Du das noch mit einbaust kommst bestimmt ganz groß raus ...
 
Bezahlt Mandant den Mitarbeiter oder vielleicht den Fall?
Was sind die Schlüssel in Deinem Modell?
Wie sehen die Beziehungsgrade (Kardinalitäten) aus?
Ja, wenn man genauer drüber nachdenkt schon. Soll ich dann die Beziehung "geben auf" entfernen und durch bezahlen ersetzen?
Bei den Primär- und Fremdschlüsseln habe ich mir noch nicht wirklich Gedanken gemacht. Aber es sollte auf jeden Fall eine FallID und MandantenID geben. Bei den Mitarbeitern bin ich mir nicht sicher. Könnte man Mitarbeiter auch generell als Firma bezeichnen?
Mandanten - Fall: 1:1-Beziehung
Mandanten - Mitarbeiter(Firma): 1:n-Beziehung
Firma - Fall: Bin ich mir nicht sicher
 
Du kannst das (mit modernen Datenbanken) noch weiter aufschlüsseln. In Deinem Fall könnte man z.B. für jeden Fall den Mandanten und den Mitarbeiter definieren und dann sagen: auf diesen Fall haben nur der passende Mandant und der bearbeitende Mitarbeiter Zugriff. Nennt sich RLS, was für Row Level Security steht. Davon ist in Deinem PDF keine Rede, aber wenn Du das noch mit einbaust kommst bestimmt ganz groß raus ...
Und wie genau baue ich so etwas ein? Habe davon leider wirklich keine Ahnung.
 
Und wie genau baue ich so etwas ein? Habe davon leider wirklich keine Ahnung.
 
bezahlen statt geben auf scheint mir sinnvoll
Du würdest in dem Modell ja nicht die PK eintragen, sondern natürliche Schlüssel, sowas wie Name&Geburtsdatum usw.
Einen technischen PK machst Du am Ende sowieso.
Mitarbeiter sind Mitarbeiter, eine Firma wäre was eigenes, zu der Mitarbeiter gehören können
 
"unbefugter Zugriff": Laut Aufgaben ist Dein Datenmodell ja nur ein Schritt in der Entwicklung. Der Zugriffsschutz in der Anwendung ist etwas anderes als datenbankseitige Mechanismen:

Bei DB spricht man von "Grants", die Rechte festlegen zum Zugriff auf die Entitäten (und weiteres)
Man meldet sich in der DB an*, die Authentifizierung, als "Admin" oder als "Mitarbeiter", vielleicht sogar explizit mit eigenem Login. Damit erhält man definierte Zugriffsrechte. Die Grants bestimmen nun entsprechend der Anmeldung als User "admin" oder so, welche Rechte dieser hat (Autorisierung). Es geht also zunächst um, "Wer bin ich" und danach um "Was darf ich".

Eine Webanwendung, wie sie bei Euch am Ende offenbar erstellt werden soll, kann für dutzende oder hunderte "Mitarbeiter" nutzbar sein, die sich dort alle individuell anmelden wollen/müssen. Das wird meist über eine Tabelle eigens für die Anmeldung geregelt, evtl. ist das hier in der Aufgabe gemeint.

* Wenn ihr mit sqlite als DB arbeitet, ist allerdings eine solche typische Datenbank Anmeldung nicht möglich, also nicht vorhanden. Das muss dann die Webanwendung regeln.
 
Werbung:
In der Realität wird auch ein Fall nicht nur von einem Mitarbeiter betreut werden.
Die Einkommensklasse ist irgendwie zu dünn. Ich würde eine Tabelle dafür spendieren, die beliebig befüllt werden kann. Und gezahlt wird am Ende ein echter Betrag oder?
Wenn eine Webanwendung laufen soll, muss eine Anmeldung, also auch ein Passwort Mechanismus unterstützt werden. Dafür bräuchte man minimal ein Passwort Feld.
 
Zurück
Oben