Teil 6: Datenbanken und Datenmodellierung für Entwickler im Überblick

Einführung in die Programmierung: Daten, Daten, Daten
Kommentare

Enterprise-Anwendungen dienen hauptsächlich der Datenverarbeitung. Deren Basis sind Datenbanken. Als Entwickler muss man daher mit den Konzepten der Datenbanktheorie vertraut sein. Begriffe wie Datenmodellierung, relationales Schema und Normalisierung dürfen keine Schweißperlen auf der Stirn hervorrufen. Im Rahmen des letzten Teils dieser Artikelserie erhalten Sie einen kompakten Überblick über das Thema.

Im Unternehmensumfeld (Enterprise-Segment) sind Datenbankapplikationen das bestimmende Thema der Softwareentwicklung. Dabei ist man als Entwickler oft gar nicht in der Situation, eine Datenbank von Grund auf neu zu gestalten. Vielmehr entwickelt man Applikationen, die einen entsprechenden Zugriff auf die Datenhaltungssysteme, meist eine Datenbank in Form eines Datenbankservers, herstellen.

Aber auch wenn man als künftiger Softwareentwickler in einem ganz anderen Segment tätig sein möchte, kommen die Konzepte und Technologien von Datenbanken zum Einsatz. Betrachtet man in diesem Zusammenhang zum Beispiel das Tätigkeitsfeld der App-Programmierung für Smartphones und Tablets, so greifen auch diese kleinen Applikationen meist auf Datenbanken zurück. Auf diesem Weg werden die Nutzer mit Informationen versorgt oder können Geschäftsvorgänge bearbeiten.

Grund genug also, sich bereits zu Beginn der Karriere als künftiger Softwareentwickler mit diesem wichtigen Thema auseinanderzusetzen. Das Thema ist komplex und umfassend, sodass es nicht gelingt, es im Rahmen eines Artikels auch nur annähernd erschöpfend abzudecken. Das ist auch nicht das Ziel. Der Leser erhält dafür einen kompakten Einblick in die Welt der Datenbanken und somit eine Einstiegshilfe. Die weitere Auseinandersetzung mit den Fragestellungen wird dann der Fachliteratur überlassen. Beginnen wir mit der notwendigen Theorie.

Was ist eine Datenbank?

In einer Datenbank werden Daten abgespeichert. Konkret kann man definieren: Eine Datenbank ist eine logisch zusammenhängende Sammlung von Daten, die einen Ausschnitt aus der realen Welt beschreiben. Um welche Art von Daten es geht, ist dabei zunächst nicht von Interesse. In der Kundendatenbank werden die Merkmale der Kunden (Name, Anschrift, Kommunikationsdaten, …) gespeichert. Eine Datenbank zur Verwaltung von Buchungsaufträgen im Hotel umfasst die Daten zu den Aufenthalten der Gäste.

Es spielt hier auch keine Rolle, auf welche Art und Weise die Informationen abgelegt werden. Sehr häufig – da werden wir noch ausführlich darauf zurückkommen – erfolgt dies in Tabellenform. Aber auch die Sammlung von einzelnen Dokumenten, auf die man beispielsweise mittels Stichworte zugreifen kann, ist eine Datenbank. Das Softwaresystem (i. d. R. mehrere Programme), das dem Benutzer das Erstellen und die Pflege einer Datenbank ermöglicht, bezeichnet man als Datenbankmanagementsystem (Abb. 1). Die eben angesprochene Verwaltung der Daten in Tabellenform wird als so genannte relationale Datenbank bezeichnet. Tabelle 1 gibt einen kompakten Überblick über die verschiedenen Datenbanktypen.

 

Abb. 1: Die Datenbank wird mittels Datenbankmanagementsystem erstellt und gepflegt [1]

Abb. 1: Die Datenbank wird mittels Datenbankmanagementsystem erstellt und gepflegt [1]

Tabelle 1: Typen von Datenbanken

Tabelle 1: Typen von Datenbanken

Aufgrund der Bedeutung der relationalen Datenbank in der Praxis werden wir uns in den folgenden Textabschnitten mit dieser Form der Datenhaltung beschäftigen. Mögliche Grenzen und Nachteile einer relationalen Datenbank kann man erst dann erkennen und ggf. einen Bedarf nach anderen konzeptionellen Ansätzen daraus ableiten, wenn man sich ausführlich damit auseinandergesetzt hat. Wie bereits ausgeführt, basieren die meisten Datenbanken im geschäftlichen Umfeld auf diesem Ansatz.

Sichten auf eine Datenbank

Auf eine Datenbank sind unterschiedliche Sichten möglich (Abb. 2). Diese richten sich nach der jeweiligen Aufgabe:

  • Interne Sicht: Die interne Sicht beschäftigt sich mit der physikalischen Anordnung der Daten auf den Datenträgern. Die Daten können auf verschiedenen Rechnern in unterschiedlichen Gebäuden und Städten verteilt sein. Daten, die später als eine Tabelle zu sehen sind, müssen nicht zwangsläufig gemeinsam gespeichert werden.
  • Logische Sicht: Die Gesamtheit aller Daten wird in der logischen Sicht mit ihren Beziehungen dargestellt. In der logischen Sicht setzt das Datenbankdesign ein: Welche Informationseinheiten werden wo verwaltet und welche Beziehungen bestehen zu anderen Daten?
  • Benutzersicht: Stellt die Sicht des Anwenders dar, der nur mit einem Teil der Daten arbeitet. Diese Sichtweise kennt weder den internen Aufbau noch die Gesamtsicht der Datenbank. Der Benutzer hat nur ein Interesse an bestimmten Daten. Die Benutzersicht kann sich wiederum von der internen und der logischen Sicht auf die Datenbank unterscheiden.

 

Abb. 2: Unterschiedliche Sichtweisen auf eine Datenbank [2]

Abb. 2: Unterschiedliche Sichtweisen auf eine Datenbank [2]

Relationale Datenbanken

Das relationale Datenbankmodell wurde 1970 vom Mathematiker E. F. Codd entwickelt und mithilfe der Mengentheorie beschrieben. Es bildet die Basis für relationale Datenbanken. Die wesentlichen Elemente dieses Ansatzes sind:

  • Tabellen (Relationen): In einem relationalen Datenbankdesign muss jedes Objekt in einer Tabelle gespeichert sein. Zwischen den Tabellen können Beziehungen über so genannte Schlüssel hergestellt werden.
  • Eigenschaften (Attribute): Die jeweils zu einem Objekt vorhandenen Informationen werden in Eigenschaften aufgeteilt.
  • Wertebereich (Domänen): Eine Domäne beschreibt den zulässigen Wertebereich eines Attributs. Das können fest vorgegebene Werte, Bereiche oder Mengenangaben bzw. Datentypangaben sein.
  • Tupel: Ein Tupel stellt eine Menge der Attribute eines Objekts, also einen Datensatz, dar. Der Aufbau aller Tupel einer Tabelle ist gleich.
  • Schlüssel (Indizes): Es wird zwischen dem Primär-, Sekundär– und Fremdschlüssel unterschieden. Schlüssel dienen grundsätzlich zur Identifikation eines Datensatzes. Über den Primärschlüssel kann ein Datensatz innerhalb einer Tabelle mithilfe eines Attributs oder mittels einer Kombination aus mehreren Attributen eindeutig identifiziert werden. Der Wert des Primärschlüssels ist normalerweise konstant, d. h., er wird während der gesamten Existenz eines Datensatzes nicht geändert. Häufig sollen die Datensätze einer Tabelle zusätzlich in einer anderen Reihenfolge durchlaufen werden, als das durch den Primärschlüssel vorgegeben ist. Um das zu erreichen, können weitere Schlüssel angelegt werden. Ein Sekundärschlüssel sortiert die Datensätze innerhalb einer Tabelle nach einem weiteren Merkmal und erlaubt ein schnelles Suchen. Ohne Schlüssel müsste bei einem Suchvorgang der gesamte Datenbestand jedes Mal vollständig überprüft werden. Bei sehr umfangreichen Datenbeständen wäre der dafür notwendige Zeitbedarf zu groß. Mittels Fremdschlüssel werden Beziehungen zwischen den Tabellen einer Datenbank hergestellt. Der Fremdschlüssel der einen Tabelle verweist auf den Primärschlüssel in einer anderen Tabelle.

Die Elemente der relationalen Datenbank und deren Zusammenhänge werden verständlich, wenn wir sie uns anhand eines Beispiels ansehen. Zunächst sind jedoch einige Aussagen bezüglich der zu verwaltenden Daten zu treffen. Es geht um Datentypen, die eine ähnliche Bedeutung haben wie die Typen der Variablen bei der Programmierung.

Datentypen

Es macht einen Unterschied, ob man Text (zum Beispiel den Namen eines Kunden), Zahlenwerte (zum Beispiel den Preis eines Produkts) oder Multimediaelemente (zum Beispiel Bilder) in einer Datenbank speichern möchte. Jedes Attribut muss durch einen Datentypen näher charakterisiert werden. Die verfügbaren Datentypen unterscheiden sich zwischen den einzelnen Datenbanken. Daher kann eine vollständige Kompatibilität nicht gewährleistet werden. Das ist insbesondere bei einem Wechsel der Datenbank zu beachten. Es ist sicherzustellen, dass der Import von externen Daten nicht zu Datenverlust bzw. Fehlern führt. Besonders eindeutig ist der Datentransfer bei nicht standardisierten Datentypen wie zum Beispiel Datumswerten nachzuvollziehen.

Folgende wichtige Datentypen sind nahezu für alle Datenbanken verfügbar; deren genaue Bezeichnung und ihr gültiger Wertebereich sind jedoch in der Dokumentation nachzuschlagen:

  • Integer: Ganze Zahl (positiv oder negativ), wobei je nach Anzahl der zur Verfügung stehenden Bits Bezeichnungen wie smallint, tinyint oder bigint verwendet werden. Die jeweiligen Wertebereichsgrenzen und die verwendete Terminologie sind vom Datenbanksystem abhängig.
  • Numeric oder Decimal: Festkommazahl (positiv oder negativ) mit insgesamt maximal n Stellen, davon m Nachkommastellen. Für Geldbeträge ist die gewünschte Genauigkeit (zwei Nachkommastellen) anzugeben.
  • Float: Gleitkommazahl (positiv oder negativ) mit maximal m Nachkommastellen.
  • Real: Gleitkommazahl (positiv oder negativ). Die Genauigkeit für diesen Datentyp wird jeweils vom Datenbanksystem definiert.
  • Float und Double: Sind für technisch-wissenschaftliche Werte geeignet und umfassen auch die Exponentialdarstellung. Wegen der Speicherung im Binärformat sind diese Datentypen aber für Geldbeträge nicht geeignet, da sich beispielsweise der Wert 0,10 Euro (entspricht zehn Cent) nicht exakt abbilden lässt.
  • Character oder char: Zeichenkettetext mit n Zeichen
  • Date: Datum (ohne Zeitangabe).
  • Time: Zeitangabe (eventuell inklusive Zeitzone).
  • Timestamp: Zeitstempel, umfasst Datum und Uhrzeit; eventuell inklusive Zeitzone. Meistens in der Genauigkeit von Millisekunden, teilweise auch mikrosekundengenau.
  • Boolean: Boolesche Variable. Kann die Werte true (wahr) oder false (falsch) annehmen.
  • Blob (Binary Large Object): Binärdaten von maximal n Bytes Länge.
  • Clob (Character Large Object): Zeichenketten mit maximal n Zeichen Länge.

Das Entity Relationship Model (ER-Modell)

Das Schema, in dem man eine Datenbankstruktur konzipiert, nennt sich Entity Relationship Model (ER). In einem ER-Modell wird die grundlegende Tabellen- und Beziehungsstruktur einer Datenbank entworfen und abgebildet. Die Darstellung im ER-Modell (grafisch) und die Abbildung der Datenbankstruktur mithilfe von Tabellen sind äquivalent, d.h., eine gegenseitige Überführung ist möglich (und wird von Entwicklungsumgebungen auch automatisch durchgeführt). Um mit dem ER-Modell arbeiten zu können, sind einige Begriffe zu definieren und in Beziehung zu den Datenbankbegriffen (siehe oben) zu bringen:

  • Attribute: Dabei handelt es sich um die Felder eines Datensatzes.
  • Entität: Es sind die Datensätze.
  • Entitätsmengen: Eine Entitätsmenge entspricht einer Tabelle in der Datenbank.
  • Beziehungen: Die einzelnen Tabellen sind nicht losgelöst voneinander. Zwischen den Entitäten werden Verknüpfungen hergestellt. Eine Beziehung kann einem Beziehungstyp zugeordnet werden. Die wichtigsten Beziehungstypen lauten 1:1, 1:n und n:m-Beziehungen (siehe Tabelle 2)
Tabelle 2: Die Beziehungstypen der Tabellen einer relationalen Datenbank

Tabelle 2: Die Beziehungstypen der Tabellen einer relationalen Datenbank

Es gibt verschiedene Arten, wie die Beziehungstypen in einem ER-Diagramm abgebildet werden. Eine wichtige Form ist die so genannte MIN-MAX-Notation. Dabei wird für jeden an einer Beziehung beteiligten Entitätstyp ein geordnetes Paar mit einem Minimal- und einem Maximalwert angegeben.

Phasen des Datenbankentwurfs

Der Aufbau einer Datenbank gelingt nicht in einem Schritt. Dazu müssen mehrere Phasen durchlaufen werden:

  1. Externe Phase – Ermittlung der Informationsstruktur: Die Datenbank soll einen Ausschnitt aus der realen Welt (auch als „Miniwelt“ bezeichnet) im Rechner abbilden. Diese Abbildung erfolgt durch die Beschreibung der Daten. Dazu ist der Informationsbedarf der Benutzer zu ermitteln und zu strukturieren. Das Ergebnis dieses ersten Schritts – auch als Spezifikations- und Anforderungsanalyse bezeichnet – ist eine informelle Beschreibung des Fachproblems.
  2. Konzeptionelle Phase – Aufstellung des semantischen Modells: Ziel des konzeptionellen Entwurfs ist die formalisierte Beschreibung des betrachteten Sachverhalts. Es existieren verschiedene Ansätze zur Erzeugung einer solchen Gesamtsicht. Das bekannteste Modell ist das ER-Modell. Das Ergebnis dieses Schritts ist das Fachkonzept der Datenbank.
  3. Logische Phase – Erstellung des logischen Datenmodells: Ziel ist die Übertragung des semantischen in ein logisches Datenmodell – zum Beispiel in das relationale Datenmodell. Diese Phase umfasst zwei Schritte: Im ersten Schritt muss eine Transformation des konzeptionellen Schemas (ER-Modell) in das Datenbankschema erfolgen. Dieser Schritt ist mithilfe von Software automatisierbar. Im zweiten Schritt erfolgt eine Optimierung des relationalen Schemas, zum Beispiel die Durchführung einer Normalisierung der Tabellenstruktur.
  4. Physische Phase – Implementierung der Datenbank: Am Ende dieser Phase sollte die leere Datenbank existieren. Dazu sollte das logische Modell unter Verwendung einer Datendefinitionssprache (zum Beispiel SQL) in ein konkretes Datenbankschema übersetzt werden. Es müssen Datentypen, Wertebereiche, Relationen und Sichten festgelegt werden.

Optimierung: Normalisierung des Datenmodells

Die Daten bzw. deren Struktur liegen meist in einer ungeordneten Form vor. Für eine relationale Datenbank muss eine Datenbankstruktur aufgebaut werden, d. h., es muss festgelegt werden, in welcher Form die Daten auf mehrere Tabellen aufgeteilt werden. Das oberste Ziel ist es dabei, die mehrfache Speicherung der gleichen Daten, so genannte Redundanzen (Kasten: „Redundanzen in der Datenbank“) zu vermeiden. Dieser Prozess wird für relationale Datenbanken als Normalisierung bezeichnet. Er besteht aus mehreren Schritten. Am einfachsten zu verstehen ist er, wenn man ihn sich anhand eines einfachen Beispiels ansieht. Es ist besonders sorgfältig vorzugehen, da Fehler in dieser Phase später nur mit sehr viel Aufwand (und Kosten) beseitigt werden können. Schlimmstenfalls kann es zu Dateninkonsistenzen oder zu Datenverlust kommen.

Redundanzen in der Datenbank

Grundsätzlich sind die mehrfache Speicherung der gleichen Daten (Informationen) in der IT – und damit auch in einer Datenbank – unerwünscht. Redundanzen können zu Anomalien, d. h. einander widersprechenden Datenbankinhalten führen.

Ein einfaches Beispiel: Eine Datenbank speichert zu einem Auftrag nicht nur die Kundennummer, sondern auch die Adressdaten des Kunden. Hat der Kunde mehrere Bestellungen geordert, liegen diese Informationen mehrfach (redundant) vor, d. h., jeder Bestellsatz enthält neben den Angaben zur Bestellung auch die Adressdaten.

So weit, so gut! Das Problem entsteht, wenn eine Änderung der Kundendaten durchgeführt wird. Es müssen dann die Adressdaten aller Datensätze des Kunden angepasst werden. Dass dabei etwas vergessen werden kann, liegt auf der Hand. Besser wäre es, die Datenstruktur aufzuteilen und die Kundendaten losgelöst von den Bestellinformationen zu verwalten.

Es gibt auch Situationen, in denen Redundanzen in einer Datenbank explizit erwünscht und ausdrücklich hergestellt werden. Beispielsweise ist es üblich, den Datenbestand parallel auf mehreren Datenbankservern zu halten (zu spiegeln). Bei Ausfall eines Servers kann ein anderer Server dessen Aufgaben nahtlos übernehmen. Die Anwender bekommen dann vom Problem im Idealfall nichts mit.

Auch bei der Anfertigung eines Back-ups wird der komplette Datenbestand oder ein Auszug daraus zu Zwecken der Datensicherung nochmalig an einem anderen Ort gespeichert. Diese beiden Beispiele ändern jedoch nichts daran, dass die grundsätzliche Struktur einer relationalen Datenbank so anzulegen ist, dass eine doppelte Ablage gleicher Daten vermieden wird.

Der Vorgang der Normalisierung kann wie folgt beschrieben werden. Die Schritte können Sie anhand des einfachen Beispiels in Abbildung 3 nachvollziehen.

Abb. 3: Beispiel Normalisierung [3]

Abb. 3: Beispiel Normalisierung

  1. Rohdaten: Nach der Datenerhebung bzw. Ermittlung der relevanten Eigenschaften liegt der Datenbestand in der „Rohform“ vor. Typisch ist, dass Attribute mehrere Werte enthalten. Als Erstes gilt es, dies zu beseitigen. Die Spalte Ort enthält den Eintrag „88959 Musterort“, also Informationen zu Postleitzahl und Ort. Das gilt es, in zwei Datenfelder aufzuspalten. Auch auf das Attribut Name trifft das zu.
  2. Erste Normalform: Eine Relation befindet sich dann in der ersten Normalform (1NF), wenn alle Attribute atomar, also unteilbar, sind. Das Attribut Name wurde in die Attribute Name und Vorname und das Attribut Ort in Postleitzahl und Ort Aber auch jetzt liegt noch kein Idealzustand der Datenstruktur vor. Inhaltlich werden alle Daten in einer Tabelle gehalten. Um einen eindeutigen Primärschlüssel zu bestimmen, müsste man ihn aus mehreren Attributen zusammensetzen.
  3. Zweite Normalform: Eine Relation befindet sich in der zweiten Normalform (2NF), wenn sie in der ersten Normalform ist und jedes Nichtschlüsselattribut vom Primärschlüssel voll funktional abhängig ist. Es ist eine Aufspaltung in drei eigene Tabellen notwendig: die Tabelle „Rechnungen“, die Tabelle „Kunden“ und die Tabelle „Artikel“. Die Tabelle „Kunden“ enthält dabei alle Angaben zu den Kunden und die Tabelle „Artikel“ die Eigenschaften zu den Artikeln. Über die Tabelle „Rechnung“ wird der Zusammenhang hergestellt, d.h. welcher Kunde welche Artikel bestellt hat. Die Struktur der Datenbank hat jetzt erheblich an Qualität gewonnen. Dennoch gibt es noch Verbesserungspotenzial. In der Tabelle „Kunden“ gibt es die Attribute Postleitzahl und Ort. Bei exakter Betrachtung ist über die Postleitzahl der Ort des Kunden stets eindeutig bestimmt, d. h., das Attribut Ort hängt in diesem Fall nicht nur von der KundenNr, sondern gleichzeitig auch vom Attribut Postleitzahl Diese doppelte Abhängigkeit gilt es über die dritte Normalform aufzulösen.
  4. Dritte Normalform: Eine Relation befindet sich in der dritten Normalform (3NF), wenn sie sich bereits in der zweiten Normalform befindet und kein Nichtschlüsselfeld von einem anderen Nichtschlüsselfeld abhängig ist. Um die eben beschriebene doppelte Abhängigkeit aufzulösen, wurde die ursprüngliche Tabelle „Kunden“ in die neue Tabelle „Kunden“ und „Ort“ Alle anderen Tabellen („Artikel“ und „Rechnungen“) bleiben unverändert.

In der Theorie existieren noch Definitionen für Normalformen höherer Ordnung. Für die meisten praktischen Einsatzfälle dürfte jedoch das Erreichen der 3NF ausreichen. Wird der Vorgang der Normalisierung zu weit fortgesetzt (Übernormalisierung), so steigt die Komplexität unnötigerweise.

Auch das Antwortverhalten verschlechtert sich, da bei Abfragen erst eine Vielzahl von Schlüsselverweisen ausgewertet werden müssen und die eigentlichen Informationen auf zu viele Tabellen zerstreut sind. Daher gilt: Mithilfe der Normalisierung sollte ein guter Kompromiss zwischen Systemleistung und Redundanzfreiheit angestrebt werden. Der Einsatz von Werkzeugen aus Datenbanksystemen führt gelegentlich auch zu der beschriebenen Übernormalisierung. Es ist Aufgabe des Datenbankdesigners, das zu erkennen und die Arbeit dieser Tools zu bremsen!

Der Normalisierungsprozess führte – wie dargestellt – zu einer Aufteilung der Daten auf verschiedene Tabellen. Neben den erwähnten Vorteilen ist jedoch bei der Arbeit mit der Datenbank (Abfragen, Transaktionen) der Zustand der so genannten referenziellen Integrität zu beachten. Dazu ein Beispiel: Aus der Tabelle „Kunden“ wird ein Datensatz gelöscht; die anderen Tabellen werden dabei jedoch nicht betrachtet. In der Tabelle „Rechnung“ existieren dann ggf. „verwaiste“ Datensätze, mit dem betreffenden Schlüssel (KundenNr), wenn dieser Umstand nicht beachtet wird. Bei der Durchführung von Transaktionen ist sicherzustellen, dass alle Tabellen entsprechend einer Änderung nachgeführt werden. Datenbankmanagementsysteme leisten dabei sehr gute Unterstützung.

Auch auf einen weiteren Aspekt soll hingewiesen werden: Während des Normalisierungsprozesses werden Tabellen verändert und neue Tabellen angelegt. Bei der Wahl der richtigen Bezeichner sind einige Konventionen zu beachten. Im Allgemeinen sagt man:

  • Der Tabellenname muss die Bedeutung der Einträge wiedergeben.
  • Der Tabellenname muss eindeutig sein.
  • Der Tabellenname soll kurz sein.

Wie bei der Wahl der Klassennamen bei der objektorientierten Programmierung sind die Namen sorgfältig auszuwählen. Dabei ist der inhaltliche Kontext zu beachten.

Anbindung und praktischer Einsatz

Nach dem weitgehenden Verständnis der Datenbanktheorie geht es darum, es in der Programmierpraxis anzuwenden. Alle Frameworks, Klassenbibliotheken und Programmiersprachen bieten entsprechende Konzepte und Schnittstellen zur Kommunikation der Anwendung mit Datenbanken. Ein Ansatz des .NET-Frameworks ist das ADO.NET Entity Framework (EF).

Hier startet man tatsächlich in geänderter Reihenfolge, d. h., man schreibt zunächst den Code (Klassenstruktur) für den Zugriff/Verwaltung der Daten im Programm. Daraus wird dann automatisiert die Datenbankstruktur generiert. Das Wissen um die Datenbanktheorie ist dennoch notwendig. Programmiereinsteiger, die jetzt ihre erste Anwendung mit Anbindung einer Datenbank entwickeln wollen, können also das Stichwort ADO.NET Entity Framework als Einstieg für die weitere Recherche verwenden.

Einen noch direkteren Start in die Entwicklung von datenbankbasierten Applikationen bietet das Werkzeug LightSwitch. Es ist Bestandteil von Visual Studio und erlaubt ein Design der Datenbank, beginnend mit einer Tabellenstruktur. Datenzugriffsschicht und Benutzeroberfläche werden über Assistenten automatisiert erstellt. Der Schwerpunkt liegt in der fachlichen Gestaltung von Datenbankapplikationen; das Tool richtet sich u. a. auch an Fachpersonal in den Unternehmen, die nicht zwingend Softwareentwickler sein müssen. Mit LightSwitch erstellte Anwendungen können jedoch problemlos über Visual Studio weiterentwickelt werden.

Fazit und Ausblick

Sowohl zum Thema Datenbankentwicklung als auch zu den gesamten Inhalten unseres Programmierkurses gäbe es noch viel zu sagen. Nach insgesamt sechs Teilen ist dieser jedoch am Ende angekommen. Zum Softwareentwickler wird man nicht über Nacht! Es bedarf Geduld und einer stetigen Portion Neugier. Suchen Sie sich interessante Anwendungen und setzen Sie diese schrittweise um. Am Anfang ist das Ziel zunächst das Lernen. Am besten gelingt es, wenn die gesteckten Aufgaben nicht allzu groß sind.

Links & Literatur

[1] Elmasri, R.A.: „Grundlagen von Datenbanksystemen“, Bachelorausgabe, Pearson-Studium, 2009
[2] RRZN Handbuch-Team: Access 2013 – Grundlagen für Datenbankentwickler

Entwickler Magazin

Entwickler Magazin abonnierenDieser Artikel ist im Entwickler Magazin erschienen.

Natürlich können Sie das Entwickler Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -