Guten Tag,
ich möchte für meine kleine, spezielle Vereinssoftware eine Zugriffshistory anlegen.
Dies wird nach der Datenschutzgrundverordnung verlangt.
In dieser History soll abgelegt werden:
Wer hat sich wann am Programm angemeldet und was hat er in welchem Programmteil getan.
Auch soll eine Auswertung in Form eines Druckes enthalten sein,
a) über alle Aktivitäten und auch
b) speziell für einen Programmnutzer.
Dazu dachte ich mir, das ich 3 Tabellen benötigen werden.
Da sehr wahrscheinlich sehr viele Zugriffe über das Jahr verteilt stattfinden werden,
möchte ich keine Generatoren als PrimaryKey verwenden, sondern den Hauptschlüssel der Tabellen über 2 Spalten erzeugen.
So wie ich es im Codebeispiel zeige, kann es nicht funktionieren. Ich muss ja die Tabellen mit einander über die Hauptschlüssel
verbinden und dies ist in meinem Beispiel sehr unglücklich gelöst.

Deshalb meine Fragen:
a) Wie würdert Ihr es lösen?
b) Wie würdet Ihr den Hauptschlüssel aufbauen?

1. Tabelle Anmeldung
2. Tabelle Protokolle
3. Tabelle Abmeldung

zusammenfalten · markieren

Delphi-Quellcode:

dtmdMain.bpsql.Close;
    dtmdMain.bpsql.SQL.Clear;
    dtmdMain.bpsql.SQL.Add('create table ProtAnmeldung ( '
      + 'angemeldetam timestamp not null, '
      + 'adressid integer not null, '
      + 'brdname do62 )');
    dtmdMain.bpsql.Prepare;
    dtmdMain.bpsql.ExecQuery;

    dtmdMain.bpsql.Close;
    dtmdMain.bpsql.SQL.Clear;
    dtmdMain.bpsql.SQL.Add('alter table protanmeldung add primary key (angemeldetam, adressid) ');
    dtmdMain.bpsql.Prepare;
    dtmdMain.bpsql.ExecQuery;

    dtmdMain.bpsql.Close;
    dtmdMain.bpsql.SQL.Clear;
    dtmdMain.bpsql.SQL.Add('create table protokolle ( '
      + 'loprotokolleid timestamp not null, '
      + 'adressid integer not null, '
      + 'menuename do50, '
      + 'protokoll blob )');
    dtmdMain.bpsql.Prepare;
    dtmdMain.bpsql.ExecQuery;

    dtmdMain.bpsql.Close;
    dtmdMain.bpsql.SQL.Clear;
    dtmdMain.bpsql.SQL.Add('alter table protokolle add primary key (loprotokolleid, adressid) ');
    dtmdMain.bpsql.Prepare;
    dtmdMain.bpsql.ExecQuery;

    dtmdMain.bpsql.Close;
    dtmdMain.bpsql.SQL.Clear;
    dtmdMain.bpsql.SQL.Add('create table protabmeldung ( '
      + 'abgemeldetam timestamp not null, '
      + 'adressid integer not null )');
    dtmdMain.bpsql.Prepare;
    dtmdMain.bpsql.ExecQuery;

    dtmdMain.bpsql.Close;
    dtmdMain.bpsql.SQL.Clear;
    dtmdMain.bpsql.SQL.Add('alter table protabmeldung add primary key (abgemeldetam, adressid) ');
    dtmdMain.bpsql.Prepare;
    dtmdMain.bpsql.ExecQuery;

Vielen Dank für Eure fachmännischen Hilfen im Voraus.

Hallo,

Zitat:

kleine, spezielle

Zitat:

wahrscheinlich sehr viele Zugriffe

Zitat:

keine Generatoren als PrimaryKey

http://docwiki.embarcadero.com/Inter...ing_Generators
Generators return a 64-bit value

64bit
-> 2^64 -> rechne mal aus, wie viele Mio. Jahre sich tausende Anwender (ja, ich übertreibe )
sich da an- und abmelden können.

Nimm Int64 oder eine GUID als PK, aber keine Doppelfelder.
Und vor allem, nimm künstliche Schlüssel als PK, die mit dem eigentlichen Dateninhalt nichts zu tun haben.

Aus der holen Hand

Table_Connection:

id

pers_id

login

logoff

autologoff

Table_Action:

id

pers_id

table_name

table_id

table_action (new/delete/edit/read)

Damit solltest Du die wesentlichen Anforderungen abdecken können.

Gruß
K-H

P.S.
Über den Einsatz von Generatoren sollte man nicht nachdenken. Wenn es eng werden könnte, dann nimmt man für die Log-Tabellen eben eigene Generatoren

Hallo,

Zitat:

Wenn es eng werden könnte, dann nimmt man für die Log-Tabellen eben eigene Generatoren

Hm?
Pro Tabelle wird ein Generator benutzt.

Dass die DSGVO eine Zugriffshistory verlangt, würde mich wundern. Meines Wissens sind technisch/organisatorische Maßnahmen zu ergreifen, dass nur Befugte auf die Daten zugreifen können. Aber vielleicht ist das bei Euch in D wirklich so anders als bei uns in A.

Ich würde eine einzige Tabelle nehmen, PK ist eine generierte ID, dann gibt es noch eine Referenz auf die Person + was(!) sie wann(!) (+ev. womit) gemacht hat. Dann kannst du alles ermitteln, was du brauchst:
- wer hat sich in einem Zeitraum angemeldet?
- Wer hat X gemacht?

In die Tabelle kannst du sogar Teile des Datenbestands kopieren, wenn du genau nachvollziehen willst, was gemacht wurde.

Den Bedarf seh ich auch nicht so recht gemäß DSGVO.
Solange es reguläre Zugriffe durch Vereinsmitglieder mit entsprechenden Aufgabenbereichen sind, gehört es eher in die Datenschutzerklärung rein. Es wird halt mit den Daten gearbeitet, entsprechend des Bedarfs.

@generatoren
Man nimmt meist einen pro Spalte/Tabelle, aber das kann man auch anders machen und dafür gibt es einen Grund. Das ist "Widerstandskraft" gegen Fehlbedienung (durch Admin, Entwickler, ..)

Änderungen sollte man protokollieren. Aber die Protokollierung von Zugriffen wäre ja eher ein Verstoss gegen den Datenschutz.

Zitat von hoika:

Hallo,

Zitat:

Wenn es eng werden könnte, dann nimmt man für die Log-Tabellen eben eigene Generatoren

Hm?
Pro Tabelle wird ein Generator benutzt.

Ich kenn es von Oracle so daß es nur einen "Generator" gibt. Manchmal werden mehrere eingesetzt z.b. einer für Personendaten und einer für Aktendaten und einer für das Log.

@MKinzler
Ist in einem Betrieb problematisch wg. Leistungsüberwachung.

Gruß
K-H

Zitat von mkinzler:

Änderungen sollte man protokollieren. Aber die Protokollierung von Zugriffen wäre ja eher ein Verstoss gegen den Datenschutz.

Das ist nicht richtig. Wenn es wichtig ist, zu wissen, wer wann was geändert hat, ist es natürlich zulässig.

Die DSGVO enthält keine technischen Vorgaben oder Einschränkungen. Im Grundsatz verlangt sie Transparenz und Nachvollziehbarkeit, was mit den Daten geschieht unter dem Gesichtspunkt "nur was notwendig ist" und "nicht länger als notwendig". Das "notwendig" ist zu begründen und zu dokumentieren.

zusätzlich muß die Person deren Daten erfaßt werden, darüber informiert werden, daß die Daten erfasst werden.


Gruß
K-H