Datenbank zu einem Genehmigungsportal

[Säsch]

Hallo IT-Community,

ich muss zur Beschleunigung eines Prozesses einen Unterschriftenprozess automatisieren.
Das heißt Dokumente werden zur Zeit zu Fuß zu den Verantwortlichen gebracht, sodass diese dieses Dokument unterzeichnen können. Das soll mit Hilfe einer Web-Anwendung automatisiert werden.

Also Berechtigte Personen können mehrere Dokumente (für die sie berechtigt sind) unterzeichnen (JA/NEIN-boolsch) und andersrum kann ein Dokument von einer oder mehreren Personen unterschrieben werden. Wir haben also "m" "Berechtigte" zu "m" "Dokumenten". Wir brauchen also eine Verbindungstabelle die von "Berechtigte" und "Dokumente" die Schlüssel nimmt. Diese Tabelle nennen wir auch direkt "Unterschriften". So haben wir also nur 3 Tabellen.

Nun wollte ich meine Datenbank-Manipulationen und Selects mit meinen "Eingabe-Knöpfen" verbinden. Da ich wenig Ahnung von PHP habe und überhaupt noch nicht weiß welches Programm überhaupt dazu in Frage kommt (vlt. ein bestimmter Formular-Generator oder ein anderes Programm....), muss ich nur ein Konzept entwickelt: Also die SQL-Logik hinter den Eingabefeldern beschreiben und das Frontend in einer Power-Point-Präsentation zeigen.

Das Front-End sieht in etwas so aus, dass ich mich erst einmal anmelden muss (Username/Passwort). Diese 2 Attribute sind in der Tabelle "Berechtigte" definiert. Dann kann ich aus einem Dropdown-Menü das betreffende Dokument (liegt in einer Dokumentenmanagement-Software) auswählen und es mit einem Klick auf einen Knopf "Signieren" signieren und außerdem einen Kommentar in ein Textfeld schreiben. Zusätzlich zu signieren müssen noch 3 weitere Knöpfe anklickbar sein: "approved", "rejected", "in process". Man muss also die 3 eben erwähnten Optionen und das Kommentarfeld signieren. Fragt mich nicht warum. Wird so erwünscht.

Ich hab ein Relationship-Diagramm der Tabellen im Anhang.

Nun zur SQL-Logik hinter den Feldern, die ich beschreiben soll. Bin mir da sehr unsicher.

a) Das Auswahlfeld des Dokuments ist einfach:
SELECT Referenz zu Dokument FROM Dokument
Die Auswahl wäre dann in der Variablen hinter dem Auswahlfeld abgespeichert.

b) Das schwierige is der Knopf "Signieren" mit dem ich alle Eingaben der Maske irgendwie in die Datenbank und nur zum jeweiligen "Berechtigten" schreiben muss.

Es ist klar, dass dieser Knopf verschiedene INSERT INTOS machen muss:
INSERT INTO Unterschrift (Comment)
VALUE ("Text aus Eingabefeld");
AND
INSERT INTO Unterschrift (Signed?)
VALUE ("Wert der hinter dem Knopf "Signieren" liegt");

Ich frage mich an dieser stelle gerade nur wie ich INSERT INTOS mit verschiedenen Tabellen die mit der INSERT-INTO-Tabelle mit Fremdschlüsseln verbunden sind miteinbeziehe. Es soll ja nur bei dem "Berechtigten" reingeschrieben werden der sich mit Username und Passwort angemeldet hat.

Es muss irgendwie ein SELECT WHERE der Anmelde-Information und des betreffenden Dokuments mit meinem INSERT INTO verbunden werden.

Vielleicht so mit 2 SELECT WHERES? =>

INSERT INTO Unterschrift (Comment)
VALUE ("Text aus Eingabefeld")
SELECT * FROM Berechtigte
WHERE Username = Wert hinter Anmelde-Bestätigungsknopf
SELECT * FROM Dokument
WHERE Referenz zu Dokument = Wert hinter dem Drop-Down-Menü

Geht das so in etwa oder bin ich komplett auf dem falschen Weg?

Viele Grüße

 

[Distrilec]

1. Was für ein DBMS

Oracle (und ich glaube auch Postgres) unterstützt Mutli-Table Inserts... (Wahrscheinlich auch MS SQL)

2. Wieso meldest du dich an einer Datenbank an, nur um dich an deiner Applikation anzumelden? Nimm doch den Datenbank-User ?
3. Bitte schmeiß dein gesamtes "Modell" (wie du es nennst) in die Tonne...

Es gibt wesentliche Fehler in deinem Gedankengang...
- Wie bekommst du deine Dokumente aus deiner Dritt-Software in die Datenbank?
- Wie bekommst du deine Signatur aus deiner Datenbank in die Dritt-Software?
- Wie stellst du sicher das die nötige Anzahl signaturen vorhanden ist?
(Bspw.: Ab einem Einkaufsbetrag von 200.000 Euro muss nicht nur der Einkäufer sondern auch der Abteilungsleiter unterschreiben)
- Kann das deine Dritt-Software nicht?
- Wie stellst du die nötigen Berechtigungen sicher? Immerhin soll nicht jede Person jeden Vertrag/ jedes Dokument sehen können.

Das ist kein triviales Projekt das mal eben in einer Woche abgeschlossen wird...

Es sei denn dir ist Skalierbarkeit und struktureller Aufbau scheiß egal, da du in einem kleinen Unternehmen sitzt und die Probleme die in den nächsten Jahren auftauchen werden in Kauf nimmst...

 

[Säsch]

Genau, also die Probleme die bei meinem "Modell" vorhanden sind, sind zusammengefasst folgende:

1.) Der komplette Signierungsprozess muss genau wie in meinem "Modell" nochmal im Dokument eingetragen werden. Das habe ich nicht abgebildet, weil ich nicht weiß, wie man über mein Tool und über die Drittsoftware in das Dokument reinschreiben soll.
2.) Streng genommen hat jedes Dokument nur eine bestimmte Anzahl an Berechtigten die signieren dürfen. Da hast du Recht das ist ein Problem. In meinem Modell sind nur ALLE BERECHTIGTEN drin. Deswegen müsste ich die Tabelle "Unterschriften" eigentlichen umbenennen in "Unterschriften/Berechtigung" und noch abklären ob die Person überhaupt für das jeweilige Dokument berechtigt ist. Und das ist wie du schon sagst nicht ohne weiteres möglich.

Das sind Probleme an die ich gedacht habe aber mir keine Lösung dafür eingefallen ist. Werde ich einfach erwähnen.

Es gibt nämlich eigentlich eine viel einfacherere Lösung:
Ein E-Mail-Notification an die beteiligten Personen mit einer Workflow-Software, in der alle Informationen drin steht. Dann machen die beteiligten das Dokument auf und machen alles manuell. Sicherlich einfacherer.
Ich werde beide Möglichkeiten vorstellen und auf Probleme hinweisen.

Es wird Oracle genutzt. Es sind aber auch MS SQL Lizenzen zur Verfügung.

Das was du mir mit Datenbankanmeldung und User geschrieben hast, habe ich nicht Verstanden. Du meinst, dass man zur Anmeldungen einen User nimmt, der im Datenbank-Management-Tool angelegt wird (z.B. der Benutzer in phpmyAdmin) und den Benutzer nicht in der Datenbank-Tabelle anlegt. Wie ordne ich diesem Nutzer dann die Daten Kostenstelle, Abteilung etc zu, die ich VLT später noch brauche oder sonstige Beziehungen.

 

[Säsch]

Ich wollte nocheinmal auf ein paar "schlechte" Lösungen der genannten Probleme eingehen:

a) Die Zugriffsberechtigung ist doch über Username/Password geregelt? Also nur die Leute die sich anmelden können, dürfen auch signieren. Streng genommen können also nur zu wenige Signaturen vorhanden sein, oder zu viele, aber komplett umberechtigte haben keinen Zugriff, weil sie kein Username und Password haben. Später kann dann im Originaldokument und meinem Tool geschaut werden, ob die Signaturen übereinstimmen (steht auch alles nochmal im Dokument).

b) Einfach nicht in die Drittsoftware "reinschreiben" sondern nur den Namen des Dokuments aus der Drittsoftware ermitteln und nicht das komplette Dokument (dürfte nicht so schwer sein, hoffe ich). Und dann einfach Dokumentname und Signierungsdaten anzeigen.

Überzeugender ?

 

[Tom.S]

Noch einmal Grundlegendes zu HTML+PHP+Datenbank:
Du hast auf einer HTML-Seite eine beliebige Anzahl höchst unterschiedlicher Formulare (Radio-Buttons, Textfelder). Die sind eingeschlossen in eine <form action...>-Element. Alle eingeschlossen Daten werden bei einem Klick auf den Button auf den Server geladen und dort von PHP in Empfang genommen. PHP kann jetzt diese Daten nach Herzenslust manipulieren und sie, wenn es Spass daran hat, in 1000 unterschiedliche Tabellen in der Datenbank schreiben, in welcher Form auch immer.
Das einmal verstanden, lösen sich die meisten Deiner Probleme in Wohlgefallen auf.

Jetzt zu Deinem Ansatz:

2.) Streng genommen hat jedes Dokument nur eine bestimmte Anzahl an Berechtigten die signieren dürfen. Da hast du Recht das ist ein Problem. In meinem Modell sind nur ALLE BERECHTIGTEN drin. Deswegen müsste ich die Tabelle "Unterschriften" eigentlichen umbenennen in "Unterschriften/Berechtigung" und noch abklären ob die Person überhaupt für das jeweilige Dokument berechtigt ist. Und das ist wie du schon sagst nicht ohne weiteres möglich.

Es wird eine oder mehrere administrierende Personen geben, die neue Dokumente einstellt und die Unterzeichner auswählt. Technisch wird erst jetzt ein neuer Eintrag in der Dokument-Tabelle vorgenommen, mit einer entsprechenden Referenz auf das Dokument in der anderen DB. Zudem wird die Koppelungstabelle um die Verknüpfungen zwischen dem Dokument-Eintrag und den Unterzeichnern ergänzt. Nicht ausgewählte Unterzeichner werden also gar nicht gekoppelt, weshalb sie auch nie ein anderes Dokument zu Gesicht bekommen. Eine weitere Berechtigungsprüfung oder den Eintrag "Authorized?" braucht es also gar nicht.
Jeder der Personen bekommt jetzt automatisch per PHP eine Email geschickt, dass ein neues Dokument zum zeichnen bereitsteht und die den Link auf die entsprechende Seite enthält. Dort loggt er sich ein mit seinen Benutzerdaten und findet sowohl die bereits signierten Dokumente vor als auch die noch nicht bearbeiteten. Er kann den Dokumentenlink anklicken und dann Häkchen bei allen noch nicht bearbeiteten Dokumenten machen. Ein Klick auf den Signieren-Button übergibt seine geänderten Daten an PHP, das die Datenbank aktualisiert.
PHP sendet jetzt eine E-Mail an den Administrator bzw. die Person, die das Dokument eingestellt hat und prüft dafür, ob noch Unterzeichner fehlen.
Dann brauch es nur noch einen Cronjob, der alle paar Stunden/Tage prüft, für welche Dokumente noch Unterschriften fehlen und Erinnerungsmails schickt bzw. den Admin informiert.

1.) Der komplette Signierungsprozess muss genau wie in meinem "Modell" nochmal im Dokument eingetragen werden. Das habe ich nicht abgebildet, weil ich nicht weiß, wie man über mein Tool und über die Drittsoftware in das Dokument reinschreiben soll.

Du brauchst eine Schnittstelle für die Drittsoftware, mit der Du Dokumente manipulieren kannst. Da schreibst Du dann mit PHP rein. Generiert die Drittsoftware die Dokumente nicht, sondern speichert nur statische Dateien (PHP, Word,...), dann lädst Du das Dokument per PHP, editierst es und lädtst es wieder in die Drittsoftware (updatest es also dort).
In jedem Fall nutzt Du PHP für diesen Prozess.

Das was du mir mit Datenbankanmeldung und User geschrieben hast, habe ich nicht Verstanden. Du meinst, dass man zur Anmeldungen einen User nimmt, der im Datenbank-Management-Tool angelegt wird (z.B. der Benutzer in phpmyAdmin) und den Benutzer nicht in der Datenbank-Tabelle anlegt. Wie ordne ich diesem Nutzer dann die Daten Kostenstelle, Abteilung etc zu, die ich VLT später noch brauche oder sonstige Beziehungen.

Man kann natürlich den PHP-Benutzer mit dem Datenbanknutzer koppeln. Meistens gibt es einen Standarduser und alles, was PHP entgegenimmt (egal unter welchem PHP-Benutzernamen) wird unter diesem Standardnutzer in die Datenbank geschrieben. Die reine Lehre sieht natürlich so aus, für jeden Nutzer auch einen Datenbank-user einzurichten (mit Standard-Rechten) und ihn mit dem PHP-Benutzer zu koppeln, so dass ein PHP-User ThomasFischer automatisch als DB-User thomasfischer in die Datenbank schreibt. Aber wie das gehandhabt wird, kann Dir jetzt egal sein. Es macht keinen wirklichen Unterschied.

Ein E-Mail-Notification an die beteiligten Personen mit einer Workflow-Software, in der alle Informationen drin steht. Dann machen die beteiligten das Dokument auf und machen alles manuell. Sicherlich einfacherer.
Ich werde beide Möglichkeiten vorstellen und auf Probleme hinweisen.

Also ich finde die Sache eigentlich ziemlich simpel. Sicherlich gibt es ein paar Sachen zu bedenken und etwas zu programmieren, denn Du brauchst eine Administrator-Oberfläche, auf der man User hinzufügen kann, Dokumente einstellen kann, Dokumente löschen und Zuordnungen editieren kann. Und dann brauchst Du das User-Interface, auf dem Zeichnungsberechtigte ihre Entscheidungen ansehen und auch zurücknehmen können. Das gut umzusetzen, dauert sicherlich mehr als eine Woche, aber das Konzept dafür ist recht straightforward und ohne große Schwierigkeiten.

 

[Distrilec]

Also ich finde die Sache eigentlich ziemlich simpel. Sicherlich gibt es ein paar Sachen zu bedenken und etwas zu programmieren, denn Du brauchst eine Administrator-Oberfläche, auf der man User hinzufügen kann, Dokumente einstellen kann, Dokumente löschen und Zuordnungen editieren kann. Und dann brauchst Du das User-Interface, auf dem Zeichnungsberechtigte ihre Entscheidungen ansehen und auch zurücknehmen können. Das gut umzusetzen, dauert sicherlich mehr als eine Woche, aber das Konzept dafür ist recht straightforward und ohne große Schwierigkeiten.

Um dieses "ziemlich simple" Thema dann einmal zusammen zufassen:
- Berechtigungsverwaltung: Immerhin darf ja nicht jeder jedes Dokument sehen... Oder?
- Sicherheit: Das Passwort in einer Tabelle zu speichern auf die potentiell jeder der sich an deiner Applikation anmelden kann auch Zugriff hat... Gefährlich... (Deswegen auch lieber direkt den DB-User...)
- Hierarchie: Wenn ein Einkäufer eine Bestellung unterschreiben darf, darf das auch ein Geschäftsführer... Wenn das dann der Geschäftsführer unterschrieben hat, ist die Unterschrift des Einkäufers wohl überflüssig? (Selbst wenn es keine Anforderung ist... Es wird sehr schnell eine werden sobald das ganze Produktiv genutzt wird...)
- Handling mehrerer Signaturen: Manche Dokumente müssen nach dem 4-Augen Prinzip abgesegnet werden.
- Man möchte die Signierung direkt ins Dokument eintragen (PDF, Word-Dateien, etc. direkt anpassen?)
- Stabile Schnittstelle zum Dritt-System das die Dokumente bereitstellt (Was passiert wenn zwei Leute gleichzeitig ein Dokument signieren wollen? Ein Dokument kann nur von einem Benutzer bearbeitet werden)
- Man soll Signaturen auch wieder widerrufen können (Erfordert ja fast schon eine revisionsichere Archivierung?)
- Man möchte ein gesamtes Front-End als Web-App (Intern oder auch extern erreichbar?)

- TONNENWEISE Exception-Handling... Bsp.: Was passiert wenn beim Bearbeiten eines Dokuments plötzlich die Verbindung zur Dritt-Software abbricht? Worst-Case: Es verbleibt nur etwas Datenmüll und ein gesperrtes Dokument das keiner mehr anfassen kann. (Hängt natürlich davon ab was eure Dritt-Software alles kann oder eben auch nicht kann )

@Tom.S Dafür "sicherlich mehr als eine Woche" zu planen... Sportlich...

@Säsch Auch wenn es sich erstmal nur um graue Theorie handelt... Die Punkte oben kannst du bei deiner Präsentation ALLE ansprechen... Das sind jetzt aber auch nur Punkte die mir auf die schnelle einfallen... Da kommt bestimmt noch einiges mehr wenn man dann erstmal was vorbereitet.

 

[Tom.S]

@Distrilec Wenn Du haufenweise Anforderungen hinzufügst, dann kann es natürlich beliebig komplex werden. Aber von 4-Augen-Prinzip war genauso wenig die Rede wie von hierarchischen Beziehungen. Wenn die Dokumente nicht einfach Text in einer Dokumenten-DB sind, sondern leibhaftige PDFs, brauch man halt eine Zusatzsoftware, wie z. B. http://www.setasign.com/products/setapdf-signer/
Auch sehe ich keine großen Probleme dabei, wenn zwei Leute gleichzeitig ein PDF signieren wollen. Sie übergeben ja nur dem Server-Programm die Information, dass sie es signieren. Das kann dann das Dokument locken. Es geht hier wohl eher nicht um eine Signatur mit privatem Schlüssel und Passwort-Eingabe.
Ich sehe nach wie vor nicht, dass es nennenswert kompliziert ist. Wenn es wirklich um das Signieren von PDFs geht, dann steigt der Aufwand und man muss eine lib dazukaufen, aber ansonsten sehe ich immer noch keine wirklichen Probleme.

 

[Distrilec]

@Tom.S
Ein kleines Beispiel das meinen Gedankengang hoffentlich ganz gut erklärt:
Nehmen wir mal an es handelt sich bei diesen "Dokumenten" um technische Zeichnungen für Geräte die Sie herstellen.
Nehmen wir mal an es wird eine Änderung an einem Gerät vorgenommen, da ein Bauteil zu spontanen Selbstentzündungen führen kann.
Jetzt muss diese Zeichnung von mindestens einem anderen tech. Zeichner überprüft werden, bevor nach der Zeichnung gebaut werden darf.
Aus irgendeinem Grund geht die Signatur (das OK-Zeichen des zweiten Zeichners, der bestätigt das die Zeichung in Ordnung ist) auf dem Weg zum Dokument verloren.
Die Fertigung baut beim werten @Säsch jetzt fröhlich weiter nach dem alten Plan (der ja das potentiell selbstentzündende Bauteil enthält).
Zwei Wochen später kommt es bei einem Kunden zum Großbrand und eine Lagerhalle brennt komplett ab.
(Ein ziemlich extremes Beispiel... Aber wir wissen nunmal nicht für wen das ganze gedacht ist und was diese "Dokumente" sind bzw. sein werden)

Es geht hier nicht um eine Musik-Datenbank eines Hobby-DBAs, das sind Betriebsdaten die er damit verarbeiten will.
Da ist es numal normal das ich versuche sämtliche Fehlerquellen und Änderungen im Nachhinein (was auch nichts weiter als potenzielle Fehlerquellen sind) von Anfang auszuschließen.

In etwas allgemeinerer Sprache nennt man das Pflichtenheft.
Und da es ihm derzeit nur um ein "Konzept" geht das er später in einer Präsentation vorstellt -> ist das nicht der perfekte Zeitpunkt um so ein Ding tatsächlich auch zu definieren?
Derzeit scheint ja nur das Lastenheft vorhanden zu sein... Nach dem sollte man eine Applikation allerdings nicht erstellen

Und der Grund warum Lastenheft != Pflichtenheft ist nunmal um die Anforderungen des Users um Anforderungen von anderen Quellen zu erweitern.
Das könnte dann sogar das erste Dokument werden, dass später über die Applikation eigenst vom Chef signiert wird

 

[Säsch]

Kurz zum Dokument um das es sich handelt:

Ich habe hier ja einen weitere Thread offen. Mein Bachelorthema hat sich offensichtlich um eine Nebenaufgabe ergänzt

Es handelt sich um Ein Excel-Dokument zur Aufwandsabschätzung von Produkten, an denen etwas neues Entwickelt werden muss. Dieses Dokument liegt in einem sehr sicheren Dokumenten-Management-Tool mit dem Namen Clarity PPM. Dort muss man "aus-checken" wenn man das Dokument bearbeitet und es wieder "ein-checken". Das ganze dauert ein wenig und ist nervig, deswegen werden manche Direktoren, die das Dokument letztendlich unterzeichnen müssen gegen meine "Einfache Möglichkeit" sein.

Später steht ja sowieso, ob durch mich, mein Kozept oder einen IT-Experten eine Datenbank, die alle Informationen dieses Excel-Dokuments in einer Datenbank darstellt. Deswegen wäre es am besten, wenn es direkt mit meiner Bachelor-Arbeit kombinierbar wäre. Deswegen bin ich auch nicht auf die Verbindung zur Drittsoftware und Manipulation des Dokuments an sich eingegangen.

Ich weiß das man auf die Datenbank von Clarity PPM mit Oracle ganz einfach zugreifen kann.

 

[Säsch]

@Tom S.

ich verstehe nicht, warum ich den Eintrag "authorized?" bei deiner Möglichkeit nicht brauche.
Du meinst doch, das wir einen Administrator brauchen der manuell das Dokument und die betreffenden Unterzeichner festlegt. An meiner Tabellenstruktur ändert sich alao nichts. Also eigentlich würde der Admin doch dann "authorized" auf YES setzen. Was meinst du mit Kopplung und Verknüpfung?

@Distrilec

Ich muss mir darüber mal Gedanken machen. Auf alle Fälle Liste ich alle Probleme auf.

Viele Grüße

 

[Tom.S]

@Distrilec Gut, dann konzipieren wir aneinander vorbei. Dir schwebten hochsicherheitsrelevante Daten vor, mir die langweiligen Sitzungsprotokolle, die eh keiner liest, aber gegenzeichnen muss (wenn es nicht die Sekretärin tut). Hätte man es mit Deinen Daten zu tun, so dachte ich, würde man nicht die studentische Hilfskraft dafür heranziehen. Ich lag anscheinend falsch und Du richtig.

Allerdings würde ich nicht das Pflichtenheft vor dem Konzept entwickeln. Es ist jetzt eben nicht der richtige Zeitpunkt das detailliert zu entwickeln. Jetzt geht es um das grundlegende Konzept und einen kurzen Powerpoint-Vortrag. Und da sind solche Details fehl am Platz. Und Säsch wird wahrscheinlich auch bei IT-Sicherheit eher bei Adam und Eva anfangen, deshalb verwirren die Details mehr als dass sie zu einem runden Vortrag führen.

@Säsch An deiner Stelle würde ich mich etwas mehr auf die Bachelorarbeit fokussieren.

Es handelt sich um Ein Excel-Dokument zur Aufwandsabschätzung von Produkten, an denen etwas neues Entwickelt werden muss. Dieses Dokument liegt in einem sehr sicheren Dokumenten-Management-Tool mit dem Namen Clarity PPM. Dort muss man "aus-checken" wenn man das Dokument bearbeitet und es wieder "ein-checken". Das ganze dauert ein wenig und ist nervig, deswegen werden manche Direktoren, die das Dokument letztendlich unterzeichnen müssen gegen meine "Einfache Möglichkeit"

Und eine Software wie Clarity ist nicht in der Lage, so einen Workflow bereitzustellen? Das solltest Du als erstes prüfen, ob sich das nicht alles schon mit den teuer bezahlten Bordmitteln bewerkstelligen lässt.
Aber für uns interessanter ist die Frage, wie soll das Signieren des Clarity-Dokuments vonstatten gehen? Ist das auch einfach nur ein Eintrag in der Clarity-Datenbank oder soll das Excel-Dokument digital signiert werden?

Ich weiß das man auf die Datenbank von Clarity PPM mit Oracle ganz einfach zugreifen kann.

Kein Wunder, unter der Haube von Clarity läuft ja auch wahrscheinlich Oracle.

ich verstehe nicht, warum ich den Eintrag "authorized?" bei deiner Möglichkeit nicht brauche.
Du meinst doch, das wir einen Administrator brauchen der manuell das Dokument und die betreffenden Unterzeichner festlegt. An meiner Tabellenstruktur ändert sich alao nichts. Also eigentlich würde der Admin doch dann "authorized" auf YES setzen. Was meinst du mit Kopplung und Verknüpfung?

An Deiner Tabellenstruktur würden sich eher Details ändern*, aber die grundlegende n:m-Handling scheint mir richtig.
Du brauchst deshalb kein authorized=YES, weil erst einmal keine Verbindung zwischen Person und Dokument existiert. Die Koppelungstabelle ist also leer. Erst wenn ein Admin eine Verknüpfung herstellt, wird ein Eintrag in der Koppelungstabelle (Verknüpfungstabelle) hinzugefügt. Authorized bräuchte man dann, wenn man erst einmal alle Dokumente mit allen Personen verbinden würde. Aber das wäre ganz schlechtes Datenbankdesign.
Generell ist es auch nicht Deine Aufgabe, Dich um die Sicherheit der Dokumente zu kümmern, das ist Aufgabe der Clarity-Software. Die muss verhindern, dass nicht autorisierte Personen keinen Zugriff auf die Dokumente haben, bei Dir geht es eher darum, dass niemand ein Dokument angezeigt bekommt, mit dem er nichts zu tun hat.

Was mir als Zusatz noch empfehlenswert erscheint, wäre die Möglichkeit, Benutzer in Gruppen einzuteilen, wenn häufiger die selben Personen ausgewählt werden müssen, sonst kann es eine sehr nervige Klickarbeit werden. Das wäre noch eine n:m Verknüpfung von Person zu Gruppe.

* z. B. hast Du Name der Person. Was machst Du bei einer Namensänderung? Fünf Jahre später weiß niemand mehr, dass es sich bei der Fr. Schmitt in dem Archiv um die Fr. Meier handelt. Eigentlich sollte von Dir hier nur die Personal-ID als Fremdschlüssel stehen und alle Namens-Daten aus einer zugreifbaren Personal-DB geholt werden. Damit Du Redundanzen vermeidest und nicht in beiden Tabellen Namen nachgetragen werden müssen. Wenn es eine solche Mitarbeiter-DB nicht gibt, dann sollten die Namensdaten in einer gesonderten Tabelle untergebracht werden.

 

[Säsch]

Also nochmal zum Thema "Sicherheit".

Es ist sogar erwünscht das eine automatische Genehmigung nach 15 Tagen erfolgen soll.
Diese Genehmigung hat historische Gründe. Das Dokument wurde schon von Experten abgesegnet muss aber trotzdem noch von den obersten Direktoren "unterzeichnet" werden. Einfach nur um die Verantwortlichkeiten klar zu machen.

Warum kann man das Passwort nicht in einer Tabelle stehen haben? Kann man das nicht irgendwie schützen?`

Viele Grüße

 

[akretschmer]

Zu Deinen 'Sicherheitsfragen': Du solltest Dich mit den Möglichkeiten der eingesetzten DB vertraut machen. In PostgreSQL z.B. kannst Du Leuten (User bzw. Rollen) Rechte auf Spalten nehmen oder setzen, und in 9.5 kannst Du sogar Rechte auf konkrete Zeilen setzen / wegnehmen : Row Level Security. Damit kann man sehr komplexe Zugriffs-Policies setzen, vielleicht zeige ich demnächst mal im PostgreSQL-Unterforum hier mal ein paar kleine Beispiele.

Deine automatische Genehmigung nach 15 Tagen ist einfach: wenn das aktuelle Datum > Datum + 15 Tage ist, dann ...
Passwort: mir ist nicht ganz klar, was Du genau vorhast und wo und warum Du es irgendwo speichern willst. Jede DB hat eine Userverwaltung, nutze doch einfach diese. Oft, wie bei PG, kannst Du User zu Rollen zusammenfassen, und diesen Rollen Rechte geben. Ich denke, auch Oraggle kann das.

 

[Säsch]

Hi,

ich habe eine Frage zur Ergänzung meines oben gezeigten ER und Rel-Diagram. Man möchte möglichst wenig Aufgaben an Administratoren verteilen.

Eine Möglichkeit wäre also die Personen und Dokumente nach Produktlinien zu gruppieren. Jedem Dokument ist eine Produktlinie zugeordnert und der Produktlinie immer die gleiche Handvoll an Unterzeichnern. Wie ergänze ich meine Diagramm am besten?

Das sind die Beziehungen:

Unterzeichner : Produktlinie => m:1 => Ein Unterzeichner ist einer Produktlinie zugeordnet und eine Produktlinie hat mehrere Unterzeichner

Document : Produktlinie => m:1 => Ein Dokument ist einer Produktlinie zugeordnet und eine Produktlinie hat mehrere Dokumente.

Ich würde eine neue Tabelle Produktlinie zur gemeinsamen Gruppierung von Dokumenten und Unterzeichnern implementieren. Ich Frage mich nur, wie ich dann wieder die "Authorisierung" auf TRUE setzen kann. Habt ihr eine Lösung?

 

[Distrilec]

Tabelle: Produktlinie
- Produktlinien_ID
- Bezeichnung

Tablle: Produktlinie_Unterzeichner
- Produktlinien_ID
- Unterzeichner_ID

Tabelle: Dokument
- ... Alle Spalten die es schon gibt
- Produktlinien_ID

Recht einfach... (Auch wenn man die Spaltenbezeichner anpassen sollte... Da bin ich immer sehr kreativ... )

Edit: Wobei ich da fast schon eher auf Row-Level-Security setzen würde... Davon ausgehend das euer DMS wahrscheinlich auch so ein Eigenschaftsfeld führt... (zumindest mit Oracle und Postgre 9.5 möglich...)