Datenbank Design

[MarkusR]

Hallo zusammen,

ich habe vor einigen Jahren eine Datenbank für unsere Familienfirma erstellt. Mittlerweile ist die ziemlich komplex geworden und ich habe gemerkt, dass ich das von Anfang an falsch angepackt habe.

Die meisten Daten sind in einer Tabelle mit mittlerweile ca. 180 Feldern. Das man da an Grenzen stößt, habe ich jetzt gemerkt. Also ab zu Google und mal ein bisschen damit beschäftigt. So habe ich jetzt ein bisschen über Normalisierung und Vermeidung von Redundanzen gelesen.
Ich bin also jetzt bereit, die Datenbank nochmal komplett neu zu gestalten (und hoffe, dass ich am Ende auch die ganzen Datensätze ordentlich in die neue Datenbank übernehmen kann). Der erste Schritt war jetzt, ein Design zu erstellen: Also alle Daten in zusammenhängende Teile auf zu teilen. Jetzt wollte ich die Tabellen erstellen und bin mir aber nicht ganz sicher. Bisher habe ich es so gehabt, dass ich Felder, die aus anderen Feldern berechnet werden, auch in die Tabelle aufnehme, aber die kann man ja auch im Formular berechnen.

Als Beispiel beim Material: Ich habe ein Feld MatEKSTK (also Einkaufspreis pro Stück) und ein Feld MatAufschlSTK (also Aufschlag pro Stück). Im Formular möchte ich jetzt ein Feld haben MatVKSTK (also Verkaufspreis pro Stück), dass sich aus MatEKSTK und MatAufschlSTK zusammensetzt. Mache ich jetzt einfach ein Textfeld und berechne das darin oder erstelle ich in der Tabelle direkt ein Feld mit der Berechnung?

Für die Datenbankdynamik wäre es wahrscheinlich besser, so wenig Felder in den Tabellen zu machen wie möglich, oder?

Vielen Dank für Eure Meinungen im Voraus!

Gruß, Markus

[Josef P.]

Hallo!

Läuft die Materialdaten-Pflege bei euch wirklich so ab?
Ihr speichert je Materialstamm einen Einkaufspreis und gebt dann manuell den Zuschlag ein?

Wäre es nicht wartungsfreundlicher, wenn man den Materialstamm in Kategorieren ordnet und z. B. je Kategorie einen Zuschlagssatz bestimmt.
Weiteres: Ist der Einkaufspreis immer der zuletzt verwendete Einkaufspreis oder ist das eher ein "Standardpreis" von dem einzelne Bestellungen/Rechnungen abweichen können?
Falls der Verkaufspreis direkt vom Einkaufspreis abhängt: wie sieht das aus, wenn noch Lagerware vorhanden ist, bei einer Zusatzlieferung aber ein neuer Preis gilt? Wird dann jedes Mal das Lager umbewertet?

Tipp: überlege dir zuerst das anzuwendende Geschäftsmodell und baue darauf die Tabellenstruktur auf. Meisten ergibt sich dadurch bereits eine relative gut normalisierte Struktur. Verfeinern im Sinne des Datenmodells kannst du immer noch.  Wichtig ist aber am Anfang, dass die Geschäftsprozesse abwickelbar sind, oder?

mfg
Josef

[MarkusR]

Guten Morgen,

ja, leider läuft das hier so ab. Material bedeutet bei uns Kupfer -> Kupfer hat jeden Tag einen anderen Preis.
Der Ablauf sieht aus wie folgt:

1. Wir bekommen von unserem Hauptkunden einen Auftrag
2. Wir fragen bei unseren Materiallieferanten den aktuellen Preis für das benötigte Material an
3. Preise vergleichen und beim günstigsten bestellen

Somit hat man beim gleichen Artikel im einen Monat einen anderen Preis als im nächsten Monat. Auch der Aufschlag ist unterschiedlich.

Gruß,
Markus

[Josef P.]

Hallo!

Auch der Aufschlag ist unterschiedlich

Wird der geschätzt/"gewürfelt" oder gibt es eine Berechnungsformel dafür?

Hintergrund der Frage: vielleicht kann man die Datenpflege vereinfachen, wenn man z. B. nur noch den Einkaufspreis eingeben müsste und der Rest berechnet werden kann.

Tipp bezüglich Tabelle:
Eine Tabelle für die Materialstammdaten und eine extra Tabelle für die Einkaufspreise zu bestimmten Zeitpunkten bzw. Zeiträumen. Also nicht in der Materialstammtabelle den aktuellen Preis eingeben, sondern in einer extra Tabelle je einen Datensatz je Materialstamm und Datum einfügen. Damit kannst du auch später die Preisentwicklung nachschlagen.

mfg
Josef

[DF6GL]

Hallo,


wenn ich das recht versteh, dann werden IMMER der Tagespreis und auch der Aufschlag außerhalb der DB ermittelt und als unabhängige Werte in der DB ( in der Bestellung(sposition)  ) gespeichert.  Insofern ist keine Pflege der Preise in einer Tabelle erforderlich, wenn keine Preishistorie gewünscht ist.

Im Formular möchte ich jetzt ein Feld haben MatVKSTK (also Verkaufspreis pro Stück), dass sich aus MatEKSTK und MatAufschlSTK zusammensetzt.

Dafür ist lediglich ein berechnentes Textfeld ("MatVKSTK") im Formular (bzw. überall dort, wo die Berechnung erforderlich ist, z. B. in einem Bericht -->Bestellung) nötig, etwa so in der Eigenschaft "Steuerlementinhalt":

Code [Auswählen] Erweitern

=nz([MatEKSTK],0) + nz([MatAufschlSTK],0)

[MarkusR]

Hallo

wenn ich das recht versteh, dann werden IMMER der Tagespreis und auch der Aufschlag außerhalb der DB ermittelt und als unabhängige Werte in der DB ( in der Bestellung(sposition)  ) gespeichert.  Insofern ist keine Pflege der Preise in einer Tabelle erforderlich, wenn keine Preishistorie gewünscht ist.

Ja, genau! Im Normalfall bekommen wir das Material sowieso vom Auftraggeber beigestellt. Nur in wenigen Fällen besorgen wir das selber. Und dann wirds, wie Du schon vermutet hast, außerhalb der DB kalkuliert. Eine Preishistorie sehen wir automatisch, wenn wir nach dem Artikel filtern.

Dafür ist lediglich ein berechnentes Textfeld ("MatVKSTK") im Formular (bzw. überall dort, wo die Berechnung erforderlich ist, z. B. in einem Bericht -->Bestellung) nötig, etwa so in der Eigenschaft "Steuerlementinhalt":

Code [Auswählen] Erweitern

=nz([MatEKSTK],0) + nz([MatAufschlSTK],0)

Wunderbar. Das spart dann auch ne Menge speicher.

Eine anderen Frage:
Ich habe grad mal probiert, Datensätze aus der alten Datenbank in die neue zu kopieren. In der neuen Datenbank habe ich eine Tabelle gemacht, in der alle Angebote gespeichert werden sollen. Zu jeder Zeichnungsnr gibt es nur ein Angebot, somit ist Zeichnungsnr logischerweise mein Primärschlüssel in der Tabelle.
Kopiere ich jetzt die Datensätze der alten Datenbank in die neue, kommt jede Zeichnungsnr einmal, mit den Daten die dazu gehören. Soweit wunderbar.
Bei der Tabelle tabAuftraege setzt sich der Primärschlüssel aus mehreren Feldern zusammen, da die Kombination dieser Felder immer nur einmal vorkommen soll. Jetzt gibt es in der alten Tabelle wohl ein paar Datensätze, wo diese Kombination aber mehrfach vor kommt (ca. 100 von mehreren Tausend). Kann man die irgendwie finden?

Gruß,
Markus

[Wurliwurm]

Jetzt gibt es in der alten Tabelle wohl ein paar Datensätze, wo diese Kombination aber mehrfach vor kommt (ca. 100 von mehreren Tausend). Kann man die irgendwie finden?

Ja. Abfrage erstellen -> Assistent zur Duplikatsuche.