Datenbanklogik ....

[maynard]

Tach...

Ich muß demnächst eine Kundenverwaltung schreiben und da hab ich noch eine etwas komplizierte Frage zur Speicherung der Daten.
Zu einem Kunden gehört eine gewisse Basis an Daten, zb. Name, Adresse usw. Um das genaze Programm einigermaßen flexibel zu halten (und das auch Anwender, die absolut keine Ahnung von Datenbanken haben), soll der Anwender auch eigene Daten (zb. Datum, an dem die Person Kunde geworden ist) dem Konzept hinzufügen könnne. Gleichzeitig soll es auch möglich sein, das Kunden nicht nur sequentiell gespeichert werden sonder auch in einer Hirachie(Kunde X wurde von Kunde Y geworben) gespeichert werden.
Das ganze will ich über eine relationale Datenbank lösen. Wie kann ich jetzt allerdings entscheiden, wie die vom Kunden hinzugefügten Daten gespeichert werden?

Dazu ein Beispiel:
Wenn ich eine Artikelverwaltung habe, dann hab ich in einer Tabelle die Artikel und in einer anderen die Lagerhäuse(mit Adresse usw.) in der sie gelagert sind. Dann weiße ich den Artikeln einfach die entsprechnde ID des Lagerhauses zu und muß dann eben bei Anderungen beispielsweise an der Adresse eines Lagerhauses nur einen Datensatz ändern und nicht eben alle Artikel die in dem betreffenden Lagerhaus lagern ... eben das typische Prinzip einer relationalen Datenbank.

Wie treffe ich aber jetzt bei meinem Vorhaben die Entscheidung, ob die vom Anwender hinzugefügten Daten besser in eine eigene Tabelle kommen, oder in der Kundentabelle abgelegt werden. Oder könnte ich für den Anwender irgendwelche allgemein verständlichen Kennzeichen festlegen, um dem Algorithmus die Entscheidung zu erleichtern? Bis jetzt bin ich noch relativ ratlos!

MfG

[urs.liska]

Hallo maynard,

das ist jetzt so ein bisschen arg schwammig formuliert (und möglicherweise auch gedacht).
Also zuerst einmal musst Du Dir klar werden, welche Informationen überhaupt gespeichert werden sollen.
Dann kannst Du erst damit anfangen, Dir zu überlegen, wie das auf Tabellen verteilt werden kann.
Und dann wirst Du nicht um etwas theoretische Lektüre herumkommen. Such Dir ein Buch oder ein Tutorial zum Thema Datenbankdesign, Stichwort Normalisierung.
Wenn Dir das nicht einigermaßen (oder besser: richtig) klar ist, wirst Du Dich bei einer Kundenverwaltung wahrscheinlich bald verrennen und steckenbleiben.

Das mit den Artikeln und Lagerhaus-Nummern ist doch schon ganz richtig. So läuft das mit den Datenbanken.

Ein paar Stichworte zu den Info-Fetzen, die man aus Deinem Posting entnehmen kann:
- Das Datum, an dem der Kunde gewonnen wurde, gehört in die Tabelle KUNDE (denn es ist EINE Information zu EINEM Kunden).
- Die "geworbenen Kunden" realisierst Du, indem Du in der Tabelle für die Kunden ein Feld KUNDE_ID (oder wie auch immer benannt) einfügst, das mit einem Fremdschlüssel auf dieselbe Tabelle KUNDE verweist.

Den letzten Abschnitt verstehe ich nicht so recht (wahrscheinlich, weil Du ratlos bist...), aber:
- Der Anwender sollte überhaupt nichts davon mitbekommen, was in welcher Form wie abgespeichert wird. Er sieht einfach ein Eingabeformular mit einer Anzahl von Steuerelementen
- Es gibt keinen Algorithmus, der während der Programmausführung entscheidet, was wo abgespeichert wird. Alles wird vorher von Dir festgelegt (beim Entwurf der Datenbank).

Viel Erfolg
Urs

[maynard]

Tach...

Zitat von urs.liska:

Den letzten Abschnitt verstehe ich nicht so recht (wahrscheinlich, weil Du ratlos bist...), aber:
- Der Anwender sollte überhaupt nichts davon mitbekommen, was in welcher Form wie abgespeichert wird. Er sieht einfach ein Eingabeformular mit einer Anzahl von Steuerelementen
- Es gibt keinen Algorithmus, der während der Programmausführung entscheidet, was wo abgespeichert wird. Alles wird vorher von Dir festgelegt (beim Entwurf der Datenbank).

Genau das ist das Problem! Wie gesagt, es gibt Basisdaten die zu jedem Kunden gehören ... aber verschiedene Anwender brauchen eben auch verschiedene Eigenschaften, die zu ihrem Kunden gehören. Heiß, das verschieden Firmen verschiedene Formen von Kunden haben. Deshalb sollen die einzelnen Anwender ihrem Kunden spezifische Eigenschaften hinzufügen können. Und das Programm speichert nun diese Daten, also muß es eben teilweise auch über das DB - Design entscheiden können. Das Basisdesign ist klar nur das was von den einzelnen Anwendern hinzugefügt wird, dass muss eben das Programm übernehmen! So mein ich das...

MfG

[Catbytes]

Hallo,

ich kenne die Materie Artikel/Kundenstammdaten auch recht gut - weiß aber immer nocht nicht, was Du genau willst. Soll das eine Branchenübergreifende Kundendatenbank werden?

Sprich: Ein Mauererbetrieb soll genauso Kunden verwalten können wie eine Bank z.B.?

Wenn ja: Da wirst Du um verschiedene Datenbankmodelle gar nicht drum rum kommen. Das machen die großen (SAP, SAGE KHK) genauso. Da gibt es dann Software fürs Baugewerbe, für Einzelhandel etc, weil eben zuviele Unterschiede existieren.

Beispiel: Ein Mauerergewerbe muß nunmal sowas wie "Güteklassen" etc. verwalten, was eine Bank nicht wirklich interessiert.

Wenn es darum geht, daß der Benutzer einfach eigene Infos eingeben kann, wirst Du um eine "offene Datenbank" nicht herum kommen. Sprich eine Oberfläche, wo der Benutzer quasi das Datenbankdesign benutzerspezifischer Felder selbst anlegen/ändern/löschen kann. Da langt als Auswahl quasi:

Feldname (für die Datenbank)
Angezeigter Name (für den Benutzer)
Art (String, Ja, Nein, Zahl etc.)
Länge
Änderbar J/N?

Denke aber auch an solche Unarten, wie das ein Kunde z.B. auch ein Lieferant sein kann. Also Kreditor und Debitor in einer juristischen Person.

Besser ist es dann, Du legst eine Tabelle "Adressen" an - da kannst Du alle Adressen verwalten. Über eine ID vergibst Du dann in der Tabelle "Kontokorrent" Debitoren/Kreditorennummern und andere, Kontokorrenttypische Angaben, wie Zahlungsmodalitäten, Skonto, Lieferart etc.

Du kannst dann nämlich mit der strikten Trennung von den einzelnen Tabellen (also "Adressen" -> "XY") wunderbar noch alle anderen Informationen unterbringen. Du brauchst also noch Tabellen wie "Ansprechpartner", "Lieferadressen", "Kostenstellen" etc.

Über den "Umweg" der einzelnen Adressen-Tabelle kannst Du nämlich dann jede Art von Adressen (nicht nur Kunden mit Kundennummer) verwalten. Also auch Mitarbeiter, Interessenten etc. Das ganze dann per Flag oder Feld "Gruppe" und Du kannst es schön trennen.

[Marcel Gascoyne]

Es ist auch immer gut die Anwendung mandantenfähig zu machen, schnell braucht Du eine weitere Firma und Du stehst auf dem Schlauch. Hat auch gleich den Vorteil das man zum Testen einen Demo-Mandanten anlegen kann.

Außerdem solltest Du immer speichern wer die letzte Änderung gemacht hat.
Hier mal ein Beispiel für die drei Grundtabellen für Benutzer, Mandanten und Kunden.

SQL-Code:

create table users (
  id integer not null,
  name varchar(20) not null,
  change_user integer not null,
  change_date timestamp not null,
  constraint pk_users primary key (id),
  constraint fk_users foreign key (id) references users (id)
)

create table mandant (
  id integer not null,
  name varchar(50),
  change_user integer not null,
  change_date timestamp not null,
  constraint pk_mandant primary key (id),
  constraint fk_users foreign key (change_user) references users (id)
)

create table kunde (
  id integer not null,
  mandant_id not null,
  change_user integer not null,
  change_date timestamp not null,
  constraint pk_kunde primary key (id),
  constraint fk_mandant foreign key (mandant_id) references mandant (id),
  constraint fk_users foreign key (change_user) references users (id)
)

Gruß,
Marcel

[Catbytes]

Hallo nochmal,

das, was Marcel Gascoyne sagte ist absolut korrekt. Hatte ich vergessen (war ja auch schon spät)

Der weitere Vorteil von Mandanten - Du kannst per Mandant 99 (so'n typischer Mandant) schonmal vorgefertige Demodaten dem Kunden liefern, damit er sieht, wie es geht und alle möglichen Fälle abdecken.

In die Tabelle Mandant gehören auch solche Sachen wie eigene Adresse, Adresse vom Finanzamt etc.

Nachteil: Du mußt halt immer mit Mandant verknüpfen - quasi bei jeder Abfrage.

Also z.B.

select * from adressen where id=0815 and mandant=1 oder so in der art.

[PRehders]

Hallo maynard,

ich kann mir schon denken, was du möchtest; ich habe mal mit einem (Großrechner-) System gearbeitet, wo man etwas ähnliches machen konnte. Natürlich kann man nicht erwarten, dass der Anwender im Datenbankdesign rumfummelt, zumal damit ja noch nichts an Anzeige und Verarbeitungslogik vorhanden wäre.
Ich skizziere mal, was das System damals gemacht hat: Das Basissystem hat natürlich weitestgehend alles abgedeckt, was man im Normalfall so benötigt (z.B. Kontodaten o.ä). Es gibt sog. "Sonderdaten", die der Anwender definieren kann. Ein Sonderdatum hat einen Code, einen Namen, einen Typ und ggf. sogar Ausprägungen. Der Anwender - bzw. der Administrator beim Kunden - gibt also in einer Maske einen Datensatz ein, der z.B. besagt: Sonderdatum "101", heisst "Debitorenkontonummer", ist "String" der Länge "10". Denkbar wären noch z.B. Datum, Zahl, Betrag, Flag.

Jetzt kann der Anwender in einer allgemeinen Sonderdatenmaske neue Sätze zu einem Objekt einfügen, die vom Typ "101" sind, akzeptiert werden hier nur Strings bis zur Länge 10.
In der Sonderdatenmaske sind alle vorhandenen Sonderdaten zu einem Objekt einfach als Liste angezeigt.
Ein weitere Verfeinerung wäre die Möglichkeit, in einer weiteren Sonderdatenmaske zu einem Typ ("101") definieren zu können, welche Ausprägungen es gibt. Wäre der Datentyp Zahl, so könnte man eingeben 0 = "nicht vorhanden", 1 = "XXX", 2 = "yyy".
Dann werden in der Anzeige der Sonderdaten die Ausprägungen übersetzt.

Diese Methode ist sehr mächtig und kann mit sehr wenig Aufwand in der DB implementiert werden: Ein Table definiert die Sonderdaten:

Art : Integer;
Typ : (Integer, Boolean, Date, String, Currency);
Länge : Integer;
Name : String(40);

Und jetzt kann man sie in genau einer(!) Tabelle speichern:

Objekt-ID : ...
Art : Integer;
Wert_Integer : Integer;
Wert_Boolean : Boolean;
Wert_Date : Date;
Wert_String : String(...);
Wert_Currency : Currency;

Bei der Anzeige in der Maske entscheidet dann der Typ des Sonderdatums, welche Spalte angezeigt wird. Diese Anzeigemaske muss dann halt recht universell programmiert werden, also nur String-Anzeigen o.ä.

Arbeitet man mit Ausprägungen, so kommt noch eine Tabelle dazu, die diese definiert:

Art : Integer;
Wert_Integer : Integer;
Wert_Boolean : Boolean;
Wert_String : String(...);
(* andere Typen machen wohl keinen Sinn *)
Bedeutung : String (...);

Mit dieser Tabelle kann man jetzt die Eingaben der Anwender prüfen/beschränken und die Anzeige in der Liste sprechender gestalten.

Mit etwas Phantasie kann man jetzt noch einiges verfeinern, z.B. den Typ-Code so sprechend machen, dass man eine Berechtigungsverwaltung draufsatteln kann (ein Anwender kann nur Sonderdaten eingeben, zu denen er berechtigt ist...)
Oder man sagt, zu welcher Art von Objekt ein bestimmter Typ nur angegeben werden darf...

Es sind damit in gewissen Rahmen auch Auswertungen für den Anwender machbar ("Anlisten aller Kunden, die Sonderdatum "101" haben bzw. die Sonderdatum "101" = "xxxxx" haben").

Ich hoffe, das gibt ein paar Ideen...

Viel Spass beim machen!

Bis dann

Peter