Robert Großkopf schrieb: >>> http://www.scoolonline.de/download/Musik_Klassik.odb >> >> Zu Primärschlüsseln: >> >> Du verwendest auch in Tabellen mit nur einem Datenfeld (Beispiel >> Tabelle Form) zusätzlich einen Primärschlüssel. >> Jeder Datensatz enthält dort jedoch einen anderen Wert. >> Dubletten kommen nicht vor. >> >> http://borumat.de/+screenshots/sc-052.png >> >> Kann daher das Datenfeld Form nicht selbst als Primärschlüssel dienen? > > Dann wäre eigentlich die ganze Tabelle überflüssig. Denn wenn Du nur die Form > wie "Gesang" oder "Orchester" in der Tabelle führst ergibt sich bei der > Haupttabelle zwangsläufig, dass genau dieser Begriff dort eingetragen werden > muss
Eben. > - und eben nicht eine (speicherplatzschonende) Ziffer. Dies ist ein Argument aus Sicht der Maschine. Das stelle ich nur fest, und kritisiere es selbstverständlich nicht. Wie ich schon in einem anderen Thread erwähnte, kann ich nicht beurteilen, ob sich sowas per Caching oder anderen technischen Verfahren, die sich mit Redundanz und Komprimierung beschäftigen, lösen liesse (ganz abgesehen davon, ob das jemand will). > Sobald Du dann > die Begriffe aus irgendeinem Grund ändern würdest, Das überzeugt mich. Denn hier meinst Du ja "ändern" im Sinne von "Änderung unter Wahrung der Konsistenz des gesamten Datenbestandes". Es soll also nicht das eine Stück mit "Kammermusik", ein anderes der gleichen Form jedoch mit "chamber music" bezeichnet werden dürfen. Und eine andere Integrität müsste auch sichergestellt werden: gleiche Sprache in einem Feld. Dieses Änderungspotential existiert beim Feld Jahr nicht. Es ist fix. > würde Dir die Datenbank in > etwa mitteilen, dass die Änderung aufgrund von Beziehungen zu anderen > Tabellen (hier: "Work") nicht möglich ist - es sei denn, Du lässt automatisch > alle Begriffe in "Work" auch ersetzen. So arbeitet man eben in einer Tabellenkalkulation. In der Datenbank soll es eleganter und robuster gelöst werden. Danke für Deine Argumentation. Nochmal zu der bisher ungelösten Aufgabe der besten Abbildung der Abhängigkeit der Felder "LengthIndetermination" und "ComponentLengthIndetermination" (ich habe die Bezeichner präzisiert): http://borumat.de/+temp/openoffice/rohdaten-simon-barber-work.ods Könnte ein zusätzliches Feld "HasComponents" die Sache lösen? Die zweiten Normalform spricht ja nur von Daten innerhalb /einer/ Tabelle: "Daten, die in der gleichen Tabelle stehen, dürfen nicht voneinander abhängig sein." Allerdings hängt der Wahrheitswert von "Work"."HasComponents" von der Existenz eines Inhaltes in "WorkComponent"."Name" ab. In der "abzubildenden Wirklichkeit" ist das Aufteilen von Super-Objekte und Sub-Objekte nichts Besonderes. Daher vermute ich, dass es für diese Standard-Aufgabe auch eine etablierte Standard-Lösung gibt. Mir ist bisher noch nicht klar, ob man solche Zusammenhänge allein via Constraints abbildet oder besser allein mit entsprechenden Relationen. Andreas -- OOo 3.1 http://borumat.de/openoffice-writer-tipps --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
