Ausgangslage
Gerade bei Beispielen zu Queries ist es oft schwierig Tabellenverknüpfungen darzustellen. Meistens habe ich diese durch Text versucht darzustellen.
Die einzelnen Tabellen werden zumeist mit Zeichen über ihre Felder in Verbindung gesetzt.
Beispiel: Hierbei steht <--> für einen normalen Join und >LO< für einen left outer join. Die left outer joins sind erforderlich um auch Datensätze auszugeben, die nicht in allen Tabellen vorhanden sind.
Eine elegantere Methode wäre hier ein Screenshot der bestehenden Tabellenverknüofungen. Dieses ist jedoch problematisch, da zu verknüpfende Tabellen meist mehrere Felder haben und so ein Screenshot schnell unübersichtlich wirken kann.

Lösung:
Auch hier kann Dia weiter helfen. Neben UML und Flussdiagrammen können hier auch Datenbanken dargestellt werden. Als Elemente stehen hierbei Tabelle, Referenz und Attribut-Komposition zur Verfügung.

Im Beispiel sieht dieses dann wie folgt aus:


Hierbei können beim Objekt Datenbank verschiedene Attribute hinzugefügt werden.

Auf der Registerkarte Tabelle ist es dabei sinnvoll den Hacken beim Punkt "Kommentare sichtbar" zu setzen, so dass bei den einzelnen Attributen aber auch der Tabelle zusätzlich zum Namen auch ein Kommentar eingetragen werden kann.

Dieser Kommentar wird dann unterhalb des Namens ausgegeben, so dass neben den technischen Namen auch die Beschreibung der Tabelle bzw. des Feldes mit ausgegeben werden kann.

Danach können die einzelnen Tabellenattribute über eine Referenz (das zweite Symbol im Objektsatz Datenbank) miteinander in Verbindung gesetzt werden. Innerhalb der Referenz kann nun Beginn und Ende der Beschreibung formuliert werden. Dieses ermöglciht bspw. eine Darstellung einer 1:n Beziehung oder auch einer Beschreibung ala inner join oder outer join.

Vorteile

Im Gegensatz zu einer Datenbankanwendung kann in DIA ein Attribut auch mehrfach eingetragen werden, so dass gerade bei komplexeren Tabellenverknüpfungen auch mehrere Beziehungen zu Tabellen gezogen werden können ohne dass die Verknüpfungslinien sich überschneiden.

Neben der Darstellung von vorhandenen Datenbanken bietet DIA aber auch die Möglichkeit der Zeichung eines Entity-Relationship-Modell wodurch ein semantisches Datenbankmodell entworfen werden kann und später in eine Datenbank umgesetzt wird. Dieses kann bspw. bei der Konzeption einer Raumdatenbank sehr hilfreich sein.

Ausgangslage
Im Rahmene eines Projektes ist oftmals nicht nur eine gute Projektplanung (hier kann gerade für die einzelnen Zeitabläufe die Software openworkbench) sondern auch die Darstellung von verschiedenen Abläufen (Prozessen) sehr hilfreich. Neben den Programmen MS Project oder MS Visio gibt es auch OpenSource-Anwendungen, die eine vergleichbare Möglichkeit anbieten.

Lösung
Hierzu nutze ich sehr gerne die Software DIA, welche auch unter Softwareempfehlungen auf dieser Seite beschrieben ist. Ein enormer Vorteil dieser Software ist, dass sie auch als portable Version ohne Installation am Rechner bspw. von einen USB Stick lauffähig ist.

Nach der Installation der Software kann sieht die Oberfläche wie folgt aus:



In der DropDown-Liste können neben Flussdiagramm weitere Diagrammbögen (UML, ER, Karten, Leuchten und diverse andere) gewählt werden. Zur Darstellung von Prozessabläufen ist allerdings eine Kombination aus Flussdiagramm & UML hilfreich.

Die einzelnen Objekte können mit Verbindungen (Linien, Pfeile, etc.) miteinander in Verbindung gesetzt werden.

Ein Beispiel kann dabei wie folgt aussehen:



Hierbei stammen die mit roter Schrift beschriebenen Objekte aus der Kategorie Flussdiagramm. Die Anmerkung sowie Akteur stammen dabei aus den Objektbogen UML.

Die einzelnen Objekte können per Doppelklick abgeändert werden. So können einzelne Objekte eingefärbt werden und damit dann auch Akteuren (die ebenfalls einfärbbar sind) zugeordnet werden. Ferner ist es auch Möglich die Verbindungslinien im Linienstil (durchgezogene Linie, gestrichelte Linie) oder auch von der ARt des Startpfeils und Endpfeil auf unterschiedliche Weise dargestellt werden.

Unter Datei->Seite einrichten kann das Diagramm auch auf eine bestimmte Papierformatgröße angepasst werden. Über Datei-Exportieren kann das Diagramm dann auch als PDF oder in andere Dateiformate exportiert werden.


Zusammenfassung
Insgesamt ist ein solches Tool sehr gut geeignet bestimmte Zusammenhänge einfach darzustellen, so dass auf einen Blick entsprechende Prozesse ohne viele Worte gut ersichtlich sind. Darüberhinaus hilft eine solche Darstellungsform auch viele mögliche Anwendungsfälle zu bedenken und entsprechend darzustellen.

Als Anwendungsgebiete möchte ich beispielhaft folgende Artikel nennen:

• "Graphische Darstellung von Tabellenverknüpfungen bspw. bei Query"
• "Ereignisgesteuerte Prozesskette in DIA darstellen (weitere Objekte einfügen)"

Weitere Artikel zur Anwendung DIA sind hier zu finden.

Ausgangslage
Ein häufiges Problem beim Versenden von Emails ist oft dass hier verschiedene Mailserver nur eine bestimmte Größe an Dateianhängen akkzeptieren. Thunderbird hat hierbei die Möglichkeit solche Dateianhänge bei "Online-Speicherdiensten" zu hinterlegen.

Standardmäßig werden hierbei BOX, Ubuntu One oder yousendit eingebunden. Über ein Thunderbird Addon ist es aber auch möglich Dropbox als Dienst einzubinden.

Der Dienst Dropbox (Partnerlink für 250 MB Zusatzspeicher) bietet hierbei die Möglichkeit kostenfrei mindestens 2 GB zu nutzen.

Das Addon "Dropbox for Filelink" ermöglicht es nun dieThunderbird den Speicherdienst einzubinden, so dass Anhänge direkt in den Dropbox Ordner landen, und in der Mail dann ein Dropbox Link statt der tatsächlichen Datei an den Mailempfänger gesandt wird.

Die Einstellungen hierzu finden sich unter

Extras->
Einstellungen->
Anhänge->
Versand

Hier kann nun über Hinzufügen auch Dropbox als Speicherdienst eingebunden werden.

Ferner wird hier die Dateigröße angegeben aber der eine Datei per Dropbox versandt werden soll.

Bei der Einrichtung von FileLink wird auf die Seite von Dropbox verwiesen und die Anwendung für den Zugriff auf Dropbox freigeschaltet.

Die Dateien liegen dann unter:

Apps\Mozilla Thunderbird

im Dropboxverzeichnis.

Positiv zu erwähnen ist, dass Mozilla in der Rechteverwaltung auch ausschliesslich auf dieses Verzeichnis Zugriff erhält. Die einzelnen Berechtigungen für Apps sind auf dieser Seite aufgeführt.

Auf der Supportsite von Mozilla weden die Einrichtung beschrieben und auch weitere Addons für andere Speicherdienste angeboten.

Vorteile & Nachteile
Ein Vorteil ist sicherlich, dass die Mail wesentlich schneller versandt wird und auch Änderungen an der Datei zügig erfolgen können. Schliesslich liegt diese ja im eigenen Dropboxverzeichnis. Ein Nachteil für den Empfänger ist ggf., dass diese Dokumente auch schnell wieder gelöscht werden können und um eine "Archivierung" der Mailanhänge sich der Empfänger selbst kümmern muss. Auch das Thema Datenschutz sollte hier, ebenso wie generell beim Thema Mailkommunikation, nicht ausser Acht gelassen werden.

Ausgangslage
Innerhalb des Template monobook (aber auch in andere Templates) besteht die Möglichkeit eine Navigationsleiste im Wiki auf der linken Seite einzubauen. Hier bietet es sich an, bspw. über das Plugin indexmenue ein entsprechendes Indexmenü auf Basis der Berechtigungen der User auszugeben. Auf diese Weise werden nur die Seiten oder Namensräume ausgegeben, für die auch tatsächlich eine Leseberechtigung vorhanden ist.

Dieses hat sicherlich Vorteile verwandelt allerdings das Wiki eher in eine Form einer Internetseite, da alle Unterseiten und Ordner (Namensräume) mit ausgegeben werden.

Problem
Das Wiki soll innerhalb der einzelnen Namensräume die Vorzüge einer Internetseite (freier Zugang, leichte Bedienung und Bearbeitung) mit den Vorteilen eines Wiki zum freien Informationsaustausch vereinen. Die Namensräume sind hierbei als Themenfelder gedacht innerhalb deren sich die Teilnehmenden dann frei austauschen können und auch entsprechende Unterseiten innerhalb des Namensraumes anlegen können.

Auf diese Weise sollte bspw. im Bereich des Finanzwesen auch Begriffe wie Budget oder vergleichbares eingehend erläutert werden, ohne dass hierbei in der Navigation direkt diese einzelnen Unterseiten mit ausgegeben werden.

Lösungsansatz
Eine mögliche (ideale) Lösung wäre es nun, wenn in der Navigation nur die Namensräume als Navigationspunkte angezeigt werden und nur auf einer spezielen Seite das vollständige Inhaltsverzeichnis ausgegeben wird.

Lösung
Diese Lösung kann in drei Schritten erfolgen:

1.) Festlegung der Indexseite (Gesamtindex)
Innerhalb der "Indexmenu Plugin-Konfiguration" kann über die Funktion "plugin»indexmenu»page_index" festgelegt werden, welche Seite im Wiki den eigentlichen Dokuwiki Index ersetzen soll. Diese Seite bspw. wiki:inhaltsverzeichnis wird zukünftig das komplette Inhaltsverzeichnis des Wiki enthalten.

2.) Festlegung der Navigationsleiste im Template
Innerhalb der Templatekonfiguration von monobokk können zwei Punkte eingestellt werden:
a) tpl»monobook»monobook_navigation
Hierdurch wird im Template die Navigationsleiste aktiviert.
b) tpl»monobook»monobook_navigation_location
Hierdurch kann eine Wiki-Seite als Navigationsleiste definiert werden. Diese Seite kann bspw. wiki:navigation lauten.

3.) Inhalt der beiden Seiten festlegen

Als Inhalt kann folgender Wikicode auf die einzelnen Seiten zur Einbindung des Indexmenü eingetragen werden.
a) Die Navigationsleiste
{{indexmenu> ..|js navbar nocookie id#random nopg}}
Durch die Option nopg wird hier durch indexmenu nur die Namensräume als Navigation angezeigt. So kann durch einen Klick auf einen Ordner die Startseite des Namensraums aufgerufen werden und von dort aus innerhalb des Wiki und des Themengebietes durch die Seiten geklickt werden, oder auch bestimmte Begriffe durch Anlage eines Links (bspw. über [[Budget]] erläutert werden, ohne dass die Seite Budget nun ebenfalls in der Navigationsleiste erscheint.
Ergebnis:


b) das Inhaltsverzeichnis
In der Seite wiki:inhaltsverzeichns (oder wiki:index) kann nun durch folgenden Code das komplette Inhaltsverzeichnis ausgegeben werden.
{{indexmenu> ..|js navbar nocookie id#random }}
Hier wird nun das gesamte Inhaltverzeichnis inklusive aller Unterseiten aufgerufen werden.
Diese Seite kann innerhalb des Wiki über
doku.php?id=start&do=index aufgerufen werden. Dieser Link ist auch in der entsprechenden Werkzeugleiste verfügbar.
Ergebnis:



Weitere Erfahrungen
Weitere Erfahrungen im Umgang mit Dokuwiki sind unter den Tag dokuwiki zu finden.

Grundüberlegung eines Wiki sind sicherlich mehrere Punkte. Persönlich bin ich hier selbst noch ein wenig in der Testphase habe aber folgende Grundüberlegungen für mich als sinnvoll erachtet.

1.) Warum ein Wiki?
Ausgangslage ist für mich eine Sammlung von Informationen die über ein Sammlung von unterschiedlichen Dokumenten hinaus geht. Im Laufe der Zeit haben sich eine Unzahl von Dokumenten angelgt die vielleicht auch in ein DMS gut aufgehoben sein könnten aber doch so umfangreich sind, dass sie nur schwer durchsuchbar geschweige denn geordnet sind.
Daher hatte ich mir vor einiger Zeit Scribble Papers im Einsatz (siehe Blogbeiträge oder die Beschreibung unter Tools).
Hier können einige Texte in Ordnern festgehalten werden und es ist eine relativ einfache Struktur möglich. Der Nachteil einer solchen Software ist jedoch, dass diese a) nur von einer Person genutzt werden kann (alternativ wäre eine Speicherung auf ein Netzlaufwerk) und b) eine Extrasoftware benötigt. Ein Wikisystem hat hierbei den Vorteil, dass es zum einen von mehreren Personen genutzt werden kann und zum anderen direkt im Netz lauffähig ist.

2.) Grundüberlegungen zur Struktur
Gerade bei geschlossenen Wikis sollte sich besonders Gedanken um die Struktur gemacht werden. Hier sind zum einen die Frage der Berechtigung auf einzelne Namensräume notwendig als auch (gerade bei mehreren Schreibenden) eine grundsätzliche Überlegung zum darzustellenden Inhalt.

Für mich hat sich folgende Struktur von Namensräumen als hilfreich ergeben:

• About(Allgemeine Infos zum Wiki)
• Handbuch (Wie funktioniert das Wiki)
• FachlichesHier sollen alle inhaltliche Fragen zum Thema des Wiki besprochen und beschrieben werden. Diese sind in zwei Bereiche aufgeteilt:
  • Individueller Bereich (Hier können Informationen zu verschiedenen Bereichen hinterlegt werden, diese sind dann auch identisch zu den Benutzergruppen)
  • Verbindender Bereich (Ein Bereich der für alle Gruppen von Interesse ist, sei es durch rechtliche Vorgaben oder gemeinsam bearbeiteten Themen).
• Technischik / Anwendung (Ein Bereich in der bestimmte Software dokumentiert wird, welche zwar von allen genutzt wird, jedoch mit den Schwerpunkt auf Technik und Anwendung. Hier können z.B. Berichtstool vorgestellt werden oder gemeinsam an einer technischen Dokumentation gerabeitet werden).

3. Erste Schritte
Gerade das unter 2. erwähnte Handbuch hat für mich den Vorteil, dass hier sicher selbst mit der Technik eines Wiki vertraut gemacht werden kann und durch eine Dokumentation der Struktur des Wiki aber auch Erläuterung, wei Artikel erfast werden, zeigen sich oftmals schon im Vorfeld Verbesserungspotentiale und Ideen, wie sich das Wiki fortentwickeln kann. Danach kann es hilfreich sein schon einmal die ersten Seiten zu verschiedene Themen anzufangen, so dass diese dann erweitert werden können. Hier ist sicherlich am Anfang auch die größte Gefahr, dass am Ende nur eine Person Artikel schreibt oder das die Richtung des Wiki sehr stark von einer Person geprägt wird.
Ideal ist es, wenn anhand eines Thema schon Seiten aufgebaut werden können die später ohnehin in eine gemeinsame Dokumenntation oder Schulungsunterlagen münden werden.

4. Motivation & Fortbestand
Als besondere Gefahr ist sicherlich, dass bei aller Technikverliebtheit irgendwann der Inhalt liegen bleibt. Daher sollte sich schon vorab darum Gedanken gemacht werden, welchen Vorteil andere von diesen Wiki haben und warum diese ggf. ihre Zeit dafür gebrauchen sollten an bestehenden Texten mit zu schreiben. Hilfreich kann hier ein gemeinsames Thema sein, welches alle Beteiligten beschäftigt und fasziniert. :-)

5. Abgrenzung Wiki & Blog
Auch innerhalb eines Blogsystems kann von mehreren Personen an Artikel gearbeitet werden. Diese haben jedoch den Nachteil, dass sie nur schwer unterinander verknüpft sind und Teilaspekte nicht, so erforderlich, näher ausgeschmückt werden können.

Theoretisch ist ein Wiki (in meinen Verständnis) eine aktiveres Instrument als ein Blog, welches zu einen besseren Austausch und tiefere Bearbeitung eines Thema führen kann.

Weitere Erfahrungen
Weitere Erfahrungen im Umgang mit Dokuwiki sind unter den Tag Dokuwiki zu finden. Wobei ich künftig dieses Thema eher in der Kategorie "Internet" einsortieren werde.