guid über mehere Tabellen

E

executor

Benutzer
Beiträge
5
Hallo Leute,
ich hab ein kleines Programm geschrieben um die Bestellabwicklung für unsere IT etwas zu vereinfachen.
Hierfür hab ich eine Datenbank unter Sql mit der ich mehrere Tabellen fülle.
Ich habe für jeden Gerätetyp eine eigene Tabelle erstellt, da nicht jedes Gerät die volle Anzah der Spalten benötigt:

für die Tabellen Rechner, Monitore, NC und Bestellungen habe ich mit eineigen Abweichungen unten genanntes Schema verfolgt:
Name|Benutzer|Verschiedene Liefer und Bestelldaten|.....|Gerätedaten|HandelswareGuid
Bestimmte wiederkehrende Daten wie Hersteller und modelle habe ich schon über Normalisierung in untertabellen verfrachtet.
Der Name der geräte ist immer auch der Jeweilige primärschlüssel der Tabellen.
Also lt001,lt002 usw.
Nun wollte ich eine weitere Tabelle Handelsware einfügen in der Geräte landen, welch nicht sofort einem User zugeordnet werden .
Beim Umbuchen eines Gerätes auf die Handelsware lasse ich in den jewiligen Tabellen bei dem betroffenen Gerät eine Guid im Feld Handelsware erstellen, welche dann auch Primärschlüssel der Tabelle Handelsware ist.
Hier stehen dann weitere Informationen wie Preis und Belegnummer.
Beim ausbuchen aus der Handelsware fehlt mir aber eine Möglichkeit von der Guid aus auf die richtige Tabelle zu schließen, weil Sie ja in einer der 4 Tabellen versteckt ist.
Bisher helfe ich mir damit das ich in der Handelswaretabelle eine weiter Spalte einfüge in der ich die
passende Tabelle als String abspeichere. Diese Frage ich dann vor dem eigentlichen Update programmiertechnisch ab.

Ich will mein programm aber in zukunfz immer mal wieder erweitern, und würde so ein update dann gerne über 1 einziges Sql-Statement machen da das Programm und der Aufbau wahrscheinlich sonst zu umständlich wird.

Habe ich beim Datenbankdesign einen Fehler gemacht?
Muss ich die Tabellen in irgendeiner weise in Beziehung zu einander setzen?

Ich bin bereit die ganze Datenbank nocheinmal von vorne zu erstellen, Hauptsache sie bleibt skalierbar!

Besten Dank im Voraus
 
Werbung:
Nein eigentlich ist das Vorgehen mit einer zusätzlichen Spalte für den Tabellennamen völlig korrekt. Er verbraucht natürlich etwas Platz, aber bei kurzen Namen ist das Verschmerzbar. Ansonsten könnte man hier auch mit IDs arbeiten, klingt mir aber jetzt zu umständlich.

Wenn sich dein Programm um neue Objekttypen erweitert (z.B. Autos, Flugzeuge, Schiffe) die sich aufgrund der Unterschiede in den Eigenschaften wieder nur in neuen Tabellen abbilden lassen, wäre ein Redisign sinnvoll. Auch wenn der Anwender in der Lage sein soll, neue Objektarten zu bestimmen.

Um in einem solchen Fall nicht immer neue Tabellen kreieren zu müssen kann man wie folgt vorgehen: Alle Atribute die durch alle Objekte gegeben sind (z.B.: Datum, Hersteller, Gewicht etc.) werden in einer Objekttabelle geführt. Alle Atribute die individuell sind (z.B.: Arbeitsspeicher, Bilddiagolnale, Anzahl Räder, etc.) werden in einer gesonderten Tabelle definiert. Ein Fremdschlüssel verweisst auf das Objekt, eine Spalte definiert den Atribut Namen, eine weitere den Wert und ggf. noch eine die Einheit.

Diese Methode ist natürlich nicht voll normalisiert. Auch birgt sie ein paar Tücken: Das Programm muss mit einem gewissen Mehraufwand alle Atribut Einträge in den Datensatz puzzeln - das geht aber wenn man sich dran gewöhnt. Außerdem musst hast du alle Atribute in einer Spalte gleichen Datentyps stehen, das ist auch sonne sache wenn man rechnen will :) Hier kann man aber auch den Schritt zurück gehen und einfach die eine Atribute Tabelle in mehrere Aufteilen, eine für CHAR, eine für INT, eine für DATETIME, etc. In jedem Fall erreicht man damit eine enorme Flexibilität was die Abbildung von unterschiedlichen Objekten angeht.
 
Hallo,

da es immer gut ist, mehrere Meinungen zu hören, insbesondere be einem solchen Thema, gebe ich hierzu auch noch einmal einen Kommentar ab.

Ich habe bereits Projekte mit ähnlichen Anforderungen abgewickelt und denke, dass ich hier ein paar Tipps geben kann.
Die von ukulele beschriebene Vorgehensweise bei der Modellierung ist im allgemeinen auch der Weg, den ich gegangen bin.

Wenn schon von vornherein davon ausgegangen werden kann, dass inhaltlich mehrfach Erweiterungen gemacht werden müssen oder sollen,
dann sollte das Datenbankmodell so aufgebaut sein, dass es diese dynamik für die meisten Fälle abdecken kann.

Hierzu habe ich z.B. eine Stammdatentabelle für Anlagen, also Geräte angelegt, in der die für alle Gerätetypen (Monitore, PCs, Notebooks, Druckert etc.) gleich sind.
Hierzu gehören Daten wie Anschaffungsdatum, Preis, Kostenstelle usw.

Angaben wie Hersteller, Gerätetyp oder Modell können dann in eigenen Tabellen verwaltet werden und über F-Keys an die Anlage gebunden werden.
(In meinem Projekt existiert sogar eine Abhängigkeit von Hersteller, Geratetyp mud Modell - in dieser Reihenfolge)

Die Attribute der Gerätetypen habe ich so verwaltet, dass ich zunächst eine Tabelle mit den MÖGLICHEN Attributen zu einem Gerätetyp angelegt habe,
was dann ebenfalls als Stamm- oder Systemdaten anzusehen ist. Die Bewegungsdaten, also die eigentlichen Wert-Angaben bilden dann noch einmal eine eigene Tabelle,
die wieder über F-Keys auf die Anlage und das Attribut verknüpft sind.

Die Tabelle mit den Attributwerten kann man hier natürlich auch auf verschiedene Arten aufbauen. Entweder man erstellt für jeden Datentyp eine Tabelle (Vorschlag von ukulele)
oder man packt einfach drei (oder mehr) Werte-Spalten in die Tabelle ein. Je nachdem kann man auch mit zwei String-Spalten auskommen (Wert und Datentyp), da man eigentlich fast alles in einen String und zurück konvertieren kann (aber hier vorsicht, Konvertierung kostet Zeit).

Dieser Aufbau bietet sowohl für die Stammdaten wie auch für die Bewegungsdaten eine ordentlich dynamische Verwaltungsmöglichkeit.
Die Programmierung der Eingabeoberfläche mag so zwar etwas komplexer werden, aber der Vorteil der dynamik überwiegt hier.
Man muss an Grundsystem keine großen Änderungen mehr vornehmen.

Kurzum, ich bin auch der Meinung, wie ukulele vor mir, dass dies die Beste Möglichkeit ist, um Erweiterungen direkt im Aufbau abzubilden.

Viele Grüße,
Tommi
 
Erst einmal vielen Dank für die Antworten, ich hab mir eure Ratschläge zu Herzen genommen, meine tabellenstrucktur für das Beispiel "andere Bestellungen" sieht nun so aus ( im Anhang)
Guid ist noch der vorherigen Programmierung geschuldet,
Neben Der Programmoberfläche haben die "User" auch die Möglichkeit über ein Datagridview komplette Tabellen einzusehen!
Wenn Daten geändert werden brauche ich nun etwas mehr Code für die Artikelbeschreibung (zwei Updates), das ist aber ok.
Die Lieferanten hatte ich auch in der ersten Version schon in eine extra Tabelle ausgelagert, diese waren über das dgv bisher nicht änderbar da ja eigentlich in der Tabelle Bestellungen nur ID's der Tabelle Lieferanten stehen die ich per select auflösen lasse.
Nun können die User ja keinen eigenen Text bei Lieferanten eingeben für den es keine ID gibt. Ist es vieleich möglich innerhalb eines dgv eine Combobox mit Auswahlmöglichkeiten zu integrieren, und wie programmier ich dann das Ganze?

Im Grunde werden bei den Rechnern egal von welchem Hersteller immer die selben Werte erfasst(mac SN, OS usw.) nur Bei Dell Geräten kommt noch das Service Tag hinzu. Also habe ich eigentlich keine Bewegungsdaten
trotzdem finde ich die Idee super und hätte hier nur noch gern erklärt wie genau das konzepiert wird ein Beispiel der Tabellenstrucktur wäre toll.
Des weitern muss ja auch die Programmoberfläche dynamisch auf wechselnde Anzahl von Attributen reagieren, wie realisiert ihr das ?

Besten Dank
 

Anhänge

  • Unbenannt.png
    Unbenannt.png
    24,4 KB · Aufrufe: 7
Das mit der Combobox wirst du in der Anwendung / Eingabemaske realisieren müssen, das ist ja nicht Teil der DB.

Zu der Programoberfläche und der Tabellenstruktur mal ein abstraktes Beispiel:
Du hast ein Versandhandel in dem nicht nur Computer sondern auch Monitore und Scanner bestellt werden können. Es gibt eine Objekte Tabelle in der die Grundinformationen liegen die jeder Artikel hat (z.B. Artikelnummer etc.), außerdem ein Objekttyp. Anhand dieses Objekttyps bestimmst du, mit welcher Oberfläche / Eingabemaske deine Anwendung das Objekt anzeigt. Die Objekteigenschaften für Computer (CPU, RAM, HDD), Scanner (dpi, Schnittstelle) und Monitor (Auflösung, Schnittstelle #1-n) liegen in einer gesonderten Tabelle in der für jede Eigenschaft eine Zeile eingetragen wird. Hier kann das ganze auch eine dynamische Anzahl an Atributen annehmen aber über die Objekttypen ID weiss meine Anwendung erstmal, was sie da zu tun hat. Alle anderen Eigenschaften kann sie dann auslesen und entsprechend der Aufteilung und Darstellung des Artikels sortieren / anordnen etc.

Tabellen wie Bestellung, Lieferanten sind ähnlich wie Objekte natürlich fest stehend, nur Eigenschaften von Artikel müssen irgendwo frei definiert werden können. Sonst musst du bei einer Tabelle Objekte jede mögliche Spalte für alle Objekte anlegen.
 
Hallo executor,

ich habe mir mit meiner Antwort ein wenig Zeit gelassen. Manchmal ist es ja besser, wenn man sich auch selbst mit einem Problem beschäftigt und zu einer Lösung kommt.
Dennoch, du hast nach einem Beispiel für ein Datenbank-Schema gefragt. Ich habe ein kleines Schema angefügt. Dieses habe ich (so ähnlich) in einem Projekt von mir eingesetzt.
Die Spalten der Tabellen können selbstverständlich nach Bedarf und Anforderung angepasst werden.

Du wirst feststellen, dass ich die IDs immer den Tabellen entsprechend benannt habe und diese auch in den abhängigen Tabelle wieder genau mit diesem Namen auftauchen.
So kannst du auch gut die FKEYs und die Abhängigkeiten erkennen.

Ich hoffe, es gefällt und vielleich kannst du dir hier ja was abschauen (wenns sinnvoll für dein Projekt ist)

Viele Grüße,
Tommi
 

Anhänge

  • Beispiel Attribute.jpg
    Beispiel Attribute.jpg
    64,3 KB · Aufrufe: 13
Vielen Dank erst mal für deine Antwort, ich hatte mich gerade erst mal mit einem neuen WPF-Design für die Anwendung beschäftigt.
Ich steige aber gerade wieder in die Datenbankmodellierung ein und versuche das Konzept zu adaptieren, werde hier posten wenn es fertig ist.
Eine kurze Zwischenfrage habe ich aber noch:
Enthält die Gerätetyp Tabelle in deiner Datenbank die Geräteklassen? Also Monitor PC NC?
Das hat bei mir so ein bischen für Verwirrung gesorgt da ich auch eine Gerätetyp Tabelle benutze aber hier die Typenbezeichnung des Herstellers speichere.
Ich müsste um das umzusetzen wahrscheinlich noch eine weiter Tabelle Geräteklasse einfügen.
Bei dem Konzept welches mir grad durch den Kopf schwirrt würde ich die Attributabllen auch abhängig von der Geeräteklasse machen, werde wohl mit der Zeit sehen ob das praktikabel ist.
 
Hi,

in der Tabelle [Gerätetyp] verwalte ich in der Tat die verschiedenen Arten (Typen) von Anlagen/Geräten (also PC, Monitor, Drucker etc.)
Die Typenbezeichnung der Hersteller wird dann in der Tabelle [Gerätemodelle] verwaltet.

Eine Anlage wird dann nur noch einem Gerätemodell zugeordnet. Durch die Schlüssel/Beziehungen können dann auch Gerätetyp und Hersteller ermittelt werden.

Beispiel: InvNr "12345" (aus [Anlagen]) - Modell "LaserJet 2100" (aus [Gerätemodelle]) - Gerätetyp "Drucker" (aus [Gerätetyp]) - Hersteller "Hewlett Packard" (aus [Hersteller])


Viele Grüße,
Tommi
 
So ich habe jetzt erst mal grob das Modell erstellt, wie ich mir die Datenbank später vorstelle.
Ich habe sowohl für Hersteller als auch für Geräteklassen Attributtabellen erstellt, da ich z.B bei Dell noch einen Xpress Service Code habe und weiter Garantiedaten.
in der Geräte-Tabelle habe ich Herrsteller und Modell belassen, wegen dem einfacheren Zugriff auf die Daten, es würde wohl auch referenziert über Typ gehen aber so ist es glaub ich auch ok.
In die Geräteklassen-Attribute sollen nacher Daten wie MAC-Adresse usw kommen.

Ich nehme jeden Einspruch gerne entgegen :)!
 

Anhänge

  • datenbank.png
    datenbank.png
    40,4 KB · Aufrufe: 16
Werbung:
Hallo executor,

Einspruch erheben wird hier soundso keiner (es sei denn, das Modell wäre wirklich absoluter Murks ;)) . Wir geben ja nur gut gemeinte Tipps. Was Du davon nachher wirklich brauchen kannst, hängt ja in erster Linie von den Anforderungen Deines Projekts ab. Mit unseren Tipps hoffen wir Dir nur soweit helfen zu können, dass du nachher nicht in eine echte Problem-Falle läufst.

Zu Deinem Design: ich finde Deine Lösung gut. Ich selbst bin zwar kein Freund von zu vielen Schlüssel-Verweisen sondern bevorzuge einen hierarchischen Aufbau, aber das ist mein persönliches Gusto.
Deine Lösung hat in jedem Fall den Vorteil, dass du bei Auswertungen und Abfragen nicht zu viele Tabellen einbinden musst (wie Du auch selbst geschrieben hast). Das ist natürlich einfacher und, je nach Tabellengröße, auch performanter.


Viele Grüße,
Tommi
 
Zurück
Oben