Von Access zu Entity Framework: Datenmodell

Lies in den Artikel rein und unten bekommst Du ein unschlagbares Angebot!

Bild 1: Beispiel für ein zu migrierendes Datenmodell

Viele Leser dieses Magazins programmieren auch mit Access. Der eine oder andere hat vielleicht sogar eigene Anwendungen oder Anwendungen von Kunden auf Access-Basis, die er gern in Form eines WPF- oder ASP.NET-Projekts umsetzen würde. Das Problem: Der Zugriff auf die Access-Datenbank ist unter .NET nur begrenzt möglich, die tolle Datenzugriffstechnologie Entity Framework beispielsweise unterstützt Access-Datenbanken nicht. Dafür unterstützt es allerdings SQL Server-Datenbanken. Wie gehen wir also vor Wir migrieren die Access-Datenbanken zum SQL Server und bauen dann ein Entity Data Model auf Basis dieser Datenbank. Es geht allerdings auch anders: Sie könnten auch ein paar Routinen in VBA schreiben, die ein Entity Data Model direkt aus Access heraus auf Basis des gewünschten Datenmodells erzeugen. Dieser Artikel zeigt, wie letztere Möglichkeit funktioniert.

Als Beispiel habe ich eine kleine Bestellverwaltung zusammengestellt, welche die wesentlichen Tabellen enthält (siehe Bild 1).

Bild 1: Beispiel für ein zu migrierendes Datenmodell

Ziel ist es, aus diesem Datenmodell und den enthaltenen Daten ein Entity Data Model mit je einer Klasse für jede Tabelle und einer Liste der benötigten DbSet-Auflistungen zu erstellen.

Außerdem wollen wir die Befehle für eine Seed-Methode zusammenstellen, die notwendig ist, um die Daten aus den Access-Tabellen dann beim Initialisieren des Entity Data Models in die zu erstellende Datenbank zu schreiben. Die Grundlagen zur Initialisierung einer Datenbank finden Sie im Artikel Entity Framework: Datenbankinitialisierung.

Was wollen wir also genau tun Wir möchten beispielsweise für die Tabelle tblAnreden, deren Entwurf Sie in Bild 2 sehen, zwei Dinge erzeugen:

Bild 2: Zu migrierende Tabelle

• die Definition einer Klasse und
• die Definition eines DbSet-Objekts.

Die Klassendefinition soll beispielsweise wie folgt aussehen:

Public Class Anrede
     Public Property AnredeID As System.Int32
     Public Property Anrede As System.String
End Class

Die Definition des DbSet-Objekts lautet so:

Public Overridable Property Anreden() As DbSet(Of Anrede)

Hier würden wir von einer automatischen Erfassung des Tabellennamens, der Felder und des Primärschlüssels ausgehen und von ein paar Anpassungen, um die Migration einigermaßen tauglich zu gestalten und beispielsweise nicht das Präfix tbl mitzuschleppen. Wir sehen hier, dass die Klasse beispielsweise Anrede heißt. Diese Bezeichnung können wir nur schwer aus dem Tabellennamen extrahieren, also holen wir ihn aus dem Namen des Primärschlüsselfeldes (hier AnredeID), von dem wir lediglich den Zusatz ID entfernen. Die beiden Felder belassen wir im ersten Schritt bei AnredeID und Anrede. Optimaler wäre beispielsweise ID und Name. Ersteres, weil wir in der objektorientierten Programmierung etwa über . auf die Eigenschaften einer Entität zugreifen und Anrede.AnredeID schlicht redundante Daten enthält – Anrede.ID wäre viel schöner. Und Anrede.Anrede ist ebenfalls optimierungsfähig. Für die Deklaration des DbSet-Objekts verwenden wir aktuell den Namen der Tabelle ohne das Präfix tbl und für den Typ der im DbSet enthaltenen Daten verwenden wir wieder den aus dem Primärschlüsselfeld ermittelten Namen, also Anrede. Gerade bei den Bezeichnern für die DbSets und die Entitäten muss man darauf achten, ob sich Plural und Singular unterscheiden. Das ist beispielsweise bei Artikel schwierig (ein Artikel/zwei Artikel), weshalb man, wenn man schon weiß, dass man mal objektorientiert mit dem Datenmodell seiner Datenbank arbeiten möchte, besser gleich eine Bezeichnung wie Produkt/Produkte verwendet. In unserer Beispieldatenbank verwenden wir aber weiter tblArtikel, gerade weil wir auch zeigen wollen, wie Sie solche Probleme durch Umbenennungen lösen können.

Beispieldatenbank

Die Beispieldatenbank enthält die im Beziehungen-Fenster von Access abgebildeten Tabellen und Beziehungen. Diese wollen wir nun, möglichst ohne manuellen Eingriff, in die entsprechenden Entitäten und DbSets umwandeln. Dazu können wir zwei Wege gehen: Entweder wir greifen von einem Visual Studio-Projekt aus auf die Datenbank zu oder wir bauen unsere Routinen direkt in der Access-Datenbank. Mir selbst geht VBA beim Zugriff auf Tabellen, Felder, Beziehungen und so weiter immer noch viel schneller von der Hand als mit VB oder C#. Außerdem wäre der Zugriff, wie er für das Auslesen der Access-Tabellen nötig wäre, eine Technik, die wir prinzipiell unter .NET nicht mehr benötigen – hier wollen wir Datenbanksysteme wie SQL Server oder SQLite nutzen, auf die wir mit dem Entity Framework zugreifen können.

Außerdem dürfte das Programmieren von Routinen, die uns aus dem Access-Datenmodell ein Entity Data Model macht, mit einer Menge Testen und Ändern verbunden sein. Das geht unter Access wesentlich schneller und komfortabler als in Visual Studio. In Access schreiben wir einfach die Prozeduren und klicken auf F5, um diese auszuführen, in Visual Studio müssten wir immer das Projekt neu starten, die Ausführung prüfen, das Projekt wieder beenden, den Code anpassen und das Ganze immer wieder von vorn beginnen. Also entscheiden wir uns in diesem Fall für die ältere, aber pragmatischere Vorgehensweise.

.NET-Projekt zum Testen vorbereiten

Damit wir die gleich unter Access generierten Klassen im .NET-Projekt auf ihre Tauglichkeit prüfen können, legen wir gleich ein neues Projekt des Typs VB|WPF-App mit dem Namen AccessZuEF an. Diesem fügen wir ein neues Objekt des Typs ADO.NET Entity Data Model namens BestellverwaltungContext mit dem Typ Leeres Code First-Modell hinzu. Dies legt automatisch die Klasse BestellverwaltungContext.vb für uns an, der wir dann gleich unsere Liste der DbSet-Elemente hinzufügen können. Der Einfachheit halber packen wir unsere Class-Elemente zum Testen auch erst einmal hier herein.

Zugriff auf die Tabellen, Felder und Beziehungen