Datenbankstruktur - Beginner

[Borge]

Hallo Zusammen,

ich wüßte gerne ob ich meine Datenbank (Access 2010) weit genug aufgelöst habe und würde mich freuen wenn sich das mal jemand anschauen könnte.

Ursprünglich war ich mit meiner Frage in einem verkehrten Bereich, darum poste ich hier jetzt noch einmal. Ich hoffe es ist okay wenn ich öfter Nachfrage und in für mich kleinen Schritten vorgehe. Klar wäre es klasse eine komplette Antwort einfach vorgesetzt zu bekommen. Jedoch würde ich dadurch nichts lernen und darum geht es mir letztlich ja. 

Bei den Beziehungen hoffe ich das diese so stimmen. Ich hab das Gefühl je nach dem wie ich Frage ändert sich die Beziehung immer wieder ins Gegenteil... 

Ziel ist ausschließlich die einmalige Erfassung von Neukunden! Sobald alle Daten vom Kunden vorliegen, passiert mit den hier erfassten Daten nichts mehr. (Abgesehen von Berichten und Abfragen)

• 
  Erfasst werden Einträge von Firmen- und Privatdaten (inkl. Geburtstag, Telefon etc)
  
• 
  Erfassen von Geschäftsdaten (Z.B. Ladengröße). Sortiment und Umsatzträger sind reine Textfelder
  
• 
  Dazu die möglichen Liefertage und Zeite von Kundenseite. Z.B. Mo-Fr von 8:00 - 12:30 Uhr und 13:00 Uhr bis 18:00 Uhr (Wegen der Mittagspause) oder Mo,Mi,Fr 12:00 bis 20:00 Uhr.
  
• 
  Das Sortiment dient dazu einen groben Überblick zu bekommen und besteht aus Ja/Nein-Feldern.
  
• 
  Rechnung und Abbuchungsauftrag bestehen aus Ja/Nein-Feldern und Datumfelder. Hier geht es nicht um Rechnungsnummern. Sondern nur um ein Formular welches dem Kunden zugeschickt wird, wo er sich z.B. bereit erklärt die Rechnung per E-Mail zu erhalten. Selbiges gilt  für den Abbuchungsauftrag.
  
• 
  Interne Daten sind quasi die Checkliste damit nichts vergessen wurde. Die Internen Daten werden bis zur endgültigen Kundenanlage immer wieder aktualisiert, da man ja z.B. nicht am gleichen Tag einen Abbuchungsauftrag auf dem  Postwege zurück erhält.
  
• 
  Wenn alles durch ist, erhält der Kunde eine Tour zugewiesen. Hier kann er mehrere Touren erhalten. TKK (Tiefkühl) z.B. am Montag und Donnerstag, eine Food-Tour am Samstag.
  

Des Weiteren erhalte ich beim aufmachen immer die Meldung das im Navigationsformular ein Makro mit verkehrtem Namen eingetragen wurde. Ich hab vorher mit Navigationsformularen experimentiert und finde nun das Makro zum löschen nicht.

Ich hoffe ich konnte das so einigermaßen erklären was ich damit bezwecken möchte. Würde mich freuen wenn sich das einer von Euch ansehen könnte.

Danke im Voraus!
Borge

[Anhang gelöscht durch Administrator]

[DF6GL]

Hallo,

mhmm,   da ist vermutlich noch Einiges an Nachbearbeitung/Veränderung nötig.  Anhand der Beziehungen erschliesst sich mir nicht die Aufgabe der DB.


"Firmenanschrift"  sollen vermutlich die Kunden insgesamt sein. Was dazu die Tabellen Privatanschrift, Namen, Anschrift für eine Rolle spielen sollen, ist mir unklar.  Ein DS in "Namen" oder auch "Privatanschrift"  kann doch nicht für viele verschiedene  "Firmenanschriften"  (Kunden) gelten ??

Das Gleiche gilt für "Geschäftsdaten" und "Interne_Daten", deren Felder allesamt in "Firmenanschrift" (Kunden) gehören.  Nur bei "Sortimente" (wobei diese Tabelle noch zu normalisieren wäre) kann ich mir vorstellen, dass ein bestimmtes Sortiment  für mehrere Kunden gelten könnte.


Genauso müssten "Touren", "Rechnungen" und Abbuchungsauftrag mit der Tabelle Firmaenanschrift nicht in 1-n, sondern n-1-Beziehung stehen.

Die Tabelle "Uhrzeit" wäre nur dann sinnvoll, wenn eine in vorgegebenen Schritten eingeteilte Tageszeit jeweils ausgewählt werden soll.

[Borge]

Hallo und Danke für deine Antwort.

Die DB soll rein zur Erfassung von Neukunden sein. Sobald alle Daten zusammen sind (Kd-Nr, Tour etc) wird mit den Daten nichts weiter gemacht. Höchstens über Berichte ausgewertet wieviele Kunden sich in welchem Zeitraum gemeldet haben und welche Kunden noch nicht vollständig angelegt sind (z.B. weil der Gewerbeschein fehlt).
Mein erster Entwurf war wohl dermassen daneben das mir gesagt wurde er wäre unbrauchbar. Also habe ich mich noch mal an das Thema "Normalisierung" gesetzt und bin dabei vielleicht ein wenig übers Ziel hinausgeschossen...

• Zuerst sollen die Daten der Firma erfasst werden. Von daher hast du mit deiner Vermutung recht das es sich hier um den Kunden handelt. Meine Beschriftung war da nicht ganz eindeutig.
• Die Privatanschrift wird benötigt um bei Einzelunternehmen eine Kreditabfrage machen zu können. Sprich alle Kunden welche keine Kapitalgesellschaft (AG, GmbH etc.) sind.
• Anschrift, Namen, PLZ und Anrede habe ich soweit aufgeschlüsselt da ich den Normalisierungsprozess so verstanden habe. Wenn ich die wieder zusammenfassen kann, wird alles für mich natürlich wieder übersichtlicher.
  Den Namen habe ich hier aufgeschlüsselt da zumindest der Nachname doppelt vorkommen kann. Bsp: Ein Einzelunternehmer "Martin Müller" betreibt das Geschäft. Ansprechpartner ist seine Frau Julia Müller.
• Die Uhrzeit habe ich gewählt, da ich ja die Zeiten eintragen wollte zu dennen der Kunde beliefert werden kann. Hier könnte ich natürlich auch auf ein einfaches Textfeld zurück greifen.
• Die Tage habe ich aufgeschlüsselt da der Kunde seine Wunschliefertage angeben soll und die Logistik mir dann bescheid sagt an welchen Tagen der Kunde angeliefert werden kann...
• Rechnung + Abbuchungsauftrag habe ich mit bei den Internen Daten da es sich hier nur um eine Checkliste handelt welche Punkte alle abgefragt wurden. Rechnung heißt in dem Fall nicht das der Kunde eine Rechnung mit Rechnungsnummer, Artikel und Betrag erhält, sondern nur das der Kunde ein Formular zugeschickt bekommen hat, welches er dann unterschrieben  zurück schickt.
• Sortimente habe ich nicht weiter normalisiert, weil es hier nur um die dort eingetragenen Gruppen geht. Also ein grober Überblick woran der Kunde interesse hat (als ja/nein-feld). Es gibt also keine Untergliederung (z.B. bei Eis noch Magnum, Capri oder Flutschfinger) und somit auch keine Artikel-Nr..

Die Beziehungen werde ich noch mal überarbeiten. Du meinst es macht also Sinn einige Tabellen wieder zusammen zu führen? zB. Plz, Anschrift, Name, Anrede und Tag.

[DF6GL]

Hallo,

"übers Ziel hinausgeschossen"  , ja, in zweierlei Hinsicht: Zuviel Tabellen und "verdrehte" Beziehungen.. 


1) Benn die Tabellen in Form einer "Überschrift"  für den sinngemäßen Inhalt der Tabelle..  also, wenn Kunden definiert werden, eben "tblKunden"
2) Wenn es zu einem Kunden nur eine Privatanschrift geben kann, dann ist es überflüssig, eine extra Tabelle zu spendieren. Setz die Felder gleich in "tblKunden" und benenne die entspr. und eindeutig.
3) Selbst wenn es einen Vor-/Nachnamen zweimal in tblKunden geben sollte, ist dafür eine extra (Auswahl-, bzw. Stamm-)Tabelle eher überkandidelt.  Normalisierung sollte man nicht bis zur Vergasung treiben, nur soweit, wie es die akt. Anwendung erfordert. (Ich selber verfechte stark die Normalisierungsregeln) aber in Deinem Fall ist für die Namen das nur Ballast.  Als "Kompromiss" zur komfortablen Eingabe des Nachnamens (wie bei Deinem Beispiel "xxx Müller") kann man auch eine Auswahl aus den schon gespeicherten Nachnamen des Kunden realisieren.  Wenn Du hier "Ansprechpartner" ansprichst, muss aber die Frage gleich gestellt werden, ob es nur einen oder mehrere Ansprechpartner bei einem Kunden geben soll/darf. In solchen Fäallen wäre eine weitere Tabelle "tblKundenansprechpartner" (die Tabellenamen können auch kürzer gehalten werden, wenn sie trotzdem die inhaltlichen Sinn beschreiben--> "tblKuAnPa")
4) Uhrzeit(en) aus einer Tabelle auswählbar bereitzustellen, ist eher nicht komfortabel, wenn jede möglichliche Uhrzeit (Zeitpunkt) im Minutentakt möglich sein soll.  Sind die Uhrzeiten im Viertel- oder Halbstundentakt nur zulässig, oder auch nur bestimmte Zeitbereiche innerhalb eines Tages, dann wäre die "tblUhrzeit" schon  erforderlich.
5) Bei den Tagen ist eine Auswahltabelle vertretbar.
6) Was heißt denn "intern" ? Alle Deine Daten sind "intern". Ich versteh hier noch nicht den Sinn, der damit bearbeit werden soll. Wenn nur registriert werden soll, ob der Kunde eine (Papier-Rechnungs-)Formular zugeschickt bekommen hat, dann wäre dafür ein Datumsfeld ("ReGeschicktAm", resp. "AbAufGeschicktAm") ausreichend. Wenn auch das Rücksendedatum erfasst werden muss, dann eben zweizusätzliche Datums-Felder, z. B. "ReRetourAm" ,bzw. "AbAufRetorAm".
7) Bei den Sortimenten unterstütze ich nicht die  fehlende Normalisierung. Man könnte das so machen, aber das geht nur solange gut, wie es nur und nur die akt. vorhandenen Artikelkategorien  gibt. Klar verführt ein "Klickbereich" im Formular dazu, schnell die entspr. Artikelgruppen anzuklicken und damit zu definieren, aber der Bummerang kommt bei o. g. Situation von neuen/anderen Artikelgruppen UND  bei der Auswertung der Daten.

Mein Vorschlag an Tabellen (beim bisherigen Daten-Kenntnisstand):

tblKunden  (alles, was einen Kunden auszeichnet)
tblAnsprechpartner (alle Ansprechpartner zu einen bestimmten Kunden)
tblAnreden (alle möglichen Anreden, wobei da auch Anreden für verschiedene "Anlässe" enthalten sein können, z. B. Briefadress-Anrede, Ansprech-Anrede, etc) 
(tblUhrzeiten) (falls wie o. g. Zeitabschnitte, bzw. -schritte definiert werden müssen)
tblTagesnamen (alle zulässigen Tagesnamen)
tblArtikelgruppen (Auswahltabelle mit allen akt. möglichen Artikelgruppen)
tblKundenArtikelgruppen (Zuordnung der Artikelgruppen zu einem bestimmten Kunden)