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

Hallo zusammen!

Aus tbl_DATAS_modified sind die jetzigen Tabellen normalisiert,
ausgenommen tbl_AnlageArtikel. Diese wird hier versucht, erstellt zu werden. Es sieht im ersten Moment gut aus.
Wenn man aber qry_DATAS_modified und qry_DATAS_modified_Gegencheck vergleicht, sieht man eine
falsche Aufteilung. Wer hilft mir, eine Lösung zu finden?

Um das Ganze übersichtlich zu halten, habe ich die Daten reduziert.

https://drive.google.com/open?id=1be...jU1lgJR-zjk_oO

Ausserdem den vorausgehenden Normalisierungsprozess in einer anderen DB, welche wegen der Größe hier nicht hochladbar ist, aber im Forum aus einer Cloud downloadbar ist.

Ich hab mir im Freundeskreis für so manches helfen lassen und
bin nicht mit jeder Codezeile voll vertraut. Aber ich will lernen.

Mir ist klar, dass ich die tbl_Lagerfach auch noch füllen muss,
mir würde aber schon mal der Schritt reichen, die tbl_AnlageArtikel richtig zu füllen.

Grüße

tfluege

 

Das Modell scheint mir zu wässrig (mit anderen Worten falsch) zu sein, als dass es sich lohnt, Daten überhaupt zu transferieren.

 

Hallo nuoba,

könntest Du mit bitte sagen was Du genau meinst?

Wo liegt Deiner Meinung nach der Fehler u. was wäre nötig um diesen zu eliminieren?

Danke für deine Rückmeldung !

Gruß

Tfluege

 

Wenn ein Lagerartikel von mehreren Abteilungen verwendet wird, und eine Abteilung mehrere Lagerartikel verwendet, wäre das eine klassische m:n-Beziehung. Andererseits sollte man aber auch prüfen, ob diese Zuordnung nicht besser über die Struktur Abteilung -> Kostenstelle -> Asset (Anlage) bedient wird. D. h., weder Abteilung, noch Kostenstelle oder Anlage wären ein Attribut eines Artikels.

Ob es generell gilt, einen Lagerartikel immer nur in einem Lagerfach vorzufinden, weiß ich nicht. Große Stückzahlen oder große Volumina eines Artikel könnten durchaus auch an mehreren Orten aufbewahrt sein.

Ein Artikeltyp wäre Kandidat für eine eigene Tabelle.

 

Hallo nuoba,

ich versuche das mal zu veranschaulichen.

Wir sind eine Abteilung in einer Aussenstelle.

Wir beziehen unsere ET in der Regel aus dem Zentrallager, an das wir keine direkte Anbindung haben, ausser einer SAP basierter Suchseite (welche sehr umständlich und zeitaufwendig ist).

Deshalb sammeln wir die ET-Daten der für uns benötigten Teile in einer DB, früher Excelliste. Damit die Suche nach Teilen schneller und effizienter geht.
Seither waren wir in 2 getrennte Abteilungen aufgeteilt, somit auch 2 verschieden DB. Diese sollen nun zusammengeführt werden, wobei in beiden DB`s die Felder nur so gut ausgefüllt sind, wie der entsprechende der es eingetragen hat für nötig gehalten hat.

Dann haben wir noch das Konsignationslager, welches sich bei uns vor Ort befindet. Dort werden die Teile gelagert, die immer vor Ort vorhanden sein müßen, wegen schnelleren Wegen usw. Das Konsi hat z.B. auch ein Buchungssystem, wekches in der aktuellen DB aber noch nicht eingebaut ist, da die Daten ja noch nicht sauber sind. Dieses Buchungssystem gibt es in den Orginal Such DB`s natürlich nicht, da es keinerlei Anbindung an das SAP System gibt(was wahrscheinlich auch nicht sinnvoll wäre, da dort alle Teile von allen Abteilungen drin sind und das sind so ca. 150 Abteilungen)

Die ganzen ET im Konsignationslager werden in einem Megamat gelagert, ähnlich einem elektrischem Patanoster. Dort gibt es diverse Schubladen, mit diversen ET.
Da Lagerplatz nur gering vorhanden ist, sind dort natürlich auch verschiedene Teile in einer Schublade untergebracht.

Das ganze System ist(sollte) auf B-Nummern aufgebaut(sein), die vom Zentrallager jedem Bauteil zugeordnet werden, also eine Art interne eindeutige Zuordnungsnummer. Selbst in diesem System ist es so, das ein und das selbe Teil mehrfach angelegt sein kann, weil sich die Typbezeichnung etwas verändert hat, oder weil der Besteller des Teils die Daten nicht richtig eingetragen hat.

Soweit so gut, jetzt haben wir aber auch den Fall, das im Konsignationslager ET gelagert werden, die extra oder nur nach Zeichnungsnummer gefertigt werden, somit keine B-Nummer haben. Das macht das ganze etwas schwieriger.

Zum Aufbau der Abteilungen:

Wir sind aufgeteilt in Fertigung und Montage.
In der Fertigung gibt es 3 Abteilungen in der Montage sind es etliche mehr.
Zudem sind in den DB`s noch Altabteilungen drin, da dort schon Teile eingetragen sind, die auch in den noch vorhandenen Abteilungen gebraucht werden. Dann hat jede Abteilung Maschinen mit eindeutigen EQ-Nummern und Bezeichnungen, wobei die Bezeichnung auch in anderen Kostenstellen vorkommen kann, aber die EQ-Nummer ist immer einzigartig einer Abteilung zugeordnet, außer die Maschine wird umgesetzt.

Die von Dir angesprochene Zuordnung ist durchaus sinnvoll, da die ET für die Maschinen im Normalfall ja durch B-Nummer und EQ-Nummer eindeutig zugeordnet sind.

Zur 2ten Anmerkung: In der Regel sind die Artikel im Konsignationslager immer dem gleichen Lagerfach zugeordnet (ausser es wird umgeräumt durch Artikelentfall oder so). Für das Zentrallager ist das unerheblich, da die Et angeliefert werden.

So, jetzt hoffe ich, das ganze ist nicht zu verwirrend, da nicht jeder in so einem System arbeitet.

MfG

tfluege

 

Die Problematik verstehe ich schon durch und durch. Und wie aus meinem vorletzten Posting von mir zu ersehen ist, gibt es ja offensichtlich Doubletten in unterschiedlicher Schreibweise. D.h. z. Bsp., dass der Festo-Zylinder XYZ nicht nur an Anlage A sondern auch in Anlage C und X in jeweils anderen Abteilungen verwendet wird. Deshalb stelle ich ein Attribut wie (Anlage oder Abteilung oder Kostenstelle) für einen Artikel in Zweifel.

Megamaten sind mir ein Begriff. Die Dinger habe ich selbst schon des Öfteren bedient. Aus meiner Praxis ist mir bekannt, dass manch ein Ersatzteil auch mehr als einen Förderkorb (Gondel) beansprucht, weil physikalisch kein ausreichender Platz für X-Stück eines Ersatzteils in einer Gondel vorhanden wäre. Das muss ja nicht bedeuten, dass das bei Euch genauso ist - zu prüfen wäre es aber.

 

Hallo Nouba,
vielen Dank dass Du mich nicht im Regen stehen lassen willst.
Wenn Deiner Meinung nach mein Modell falsch ist, dann muss ich das natürlich
untersuchen, denn es muss gewährleistet sein, dass ich bei der Entscheidung,
meine Daten einfach manuell einzugeben, keine unnötigen und unbrauchbaren
Aufteilungen in ein falsches DB_Modell vornehme.
Meine bisherige Modellierungsidee auf Papier ist:
1 Kostenstelle hat n Anlagen.
1 Anlage gehört zu 1 Kostenstelle.
1 Anlage enthält n Artikel.
1 Anlage hat n Dokumente
1 Artikel kann auch in n Anlagen enthalten sein.
1 Anlagenummer ist einzigartig und kann nicht doppelt vorkommen.
1 Artikel hat eine eindeutige ArtikelNr (bisher auch B_Nummer genannt).
1 AnlageArtikel hat n LagerfachBuchungen

tbl_Abteilung und tbl_Lagerfach sind bisher in 1:n Beziehung zu tbl_Artikel.
Das könnte falsch sein. Sie wären auch in 1:n Beziehung zu tbl_AnlageArtikel praktikabel.

Bitte gib mir Deine Meinung zu dem DB-Modell.
Damit auch möglichst viele dazu eine Meinung abgeben können, habe ich eine Access 2002-2003 Version erstellt,
welche ich hier direkt ins Forum stelle. Ich hab diesen Tipp des öfteren gelesen und finde ihn sehr praktikabel.

MfG

tfluege

 

Da ist wohl einer auf der Suche selber verloren gegangen, oder er hat es sich anders überlegt.
Naja, was solls. Da wäre am seit anderthalb Wochen vorliegenden Vorschlag nichts zusätzlich zu berücksichtigen.

Die eigentliche Frage war:

... geht das und wie geht das?

Ich meinte in allen Phasen, dass das mit Anfügeabfragen (eine pro Zieltabelle) möglich ist. Nachfolgend eine Umsetzung, die auf die etwa 12.000 Datensätze der Ausgangstabelle etwa 6 Sekunden benötigt statt der bisher genannten Minutenzeiträume, nach Korrekturen an den vorhandenen Indizierungen. Die Frage der Umsetzbarkeit an sich klärt sich damit von alleine.

Allerdings läuft hier die Verteilung der Daten nur auf 8 von 11 Tabellen, für die verbliebenen 3 Tabellen gibt es schlicht keinen Stoff in der Ausgangstabelle.
Die hier vorgenommene Verteilung beschränkt sich auf das Eintragen von eindeutigen Werten in die Zieltabellen nebst Erzeugung von Primärschlüsseln und deren Weiterverwendung als Fremdschlüssel in den verknüpften Tabellen und damit auf die Kernaufgabe.
Mein Ansinnen, die Daten möglichst vollständig und verlustfrei in das Datenmodell zu bringen, was nach meiner Auffassung selbstverständlich sein sollte, ist nicht durchführbar, da Ausgangsdaten und vorgelegtes Datenmodell nicht zueinander passen wegen offensichtlicher Fehler darin. Im Code gibt es dazu Hinweise.
An irgendeiner Stelle war von "besonderer Logik" die Rede. Den Begriff selber kann man aber nicht in Code umsetzen. Bei fehlenden Hinweisen braucht man dann auch nicht über Ersatzmaßnahmen zur Erhaltung von Informationen nachdenken, und nun ist zusätzlich das Datenmodell aus zusätzlichen Gründen in die Diskussion gekommen.

Fakt ist aber, dass eine aufwändigere Datenübertragung erst dann richtig Sinn macht, wenn das Datenmodell im Zielsystem fertig und belastbar ist. Die Ausgangsdaten sollten dann auch bereits aufgeräumt sein, auf die Varianz bei den Herstellernamen (als Beispiel) wurde weiter vorne schon hingewiesen.

Was vielleicht auch auffallen dürfte: Der Vorschlag verwendet die ursprünglichste Form der Ausgangstabelle.
Code:

Was zu beweisen war: Die Aufteilung klappt auch bei mehr als einer Beziehung.
Wenn dann der Eifer groß genug war, die sonstigen Probleme zu lösen und dann hier gezeigte Anweisungen sinngemäß anzupassen, könnte man dann auch zu einem in der Praxis nutzbaren System kommen.

 

Hallo zusammen!

Ich kann nachvollziehen, das es hier zum Anschein von Desinteresse meinerseits kommen kann.

Dem kann ich nur widersprechen, aber leider habe ich auch noch Familie und
möchte dieses Thema so weit wie möglich auf der Arbeit erledigen,
das ist im 3-Schichtbetrieb und vielen Reparaturen nicht immer so einfach.


@ebs17:

ich werde mich anstrengen, Deinen Vorschlag mal auszuprobieren.
Bitte habt Geduld. Mir flutschen die Dinge nicht soo schnell aus dem Hirn in die Finger und auf die Tasten.
Ich bin im Gegensatz zu Euch noch ein blutiger Anfänger.
Manches (z.B. SQL) muss ich erst einmal mich einarbeiten. Das geht nicht so schnell.
Ausserdem mache ich das wie gesagt nebenbei während meinen Arbeitszeiten und darin ganz anderen Aufgaben.
Du hast Anforderer und Lagerbestand als noch offen bezeichnet.
Die gehören in tbl_LagerBuchhaltung in User und BuchungsAnz.

Kannst Du mir dafür auch noch einen SQL Code geben, bitte?

Vielen Dank für die Geduld und Hilfe bisher.

MfG

tfluege

 

Korrekturen an den vorhandenen Indizierungen:
=> Beseitigung von doppelten und damit nutzlosen Indizes. Was man hat, kann man (weitgehend) sehen, was im Tabellenentwurf im Indexfenster erscheint.
=> Ergänzung sinnvoller Indizes. Wo man verknüpft, kann ein Index hilfreich sein. Vollständige Lektüre: Performance in Abfragen
Indizierung hat hier nichts mit Funktionieren an sich zu tun, sondern mit der Abfragegeschwindigkeit.

Im Code gibt es dazu Hinweise: Liest Du jede Zeile im Code, auch Kommentare?

 

Hallo ebs17!

Anscheinend lese ich nicht richtig, mein Fehler!
Ich werde es nochmal Schritt für Schritt durchgehen!

Das von Dir verlinkte PDF nehme ich mir heute Abend auf Arbeit vor, werde aber wohl auch hier etwas mehr Zeit aufwenden müssen um es zu verstehen (habe gerade Zuhause ganz kurz reingeschaut).

Vielen Dank vorerstmal!

MfG

tfluege

 

Das geht nicht. Eindeutige Inhalte in einem Tabellenfeld, die die Existenz eines Datensatzes begründen, sind nicht erkennbar.
tbl_LagerBuchhaltung benötigt zwei Fremdschlüssel, und tbl_Buchungsart bietet keine Inhalte und aus der Quelltabelle keine Zuordnung. Damit ist die Maßnahme an der Stelle durch den einen fehlenden Schlüssel beendet.

Aus ähnlicher Sicht erscheint mir die Tabelle tbl_AnlageArtikel als überflüssig (eher störend und aufwandserhöhend), weil ohne nachvollziehbare Funktion. Die Schlüssel AnlageID und ArtikelID könnte man unmittelbar in tbl_LagerBuchhaltung einleiten, wenn sie dort denn benötigt werden.

Meine Hinweise kommen aber nur aus funtioneller Sicht des Codens - wenn da etwas gar nicht oder höchst umständlich geht, können dafür durchaus Strukturprobleme verantwortlich sein statt die eigene Unfähigkeit (für die es ein genügend hohes Restrisiko gibt).
Ansonsten sage ich nichts zum Datenmodell, da ich Euren Workflow nicht kenne und ich daher überhaupt keine Grundlagen zur Beurteilung habe.


So ganz am Rande bemerkt: Dieses Projekt ist für jemanden, der soeben und damit Access und Datenbanken kennenlernt, einige Nummern zu groß, sichtbar ja auch für einige fachliche Helfer im Hintergrund (vor bunten Formularen kommt einiges anderes). Auch mit Forumshilfe wirst Du wegen der abgesplitterten und Teilinformationen irgendwo mitten aus dem Ganzen höchst schwierig zu einem befriedigenden Ergebnis kommen.
Wenn die DB betriebswichtig ist, engagiert einen Fachmann, der die richtigen Grundlagen legt. Bei Zuarbeit und Pflege hast Du dann genug Brot, um zu lernen.

 

Hallo ebs17,

Dein Zitat:
Aus ähnlicher Sicht erscheint mir die Tabelle tbl_AnlageArtikel als überflüssig
(eher störend und aufwandserhöhend), weil ohne nachvollziehbare Funktion.

Das muss doch in einer m:n Tabelle aufgelöst werden, so wie ich es meine, gelernt zu haben.
Ich will pro Anlage auch jeden Artikel sehen und eintragen können.
1 Anlage enthält n Artikel.
1 Artikel kann auch in n Anlagen enthalten sein. (thread #22)

Du hast recht damit, dass ich allgemein überfordert bin. Alle Deine Programmieranforderungen
an mich bedeuten für mich min. 6 Monate zusätzliche Voll-Tageslernzeit.

Ich hoffte insgeheim, eine vorgekaute Lösung zu bekommen, welche ich von hinten her gerne
Schritt für Schritt nachvollzogen hätte (in der Abarbeitungsgeschwindigkeit, welche an meine Möglichkeiten angepasst ist).
Mir geht es um einen einmaligen Import der Daten und nicht um weitere zukünftige Importe.

Letztendlich sagst du nichts anderes als meine Freunde, welche mir empfohlen hatten,
in Spezialforen mit meinem Problem es nochmal zu probieren.
Diese Freunde haben auch durchaus Lösungen mit SQL angeboten, welches ich aber noch nicht verstanden hatte.
Ich fand die VBA Lösungen für mich leichter nachvollziehbar und muss sagen, dass es mir bei einem einmaligen, aber richtigen Import
völlig egal ist, in welcher Geschwindigkeit der stattfindet. Hauptsache das Ergebnis stimmt.
Einige Fachfreunde gaben teilweise schon viel früher auf und empfahlen, die Daten manuell einzugeben,
wobei ich keine zeitaufwändige Überprüfung mehr benötige, welche nach einer automatisierten Eingabe
wieder nötig sei. Dafür solle man ein komfortables Suchformular nehmen und sich dort die
Artikel zusammenklicken und dann in einem Rutsch per VBA an eine Anlage weitergeben.

Deine Lösung hat mich auf jeden Fall einen wichtigen Schritt weitergebracht, wobei ich
noch überprüfen muss, ob die Ergebnisse Deiner Lösung für mich richtig sind.
Eines fällt mir jedenfalls dabei jetzt schon auf. Es gibt in Deinem Ergebnis, dass eine 1 Anlage (EqNummer) in
n Kostenstellen vorkommt, was laut meinen Vorgaben in (thread #22) nicht vorkommen darf.

Vielleicht hilft mir ja noch ein Spezialist für DB-Modellierungen anhand der Vorgaben von thread #22


MfG

tfluege

 

Ich habe überhaupt keine Anforderungen gestellt, sondern eine lauffähige Routine vorgelegt, die Daten aus den Quelle in das Datenmodell überträgt. Dabei wurden Eindeutigkeiten (in der Tabelle) berücksichtigt. Wo weitere Informationen diese Eindeutigkeiten verletzen, habe ich diese weiteren Informationen nicht berücksichtigt. Das sieht man offensichtlich auch bei der Artikeltabelle, die sich an den Artikelnummern orientiert und daher die Fremdschlüssel unberücksichtigt lässt, weil verschiedene Artikelnummern zu mehr als einer FS-Kombi zugeordnet werden (lt. Quelltabelle). Daher findet lt. meinen Daten überhaupt keine Zusammenführung zwischen Eqnummern und Kostenstellen statt und somit auch keine falsche.

Klar. Wenn man bei der Automatisierung schludert, muss man nachbearbeiten, und bei 12.000 Datensätzen macht das keinen Spass.
Die Nichtberücksichtigung von die Struktur störenden Informationen sehe ich übrigens als sinnvoller und konsequenter an, als beliebige willkürlich auszuwählen und die einzusetzen. Denn hier kommt man zwangsläufig zu einer Nachbearbeitung, die man dann auch über Zusatztabellen und -formulare steuern kann.
Und selbstverständlich habe ich willkürlich verstreute Fremdschlüsselfelder in anderen Tabellen völlig ignoriert, schon aus Prinzip, aber auch, weil auch sie Eindeutigkeiten gestört hätten.

Ja, fertig, höchstkommentiert, schnellstens, kostenlos. Wer will das nicht.

Ich erinnere an den Thementitel. Nur daran habe ich mich versucht. Wenn das "fertige" Datenmodell und die Importdaten objektiv nicht zusammenpassen, was solls? Nur wenn die Voraussetzungen stimmen, kann eine Verarbeitung reibungslos laufen. Sicher müßig, aber ich sprach auch schon von ORIGINALEN QUELLDATEN. Womöglich hätten sich andere Ansatzpunkte ergeben als die vorgelegten "modified-original"-Datenzusammenstellungen mit eingelegten Dummys.

Über das Datenmodell in Realfunktion mag und kann ich nicht nachdenken. Mich stört schon, dass da gar keine Zeitstempel enthalten sind, es sich also um ein statisches System handelt. Da in meiner Vorstellung eine Datenbank ein langlebiges Instrument ist, ist für mich selbstverständlich, dass es in der Zeit neben Lagerbeständen noch ganz andere Bewegungen geben wird, womit dieses statisch-starre System auseinanderfällt und neu geordnet werden muss => Supergau für das Datenmodell.
Bei solchen grundsätzlichen Zweifeln gehen da bei mir die Lichter aus, womit sich dann auch die Beschäftigung mit vorhandenen Details erübrigt.

 

Hallo ebs17!

Danke für Deine Anregungen.

Ich werde jetzt einfach mal die Rohdaten wie ich sie bekommen habe hier posten. Durch die Größenbeschränkung erstelle ich noch eine Antwort, damit ich alle Dateien online bekomme!

Hoffe das ist ok?!

MfG

tfluege