Live-Forum - Die aktuellen Beiträge
Datum
Titel
29.03.2024 13:14:12
28.03.2024 21:12:36
28.03.2024 18:31:49
Anzeige
Archiv - Navigation
684to688
Aktuelles Verzeichnis
Verzeichnis Index
Übersicht Verzeichnisse
Vorheriger Thread
Rückwärts Blättern
Nächster Thread
Vorwärts blättern
Anzeige
HERBERS
Excel-Forum (Archiv)
20+ Jahre Excel-Kompetenz: Von Anwendern, für Anwender
684to688
684to688
Aktuelles Verzeichnis
Verzeichnis Index
Verzeichnis Index
Übersicht Verzeichnisse
Inhaltsverzeichnis

Daten zusammenführen / Index

Daten zusammenführen / Index
22.10.2005 07:44:07
Ingo
Hallo,
unsere Personaltabelle platzt langsam aus allen Nähten..
Ich möchte nun zusammenhängende Teilbereiche (Lehrgänge, Kentnisse usw) als eigene
Mappen anlegen. Je nach ausgewählter Seite einer MultiPage sollen die entsprechenden Daten aus den Mappen nachgeladen werden.
Das ist alles auch kein Problem.
Was mir Kopfzerbrechen bereitet, ist die Zusammenführung der einzelnen Datensätze der verschiedenen Mappen zu der richtigen Person.
Natürlich hat jeder der Mitarbeiter eine Individualnr. und mein erster Gedanke war, in jeder Mappe die erste Spalte einer Tabelle mit dieser Individualnr. auszustatten. Das funktioniert dann wie eine Art Index - gleichwohl erscheint mir das irgendwie als "Krückenlösung" . Da mir momentan aber nix professionelleres einfällt, wäre ich für eine Inspiration dankbar ;-)
(Auf jeden Fall muß alles in der Umgebung VBA, Excel und kein *.txt-Import stattfinden)
Tja, wenn jemand eine Idee hat....? ;-)
Gruß, Ingo

8
Beiträge zum Forumthread
Beiträge zu diesem Forumthread

Betreff
Datum
Anwender
Anzeige
AW: Daten zusammenführen / Index
22.10.2005 08:59:28
Christoph
Hallo Ingo,
dein Ansatz mit einer ID ist prinzipiell richtig. Diese muss natürlich garantiert eindeutig sein. Da ich deine Datenstruktur nicht kenne, kann ich dir hier nur Tipps geben.
Die Idee, die Daten auf verschiedene Mappen zu verteilen, finde ich nicht sehr glücklich. Bleib erst mal innerhalb einer Mappe und arbeite mit verschiedenen Tabellen.
- entwickle ein Datenmodell (Stichwort: Tabellen und Beziehungen)
- normalisiere die Daten (Stichwort: ein Eintrag kommt in allen Tabellen nur einmal vor)
kleines Bsp:
Tabelle "Mitarbeiter"
&ltPers-ID&gt&ltName&gt&ltVorname&gt&lt...
Tabelle "Abteilung"
&ltAbtl-ID&gt&ltAbteilung&gt
Bezugs-Tabelle "Mitarbeiter-bei-Abteilung"
&ltPers-ID&gt&ltAbtl-ID&gt
Auf die Art wird sichergestellt, dass die Namen der Mitarbeiter und die Namen der Abteilungen nur an einer Stelle gepflegt werden. Wechselt ein Mitarbeiter die Abteilung, wird lediglich der Eintrag in der Bezugstabelle aktualisiert.
Dieses Prinzip wird in Datenbanken wie Access, MySQL, Oracle, etc. verfolgt und lässt sich nach dem o.g. Bsp. auch in Excel umsetzen.
Die Entwicklung eines Datenmodells (welche Daten stehen in welchen Tabellen und in welchen Beziehungen stehen diese miteinander) ist alles andere als zu vernachlässigen. Dies macht je nach Datenstruktur bis zu 30 Prozent der gesamten Entwicklungszeit aus.
weiteres findest du in einschlägiger Literatur zu Datenbanken.
viel Spaß
Gruß
Christoph
Anzeige
Datenmodell
22.10.2005 11:24:42
Ingo
Hallo Christoph,
klasse, dass Du in die Materie eingestiegen bist.
Ohne seitenlange Abhandlungen über unsere desolate Organisationsstruktur verfassen zu wollen ( was mir leider ohne weiteres möglich wäre ) ein Hinweis hinsichtlich der angedachten versch. Mappen. Es gab bereits vor Jahren eine Excellösung (eher eine einfache Tabelle) für die Personaldaten. Wurde damals ohne Weitblick auf mögliche Veränderungen angelegt und alle Erweiterungen einfach nur hinten "angeklebt". Wenn heute jemand darin eine Telefonnr. sucht, gibt es locker 20 Möglichkeiten, die Nr. nicht zu finden...
Momentan haben wir sicher unzählige "schwarze" Listen, die sich jede Abteilung nach ihren Anforderungen zusammenstrickt (Insofern gedachte ich auch die von dir angesprochene zentralistische Datenverwaltung zu verwenden) Und genau die unterschiedlichen Anforderungen waren auch mein Auslöser für die verschiedenen Mappen. Warum sollte immer der ganze Datenbestand in's Array geladen werden, wenn vorher schon klar ist, dass ich nur einen Teil X der Daten benötigen.
Warum befürwortest Du die Ablage der Daten in nur einer Mappe ? (Dein angeführtes Beispiel könnte ich jedenfalls auch mit einzelnen Mappen umsetzen)
Sorry wegen der u.U. dusseligen Fragen, aber ich träume schon von dem ganzen Projekt, das letztlich wesentlich mehr beinhaltet als nur die Personalliste uns sehe vermtl. schon recht einseitig auf die Probleme)
Ingo
Anzeige
AW: Datenmodell
22.10.2005 12:20:14
Christoph
Hi Ingo,
natürlich kannst du bei dem aufgezeigten Weg auch mehrere Mappen verwenden. Hier hast du eben den zusätzlichen Aufwand, diese jeweils zu öffnen, zu schließen und zu speichern. Ebenso musst du sicher sein, dass diese nicht umbenannt, verschoben, gelöscht oder durch eine andere Version ausgetauscht werden.
Wenn das Datenvolumen so groß ist, dass es innerhalb einer Mappe nicht mehr zu handhaben ist, dann kann ich an dieser Stelle nur eine echte Datenbank empfehlen. (Excel ist keine Datenbank)
Solange du (ob mit Tabellen oder Mappen) den aufgezeigten Weg einschlägst, kannst du später - sobald die Firmenleitung die Notwendigkeit einsieht - das Datenmodell und die "normierten" Daten in einer echten Datenbank umsetzen.
Das A und O bei diesem Thema, grade auch in Bezug auf Erweiterbarkeit, ist das Datenmodell, denn das muss als erstes stehen. Wenn später Daten dazu kommen, die in deinem Modell nicht berücksichtigt werden (oder werden können), dann fängst du wieder von vorne an ...
Sorry, aber aus eigener Erfahrung verspreche ich dir an dieser Stelle noch viele Träume zu diesem Thema ...
Gruß
Christoph
Anzeige
AW: Datenmodell
22.10.2005 12:45:51
Ingo
Hi Christoph,
da ich von Dir kein absolutes "nein" gehört habe, werde ich den Weg über die verschiedenen Mappen gehen. Bei der Fahrzeugverwaltung hatte ich bereits im kleinen erfolgreich damit experementiert.Der Punkt umbenennen, löschen usw. durch dritte ist bereits durch eine eigens für das Projekt entwickelte Rechtevergabe gelöst. Man soll ja "nie nie" sagen, aber letztlich gilt es das Projekt nur vor neugierig-gelangweilten Usern zu schützen und nicht vor "hardcore-ich-will-da-rein" Menschen. Die Erweiterbarkeit ist sicher mein größtes Problem. Um, nochmal die Fahrzeugverwaltung nennend, auch zukünftigen Ereignissen Rechnung zu tragen, habe ich eigentlich in allen Bereichen nur die Funktionen entwickelt. Wie groß die Datenmenge ist oder welcher Art wird erst bei Programmaufruf ermittelt. Für einen Nichtprogrammierer fand ich das schon ganz nett ;-)) So in der Art stelle ich mir dann auch die Personalgeschichte vor. Da kann ich mich auch getrost 'reinknien, denn eine Datenbankanwendung wird es auf unterer Ebene wie z.B. unser kleines Lan in absehbarer Zeit nicht geben. Die göttliche Administration hat wie so oft den Datenschutz locker eingeworfen und alle Diskussionen abgewürgt. Also für mich keine verschenkte Zeit und es übt ungemein.
Ich danke Dir für den angenehmen Dialog, Deine Hinweise und die versprochenen Träume ;-))
Gruß, Ingo
Anzeige
Danke für's feedback und viel Erfolg (o.T.)
22.10.2005 13:32:40
Christoph
ein' hab' ich noch ;-)
22.10.2005 16:09:26
Ingo
Nur mal so als Überlegung und ohne Berücksichtigung der Resourcen.
Was hälts du davon, Datenpaare zu bilden ?
Individualnummer (in)
in + Name
in + Vorname
in + Abteilung
in + usw...
Dann hätte man doch seinen Datenpool und könnte je nach Bedarf seinen Warenkorb
zusammenstellen. Und wenn irgendwann jemand der Meinung sei man müsse auch die
Träger von geringelten Socken erfassen, wäre bei dem System nirgends eine Einschränkung
sondern es kommt dann halt in + Socke hinzu...?
Und nun gebe ich Dir für den Rest des Wochenende auch frei ;-))
Gruß, Ingo
AW: ein' hab' ich noch ;-)
23.10.2005 19:39:59
Christoph
Die ID an jedes Attribut zu kleben ist IMHO der falsche Weg - denn früher oder später wirst an grenzen stoßen, die mit deinem Weg nicht mehr zu lösen sind. Ganz zu schweigen von der Performance - man spannt ja auch keine Pferde vor's Auto.
Bei relationalen Datenbanken ist das auch gar nicht notwendig. Wenn deine Daten "normalisiert" sind, (google mal nach Normalisierung oder nach Normalform) ordnest du diesen einen Schlüssel (ID) zu. Diesen trägst du zu jeder Tabelle in eine Spalte (Bsp.Spalte A). Damit ist dein Datensatz (=Zeile) eindeutig zu identifizieren. Egal wieviele unterschiedliche "Müller's" in der Tabelle stehen, du weißt immer, welchen "Müller" du meinst.
Die Bezüge zu Daten anderer Tabellen werden über sog. Fremdschlüssel hergestellt (der Schlüssel aus Tabelle2 wird als Fremdschlüssel in Tabelle1 geführt). Du musst also nur noch die Schlüssel (Beziehungen) zuordnen und alle Daten werden jeweils nur in einer Tabelle gepflegt. Der erste Aufwand ist das Datenmodell und die damit einhergehende Normalisierung. Wenn das Datenmodell steht, hast du damit auch alle benötigten Tabellen festgelegt. Und dann (sinnvollerweise erst dann) kannst du anfangen zu programmieren.
Das schöne ist: auf dieser Basis lässt sich auch SQL in Excel einsetzen.
weiterhin viel Spaß
Christoph
Anzeige
AW: ein' hab' ich noch ;-)
25.10.2005 16:22:16
Ingo
Hi Christoph,
ich konnte es natürlich lassen, mit den Datenpaaren zu spielen ;-) und kann Dich nur bestätigen...lach...toll, wie schnell man mit wenigen Datensätzen bei richtiger Vorgehensweise seine Rechner in lahme Möhren verwandelt.
Die Tabellen sind jetzt im Grundgerüst bereits thematisch aufgebaut. Ein paar Gesprächsrunden werden wohl noch folgen, damit Datenzusammenhänge ermittelt werden.Ist doch recht umfangreich das ganze, zumal schon die ersten Begehrlichkeiten " wir könnten doch damit auch..." geweckt wurden. Jedenfalls warst Du mir eine Große Hilfe beim Einschlagen der richtigen Richtung. 'Mal schauen, wie sich das alles entwickelt. Zur Not schreie ich hier wieder um Hilfe ;-)
Gruß, Ingo
Anzeige

Links zu Excel-Dialogen

Beliebteste Forumthreads (12 Monate)

Anzeige

Beliebteste Forumthreads (12 Monate)

Anzeige
Anzeige
Anzeige