Robert Großkopf schrieb: Geklärtes gesnipt.
>> 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. > > Ist wohl wirklich eine Frage des Geschmacks. Ich habe in dieser Liste auch > schon Meinungen gehört, z.B. für Adressdaten einfach alles in eine Tabelle zu > packen. Grundlage einer Datenbank mit Beziehungsstrukturen ist aber > eigentlich, Doubletten vor allem längerer Feldinhalte zu vermeiden. Danke. Das lasse ich mal sacken. Man kann ahnen, dass hinter den Entscheidungstyp "Neue Tabelle" einige Erfahrung steckt und keine objektive allgemeingültige Antwort möglich ist. >> 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. > > Einfachste Möglichkeit wäre wohl, die LengthTruth-Eigenschaft aus WorkPart > auszulesen und dann über eine Abfrage im Hauptformular anzuzeigen Dabei ist das Problem, dass Werke, die keine Werksteile enthalten, demnach auch keinen Wert in WorkPartLengthTruth. WorkLengthTruth könnte also nicht ermittelt werden. In anderen Worten: Auf das Datenfeld WorkLengthTruth kann beim aktuellen Stand nicht verzichtet werden. Aber vielleicht gibt es ja noch eine elegante Lösung rund um den "Genaue Angabe, ungefähre Angabe". > (ähnlich > der momentanen Anzeige der fehlenden/überschüssigen Sekunden) Die Ursache der überschüssigen Sekunden haben sich aufgeklärt. Der Komponist hatte Längenangaben inkonsistent gerundet. Werksteile hat er nicht gerundet. Werke schon. Die Rohdaten sind entsprechend überarbeitet. http://borumat.de/+temp/openoffice/rohdaten-simon-barber-work.ods >> 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]? > > Sieh Dir dazu die Abfrage "LegthDiff" an: > "Length_Work"."ID" OK. Die Anführungszeichen dürfen also trotz Abwesenheit von Leerzeichen in den Namen nicht weggelassen werden? >> 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. > > Die Verbindung erfolgt doch sichtbar im Formular. Wenn Du die > Untergliederungen der Tabelle der Unterformulars mit a,b,c usw. sortieren > willst, so muss natürlich diese Sortierung noch zusätzlich in die Tabelle > WorkPart eingegeben werden. Wir haben uns aufgrund der Sortierproblematik entschieden, auf die alphabetischen Werkstteil"nummern" zu verzichten. Sie werden jetzt nummeriert. Die Werksnummer entspricht schon jetzt der ID. Fast. Die ID muss nur noch statt bei 0, bei 1 beginnen. Das kann offenbar für den Autozähler nicht per GUI in Base eingestellt werden. Man muss wohl einfach die erste ID manuell setzen, oder? Bei Werksteilen sieht es anders aus. Hier käme als ID ein zusammgesetzter Wert in Frage: 40.3 Spricht etwas dagegen? Den Bogen nochmal zur grundlegenden Struktur: Denkbar wäre eine Tabelle, die keine statische Zahl von Datenfeldern enthält, sondern wo die Anzahl dynamisch ist. Dann könnte auf die Tabelle workpart verzichtet werden. Nein, ich behaupte natürlich nicht, dass das besser ist. Ich überlege nur laut. Tabelle work: ID Name Length PartName_1 PartName_2 ... PartName_n PartLength Form >>> 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? > > Das scheint mir ein Bug zu sein. Ich habe mich nur gewundert, dass alle > Felder > auf 1904 standen und eine Angabe von 1998 nicht angenommen wurde. Dann habe > ich das ganze Datum sichtbar gemacht. Dort standen dann irgendwelche > Komplettdaten, die anscheinend aus der Jahreszahl konstruiert wurden. Hier > ließ sich dann auch die Jahreszahl ändern und anschließend wieder anzeigen. > > Vielleicht ist das aber auch ein Übertragungsproblem von Calc nach Base. Hier > wird wohl nicht die Formatierung des Base-Feldes berücksichtigt, sondern > aus "1998" ein komplettes Datum gebildet. Ob die Neueingabe mit > dentsprechender Jahresformatierung funktioniert habe ich nicht mehr > überprüft. Die Ursache könnte tatsächlich in Calc liegen. Die Jahreszahlen habe ich in unformatierte Zellen eingegeben. Calc konnte sie also nur als vier Ziffern werten und nicht als Datumsangabe. Aber auch wenn man in Calc eine Zelle zuerst als Datum "JJJJ" formatiert und danach einen Wert wie "1905" eingibt, interpretiert Calc das als "1905". In Jörg Schmidts Buch habe ich zu Typ auf Seite 315 nur 6 Typen gefunden: Zahl, Text, Wahrheitswert, Formel, Fehlerwert, Matrix Datum oder Zeit scheint es als Typ nicht zu geben. Calc bildet sie offenbar als Zahl ab. 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
