Produkt-Datenbank Setup

[FrankiLi]

Hallo zusammen,

folgendes Problem:

Ich möchte Produkte in einer Access2016-Datenbank verwalten, inklusive zahlreichen Attributen.

Alle Produkte haben die üblichen Daten wie Preis, Name usw.
Unterschiedliche Warengruppen haben unterschiedliche Attribute, zum Beispiel
• Warengruppe 1 hat eine Farbe
• Warengruppe 2 eine Größe
• Warengruppe 3 eine Farbe, eine Größe und eine Höhe
usw. (natürlich jeweils mit entsprechenden Werten)

Nach der Ersterfassung muss das Ergebnis ,,flach" exportiert und in ein anderes System importiert werden, idealerweise sind die Attribute also einfach Felder, die Zeilen enthalten die entsprechenden Werte (nur ein Wert möglich pro Produkt).
Nun würde ich ja einfach eine (1) Tabelle anlegen, die alle Felder beinhaltet, egal, ob sie pro Warengruppe überhaupt benötigt werden (am o.g. Beispiel also Farbe, Größe und Höhe, wobei zB Farbe und Höhe bei WG 2 einfach leer bleiben) ...
ABER: Es handelt sich warengruppenübergreifend um mehr als 300 Felder/Spalten/Attribute, was ja in Access schon mal unmöglich ist.

• Gedanke 1: Tabelle unterteilen mit 1:1-Beziehung.
Nachteil: Lässt sich in SharePoint nicht schön abbilden, da dort solche Beziehungen nur rudimentär funktionieren bzw. nicht benutzerfreundlich gezeigt werden können. Und im Prinzip ist das ja auch nur geschummelt.

• Gedanke 2: Nicht 1 Tabelle mit allen Attributen, sondern je Warengruppe eine Tabelle, im o.g. Beispiel also drei Tabellen, die jeweils nur die Attribute enthalten, die für die WG auch relevant sind.
Nachteil: Die ,,normalen" Stammdaten wie der Preis sowie die für mehrere Warengruppen relevanten Attribute, am o.g. Beispiel zB die Farbe in WG1 und WG2 sind über mehrere Tabellen verstreut. Und kommt ein Stammdatenfeld hinzu muss das in x Tabellen nachgetragen werden.

• Gedanke 3: Die Attribute nicht als Felder einsetzen, sondern in der Form:
Feld: Attribut 1 Name (Wert: Farbe) | Feld: Attribut 1 Wert (Wert: weiß) usw. (ca. 20 Attribute)
... was auch für meinen späteren Ex-/Import funktionieren würde
Nachteil, fürchte ich: Auswertbarkeit und Massenänderungen, zB 2.000 Artikel sollen zusätzlich Attribut Breite bekommen (an welcher Position ist nun der erste Attribut-Name frei?) oder Attribut Farbe soll in Oberfläche geändert werden (ist Farbe nun Attribut 1, 4 oder 17?).
-----
Unabhängig davon suche ich noch eine Möglichkeit, Artikelvarianten auszumultiplizieren, neben den ,,harten" Attributen gibt es noch Variantendimensionen, zB Variantendimensionen Ausführung links und rechts, ich will einzelne Datensätze erstellen, Artikel 1 = Ausführung links, Artikel 2 = Ausführung rechts (real natürlich deutlich komplexer mit bis zu 10 Variantendimensionen und je bis zu 10 Werten), aber das kann auch ein anderes Thema sein.

Ich bin super-dankbar für jede Hilfe!

Gruss
FrankiLi

[MzKlMu]

Hallo,
alle Attribute (eine Farbe, eine Größe, Höhe usw.) in eine Tabelle mit einem Schlüsselfeld für welche Warengruppe das Attribut zutreffend ist. In die Tabelle noch ein Schlüsselfeld für mögliche Einheiten (cm, m, Kg, keins etc.). Auch für die Einheiten dann natürlich eine Tabelle. Für die Warengruppen ist auch eine Tabelle erforderlich.
Die Artikel erhalten einen Fremdschlüssel für die Warengruppe.
In einer n:m Tabelle werden die Attribute den Artikeln zugeordnet. Da im Artikel die Warengruppe erfasst ist, kann man automatisch nur die Attribute zuordnen die zutreffend sind. In die Tabelle kommt dann noch ein Feld für den Eigentlichen Eintrag.

Ich habe mal ein ähnliches Beispiel gemacht. Muss ich mal suchen.

[FrankiLi]

Holla, das muss ich mal eben verdauen.
Vielen Dank schon mal, und eine Rückfrage: Mit Schlüsselfeld meinst Du NICHT Nachschlagefeld (dass über selbiges die Meinungen auseinandergehen mit starker Tendenz zu "ist Bullshit", habe ich schon gemerkt), richtig? Und: Die Schlüsseldatei für die Attribute, wenn Farbe für mehrere Warengruppen relevant ist, alle WG in einen Datensatz packen, also nur ein Eintrag "Farbe" mit "WG 1 und 2"?

[MzKlMu]

Hallo,
habe das Beispiel gefunden.
Übersetzung:
Merkmale = Attribute
Kategorien = Warengruppe

Ein Schlüsselfeld hat mit Nachschlagefeldern nicht zu tun.
Schlüsselfelder sind die Paarungen Primärschlüssel > Fremdschlüssel für eine 1.n Beziehung.
Nachschlagefelder vergisst Du gleich wieder , die braucht man nicht. Ich bin auch für Bull... 

also nur ein Eintrag "Farbe" mit "WG 1 und 2"?

Nein, 2 Datensätze
Farbe WG1
Farbe WG2

Siehst Du im Beispiel.

[FrankiLi]

Herzlichen Dank nochmal!

Kurze weitere Frage, dafür lohnt sich m.E. kein neues Thema:
Wie kann ich in einer 1:1-Tabellenbeziehung dafür sorgen, dass bei Erstellen/Anlegen eines neuen Datensatzes in einer Tabelle das entsprechende Gegenstück in der anderen Tabelle automatisch ebenso (quasi "nackt, nur die ID) angelegt wird?

[DF6GL]

Hallo,

indem Du die 1:1 Beziehung (und eine Tabelle)  entfernst und die Felder in die andere Tabelle einfügst.

Ansonsten muss das mit Hilfe einer Anfügeabfrage (bzw. Recordset) erledigt werden.


Was ist der Grund für eine 1:1 Beziehung?

[FrankiLi]

Unterschiedliche Tabellen aufgrund Verknüpfen nach Sharepoint und dort unterschiedliche Berechtigungen (einer pflegt dies, der andere das). Geht m.W. nicht nach Spalten, sondern nur Tabellen (Listen).

Hat mit dem o.g. nur am Rande zu tun.

Wobei das Thema ja auch bei 1:n relevant sein könnte: Ich habe einen Artikel, der mindestens ein Bild haben soll (letzteres in anderer Tabelle), und ich will eine ToDo-Liste für denjenigen, der die Bilder erfassen soll.

[DF6GL]

Hallo,

Berechtigungen könnten auch mit entspr. aufgebauten Abfragen behandelt werden.


Eine weitere Möglichkeit gäbe es noch:


Erstell für jede  Tabelle ein Einzel-Formular.

Füge in das Formular der "Haupt"-Tabelle das andere Form als UFO ein.  Die Eigenschaften "Verknüpfen von/nach" des UFO-Steuerelementes setzt Du auf die Schlüsselfelder. Dabei darf das Schlüsselfeld der "Neben"-Tabelle kein Autowert sein, sollte aber eindeutig (ohne Duplikate) indiziert sein.

[FrankiLi]

Berechtigungen könnten auch mit entspr. aufgebauten Abfragen behandelt werden.

.. aber nicht so, dass SharePoint die Berechtigung (weiter-)verwalten kann, sondern nur "Access-Intern", oder liege ich da falsch?

[DF6GL]

Hallo,


mit SharePoint kenne ich mich nicht aus....

[FrankiLi]

Hallo zusammen,

ich habe mich entschieden, auf SharePoint erstmal keine Rücksicht zu nehmen, jedenfalls nicht nur aus diesem Grund auf den "richtigen" Aufbau einer Datenbank zu verzichten. Danke an alle für den bisherigen Input auch in anderen Threads.

Plan ist nun jedenfalls erst mal der saubere Aufbau in Access, die Erstellung einfacher Listen für SharePoint und ggf. später umswitchen auf SQL-Server-DB mit der Möglichkeit, in SP komplexere Listen zu realisieren.

Wenn Ihr erlaubt, werde ich meine Fragen zu Access in dem Zusammenhang hier in diesem Thread los?

Im Moment beschäftigt mich Folgendes:

a) in einer Schlüsseltabelle darf eine Kombination Feld 1 und Feld 2 nur einmal vorkommen. Ich habe das jetzt mit einem kombinierten Index in der Tabelle realisiert, in der die Kombi eindeutig sein muss. Ist das so korrekt oder gibts einen saubereren Weg?

b) In einer Beziehung Haupttabelle zu Schlüsseltabelle (ref. Integrität mit Aktualisierungsweitergabe) soll es zwar möglich sein, die Werte in der Schlüsseltabelle zu ändern, so dass diese Änderung an die Haupttabelle weitergegeben werden - aber NICHT umgekehrt. Wie mache ich das?

c) Problem Haupt-Index überhaupt, die Artikelnummer. Ich habe eine Grundtabelle mit den Daten des Grundartikels, aber erst durch die Kombination mit diversen, pro Artikel unterschiedlichen Varianten-Dimensionen (zB Farbe weiß, gelb, grün) ergibt sich der endgültige, bestellbare Artikel und somit die fertige Artikelnummer. Ich bin mir nicht sicher, wie ich damit umgehen soll. Habe nun in der Zuordnung Artikel<1:n>Varianten-Dimensionen<1:1>Wert ein manuelles Artikelnr.-Suffix vorgesehen, hier wird quasi händisch durchnummeriert und ebenfalls auf die Kombination Artikel->Suffix ein eindeutiger Index gelegt. Die fertige Artikelnr ergibt sich dann aus Grundartikelnr&Suffix per Ausdruck in einer Abfrage. Ein Auto-Wert wäre hier zwar richtiger, aber ich will eben sauber von 1 an durchzählen, und nicht irgendwann durch Änderungen etc. bei 1439 starten. Außerdem erscheint es mir so "soft" (finde keinen besseren Ausdruck), die elementar wichtige fertige Artikelnummer nur mal eben per Abfrage zu ermitteln und nicht hart weg-zu-speichern, allerdings wüsste ich auch nicht, wohin - in der Haupttabelle stehen ja nur die Grundartikel. Was meint Ihr dazu?`

Ich danke Euch
gruss
Frank

[MzKlMu]

Hallo,
Zu a)
Zusammengesetzter Index ist der richtige und übliche Weg.

Zu b)
Hier gibt es glaube ich ein Missverständnis. Was ist für Dich die Mastertabelle und was die Schlüsseltabelle ? Für mich ist die 1-Seite die Mastertabelle und von der 1-Seite zur n-Seite wird aktualisiert. Der umgekehrt Weg braucht man nicht.

Zu c)
Hier wäre auch erst mal etwas grundsätzliches zu klären.
Wenn Du ein normalisiertes Datenmodell aufbauen willst (und das willst Du ja), kann es in Deiner DB keine 1:1 Beziehung geben. Mein Beispiel in #3 ist genau auf Deine Anwendung übertragbar. Siehst Du da eine 1:1 Beziehung ?

[FrankiLi]

Hallo Klaus

meine Konstellation ist nicht genau die wie in Deinem Beispiel. ZB ist das "1:1" wie geschildert gar keines, sondern ein direkt zugeordnetes Feld.

Gruss
Frank

[MzKlMu]

Hallo,

Habe nun in der Zuordnung Artikel<1:n>Varianten-Dimensionen<1:1>Wert

Was verstehst Du dann unter 1:1 wenn Du das im Zusammenhang mit 1:n erwähnst ?
Erkläre das mal ausführlicher.

[FrankiLi]

Damit es nicht zu verwirrend wird schlage ich vor, ich schildere die konkretere Situation (o.g. waren ja nur Fragmente, inzwischen weiß ich schon genauer, in welche Richtung es gehen soll und kann auch detailiierter werden) nochmal in einem neuen Thread. Jetzt muss ich erst mal raus

Nachtrag: Habe das Thema jetzt hier neu aufgemacht.