Frage zu MICROSOFT ACCESS Datenbank

Hallo ich habe folgendes Problem:

Ich bin Mitglied einer Musikkapelle (habe ich in einem früheren Threat schon geschrieben). Wir möchten jetzt unser gesamtes Notensortiment neu archivieren.

Ich habe jetzt schon nach Programmen gesucht, in die man die Musikstücke eingeben kann, habe aber nichts gefunden.

Daher möchte ich mir eine Datenbank mit Microsoft Access 2003 erstellen. Ich bin aber Anfänger mit diesem Programm und brauche daher ein paar Tipps, wie man so was angeht.

Die Datenbankstruktur sollte etwa so aussehen:

___________________________________________________________
Hauptformular:
IdNr.: (fortlaufende Nr.)
Titel:
Komponist:
Arrangeur:
Musikart: (Walzer, Marsch, Polka,…)
____________________________________________________________
Unterformular (Ablageort):
Raum: (Wo ist das Stück abgelegt)
Schrank:
Fach:
archiviert am: (Wann wurde das Stück abgelegt)
____________________________________________________________
Unterformular (Stimmen):
1. Klarinette (Stimme vorhanden Ja/Nein)
2. Klarinette (Stimme vorhanden Ja/Nein)
3. Klarinette (Stimme vorhanden Ja/Nein)
1. Trompete (Stimme vorhanden Ja/Nein)
2. Trompete (Stimme vorhanden Ja/Nein)
usw…
____________________________________________________________

Diese Struktur ist nur mal so ungefähr wie es mal aussehen soll.
Man kann dann nach einem Titel suchen, wenn man wissen will wo es abgelegt ist, oder welche Stimmen vorhanden sind, öffnet man das Unterformular.

Meine Frage ist jetzt, wie man das grundsätzlich mit Access angeht.

Ich habe mal angefangen (siehe den Screenshot), dass ich die drei Tabellen (Hauptdaten, Ablageort, Stimmen) erzeugt habe. Außerdem habe ich die Beziehungen zwischen den Tabellen erstellt.
Ist das bis jetzt brauchbar? Wie gehe ich weiter vor.

Ich bin für jeden Tipp dankbar.

mfg

Sieht gut aus, mach doch einfach mal weiter mit den Formularen.

Ohne selbst der große Experte zu sein sieht deine Struktur auf den ersten Blick merkwürdig aus. Prinzipiell gilt, nicht vom Formular her zu denken, sondern von der Art der Daten, die angelegt werden sollen: Kommen sie mehrfach vor? Lassen sie sich weiter aufgliedern? etc. pp. - Passende Formulare zu stricken ist einfach, wenn die Struktur stimmt.
Aber lass mich wegen des Verständnisses nochmal nachfragen:
Du willst Musikstücke archivieren, die folgende Eigenschaften haben: Titel, Komponist, Arrangeur, Musikart, Stimmen, Ablageort. Stimmen und Ablageort haben dabei in jedem Fall mehrere Untereigenschaften. Diese müssen also auf jeden Fall in extra Tabellen ausgelagert werden. Es wäre zu überlegen, ob man das nicht auch für Musikart, Arrangeur und Komponist macht - erstens erspart man sich Redundanz, man hat also in der Haupttabelle nicht mehr zwanzig mal den gleichen Komponisten stehen sondern nur noch den Verweis auf den einen Komponisteneintrag in der Untertabelle und zweitens kann man dann diese auch durch zusätzliche Angaben weiter anreichern (Lebendaten des Komponisten, Stimmung der Musikrichtung, was auch immer). Ich jedenfalls würde es empfehlen.
Jede deiner Untertabellen bekommt einen Autoschlüssel, das hast du schon richtig gemacht. Allerdings stimmen die Beziehungen imho nicht. Das ist zu sehr vom Prozess der Dateneingabe her gedacht: Du gibst erst das Musikstück ein und das verweist dann auf Ort und Stimmen. Ist aber so nicht richtig, denn gegenwärtig sagst du deiner Datenbank, dass ein Musikstück an unendlich vielen Orten liegen kann und unendlich viele Stimmenkombinationen haben kann.
Andersrum gedacht wirds richtig:
Deine Haupttabelle bekommt auch einen Autoschlüssel und dann weitere Schlüsselfelder z.b. id_ablageort und id_stimmen. Wenn du nun ein neues Musikstück anlegst, trägst du den Titel in die Haupttabelle ein und dann in die Felder id_Ablageort und id_Stimmen die Schlüssel jener Datensätze, die in den Untertabellen die passenden Eigenschaften für Ablageort und Stimmen enthalten. (Die hast du natürlich schon vorher angelegt, denn du weisst ja bereits, wo deine Noten alle rumliegen und welche Stimmen drin vorkommen können.) Ich hoffe, du konntest mir bis hierhin hinterher trotten, ansonsten muss ich auch mal nen Screenie einer DB von mir posten. Die Beziehung ist immer: 1 Datensatz in der Untertabelle kann auf unendlich viele Fälle in der Haupttabelle zutreffen.

Bei längerem Nachdenken finde ich auch deine "Stimmen" Tabelle merkwürdig. Wenn ich dich richtig verstehe, dann dort eine nahezu unendliche Kombination von Stimmen auftreten - will meinen, in der Tabelle taucht eine riesige Zahl von Datensätzen auf. Man kann das so lösen, wie du das machst, ich bin mir aber noch nicht sicher, ob es nicht bessere Lösungen gibt. Wie gesagt, so großartig bin ich auch nicht der Accessheld.

Gebe Strudelbrain hier völlig Recht.
Die Datenbank kann zunächst garnicht funktionieren, da die Beziehugen garnicht stimmen.
- Ein Musikstück sollte nur einen Ablageort haben und ein Ablageort kann mehrere Stücke beinhalten; nicht umegekehrt
- Ein Musikstück kann nur eine Anzahl von Stimmen haben, die Anzahl der Stimmen aber mit mehreren Stücken übereinstimmen; nicht umgekehrt

Zudem fehlt jeder Normalisierungsprozeß zur Vermeidung von Redundanzen und Erhaltung der Integrität.
Weitere Tupel:
- Interpret (I_Nr, Name, Vorname, ..., ID-Nr)
- Arrangeur (A_Nr, Name, Vorname, ..., ID-Nr)
- Genre (G_Nr, Text,..., ID-Nr)
- Archivierungszeitpunkt (Arch_Nr, Datum, Uhrzeit, ..., Nr (Ablageort))

Für die Stimmen würde ich den Attributtyp ändern.
- Anzahl Klarinetten - Wert von 1 bis 5 - usw.
Das schränkt die Anzahl der möglichen Eingaben ein ohne die Anzahl der logischen Möglichkeiten zu beschränken.
Bei weiterer Stimmen wird das aber dennoch irgendwann halsbrecherisch.

edit* Vllt. sollte man auch für jedes Instrument weitere Tabellen zur Hilfe nehmen. Kommt besser, sieht besser aus.

Zudem fehlt jeder Normalisierungsprozeß zur Vermeidung von Redundanzen und Erhaltung der Integrität.
Weitere Tupel:
- Interpret (I_Nr, Name, Vorname, ..., ID-Nr)
- Arrangeur (A_Nr, Name, Vorname, ..., ID-Nr)
- Genre (G_Nr, Text,..., ID-Nr)
- Archivierungszeitpunkt (Arch_Nr, Datum, Uhrzeit, ..., Nr (Ablageort))

Zum Vergrößern anklicken....

Ich hab mich etwas bemüht, um Normalisierung, Redundanz und Tupel drumrum zu reden, weils fürs erste Access Projekt manchmal doch etwas schwierig zu verstehen ist. Ich nehme an, ID-Nr ist bei dir der Autokey für die jeweilige Tabelle?

edit* Vllt. sollte man auch für jedes Instrument weitere Tabellen zur Hilfe nehmen. Kommt besser, sieht besser aus.

Zum Vergrößern anklicken....

Sowas in der Art geistert mir auch im Kopf rum. Es wird nicht einfacher dadurch, dass im Prinzip jedes Instrument mit jedem kombiniert werden kann.

strudelbrain schrieb:

Ich hab mich etwas bemüht, um Normalisierung, Redundanz und Tupel drumrum zu reden, weils fürs erste Access Projekt manchmal doch etwas schwierig zu verstehen ist. Ich nehme an, ID-Nr ist bei dir der Autokey für die jeweilige Tabelle?

Zum Vergrößern anklicken....

Ist sein Primärschlüssel für das "Hauptformular".
Und Du hast Recht:
Tupel = Tabelle
Attribute = Inhalte einer Tabelle
Primärschlüssel = Attribut mit welchem eine Entität eindeutig identifiziert wird
Entität = Tabellenname

Naja, so in etwa zumindest, glaube ich.
Dein Beitrag war etwas unübersichtlich, deshalb habe ich nochmal nachgelegt. Nix für Ungut.

greedx schrieb:

Ist sein Primärschlüssel für das "Hauptformular".

Zum Vergrößern anklicken....

Das meinte ich... Ich sollte mich mal an die sprachlichen Konventionen gewöhnen.

Dein Beitrag war etwas unübersichtlich, deshalb habe ich nochmal nachgelegt. Nix für Ungut.

Zum Vergrößern anklicken....

Wie so Beiträge nun mal sind zwischen Morgenkaffee und Brötchen...