Access-o-Mania

Access-Forum (Deutsch/German) => Tabelle/Abfrage => Thema gestartet von: Borge am August 21, 2011, 01:45:19

Titel: Datenbankstruktur - Beginner
Beitrag von: Borge am August 21, 2011, 01:45:19
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)


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]
Titel: Re: Datenbankstruktur - Beginner
Beitrag von: DF6GL am August 22, 2011, 14:26:48
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.

Titel: Re: Datenbankstruktur - Beginner
Beitrag von: Borge am August 23, 2011, 17:03:48
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...


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.

Titel: Re: Datenbankstruktur - Beginner
Beitrag von: DF6GL am August 23, 2011, 18:25:46
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)