Robert Großkopf schrieb: Guten Morgen zusammen,
>> das Mittagessen wartet. Ich habe gerade einen Entwurf der Datenbanktabellen >> nach Deiner Tabelle gemacht. Er steht unter >> http://www.scoolonline.de/download/Musik_Klassik.odb echt nett von Dir, Robert! :) Ganz herzlichen Dank! Wenn Du mal Interesse an Noten zu neuer Musik bekommst, melde Dich bitte. Der Komponist revanchiert sich gerne. Zur Struktur, die vermutlich das Wichtigste beim Erstellen einer DB ist, habe ich noch Fragen. 1 Rechtfertigung für weitere Tabellen Du verwendest in Tabelle Work für $Year ein Datenfeld, speist jedoch die Gattung (Form) via ID ein. Auch gleiche Werte für Jahr kommen vor. Handelt es sich dabei um eine Frage des Geschmacks oder gibt es objektive Kriterien für eine Entscheidung. Dito für Instrumentation. 2 WorkLengthTruth und WorkPartLengthTruth Hier gibt es eine Abhängigkeit. Zur Zeit wird diese noch nicht durch die Struktur abgebildet. Beispiel: Work.LengthTruth kann den Wert WAHR enthalten, während gleichzeitig WorkPart.LengthTruth, bei einem Werksteil des gleichen Werkes, den Wert FALSCH einnehmen kann. Logisch ist das verboten. Wenn ich Andreas Saeger richtig verstanden habe, kann man allein durch eine richtige Struktur sowas vermeiden, ohne Makros. Aber wie gesagt: ich bin nicht sicher, ob es so gemeint war. Kleinigkeit am Rande: Wie schreibt man eigentlich in der richtigen Syntax über "Datenfeld 'LenghtTruth' der Tabelle 'WorkPart' der Datenbank 'SimonBarberWork', damit man sich eindeutig verständigen kann? Irgendwas in der Form "SimonBarberWork.WorkPart.LengthTruth"? Also [Datenbankdatei].[Tabellenname].[Datenfeldname]? 3 Nummerierung der Werksteile/ Primärschlüssel Du hattest ja schon geschrieben, dass von Primärschlüsseln abzuraten ist, die aus einem Datentyp als INTEGER bestehen. In den Rohdaten tragen Werksteile IDs, die sehr klar und gut lesbar sind: 7a, 7b, etc. In Deiner Datenbank tragen die Werksteile IDs, die keine Schluss auf die Zugehörigkeit zu einem Werk erlauben. Ist es in einem solchen Fall empfehlenswert die sprechende ID manuell als zusätzliches Datenfeld einzuführen. Sozusagen IDs für Maschinen, $WorkNumber und $WorkPartNumber für Menschen? Das berührt auch die Frage, ob man beim Löschen eines Datensatzes die IDs der anderen Datensätze anpassen sollte oder nicht. Ist es bewährte Praxis die Maschinen-IDs niemals nach dem ersten Erstellen zu ändern? > Habe mich gerade noch einmal für 45 Minuten dran gesetzt. Irgendwie hat die > Formatierung des Datums als JJJJ nicht richtig funktioniert. Habe das jetzt > als 4-stellige Zahl realisiert. OK. Vermutest Du da einen Bug in Base? >> Die Daten sind drin, aber noch nicht verknüpft. > > Jetzt sind sie verknüpft, soweit es Titel und Untertitel angeht. Für di > ersten > Titel sind auch die anderen Verknüpfungen über das Formular erstellt. Das ist sehr hilfreich für den Einstieg. Danke nochmal. Das Thema Datenbank, besonders deren Strukturen, beginnt mich mehr und mehr zu interessieren. > Zur Datenbank "Inventur": Ich lege am liebsten alle Daten, die ich in der > Datenbank brauche, auch dort ab. Maßeinheiten sind beispielsweise nicht > Bestandteil der darunterliegenden Datenbank, sondern auch in Base nur durch > die Benutzeroberfläche zusätzlich einstellbar. Verstehe ich Dich richtig, dass Du hier Formatierungen meinst? Und Formatierungsinformationen (Formatcode wie "0,00' EUR'") werden beim Import der Datenbank in eine andere Anwendung nicht, oder nicht zuverlässsig übertragen? > Für meine Web-Datenbanken > entnehme ich die Werte für Listfelder grundsätzlich solchen kleinen > Tabellen Was spricht denn gegen eine Aufnahme der Einheit in einem Datenfeld derselben Tabelle? Also in Inventur.Name: $ID | $Name | $Preis | $PreisEinheit Für $Einheit könnte als Defaultwert "EUR" eingestellt werden. Oder muss man "EUR" als Konstante auffassen und es ist dann bewährte Praxis Konstanten so in die Datenbankstruktur einzubinden, wie Du es tust? Andreas -- OOo 3.1 http://borumat.de/openoffice-writer-tipps --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org