Produkt-Datenbank

[FrankiLi]

Ich werde jetzt mal einiges testen, inzwischen habe ich auch erfahren, dass ich per ODBC direkt mit der SQL-DB der ERP verknüpfen kann.

Vielen Dank Josef, ich melde mich wieder!

[FrankiLi]

Nebenbei: Josef, hast Du Lust, den Unterschied zwischen "normalisieren" und "objektorientiert normalisieren" noch etwas deutlicher zu machen, vielleicht an einem Beispiel, an dem man den Unterschied erkennt? Ist jetzt für mich nicht wahnsinnig entscheidend, interessiert mich aber - und ich habe das anhand Deines letzten Beitrages nicht so richtig verstanden.

[Josef P.]

Vorab "objektorientiert" normalisieren gibt es nicht - ich verwendete das nur zur bildlichen Beschreibung, da du dir vielleicht unter objektorientierter Programmierung etwas vorstellen kannst.

"Objekte" beim Datenbankaufbau sind für mich alle Elemente, die für die Arbeit mit der Anwendung benötigt werden.

Ich versuche einmal meine Vorgehensweise zu beschreiben (ob es mir verständlich gelingt, werden wir sehen. )

Beispiel: Kundenstamm
1. Objekt: Kunde
Dieser Kunde hat eine Kundennummer (=Attribut) der Kunde hat auch einen Namen (=Attribut) und eine oder mehrere Adressen. Die Adresse ist jetzt wieder ein Objekt, daher kümmere ich mich in der Kundentabelle nicht um deren Attribute. Die Felder in der Kundentabelle müsse "echte Eigenschaften" des Kunden sein und keine aus anderen Objekten abgeleitete Eigenschaften. Sie haben einen direkten Bezug zum Kunden (stellvertretend für den Kunden ist die Kunden-ID).

In den Anwendungsanforderungen sei festgelegt, dass eine Adresse direkt einem Kunden zugeordnet werden soll und nicht eine Adresse zu mehreren Kunden benötigt wird. (Das regelt, ob 1:n oder n:m.)
Lt. obiger Anforderung ist die Adresse vom Kunden abhängig und nicht umgekehrt. Daher schreibe ich im Kundenstamm keinen Bezug zur Adresse sondern in der Adresstabelle den Bezug zum Kunden (Fremdschlüssel zur Kundentabelle). Dieser Bezug könnte aber auch umgekehrt sein, wenn z. B. eine Adresse für mehrere Kunden gelten soll. Dann müsste die Adresse alleine stehen können und im Kunden bzw. in einer n:m-Tabelle die Referenz zur Adresse gespeichert sein.

Aus den Kundendaten kommt nun all das in die Adresstabelle, was direkt mit der Adresse in Beziehung steht (Strasse, PLZ, Ort, Land usw.)
Da aber PLZ, Ort und Land zusammengehören bzw. voneinander abhängig sind, gibt es wieder ein neues "Objekt", das diese 2 Daten kapselt. Aus Tabellensicht: also eine Postleitzahlentabelle oder Ortstabelle mit einer PlzID oder OrtID, der PLZ dem Ort und einem Verweis auf das Land (welches aus der Ländertabelle kommt). In der Adresstabelle gibt es nur noch das Fremdschlüsselfeld um den Verweis zu PlzID zu speichern. Alle Daten die zum "Objekt" Land gehören sind in der Ländertabelle gespeichert. In der PLZ-Tabelle gibt es daher wieder nur einen Fremdschlüssel zur Ländertabelle.

Aus "Objekt-Sicht" würde man nun auf das Land des Kunden so zugreifen:
(Stell dir vor du bist im VBA-Editor und verwendest ein Objektmodell. Beispiel <code>DBEngine.Workspace(0).Database(0).OpenRecordset(....)</code>)

LandesnameDesKunden = AktuellerKunde.Adressen(0).PLZ.Land.Name
Anm.: Addressen(0), da es mehrere Adressen zum Kunden geben kann. 0 sei die erste Adresse.

In SQL-Schreibweise sieht das zwar anders aus, der Pfad ist aber im Prinzip der gleiche.
Du verwendest dann eben Join, um die Verbindung herzustellen.

Wichtig: Bitte den obigen Text nicht als Beschreibung für Normalisierung betrachten. Das ist nur meine Vorgehensweise die benötigten Elemente für eine Anwendung in eine Datenstruktur zu bringen.

Anm.: durch etwas längere DB-Erfahrung fließen in meiner Vorgehensweise bestimmt auch Normalisierungergeln mit ein, ich denke nur nicht bewusst daran, sondern gestalte das DB-Modell eher mit den beschriebenen Gedankengängen.
Im Prinzip interpretiere ich nur eine Regel aus der OOP für das Tabellendesign: Kapselung.

mfg
Josef

[FrankiLi]

Kurze Frage, zwar zu diesem Projekt hier, aber mehr allgemeiner Natur:

Wie schaffe ich es am elegantesten, flache Tabellen (hier: importierte xls) in eine vorhandene, relationale, "normalisierte" Struktur zu bringen?
ZB aus...
Farbe | Größe
weiß | 170
wird...
Attribut | Wert
Farbe | weiß
Größe | 170

Wahrscheinlich/hoffentlich fehlt mir (auch aufgrund fehlender Erfahrung) einfach nur der richtige Gedanke.

[Josef P.]

Hallo!

Ich würde zuerst einmal die Excel-Daten 1:1 in eine Hilfstabelle importieren.
Anschließend per VBA eine union-Anweisung zusammenstellen, die jede Spalte über eine Union in eine Zeile bringt.

Prinzip

Code [Auswählen] Erweitern

insert into ArtikelAttributTabelle (fiArtikel, fiAttribut, AttributWert)
select * from (
select ID, [AttributIDfuerFarbe], W.AttributwertID from ExcelImport E inner join AttributWerte W ON W.fiAttribut = [AttributIDfuerFarbe] and W.AttributWert = E.Farbe
union all
select ID, [AttributIDfuerGröße], W.AttributwertID from ExcelImport E inner join AttributWerte W ON W.fiAttribut = [AttributIDfuerGröße] and W.AttributWert = E.Größe
union all
...
) X

mfg
Josef

[FrankiLi]

Hallo Josef,

nochmals vielen Dank für Deine Hilfe hier, echt super.
Im Moment bin ich aus diversen Gründen gezwungen, erstmal flach zu arbeiten, aber das hier war mitnichten "umsonst", die Datenbank wird auf jeden Fall noch so sauber aufgebaut.

Viele Grüße
Frank