Unsere Datenschutzrichtlinie wird in Kürze aktualisiert. Bitte sehen Sie sich die Vorschau an.

Access: Datenbank-Coaching – Beispiel Kundenverwaltung

Aufgabenstellung und Ziel erläutern

Testen Sie unsere 2019 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
Die ursprüngliche, einfache Tabelle kann die gewünschten Aufgaben des Überblicks über die Kunden und deren Ansprechpartner nicht mehr erfüllen. Weder mehrere Ansprechpartner sind dabei möglich, noch die Nutzung für unabhängige Serienbriefe oder die Protokollierung von Gesprächen.

Transkript

Das Projekt, was ich heute in eine Datenbank umwandeln möchte mit Ihrer Hilfe, ist so millionenfach verbreitet, dass ich sicher sein kann, dass das auch bei Ihnen irgendwie existiert. Ein irgendwie geachteter Kundenüberblick beginnt meistens mit einer Excel-Liste, da trägt man sich kurz den Namen und die Telefonnummer des Kunden ein, später wird das um die Adresse erweitert, dann kommt noch eine Spalte für den Ansprechpartner hinzu, und eigentlich war es mal ursprünglich eine Liste von Kunden, mehr nicht. Aber durch diese Erweiterung stehen da jetzt auch schon Ansprechpartner drin und zwar leider mehrere. Na ja, macht ja nichts, denn Excel kann man einfach mehrere Daten in einen Feld schreiben, die Telefonnummern auch irgendwie noch dazu und Handynummer und Fax, und wenn es mehrere Telefonnummern gibt, gibt es zur Not eine Spalte Telefon 1, Telefon 2, Telefon 3. Das führt relativ schnell zu Problem, und wenn Sie dann noch sagen, ich schreibe meinen Kunden Serienbriefe beispielsweise, da kann man in einem Excel einfach eine Spalte machen, da kommt ein X an den Kunden, der jetzt diesen Serienbrief erhalten soll, kann man das schon filtern und als Datengrundlage benutzen. Dann werden Sie spätestens feststellen, wen Sie den nächsten Serienbrief schreiben und neue X-e machen und also löschen, dass Sie die Historie nicht vermerken können, Sie können also nach dem nächsten Serienbrief nicht mehr nachgucken, wer hat den Vorherigen bekommen. Natürlich können Sie eine Kopie von der Liste machen, und das ist meistens sowieso das Problem, diese listen werden von Kollegen kopiert, als parallele Liste geführt, auch die Kollegen selber reichen die dann weiter, manche führen sogar auf ihrem eigenen Arbeitsplatz mehrere solche Listen mit den leichen Firmen, und sei es nur für die Serienbriefe oder für die verschiedenen Ansprechpartner früher und heute. Und wenn wir sowieso schon dabei sind, so ein kleines Kundenkontakt-System aufzubauen, dann kann man eigentlich auch richtig die Gespräche protokollieren und nicht in einer Spalte einfach zusätzlich noch zu notieren, was Sie beim letzten Mal mit diesem Kunden besprochen haben, denn Sie haben leider nicht dabei notiert, mit welchem der Ansprechpartner Sie, möglicherweise sogar wann gesprochen haben, und selbst wenn Sie in einem Feld mehrere solche Einträge machen, dann fängt es an wirklich unübersichtlich zu werden. Es sollte also dringend aus dieser flachen Excelliste wegen der gestiegenen Anforderung, und damit auch mehrere damit arbeiten können, eine relationale Datenbank werden, zum Beispiel mit Access. Da ist auch der Mehrbenutzerzugriff einfaher, die ganzen Formulare, die Bedienungsoberflächen sind handlicher, und vor allem bestimmte Sachen gehen wesentlich besser, um nicht zu sagen nur dort, in einer relationalen Datenbank statt in einer flachen Excelliste. Das bedeutet natürlich nicht, dass Sie jetzt einfach die Exceltabelle nach Access rüberexportieren und sagen ich bin fertig, dann haben Sie aus alten Fehlern neue Fehler gemacht, sondern bei diesem Umbau müssen Sie sich natürlich an die üblichen Regeln für relationale Datenbanken halten, die dort nicht Regeln, sondern Normalformen heißen. Glücklicherweise gibt es ja nur 3, deswegen können wir die kurz einmal ind Gedächtnis rufen. Die Normalform Nummer 1 ist die sogenannte Unteilbarkeit. Atomisierung, das ist nur das Gleiche auf Griechisch, können Sie das auch nennen. Das bedeutet mehrere Inhalte in einem einzigen Feld sind nicht erlaubt. Und schon das wird so oft verletzt, dass es erstaunlich ist, dass es niemandem auffällt, gibt ein eiziges Feld, da stehen die Namen mehrerer Ansprechpartner drin. Das ist eine Verletzung dieser Regel, denn nach denen können Sie nicht vernünftig filtern. Genau so gut können Sie mehrere Telefonnummern in einen Feld schreiben, auch das ist teilbar und damit verboten. Dabei ist es egal, ob Sie gleiche Inhalte hineinschreiben, also Telefonnummer 1, Telefonnummer 2, Telefonnummer 3 oder unterschiedliche, Vorname, Nachname. Gehört auch nicht in einem Feld, auch wenn es häufig so gemacht wird. Wenn Sie die in irgendeiner Form später getrennt brauchen und sei es nur, um im Serienbrief sehr geehrter Herr+Nachname, sehr geehrte Frau+Nachname schreiben zu dürfen, dann müssen Sie die getrennt speichern. In einem einzigen Feld können Sie nur hoffen, dass es immer das zweite Wort ist, was den Nachnamen beschreibt, und da nicht Johan Sebastian Bach drinsteht, den würden Sie da nämlich leider falsch trennen. Also die erste Normalform Unteilbarkeit, keine mehrfachen Daten in einem einzigen Feld. Die zweite Normalform lässt sich kurz beschreiben als Redundanz oder sagen wir besser nicht Redunddanz. Sie heißt ausführlich, dass Daten, die von einem Feld des gleichen Datensatzes abhängig sind, nicht in der gleichen Tabelle gespeichert sein dürfen. Der Klassiker ist zum Beispiel ein Nettopreis, der Mehrwertsteuersatz und der Bruttopreis. Die sind voneinander abhängig, entweder Sie haben Netto und Mehrwertsteuersatz, dann können Sie den Bruttopreis errechnen, oder Sie haben meinentwegen den Brutto- und den Nettowert, dann können Sie die Differenz, den Steuerprozentwert daraus errechnen, einer von den dreien ist immer zu viel. Genau so gut und so offensichtlich, wie eigentlich auch unauffällig ist die Postleitzahl und der Ort in der gleichen Tabelle verboten. Die Postleitzahl ist eindeutig, daraus kann man anhand einer Liste nachgucken, wie der Ort heißt. Andernfalls würde ich, sagen wir die Postleitzahl 52099, die in Aachen liegt, und den Ort München zusammenspeichern. Das ist inhaltlich falsch, aber technisch dann möglich. Ich muss also dafür sorgen, dass Daten, die voneinander abhängig sind, getrennt werden. Das eindeutige Erkennungsfeld, zum Beispiel die Postleitzahl, bleibt in der Tabelle, das Andere wandert in eine sogenannte Nachschlagetabelle, wo ich dann anhand der Liste aller Postleitzahlen den eindeutigen Ort ermitteln kann. Also die zweite Normalform Redundanz sagt, Felder die voneinander abhängig sind, müssen getrennt werden. Und schließlich die dritte Normalform, die sich kurz als Historie bezeichnen lässt, die klingt erstmal sehr ähnlich, die sagt nämlich Daten, die indirekt von anderen Werten abhängig sind, dürfen nicht in der gleichen Tabelle geseichert sein. Das klingt erstmal sehr ähnlich, wie die zweite Normalform, das Zauberwort dabei ist indirekt. Zum Beispiel eine Tabelle mit Artikel. Da stehen die Artikelbezeichnungen und deren Preise drin, das sieht ganz selbstverständlich aus, sowie es in jeder Artikel-Preisliste vorkommt. Nur wenn Sie später den Preis ändern, können Sie anhand der Artikel nicht mehr den ursprünglichen Preis rekonstruieren, aber Sie haben möglicherweise Verkäufer zu dem dameiligen Preis getätigt. Das heißt Sie müssen den Preis auslagern in eine zeitorganisierte Tabelle. Das heißt zu dem Artikel gibt es eine Angabe, seit diesem Datum hat er diesen Preis, und der gleiche Artikel seit dem nächsten Datum einen neuen Preis, und drittes Datum wieder einen neuen Preis. Das ist aufwendig und lästig, aber es hilft nichts, Sie brauchen, wenn Sie es korrekt machen mit der Historie immer die Möglichkeit vorherige Daten zu rekonstruieren, wenn Sie auf die Bezug genommen haben. Wenn Sie Anfang des Jahres die Artikel zu einem früheren Preis verkauft haben beispielsweise, dann ist es wichtig, dass Sie den Preis auch wiederherstellen, auslesen undrekonstruieren können. Also diese 3 Normalformen haben wir: die Atomisierung, die Unteilbarkeit, die Redundanz und die Historie. Und damit sollte es eigentlich ganz einfach sein, sich die Excelliste anzugucken und so zu überarbeiten, dass sie den Anforderungen einer relationalen Datenbank entspricht.

Access: Datenbank-Coaching – Beispiel Kundenverwaltung

Aufgaben und Lösungen für den Datenbankentwurf. Diesmal am Beispiel einer einfachen Kundenliste, die zu einem Datenmodell für die Kundenverwaltung weiterentwickelt wird.

1 Std. 0 min (20 Videos)
Derzeit sind keine Feedbacks vorhanden...
 
Hersteller:
Exklusiv für Abo-Kunden
Erscheinungsdatum:25.08.2016

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!