Hallo zusammen,
ich habe Euch schon einige Male bei den Überlegungen zu unserer Produkt-DB in Anspruch genommen, würde aber gerne nochmal explizit zu folgendem Thema Eure Meinung wissen.
Erstmal die Gegebenheiten:
1. Produkterstanlage mit den wichtigsten Artikel-Grunddaten findet mit .xls statt (warengruppenübergreifend über 200 Felder, pro Warengruppe ca. 130, d.h. im Schnitt 70 pro Produkt bleiben leer....)
2. Import in Access-DB/SQL (Backend: SQL Azure)**
3. Massen-Weiterbearbeitung der Produktdaten
4. Feintuning und Datenanreicherung in Access-Frontend (2016, Runtime)
5. Ausgabe der Daten flach** (csv) an ERP/Warenwirtschaft
Dass *1. in Excel und flach stattfindet ist definitiv nicht zu ändern, dass das "doof ist", ist mir klar, hat aber Prozess-/Zeitvorteile, darum gehts mir aber gar nicht. Ebenfalls nicht zu ändern ist der **flache Export in 5..
Infolge hatte ich beschlossen, die Tabellen in SQL auch flach abzubilden, aufgrund der Feldanzahl drei 1:1-Tabellen. Dass das immer wieder Probleme macht, ist klar, nicht ohne Grund macht "man" ja einen normalisierten Aufbau.
Deshalb meine Frage:
Würdet Ihr, unter den o.g. Voraussetzungen (Import flach, Export flach) die Datenbank trotzdem normalisiert aufbauen, sprich, den Aufwand mit der Normalisierung und im Export wieder De-Normalisierung betreiben? Wobei, ob Ihr ("Freaks" :)) das so machen würde, ist nur die halbe Wahrheit, Ihr habt die Techniken drauf - ich nicht, möchte zwar VBA lernen, aber das Ganze ist auch zeitkritisch.
Danke für jede Meinung
Gruss
Frank
Der Teufel steckt im Detail. Ich sehe zwei Fragen, die man sich beantworten sollte.
1) Ist das eine Lösung, um Daten im Durchlauf (Import, Verarbeiten, Löschen) etwas zu verarbeiten, oder ist da eine nachhaltige Datenhaltung beabsichtigt? Im zweiten Fall ist eine normalisierte Datenablage unabdingbar.
2) Normalisierung dient nicht nur dazu, Informationen nur einmalig zu speichern und so eine Datenintegrität abzusichern, sondern sie stellt auch in der unteren Stufe eine Datenverarbeitbarkeit per SQL erst einmal her (gleiche Informationen in einem Feld).
Da Du von Server und Massen-Weiterbearbeitung sprichst, darf man ja von "richtigen" SQL-Lösungen ausgehen. Wenn man richtig SQL fahren will und dazu wegen der Datenmenge eine Indexnutzung benötigt, sollten die Daten sofort in den benötigten Strukturen liegen und nicht erst durch Hilfsaktionen wie UNION zusammengeklaubt werden.
Außerdem wird ein Aufwandsvergleich, ob man Daten einmalig bei Import umstrukturiert oder jedesmalig bei jeder Verarbeitung, sehr schnell für den ersten Fall sprechen.
Die flache Datenausgabe ist nun gar kein Problem, in einer Auswahlabfrage bringt man beteiligte Datenbanktabellen zusammen und hat wieder die gewohnte Excelansicht.
Für den Import würdest Du ein vorhandenes Datenmodell benötigen, dass die o.g. Anforderungen erfüllt. Die Aufteilung der Daten könnten z.B. im Stil wie hier erfolgen:
Importtabelle in m:n-Beziehung auflösen (http://www.dbwiki.net/wiki/Datei:AccSampleDivideTable.zip)
Zitat1) Ist das eine Lösung, um Daten im Durchlauf (Import, Verarbeiten, Löschen) etwas zu verarbeiten, oder ist da eine nachhaltige Datenhaltung beabsichtigt? Im zweiten Fall ist eine normalisierte Datenablage unabdingbar.
Das ist noch nicht ganz klar: Im Moment geht es um Massenanlage und Anreicherung als Erstanlage. Wenn alles nach dem Verfahren angelegt und in der ERP ist wird endgültig entschieden, ob diese DB hier führend in Sachen Artikelpflege ist – oder ob das die ERP ist. Das ist aus verschiedenen Gründen, die hier den Rahmen sprengen, jetzt noch nicht entscheidbar. Ich verstehe Deinen Punkt absolut – gehen wir davon aus, dass die ERP nachher die Führung übernimmt.
ZitatDie flache Datenausgabe ist nun gar kein Problem, in einer Auswahlabfrage bringt man beteiligte Datenbanktabellen zusammen und hat wieder die gewohnte Excelansicht.
Huch, klar, stimmt. Einziger Punkt ist, dass dort alle 200 Felder ausgegeben werden müssen, auch wenn für die jeweils zu exportierenden Artikel (das passiert etappenweise) nur einzelne Felder überhaupt relevant und 1:n angelegt sind, aber das dürfte ja auch lösbar sein.
ZitatFür den Import würdest Du ein vorhandenes Datenmodell benötigen, dass die o.g. Anforderungen erfüllt. Die Aufteilung der Daten könnten z.B. im Stil wie hier erfolgen: Importtabelle in m:n-Beziehung auflösen
Zum Datenmodell: Das würde ich hinkriegen, habe ich für Teile, die nicht aus der Massenanlage kommen schon umgesetzt.
Zur Aufteilung: Angenommen, ich hätte selbst weder die Kompetenz (...), noch würde sie mir so schnell aneignen können, wie es die Projektumsetzung erfordert (auch wenn mir das lieber wäre, ich verstehe gerne alles), hättest Du bzw. hätte jemand der mitlesenden Experten Interesse, das gegen Vergütung per Teamviewer o.ä. bei mir umzusetzen - also den Import von xls mit jeweils unterschiedlichen Varianten/Eigenschaften in eine normalisierte Struktur? Quasi als kombinierte Umsetzung+Learning-by-doing?
Hier steckt der Teufel womöglich auch im Detail, weswegen ich mir das nur bedingt zutraue, aber das tut er ja regelmässig :)
PS: Zum Beispiel möchte ich keine "harte" Zuordnung der Spalten aus der .xls zu Attributen aus einer SQL-Schlüsseltabelle, sondern das ganze dynamisch anhand des .xls-Spaltennamens. ZB xls-Spalte "Farbe" findet automatisch das gleichnamige Attribut in der 1:n-Tabelle. Da jedes Mal Code anpassen zu müssen wäre mir deshalb zu aufwendig, weil fast jede Importtabelle unterschiedliche Spalten/Attribute hat. Jede Spalte in der xls hat eine klare ID (da steht also nicht "Farbe", sondern 4711), unter der das Attribut auch in der DB läuft.
Hallo Frank,
scheinbar geht es ja "nur" darum, Produktdaten letztlich in ein WaWi-System einzuspeichern. Excel und Access dienen dabei ja wohl nur als "Arbeitspferde", um die Daten elegant zu erfassen und aufzubereiten.
Access ist demnach also nur ein Zwischenschritt.
Warum solltest du dich hier also um Normalisierung kümmern? Die ursprünglichen Daten stammen ja aus einer Excel-Tabelle und sind nicht normalisiert, sondern "flat".
Was bringt es dir dann, in Access eine Normalisierung zu machen? Dazu müsstest du ja zuerst ein Datenmodell und entpr. Tabellen erstellen, die auch noch befüllt werden müssten.
Mein Rat lautet deshalb: mach es ruhig so, wie du beschrieben hast. Du hast dann in Access zwar auch nur eine Tabelle mit 200 Feldern, kannst aber diverse Auswertungen mit Access machen, die so mit Excel nicht möglich wären.
Wenn deine Access-Daten dann gesichtet und aufbereitet sind, kannst du sie an das WaWi-System exportieren und danach sowohl Excel als auch Access vergessen, denn die weitere Pflege der Daten wird ja wohl über das WaWi-System erfolgen.
Bis dahin könntest du dich allerdings in Access "austoben", um die Daten zu vereinheitlichen und sie letztlich "wohl geflattet" übergeben zu können. Du könntest mit einfachen Abfragen z.B. leicht ermitteln, welche Werte in einzelnen Spalten mehrfach vorkommen, deren unterschiedliche Schreibweise korrigieren. Dazu reichen einfache Abfragen mit Gruppierung und Anzahl.
Wenn du die Daten in normalisierte Access-Tabellen importieren möchtest, müsstest du diese Tabellen ja - wie schon gesagt - erst erstellen und befüllen. Da du aber wenig Zeit hast und das WaWi-System vermutlich über entsprechend normalisierte Tabellen verfügt, würde ich mich lediglich auf unterschiedliche Schreibweisen und Tippfehler in den einzelnen Spalten beschränken. Zum Teil könntest du das ja auch schon in den Excel-Daten machen.
Vermutlich bin ich mit dieser Meinung ziemlich allein, wenn Access aber nur als temporäres Hilfsmittel dienen soll - warum nicht.
Andere werden mich wegen dieser Aussagen wieder verfluchen, aber wozu eine normalisierte Access-Umgebung nachbauen? Zumal dann, wenn es nur darum geht, eine "Erst-Befüllung" des WaWi-Systems vorzunehmen, in dem auch nachträglich noch Fehler korrigiert werden können.
Es sähe freilich anders aus, wenn de Weg über Excel und Access auch später die Regel sein sollte, aber aufgrund deiner Schilderung nehme ich das nicht an.
lg
crystal
Hallo nochmal,
wenn es darum geht festzustellen, welche der vielen Attribute der Input-Datei qualitative Attribute sind, die nur einen gewissen Werteumfang haben (z. B. Farbe), und entsprechene Tabellen im WaWi-System bereitgestellt werden sollten, kannst du das ja schon anhand der Excel-Tabelle(n) erkennen.
Statt hier also "Klimmzüge" in Access zu machen, würde es m.E. ausreichen, den Admins des WaWi-Systems mitzuteilen, welche Attribute (von den 200!) numerische und welche diskrete Werte (aus einer Wertetabelle) enthalten können. Die müssen dann entprechende Tabellen bereitstellen. Natürlich werden sie sich freuen, wenn du diese Arbeit für sie erledigst...
lg
crystal
PS: Ich störe mich etwas am Begriff ERP (Entity Relation Plan), weshalb ich lieber WaWi schreibe...
Zitatweil fast jede Importtabelle unterschiedliche Spalten/Attribute hat
Wenn das trotzdem nach formulierbaren Regeln läuft, kann man diese Regeln in Codes übernehmen. Durch die Maschinenausgabe aus einem DB-System würde ich eine Konstanz der Regeln und der entsprechenden Ausgaben und somit eine Programmierbarkeit erwarten.
ZitatDa jedes Mal Code anpassen zu müssen ...
Wenn man da systematisch herangeht statt pragmatisch kurzzuspringen, sollte das nicht passieren. Wegen ein paar neuer Daten oder dem Auftreten erwartbarer Zustände neu programmieren zu müssen ist der Gau.
Schnittstellenprogrammierung mag ich. Wenn Du also eine Notwendigkeit dazu siehst und Hilfe benötigst, kannst Du eine PN an mich schicken.
Hallo!
ZitatWas bringt es dir dann, in Access eine Normalisierung zu machen?
Ein Vorteil könnte eine schnellere Erfassung der benötigten Daten sein.
Ich verstehe irgendwie die "Angst" vor der Normalisierung nicht. Die macht man doch nur, weil man damit besser mit den Daten umgehen kann.
Aus einer gegliederten Struktur kann man relativ einfach eine "flache Ausgabe" erzeugen. Umgekehrt ist das zwar auch möglich - es ist aber eine höherer Aufwand notwendig.
Daher würde ich das Normalisieren folgendermaßen angehen: wie kann man die Tabellen gestalten, um schnell die Daten erfassen und anpassen zu können und dabei die Übersicht/Sicherheit zu behalten, dass die Daten stimmen. ... dann ergibt sich vermutlich eine normalisierte Struktur von alleine.
Wenn der Weg ist: Flache Excel-Tabelle => normalisierte Access-Tabellen => flache Zielstruktur, würde ich nur das Notwendigste in den Access-Tabellen normalisieren. Ich würde dann sogar den Access-Zwischenschritt in Frage stellen.
Ich würde aber auch eher folgenden Weg gehen:
In normalisierter Struktur die Daten erfassen und dann in die flache Zielstruktur zu übertragen.
Interessehalber: Von welchem ERP ist eigentlich die Rede? Reden wir von so "kleinen" wie SAP oder Dynamics AX? ;)
BTW @crystal: mit ERP meine ich Enterprise Resource Planning.
mfg
Josef
ZitatIch verstehe irgendwie die "Angst" vor der Normalisierung nicht. Die macht man doch nur, weil man damit besser mit den Daten umgehen kann.
Es gibt keine Angst. Natürlich kann man dann besser mit den Daten umgehen. Aber die Voraussetzungen hatte ich ja oben schon geschildert.
Danke für Eure Meinungen!
Ich glaube, entscheidend wird jetzt sein, ob die künftige Datenpflege über eben dieses System stattfindet (=Normalisierung, Aufbau und Struktur von langfristiger Relevanz), oder Access nur eine Zwischenstation sein wird (=vice versa). Ich werde diesen Punkt versuchen, schnellstens zu entscheiden und mich dann wieder in der Sache melden.
Viele Grüße
Frank