Re: [de-users] Re: Datenbank: Werk eines Komponisten
Hallo Ernst und alle anderen ... Ernst Hügli schrieb: ... Wenn er aber mal 09 oder gar nur 9, ein ander Mal aber 1992 eingibt, dann kommt die DB damit nicht klar. das kann man aber über constraints (Bedingungen) lösen, nicht unbedingt 4-stellig, bzw. integrierten Korrekturen (habe dazu gerade kein Beispiel, kann aber meist über die interne Programmiersprache der DB erledigt werden, Stichwort: stored procedures) CREATE TABLE Tabelle ( ... Beginn DATE; Ende DATE; CHECK (Ende Beginn) ); Wie in diesem Thread schon mehrfach betont: der Design - und da empfehle ich meinen Schülern auch: Bleistift und Papier, allenfalls die Textverarbeitung oder ein Zeichnungsprogramm à la Draw oder Visio - ist das Alpha und Omega einer guten Datenbank-Applikation. Dazu gehört auch eine sorgfältige Überlegung, welchen Datentyp ein Feld denn aufnehmen soll. es gibt aber auch grafische Tools hierfür, Stichworte UML, entity relationship (o.ä.) PS. Bezüglich der erbetenen Literaturangaben zum Thema DB werde ich mich später noch melden. Nun, mit Literatur ist das immer so eine Sache. Was dem einen zusagt, muss dem anderen überhaupt nicht zusagen. ... Zum Glück kann man heute oftmals im Internet Teile eines Buches Probe lesen, bevor man es kauft. auch eine gut sortierte Buchhandlung kann ich empfehlen. Sofern das betreffende Buch dort vorhanden ist, kannst Du es in Ruhe lesen ... Ich habe noch nie erlebt, daß ich bei Hugendubel, Lehmans, ... angesprochen wurde ... auch wenn ich ein Buch über eine Stunde gelesen habe! MfG Günter - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Datenbank: Werk eines Komponisten
Hallo Guenter Guenter Wallnig schrieb: Wie in diesem Thread schon mehrfach betont: der Design - und da empfehle ich meinen Schülern auch: Bleistift und Papier, allenfalls die Textverarbeitung oder ein Zeichnungsprogramm à la Draw oder Visio - ist das Alpha und Omega einer guten Datenbank-Applikation. Dazu gehört auch eine sorgfältige Überlegung, welchen Datentyp ein Feld denn aufnehmen soll. es gibt aber auch grafische Tools hierfür, Stichworte UML, entity relationship (o.ä.) Selbstverständlich gibt es diese Tools - die Frage ist bloss: soll ich - wenn ich nur gelegentlich mal eine DB selber entwerfen - mich dafür in ein weiteres Tool einarbeiten, das trotz GUI i.d.R. nicht trivial zu bedienen ist? Ich halte es da eher mit der altmodischen Variante: Einsteiger und Gelegenheits-Entwickler sollen zunächst einmal die Theorie verstehen lernen und ihre Entwürfe mit Papier (Flipchart-Bögen sind empfehlenswert) und Farbstift erarbeiten, dann können sie bei Bedarf immer noch weitere Tools anschaffen. Als Neuling im Bergsteigen wage ich mich wohl auch kaum als erstes an die Eigernordwand - u.a. auch darum, weil dafür der gleichzeitige Einsatz mehrerer Tools notwendig ist. Das ist erfahrenen Bergsteigern vorbehalten. Aber vielleicht ist das auch die spezifische Sicht eines Lehrers, der den Ehrgeiz hat, seinen Schülern beizubringen, dass sie wissen, was sie tun, und nicht wie hirnlose Roboter einfach ein paar Tasten drücken können O:-) . Denn eins bleibt gerade in diesem Zusammenhang der DB-Entwicklung immer wieder zu beachten: A fool with a tool is still a fool! :-X Freundlich grüsst Ernst - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Datenbank: Werk eines Komponisten
Hallo Andreas Andreas Borutta schrieb: ... Na, dann haben wir ja schon mal MySQL as Backend. da ebenfalls OpenSource und eine große aktive Community, ist das eine gute Wahl! Also bleibt mir als Tool zum Verwalten allein PHPmyAdmin? nein, wie Du ja auch dem vorherigen posting entnehmen kannst und hier ... Doch, es ist möglich, Felder einzufügen. Nur bietet Base das nicht in seiner GUI an. ... menu:ExtrasSQL... ist die Kommandozeile zum Datenbank-Backend. Über diese Kommandozeile klappts dann auch mit MySQL wie mit jeder anderen Kommandozeile auch. diese Kommandozeile ist nichts anderes als ein Fenster in die Edit-Ebene von beispielsweise /usr/bin/mysql (unter Linux) Das Kommando in einer Shell (auch mit Putty unter Windows zum Linux-Rechner mit der MySQL-DB) mysql -h $HOST -D $DATABASE -u $USER -p öffnet Dir einen prompt zur Bearbeitung der DB (natürlich mit den entsprechend eingerichteten Berechtigungen) mysql help For the complete MySQL Manual online visit: http://www.mysql.com/documentation For info on technical support from MySQL developers visit: http://www.mysql.com/support For info on MySQL books, utilities, consultants, etc. visit: http://www.mysql.com/portal List of all MySQL commands: (Commands must appear first on line and end with ';') ... OK. Mit der Sprache muss ich mich eh beschäftigen. ich wiederhole nochmal aus meinen früheren Beitrag: In der c't 09/2003, ab S. 234 steht ein guter Artikel über Datenbanken Datenschule. Mit SQL zur eigenen Datenbank von Hajo Schulz Da Du als Verfahren die Kommandozeile erwähnst, nehme ich an, dass der Quellcode eines Tabellenentwurfes nicht in Form einer Textdatei editierbar ist, oder? Weil die MySQL-DB ja eigenständig ist (Base ist ja nur die GUI), kannst Du *sehr viel* mit den Tools für MySQL machen ... So erstellst Du mit einem Dump der DB eine editierbare ASCII-Datei, die *alle* Befehle zum Erstellen der DB enthält ... auf Wunsch sogar mit Benutzern und Passwörtern. Außerdem wählbar: nur Struktur oder Struktur mit Daten ... Dieser Dump ist eine gute Backup-Möglichkeit. Er kann auch zum Erstellen der DB auf einem anderen Rechner dienen. MfG Günter - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Datenbank: Werk eines Komponisten
Hallo Andreas Andreas Borutta schrieb: Danke. Daraus folgt, dass eine Formatangabe , wie Robert sie zuerst in Base vorgenommen hatte, scheitern muss, weil es eben keinen Datentyp Jahreszahl gibt. Die aktuelle Feldeigenschaft Vierstellige Ganzzahl ist also genau richtig. Richtig. Wichtiger scheint mir aber - denn die Definition des Typs bleibt dem User in einer gut designten [! furchtbares Wort] DB verborgen - dass Du ihn zwingst, 4 Ziffern einzugeben. In Deiner Anwendung sind Jahrzahlen aus dem Mittelalter oder gar Altertum doch wohl unwahrscheinlich. Wenn er aber mal 09 oder gar nur 9, ein ander Mal aber 1992 eingibt, dann kommt die DB damit nicht klar. Das will heissen: sortieren, selektieren u.ä. wird mit solchen Daten extrem schwierig. Wie in diesem Thread schon mehrfach betont: der Design - und da empfehle ich meinen Schülern auch: Bleistift und Papier, allenfalls die Textverarbeitung oder ein Zeichnungsprogramm à la Draw oder Visio - ist das Alpha und Omega einer guten Datenbank-Applikation. Dazu gehört auch eine sorgfältige Überlegung, welchen Datentyp ein Feld denn aufnehmen soll. Und auch das kann ich nur betonen und wiederholen: sind in einer DB mal Daten drin, dann ist eine Änderung der *Struktur* oft - wenn überhaupt! - nur mit weitreichenden Konsequenzen machbar. Das Ganze wird schnell zu einem Murcks. Darum: Gehirn einschalten - denken - zeichnen - hin und her überlegen - korrigieren - realisieren - testen - Testdaten löschen - ggf. Struktur nochmals anpassen, und erst nach dieser langen Zeit produktive Daten eingeben. PS. Bezüglich der erbetenen Literaturangaben zum Thema DB werde ich mich später noch melden. Nun, mit Literatur ist das immer so eine Sache. Was dem einen zusagt, muss dem anderen überhaupt nicht zusagen. Was für den Einsatz im Klassenverband geeignet ist, taugt nicht für den Selbstunterricht, usw. usf. Nimm also diese Empfehlungen mit der nötigen Sorgfalt auf. Zum Glück kann man heute oftmals im Internet Teile eines Buches Probe lesen, bevor man es kauft. Suche also auch aktiv nach Literatur, die für Dich passt. Ich gebe Dir zwei Bücher an, die sich aus meiner Sicht [!] für Dein Anliegen - in DB im allgemeinen und in Base im besonderen einzusteigen - bewährt haben: Hölscher Lorenz; Richtig einsteigen: Datenbanken entwickeln mit Access 2007; Microsoft Press Deutschland; ISBN 978-3-86645-203-9; €24.90 Krumbein Thomas; Datenbanken mit OpenOffice.org 3; Galileo Computing Bonn; ISBN 978-3-8362-1301-1; €39.90 Zu den beiden Büchern: das erste Buch ist zwar von der Konkurrenz, was bedeutet, dass Du die Beispiele nicht immer 1:1 übertragen kannst. Doch bei aller Kritik an MS: die können auch gute Bücher schreiben. Da wir in der Schule mit den MS-Produkten arbeiten, gehe ich nach diesem Buch vor. Was mir besonders gut gefällt ist gerade der Teil, der hier im Thread so ausgiebig breitgewalzt wird: der Design, die zugrunde liegenden DB-Strukturen, die Normalisierung sind m.E. mit der nötigen Sorgfalt, aber nicht theoretisch, behandelt (und darum empfehle ich Dir dieses Buch). Nicht zu vergessen ein Punkt, der auch schon verschiedentlich angesprochen wurde: wie sollen Tabellen, Abfragen, Formulare und Berichte, aber auch DB-Felder, sinnvoll benannt werden? Der Autor hat hier m.E. einen sehr guten, stilsicheren Ansatz vorzuweisen. Das Buch von Thomas Krumbein hat Volker schon kurz erwähnt - m.E. unverzichtbar, wenn man seriös in Base einsteigen will. Also, wie gesagt: jeder hat seine Vorlieben. Ich halte es auch so, dass ich aus einem Buch das herauspicke, was mir zusagt - den Rest überlese ich geflissentlich. Ich empfehle Dir diese Bücher in diesem Sinne. Freundlich grüsst aus der regnerischen Schweiz Ernst - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Datenbank: Werk eines Komponisten
Hallo Andreas Andreas Borutta schrieb: Bitte gehe auf die von mir genannten Argumente ein, wo ich schreibe, dass ich keinen guten Grund sehe, bewußt eine für menschliche Verwalter (ich schrieb explizit nicht von Anwendern) schlechter lesbare (Benennungen, Reihenfolge) und somit schlechter wartbare Struktur anzulegen. Auf diese Deine Aussage bin ich bis jetzt noch nicht eingegangen und will das gerne nachholen: Es kann keine Rede davon sein, eine (...) schlechter wartbare Struktur anzulegen. Die Aussage lautete ganz anders: die Benennung von Feldern und ihre Reihenfolge in der Tabelle ist für das Funktionieren der DB absolut belanglos - das war sinngemäss der Inhalt der Aussage. Dazu folgende Bemerkungen: * Eine klar gegliederte Struktur kann nie schaden - doch darf diese Gliederung (im Sinne von: Reihenfolge der DB-Felder) nicht überbewertet werden. Aus zwei Gründen: erstens sieht der User nie die Tabellen, denn er wäre - wie ich schon verschiedentlich betont habe - bei einer gut gemachten DB-Applikation überfordert: da müsste er sich mit mehreren Tabellen herum schlagen, müsste Primärschlüsselwerte auslesen und sie als Sekundärschlüsselwerte in anderen Tabellen einfügen, und derlei Spässe mehr. Dafür bietet ein DB-System die Formulare (im wesentlichen für die Eingabe) und die Reports (im wesentlichen für die Ausgabe). In diesen Objekten zerschiesst man bewusst die schön aufgebaute Struktur, damit der User versteht, was er eingeben soll oder was bekommen kann. Die Gliederung der Felder kann völlig anders sein als in den Tabellen. Es liegt am Entwickler, das Ganze im Hintergrund wieder auseinander zu bröseln. Zweitens: was ist denn eine gut lesbare Struktur? Das ist kein objektives Kriterium. Nimm als ganz einfaches Beispiel einen Adressdatensatz: Amerikaner und Engländer setzen die PLZ (dort Zip genannt) ganz anders als wir in Zentraleuropa. Oder die Russen: ihre Adressstruktur ist völlig auf den Kopf gestellt und damit für uns sehr gewöhnungsbedürftig: zuoberst wird das Land angegeben, dann die PLZ und die Stadt, auf der nächsten Zeile die Adresse, und zuunterst der Name des Empfängers - auch eine Logik, aber aus unserer Sicht wie gesagt sehr gewöhnungsbedürftig. Das ergäbe in einer Adress-DB eine völlig andere Struktur als bei uns. Was ist nun eine gut lesbare und damit wartbare Struktur? Doch eine sehr subjektive Angelegenheit. Dazu ein Beispiel: nimm eine Adress-DB. Die Normalisierung verlangt mindestens zwei Tabellen: eine mit den personenbezogenen Angaben (Name, Vorname, Adresse, Telefonnummern, ..., sowie den Sekundärschlüssel auf die Ortstabelle) und eine für den Ort (PLZ, Ortsname, evtl. Stadtteil). Was ist jetzt die richtige Struktur? Hängt doch sehr vom Anwendungsfall ab: für Adressetiketten ist eine andere Reihenfolge sinnvoll als für ein Mitgliederverzeichnis. Trotz dieses Einwandes spricht nichts dagegen, sich auch die Reihenfolge gut zu überlegen und für eine logisch erscheinende (das ist subjektiv, nicht objektiv) Reihenfolge zu entscheiden. Gerade weil ein nachträgliches Einschieben nicht ohne weiteres möglich ist, muss ich aber im Sinne der Aufwandminimierung auch akzeptieren, dass in der Testphase noch Änderungen auftreten, die diese Struktur zerschiessen. Beispiel: ich habe mich ursprünglich dafür entschieden, PLZ und Ort im gleichen Feld zu erfassen (warum auch immer - es geht ums Prinzip). Nun zeigt aber die Testphase, dass ich sie doch auseinander nehmen muss. Dann habe ich in der Tabelle nicht die übliche Struktur PLZ - Ort(sname). Für die Leistungsfähigkeit der DB-Applikation ist das belanglos. Wichtiger scheint mir da, in der Entwurfsansicht nicht nur die Spalten Feldname und Feldtyp zu beachten, sondern ganz speziell die dritte Spalte Beschreibung: hier soll man Hinweise auf Bedeutung und Zusammenhänge der Felder notieren. * Was sind gut lesbare Feldnamen? Der Entwickler wird darunter etwas Anderes verstehen als der User. Name ist Schall und Rauch ist man mit Johnny Goethe versucht zu sagen - solange der Entwickler mit seiner eigenen Namensgebung klar kommt. Dem Entwickler ist es i.a. wichtiger, über die Namen einen Hinweis auf die Struktur zu erhalten: zu welcher Tabelle gehört ein Feld? Hat es eine spezielle Aufgabe (z.B. Sekundärschlüssel), und auf welche Tabelle referenziert es in diesem Fall? Das von mir empfohlene Buch von Hölscher schlägt diesbezüglich eine aus User-Sicht ungewohnte, aus Entwicklersicht aber sehr sinnvolle Konvention vor. In den User-Interfaces - sprich Formularen und Berichten - sollte das Ganze aber im Klartext, möglichst in epischer Breite, daher kommen, damit der User klar weiss, worum es geht. Fazit: ich bin der letzte, der der Schludrigkeit das Wort redet - aber die Ansicht, was eine gut lesbare und wartbare Struktur sei,
Re: [de-users] Re: Datenbank: Werk eines Komponisten
Hallo Am Sonntag, 14. Juni 2009 schrieb Andreas Borutta: snip Darauf möchte ich mich im Moment auch konzentrieren. Formulare kommen dann in der zweiten Phase. Der Datenbankentwurf ist das A und O des ganzen. Wenn das nicht stimmt, kannst du mit Formularen nichts mehr retten. Erstmal muss mir klar werden, mit welcher Struktur das Werk eines Komponisten am besten abgebildet wird. Mir geht es dabei um Langlebigkeit, um Nachhaltigkeit. Auch hier wieder: Datenbankentwurf. Wenn das Ganze gut wird, möchte ich die Datenbank auch anderen Komponisten zur freien Nutzung bereitstellen. Die in der Rohdatentabelle aufgeführten Merkmale gelten für beliebige Kompositionen von Komponisten für neue Musik, sagte mir mein Freund. Da musst du dir aber absolut sicher sein, dass das so ist. Das ganze lieber dreimal hinterfragen. snip Dennoch finde ich, dass es der Nachhaltigkeit dient, wenn die Datenfelder der Tabelle in einer sinnvollen Reihenfolge stehen und sprechende Namen tragen. Das kann, muss aber nicht so sein. Jede zusätzlich Schicht erhöht die Komplexität und erschwert die Wartung. Ohne Not, denke ich, sollte man eine solche Schicht hinzufügen. Spätestens hier wird es notwendig auf ein paar Konzept hin zu weisen: ACID, Trennung der Daten von den Sichten, Normalformen, Transaktion usw. Ich denke du kommst um ein bischen Theorie zu Datenbanken nicht herum. Aber offenbar kann man in Base Datenfelder nachträglich nicht in der Reihenfolge ändern oder mittendrin ein neues Datenfeld einfügen. Das sollte in allen Datenbanken tunlichst unterbleiben. Ich bin kein Datenbankentwerfer, arbeite aber täglich in der Programmierung von und mit Datenbanken in der Verwaltung von Technischen Dokumenten. Das ganze ist nicht trivial. -- Mit freundlichen Grüßen Matthias Müller (Benutzer #439779 im Linux-Counter http://counter.li.org) PS: Bitte senden Sie als Antwort auf meine E-Mails reine Text-Nachrichten! signature.asc Description: This is a digitally signed message part.
Re: [de-users] Re: Datenbank: Werk eines Komponisten
* Andreas Borutta [14-06-2009 19:08]: Welche didaktisch exzellente (deutschsprachige) Literatur zur Struktur (relationaler) DB kannst Du mir empfehlen? Hallo Andreas, einen direkten Literaturtipp habe ich nicht für dich, aber 2 Seiten für einen groben Überblick: http://de.wikipedia.org/wiki/Relationale_Datenbank http://de.wikipedia.org/wiki/Entity-Relationship-Modell Wenn du das ERM verstanden hast, bist du ein großes Stück weiter. Gruß Uwe - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Datenbank: Werk eines Komponisten
Hallo Andreas, 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 Die Daten sind drin, aber noch nicht verknüpft. Ein Formular zur Eingabe fehlt natürlich auch noch. Gruß Robert - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Datenbank: Werk eines Komponisten
Hallo Andreas, 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 Habe mich gerade noch einmal für 45 Minuten dran gesetzt. Irgendwie hat die Formatierung des Datums als nicht richtig funktioniert. Habe das jetzt als 4-stellige Zahl realisiert. 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. Ein Formular zur Eingabe fehlt natürlich auch noch. Steht jetzt. Die Instrumentation scheint mir aber noch nicht ideal gelöst zu sein. Zu Deinen Anmerkungen: Mit Base kannst Du keine Webformulare erstellen. Allerdings kannst Du mit Base sehr wohl auf eine Webdatenbank zugreifen. Dafür ist dann aber die eingebaute HSQLDB nicht geeignet. Umfassende Makroprogrammierung ist nur dann notwendig, wennn das Handling von Datenbanken mit dem Base-Frontend verbessert werden soll. Bevor ich die Medien-Datenbank erstellt habe hatte ich noch kein einiges Makro erstellt. Nur gab es da einige Ansprüche, die ich so nicht lösen konnte. Ähnliches könnte z.B. auch bei der Intrumentation in Deiner Datenbank der Fall sein. 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. Für meine Web-Datenbanken entnehme ich die Werte für Listfelder grundsätzlich solchen kleinen Tabellen - es sei denn, die Menge der Bezeichnungen ist klar begrenzt, wird nicht erweitert und außerdem direkt in einer weiteren Tabelle abgelegt (m für männlich, w für weiblich). Bei den Maßeinheiten für das Inventur-Beispiel war das eigentlich erst einmal unklar. Das Beispiel ist auch nur entstanden, weil in dieser Liste jemand Probleme beim Datenbankerstellen hatte und sich unsicher war, wie denn eventuell Berechnungen in Base gingen. Gruß Robert - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
