Grundlegende Datenbankstruktur

[MarkusR]

Hallo Ihr Profis,

ich möchte eine neue Datenbank erstellen. Diese Datenbank soll der Bearbeitung aller Abläufe bezüglich Bestellungen von Kunden dienen. Heißt:

- eine Tabelle mit Angeboten
- eine Tabelle mit Aufträgen
- eine Tabelle Kunden
- eine Tabelle mit Rechnungen
- eine Tabelle mit Bestellungen die wir tätigen (für Material und Dienstleistungen, die wir extern vergeben)
usw.

Ich habe also mehrere Tabellen erstellt (mit Primärschlüsseln) und diese in Beziehung zu einander gesetzt. Als nächstes erstelle ich alle Eingabeformulare.

Meine große Frage ist jetzt, wie man am besten das Hauptformular mit den Aufträgen aufbaut.
Klar, erst einmal alle auftragsbezogenen Daten, die man ja in der Auftragstabelle speichert (Bestellnummer, Artikelnummer, Liefertermin usw.). Wenn ich jetzt in einem Datensatz bin, z.B. die Bestellung 12345, soll er mir aus der Angebotstabelle den Preis anzeigen, der dort für diesen Artikel hinterlegt ist.
Meine erste Überlegung war jetzt, dass ich ein Textfeld im Hauptformular erstelle, in das ich per VBA per DLookup den Wert aus der Angebote Tabelle eintragen lasse. Also habe ich beim Formular unter der Eigenschaft "Beim Anzeigen" den Code dafür hinterlegt.
Aber angenommen ich habe 3000 Aufträge in der Tabelle, dann würde der das ja jedesmal, wenn ich die Datenbank öffne, für alle Felder nachrechnen, oder? Das würde doch bei so vielen Feldern wie ich brauche (ca. 200 pro Datensatz), ne Menge Zeit bei 3000 Datensätzen brauchen, oder?
Die andere Überlegung war, mit Unterformularen zu arbeiten. Aber dann müsste ich ja für jedes von den 200 Feldern ein Unterformular erstellen und hätte zudem den Nachteil, dass ich im geteilten Formular beim Datenblatt die Felder auch nicht sehen würde.

Wie also stellt man sowas am besten an? Für Eure Hilfe wäre ich Euch sehr sehr dankbar 

Beste Grüße,
Markus

[MzKlMu]

Hallo,
bei 200 Feldern habe ich erhebliche Zweifel am Datenmodell. Wozu sind das 200 Felder? Ich denke hier fehlen auch noch einige Tabellen.
Lasse die Formulare beiseite, die machen noch keinen Sinn, erst muss die Struktur stimmen.
Erst mal noch folgende Fragen:

- wie unterscheiden sich die Tabellen für Angebot und Auftrag?
- kann ein Auftrag mehrere Produkte/Artikel umfassen?
- gleiche Frage für das Angebot
- kann es Teilrechnungen geben?

Es ist eine Tabelle für das Material erforderlich.
Weiterhin eine Tabelle für die Dienstleistungen (falls feststehende Leistungen)

Dann fehlen auch n:m Zwischentabellen für die Angebotspositionen, für die Auftragspositionen, für die Bestellpositionen Material und für die Bestellpositionen Dienstleistung.

Ich sehe hier noch mindestens 6 fehlende Tabellen.

DLookup solltest Du auch vergessen, das wird hier nicht benötigt.
Und der aktuelle Preis muss redundant gespeichert werden sonst stimmen ja alte Aufträge nicht wenn sich der Preis ändert. Der aktuelle Preis gehört auch in die Produkt/Materialtabelle und nicht in das Angebot/Auftrag. Dort kommt der Preis wie gesagt zusätzlich rein.
Mache zum jetztigen Zeitpunkt nicht mit den Formularen weiter, es wäre für die Katz.

[oma]

Hallo Markus,


nur mal als Anregung: Ich habe das für ein Unternehmen andes gelöst: Es gibt nur eine Tabelle: tblAufträge. Diese Tabelle enthält Angebote u. Aufträge gleichermaßen.
Ein Angebot wird mit Angebotsdatum u. Status "Offen" geschrieben u. nach evtl. Bestätigung dann  mit AuftragsBeginn und Status "Auftrag"  versehen oder auch als Erledigungsdatum und Status "Ablehnung"
So sind alle möglichen Positionen alle in einer Tabelle ---> in einem Formular und man kan mit einfachen Klicken sich verschieden Optionen herstellen (Offene Angebote, laufende Aufrtäge, abgelehnte Angebote usw.
als auch zahlreiche Recherchen durchführen.

Kann natürlich sein, das deine Datenstruktur bei Angebot und Aufträge dass nicht zulässt, musst mal überprüfen

Gruß Oma

PS: Nach den Hinweisen von Klaus; Stelle doch mal dein gesamtes Tabellenkonzept mit den Feldern und den Verknüpfungen dar.
Eine Grundregel: Kümmere dich nicht um Formulare , Abfragen, Berichtsgestaltung u.a bevor nicht das Datenkonzepz steht. Der Rest geht dann von alleine

[MzKlMu]

Hallo,

@Oma
das mit einer Tabelle für Auftrag und Angebot war auch der Hintergrund meiner Frage wie sich beide Tabellen unterscheiden.
Wenn er wie gesagt den Preis aus dem Angebot holen will (was aber nicht richtig ist) darf sich Angebot und Auftrag nicht unterscheiden. Also genügt eine Tabelle.

[oma]

Hallo

@Klaus: jo, sorry, hatte dein Beitrag beim Schreiben nicht gelesen

Gruß Oma

[database]

Hallo,

@Klaus, @Oma

Ich finde beide eurer Varianten und Vorschläge passend - aber:
Ich darf vielleicht an der Stelle hinzufügen, dass die Gestaltung (und speziell die einer Auftrags-DB) nicht nur von Normalisierungsregeln abhängig ist sondern auch von jeweiligen Geschäftsmodell.
Was ja nun nicht bedeuten soll, dass dabei die Normalisierung zu kurz kommen soll / darf.

Kann natürlich sein, das deine Datenstruktur bei Angebot und Aufträge dass nicht zulässt, musst mal überprüfen

Es gibt durchaus Unternehmen, die für die Angebotslegung einen aktuellen Artikelpreis 'nur' als Grundlage der Angebotslegung heranziehen.

...wie gesagt den Preis aus dem Angebot holen will (was aber nicht richtig ist)...

Dabei kann der Angebotspreis eines Artikels / einer Dienstleistung für unterschiedliche Kunden in Abhängigkeit der angewendeten Margen (z.B. für A,B, oder C-Kunden)
trotzt eines aktuellen Artikelpreises auch unterschiedlich ausfallen.
Was aber dann auch bedeutet, dass der Preis aus dem Angebot den primären Status gegenüber dem gespeicherten Artikelpreis besitzt.
Eine gewollte Denormalisierung läßt dann die redundante Datenhaltung des Preises in einer Tabelle für Angebote und Aufträge zu.
Ja Klaus, - ich kann dich hören - klar läßt sich der anzuwendende Preis aus aktuellem Preis und Angebotsmarge jederzeit neu berechnen. 

Persönlich würde ich aber dennoch die tabellenmäßige Trennung von Angeboten und Aufträgen mit zusätzlicher Redundanz der Preise bevorzugen.
Aber wie schon angesprochen - in Abhängigkeit des jeweiligen Geschäftsmodells kann es da zu unterschiedlichen Auslegungsvarianten kommen.

Und der aktuelle Preis muss redundant gespeichert werden sonst stimmen ja alte Aufträge nicht wenn sich der Preis ändert

Dazu würde ich anregen sich zusätzlich über eine Preishistory (der Artikel und Dienstleistungen) Gedanken zu machen.
Klaus hat schon früher in vielen Beiträgen mehrfach dazu Stellung bezogen.
Zur Angebotserstellung soll/darf ja nur der aktuelle Preis herangezogen werden.

[oma]

Hallo,

natürlich muss die gleichzeitige Speicherung von Angebotsdaten und Auftragsdaten in einer Tabelle sorgfältig vom Geschäftsmodell geprüft werden.
Und hierzu gibt es natürlich auch noch verschiedene Varianten. So können z.B. verschiedene Preise gespeichert werden (aktueller Artikelpreis, Angebotspreis, berechneter(festgelegter) Auftragspreis usw.)
Ich wollte nur, das Markus einmal Überlegungen in dieser Richtung anstellt...

Gruß Oma

[database]

Hallo,

@Oma, @Klaus
Bitte meinen Beitrag NICHT als negative Kritik an euren bereits abgegebenen Statements zu sehen!
Gleiches gilt natürlich auch im Zusammenhang mit dem Anregungen und Beiträgen von Klaus!

Ich wollte nur, das Markus einmal Überlegungen in dieser Richtung anstellt...

Wollte damit eher dem TO (auch) zu euren Anregungen passende 'Überlegungsanregungen' liefern.

Insgesamt ist es m.M. nach recht schwierig zu solchen Anfragen von Anfang an passende/richtige Ratschläge zu geben,
die dann auf Anhieb auf das dahinter stehende Geschäftsmodell anwendbar sind - meist kann es aus den Anfragen
leider nur erahnt werden - da es in diesen ja kaum einmal konkret angesprochen oder dargestellt wird.

[MarkusR]

Guten Morgen zusammen,

erst einmal vielen Dank für Eure Anregungen.

Ja, natürlich ist jedes Geschäftsmodell anders und es gibt keine non-plus-ultra-Lösung. Vielleicht erläuter ich einfach noch ein bisschen:

Bisher arbeiten wir mit einer Access Datenbank, die auf einer Tabelle basiert (abgesehen von einer Tabelle mit Rechnungen). In diese Tabelle wird jeder Auftrag eingepflegt. Zu jedem Auftrag haben wir eine riesige Menge an Daten:
Kunde, Bestellnummer, Bestelldatum, AB-Nummer, AB-Datum, ZielterminA, ZielterminB, Liefertermin, Menge, Artikel, Artikelnummer, Zeichnungsnummer, Bearbeitungsart, Kommentar, Rechnungsnr, -datum & -kommentar, Lieferscheinnr, -datum & -kommentar, Prüfzahl von, Prüfzahl bis, externe Bearbeitung, Kontrollkästchen für Sofortrabbat 2% / 5% / 6%, Material Lieferant / Liefertermin / EK pro Stück / Aufschlag pro Stück / Material Art / Material Durchmesser 5x / Material Länge 5x / Material Wareneingang, für 10 verschiedene Maschinen jeweils Felder für Mitarbeiter, Rüstzeit, Bearbeitungszeit, Programmierzeit, Bearbeitungspreis, Richtkosten, Rüstkosten, Sägekosten, Werkzeugkosten, Sonderkosten, 8 Felder für externe Dienstleister, dazu noch Bestellnummer, Bestelldatum und Lieferscheinnummer, Lieferscheindatum für unsere Bestellungen
usw. usw.

Wie Ihr seht, kommen zu jedem Auftrag eine ganze Menge an Daten zusammen. Somit komme ich jetzt an die Grenzen einer Tabelle mit 200 möglichen Spalten. Und da ich mal was von "Redundanzen vermeiden" gelesen habe, indem man mit mehreren Tabellen arbeitet und doppelt gespeicherte Daten verhindert, kam ich jetzt halt zu diesem Ansatz mit den mehreren Tabellen.
Wir arbeiten zu 90% für einen Kunden. Dieser fragt Artikel an, wir geben ein Angebot ab, der Kunde bestellt. Den Artikel kann er natürlich auch öfters bestellen. Wir bekommen jetzt noch Bestellungen von Artikeln, die wir vor mehreren Jahren angeboten haben. In solchen Fällen machen wir natürlich auf die Bestellung hin ein neues Angebot mit einem aktuellen Preis (da ja die Bearbeitungskosten steigen und sich auch die Materialpreise verändern). Somit hat ein Angebot also nur so lange Gültigkeit, bis wir ein neues Angebot für diesen Artikel abgeben, ABER wir wollen natürlich auch eine Preishistorie haben um immer zu sehen, wie sich die Preise entwickeln etc.

Soweit unsere Grundlagen. Zu den Fragen von MzKlMu:
1. Bei Angeboten trage ich alle Preise ein, von interner Bearbeitung, über benötigtes Material, wer das anbietet und zu welchem Preis, bis hin zu den Angeboten von externen Dienstleistern. Mit ins Angebot kommt natürlich, von wann die Anfrage ist, über wieviel Stück zu welchem Liefertermin, wann wir das Angebot abgeben und welchen Liefertermin wir anbieten.
In die Auftragstabelle kommen dann halt die Daten, wie es der Kunde bestellt. Dann halt nur die Preise, die auch benötigt werden (also nur die von dem Material Lieferanten, bei dem wir auch tatsächlich bestellen).
2. Ein Auftrag ist immer nur über einen Artikel. Es kann höchstens vorkommen, dass ein Auftrag über zwei oder mehr Liefertermine gesplittet wird.
3. Beim Angebot ist es genauso.
4. Wenn Du mit Teilrechnungen meinst, dass es zu einem Auftrag zwei oder mehr Rechnungen geben kann, dann ja. Weil es wie gesagt vorkommt, dass ein Auftrag auf mehrere Liefertermine gesplittet wird. Abgerechnet wird aber immer jede Lieferung. (Andersherum können wir natürlich auf eine Rechnung mehrere Aufträge schreiben)

Was sind denn n:m Tabellen?

@oma:
Deine Idee mit dem Status eines Datensatzes find ich super. Aber wie oben beschrieben, komme ich leider an die Grenzen mit den 200 Feldern, womit das dann wohl leider nicht möglich ist.

Grüße, Markus

[MzKlMu]

Hallo,
das Datenmodell dürfte bei den geschilderten Feldern völlig daneben liegen.

Material Durchmesser 5x / Material Länge 5x

>eigene Tabelle mit 1-n Datensätzen keine 5 Felder

für 10 verschiedene Maschinen jeweils Felder für Mitarbeiter, Rüstzeit, Bearbeitungszeit, Programmierzeit, Bearbeitungspreis, Richtkosten, Rüstkosten, Sägekosten, Werkzeugkosten, Sonderkosten,

Auch grundsätzlich völlig falsch.
Hier ist eine Tabelle erforderlich für die Zeiten in einem Feld, zusätzlich eine Feld für die Maschine (als Fremdschlüssel) und die Zeitart (ebenfalls als Fremdschlüssel aus einer extra Tabelle). Sowie ein Feld für den Schlüssel des Mitarbeiters. 10 Maschinen zu je 9 Zeiten ergeben dann 90 Datensätze in dieser Tabelle und keine 90 Felder.

8 Felder für externe Dienstleister,

Auch in eine extra Tabelle mit den jeweiligen Details immer ein neuer Datensatz. Das sind alles n:m Tabellen.
Wenn Du nicht weist, was eine n:m Beziehung ist, solltet Du Dich unbedingt mit den Grundlagen zu Access beschäftigen.
Wenn Teilrechnungen zugelassen sind, ist auch für die Teilrechnungen eine eigene Tabelle erforderlich.

Hier ist noch eine ziemliche Aufgabe zu bewältigen, so kann es auf keinen Fall bleiben, wenn Du mit Access weiter machen willst.