Datenbanken anonymisieren

[Doming]

Hallo,

wir haben bei uns im Unternehmen eine gewachsene DB-Struktur, d.h. User A baut ein FrontEnd DB_Rechnungen und steckt die Tabellen in Rechnungen_be, User B baut DB_Auftrag und schreibt die die Tabs in Auftrag_BE usw.

Nun sollen die Fileserver abgeschaltet werden und die DB sollen auf ein neues Netzlaufwerk, damit es "mit dem Wildwuchs" ein Ende hat. Also: Die Anwender bekommen die FrontEnds irgendwo in der Verzeichnisstruktur, so dass auch nur sie Zugriff haben. Auf die BE haben ja alle Anwender Vollzugriff, damit sie die Daten lesen und schreiben können. Es gibt natürlich Tabellen, die von mehreren FrontEnds genutzt werden, z.B. tbl_Kundendaten.

Meine Idee wäre jetzt, die BackEnds zu anonymisieren, also statt Auftrag_BE dann nur noch BE1, BE2 usw.. Und auch die Tabellen könnten Dann Tab1, Tab2 usw. heißen. Das Ganze, um Manipulationen der Daten zu erschweren.
Der Entwickler hat dann natürlich eine Liste mit Art und Funktion der verschiedenen Tabellen.

Im Frontend kann Tab1 dann wieder als tbl_Kunde verknüpft werden.

Klar, für den Entwickler mehr Arbeit, aber für den Feldwaldwiesen-Schlingel eine große Hürde, um gezielt Rohdaten zu manipulieren.

Gruß
 Doming

[Bitsqueezer]

Hallo,

parallel zu Deiner anderen Frage, spätestens jetzt wäre es dringend nötig, ein DB-Backend und nicht mehr Access-Backends zu verwenden.

Zum einen hast Du ein zentrales Repository für ALLE Tabellen, die dann auch perfekt zusammenarbeiten können, zum anderen kannst Du hier alle Arten von Rechten vergeben, Zugriffsarten auf welche Ressourcen, Benutzer, Benutzergruppen, Rollen, granular bis runter zu einzelnen Feldern oder Datensätzen. Ebenso kann man Daten anonymisieren, so daß der nicht berechtigte Benutzer nur verschlüsselte Daten sieht bzw. Dummy-Daten, so daß man Daten auch vor Entwicklern verborgen halten kann, wenn gewünscht.
Mit Access ist Datensicherheit quasi nicht sinnvoll realisierbar.

Ein DB-Server braucht dabei auch keinen Fileserver, läuft als Dienst.

Gruß

Christian

[Doming]

Hmtja, tatsächlich ist es so, dass unsere IT am Liebsten sowieso alle Access-Anwendungen einstampfen will (die Argumentation kann ich verstehen, ich möchte als Außenstehender meinen Quellcode auch nicht reparieren müssen, wenn der Verursacher im Urlaub ist ) Allerdings sind die Dinger teilweise schon essentieller Bestandteil der Arbeitsweisen in der Abteilung, an eine Ablösung ist von der Seite kaum zu denken.

[Bitsqueezer]

Hallo,

neinnein, Du hast mich falsch verstanden: Nicht die Access-Anwendungen (die Frontends), sondern nur das Backend.
Das ist einigermaßen einfach auszutauschen mit SSMA und die Frontends funktionieren danach i.d.R. 1:1 wie vorher.

Die IT wird es freuen, nur eine Datenbank auf SQL Server mit Backup (automatisiert durch SQL Server selbst) zu bestimmten Zeiten durchzuführen, statt x Access Backends, die ggf. gerade auch noch defekt sind.

Gruß

Christian

[Doming]

Hallo,

da ich bisher ausschließlich mit Access-BackEnds gearbeitet und mir mein bisheriges Wissen autodidaktisch beigebracht habe, gibt es ein möglichst nicht zu verkopftes Tutorial, welches man sich dazu mal einverleiben könnte?

Gruß
 Doming

[Bitsqueezer]

Hallo,

naja, Tutorials gibt es sicherlich, aber welches davon zu Dir paßt, mußt Du schon selbst herausfinden.
Ich würde empfehlen, einfach die nächstbeste KI zu verwenden, die Dir geduldig jede Frage dazu beantworten kann. Die kannst Du auch fragen, ob sie Dir Tutorials nach Deinen Vorstellungen heraussuchen kann (vorzugsweise hier Gemini mit Google Suchmaschine im Hintergrund), außerdem kannst Du sie fragen, ob sie die Rolle als Lehrer einnehmen kann, also keine fertigen Lösungen präsentiert, sondern Dir das Thema näherbringt.

Aber so generell: Du arbeitest im Backend mit SSMS (SQL Server Management Studio, kannst Du Dir bei MS kostenlos downloaden, verwaltet jedwede SQL Server Instanz). Damit verbindest Du Dich auf den SQL Server und er listet Dir u.a. alle vorhandenen Datenbanken. Die kann man aufklappen und findet dann Tabellen, Views ("Sichten"), und einiges mehr.
Hier kannst Du z.B. neue Tabellen mit einem grafischen Designer erstellen, recht ähnlich zu dem von Access. Du kannst Views (Abfragen/Queries) erstellen, ebenfalls mit einem grafischen Designer, der um einiges einfacher und logischer ist als der von Access. Das sind schon die beiden wichtigsten Dinge. Es gibt auch einen Beziehungseditor ("Diagramme"), im Gegensatz zu dem von Access kannst Du hier auch so viele Diagramme anlegen, wie Du willst, so daß nicht ein Spinnennetz von wirren Beziehungen aus ALLEN Tabellen entsteht, wie man es in Access hat, sondern je Thema getrennt, außerdem kann man Notizen an beliebiger Stelle in's Diagramm schreiben.

Bis hierhin mußt Du also nicht einmal eine Zeile SQL können, um alles verwalten zu können.

Und, wie gesagt, SSMA (SQL Server Migration Assistant, ebenfalls kostenlos bei MS downloadbar) kannst Du dazu verwenden, Deine aktuelle Datenbank zu migrieren (immer mit einer Kopie natürlich, weil SSMA die Access-Datei verändert). Er sammelt die verlinkten Ressourcen eines Access Backends ein, holt auch lokale Tabellen des Frontends und schiebt alles als neue Tabellen auf den Server, verlinkt sie dann passend ins Frontend und behält dabei die Namen bei, so daß Dein Frontend, wenn es nicht zu kompliziert gebaut ist, nach Fertigstellung sofort mit SQL Server lauffähig ist (im Idealfall).

Natürlich braucht es etwas Nacharbeit, zum Beispiel sinnvolle Indizes zu setzen, die nicht immer richtig oder gar nicht übernommen werden, usw.

Lokale Queries übersetzt er, glaube ich, nicht. Hier kann man dann entsprechend analoge Views auf dem SQL Server erstellen und ins Frontend verlinken, um die Performance zu verbessern. Was bei Views natürlich nicht geht: Zugriffe auf lokale VBA-Funktionen oder auf Formular/Report-Elemente.
Views sind, korrekt erstellt, wie Tabellen editierbar. Für das Access-Frontend gibt es da keinen Unterschied, für Access sind alles Tabellen.
Es ist empfehlenswert, für Access keine Tabellen direkt zu verlinken, sondern immer nur Views. Aber das ist mit Access (ohne SQL Server) ja ebenso zu empfehlen.

Für einen ersten Test würde ich empfehlen, einen lokalen SQL Server zu installieren (Developer-Version ist gratis, aber entspricht der größten SQL Server Ausbaustufe, alternativ SQL Server Express). Für Produktiv-Umgebung SQL Server Express (Developer darf nicht produktiv eingesetzt werden) oder, wenn der Weg dahin klar ist und Budgets vorhanden sind, dann mind. die SQL Server Standard Version, die i.d.R. alle Wünsche abdeckt. Die kostet halt Lizenzen je User oder alternativ je CPU-Kern, dann unbegrenzte User.

Mit einem lokalen kannst Du erst mal experimentieren, SSMA ausprobieren usw.

Gruß

Christian

[Doming]

Ich würde empfehlen, einfach die nächstbeste KI zu verwenden, die Dir geduldig jede Frage dazu beantworten kann. Die kannst Du auch fragen, ob sie Dir Tutorials nach Deinen Vorstellungen heraussuchen kann (vorzugsweise hier Gemini mit Google Suchmaschine im Hintergrund), außerdem kannst Du sie fragen, ob sie die Rolle als Lehrer einnehmen kann, also keine fertigen Lösungen präsentiert, sondern Dir das Thema näherbringt.

Ich habe nun schon einige Probleme in VBA mittels KI lösen können, hatte aber da aber den Vorteil, dass ich so ungefähr wusste, was mir da vorgeschlagen wird. Da SQL wie erwähnt Neuland ist, habe ich Angst, dass mir der Kollege irgendwelchen Kram erzählt, der im Nachhinein gar nicht funktionieren kann.

[Bitsqueezer]

Hallo,

naja, wie arbeitest Du mit Access ohne SQL-Kenntnisse?

Aber wie gesagt: Das, was Du mit grafischen Designern in Access machen kannst, kannst Du auch mit SSMS machen, der Rest kommt von ganz allein. T-SQL ist weitaus umfangreicher als das karge Access SQL, die Möglichkeiten dafür auch.

Und: Wenn Du einen lokalen SQL Server installierst, kannst Du ja erst in Ruhe alles ausprobieren, ohne Firmendaten zugefährden.

Gruß

Christian