Produkt-Datenbank

[FrankiLi]

Hallo zusammen,

ich hatte hier schon einmal mein Vorhaben kurz erläutert, allerdings bezogen auf ein Detailproblem und auf Warengruppen bezogen (soll im Folgenden erst mal irrelevant sein). Hier etwas konkreter bzw. zum "Einstieg" ein Grundsatzproblem, auch deshalb, weil ich hier bisher schon super Hilfe erfahren habe, tolles Forum, sehr kompetente und angenehme Mitglieder, danke!

Produkt-Datenbank
• ca. 10.000 Grund-Artikel
• ca. 500.000 SKU (bestellbare Artikel, die sich aus Grund-Artikel + Varianten-Dimensionen bilden)

• Pro Grund-Artikel bis zu 5 Varianten-Dimensionen (= Farbe, Größe, ...) mit je bis zu 10 möglichen Werten (= weiß, gelb, grün...160, 170, 180...)
   • Produktübergreifend ca. 40 Varianten-Dimensionen insgesamt
   • Varianten-Dimensionen sind sinngemäß die Dropdown-Felder in einem Webshop, durch die Auswahl wird der SKU definiert

• Pro SKU bis zu 25 Attribute (= Material, detailliertere Maße ....)
   • Produktübergreifend ca. 80 Attribute insgesamt
   • Attribute sind sinngemäß die Werte in einer Tabelle, die nach Definition des SKU als Information vorliegen

Das Ganze soll Datenbank-gerecht, normalisiert aufgebaut werden (der Export muss dann vermutlich doch wieder flach sein, aber das ist ggf. ein eigenes Thema).

Nun habe ich ein erst mal ein grundsätzliches Logik-Problem:

Die Artikelnummer (vergeben wir selbst neu) muss ja eindeutig sein und ist ja DER Schlüssel schlechthin. Diese ist so aufgebaut: ABC123-xxx
ABC123 ist der Grundartikel
xxx ist eine laufende Nummer für den aus der Kombination der Varianten-Dimensionen resultierenden SKU
z.B.:
• ABC123-001  = Farbe weiß, Größe 180
• ABC123-002  = Farbe weiß, Größe 190
• ABC123-003  = Farbe gelb, Größe 180
usw.
Übrigens sind wir in der Gestaltung der Artikelnr frei, das "xxx" könnte auch anders organisiert sein.

Das Problem:
Wenn ich nun eine Grundtabelle, nennen wir sie tblMain, aufbaue und in dieser die Grundartikel (ABC123) pflege, dazu die Varianten-Dimensionen und deren Werte in separaten 1:n-Tabellen zuordne...
• ... wie kann ich dann die endgültige Artikelnr, die natürlich fix sein muss, ermitteln und wo hinterlegen?
• ... wie ordne ich dann die Attribute, die pro SKU/Variante unterschiedlich sein können, den SKU (nicht den Grundartikeln!) zu? Diese ergeben sich ja erst aus der Kombination Grundartikel>Variantendimensionen>Werte und somit aus der endgültigen Artikelnr ABC123-xxx.

Das ist ein Problem, das es einer flachen Tabelle (xls-like) ja nicht gibt, dort gibt es 500.000 Zeilen mit SKU und die entsprechenden Werte pro SKU und fertig. Aber vom flachen Aufbau will ich ja weg, allerdings nur, wenn das realisierbar ist und Sinn macht.

Ich könnte jetzt noch viel mehr Fragen zum Aufbau stellen, aber das o.g. ist für mich ein ganz elementares Gestaltungsproblem, und ich hoffe sehr auf Hilfe von Euch. Hoffe, ich habe mein Problem verständlich geschildert, sonst bitte fragen.

Vielen Dank!

Gruss
Frank

[Josef P.]

Hallo!

Vorab zum Verständnis (für mich):
Es gibt Varianten von den Artikeln. Du benötigst aber keine Variantenstücklisten - also die Bauteile eines Artikels je nach Variante unterschiedlich ausführen.

Die Varianten werden somit über "variable Eigenschaften" des Grundartikels definiert.
Die Eigenschaftsgruppen (Farbe, Höhe, Breite, Material, Geschmack usw.) sind je Artikel in unterschiedlichen Kombinationen verwendet.

Ich stelle einmal folgenden Aufbau zur Diskusssion:

tblArtikel (= Grundartikel )
- idArtikel (int, PK)
- Grundbezeichnung
- ....

tblEigenschaften ( = Größe, Höhe usw.)
- idEigenschaft
- Eigenschaftsname
- ...

tlbEigenschaftsWerte ( = Zugelassene Werte je Eigenschaft)
- fiEigenschaft (FK zu tblEigenschaften.idEigenschaft)
- idWert (! nicht PK)
- EigenschaftsWert (varchar(n), solange du damit nicht rechnen musst, ist kein extra Zahlendatentyp erforderlich)
- ...
2-Felder-PK = fiEigenschaft + idWert

tblArtikel_Eigenschaften (  = die beim jeweiligen Artikel erlaubten Eigenschaften)
- fiArtikel  (FK zu tblArtikel.idArtikel)
- fiEigenschaft (FK zu tblEigenschaften.idEigenschaft)
PK = 2-Felder-PK: fiArtikel + fiEigenschaft

tblArtikel_EigenschaftsWerte
- fiArtikel
- fiEigenschaft
- fiEigenschaftsWert

PK = 3-Felder-PK (oder auch Autowert, ist egal)
Wichtig sind hier die Fremdschlüssel:
1. FK: fiArtikel + fiEigenschaft zu tblArtikel_Eigenschaften.fiArtikel   + tblArtikel_Eigenschaften.fiEigenschaft
2. FK: fiEigenschaft + fiEigenschaftsWert zu tlbEigenschaftsWerte.fiEigenschaft + tlbEigenschaftsWerte.idWert


Surrogatschlüssel mit einem Autowertfeld kannst natürlich immer ergänzen, falls es dir das Ansprechen der einzelnen Datensätze erleichtert. Die kombinierten PK/FK ermöglichen jedoch eine datentechnische Regelung, dass keine Eigenschaft bzw. kein Eigenschaftswert dem Artikel zugeordnet ist, der nicht zuvor "freigegeben" wurde.

Als "Artikelnummer" für den Verkaufsartikel könnte ich mir eine Nummer vorstellen, die aus den Eigenschaftskennungen und aus den Wertkennungen (also aus den Daten von tblArtikel_EigenschaftsWerte) berechnet wird.

Zum Überlegen ist, ob es vielleicht trotzdem sinnvoll ist, eine extra Tabelle mit Verkaufsartikeln zu führen.
Denn irgendwann wird es vorkommen, dass die Farbe "Blau" bei einem Artikel nicht mehr verkauft wird, die Information, dass es den Artikel in Blau gegeben hat, aber erhalten bleiben muss. Und das muss dann ja auch irgendwie gespeichert werden. .. oder ist das dann bereits Aufgabe vom ERP-System?

/edit:
Falls es viele ähnlich Hauptartikel gibt, ist vielleicht eine zusätzliche Tabelle für Artikelgruppen nützlich. Dann könnte man in dieser die erlaubten Eigenschaften festlegen und müsste das nicht je Artikel machen.

mfg
Josef

[FrankiLi]

Hallo Josef,
vielen Dank erstmal.

Es gibt nur Variante von den Artikeln. Du benötigst aber keine Variantenstücklisten - also die Bauteile eines Artikels je nach Variante unterschiedlich ausführen.

Falls Du damit meinst, ob ein Artikel/SKU mit einem anderen kombiniert werden kann: Nein.

Ich übersetze mal Deine Struktur grob in ein Beispiel, damit ich es sicher verstehe:

tblArtikel:
  ABC123 | Sofa Modell Sowieso   (gibt's angenommen in Größe 170 und 180, Farbe irrelevant)

tblEigenschaften:
  Größe
  Farbe

tblEigenschaftswerte:
  (Größe): 170 | 180 | 190
  (Farbe): weiß | gelb | grün

tblArtikel_Eigenschaften:
  ABC123 hat Größe, aber keine Farbe
  ABC123 gibt's in Größe 170 und 180

tblArtikel_EigenschaftsWerte:
  definiert nur intern die Beziehung von Grundartikel zu Eigenschaft zu Eigenschaftswert

Artikelnummer ergibt sich so:
ABC123-[idEigenschaft]&[idWert]- [idEigenschaft]&[idWert]- usw

--- soweit richtig verstanden? ---

Allerdings fehlt ja dann noch das, was ich als Attribute (also nicht die SKU-definierenden Variantendimensionen) bezeichnet habe, an meinem o.g. Beispiel Material oder detaillierte Maße. Würde ich damit nach dem gleichen Prinzip weitermachen, also die fertige Artikelnr dann mit fixen Attributen ausstatten?

Gruss
Frank

[Josef P.]

Unten ist noch eine kleine Korrektur, ansonsten meinte ich das genau so.

tblArtikel_Eigenschaften:
  ABC123 hat Größe, aber keine Farbe
 
tblArtikel_EigenschaftsWerte:
  ABC123 gibt's in Größe 170 und 180
  ABC123 können keine Farben ausgewählt werden, da diese in tblArtikel_Eigenschaften nicht freigegeben wurde.

Allerdings fehlt ja dann noch das, was ich als Attribute (also nicht die SKU-definierenden Variantendimensionen) bezeichnet habe, an meinem o.g. Beispiel Material oder detaillierte Maße.

Diese fixen Attribute könnten auch in die gleiche Struktur. Allerdings darf dann nur 1 Wert dafür gespeichert werden. (Ob fix oder mehrfache Auswahl möglich ist, könnte man vielleicht als weiteres Attribut in die Tabelle tblArtikel_Eigenschaften speichern.
Sobald eine Eigenschaft (oder sollte das eher Eigenschaftskategorie heißen?) mehr als einen Wert hat, können Kombinationen davon in der "Verkaufsartikel-Erstellung" erzeugt werden.

Jetzt fällt mir noch etwas ein:

Artikel ABC123:
in Größe 170 gibt es die Farben: blau, rot und grün
Größe 180 gibt es nur in blau.

Kann so etwas auch vorkommen?

[FrankiLi]

Artikel ABC123:
in Größe 170 gibt es die Farben: blau, rot und grün
Größe 180 gibt es nur in blau.
Kann so etwas auch vorkommen?

Ja, unbedingt.

Was mich generell noch etwas "stört" (ohne zu wissen, ob zu Recht, das ist der Punkt), ist die Tatsache, dass die immens wichtige fertige Artikelnummer, die ja auch fürs Lager etc. relevant ist und sich nie ändern darf, so "dynamisch" zusammengesetzt wird. Ist das nicht etwas gefährlich, oder denke ich da zu vorsichtig? Geht ja wahrscheinlich nicht anders, alles andere wäre ja komplett flach. Jedenfalls wird mir klar, warum es so wenige fertige, gute Lösungen für variantenreiche Konstellationen gibt im Bereich der PIM...

[Josef P.]

Darum schrieb ich "Zum Überlegen ist, ob es vielleicht trotzdem sinnvoll ist, eine extra Tabelle mit Verkaufsartikeln zu führen."

Ich könnte mir das so vorstellen:
In der Artikelverwaltung werden die möglichen Eigenschaften und deren Werte zum Hauptartikel definiert.
Dann lässt man sich von diesem Artikel die Varianten in einer Liste anzeigen und wähle jene aus, die es als Verkaufsartikel geben soll.
Anschließend wird dieser Verkaufsartikel in eine Tabelle geschrieben und eine ähnliche Struktur für die Eigenschaften befüllt - allerdings immer nur ein Wert je Eigenschaft zum jeweiligen Verkaufsartikel.
.. Oder du schreibst die Eigenschaften in die gleiche Tabellenstruktur und verpasst dem Artikel in der Artikelkennung ein Attribut, damit man Haupt- und Verkaufsartikel unterscheiden kann. (Das Schreiben in die gleiche Artikel-Struktur hätte auch den Vorteil, dass du einen bereits vorhandenen "Verkaufsartikel" bei Bedarf noch einmal unterteilen könntest.)
Bezüglich fixe Eigenschaften könnte man dann noch so vorgehen, dass zum Verkaufsartikel nur die Eigenschaften gespeichert werden, die aus den variablen Eigenschaften des Hauptartikels entstanden sind und die fixen Eigenschaften des Hauptartikels nimmt man immer von dort.
Für die Beschreibung eine Verkaufsartikels setzen sich dann die Eigenschaften aus den im Verkaufsartikel fixierten Eigenschaften und aus den fixen Eigenschaften des Hauptartikels zusammen.

Dann würde dann auch

Artikel ABC123:
in Größe 170 gibt es die Farben: blau, rot und grün
Größe 180 gibt es nur in blau.
Kann so etwas auch vorkommen?

Ja, unbedingt.

abdecken.
Ohne manuelle Auswahl der Eigenschaftskombinationen zum Hauptartikel wird das meiner Meinung nach ein kompliziertes Definieren der Eigenschaftswerte die miteinander in Kombination vorkommen können. Bei 2 Eigenschaften ist das vielleicht noch machbar  - aber was ist, wenn ein Artikel 5 variable Eigenschaften besitzt?

Wo beginnt eigentlich die Aufgabe des ERP? Falls ich mich richtig erinnere, ist doch die aktuell von dir beschriebene Aufgabenstellung zum Befüllen einer Artikel-Liste in einem ERP. - Warum soll sich dieses System nicht darum kümmern, dass die Artikel bestehen bleiben. Ich nehme an, dass die Lagerwirtschaft auch im ERP laufen wird.

mfg
Josef

[FrankiLi]

Das mit der Extra-Tabelle habe ich wohl übersehen, vielleicht war es auch ein Nachtrag.

Wo beginnt eigentlich die Aufgabe des ERP? Falls ich mich richtig erinnere, ist doch die aktuell von dir beschriebene Aufgabenstellung zum Befüllen einer Artikel-Liste in einem ERP. - Warum soll sich dieses System nicht darum kümmern, dass die Artikel bestehen bleiben. Ich nehme an, dass die Lagerwirtschaft auch im ERP laufen wird.

Da erinnerst Du Dich richtig.
Die Frage, welches System nachher führend in der Artikelstamm-Pflege ist, ist noch nicht geklärt. Im Moment geht es um die Erstbefüllung, aber je besser das System funktionierend, umso eher würde ich die Führung bei der Access-DB sehen. Natürlich nicht in Bezug auf Lagerbestände. Aber für vieles andere wäre die Access-DB viel einfacher zu händeln, zB Lieferant schickt xls mit neuen Preisen für 5.000 Artikel - in Access viel einfacher zu händeln als mit manuellen Ex- und Importen, Aktualisierungsabfrage mit neuen EKs und darauf basierend neu kalkulierten VKs und ferddich.

Du meinst, die ERP könnte führend in Punkto fertiger Artikelnummer sein und mein "Problem" mit dieser Dynamik in der Artikelnrvergabe/des Festhaltens lösen, richtig?

Das könnte weiter gedacht bedeuten:
- Neue Artikel (jetzt in der Massenanlage und später bei neuen Sortimenten): Anlage in der Access-DB
- Bestehende Artikel: Artnr führend in der ERP, verknüpfte Tabelle von dort nach Access, dadurch Pflege mit direkter Zuordnung zum ERP-Artikel möglich. Wobei hier ja die schön aufgebaute Struktur für die Erstanlage nichts mehr nützt und das Ganze viel flacher abgehandelt wird (vermute ich, so tief bin ich in den Möglichkeiten der ERP noch nicht drin).

In der Artikelverwaltung werden die möglichen Eigenschaften und deren Werte zum Hauptartikel definiert.
Dann lässt man sich von diesem Artikel die Varianten in einer Liste anzeigen und wähle jene aus, die es als Verkaufsartikel geben soll.

Eine Art vorgelagerter Varianten-Konfigurator, der dann aber keine ,,flache" Tabelle produziert, sondern wieder eine normalisierte mit 1:n Artikel>Eigenschaft + Wert, richtig?

.. Oder du schreibst die Eigenschaften in die gleiche Tabellenstruktur und verpasst dem Artikel in der Artikelkennung ein Attribut, damit man Haupt- und Verkaufsartikel unterscheiden kann.

Meinst Du damit, dass nachher in einer Artikeltabelle steht
ABC123 Sofa Sowieso | Artikelart: Grund
ABC123-001  Sofa Sowieso | Artikelart: SKU / Farbe weiß   (natürlich nur sinngemäß)

Bezüglich fixe Eigenschaften könnte man dann noch so vorgehen, dass zum Verkaufsartikel nur die Eigenschaften gespeichert werden, die aus den variablen Eigenschaften des Hauptartikels entstanden sind und die fixen Eigenschaften des Hauptartikels nimmt man immer von dort.

Hieße am o.g. Beispiel:
ABC123 Sofa Sowieso   /  Material: Stoff
ABC123-001  Sofa Sowieso Farbe weiß  / automatisch aus ABC123: Material Stoff

Ohne manuelle Auswahl der Eigenschaftskombinationen zum Hauptartikel wird das meiner Meinung nach ein kompliziertes Definieren der Eigenschaftswerte die miteinander in Kombination vorkommen können. Bei 2 Eigenschaften ist das vielleicht noch machbar  - aber was ist, wenn ein Artikel 5 variable Eigenschaften besitzt?

Deshalb ja auch die Grundsatz-Diskussion über den Grundaufbau: Ich wills so einfach wie möglich, aber komplex/kompliziert wie nötig, um in keine Sackgasse zu fahren

[Josef P.]

Eine Art vorgelagerter Varianten-Konfigurator, der dann aber keine ,,flache" Tabelle produziert, sondern wieder eine normalisierte mit 1:n Artikel>Eigenschaft + Wert, richtig?

Genau.

Hieße am o.g. Beispiel:
ABC123 Sofa Sowieso   /  Material: Stoff
ABC123-001  Sofa Sowieso Farbe weiß  / automatisch aus ABC123: Material Stoff

Ja. Material Stoff müsste nicht unbedingt dem Artikelstamm ABC123-001 zugeordnet sein. Dafür muss natürlich der Artikel seinen Basisartikel kennen.

Tabelle könnte dann so aussehen:
- idArtikel
- fiBasisArtikel (FK zu idArtikel)
- Artikelbezeichnung
- ...

Der Wert in fiBasisArtikel wäre beim Basisartikel NULL und beim einem SKU würde die ID vom Basisartikel enthalten sein.

Jetzt kommt noch ein ABER:
Bei dieser geschachtelten Struktur ist zu beachten, dass sich für alle SKU-Artikel die im Basisartikel festgelegten Eigenschaften ändern wenn sie im Basisartikel geändert werden. Sobald ein SKU also bestellt/produziert wird bzw. auf Lager liegt, darf man diese Basis-Artikel-Eigenschaften sowie die speziellen Eigenschaften des SKU-Artikels nicht mehr ändern.
Wenn ich jetzt bei einem für das ERP freigegebenen Artikel eine Basis-Eigenschaft ändern will, würde das eine neue Artikelnummer erzwingen.

Möglicherweise ist es aus Praxis-Sicht daher besser, wenn man den Basis-Artikel eher als Vorlage zum Generieren der eigentlichen Artikel betrachtet und zum SKU-Artikel alle Eigenschaften speichert. (Das ist zwar etwas redundant, erlaubt aber eventuell eine flexiblere Handhabung der SKU-Artikel, falls das benötigt wird.)
Später kann man immer z. B. im Basisartikel eine fixe Eigenschaft ändern und bei Bedarf diese Eigenschaft noch programmtechnisch in alle damit verknüpften SKU-Artikel weiterreichen (Update-Anweisung).
Eventuell benötigst du dann auch noch eine Versionsverwaltung der Artikel.

Im Prinzip ist das eine Entscheidung zw.
* vollständig geführter SKU-Artikelstamm mit allen Eigenschaften (nur die Erzeugung erfolgt halbautomatisiert über "Vorlagen")
und
* Varianten-Datensätze mit eigenen Eigenschaften und den "übergeordneten" Eigenschaften des Basisartikels.

Die Variante mit den abhängigen Artikeldaten würde keine redundaten Daten speichern.
Bei der Variante mit den "vollständigen" Daten je SKU, würde die Möglichkeit bestehen ein "Basiseigenschaft" in nur einem SKU-Artikel zu ändern. Die Frage nun: soll oder darf das sein?

mfg
Josef

[FrankiLi]

Bei dieser geschachtelten Struktur ist zu beachten, dass sich für alle SKU-Artikel die im Basisartikel festgelegten Eigenschaften ändern wenn sie im Basisartikel geändert werden. Sobald ein SKU also bestellt/produziert wird bzw. auf Lager liegt, darf man diese Basis-Artikel-Eigenschaften sowie die speziellen Eigenschaften des SKU-Artikels nicht mehr ändern.
Wenn ich jetzt bei einem für das ERP freigegebenen Artikel eine Basis-Eigenschaft ändern will, würde das eine neue Artikelnummer erzwingen.

Der Fall wäre ja zB beim Sofa: Material ändert sich von Stoff auf irgendwas anderes. Oder die Abmessungen ändern sich. Das, was ich als fixe Attribute o.ä. bezeichnet hatte.

Stimmt, der Einwand ist korrekt, wobei ich das bei uns nicht (bzw. sowieso) sehe, denn dadurch würde sich ja auch zwangsläufig die Werks-Artikelnr ändern (fix zugeordnet, eine SKU bei uns = eine beim Lieferanten), was schon dadurch definitiv einen neuen Artikel bedeutet. Ansonsten beschränken sich die fixen Attribute mehr auf Anreicherung, d.h. es kommt ein Attribut ,,Form" dazu, um Kunden mehr Infos zu geben, das gilt dann widerrum für Basisartikel und SKU. Die Verschachtelung ist also eher ein Vorteil als ein Aber.

PS zu Deinem Nachtrag:

Bei der Variante mit den "vollständigen" Daten je SKU, würde die Möglichkeit bestehen ein "Basiseigenschaft" in nur einem SKU-Artikel zu ändern. Die Frage nun: soll oder darf das sein?

Ich glaube, das muss ich konkreter: Als Basis-Eigenschaft würde ich ja nur definieren, was für alle SKU gilt. Daneben gibt es schon Eigenschaften, die auf SKU-Ebene gepflegt werden müssen.
Beispiel: Sofa in Größe 170 | SKU-Eigenschaft Gewicht = xy  (in Größe 180 ein anderes Gewicht) / EDIT: siehe nächster Beitrag konkreter

Möglicherweise ist es aus Praxis-Sicht daher besser, wenn man den Basis-Artikel eher als Vorlage zum Generieren der eigentlichen Artikel betrachtet und zum SKU-Artikel alle Eigenschaften speichert. (Das ist zwar etwas redundant, erlaubt aber eventuell eine flexiblere Handhabung der SKU-Artikel, falls das benötigt wird.)

Etwas Redundanz macht mir nichts, das meinte ich auch mit (nur) so komplex wie nötig, also keine Nicht-Redundanz als Selbstzweck, während sie unpragmatisch wäre.

Wenn aber nur der vorgenannte Punkt (Stoff ändert sich) gegen eine saubere, nicht-redundante Lösung spricht, darfs also gerne auch nicht-redundant sein...

Im Prinzip ist das eine Entscheidung zw.
* vollständig geführter SKU-Artikelstamm mit allen Eigenschaften (nur die Erzeugung erfolgt halbautomatisiert über "Vorlagen")
und
* Varianten-Datensätze mit eigenen Eigenschaften und den "übergeordneten" Eigenschaften des Basisartikels.

Vielleicht an der Stelle jetzt mal dazu, wie es nach dem ganzen Prozedere weitergeht, möglicherweise hat das noch Einfluss auf die Entscheidung:

Voraussichtlich* muss der Export an die ERP flach erfolgen, ungefähr so:
ArtNrBasis | ArtNrSKU | Material (fix) | Farbe (Varianten-Dim.) | dynamisches Attribut | Wert
ABC123 | ABC123-023 | Stoff | weiß | Anzahl Füße | 4
ABC123 | ABC123-047 | Stoff | gelb | Anzahl Füße | 4

Heißt, ich müsste die ,,Relationalität"/Beziehungen wieder auflösen und das Ergebnis relativ flach ausspucken. Dynamisches Attribut heißt übrigens, dass es überhaupt für den Artikel relevant ist, ein Wandspiegel hätte keine ,,Anzahl Füße" etc...
Würde der Sachverhalt für Dich noch für die eine oder andere Lösung sprechen oder sonstwie Einfluss auf eine Grundsatzentscheidung haben?

Und, möglicherweise nicht relevant, noch eins: Die Verarbeitung in der Access-DB erfolgt in der Erstanlage (Masse), wenn Artikel in einer xls geliefert werden. D.h. Mitarbeiter legen in einer xls (flach) an, das soll auch in dieser Phase nicht geändert werden. Heißt, ich müsste noch einen Import-Mechanismus bauen, um von flach auf relational zu ändern, und anschließend wieder flach auszuspielen. Konfigurator usw macht trotzdem Sinn, denn wenn alles mal angelegt ist und es später im Tagesgeschäft nur um ein paar neue Artikel geht, kann das auch direkt in der Access-DB erfolgen.

*eventuell lässt sich die Access-DB noch eleganter anbinden, das steht aber momentan in den Sternen.

[FrankiLi]

Ich muss das mit den Eigenschaften etc., glaube ich, nochmal klarer/vollständiger machen, sorry, wenn ich da zu unspezifisch war.

Es gibt:

• Varianten-Dimensionen, zB Farbe, die in Kombination mit den Werten den SKU bilden
Bsp.: Sofa ABC123, Farbe: weiß ABC123-001

• Fixe Attribute
Diese können
a) für alle Sofas in allen Varianten gelten (=Zuordnung zum Basisartikel, Beispiel: Material Stoff)
aber auch
b) nur pro SKU gelten (Beispiel: klare Werks-Artikelnummer oder EAN)
Diese fixen Attribute bzw. entsprechenden Felder gibt es in der ERP bei jedem Artikel.
zB: Werks-Artikelnummer: [Wert]

• Dynamische Attribute
Wie die fixen Attribute, aber die Zuordnung, ob das Attribut relevant ist, erfolgt pro Artikel.
Beispiel: Anzahl Füße (und der entsprechende Wert 4) ist relevant bei Sofas, aber nicht bei Wandspiegeln.
zB in der ERP: Dynamisches Attribut 1 (zB Anzahl Füße): Wert (zB 4)
Die Zuordnung (hat ein Artikel das Attribut "Anzahl Füße"?) soll/kann auf Basisartikel-Ebene definiert werden, der Wert dann auf SKU-Ebene.

[Josef P.]

EAN, Gewicht und ähnliche Daten würde ich direkt als Attribut in der Artikeltabelle führen und nicht in die Eigenschaften-Tabelle aufnehmen.

Heißt, ich müsste die ,,Relationalität"/Beziehungen wieder auflösen und das Ergebnis relativ flach ausspucken. Dynamisches Attribut heißt übrigens, dass es überhaupt für den Artikel relevant ist, ein Wandspiegel hätte keine ,,Anzahl Füße" etc...
Würde der Sachverhalt für Dich noch für die eine oder andere Lösung sprechen oder sonstwie Einfluss auf eine Grundsatzentscheidung haben?

Das lässt sich durchaus aus einer normalisierten Sturktur so abbilden. Einfachste Variante: Zuerst kommen die Attribute die direkt in der Artikeltabelle gespeichert sind. Dann kommen alle Eigenschaften aus der Tabelle "tblEigenschaften" und wenn es zum Artikel für die jeweilige Spalte einen Wert gibt, steht der dort.
(Bei Access musst du nur beachten, dass nicht mehr als 255 Spalten in einer Abfrage möglich sind.)

D.h. Mitarbeiter legen in einer xls (flach) an

Warum legt der Mitarbeiter die Artikel nicht gleich im Access-Frontend an?

[FrankiLi]

Warum legt der Mitarbeiter die Artikel nicht gleich im Access-Frontend an?

Weil es kein Frontend gibt, das ihm mehr ermöglicht als eine .xls (Runterziehen, schnelle Formeln). Würde die Erfassung erst beginnen, wenn die DB steht, wäre das was anderes, aber Artikel-Vor-Erfassung (xls) und DB-Aufbau laufen halt aus Zeitgründen parallel, da war/ist das die pragmatischste Lösung, um strukturiert aufzubauen ohne dadurch Zeit zu verlieren. Eventuell will ich bewusst diesen Weg auch für die Zukunft beibehalten - weil gewohnt, einfach + eine eingebaute Hürde, bevor die Daten in die "echte" DB kommen.

Zum Ganzen nochmal, und entschuldige die fast schon provokative Frage:
Was spricht kolossal dagegen, das Ganze einfach flach in einer Tabelle (bzw. mehreren mit 1:1 verbunden) abzubilden?
Klar spricht das gegen alle Grundsätze einer normalisierten DB, es kommen Daten x-fach vor (zB bei 50.000 Artikeln der gleiche Hersteller) und eine Erfassung direkt in Access wird dadurch nicht gerade elegant, aber zB könnte man wiederkehrende Felder per Nachschlagefelder realisieren, um Fehler zu vermeiden.

Ich sage nicht, dass ich das so machen will, muss mir aber immer wieder kurz klar machen, warum ich den erst mal schwereren Weg gehe und inwiefern die Vorteile die Nachteile überwiegen. Auch um sicher zu sein, dass ich den normalisierten DB-Aufbau nicht überwiegend als Selbstzweck betreibe.

[Josef P.]

Eventuell will ich bewusst diesen Weg auch für die Zukunft beibehalten - weil gewohnt, einfach + eine eingebaute Hürde, bevor die Daten in die "echte" DB kommen.

Dann bleib aber konsequent und mach gleich die ganze Artikelverwaltung im Excel.

Warum sollen die Daten in eine Excel-Liste einfacher zum Eingeben sein als in ein Access-Frontend?
Das ist doch nur dann der Fall, wenn das Frontend am Anwender vorbei gestaltet wird.
Bitte beachte: die Tabellenstruktur soll dem Anwender egal sein. Die kann noch so komplex aufgebaut sein, solange der Anwender die Daten in übersichtlich gestaltete Formulare eingibt, wird er zufrieden sein und vermutlich schneller als in Excel, wo er bei vielen Spalten 3 Bildschirme nebeneinander benötigt um alle Daten eines Artikels sehen zu können.
Immer im Hinterkopf halten: Der Anwender tippt nicht in die Tabellen sondern in für ihn optimierte Masken ein.

Was spricht kolossal dagegen, das Ganze einfach flach in einer Tabelle (bzw. mehreren mit 1:1 verbunden) abzubilden?

Gegenfrage: Was spricht gegen falsche Daten bzw. gegen Daten, auf die man sich nicht verlassen kann?
Wie stellst du sicher, dass bei Änderung in einem Datenfeld eines dieser Datensätze alle anderen Datensätze auch geändert werden, weil das Daten des Basisartikels sind?
Natürlich kann man auch in einer flachen denormalisierten Struktur eine brauchbar Anwendung erstellen. Man muss nur programmtechnisch  dafür sorgen, dass kein Datenmüll (falsche Daten) entsteht.
Bei einer normalisierten Struktur würde die Datenstruktur diesen Datenmüll verhindern.


Damit wir nicht aneinander vorbei reden:
Es geht dir vermutlich vor allem um diese Eigenschaften-Tabellen. Das hat meiner Meinung nach gar nicht so viel mit Normalisierung zu tun.
Wenn die Eigenschaftsnamen unverändert bleiben, kannst du durchaus überlegen, diese als Attribute im Artikelstamm zu speichern. Das
widerspricht nicht dem Normalisierungsgedanken. Nur weil ein paar Felder leer bleiben, muss das kein falsches Datenmodell sein. Es muss aber auch nicht ganz richtig sein. Allerdings baut man das Datenmodell nicht für einen Normalisierungsverein sondern für die jeweilige Anforderung, um damit mit möglichst wenig Aufwand zum Ziel zu kommen.

Beispiel: je nach Artikel gibt es bestimmte Eigenschaften oder auch nicht. Wenn du alle Eigenschaften im Artikelstamm (bzw. in 1:1-verknüpften Tabellen) hast, musst du per Client die richtigen Felder anbieten.
Liegen die erlaubten Eigenschaften in Listenform vor, musst du nur ein Endlosformular verwenden und kannst neben dem Eigenschaftsnamen den Wert eintragen lassen.

Diese Eigenschaftslisten würde ich allerdings auch nicht für in jedem Artikel vorhandene Eigenschaften verwenden. Die Artikelnummer als Eintrag in der Eigenschaftentabelle würde ich nicht machen.
Für dein Szenario sehe ich den Nutzen der Eigenschaften in einer 1:n-Struktur aber gar nicht so sehr im festhalten der Eigenschaften sondern im Erzeugen der Varianten.
Ein cross join ist viel einfacher erstellt als aus einer fachen Hierarchie alle möglichen Kombinationen abzuleiten.

Außerdem: für eine flache Struktur musst du entweder für jedes Eigenschaftsfeld eine n:m-Tabelle führen (das entspricht ungefähr den Mehrwertigen Feldern in Access) oder du führst nur eine Tabelle, musst in dieser, um das passende Feld zu treffen, eine Eigenschaften-Kennung mitführen. Bei letzterem sind wir dann wieder bei dieser Tabelle:

tblArtikel_EigenschaftsWerte
- fiArtikel
- fiEigenschaft .. das wäre dann die Kennung für das Artikelfeld
- fiEigenschaftsWert

=> Das Ziel (zumindest für die Basisartikel) ist das gleiche - der kann anders sein.

[FrankiLi]

Dann bleib aber konsequent und mach gleich die ganze Artikelverwaltung im Excel.

Nö Alleine schon wegen Aktualisierungsabfragen nach x Kriterien.

Wie stellst du sicher, dass bei Änderung in einem Datenfeld eines dieser Datensätze alle anderen Datensätze auch geändert werden, weil das Daten des Basisartikels sind?

Gar nicht (automatisiert), daran müsste ich bzw. derjenige, der das in die DB einspielt/dort pflegt ,,mit dem Kopf" wissen. Bei normalisiert müsste ja auch einer ,,mit dem Kopf wissen", dass Änderungen am Basisartikel sich automatisch auf die Kinder auswirken.

Wenn die Eigenschaftsnamen unverändert bleiben

Das tun sie. Es werden nur einige dazu kommen.

Allerdings baut man das Datenmodell nicht für einen Normalisierungsverein sondern für die jeweilige Anforderung, um damit mit möglichst wenig Aufwand zum Ziel zu kommen. 

Nur weil ein paar Felder leer bleiben, muss das kein falsches Datenmodell sein.

Das nenne ich mal pragmatisch, ganz ehrlich, ich fühle mich mit Deiner Denkweise sehr wohl.
Wobei hier ,,ein paar" relativ (...) ist: Bei produktübergreifend 40 Varianten-Dimensionen werden pro Produkt maximal 5, bei 80 dynamischen Attributen pro Produkt maximal 25 verwendet, da bleibt halt viel leer.

BTW, falls das nicht eh schon glasklar sein sollte, natürlich versuche ich mir nicht, die nicht-normalisierte xls-like Lösung zu verkaufen, dann wäre ich im falschen Forum. Aber halt auch nicht zwanghaft das ,,Gegenteil". Du hast das aber schon so verstanden, wie ich sehe.

Für dein Szenario sehe ich den Nutzen der Eigenschaften in einer 1:n-Struktur aber gar nicht so sehr im festhalten der Eigenschaften sondern im Erzeugen der Varianten.

Quasi der ,,Varianten-Generator" von oben. Klar, an dem gibt's keinen Zweifel. Habe so was dank Klaus aus dem Forum hier schon im Einsatz, auch wenn das Ergebnis erst mal wieder in die .xls kopiert wird...
Also dem Gedanken folgend könnte eine Art ,,Hybrid" die Lösung sein:
-   Varianten-Generieren mit 1:n
und dann:
-   Varianten-pflegen 1:1/flach

Außerdem: für eine flache Struktur musst du entweder für jedes Eigenschaftsfeld eine n:m-Tabelle führen (das entspricht ungefähr den Mehrwertigen Feldern in Access) oder du führst nur eine Tabelle, musst in dieser, um das passende Feld zu treffen, eine Eigenschaften-Kennung mitführen. Bei letzterem sind wir dann wieder bei dieser Tabelle:

Das stimmt allerdings.

[Josef P.]

natürlich versuche ich mir nicht, die nicht-normalisierte xls-like Lösung zu verkaufen, dann wäre ich im falschen Forum. Aber halt auch nicht zwanghaft das ,,Gegenteil".

Wenn du die Tabellen "objektorientiert" normalisierst wirst du feststellten, dass du meist in der 3. oder höherer Normalform bist.

Mit "objektorientiert" normalisieren meine ich: Für Attribute in einer Klasse (steht symbolisch für einen Datensatz), für die man in der OOP eine weitere Klasse verwenden würde, verwendet man in der DB eine extra Tabelle und trägt nur noch den PK dieser Tabelle im Datensatz ein.
Eine 1:n-Struktur würde im obigen Gedankenexperiment mit OOP eine Auflistungsklasse sein.

Wenn ich eine Tabellenstruktur gestalten, dass gehe ich meist nach dieser Variant vor. Dass ich dabei irgendwelche Normalisierungsregeln verwende, kommt bestimmt vor. Ich kann dir diese Regeln allerdings nicht auswendig aufsagen, die ergeben sich automatisch.

Also dem Gedanken folgend könnte eine Art ,,Hybrid" die Lösung sein:
-   Varianten-Generieren mit 1:n
und dann:
-   Varianten-pflegen 1:1/flach

Was verstehst du unter "Varianten pflegen"?
Das Einstellen er variablen Eigenschaften könnte in der 1:n-Variante pflegeleichter sein, da du dann relativ gut mit SQL und wenigen Sonderbehandlungen auskommen wirst.
Falls es nur um den Eintrag von Preisen usw. geht - ist es egal, wie die Eigenschaften gespeichert sind, da der Preis sowieso entweder direkt im Artikel oder in einer extra Preistabelle (1:n mit gültigkeitszeitraum) stehen wird.

Ich würde den Ansatz probieren:
-   Varianten-Generieren mit 1:n
und dann:
-   Varianten-pflegen: Eigenschaften 1:n, damit die aus dem Basisartikel eingestellten Werte einfach übernommen werden können.
-   Varianten in Liste anzeigen/exportieren: flach
-   Varianten über Listendarstellung ändern: Anzeige flach / Speicherung in 1:n-Struktur
-   einzelne Vartiante ändern: Maske die die 1:n-Struktur mit Unterformularen u. ä. abbildet.