Hilfe beim Entwerfen eines DB-Modells

[wahid]

Hallo zusammen,

ich bin momentan bei der Umsetzung eines Schulprojektes (DB-basierte Desktop Anwendung), und brauche eure Vorschläge um mein Datenmodell richtig zu unsetzen. Es geht um ein kleines Warenwirtschaftssystem für einen Second-Hand Computerladen. Die Waren müssen spezifisch nach dem Warentyp unter verschiedenen Kategorien gespeichert werden. Jede Ware wird einzeln eingescannt (mittels Barcodescanner) und deren entsprechenden Attributen gespeichert. Z.B. dem Verkäufer soll ermöglicht werden den Artikel "DELL Latitude XY" in der Tabelle "LAPTOPS" (diese Tabelle soll nur Laptops spezifische Attribute enthalten) anzulegen, während er den Artikel "Samsung TFT XY" in einer anderen Tabelle "DISPLAYS" (spezifische Eigenschaften für Displays) anlegt, und so weiter bei den anderen Artikelarten.

Es muss auch möglich sein, dass der Benutzer die Menge der gescannten Artikelgruppe (Laptop DELL XY) ermitteln kann.

Leider alle Möglichkeiten, die ich bis jetzt versucht habe, führen zu einer Datenredundanz.

Für irgendwelche Vorschläge dazu, würde ich sehr dankbar.

Gruß

[Sturm]

Vielleicht kannst du uns ja mal mit einem ER-Diagramm deine bisherige Lösung zeigen, und wir schauen dann mal wo man noch ansetzen kann!

[wahid]

Hallo "Sturm",

so im Anhang findest du meine bisherige Lösung, die ich bisher optimieren möchte.

Die Endung "_copy1" ist unnötig (wollte nur diesen Abschnitt der DB zeigen).

Und jetzt eine kurze Vorstellung zu diesem Abschnitt:

1- Ein mehrfach eingelieferter Artikel (10 Stck. IBM THINKPAD XY) kann unter der Tabelle "ARTIKEL" angelegt werden. Dieser gehört zu einem bestimmten Artikeltyp (Tabelle "KATEGORIE") , jeder Kategorie kann auch untekategorien haben (durch die 1:n Beziehung innerhalb der Tabelle "KATEGORIE".

2- Jeder angelegter Artikel hat 1 bis n Artikels von Typ "COMPUTER", "DISPLAY", "DRUCKER" oder "ZUBEHOER", sodass derselbe Artikel mehrfach (da jedes Stück einen Barcode hat) unter der zugehörigen Tabelle angelegt wird. Also durch diese 1 zu 1...* Beziehung muss es unbedingt einen Datensatz in einer der erwähnten Tabelle angelegt wird.

3- Jeder "ARTIKEL" stammt aus einem "LIEFERANT"

4- Jeder "ARTIKEL" hat einen "STATUS" (ausverkauft, lieferbar) oder jeder "COMPUTER" ...usw hat auch einen "STATUS" (verkauft, verfügbar, defekt...)

Das Problem liegt bei meiner komischen Vorstellung, dass in jeder der Artikeltyps-Tabellen dieselbe Datensätze für einen bestimmten Artikel gibt, außer dem Barcode, der wird unterschiedlich sein.

Any Idea?

Danke

[_n4p_]

nun zunächst mal, alles was nicht typ spezifisch ist in die artikeltabelle

barcode,hersteller,modell

warum in den typtabellen ein PK id und artikel ID? artikel ID sollte doch eindeutig genug sein?

wieso kann ein artikel in der artikel tabelle mehrere computer, tfts oder drucker enthalten?

eine lieferung ja, aber du willst ja die artikel speichern.

was is mit dem status? kann ein TFT grundsätzlich andere werte für status bekommen als ein drucker?

ich mein verfügbar is verfügbar und bestellt ist bestellt völlig egal was für ein Typ das is, oder nich? wäre dann also noch ein kandidat für die artikeltabelle

und du möchtest bestimmt kein bild binär in die tabelle schreiben, oder?

[wahid]

Hallo _n4p_,

So zu deinen Fragen:

warum in den typtabellen ein PK id und artikel ID? artikel ID sollte doch eindeutig genug sein?

=> Artiekl_ID ist in dem Fall ein Foreign Key, brauche ich das nicht?

wieso kann ein artikel in der artikel tabelle mehrere computer, tfts oder drucker enthalten?

=> Ja hier meinte ich folgendes: Händler bekommt eine bestimmte Menge von einem Artikel X, dieser wird dann in der Tabelle "ARTIKEL" mit den allgemeinen Attributen gespeichert. Jedes Stück aber (mit eigenem Barcode) wird von ihm eingescannt und deren Eingenschaften in einer der Artikeltyps_Tabellen gespeichert. Später kann der Vekäufer sowohl die Eigenschaften von einem "ARTIKEL" ermittlen, oder genau den ARTIKEL mit dem Barcode "123456789DE" durch den Barcodescanner ermitteln. Und so ist die Entität "ARTIKEL" das Produkt sozusagen und "ARTIKELTYP" das Einzelstück.

was is mit dem status? kann ein TFT grundsätzlich andere werte für status bekommen als ein drucker?

=> Mit "STATUS" wollte ich eigentlich einmal den status für den ARTIKEL, d.h eine Warengruppe ARTIKEL kann entweder ausverkauft oder nicht sein, während ein TFT oder DRUCKER kann den Status "verkauft" oder "verfügbar" bzw. "defekt" haben kriegen solange diese nur ein Stück der Gesamtmenge sind.

und du möchtest bestimmt kein bild binär in die tabelle schreiben, oder?

=> dieser binärer Datentyp wird von MySQL unterstützt um z.B Bilder zu speichern.

Falls irgendwelche Vorschläge zum DB-Modell bitte nicht zögern, Danke!

[_n4p_]

ok in "artikel" sind also 1..N verschiedene produkte pro datensatz die dann einzeln in den jeweiligen tabellen liegen?

also betrachten wir den typischen wareneingang:

der lieferant schickt ein päckchen

allein das sind minimum 3 tabellen, daten zum lieferanten in der einen, daten pro lieferung in einer anderen und in die 3te kommen daten wie artikelnummer, liefernummer, menge, (stückpreis,...)

in der artikeltablle kommen allgemeine daten zum artikel: artikelnummer, verkaufspreis, mwst-satz, barcode, hersteller, artikeltyp, artikelkategorie, menge auf lager, ...

in die typspezifischen tabellen kommt wieder die artikelnummer und alle attribute die die anderen typen nicht haben

den pk in den typspezifischen tabellen brauchst du nicht, durch die artikelnummer wäre das immer noch eindeutig. praktisch wird man wohl eher nach allen artikeln die ein tft von hersteller XY sind suchen oder nach einer artikelnummer, als nach einer nummer die außerhalb der software eigentlich keiner kennen könnte.

ja man kann Bilder in MySQL speichern. nur sinnvoll ist es nicht in jedem fall.

ob du das bild tatsächlich in die DB haben willst ist system abhängig. in einer desktop anwendung, kann es sinnvoll sein, speziell wenn du mehrere kleine bilder anzeigen willst.

zeigst du ein einzelnes dafür großes bild is das dateisystem wahrscheinlich der schnellere speicher.

für webapplikationen ist es weniger sinnvoll, da der browser für das bild sowieso einen weiten GET auslöst, musst du an der stelle das bild irgendwie aus der DB holen hast du als kosten den dateizugriff + script laufzeit + datenbakzugriff im vergleich zu einem einzelnen dateizugriff wenn du nur den pfad zum bild angeben musst

in jedem fall wird das dateisystem schneller wenn die BLOBs "sehr" groß werden..

[wahid]

Hallo _n4p_,

erstmal Danke für die Bemühung.

ok in "artikel" sind also 1..N verschiedene produkte pro datensatz die dann einzeln in den jeweiligen tabellen liegen?

=> Ganz genau!

allein das sind minimum 3 tabellen, daten zum lieferanten in der einen, daten pro lieferung in einer anderen und in die 3te kommen daten wie artikelnummer, liefernummer, menge, (stückpreis,...)

=> Wie würden dann die Beziehungen im Falls der drei Tabellen (LIEFERANT, LIEFERUNG, ARTIKEL) aussiehen ? so was ähnliches:

LIEFERANT - LIEFERUNG => 1:n ?

LIEFERUNG - ARTIKEL => 1:n ?

ARTIKEL - LIEFERANT => 1:1 bzw jeder Artikel kommt aus einem Lieferant?

den pk in den typspezifischen tabellen brauchst du nicht, durch die artikelnummer wäre das immer noch eindeutig. praktisch wird man wohl eher nach allen artikeln die ein tft von hersteller XY sind suchen oder nach einer artikelnummer, als nach einer nummer die außerhalb der software eigentlich keiner kennen könnte.

=> Wäre dann die Beziehung in dem Fall eine 1:1, d.h jeder ARTIKEL ist ein COMPUTER oder? Also in der Tabelle COMPUTER z.B wird kein PK geben? nur der FK von Artikel-Tabelle? Ist der PK bei MySQL-DB ungeachtet der DB-Größe nicht ein Muss?

ja man kann Bilder in MySQL speichern. nur sinnvoll ist es nicht in jedem fall.

ob du das bild tatsächlich in die DB haben willst ist system abhängig. in einer desktop anwendung, kann es sinnvoll sein, speziell wenn du mehrere kleine bilder anzeigen willst.

zeigst du ein einzelnes dafür großes bild is das dateisystem wahrscheinlich der schnellere speicher.

für webapplikationen ist es weniger sinnvoll, da der browser für das bild sowieso einen weiten GET auslöst, musst du an der stelle das bild irgendwie aus der DB holen hast du als kosten den dateizugriff + script laufzeit + datenbakzugriff im vergleich zu einem einzelnen dateizugriff wenn du nur den pfad zum bild angeben musst

=> Das wird ja auch eine DB einer Desktop Anwendung.

Danke dir

[_n4p_]

es gibt keine direkte beziehung zw artikel und lieferant. ist ja unnötig, da du über die lieferungen vom lieferant zu den artikeln und von den artikeln zum lieferant kommst

ein pk ist nicht notwendig. die beziehung zw computer und artikel ist eine generalisierung: computer ist ein artikel, aber artikel KANN ein computer sein. artikel kann aber auch ein tft sein.

du könntest auch jedem artikel ein set von eigenschaften zuordnen.

artnr, attributename, wert

111, taktfrequenz, 3GHz

111, cache, 3MB

112, diagonale, 24"

das ist dann sauber normalisiert.

[wahid]

Hallo "_n4p_",

Zuerst möchte ich dir für deine Bemühung wirklich sehr danken!

es gibt keine direkte beziehung zw artikel und lieferant. ist ja unnötig, da du über die lieferungen vom lieferant zu den artikeln und von den artikeln zum lieferant kommst

=> Soll dann also dieses Prozess so sein:

ARTIKEL

_____________________________________

ID| lieferung_ID|Attribute 1| Attribute 2|...

------------------------------------------

LIEFERUNG

___________________________

ID | Lieferant_ID| Attribute 1|...

-------------------------------

LIEFERANT

__________________________

ID| Attribute 1| Attribute 2| ...

------------------------------

ein pk ist nicht notwendig. die beziehung zw computer und artikel ist eine generalisierung: computer ist ein artikel, aber artikel KANN ein computer sein. artikel kann aber auch ein tft sein.

du könntest auch jedem artikel ein set von eigenschaften zuordnen.

artnr, attributename, wert

111, taktfrequenz, 3GHz

111, cache, 3MB

112, diagonale, 24"

=> Dann brauche ich hier in dem Fall das erweiterte ER-Modell und ist damit auch eine richtige Lösung. Aber da ich für MySQL-DB entschieden habe, weißt du wie ich eine "is-a" Beziehung mit MySQL umsetzen kann?

Nach der Arbeit werde ich das Modell überarbeiten, und ein Screenshot davon posten, damit du die "letzte Version" bewerten kannst. Danke dir

Grüße

[_n4p_]

zum ersten teil, genau so hatte ich das gemeint ^^

zum zweiten

artikel

------

id|lieferung_id|barcode|hersteller|modell|einzelpreis|artikelTyp|..

--------------------------------------------------------------

1|1|2452345|Samsung|Syncmaster XY|146.00|TFT

2|1|328783946|Samsung|Spinpoint M2|56.89|HDD

tabelle hdd:

-----------

artikelid|size|rpm|...

2|400GB|5400|..

tabelle TFT:

------------

artikelid|diagonale|HDMI|..

1|24|yes|..

SELECT * FROM artikel LEFT JOIN hdd ON (artikel.artikelid = hdd.artikelid) LEFT JOIN tft ON (artikel.artikelid = tft.artikelid) WHERE hersteller = 'Samsung'

hier wärs natürlich gut du wüsstest vorher welchen artikeltyp du grade suchst, leider kann MySQL keine tabellen als rückgabewert für funktionen, weshalb du selbst bestimmen musst welche tabellen beteiligt sind.

[wahid]

Hallo _n4p_,

im Anhang findest eine Übersicht vom DB-Modell, nachdem ich es nach deinen Vorschläge verbessert habe. Ich habe aber noch eine Frage, die ich selbst nicht beantworten konnte und zwar:

wie kriege ich, dass die Artikeltyps-tabellen die ID des entsprechenden Artikels zugewiesen bekommen? Weil nämlich, wenn ich artikel_ID als FK bei den Artikeltyp-tabellen dann bedeutet das eine 1-n Beziehung oder?

(Im Grafik siehst du den zweiten Teil meiner DB, es geht um Reparaturaufträge, wenn du magst, du kannst den auch auf Fehler prüfen :-) ).

Danke dir

Gruß

[_n4p_]

im ER modell gibt es keine spezialisierung bzw generalisierung, das gibts soweit ich weiß erst im EERM:

Grundlagen von Datenbanksystemen - Google Bücher

da siehst du die darstellung in einem UML diagramm, das dreieck ist das was du suchst.

die reperaturen sehen auf die schnelle ganz gut aus, wo ist denn da das problem?