TurboCalc WorkShop Nr. 3.01 © 1997 by Günther Klug Frh. v. Biedermann, München DATENBANK-PRAXIS Das ist ein weites Gebiet und kann nicht in nur EINEM Work-Shop - so im Vorbeigehen - behandelt werden; deshalb die Nummerierung 3.01 bis 3.xx? Eine der meistgebrauchten Anwendungen im PROFESSIONELLEN Einsatz von Spreadsheets sind Datenbanken. DATENBANK (database) ist bei TurboCalc (wie bei allen gleichartigen Programmen) ein rechteckiger (zwar nicht zwingend, aber tunlichst mit einem Namen versehener) Bereich, der bestimmten Formen entspricht. Eine Datenbank besteht aus MINDESTENS einem Feld-Namen und einem Datensatz - also zumindestens 2 Zeilen. Ob man dieses Zwergerl aber als "Datenbank" bezeichnen kann, bleibt dahingestellt. Feldname (fieldname): Der Feldname ist sozusagen die Überschrift über eine Spalte von Feldern und beschreibt (üblicherweise) den Inhalt der darunter befindlichen Felder. Tatsächlich können Sie natürlich dort reinschreiben, was Sie lustig sind - aber wenn Sie sich was Gutes tun wollen, dann sorgen Sie dafür, daß die Feldnamen (innerhalb dieser Datenbank) UNIKATE, also alle unterschiedlich sind! Feld (field): ist der (Teil-)Inhalt eines Datensatzes Datensatz (record): ist der Inhalt aller Felder in derselben Zeile mit dem horizontalen Ausmaß der Datenbank. Beispiel: Vorname Name Straße Ort&PLZ <-- 4 Feldnamen Heinz Braun Babelstr. 4 81673 München <-- 1 Datensatz Obige Datenbank besteht aus 4 Feld-Namen und 1 Datensatz. Ein Datensatz muß NICHT in allen Feldern einen Inhalt haben; aber wenn Sie einen Datensatz "suchen", sollte als Kriterium (siehe weiter unten) derjenige Feld-Name gewählt werden, dessen Felder in ALLEN Datensätzen besetzt ist - andernfalls finden Sie eventuell nix! Datenbanken einen Namen geben. Definition von "Namen": Hier ist zunächst zu empfehlen, daß die Konventionen für Namen tunlichst eingehalten werden sollten. Zwar wird im Manual empfohlen, Namen mit Leerzeichen oder Sonderzeichen (da es ein DEUTSCHES Programm ist, gelten Umlaute und "ß" NICHT als Sonderzeichen) zu vermeiden, aber von Zahlen ist nicht die Rede! Nun, Zahlen werden bei der Namengebung zwar zunächst akzeptiert und ein so definierter Name (beispielsweise "123") erscheint auch brav in der Liste der Namen, aber wenn Sie die Formel =2*123 in eine Zelle reinschreiben, wird das Ergebnis 246 sein - egal was Sie in der mit 123 benamsten Zelle drin haben (ist auch irgendwie logisch, oder!). Warum das Ergebnis "falsch" ist, können Sie feststellen, wenn Sie im Menu "Gehe zu..." anwählen und in der Liste "123" anklicken: Der Cursor wird den Teufel tun und "gehen", sondern er bleibt, wo er vorher war - weil dieser Typ Name schlicht ignoriert wird! In gleicher oder ähnlicher Weise werden Punkt (".") oder "$" vor einem Namen behandelt, nur daß dann gleich eine Fehler-Meldung in der Zelle erscheint. Ich habe nicht ALLE Sonderzeichen auf Akzeptanz und Verträglichkeit geprüft, aber wenn Sie glauben, ohne solche "Exoten" nicht auskommen zu können, empfehle ich obigen Test mit "Gehe zu". Dagegen würde ein Name wie "Hans Dampf" (obwohl lt. Manual Leerzeichen eigentlich verpönt sind) voll akzeptiert. Auch ein Unterstrich "_" vor/innerhalb von Name (z.B. "_heini") wird keine Probleme bereiten. Auch Namen, die einer Zell-Adresse gleichen, werden (erstaunlicherweise) nicht verworfen. Ein Name "A17" wird akzeptiert! Somit tritt der (kuriose) Fall ein, daß eine Formel "=3*A17" den Wert der Zelle mit dem NAMEN "A17" (verdreifacht) annehmen wird, anstatt den dreifachen Wert der ZELL-ADRESSE "A17" !! Natürlich würde Niemand (außer mir) auf so eine blöde Idee kommen und... wenn M. Friedrich das liest, wird er sich was überlegen und bereits im Update 4.06 (oder schon TC5.0?) was ändern, wetten! Jedenfalls sind Sie jetzt gewarnt! Bei der Namengebung werden KEINE Unterschiede in der Schreibweise GROSS oder klein gemacht. Somit können Sie nicht "heini" und "HEINI" als zwei verschiedene Namen verwenden! Warum überhaupt Namen für eine Datenbank verwenden? Klare Antwort: Weil es (besonders in Makros) die Handhabung vereinfacht - was zu beweisen ist: Vielleicht haben Sie in Mathe (wie meine Kinder) "Mengenlehre" lernen müssen!? Das können Sie jetzt (endlich einmal) anwenden: Der kompletten Kunden-Datenbank (Gesamtmenge) geben Sie beispielsweise den Namen "DatenbankKd". ANMERKUNG: Wenn Sie mehrere Datenbanken in der Applikation haben, ist diese Schreibweise vorzuziehen, weil sie dann in der alphabetisch geordneten Namen-Liste alle Datenbanken beieinander stehen haben; (würden Sie sie z.B. Kunden_DBK nennen dann wäre eine mögliche Waren_DBK weit hinten in der Liste). Eine in der Breite große Datenbank wird (außer bei der Modifikation) nur selten in vollem Umfang gebraucht - z. B. wenn Sie nur den Namen suchen. Da liegt es nahe, eine "Untermenge" mit einem ANDEREN Namen zu versehen und dann nur auf diese zuzugreifen. Beispiel: Geben Sie (aus obiger kleiner Datenbank) der Untermenge Name <-- Feldname Braun Heini ... den Namen "Liste_Kunden" dann könnten Sie mit dem Befehl LISTENAUSWAHL (LISTREQUEST) in einem Makro folgendermaßen... =LISTENAUSWAHL("Bitte den Kunden-Namen auswählen";Liste_Kunden) ...dem Anwender eine Liste der vorhandenen Kunden-Namen zur Auswahl vorlegen. (Die Folge-Makros sollten daraus natürlich irgendwelche Konsequenzen ermöglichen, welche vermutlich aus einem Zugriff auf die GANZE Datenbank oder eine weitere "Untermenge" bestehen !). Ist doch praktisch, oder!? Damit sind wir mit der Mengenlehre aber schon wieder am Ende, denn eine beispielsweise "Schnittmenge" (obwohl das durchaus reiz- und sinnvoll wäre) gibt es - zumindest bisher - für Datenbank NICHT. Makros schreibt man zwar nicht für die Ewigkeit, aber wenn mal alles funktioniert, gibt es keinen Grund mehr, sie groß zu verändern. Greifen Makros auf modifizierbare Bereiche (also z.B. Datenbanken) zu, dann wäre die Verwendbarkeit dramatisch eingeschränkt, gäbe es nicht die Möglichkeit, sowohl bei der Modifikation als auch bei der Auswertung auf "Namen" abzustellen. Wenn Sie natürlich nur EINE mickrige Datenbank in der Applikation haben, und die sich NIE ändert, kommen Sie mit Startzelle:Endzelle (also etwa B30:D60) auch zum Ziel (sogar dann, wenn sie auf eine Untermenge - wie oben beschrieben - zugreifen wollen). Richtig in Schwierigkeiten kommen Sie aber, wenn diese EINE Datenbank gelegentlich modifiziert wird! Woher soll Ihr mühsam aufgebautes Makro wissen, wo die Datenbank nach einer Veränderung nun endet? Man kann sich natürlich auch mit dem linken Daumen im rechten Ohr kratzen; will heißen, den neuen Datenbank Bereich nach Modifikationen im Makro verändern! Warum also swohl im Modifikations- als auch im Zugriffs-Makro auf die Datenbank nicht mit einem "Namen" zugreifen und die "Verantwortung" für die richtige Wahl TurboCalc überlassen? Haben Sie mehrere Datenbanken in Gebrauch, dann sollten Sie diese unter verschiedenen Namen (als Typ Datenbank-Bereich) in die Namenliste aufnehmen und vor der Verwendung die benötigte Datenbank als AKTUELLE Datenbank anmelden (siehe "Sub-Makro1" beginnend in N2). Starten Sie in der beiliegenden Applikation "WS_Datenbank01.TCD" einfach das Objekt "Zeige Bereiche" (keine Angst, es wird nichts Wesentliches verändert). Interessant ist für Sie natürlich die Makro-Sequenz (in Spalte L), welche diverse Folge Aktionen bewirkt. Diese beinhaltet zwar einige Befehle, welche (jetzt noch nicht) nötig wären, aber für die Weiterführung dieses Work-Shop Bedeutung haben. Beachten Sie (in L53) den Befehl "CALL(N2)", welcher die Anmeldung der gerade benötigten Datenbank und der zugehörigen Kriterien übernimmt). Diese Sequenz wurde in ein Sub-Makro ausgelagert, weil auch andere Makro-Sequenzen (hier vorläufig nur "Modify_Waren" in J1) diese Sequenz verwenden müssen - und warum soll man die dann ZWEI Mal schreiben? Da eine Datenbank natürlich zu etwas gut sein soll, muß man darauf in irgendeiner Weise zugreifen können. Bei TurboCalc sind die Möglichkeiten vielfältig. Für die Manipulation in Datenbanken gibt es eine Reihe eigener Makros und -Funktionen. MAKROS: Name-deutsch (english) Parameter/argument * DBEXTRAHIEREN (DBEXTRACT) Zelle/cell DBLÖSCHEN (DBDELETE) * DBSORTIEREN (DBSORT) DBSUCHEN (DBFIND) DBVORHERIGER (DBPREV) * DBMASKE (DBMASK) Routine/routine Dazu kommen noch * DATENBANKBEREICH (DATABASE) Bereich/range * KRITERIENBEREICH (CRITERIA) womit die Bereiche für Datenbank und Kriterien definiert werden können. FUNKTIONEN: Name-deutsch (english) Parameter/argument DBANZAHL (DCOUNT) Datenbank;Spalte;Kriterien/ DBANZAHL2 (DCOUNT2) database;column;criteria DBERSTER (DFIRST) DBLETZTER (DLAST) DBMAX (DMAX) DBMIN (DMIN) DBMITTELWERT (DAVERAGE) DBPRODUKT (DPRODUCT) DBSTABW (DSTDEV) DBSUMME (DSUM) DBVARIANZ (DVAR) DBWÄHLEN (DPICK) Makros und Funktionen aus obiger Liste, denen ein * voransteht, sind in diesem Work-Shop bereits in Gebrauch. KRITERIEN: sind die einfachste Art, einen Datensatz zu finden. Kriterien besteht aus einem oder mehreren Labels, welche GENAU einem/mehreren Feldnamen der zugehörigen Datenbank entsprechen muß/müssen... TIP: Kopieren Sie aus der entsprechenden Datenbank das Label und setzen Sie es ins Kriterium, um sicher zu sein, daß dieses GENAU dem Label in der Datenbank entspricht - ich hab früher schon mal stundenlang gesucht, weil das shit-Ding nix fand; und dann fehlte im Label ein "i"! ...und mindestens einem Suchbegriff oder Pattern; also aus mindestens 2 Zeilen. In der Beispiel-Applikation sind 2 Kriterien enthalten (Bereich B3:C4) Wenn Sie NUR diese beiden Kriterien in Gebrauch haben, genügt es, sie einmalig als "SUCHKRITERIEN" anzumelden; TurboCalc definiert ihn dann automatisch als Typ "Kriterien-Bereich". Haben Sie aber mehrere Kriterien in Gebrauch, dann sollten Sie diese unter verschiedenen Namen (ebenfalls als Typ Kriterien-Bereich) in die Namenliste aufnehmen und vor der Verwendung die benötigten Kriterien als AKTUELLES Kriterium anmelden (siehe Beispiel-Applikation "Sub-Makro1" beginnend in N2). Als Suchbergriff gibt es eine Vielzahl möglicher Varianten, die in einem späteren Work-Shop innerhalb dieser Reihe behandelt werden sollen. DATENBANK MODIFIZIEREN: Sowas können Sie a) manuell machen (wenn Sie es sich zutrauen) b) oder sich ein spezielles Makro schreiben - das sollte dann aber schon sehr ausgeklügelt sein, um auf alle Eventualitäten reagieren zu können! c) oder ein Makro schreiben, das die Funktion MASKE aufruft und dann am Ergebnis einige Korrekturen selbstständig vornimmt. d) oder durch Aufruf von "Maske" im Menu. Zu a): Das ist in einfachen Datenbanken ein probates Mittel: Einfach einen Datensatz unten anhängen, die Datenbank mit dem neuen Ausmaß anmelden und sortieren - basta! Zu b): Das kann ganz schön nervig werden (die Erstellung des Makros) und ich hab jetzt nicht den Nerv, darauf einzugehen ;-)) Zu c): Dafür ist in der mitgelieferten Applikation ein Beispiel, das einige (in Version 4.05 noch vorhandenen) Unzulänglichkeiten der Funktion MASKE ausbügelt. MASKE hat nämlich noch eine ganz grobe Macke, die aber mit dem nächsten Update (oder der Version 5.0?) bereinigt sein wird. Momentan vernichtet MASKE nämlich alle Formeln (innerhalb der Datenbank), wenn auch nur EIN Datensatz geändert wird - und zwar die dieses und oberhalb dieses Record! Zu d): Probieren Sie es aus! Je nach Art der Datenbank haben Sie dann ein Erfolgserlebnis - oder nicht :-(( Vergessen Sie aber nicht, VORHER die zu bearbeitende Datenbank als DATENBANK zu definieren! Versuchen Sie nun (mit Klick auf das Objekt "Modify Waren") diese Datenbank zu erweitern/verringern/modifizieren. In anderen Datenbanken müssen diese oder ähnliche Sequenzen natürlich entsprechend erweitert werden! Wenn Sie Mist gebaut haben... ...die Speicherfunktion in Zelle J49 ist (im Original) nicht aktiv... und ich jetzt auch nicht mehr! Beim nächsten Work-Shop geht's weiter. Viel Spaß!