Office: (Office 2013) komplexe Tabelle in ein normalisiertes Tabellenmodell aufteilen

Hallo zusammen!

Ich möchte die Daten einer mir gelieferten Ausgangstabelle ‚tbl_DATAS_modified“ in die Tabellen
des Tabellenmodells (siehe Beziehungsfenster) so verteilen, dass die Regeln von relationalen Datenbanken eingehalten werden.
Die gesamten Programmierungstexte sind nicht von mir. Die hat ein Freund mir geliefert.

Er hat aber aufgegeben und mir empfohlen, hier weiter zu fragen.



Als Prüfung für eine richtige Aufteilung gibt es das Formular ‚HF_ArtikelVerwaltung‘ .

Ich würde die Datenbank ja gerne hochladen, komme aber nicht auf 244,1 kb runter. Die DB ist unentpackt 15MB groß und ich krieg sie nicht kleiner wie 1.071 kb. Hab leider grad nur 7zip zur Hand (auf Arbeit). Ansonsten versuch ich es heute Abend zu Hause noch einmal. Oder kann man das irgendwie ändern?

Gruß

Torsten

:)

 

Moin,
schmeiß einfach erst mal alles raus, was für die Fragestellung nicht benötigt wird und lass ein nur paar Dummydaten im Beispiel drin.
Dann über Access Menü Datenbanktools "Komprimieren und Reparieren", wirkt meist Wunder *wink.gif* . Hinterher zippen.
maike

 

Servus alle,
ich hab per email in PN die DB bekommen und angeschaut. Da gibts wenig mehr zu komprimieren/reparieren. Kleiner als 700kb wäre nicht drin.
Es liegt an an einer sehr komfortablen VBA-Demonstration der angefangenen Datenaufteilung, welche man nicht löschen kann, ohne die Aufgabe dann noch
zu verstehen.
Kannst Du, TFluege, die DB gezipped oder rared auf DropBox (oder ähnliche Services) hochladen und den Link dahin hier uns geben?
Auf jeden Fall solltest Du ein Bild des Beziehungsfensters hier zeigen, damit man sich einen Überblick machen kann.
Und auch den Text der Aufgabenstellung zur Normalisierung in Deiner DB.

 

Hallo zusammen!
Das Bild mit den Beziehungen habe ich als Doc angefügt.

Hier noch der Text zur Aufgabe:

Aus der Tabelle 'tbl_DATAS_modified_original' soll die Aufteilung auf das vorhandene Datenbankmodell und seinen Tabellen
erfolgen. Die dafür notwendigen Schritte sind im Formular 'frm_Normalisierung' per VBA erstellt worden und können auch
bequem eingesehen werden. (Buttons: siehe VBA-Code).
Leider fehlt noch der letzte Schritt, die Artikel (tbl_Artikel) mit den AnlageNummern (alt: EqNummern) zu verbinden
und die Zuordnung der Daten in Tabelle 'tbl_LagerfachBuchung'. Der Inhalt von Feld 'Lagerbestand' in 'tbl_DATAS_modified' entspricht
dem ersten Eintrag 'Zugang' in Feld 'Buchungsart'.

Da die Tabelle 'tbl_DATAS_modified' bei den Normalisierungsversuchen verändert wird, wird sie vor einem erneuten Normalisierungsversuch immer wieder komplett gelöscht und aus der Originaltabelle 'tbl_DATAS_modified_original' als Kopie für weitere Versuche neu erstellt.
Die Originaltabelle 'tbl_DATAS_modified_original' entspricht als Zusammenfassung (Zsf) den zuletzt gelieferten
Daten am Ende des Jahres 2017. Diese Daten sollen in einer normalisierten DB verteilt werden.
Problematisch dabei sind Beziehungen, wie z.B. Zwischentabellen 'tbl_AnlageArtikel'. welche in Zsf nicht vorhanden sind und über künstliche Wege zu erstellen versucht werden müssen..

Eine entscheidende Information scheint mir in den EqNummern zu liegen. Diese dürfen nur ohne Duplikate vorkommen.
Es sind nun aber 2750 mal EqNummern mit der Bezeichnung "DummyKonzi" vorhanden. Alle entsprechenden Artikel werden
also dann dieser EqNummer (Anlage) zugeordnet. Das ist doch ziemlicher Nonsense, der nach einer Lösung sucht.
Siehe 'qry_DATAS_modified_original_DummyKonzi'
Weiterhin habe ich in tbl_Artikel zusätzlich das Feld 'EqNummerID_f' eingebaut und fülle es über die VBA/SQL-Codes als Stützpfeiler für weitere Programmierungen.

ICH SUCHE FOLGENDEN WEG:
Einen SQL Code, über welchen eine Brücke zwischen 'tbl_Anlage' ,' tbl_AnlageArtikel' hin zu 'tbl_Artikel' und 'tbl_LagerfachBuchung'
geschaffen werden könnte, um eine passende Zuordnung der Artikel erreichen zu können.
Die Voraussetzungen dafür sind in der bisherigen DB meines Erachtens geschaffen.
Es gibt auch in tbl_Artikel die EqNummerID_f, deren Werte helfen könnten.

Bei richtiger Aufteilungsprogrammierung müsste in UFO_Artikel die richtige Zuordnung der Artikel zu den Anlagen in UFO_Anlage angezeigt werden. Die Ufos sind in HF_ArtikelVerwaltung.

mit der Bitte um Hilfe

Vielen Dank im vorraus.

Nach einer Möglichkeit die DB online zur Verfügung zu stellen werde ich mich nach der Arbeit umsehen!

 

Die Datei als png hochzuladen wäre wegen der Lesbarkeit geschickter gewesen.

 

Da möchte ich nicht widersprechen, aber bin hier sehr eingeschränkt von meinen Möglichkeiten. Was ich eigentlich nicht gedacht hätte!

Wenn ich wieder Zuhause bin, kann ich das ganze bestimmt nochmal Optimieren!

Bis dahin erst mal vielen Dank.

tfluege

 

Das habe ich an anderer Stelle schon mal gesehen. Der dortige Fragesteller hatte aber kein ernsthaftes Interesse, nur einige persönliche Allüren.

Primär würde ich die Importtabelle so wie sie kommt verwenden wollen. Welche Bedeutung hat das "modified"?

Als Ausgangspunkt für Überlegungen sollte eine Liste vorhanden sein, die die Felder der Quelltabelle zu Feldern der Datenmodell-Tabellen zuordnet, da die Zuordnung ausgehend vom Beziehungsbild nicht vollständig und zweifelsfrei nachvollziehbar ist.
Dann wird man sehen, ob und wie eine vollständige Datenaufteilung erfolgen kann.

Bevorzugt würde ich Daten von einer Tabelle zu einer anderen Tabelle per SQL-Anweisung übertragen und dabei nach folgender Strategie vorgehen wollen:
Importtabelle in m:n-Beziehung auflösen
Das wäre dann eine Anfügeabfrage pro Zieltabelle (sofern die Daten der Quelltabelle entsprechende Daten und Zurordnungen bieten).

Aus diesem Ansatz heraus ist mir unklar, welche Rolle Formulare und eine umfangreiche VBA-Demonstrationt für die Datenaufteilung spielen sollen. Diese sind also, zumindest für den ersten Ansatz, verzichtbar.

 

Hallo zusammen!

Ich habe die DB jetzt online zur Verfügung gestellt.

https://drive.google.com/file/d/1S9e...ew?usp=sharing

Ich hoffe jemand kann mir weiterhelfen!

Vielen Dank erstmal!

tfluege

 

Hohes Interesse am Thema scheint nicht zu bestehen, nicht mal beim TE selbst.
Sonst würde er eine einfache Frage beantworten, und zwar umgehend, zumal eine solche Frage der Testballon für richtige Fragen zum Projekt ist.

Neben einigen Daten braucht man auch eine brauchbare Logik. Diese wäre aber vom Wissen um Daten und Abläufe abhängig.

Meiner Ansicht beginnt der Nonnsens damit, dass da jemand Dummy-Zeugs in die Tabelle hineinschreibt und das dann als gegeben nimmt.

 

Hallo zusammen!

Bei der DB handelt es sich um eine Ersatzteilhaltung, die seither in 3 einzelnen DB geführt wurde.

Durch Umstrukturierung entstand der Wunsch nur noch eine DB zu führen.

Aufgeteilt war das ganze seither so:

1te DB = ET für Abteilung 1 (Mechanik)
2te DB = ET für Abteilung 2 (UET)
3te DB = ET für Konsignationslager (Lager für alle Abteilungen)

Das größte Problem stellt das Konsignationslager dar, da dort ET von insgesamt 5 Abteilungen geführt werden, die Real vorhanden sind.

Bei den anderen DB`s sind ET eingetragen, die zwar benötigt werden für die jeweilige Abteilung, aber nicht zwingend Real vor Ort sein müssen. Aber es sind dort auch Daten aus dem Konsignationslager eingetragen, wegen der Auffindbarkeit.

Ich versuche mal es zu erläutern, was nicht einfach ist.

Die 5 Abteilungen die Daten ins Konsignationslager eintragen sind aufgeteilt in 2 mal Elektrik u. 3 mal Mechanik. Jede dieser Abteilungen führt eine eigene Datenhaltung, da die Teile der anderen Abteilungen in den meisten Fällen nicht relevant sind. Natürlich gibt es aber ET die in allen Abteilungen vorkommen.

Die ganzen ET werden für verschiedene Fertigungs u. Montagelinien benötigt.
Da Montage u. Fertigung Abteilungsmäßig bisher keine Berührungspunkte hatten, ging das auch relativ reibungslos. Jetzt wurden die Abteilungen aber zusammengeführt, das bedeutet es gibt nur noch eine Mechanische und eine elektrische Abteilung. Weiterhin getrennt werden aber Montage und Fertigungsabteilung.

Deshalb wurde der Versuch angestoßen, die Mechanischen ET und die ET der UET sowie das Konsignationslager zusammenzuführen. Was sich schon als ziemlich schwierig herausgestellt hat, da jede Abteilung Ihre eigene Art hatte die Daten zu pflegen. Das konnte aber bis auf das Konsignationslager zu 80% bereinigt werden.

Was die Daten aus dem Konsignationslager betrifft, ging es einfach nicht, da zu viele Daten zu kontrovers eingetragen wurden, deshalb gibt es auch die vielen Dummyeinträge, damit bei einer möglichen erfolgreichen Zusammenführung erst mal keine Daten verloren gehen.
Das es im Nachgang dann eine sehr große Aufgabe werden wird, diese Daten zu bereinigen ist klar.

Ich hoffe ich konnte etwas aufklären, was die Funktion der DB werden oder sein soll.

MfG

tfluege

 

Das war die große Geschichte, warum es so durcheinander losgeht (maschinell erzeugte Daten würden anders aussehen).

Irgendwo glaube ich gelesen zu haben, dass das Daten für 2017 seien. Nirgends erscheint ein Datum. Das erscheint bei einer Ersatzteilverwaltung höchst problematisch, es sei denn, der Glaube ist sehr groß, dass jedes Teil über alle Jahre - es folgen sicher noch ein paar - einzigartig ist.

Laut dem VBA-Projekt wird jeder Datensatz der Ursprungstabelle als eigener Artikel (eigener PK) angelegt. Da steigt mein Verständnis aus, und das setzt sich in der nachfolgenden Tabelle tbl_AnlageArtikel fort. Sollen dort auch 12032 Datensätze erscheinen oder ein paar Millionen, und wenn eine bestimmte Anzahl aus den vorhandenen Daten heraus, warum diese?
Also Zusatzfrage: Wodurch wird ein Artikel sachlich als eindeutig bezeichnet?

Das vorhandene Projekt ist fehlerbehaftet, umständlich und langsam aber dafür mit vielen Buttons und Farbe aufgebauscht und aufgehübscht (dezente Farben und dafür mehr funktionaler Inhalt wären mir angenehmer):
Langsam: Die reichlich 30 Sekunden zum Tabellenfüllen kann ich auf etwa 1 Sekunde zusammendampfen (gefühlte Messung).
Fehlerhaft: Ein Herstellername kommt mit keinen bis mehreren Herstellernummern daher. Da können nicht beide Felder in einer Tabelle 1:1 zugeordnet sein, und ein beliebiges Herausgreifen einer Nummer (First?) ist Informationsvernichtung. Bei den Anlagenummern besteht das gleiche Problem.

Es ist sicher nachvollziehbar: Wenn die Schritte im Vorfeld fehlerbehaftet und unklar sind, ist ein Weiterarbeiten bei einem So-wie-es-ist sinnfrei. Man kann zwar Tabellen mit Werten füllen, aber ob damit die Chance besteht, dass da einer glücklich wird, ist eine andere Frage.
Nebenbei sollte Dir klar sein, dass spezielles Fachwissen und damit zusammenhängende Zeit nicht immer kostenfrei zu erhalten sind, bei einem betrieblichen und damit kommerziellen Thema dann um so mehr.


Aufteilung von Daten aus Exports in normalisierte Tabellen
Ist da auch einer Deiner Freunde beteiligt?

 

Hallo zusammen!

@ ebs17:

Der Artikel wird durch die B-Nummer (wenn vorhanden) eindeutig,
ansonsten gibt es keine Eindeutigen Merkmale eines Artikels.

Und die Befüllung der Tabellen begann so gegen 1990, was anfangs über Excel gelaufen ist. Irgendwann hat dann jemand mit Access begonnen. Die Daten wurden schon so oft geändert und die Ursprungsdatenbank vom Konsignationslager genauso, das es eigentlich nur fehlerbehaftet sein kann.
Das weiß ich auch, aber das hilft mir nicht weiter. Deshalb bitte ich ja höflich um Unterstützung!

@all:

Kann mir jemand sagen, ob ich aus der tbl_DATA_modified das vorhandene Tabellenmodell normalisiert bestücken kann und wenn ja, könnte mir jemand dabei behilflich sein?

MfG

tfluege

 

In Tabelle tbl_DATAS_original ist ArtBnummer in allen Datensätzen enthalten, allerdings in 3881 von 12032 Datensätzen mehrfach.
Daraus stellt sich die Frage, ob man gleiche Artikel mehrfach in einer Artikeltabelle führt oder umgedreht, was man mit den verschiedenen Zusatzinformationen macht, wenn man auf Artikel nach ArtBnummer vereinzelt.
Code:

Prinzipiell ja.
Faktisch auch, zumindest stehen bei mir 7 der Anfügeabfragen auf 11 Tabellen. Da aber die letzte (Artikel) sichtbar ein falsches Ergebnis liefert, macht es (für mich) keinen Sinn, selbst mit richtiger Logik falsche Daten weiterzuverarbeiten. An sich sind die weiteren Anfügeabfragen, evtl. zzgl. weiterer Maßnahmen, kein wirkliches Problem - sofern es da verwendbare Ansätze gibt. Am nachfolgenden Code kann man im Kommentar auch nachlesen, dass es wenig unverarbeitete Felder der Ursprungstabelle gibt, wobei deren Adressierung an das Datenmodell dann völlig unklar ist.
Code:

Mehr muss es nicht sein, außer dass man dann einen solchen Ablauf in eine Transaktion packen würde, weil ein fehlerverursachter Abbruch so mittendrin problematisch wäre, besonders dann ab einem Zweitimport.

Zur Höflichkeit gehört aber auch, alle Fragen und Fragen vollständig zu beantworten. Wer meint, nur das zu sagen, was ihm gerade als wichtig erscheint, kriegt dann die Antwort, die entsprechend als angemessen erscheint.

//Edit: Auf unterschiedliche Schreibweisen des gleichen Herstellers (vgl. Hinweis Nouba in #14) habe ich sichtbar auch noch keine Rücksicht genommen, auf welcher Basis auch. Auch das hat selbstredend verfremdende Wirkungen in der Folge.

 

Ich habe mir nur einmal einige der Herstellerdaten im Original angesehen. Da müsste zuerst bei unterschiedlichen Schreibweisen Hand angelegt werden: Code:

Auch in anderen verdächtigen Spalten wäre für einheitliche Schreibweisen zu sorgen, bevor man überhaupt einen Ausgliederungsprozess anstösst.

Ist 'ne schöne Aufgabe für Praktikanten oder andere Mitarbeiter, die etwas auf dem Kerbholz haben. *Smilie

 

Hallo zusammen!

@ ebs17:

Ich versuche Fragen zu beantworten, auf die ich eine Antwort geben kann und die etwas mit dem Thema zu tun haben. Für alle nicht beantworteten Fragen versuche ich noch Antworten zu finden oder sie richtig zu beschreiben.

Danke für die Codeanstöße, ich will ehrlich sein, ich brauch etwas um zu verstehen, was es bewirken soll, aber ich geb nicht auf, bis ichs weiss.

@Nouba

Danke für den Hinweis, habe zwar grad keinen Praktikanten zur Hand, aber selbst ist der Mann oder so. Das werde ich nochmal genau durchleuchten.