Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Allgemeine Frage zum Aufbau einer Datenbank (https://www.delphipraxis.net/64314-allgemeine-frage-zum-aufbau-einer-datenbank.html)

gfjs 2. Mär 2006 06:20

Datenbank: mySQL • Version: 5.0 • Zugriff über: weiß ich noch nicht

Allgemeine Frage zum Aufbau einer Datenbank
 
Guten Morgen, Allerseits.

Obwohl ich noch ein ziemlicher Anfänger bin, will (besser muss) ich mich an ein größeres Projekt für meine eigene Firma (Entsorgungsbetrieb) machen. Mein erstes größeres Problem besteht darin, wie ich die Abrechnung mit unseren Kunden am besten in der Datenbank unterbringe. Hier möglichst kurz eine Schilderung der Aufgabenstellung:

Ich muss für die Festlegung des Preises viele unterschiedliche Gegebenheiten berücksichtigen, so dass ich die Beschreibung der auszuführenden und abzurechnenden Leistungen auf drei Tabellen verteilt haben, die - verkürzt - wie folgt aussehen:

Tabelle Einheit
EinhID - AutoInkrement
EinhKz - integer (4-stellig)
EinhBez - string

Tabelle Artikel
ArtID - AutoInkrement
ArtKz - integer (max 8-stellig mit führenden Null)
ArtBez - string

Tabelle Leistung
LeistID - AutoInkrement
LeistungKZ - byte (max. 2-stellig)
LeistBez - string

Die abzurechnende Leistung setzt sich aus Einträgen aller drei Tabellen zusammen. Ein paar Beispiele:

1.100 Ltr. - Gewerbeabfall - leeren - € 30,00
1.100 Ltr. - Altpapier - leeren - € 10,00
Stück - 20 cbm Container - Transport - € 75,00
Tonne - Gewerbeabfall - Entsorgung - € 175,00

Meine Frage ist nun, wie ich die Preise in der Datenbank hinterlegen soll. Mir sind dazu zwei Alternativen eingefallen, wobei ich mir unsicher bin, welche vorzuziehen ist:

Alternative 1:

Hierbei würden für die Preise (die bei den Kunden durchaus unterschiedlich sind) ein Tabelle verwendet, die - wiederum verkürzt - folgendes Aussehen hätte:

Tabelle Preise
KuNr
EinhKz
ArtKz
LeistKz
Preis

Bei der Rechnungsstellung müsste ich dann die Tabelle durchlaufen und bei jedem Datensatz mit der passemdem Kundennummer darauf prüfen, ob Einheit, Artikel und Leistung übereinstimmen, um den Preis für die entsprechende Auftragsposition festzustellen und in die Rechnung zu übernehmen.

Alternative 2:

Hierbei würde ich eine weitere Tabelle erzeugen, in der Einheit, Artikel und Leistung stehen:

Tabelle Auftragsposition
PosID - AutoInkrement
EinhKz
ArtKz
LeistKz

Tabelle Preise
KuNr
PosID
Preis

Hier müsste ich dann bei der Rechnungsstellung nur noch prüfen, ob Kundennummer und Auftragsposition übereinstimmen.

Vielleicht hat ja jemand noch eine bessere Idee - ich bin für jeden Hinweis dankbar.

mfg gfjs

cruiser 2. Mär 2006 06:44

Re: Allgemeine Frage zum Aufbau einer Datenbank
 
Hrm... ich versuchs mal... schlagt mich, wenns Falsch ist ;)

Code:
|Einh| ------> |Posten| <-- |Rchn| <-- |Kund|
|----|  /----> |------|     |----|     |----|
|ID |  | /--> |ID   |     |ID |     |ID |
|... |  | |    |EinhID|     |KuID|     |... |
        | |    |ArtkID|     |... |
|Artk| -/ |    |LstgID|
|----|    |    |RchnID|
|ID |    |    |Anzahl|
|... |    |    |Preis |
          |    |...  |
|Lstg| ---/
|----|
|ID |
|... |
Soweit so gut.. zur Erläuterung:

Ein Posten kann verschiedene Einheiten, Artikel und Leistungen haben. Evtl. solltest du Artikel und Leistungen zusammenfassen ála "Tonnen abholen", "Tonnen leeren" etc. und da einen Preis definieren, dann fiele das entsprechende Feld beim Posten weg.

Eine Rechnung ist nicht abhängig von den Posten sondern die Posten von der Rechnung. Darum die RechnungsID in den Posten und nicht die Posten-ID in die Rechnung.

Die Posten haben nichts mit dem Kunden zu schaffen. Aber in der Rechnung braucht es einen Kunden.

Wenn der Kunde nun noch verschiedene Bankverbindungen hat, wird es lustig ;) aber so wie du es hier dargestellt hast sollte das reichen. (hoff ich)

mikhal 2. Mär 2006 06:53

Re: Allgemeine Frage zum Aufbau einer Datenbank
 
Ich würde eine Tabelle wie in Beispiel 2 verwenden, allerdings ohne die Beziehung zum Kunden. Dazu würde ich eine weitere Treffertabelle verwenden. Hier kannst du am besten individuell deine Preise gestalten und verwalten.

Weiteres Problem: Was machst du, wenn der Preis für eine Leistung geändert wird?

Ein Weg wäre z.B.: Bei der Rechnungserstellung den Preis und die entsprechende Leistung redundant in der Rechnungsposition speichern, damit nach einer Preisänderung immer noch der zu dem Zeitpunkt gültige Preis ausgeben werden kann. Das ist ein Weg, wenn auch nicht unbedingt der Königsweg. Bei der Preistabelle würde ich zusätzlich noch Daten für die Gültigkeit aufnehmen (etwa GültigSeit und GültigBis), eventuell noch eine Rabattierung...

Grüße
Mikhal

gfjs 2. Mär 2006 08:12

Re: Allgemeine Frage zum Aufbau einer Datenbank
 
Vielen Dank für Eure schnellen Antworten!

Artikel und Leistung kann ich nicht zusammenfassen. Der Preis hängt ab von der Einheit (hier Behältergröße), vom Artikel (hier Abfallart) und der Leistung (z.B. Leeren). Die Leerung eines Behälters gleicher Größe hängt ab von der darin enthaltenen Abfallart. Es könnte aber statt der Leistung "Leeren" eine andere Leistung z.B. "Sortieren" zum Tragen kommen, die dann wieder einen anderen Preis hat.

@ cruiser

Der Tabellenname "Auftragsposition" ist etwas unglücklich gewählt - es handelt sich nicht um den tatsächlich aufgeführten Auftrag sondern nur um die Definition einer Auftragsposition, die für viele Kunden zutreffen kann:

PosID = 1: 1.100 Ltr. - Gewerbeaball - leeren
PosID = 2: 1.100 Ltr. - Altpapier - leeren

In der Tabelle Preise wird dann der Preis für den jeweiligen Kunden eingetragen:

Code:
KuNr = 10100: PosID = 1 - Preis = 30,00€
KuNr = 10100: PosID = 2 - Preis = 10,00€
KuNr = 10310: PosID = 1 - Preis = 29,50€
KuNr = 11201: PosID = 2 - Preis = 11,50€
Die tatsächlich ausgeführten Aufträge werden dann in einer eigenen Tabelle erfasst:

Code:
KuNr  Datum   Anzahl  Position                          Preis  RechnNr

10100 02.03.06    3      PosID 1=1.100 Ltr. Gewerbeabfall  30,00
Zum besseren Verständnis eine Zusammenfassung des Ganzen:

Die Kombinantion aus EInheit, Artikel und Leistung ergibt theoretisch sicher mehrere Hundertausend Möglichkeiten, da es alleine mehr als 1000 verschiedene Abfallarten (nach Abfallverezichnis) gibt. Davon werden aber sicher nur wenige hundert insgesamt und beim einzelnen Kunden selten mehr als fünf tatsächlich benötigt.

Es gibt einen Musterkunden, dem für die häufigsten Kombinationen (= mögliche Auftragspositionen) ein Standardpreis zugeordnet wird. Diese Positionen können für einen Teil der Kunden verwendet werden. Jedem Kunden kann aber ein individueller Preis oder eine Kombination aus Standardpreis und individuellem Preis zugeordnet werden. Deshalb wird in der Tabelle "Preise" die Kundennummer erfasst. In dieser Tabelle kann jede Position beliebig oft vorkommen (im Extremfall für jeder Kunden einmal), da die Kunden unterschiedliche Preise haben. Jeder Kunde wiederum kann mehrmals vorkommen, wenn bei ihm mehrere der möglichen Auftragspositionen vorkommen können.

Für die Disposition wird eine DispositionsPosition angelegt, in der der Kunde, die zu erbringende Leistung und das geplante Ausführungsdatum erfasst werden. Ist der Auftrag ausgeführt, wird die Disposition in die endgültige Auftragsposition überführt, in der u.a. erfasst sind:

Auftragsnummer des Auftrags, dem diese Position zugeordnet ist (für einen Kunden können mehrere Aufträge bestehen)
Kunde (kann sich ggf. aus der Auftragsnummer ableiten)
Standort (ein Kunde kann mehrere Standorte z.B. mehrere Lokale haben)
Anzahl
erbrachte Leistung (Preis ergibt sich aus der PosID in der Tabelle "Preise")
Ausführungsdatum
Rechnungsnummer (wird bei der Abrechnung eingefügt)

Zum Zeitpunkt der Rechnungsstellung wird die Tabelle mit den ausgeführten Aufträgen dann Kunde für Kunde nach durchgeführten Aufträgen durchsucht. In den Auftragspositionen wird die Rechnungsnumer hinterlegt und die Rechnung entsprechend der gewünschten Sortierkriterien (z.B. nach Datum, nach Standort und Datum, etc.) erstellt.

Das ist natürlich nur ein erster Entwurf - es müssen sicher noch einige Dinge berücksichtigt werden. Aber irgendwo muss ich ja einmal anfangen.

@ Mikhal

Ich sehe keine Möglichkeit, die Beziehung zum Kunden aus der Tabelle "Preise" heraus zu nehmen. Ich muss ja die unterschiedlichen Preise für ein und dieselbe Leistung den jeweiligen Kunden zuordnen können. Sonst müsste ich ja für jeden Kunden eine eigene Tabelle mit Preisen erstellen.

Preiserhöhungen sind für uns immer problematisch, da niemals eine lineare Preiserhöhung für eine Leistung erfolgt. Preiserhöhungen sind individuell für den einzelnen Kunden und erfolgen in der Regel auch zu unterschiedlichen Zeitpunkten. Ich kann ggf. den Standardpreis für einzelne Leistungen relativ einfach ändern. Für Kunden die individuelle Preise haben, bleibt nur die Möglichkeit, sich die für den Kunden hinterlegten Preise anzeigen zu lassen und die zu ändern, bei denen es erforderlich ist.

Nochmals vielen Dank für Eure Beteiligung. - Ich werde sicher noch mit dem einen oder anderen Problem hier auftauchen müssen.

mfg gfjs

cruiser 2. Mär 2006 09:29

Re: Allgemeine Frage zum Aufbau einer Datenbank
 
Was ich sagen wollte war folgendes:

Überleg dir einfach, was von was abhängt. Und unterteile es in kleine Stücken. Auf die Art kannst du das ganze später gegebenenfalls anpassen und erweitern. Vermutlich brauchst du noch mehr Tables als meine Grafik aufzeigt. Aus deiner Schilderung heraus und um die Uhrzeit meiner Antwort erschien mir das richtig ;)

Wichtig ist einfach nur das du keine Kreisbeziehungen zwischen den ID's baust. Der Endbaustein sollte der Posten auf der Rechnung sein. Dann musst du nur noch nach der Rechnungsnummer in der entsprechenden Table filtern und den Endpreis berechnen. Wie das nun mit der Kundennummer zusammenhängt hrm ja.. lass dir was einfallen ;) Klingt zumindest nicht nach der 'klassischen' Abrechnungsstruktur..

gfjs 2. Mär 2006 09:54

Re: Allgemeine Frage zum Aufbau einer Datenbank
 
Hallo Cruiser,

vielen Dank für Deine Mithilfe. Du hast recht, ich werde noch etliche weitere Tabellen brauchen und werde wohl auch in dem einen oder anderen Punkt nochmal umdenken müssen. Nachdem es mein erstes Datenbankprojekt überhaupt ist, werde ich wohl noch so manchen gedanklichen "Wurm" reinbringen und bin froh, wenn mich jemand auf den richtigen Weg zurückbringt.

Ich sitze gerade im Büro und kann mich nicht näher damit befassen. Aber heute abend werde ich mir Deine Hinweise nochmal genauer durch den Kopf gehen lassen und ggf. nachfragen.

Ich wünsche Dir noch einen schönen Tag.

Servus aus München

gfjs


Alle Zeitangaben in WEZ +1. Es ist jetzt 10:55 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz