Office: (Office 2013) Kleine Datenbank für eine Rechtevergabe

Hallo Zusammen,

ich suche Hilfe für mein kleines Access-Projekt. Ich habe hier ein Geoinformationssystem welches zur Zeit ca. 130 Fachanwendungen hat. Diese 130 Fachanwendungen besitzen in der Regel je einen graphischen Teil, eine Datenbank und Dateien wie Fotos oder Dokumente. Außerdem habe ich ca. 500 Anwender die die unterschiedlichsten Rechte in den Fachanwendungen besitzen. Um den Überblick wieder zurück zu gewinnen, möchte ich die gebastelte Excel-Matrix fallen lassen und mir mit Hilfe von Access eine Rechtedatenbank aufbauen. Soweit so gut.

Nun habe ich mir eine "Haupttabelle" erzeugt namens Rechte. Diese referenziert auf eine Tabelle mit allen Anwendern und auf eine Tabelle mit allen Fachanwendungen. Soll bedeuten:

ID | Ref über ID auf Tab "Anwender" | Ref über ID auf Tab "Fachanwendungen" | Dateirecht | Datenbankrecht | Geometrierecht |
Also habe ich 6 Spalten.

Das funktioniert auch (teilweise). Ich habe mir dazu schon mal eine Abfrage und ein Formular gebaut. Sieht schon ganz nett aus.

Jetzt habe zwei Probleme. Ich fange erstmal mit dem einen Problem an. Ich stehe im Formular was mir die Fachanwendung und ein Unterformular welches die eingetragenen Anwender mit ihren Rechten anzeigt. Super.
Möchte ich aber in diesem UnterFormular einen weiteren Anwender hinzufügen und ihm die Rechte eintragen so kommt eine Fehlermeldung: "Feld konnte nicht aktualisiert werden". Die Hilfe dazu ist nicht hilfreich. Ich bin der Einzige der darauf zugreift und das Feld kann man eigentlich beschreiben. Evtl ist die Referenzierung schuld.

Zweites Problem (Wenn Ersteres dann gelöst ist): Wie kann man einen Filter über die Datensätze jagen.
Fallbeispiel:
Ich muss in der Fachanwendung "Kataster" einem Anwender das Leserecht erteilen.
Mein vorgestellter Arbeitsablauf:
Ich öffne Access und dort das Formular Rechtevergabe:
Da gibts ein Eingabefeld wo ich nach einer Fachanwendung suchen kann. Es würde sogar schon reichen, wenn man damit die 130 Datensätze einfach reduzieren kann. Sprich ich gebe "Kataster" ein und es werden 125 Datensätze ausgeblendet weil ich nur 5 Fachanwendungen mit Kataster in der Bezeichnung habe. So muss ich halt maximal 5 Formular-Seiten durchblättern.

Habe ich dann also meine Fachanwendung "Kataster" gefunden, so muss ich im Unterformular den besagten Kollegen eintragen. Jetzt habe ich hier eigentlich genau das selbe Problem. Bei 500 Anwendern wie finde ich in dem Unterformular den richtigen Anwender? Also eine Auswahl-Combobox mit 500 Einträgen scheidet wohl aus. :-) Wie macht ihr das?

Viele Grüße
JumpinJack

PS: Hab die DB mal angehangen...

:)

 

Bevor ich zum eigentlichen Problem/zur eigentlichen Frage kommen, muss ich leider erstmal an den Grundlagen ansetzen...
Das Feld Name in der Tabelle Anwender ist
a) ungünstig, da Name ein von Access reserviertes, da intern verwendetes Wort ist
b) überflüssig/unnütz weil es die identische Information aus Vorname und Nachname verbindet und somit redundant vorhält (Verstoß gegen die 1. Normalform)

Die Rechtetabelle scheint mir besser als sog. m:n-Tabelle aufgebaut zu werden.
Sprich es gibt eine Tabelle welche alle möglichen Rechtearten als Datensätze enthält und die bereits vorhandene Tabelle der Anwender.
In einer weiteren Tabelle wird dann abgebildet welcher Anwender (n) hat welche Rechteart (m) und welches Recht (lesen, schreiben, etc.) darin.
Vorteil: Du kannst jederzeit weitere Rechtearten hinzufügen; das ist in Deiner Konstellation nur schwer möglich, da Du am Datenmodell Veränderungen vornehmen musst.

Die Relation ziwschen Fachdaten und Rechtetabelle erschließt sich mir nicht; bitte erklären.

Grundsätzlich solltest Du auf Sonderzeichen und Umlaute in Bezeichnungen von Tabellen und Feldern verzichten; das spart später Ärger und erleichtert z.B. die Lesbarkeit von SQL-Anweisungen da auf eckige Klammern verzichtet werden kann.


Zu den eigentlichen Fragen:
Das Unterformular lässt sich nicht editieren, da die Datenherkunft das nicht zulässt.
Binde das Formular an die Tabelle Rechtetabelle. Für das Namensfeld würde ich ein Kombinationsfeld verwenden, welches Dir die erfassten Anwender anzeigt und zur Auswahl anbietet.
Wenn Du das Datenmodell wie oben beschrieben anpasst, kannst Du das auch für die Rechte als Kombinationsfeld anbieten.

Das gewünschte Verhalten bzgl. der Auswahl von Daten kannst Du durch entsprechende Filter erwirken.


Bevor Du Dich jetzt aber auf die Umsetzung deiner 2 gestellten Fragen stürzt, solltest Du Dich zuerst mit dem Datenmodell und der Basis der Anwendung auseinander setzen... da ist IMHO noch etwas zu tun.

 

Hallo CptChaos,

ok, erstmal vielen Dank für die Antwort.

Der Hinweis a) und b) werde ich ändern und wie von dir empfohlen umsetzen.

Was die n:m-Tabelle betrifft. Darüber habe ich tatsächlich auch nachgedacht. Ich hab es aber verworfen, da ich mir sicher bin, nicht jedes Recht abbilden zu können. Wenn ich dies tun würde, dann verliere ich die Übersicht und verzettle mich zu sehr in Feinheiten die meines Erachtens unnötig sind. Viel mehr würde ich hier die Rechte in: schreibrecht/leserecht/speziell/kein Recht unterscheiden. Und bei "Speziell" würde ich in ein Memofeld entsprechende Infos wie " Nur Schreibrecht Ebene "Flurstücke" " hinterlassen. Dennoch schadet es wahrscheinlich nicht, deinen Vorschlag umzusetzen. Ich muss ja nicht die Rechtetabelle erweitern wenn ich auf n:m umsattle.

Umlaute und Sonderzeichen werde ich auch entfernen.

Was die Relation der Rechtetabelle mit der Fachdatentabelle betrifft:
Letzten Endes ist die Fachdatentabelle nur eine Liste. Wenn ich einen neuen Rechte-Datensatz anlegen möchte, so will ich aus einer vorhandenen Liste den entsprechenden Fachdateneintrag wählen. Im Prinzip genauso wie bei meinem Anwender. Da suche ich auch nach einem existierenden Anwender.

Also so:
Neuer Datensatz in der Tabelle Rechte anlegen:
Dateirecht: Lesen
DB-Recht: schreiben
Geometrierecht: kein Recht
Fachanwendung: Auswahl aus der Tabelle "Fachanwendungen"
Anwender: Auswahl aus der Tabelle "Anwender"

Deine Antwort zu meinen Fragen muss ich mir erst nach den Änderungen rein ziehen. Danke für deine Hilfe bis hierhin.

Viele Grüße

 

Davon kann ich nur ausdrücklich abraten, das wird früher oder später (eher früher!) zu Problemen führen...

Ich bin noch nicht ganz durch das System gestiegen, was hier abgebildet werden soll; ich bin allerdings auch kein Spezialist, was Geoinformationsdaten angeht. Evtl. kannst Du die angesprochene Excelmatrix zeigen damit ich mir mehr darunter vorstellen kann.

Ich habe eine Benutzerverwaltung welche auf einem Rollenmodel basiert in meinen Anwendungen im Einsatz.
Dort werden zu den Usern mehrere Rollen verwaltet welche deren Berechtigungen darstellen. In einer Anwendung habe ich dieses Model noch um eine Zuordnung zu Geschäftsbereichen erweitert.

Evtl. lässt sich das für Deine Bedürfnisse adaptieren.

 

Verdammt. :-)

Solche Aussagen sind immer schlecht. Und wenn ich die in der Vergangenheit ignoriert habe, so habe ich es später meistens bereut. :-D

Mein Problem ist halt folgendes, warum ich nicht alle Rechte aufdrösseln möchte.

Wenn du eine Fachanwendung von zur Zeit 130 raus nimmst, so kann man diese in 3 Grundrechte einteilen, nämlich Dateirecht, DB-Recht, Geometrierecht.
Jetzt geht das weiter. Jede Datei oder jedes Verzeichnis für die Fachanwendung wird meines erachtens nicht seperat beschränkt. Das wäre unsinnig und mein persönlicher Super-GAU. Dennoch: Wenn man 100 Dateien als Recht in der Tabelle für diese Fachanwendung seperat festhalten wollte, so hat man 100 neue Spalten, nur für diese Fachanwendung. Das ganze mal 130 Fachanwendungen und die Spaltenzahl ist unüberschaubar geworden. 13000

Jetzt haben wir aber noch nicht die Geometrie. Da kann man ganz gerne mal auf 50 Ebenen zeichnen. Ich hab aber auch eine Fachanwendung mit 250. Wir gehen jetzt von 50 Ebenen aus. Mal 130. 6500 + 13000

Und dann die Datenbanken die dahinter stecken. Pro Fachanwendung nehmen wir durchschnittlich 4 Tabellen mit 15 Spalten welches jede eine seperate Berechtigung erhalten soll. Macht 60*130 Anwendungen. 7800 + 6500 + 13000

Du siehst, dass ist ein Wahnsinn. In der Regel haben die Anwender Lese/Schreib oder kein Recht. Ich glaube ich habe 2 oder 3 Sonderfälle in den 130 Fachanwendungen wo dies nicht zutrifft.

Aber wenn ich jetzt auf dich höre, wie kann ich denn recht einfach Massenoperationen machen? Also alle Anweder sollen auf die Fachanwendung 1,3,5,6,7 und 99 Leserechte bekommen. Ich will das ja dann nicht 1000fach anlegen.

Aber die Idee mit der Rolle ist nicht schlecht. Da bin ich noch gar nicht drauf gekommen. Alle Admins wünschen sich für das GIS ein rollenbasiertes Rechtemanagment. (ist leider nicht vorhanden) Aber die Dokumentation mit Hilfe von Rollen zu machen, wäre auch eine Möglichkeit. Ich muss da jetzt mal in mich gehen, und überlegen wie man das in Access abbilden kann.

Danke dir.

 

Nochmal: Ich habe von der fachlichen Seite Deiner Anwendung absolut keine Ahnung... das sind die bekannten böhmischen Dörfer für mich *wink.gif*

Ich habe den Eindruck, Du denkst noch zu sehr in Excelweise... Spalten gibt es in Access nicht; das sind Felder.
Und die angesprochenen Beispiele (ich nehme jetzt nur eines) müssen als Datensätze abgebildet werden.
Aus den 100 Spalten zu den 130 Fachanwendungen werden 100 Datensätze (Zeilen) in einer m:n Tabelle. Und wenn morgen die 101 Datei dazu kommt, ist es eben eine Zeile mehr...


Kannst Du mir evtl. bitte losgelöst von dem bisher beschriebenem Modell fachlich erklären, was hier aus der Realität abgebildet werden soll/muß?

 

Ja du magst recht haben. Ich denke zu Excel-Lastig. hmmm....
Ich überlege mal wie ich das besser erklären und beschreiben kann. Muss aber jetzt weg. Das mach ich entweder heute nachmittag oder auf jeden Fall morgen.

 

Hallo CptChaos,

also ich habe mir jetzt mal ein paar weitere Gedanken gemacht und das ganze Datenbank-Design umgestellt. Das Problem ist meist nur, dass man als Laie sich ganz tolle Gedanken machen kann, und dann kommt der Profi und sagt einem das das alles Käse ist. :-D Also wollte ich dir und wenn noch ein anderer sich beteiligen mag, gerne das neue "Design" erklären.

Ich habe jetzt 5 Tabellen + 4 n:m-Tabellen:
Tabelle "Anwender":
Hier soll nur der Vorname, Nachname und das Team festgehalten werden. Das Team soll über eine N:M-Tabelle mit der "Team"-Tabelle festgehalten werden. Warum: Es könnte ja sein, dass der Anwender in mehreren Teams ist.

Tabelle "Team"
Dient nur zur Auflistung der vorhandenen Teams. Hier wird nur der Teamname festgehalten

Tabelle "Fachanwendung"
Dient nur zur Auflistung der möglichen Fachanwendungen. Zusätzlich wird auf die Tabelle "Team" über n:m-tabelle verwiesen, um die Fachanwendung einem zuständigen Team zuzuweisen.

Tabelle "Rechte"
diese Tabelle wird mit der Fachanwendung verbunden, damit man auswählen kann, zu welcher Fachanwendung man gerade ein Recht erstellt. Sonst wird Rechtebeschreibung wie (Ebene X) und Rechteart (lese und schreibrecht) festgehalten. Zusätzlich wird die Rechtetabelle über eine N:M-Tabelle an eine Rolle oder einen Benutzer gebunden. (Kann man das überhaupt machen?)

Jetzt wo ich das schreibe würde ich fast noch eine weitere Struktur einbauen.
Kann ich nicht auch einem Team eine Rolle zuweisen? Somit könnte ich allen aus einem Team recht schnell irgendwelche Rechte erteilen. Ich hab das jetzt kurzerhand eingebaut. Siehe Grafik.

Steigst du dadurch? Die N:M-Tabelle "Rechte-Verteilung" ist sehr speziell. Weil man einmal auf das Recht per Rolle als auch per Anwender verweisen kann.
Außerdem habe ich ein wenig Angst das ich mich zu sehr verschachtel und damit meine Übersicht flöten geht. Ich möchte später in der Lage sein, entweder alle Rechte der Anwender auf eine bestimmte Anwendung zusehen oder welche Rechte ein bestimmter Anwender auf alle Anwendungen hat.
Das ist ja keine einfache Abfrage mehr. Denn der Anwender könnte in einer Rolle zugeordnet sein und das Recht erhalten. Er könnte aber auch direkt das Recht zugewiesen bekommen. Und er könnte in einem Team stecken, welches eine Rolle zugewiesen bekommen hat und somit das Recht erhalten. 3 Wege. omg.

Ich glaube ich stoppe hier mal und lasse dich/euch mal antworten.

btw: Im Anhang ist mal ein Mini-Auszug aus der Matrix und mein DB-Design graphisch mit Excel gemacht. *Smilie

 

Auf meine eigentliche Frage "Kannst Du mir evtl. bitte losgelöst von dem bisher beschriebenem Modell fachlich erklären, was hier aus der Realität abgebildet werden soll/muß?" hast Du leider nach wie vor nicht geantwortet... *frown.gif*
Sorry, aber ohne das kann ich dem ganzen nicht folgen (trotz mehrmaligem Lesen fehlt mir hierfür die Vorstellungskraft)

 

Ich glaube ich verstehe die Frage nicht. Es soll abgebildet werden, wer (Anwender) welche Zugriffsrechte (schreib/lese) auf welche Daten (Fachanwendung) hat.

 

Na, damit kann ich was anfangen... so deutlich kam das in der bisherigen Beschreibung nicht raus *wink.gif*

Das Grundgerüst sollte mit 4 Tabellen abgebildet werden können.

tblAnwender
- AnwenderID (Primärschlüssel)
- Anwenderdaten (Name, etc. in einzelnen, normalisierten Feldern)

tblFachanwendungen
- FachanwendungID (Primärschlüssel)
- Anwendungsdaten (Bezeichnung, etc. in einzelnen, normalisierten Feldern)

tblRechte
- RechtID (Primärschlüssel)
- Titel (Schreiben, Lesen, etc.)
- Beschreibung

tblAnwenderRechtAufFachanwendung
- fk_AnwenderID
- fk_Fachanwendung
- fk_Recht

Ein Team hat für mich nichts mit den Rechten zu tun sondern bildet eine Gruppierung/Zusammenfassung von Anwendern.

Wenn Du anstelle oder zusätzlich von Einzelrechten auch noch Gruppenrechte im Sinne von Benutzergruppen haben möchtest, wird das ganze schwieriger bzw. muss noch erweitert werden um die Möglichkeit
a) Anwender in Gruppen zusammen zu fassen
b) Gruppen auf Fachanwendungen zu berechtigen

 

Also das hört sich ja schon gut an. So wie du es schreibst, seh ich das ähnlich.

Nun hab ich zwei oder drei Erweiterungen.

Ich würde ein Rollenkonzept mit einführen. Das soll bedeuten, ich gebe einer Rolle mehrere Rechte. Wenn ich dann einem Anwender die Rolle zuweise, dann erhält der die Rechte der Rolle. Das soll das Rechtemanagment vereinfachen.

Einfaches Beispiel: "Jedermann-Rolle"
Jeder Anwender der diese Rolle überbekommt, erhält Leserechte auf alle allgemeine Fachanwendungen. Warum so? Wenn ich einer Rolle 20 Leserechte erteile und 200 Anwendern diese Rolle überstülpe, dann habe ich 220 Zuweisungen in der Datenbank gemacht.

Würde ich das ohne Rolle machen, dann muss ich 200 Anwendern jeweils 20 Rechte vergeben. Das wären dann 200*20 Zuweisungen in der DB. Verstehst du was ich meine? Rolle wäre hier effektiver.

Zusätzlich würde ich das dann noch Erweitern auf Teams. Ich könnte mir das so vorstellen:

Team "Gesamte Firma" ( hier stecken alle Kollegen drin )
Dieses Team bekommt die Rolle "Jedermann-Rolle" über. Somit hätte ich mit einer Zuweisung allen Kollegen in der Datenbank das Recht eingeräumt bzw dokumentiert.
Natürlich muss man die selben Kollegen auch noch zusätzlich in andere Kleinere Teams stecken. Zum Beispiel "Team Planung Weihnachten". Oder "Team Kuchen backen". Das "Team Kuchen backen" bekommt das Recht alle Rezepte zu lesen und zu verändern. Usw usf.

Weißt du was ich meine? So war das mit meinem Bild oben gemeint. Geh ich damit zu weit, Rollen und Teams zur vereinfachten Dokumentation von Rechten einzuführen?
Klar muss natürlich sein, dass man später die Rechte auflöst. Ich mag dann wirklich sehen wer welche Rechte hat. Nicht das Access später sagt: Anwender steckt in Team "A" und hat Rolle "B" und "C". Das ist zwar informativ, aber wichtiger sind dann eher die Infos:
Anwender hat das Recht 1,2 und 3 vom Team "A" geerbt, das Recht 5,6 von Rolle "B" und 7,8,9 und 10 von Rolle "C" geerbt.

Weißt du was ich sagen will? *Smilie)

 

Wenn ich dich richtig verstehe, gibt es dann aber nur noch Rechte über eine Rolle, oder?
Einzelrechte auf Anwenderebene sind somit hinfällig.
Rollen werden somit Teams zugewiesen und darüber die Berechtigung gesteuert !?

 

Nun ja. Das wäre eine Möglichkeit.

Ich dachte das eher mehr flexibel.

Rechte können dann so vergeben werden:

Rechte an den Anwender.
Rechte an ein Team uns somit an jedes Teammitglied.
Rechte an eine Rolle und die kann entweder an ein Team oder an einen Anwender alleine angewandt werden.

So wäre das wohl cool. Aber wahrscheinlich in Access nicht abzubilden oder?

 

Das hat erstmal nix mit Access zu tun sondern mit Datenbanken und Datenmodellierung... ich geh mal in mich und versuch das als Modell aufzubauen.