Neue Datenbank aufbauen - Ideen und Hilfen erwünscht

[bluewalk]

Liebes Forum,

es ist schon wirklich recht lange her, daß ich eine DB erstellt habe. Mein Problem ist, daß ich echt eingerostet bin 
und Eure Hilfe brauche.

Ich soll / will für meine Verein eine DB erstellen, die die Mitgliederdaten enthält, Bankkontodaten, das Inventar etc.
Das ist auch nicht das Problem - Sondern wohl eher ein falscher Gedankengang von mir: über die von mir erstellten Tabellen (und dann die basierende Abfrage) habe ich ein Formular erstellt. Kein Problem.

Mein Problem ist eher, daß ich am 255-limit kratze und ich habe noch so viele Felder, die ich mit einarbeiten sollte.
Den RAhmen sprengt eingentlich nur die Inventarisierung. Die ist allerdings wichtig, denn alle Vorstandsmitglieder sollen auf die Datenbank drauf zugreifen sollen (mit speziellen Rechten): Präsident, Kassier, Schriftführer, Ordensgremium, Festkomitee, Funduswart, Archivar. Entsprechend ist also die Liste der Wünsche lang.

Wie kann ich das am sinvollsten bewerkstelligen?
Es wäre für den Anwender toll, wenn er auf einen Blick sehen kann, was welches Mitglied an Uniformen, Kleidern und Instrumente bei sich hat. Ich stelle mir vor, daß es für jedes Kleidungsstück ein Ausgabedatum, ein Rückgabedatum, die ja/nein-Abfrage für Ausgabe und Rückgabe, ein Bemerkungsfeld (wegen Beschädigung o.ä.), Größe und Inventarnummer.
Momentan steht jedes Kleidungsstück und Instrument etc. im Formular auf einer zweiten Seite mit den oben genannten Kriterien.

Schön wäre es - damit die übersicht einfacher wird (die Übersicht ist vorhanden, ich würde es grafisch lösen können, bzw. über verschiedene Reiter), wenn ich anhand eines Auswahlfelds der Vereinsaktivität (z.b. Musiker, Vorstand, Kinder) ein entsprechendes Formular aufbereitet wird. =====> oder wäre ein Unterformular besser? könnte ich das so dann lösen?

Hochladen kann ich euch nichts, ich habe meinen Entwurf verworfen aus den o.g. Problem wegen dem Limit und dem Formular. Befinde mich also noch im Aufbau.

lieben Dank für Eure Hilfe und Ideen

Grüßle vom Bodensee

[MzKlMu]

Hallo,
wer in einer Tabelle an die Feldzahl von 255 kommt hat drastische Fehler im Aufbau.
Hier ist ein Zerlegung in Teiltabellen unbedingt notwendig. Aber nicht einfach die Felder in weitere Tabellen, sondern nach dem Prinzip einer relationalen Datenbank.

Den RAhmen sprengt eingentlich nur die Inventarisierung

wieso, das Inventar sollte als Datensätze vorliegen und nicht als Felder bzw. Feldnamen.
Kannst Du das mit dem Inventar mal erläutern, warum benötigst Du da so viele Felder?

Es wäre trotzdem nicht schlecht gewesen, die bisherige DB mal hochzuladen, damit man sieht, wie die Tabelle nach den Normalisierungsregeln aufzuteilen ist.
Erstelle die DB (die für das Forum) bitte unbedingt in der Version 2003, die neueren Versionen sind immer noch nicht so stark verbreitet.

[bluewalk]

Hallo,

danke für deine Antwort. Ich muß dich berichtigen: nicht die Tabelle hat 255 Felder, sondern schlußendlich die Abfrage, die mir die Daten von den zugrundeliegenden Tabellen für das Hauptformular aufbereitet.

Von der Version her habe ich mich direkt von A97 auf A10 erneuert. Die alte Version A97 ist nicht mehr vorhanden, würde uns also nix bringen. Die 2010 ist nicht stabil? Da wie schon erwähnt der erste Versuch daran scheiterte, daß die Abfrage am Limit kratzt, habe ich es verständlicherweise verworfen. Ich weiß nicht, wo ich noch normalisieren könnte...bin wirklich ratlos.

Das Inventar erfasst alle Kleidung die vorhanden oder ausgegeben wurde. Jedes Hemd erhält eine Nummer, soll vom Zustand her beschrieben werden und die Größe angeben. So verhält es sich mit den Hüten, den Uniformen etc. gleich. Dazu soll es Tabellen geben. Auch für den Lagerort.
Aber: für jedes Inventar möchte ich im Hauptformular dann ein Feld für das Ausgabedatum, die Ja/nein-Abfrage für den Erhalt, das Rückgabedatum und auch wieder die Abfrage der Rückgabe erstellen. Und das ist eigentlich dann das Problem, daß es mir dann mit den Feldern nicht mehr reicht.

Warum soll das angezeigt werden? Ich will den Verantwortlichen die Möglichkeit geben, alles über eine einzige Eingabemaske eintragen (und schließlih auch sehen) zu können. Über die  ja/nein-Abfragen steuere ich dann die Berichte.

danke

[MzKlMu]

Hallo,
da fehlt noch viel, zur Normalisierung. Auch wenn eine Abfrage mehr als 255 Felder benötigt ist das Datenmodell mit ziemlicher Sicherheit falsch.

für jedes Inventar möchte ich im Hauptformular dann ein Feld für das Ausgabedatum, die Ja/nein-Abfrage für den Erhalt, das Rückgabedatum und auch wieder die Abfrage der Rückgabe erstellen.

Dazu benötigst Du 4 Felder (5 mit ID), ein Fremdschlüssel zum Inventar, ein Fremdschlüssel zur Person, ein Feld für die Vorgangsart (Ausgabe/Rückgabe) und ein Datumsfeld (Vorgangsdatum). Die Ja/Nein Felder sind überflüssig. Ausgabedatum eingetragen = ausgegeben, wozu denn noch Ja/Nein?

Für das Inventar (alles) ist eine eigene Tabelle zu erstellen, aus der dann ausgewählt wird.

Die 2010 ist nicht stabil?

wer hat das geschrieben? Ich (und andere auch) haben kein Access2010. Du kannst auch mit Access2010 eine Access2003 (MDB) erstellen.

Deine Angaben sind wenig hilfreich, weil aus der Beschreibung nur wenige Zusammenhänge erkennbar sind.

[bluewalk]

hallo,

hmm, so habe ich es ja versucht aufzubauen - muß aber wohl nochmals richtig darüber nachdenken, wie ich das dann alles zusammenfassen kann. ich habe für das inventar verschiedene tabellen, die ich nach den jeweiligen gruppen sortiert habe. daß nur wenig zusammenhänge erkennbar sind, verstehe ich nicht. habe ich zuwenig informationen gegeben? oder bin ich auf die fragen nicht richtig eingegangen?? - sorry, wenn es so ist.

mit den ja/nein felder wollte ich die berichte steuern.  du meinst, dass das nicht nötig ist? gut, den steuercode über das datum kenne ich so nicht, aber lerne gerne dazu. dadurch reduziert sich ja auf jeden fall die anzahl der felder für die hauptabfrage...

das mit a10 habe ich falsch interpretiert von dir. es ist nicht viel verbreitet. habe aber trotzdem auch gelesen, daß es nicht so stabil sei. anyway, das soll aber ja jetzt nicht unser problem sein. ich mach mich jetzt nochmals ans werk und schaue, wie weit ich komme.

[MzKlMu]

Hallo,

ich habe für das inventar verschiedene tabellen,

das ist bereits der 1. grundsätzliche Fehler, das Inventar gehört in eine Tabelle, mit einem Schlüsselfeld für die Gruppen.

[DF6GL]

Hallo,

Du musst Dir in aller erster Linie um die Datenzusammenhänge im Klaren werden, die dann strukturiert und über Beziehungen miteinander in Verbindung gebracht werden (müssen). --> Normalisierung.  Siehe dazu u. st. Links 1 und 1a.


Bevor Gedanken an  Abfragen, Formulare und Berichte verschwendet werden, MUSS dieses Daten- (Tabellen-) Gerüst konsistent stehen....


An der (scheinbaren)  Instabilität von A2010 ist in aller Regel der Entwickler schuld, der entweder schludrig gearbeitet hat oder sich nicht an die Access-Spezifikationen und auch die neuen "Features" gehalten hat.

Dass gilt aber für alle Versionen..

[oma]

Hallo,

wer in einer Tabelle an die Feldzahl von 255 kommt hat drastische Fehler im Aufbau

ich benötige in meiner Problematik öfters mehr als 255 Felder in einer Tabelle ; arbeite also häufiger mit diesen "drastischen Fehler" aber zum Glück trotzdem erfolgreich, da eine Aufteilung in mehreren Tabellen und damit zu arbeiten, möglich ist.

Gruß Oma

[database]

Hallo,
mal abgesehen davon, dass die Hinweise und Ratschläge von MzKlMu und DF6GL einer unbedingten Beachtung wert sind ...

Ich will den Verantwortlichen die Möglichkeit geben, alles über eine einzige Eingabemaske eintragen (und schließlih auch sehen) zu können

Kann mir eigentlich nicht vorstellen, dass 255 Felder auf einem Formular in irgend einer Form der Übersichtlichkeit dienlich sein könnten.
Du hast ja schon mal daran gedacht die Informationen in Registern auf einem Hauptformular anzubieten.
Genauso kann der Ausgabebestand für eine bestimmte Person in einem UFo zusammengefasst werden (richtiger DB-Aufbau vorausgesetzt) ohne 255 Felder anzubieten von denen dann 230 leer sind.

[bluewalk]

hallo an alle,
danke für die infos. ihr seid super

Kann mir eigentlich nicht vorstellen, dass 255 Felder auf einem Formular in irgend einer Form der Übersichtlichkeit dienlich sein könnten.
Du hast ja schon mal daran gedacht die Informationen in Registern auf einem Hauptformular anzubieten.

hatte ich weiter oben schon erwähnt, ich benutze register, das ist wohl auch der grund, warum es dann am limit kratzt.

Genauso kann der Ausgabebestand für eine bestimmte Person in einem UFo zusammengefasst werden (richtiger DB-Aufbau vorausgesetzt) ohne 255 Felder anzubieten von denen dann 230 leer sind

genau das schwebt mir vor. allerdings nicht nach dem benutzer der davor sitzt, sondern nach der gruppenzugehörigkeit des mitglieds.
wie kann ich das umsetzten, hast du ideen?

@oma,
ich arbeite nicht mit 255feldern pro tabelle, sondern die tabellenfelder insgesamt in der darauf basierenden abfrage ergeben dann die 255 felder. wie hast du das gelöst?

@franz,
genau. darum die überschrift. nich fehlt mir komplett der durchblick aufgrund der langen pause. ich habe mir insoweit die gedanken gemacht, daß ich sofort alle für mich wichtigen felder (also die abfragefelder ja/nein für die berichte) einbeziehe. im nachhinein macht das wenig spaß und alle würde mich fragen, warum ich denn nicht gleich dran gedacht habe. denke aber schon, daß ich noch hier und da ein gedankenfehler habe. noch steht alles auf dem papier und ich schieb das hin und her.

das ist bereits der 1. grundsätzliche Fehler, das Inventar gehört in eine Tabelle, mit einem Schlüsselfeld für die Gruppen

hast recht, das ist mir heute mittag auch so durch den kopf gegangen und arbeite schon daran....

[database]

Hallo,

nicht nach dem benutzer der davor sitzt, sondern nach der gruppenzugehörigkeit des mitglieds

Ja natürlich habe ich Ideen dazu - sonst wäre es ja fad. 
Ein richtiger Datenbankaufbau ermöglicht, die Gruppenzugehörigkeit eines Mitglieds zu ermitteln,
Das Kennzeichen - der Fremdschlüssel - der Gruppe ist dann Bestandteil eines Mitgliederdatensatzes oder bei einem anderen Aufbau
Bestandteil eines Datensatzes in einer Zwischentabelle (wir in jedem Fall benötigt, wenn ein Mitglied in mehreren Gruppen vorhanden sein kann).

So ist es dann möglich jedes Mitglied einer Gruppe aufzulisten und/oder festzustellen in welcher Gruppe ein bestimmtes Mitglied Mitglied ist.
Da in der Datenbank die Ausgaben mit dem Mitglied in Verbindung stehen ist somit möglich die Ausgaben auf die Gruppenmitgliedschaft zu beziehen.

Passende HaFo / UFo Kostrukte oder Formulare mit Möglichkeit von 'Vorauswahlen' durch abhängige Kombifelder mit Unterformular bzw. entsprechend aufbereitete Berichte lassen hier kaum einen Auswertungswunsch offen.

[bluewalk]

Hallo zusammen,

ich habe mich jetzt mal hingesetz und nach meinem minimalen verständis versucht eine DB zu erstellen. ich bin sicher noch nicht fertig, aber evtl. kann schon das ein oder andere von euch herausgelesen werden und ihr mir noch weitere ratschläge zur verbesserung und hinweise auf fehler mitteilen??

ich habe die idee, alles gleich in einer inventarliste zu speichern wieder verworfen. ich müßte so 100x saalhemd eingeben. oder auch hut oder uniform. da war ich jetzt doch viel zu faul dazu - und sinn macht das ja auch nicht. ich muß allerdings diese dinge definitiv aufführen und dann auch noch durchnummerieren, damit ich die eindeutige identifikation habe.

hättet ihr eine bessere idee?

danke und grüße

[database]

Hallo,

sieht nicht so schlecht aus - bis auf ein paar Kleinigkeiten:

Sämtliche Orden-Bezüge müssen aus der tb_Ausgabe raus
Ordentyp_key hat in der tb_Inventar nichts zu suchen
Postenvergabe_key hat in der tb_Mitglieder nichts zu suchen
Orden_key muss ebenfalls aus der tb_Mitglieder raus
Der Werdegang, so wie du ihn in der Feldbeschreibung schilderst muss in eine eigene Tabelle!
Die Zahlungsart kannst du in der Tabelle nicht als Optionsfeld darstellen - ebenfalls eine eigene Tabelle und den Zahlungsart_key dann in die tb_Mitglieder.

Dann gibt es in der tb_Mitglieder beim Feld 'Inventar_key' eine ganz interessante Feldbeschreibung:

Was hat das M wann wieviel gekauft? (Für Kassier wegen Rechnung....

Das solltest du auf jeden Fall in einer eigenen Tabelle festhalten - Verkäufe an Mitglieder lassen sich nur so auswerten.

Für die Speicherung von Daten rund um verliehene Orden an Mitglieder
erstellst du eine neue Tabelle ... z.B.  tb_MitgliederOrden
Felder:

Mitglieder_key ----  Zahl, Long
Orden_key   ------- Zahl, Long
OrdenVerliehen ------ Datum
OrdenUeberreicht --- Datum
VerleihBemerkung --- Text

Keine Leerzeichen/Sonderzeichen, keine Umlaute in Feldbezeichnungen, etc.

Benötigst du für die Bemerkungsfelder in den Tabellen wirklich mehr als 255 Zeichen (Memofeld)?

ich habe die idee, alles gleich in einer inventarliste zu speichern wieder verworfen....

Was meinst du damit?
Du musst sowieso deine tb_Inventar befüllen, ob dir das gefällt oder nicht 
Über ein geeignetes Formular geht das schon ...
Du brauchst natürlich nicht 100x Hemd eingeben, das wählst du AM FORMULAR aus einer Dropdownlisteaus, das seine Daten aus der tb_InventarTyp bezieht ... 

und sinn macht das ja auch nicht

... doch, doch, so schon! 

Na dann - an die Arbeit und die obigen Änderungen einmal einarbeiten

[bluewalk]

Hallo Peter,

danke für die Übersicht und Hilfe.
Ja, die von dir angesprochenen überflüssigen Felder in der tb_Mitglieder habe ich auch schon entdeckt und entfernt.

Bei der Inventarisierung habe ich mich nicht recht ausgedrückt und du hast nochmals das bestätigt, was ich meine. Mir ging's darum, daß ich nicht händisch die 100 verschiedenen, aber gleichnamigen Artikel eintragen wollte (die Tabelle hast du ja entdeckt). Meine Lösung gefällt dir ja.  Danke.

Benötigst du für die Bemerkungsfelder in den Tabellen wirklich mehr als 255 Zeichen (Memofeld)?

Hmmmm. War es nicht so, daß ein Memofeld nur dann Speicherplatz benutzt, wenn es befüllt wird? Und nur soviel, wie es wirklich benötigt? Irre ich mich? Was hast du "gegen" das Memofeld? (damit ich den Gedankengang verstehe) Wenn das mittlerweile nicht mehr zutrifft, kann ich as wieder ändern.

Jetzt zu dem, was ich nicht kapiere, ich evtl. nochmals Deine Idee bzw. Vorschlag zum Aufbau brauche:
Wenn ich den Werdegang in eine eigene Tabelle verlagere, welche Felder machen Sinn? Es soll da ja nicht nur die Beurlaubungszeit rein, der Aktivitätsstatus, oder wann das Mitglied welchen Posten (davon evtl auch mehrere) hat(te), sondern auch persönliche Dinge: Hilft gerne mit beim Standaufbau, muß vom Alkohol ferngehalten werden, kann gut trommeln, hat die Vereinskasse geleert und wird darum ausgeschlossen.... Und wie Verknüpfe ich am sinnvollsten?
Darum habe ich das wegen der vielen Möglichkeiten so lösen wollen. Wobei aber gerade der Zeitverlauf extrem viel Sinn macht, auf das du wohl anspielst....Grübel

Das solltest du auf jeden Fall in einer eigenen Tabelle festhalten - Verkäufe an Mitglieder lassen sich nur so auswerten.

kann ich das nicht über die schon erstellte tb_Ausgabe realisieren? Dafür war sie eigentlich gedacht. Oder macht es Sinn, wenn ich den Verkauf vom Verleih trenne?

Danke für die Hilfe und Geduld. Bin grad dran und versuche mich wieder einzulesen in die dicken Wälzer und im Forum, damit ich bald nicht mehr fragen muß. 

[database]

Hallo,

ich habe nix gegen ein Memofeld, nur als Datenspeicher für eine 'Bemerkung' scheint's mir einfach zu groß.

Bezüglich Werdegang - nun ja eine Werdegang_ID und ein Textfeld für die Aufnahme der Beschreibenden Texte sowie ein Datumsfeld um den Zeitpunkt der Dateneingabe zu speichern sollte eigentlich genügen. Da mehrere Einträge für ein bestimmtes Mitglied möglich sind/sein müssen, ist das ganze dann über eine Zwischentabelle mit der tb_Mitglieder in Beziehung zu setzen.
Anzeige in HaFo / UFo- Konstrukt ist danach realisierbar.

zu den Verkäufen:

kann ich das nicht über die schon erstellte tb_Ausgabe realisieren?

Nein, das ist nicht richtig - Verkäufe sind im eigentlichen Sinn zwar auch Materialausgeben, haben aber eine Besonderheit - sie kosten oder bringen was.
Die Datensätze der Verkäufe lassen sich per Abfrage auch mit den Ausleihen kombinieren, sodass ersichtlich wird was ein Mitglied geliehen UND gekauft hat.
Selbstverständlich kann auch dieses in HaFo / UFo Technik getrennt dargestellt werden (Ausleihen und Verkäufe in jeweils eigenen UFos am gleichen HaFo.

Warte aber noch mit der Formularsache - stell mal die Tabellen alle richtig und lade das fertige DB-Modell nochmal hoch