AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Allgemeine Frage zum Aufbau einer Datenbank
Thema durchsuchen
Ansicht
Themen-Optionen

Allgemeine Frage zum Aufbau einer Datenbank

Ein Thema von gfjs · begonnen am 2. Mär 2006 · letzter Beitrag vom 2. Mär 2006
Antwort Antwort
gfjs

Registriert seit: 8. Dez 2005
Ort: Hohenkammer
298 Beiträge
 
Delphi 2006 Professional
 
#1

Allgemeine Frage zum Aufbau einer Datenbank

  Alt 2. Mär 2006, 07:20
Datenbank: mySQL • Version: 5.0 • Zugriff über: weiß ich noch nicht
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
Mein neues Motto (von "Unbekannt"):
Gewinnen: Wenn Du kannst - Verlieren: Wenn Du musst - Aufgeben: NIE!
  Mit Zitat antworten Zitat
Benutzerbild von cruiser
cruiser

Registriert seit: 23. Dez 2003
Ort: Königsbrück/Sachsen
455 Beiträge
 
Delphi 7 Enterprise
 
#2

Re: Allgemeine Frage zum Aufbau einer Datenbank

  Alt 2. Mär 2006, 07:44
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)
  Mit Zitat antworten Zitat
Benutzerbild von mikhal
mikhal

Registriert seit: 11. Sep 2003
Ort: Linz am Rhein
796 Beiträge
 
Delphi 11 Alexandria
 
#3

Re: Allgemeine Frage zum Aufbau einer Datenbank

  Alt 2. Mär 2006, 07:53
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
Michael Kraemer
Computer erleichtern die Arbeit...
...und die Erde ist eine Scheibe!
  Mit Zitat antworten Zitat
gfjs

Registriert seit: 8. Dez 2005
Ort: Hohenkammer
298 Beiträge
 
Delphi 2006 Professional
 
#4

Re: Allgemeine Frage zum Aufbau einer Datenbank

  Alt 2. Mär 2006, 09:12
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
Mein neues Motto (von "Unbekannt"):
Gewinnen: Wenn Du kannst - Verlieren: Wenn Du musst - Aufgeben: NIE!
  Mit Zitat antworten Zitat
Benutzerbild von cruiser
cruiser

Registriert seit: 23. Dez 2003
Ort: Königsbrück/Sachsen
455 Beiträge
 
Delphi 7 Enterprise
 
#5

Re: Allgemeine Frage zum Aufbau einer Datenbank

  Alt 2. Mär 2006, 10:29
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..
  Mit Zitat antworten Zitat
gfjs

Registriert seit: 8. Dez 2005
Ort: Hohenkammer
298 Beiträge
 
Delphi 2006 Professional
 
#6

Re: Allgemeine Frage zum Aufbau einer Datenbank

  Alt 2. Mär 2006, 10:54
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
Mein neues Motto (von "Unbekannt"):
Gewinnen: Wenn Du kannst - Verlieren: Wenn Du musst - Aufgeben: NIE!
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 03:58 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