Datenbank-Konzept (Bitte um Korrektur)

[cujo]

Hallo, liebe Datenbank-Spezialisten

Mein letztes Konzept ist schon eine ganze Weile her, und ich finde irgendwie keine Fehler mehr, obwohl irgendwas nicht stimmt (ich habe die starke Vermutung, daß bei den Artikeltabellen ein Fehler gemacht wurde). Umsetzung mit Access 2000, das reicht so...

Könnt ihr bitte mal einen Blick darauf werfen? Falls doch keine Fehler gefunden werden sollten, wäre ich für Verbesserungsvorschläge sehr dankbar.

Hab's einfach aus dem Editor kopiert, "Anrede" und "Bundesland" sind nicht dabei, aber ich denke, das ist für die Fehlersuche nicht relevant. Wenn noch wichtige Informationen fehlen sollten, bitte melden!

Primärschlüssel:

KUNDEN_TAB = Kunden-Nr

RECHNUNG_TAB = Rechnungs-Nr

RECHNUNGDETAIL_TAB = R_Position

LIEFERANT_TAB = Lieferanten-Nr

BESTELLUNG_TAB = Bestell-Nr

BESTELLUNGDETAIL_TAB = B_Position

BANKEN_TAB = Bank_ID

ARTKATEGORIE_TAB = ArtKategorie_ID

ARTDETAIL_TAB = ArtDetail-Nr

ARTIKEL_TAB = Artikel-Nr

[SIZE=2]	KUNDEN_TAB			RECHNUNG_TAB			RECHNUNGDETAIL_TAB			LIEFERANT_TAB


	Kunden-Nr ---------------	Rechnungs-Nr ------------	R_Position			 ------	Lieferanten-Nr

	Anrede_ID		-------	Kunden-Nr		-------	Rechnungs-Nr			|	Anrede_ID

	Vorname				Rechnungsdatum			Artikel-Nr -------------	|	Vorname

	Name				Verpackung		 ------	Bestell-Nr		|	|	Name

	Strasse				MwStSatz		|	Menge			|	|	Strasse

	Hausnummer			MwSt			|	EinzelpreisVK		|	|	Hausnummer

	PLZ				Versandkosten		|	R_Rabatt		|	|	PLZ

	Ort				Rechnungssumme		|	Gesamt			|	|	Ort

	Bundesland_ID			Bezahlt			|				|	|	Bundesland_ID

	TelefonPrivat						|				|	|	TelefonPrivatKD

	TelefonGeschaeft					|				|	|	TelefonGewerbKD

	Mobiltelefon						|				|	|	Mobiltelefon

	Mail							|				|	|	Mail

	MailFPrint						|				|	|	MailFPrint

	Internet			BESTELLUNG_TAB		|	BESTELLUNGDETAIL_TAB	|	|	Internet

	AngelegtAm					      	|				|	|	KDNrPrivat

    ---	Bank_ID				Bestell-Nr -------------	B_Position		|	|	KDNrGewerb

   |	Kontonummer			Kunden-Nr		-------	Bestell-Nr		|	|	Kontaktpersonen

   |	AufRechnung			Bestelldatum			Bezeichnung		|	|	Bank_ID --------

   |	BarNachnahme			ZusageBis			Menge			|	|	Kontonummer	|

   |	Vorkasse			Bemerkungen			DetailInfoKD		|	|	AngelegtAm	|

   |	Bemerkungen			Erledigt			B_Rabatt		|	|	AufRechung	|

   |												|	|	BarNachname	|

   |												|	|	Vorkasse	|

   |												|	|	Bemerkungen	|

   |												|	|			|

   |	BANKEN_TAB	ARTKATEGORIE_TAB	ARTDETAIL_TAB		ARTIKEL_TAB		|	|			|

   |												|	|			|

    ---	Bank_ID		ArtKategorie_ID	---	ArtDetail-Nr	 ------	Artikel-Nr -------------	|			|

   |	Name		Kategorie	   |	Artikel-Nr -------	Lieferanten-Nr -----------------			|

   |			Bemerkungen	   |	Bezeichnung		EinzelpreisEK						|

   |					    ---	ArtKategorie_ID		AngelegtAm						|

   |					    ---	Qualitaet_ID		ArtikelNrFremd						|

   |			QUALITAET_TAB	   |	Abbildung		LetzeAenderungAm					|

   |					   |											|

   |			Qualitaet_ID ------											|

   |			Bewertung												|

   |																|

    ----------------------------------------------------------------------------------------------------------------------------[/SIZE]

Vielen Dank für eure Zeit!

Gruß, cujo

[Schwarzl]

Ich weiß nicht, ob das vielleicht bei dir so geplant ist, aber bei diesen Tabellen bekommst du große Redundanzen, falls du mehrere Artikel auf einer Rechnung stehen haben willst (n:m Beziehung). Um diese aufzulösen würde ich dir eine Zwischentabelle (zwischen Rechnungdetail_tab und Artikel_tab) empfehlen. 2. Normalform ist das glaub ich. Also eine Tabelle dazwischen mit den Spalten Rechnungs-Nr und Artikel-Nr

Gruß

Schwarzl

[beetFreeQ]

Ich weiß nicht, ob das vielleicht bei dir so geplant ist, aber bei diesen Tabellen bekommst du große Redundanzen, falls du mehrere Artikel auf einer Rechnung stehen haben willst (n:m Beziehung). Um diese aufzulösen würde ich dir eine Zwischentabelle (zwischen Rechnungdetail_tab und Artikel_tab) empfehlen. 2. Normalform ist das glaub ich. Also eine Tabelle dazwischen mit den Spalten Rechnungs-Nr und Artikel-Nr

Gruß

Schwarzl

Das verstehe ich nicht ganz - die Tabelle Rechnungsdetail enthält doch die Rechnungspositionen - und ich glaube, eine einzelne Position wird nur einen Artikel haben können - bei einer Rechnung mit mehreren Positionen sind so ja aber problemlos mehrere Artikel möglich... - die Tabelle Rechnungsdetail ist ja schon die Kreuztabelle zwischen Artikel und Rechnung...

[mme]

Ja, der Einwand von Schwarzl ist aus meiner Sicht unbegründet...

Aber z.B. an dieser Stelle solltest du dir Gedanken über die Historisierung machen (abhängig von deinen Anforderungen). Denn die Artikelbezeichnung steht ja warscheinlich auf der Rechnung. Was ist wenn du eine Rechnung erstellst und dann wird die Artikelbezeichnung leicht geändert (z.B. von "Schrauben" auf "kleine Schrauben") dann ist die Beschreibung auf einem Rechnungsnachdruck auch anders. Oder wird immer eine neue Artikelnummer vergeben wenn eine Änderung an den Artikeln gemacht wird?

Gleiches gilt natürlich an anderen Stellen auch. (Ein Kundenadresse ändert sich und du willst wissen ob die letzte Rechnung noch an die alte oder schon an die neue Adresse gegangen ist...)

Ausserdem fehlt eine Beziehung zwischen Bestellung und Kunde.

Der Verweis von Rechnungdetail zu Bestellung ist ungenau, da du im Detailsatz auf die Gesamte Bestellung (die ja auch mehrere Positionen hat) verweist. Wenn, würde ich noch das Feld B_Position in Rechnungsdetails aufnehmen und mit Bestellungedetail verknüpfen.

Und ich würde bei Bestellungdetail und auch bei Rechnungdetail die Felder Position nicht als Primärschlüssel nehmen, da jede Rechnung eigentlich mit der Position 1 anfängt und du dann aber eine fortlaufende Nummer brauchst. Also würde ich Position immer bei 1 anfangen lassen und den Primärschlüssel als zusammengesetzten Primärschlüssel aus Position und R-Nr bzw. B-Nr machen.

Arbeite davon mal das ein was du glaubst anhand deiner Anforderungen zu brauchen und Poste das dann nochmal...

Grüße mme

[mme]

Ach und noch was...

Ich würde mir überlegen, ob ich nicht alle Personendaten/Firmendaten in eine Tabelle mache. Da ein Kunde manchmal auch Lieferant sein kann.

Dann würde ich eine laufende Nummer als ID nehmen und irgendwo ein (oder zwei) Kennzeichen setzten ob dieser Datensatz kunde, Lieferant oder beides ist.

[Schwarzl]

Das verstehe ich nicht ganz - die Tabelle Rechnungsdetail enthält doch die Rechnungspositionen - und ich glaube, eine einzelne Position wird nur einen Artikel haben können - bei einer Rechnung mit mehreren Positionen sind so ja aber problemlos mehrere Artikel möglich... - die Tabelle Rechnungsdetail ist ja schon die Kreuztabelle zwischen Artikel und Rechnung...

Jup, da hast du Recht. Da hatte ich wohl einen kleinen Denkfehler.

Sorry

[geloescht_JesterDay]

Aber z.B. an dieser Stelle solltest du dir Gedanken über die Historisierung machen (abhängig von deinen Anforderungen). Denn die Artikelbezeichnung steht ja warscheinlich auf der Rechnung. Was ist wenn du eine Rechnung erstellst und dann wird die Artikelbezeichnung leicht geändert (z.B. von "Schrauben" auf "kleine Schrauben") dann ist die Beschreibung auf einem Rechnungsnachdruck auch anders. Oder wird immer eine neue Artikelnummer vergeben wenn eine Änderung an den Artikeln gemacht wird?

Gleiches gilt natürlich an anderen Stellen auch. (Ein Kundenadresse ändert sich und du willst wissen ob die letzte Rechnung noch an die alte oder schon an die neue Adresse gegangen ist...)

Ich finde die Struktur wie sie ist ok. Was du vorschlägst ist ja praktisch jeweils eine Kopie der Artikelsätze bzw. des Kundensatzes für jede Rechnung. Natürlich wäre das in den von dir genannten Fällen ok, aber sowas braucht man in der Realität kaum oder nie. Ich habe hier ein solches System, was für jede Rechnung einen neuen Satz (bzw. neue Sätze) schreibt und dort praktisch eine Kopie anlegt und ich finde das ist nicht gut.

Es muss eben vorgegeben werden, dass wenn sich ein Artikel ändert, also richtig ändert, es eine neue Nummer gibt. Das sollte ja kein Problem sein und auch bei NAchbestellungen o.ä., wo der Kunde nur die Artikelnummer kennt, kann es dann keine Probleme geben. eine einfache Korrektur in der Bezeichnung, kommt erstens wohl nur bei Schreibfehlern o.ä. vor und zweitens, wenn doch mal aus anderem Grund, dann aus einem wichtigen. Dann ist es dir auch egal, was auf alten Rechnungen mal stand, anhand der nummer kannst du davon ausgehen, dass es derselbe Artikel ist, weil die ja eindeutig ist.

Und auch wenn sich die Adresse ändert, weisst du ja, wann die Rechnung geschickt wurde und wann sich die Änderung zugetragen hat. Also kannst du auch wissen, wohin sie gegangen ist. Und wenn du das nicht weisst, normalerweise gibt es bei der Post einen Nachsendeauftrag bzw. die Post kommt zurück. Es kann dir also egal sein. Auf der Rechnung steht die Adresse vom Kunden, und nicht die, die er irgendwann mal gehabt hat. Falls du sie also nochmal drucken willst, musst du nicht erst noch eine Adressprüfung machen.

Wenn bei uns z.B. eine Rechnung zurückkommt, weil die Adresse falsch ist und der Kunde sie so nicht annehmen will, dann wird die Adresse des Kunden korrigiert und dann eine neue REchnung gedruckt. Und jedesmal kommt dann jemand zu mir und erzählt mir das und ist verwundert, warum auf der Rechnung noch die falsche Adresse steht. (Das Programm und die DB ist nicht von mir )

Ich kann dir nur empfehlen, es so nicht zu machen, es sei denn, du hast wirklich wichtige Gründe, warum das unbedingt so sein muss.

[mme]

Es gibt noch eine Zwischenlösung.

Du musst nicht für jede Rechnung die Artikeldaten speichern, sondern du Speicherst beim Artikel von wan bis wann diese "Version" des Artikels gültig ist. Dann schaust du anhand des Rechnungsdatums was genommen werden soll.

Vielleicht war mein Biespiel nicht oben nicht so gut. Nehmen wir lieber den Preis anstatt die Beschreibung. Zum 1.09.2005 erhöht sich der Preis um 5€. Dafür generierst du dann einen komplett neuen Artikel?

Oder jemand hat die alte Rechnung verloren usw. und will nun ne neue und bekommt den höheren Preis, welcher Kunde akzeptiert das denn?

(Oder du willst gucken was der Kunde vor einem Jahr für den gleichen Artikel für einen Preis bezahlt hat, nur leider steht auf der Rechnung bei Aufruf nur der aktuelle Preis...)

Mit der Adresse kannst du auch einen gültigkeitszeitraum angeben. Es wird die Adresse des Rechnungsdatums genommen. Sollte das Rechnungsdatum in der Vergangenheit liegen, sollte das Programm gucken ob es etwas neues gibt und dich daraufhinweisen. Dann generierst du die Rechnungeinfach neu mit dem aktuellen Datum und schon hast du die aktuelle Adresse.

Besser ist das meiner Meinung schon, die Frage ist nur welche Anforderungen bestehen und wie die Geschäftsprozesse sind, sodas dies entsprechend genutzt wird...

[Aquano]

Mit der Gültigkeit geht es aber auch viel einfacher. Du speicherst einen Artikel mit einem Timestamp (Trigger) ab. Diesen Timestamp ordnet man den Artikeln der Rechnung zu. Ändert sich am Artikel was wird ein neuer Satz eingestellt. PK liegt über Id und Timestamp.

[cujo]

Vielen Dank erstmal für die konstruktiven Beiträge!

Was ist wenn du eine Rechnung erstellst und dann wird die Artikelbezeichnung leicht geändert (z.B. von "Schrauben" auf "kleine Schrauben") dann ist die Beschreibung auf einem Rechnungsnachdruck auch anders. Oder wird immer eine neue Artikelnummer vergeben wenn eine Änderung an den Artikeln gemacht wird?

Gleiches gilt natürlich an anderen Stellen auch. (Ein Kundenadresse ändert sich und du willst wissen ob die letzte Rechnung noch an die alte oder schon an die neue Adresse gegangen ist...)

Üner dieses Problem habe ich auch nachgedacht, allerdings bin ich zu dem Schluß gekommen, daß ein derart komplizierter Aufbau (der eine leichte Änderung des EK-Preises oder der Beschreibung in einem neuen Datensatz berücksichtigt) durch eine Speicherung der Rechnung als "Druckdokument" umgangen werden kann. Um zu verhindern, daß ich wegen jeder Änderung eines Artikels eine neue Artikel-Nr vergeben muß, gibt es in meiner Tabelle ARTIKEL_TAB ja zwei Spalten - "EinzelpreisEK" und "LetzteAenderungAm". Wenn der Kunde eine erneute Ausgabe "seiner" Rechnung mit den alten Preisen und Beschreibungen wünscht, greife ich auf das Druckdokument zurück (z.B. PDF), da ich diese ja ohnehin speichern muß (ist das ein Denkfehler?).

Der Verweis von Rechnungdetail zu Bestellung ist ungenau, da du im Detailsatz auf die Gesamte Bestellung (die ja auch mehrere Positionen hat) verweist. Wenn, würde ich noch das Feld B_Position in Rechnungsdetails aufnehmen und mit Bestellungedetail verknüpfen.

Das leuchtet mir ein, aber würde das nicht zu großen Redundanzen und Verwirrung führen? Wenn der Kunde z.B. mehr oder weniger Artikel bekommt, als in der Bestellung XY eigentlich aufgeführt? Ich habe eben gedacht, daß der Verweis, um welche Bestellung es sich handelt, ausreicht.

Und ich würde bei Bestellungdetail und auch bei Rechnungdetail die Felder Position nicht als Primärschlüssel nehmen, da jede Rechnung eigentlich mit der Position 1 anfängt und du dann aber eine fortlaufende Nummer brauchst. Also würde ich Position immer bei 1 anfangen lassen und den Primärschlüssel als zusammengesetzten Primärschlüssel aus Position und R-Nr bzw. B-Nr machen.

Stimmt, das habe ich gar nicht bedacht...er zählt ja nur die Positionen bei jeder Rechnung wieder "von 1", wenn ich einen zusammengesetzten Primärschlüssel setze, nicht?

Eine Zusammenführung der Lieferanten und der Kunden erscheint mir nicht sinnvoll, da ich dadurch ja keine Vorteile erhalte...ich müßte ohnehin zwei Datensätze anlegen, wenn Kunde XY gleichzeitig privater und gewerblicher Kunde ist (die meisten haben beispielsweise ein privates und ein geschäftliches Konto, verschiedene Anreden und Namen - privat: "Wolfgang Mustermann", geschäftlich: "Firma WEISSNICHT"). Ich müßte dann die zusammengeführte Tabelle so erweitern, daß mir die Trennung keine Vorteile mehr bringt. Mail, Fingerprint, Kontodaten, erlaubte Zahlungsmethoden usw., alles doppelt...

Fallen euch noch logische Fehler auf, insbesondere bei den Rechnungs- und Artikeltabellen? Falsche Beziehungen bei den Primärschlüsseln (die zwischen Kunde und Bestellung hab' ich einfach nur vergessen, sorry)?

Danke nochmal

Gruß, cujo

[mme]

...durch eine Speicherung der Rechnung als "Druckdokument" umgangen werden kann.

Klar kann man so machen, aber du hast dann keine Möglichkeit detalierte Auswertungen zu machen (z.B. wieviel Umsatz mit Klopapier hatten wir mit dem einen Kunden. Es geht dann nur der Gesamtumsatz des Kunden). Aber wenn du das nicht brauchst, super.

Das leuchtet mir ein, aber würde das nicht zu großen Redundanzen und Verwirrung führen? Wenn der Kunde z.B. mehr oder weniger Artikel bekommt, als in der Bestellung XY eigentlich aufgeführt? Ich habe eben gedacht, daß der Verweis, um welche Bestellung es sich handelt, ausreicht.

Ja stimmt, aber dann würde ich den Verweis auf die Bestellung nicht bei jedem Artikel aufhängen sondern einmal für die ganze Rechnung. Da kann man aber wieder sagen was ist wenn er mehrere Bestellungen mit einer Rechnung geliefert bekommt.... (Bei uns würden dann auch zwei Rechnungen geschrieben) Also abhängig von deinen Geschäftsprozessen.

Eine Zusammenführung der Lieferanten und der Kunden erscheint mir nicht sinnvoll, da ich dadurch ja keine Vorteile erhalte...ich müßte ohnehin zwei Datensätze anlegen, wenn Kunde XY gleichzeitig privater und gewerblicher Kunde ist (die meisten haben beispielsweise ein privates und ein geschäftliches Konto, verschiedene Anreden und Namen - privat: "Wolfgang Mustermann", geschäftlich: "Firma WEISSNICHT"). Ich müßte dann die zusammengeführte Tabelle so erweitern, daß mir die Trennung keine Vorteile mehr bringt. Mail, Fingerprint, Kontodaten, erlaubte Zahlungsmethoden usw., alles doppelt...

Ich bezog das nicht auf Privater und Geschäftlicher Kunde, hier macht mein vorschlag nur Sinn, wenn du tatsächlich Kunden hast, wo Kunde und Lieferant tatsächlich identisch sind. Hast du sowas nicht hast du auch keine Vorteile...

Ach und das mit dem zusammengesetzen Primärschlüssel gilt auch für die Tabelle Artdetail...

[Bubble]

Ich finde die Struktur wie sie ist ok. Was du vorschlägst ist ja praktisch jeweils eine Kopie der Artikelsätze bzw. des Kundensatzes für jede Rechnung. Natürlich wäre das in den von dir genannten Fällen ok, aber sowas braucht man in der Realität kaum oder nie. Ich habe hier ein solches System, was für jede Rechnung einen neuen Satz (bzw. neue Sätze) schreibt und dort praktisch eine Kopie anlegt und ich finde das ist nicht gut.

Soweit ich weiss muss eine Rechnung nach der Erstellung unabänderlich sein, d.h. es ist zwingend erforderlich von allen Daten, insbesondere auch der Kundenanschrift, eine Kopie zu erstellen, die die zum Zeitpunkt der Rechnungserstellung gültigen Daten enthält. Unbedingt fachkundigen (=rechtskundigen) Rat einholen und nachfragen, ob die angedachte Vorgehensweise in Ordnung ist und bei einer Überprüfung (Steuer, usw.) keine Probleme verursacht.

[mme]

Nur lösbar durch tiff erstellung o.ä.

[geloescht_JesterDay]

Soweit ich weiss muss eine Rechnung nach der Erstellung unabänderlich sein, d.h. es ist zwingend erforderlich von allen Daten, insbesondere auch der Kundenanschrift, eine Kopie zu erstellen, die die zum Zeitpunkt der Rechnungserstellung gültigen Daten enthält.

Weiss ich jetzt nicht, aber bei uns wird bei jeder Rechnungserstellung die Rechnung eh 2mal gedruckt, 1mal Kunde und 1mal Akte. Also von der Dokumentation her ist das ja damit erledigt.

[cujo]

...bei uns wird bei jeder Rechnungserstellung die Rechnung eh 2mal gedruckt, 1mal Kunde und 1mal Akte. Also von der Dokumentation her ist das ja damit erledigt.

Ja, so habe ich mir das auch gedacht. Ich werde euch jetzt einfach vertrauen und loslegen (richtig, ich setze auf eure Kompetenz)

Wenn mit den Testdatensätzen Probleme auftreten, poste ich nochmal. Danke an alle.

Gruß, cujo

[cujo]

Hallo nochmal,

mein erstes Problem ist wahrscheinlich recht simpel, aber ich komme einfach nicht auf die Lösung (Google gibt mir nicht das, was ich finden will, und in meinem Access-Buch konnte ich keine Hinweise finden):

Ich hatte ja vor, in der Tabelle RECHNUNGDETAIL_TAB die Spalte "R_Position" nicht nur als Primärschlüssel der Tabelle (es ist, wie mir ja geraten wurde, ein zusammengesetzter Schlüssel aus "Rechnungs-Nr" und "R_Position"), sondern auch als Positionsnummer in meinen Rechnungen zu verwenden, will sagen: bei jeder neuen Rechnung wieder als Zähler von 1.

Jetzt habe ich mal ein wenig mit Testdaten experimentiert (Formular aus RECHNUNG_TAB mit Unterformular aus RECHNUNGDETAIL_TAB) und leider scheint es so nicht zu funktionieren.

Ergebnis (Beispiel):

Rechnungs-Nr: 15150

Position: 1

Position: 2

Rechnungs-Nr: 15151

Position: 3

Position: 4

Na schön, die Spalte ist ja ein AutoWert, zählt also ganz ganz normal weiter...daraufhin habe ich diesen Thread

gefunden - allerdings hätte ich nicht gedacht, daß VBA erforderlich ist, um das zu lösen.

Ich glaube, mein Problem resultiert aus einem Denkfehler. Was habe ich da falsch gemacht?

Vielen Dank, cujo

[mme]

Meiner Meinung hast du keinen Denkfehler... das Feld darf einfach kein Autowert sein, sondern muss vom Anwender oder automatisch im Formular gefüllt werden. Wenn du es automatisch im Formular machen willst, kommst du an vba wohl nicht vorbei.