SQL-Abfragen grafisch darstellen?

[TheFinn]

Guten Abend allerseits!

Gibt es eigentlich einen "Königsweg" zur grafischen Darstellung von SQL-Abfragen?

(Ich meine hier nicht die verschiedenen Varianten der ER-Notation zur Darstellung der DB-Struktur)

Aktuell möchte ich z.B. einen View dokumentieren, der (stark vereinfacht und "anonymisiert") etwa so aussieht:

SELECT

	TAB_1.ATTR1, 

	TAB_1.ATTR2, 

	DATEPART(YEAR, TAB_1.DATUM) AS JAHR, 

	DATEPART(MONTH, TAB_1.DATUM) AS MONAT, 

	SUM((CASE WHEN TAB_2.GEWICHTUNG IS NULL THEN 1 ELSE TAB_2.GEWICHTUNG END) 

	* (CASE WHEN TAB_1.ATTR3 IS NULL THEN 0 ELSE TAB_1.ATTR3 END)) AS ATTR3 

FROM

	TAB_1 WITH (NOLOCK) LEFT OUTER JOIN

	TAB_2 WITH (NOLOCK) ON TAB_1.FK2 = TAB_2.PK

GROUP BY

	TAB_1.ATTR1, 

	TAB_1.ATTR2, 

	DATEPART(YEAR, TAB_1.DATUM), 

	DATEPART(MONTH, TAB_1.DATUM)

Nun könnte ich im Prinzip ein Flussdiagramm zeichnen, in dem die Elemente der SELECT-Liste sowie TAB_2.GEWICHTUNG und TAB_2.PK Daten-Elemente sind, die über Entscheidungen ("CASE WHEN..." und "TAB_1.FK2 = TAB_2.PK") in einen Prozess ("GROUP BY") einfließen, der mir das Abfrageergebnis liefert. Was in den Flussdiagrammelementen passiert, stünde dann halt in den jeweiligen Beschriftungen.

Intuitiver als eine textuelle Beschreibung ist das aber nun nicht gerade. Auch das, was mir der MSSQL in der Entwurfsansicht zeigt, ist nicht wirklich der wahre Jakob, finde ich (kann man diese Ansicht übrigens irgendwie in eine Grafik exportieren?).

Gibt es Eurer Meinung nach eine geeignetere Notation für so etwas (Aggregation, (bedingte) Filterung), die man mit einem Tool wie z.B. Visio (das ich bislang nur rudimentär kenne) umsetzen kann? Wenn ich bei Google frage, lande ich immer wieder bei ER-Diagrammen, fürchte ich...

Danke im Voraus

(und ein Frohes Neues...)

[flashpixx]

Man kann ER Diagramme auch als UML auffassen und auch so modellieren.

Wenn man Techniken wie Hibernate oder Corba verwendet, dann lässt sich das auch wirklich relativ leicht umsetzen.

Ein Flussdiagramm passt hier nicht, denn Du hast ja keine Datenflüssen, sondern nur Beziehungen zwischen den Daten. Ein SQL Select ist ja nichts anderes als eine aktuelle Sicht auf Deine Daten (Snapshot).

Die Frage wäre, was möchtest Du mit einer graphischen Repräsentation erreichen, also welche Information möchtest Du haben?

[Grinse-Hinze]

Servus,

ich finde solche "Designer" ja eigentlich immer komplizierter als SQL selber, aber du kannst dir in MS Access ja mal eine kleine Idee holen.

Einfach eine neue Abfrage erstellen und dir die Entwurfsansicht anschauen.

Grüßle,

Grinse

P.S.: Falls du Probleme mit der Bedienung von Access hast, frag bitte jemand anderen... ;-) Ich hab das Ding noch nie verstanden... :-P

[TheFinn]

Moin, moin!

Danke für Eure Beiträge.

@flashpixx:

Wie gesagt, ich war ja selber mit der Option Flussdiagramm nicht wirklich zufrieden... Andererseits denke ich schon, daß man eine Abfrage auch als einen Prozess ansehen kann, an dessen Ende ein Ergebnis steht, insbesondere, wenn z.B. solche Gewichtungen im Spiel sind (Veränderung von Wert A in Abhängigkeit von Wert , wie ich es im Beispiel angedeutet hatte. Auch die Auswahl von Datensätzen nach bestimmten Kriterien ist ja eine aktive Handlung, die nicht nur die Beziehung zwischen Daten beschreibt, sondern basierend auf diesen Beziehungen eine "Entscheidung" trifft. Ist aber vielleicht auch ein wenig "Ansichtssache"...

Aber zur Frage, was ich damit transportieren will: ich möchte (bzw. frage mich, ob es möglich ist), daß ein "technikferner" Mensch beim Blick auf eine Grafik den Auswahl- und Verarbeitungsprozess verstehen kann, also versteht, welche Randbedingungen erfüllt sein müssen, damit ein Datensatz für die Abfrage berücksichtigt wird oder eben nicht, nach welchen Kriterien einzelne Attribute gewichtet oder ungewichtet in eine Summe eingehen etc.

@Grinse-Hinze:

Ja, auch ich finde das SQL für eine Abfrage, ggfs begleitet von einer textuellen Beschreibung i.A. ausreichend. Was Access angeht, so wird die grafische Darstellung dort vermutlich eine ähnliche sein wie auch im Entwurfsmodus des MSSQL. Die Frage ist eben (s.o.), ob es Möglichkeiten gibt, für die Dokumentation sozusagen weitere Zielgruppen zu erschließen...

Für den aktuellen Fall habe ich mich jetzt auch eher auf die Kombination SQL + Beschreibung zurückgezogen, bleibe aber grundsätzlich interessiert...

[flashpixx]

Aber zur Frage, was ich damit transportieren will: ich möchte (bzw. frage mich, ob es möglich ist), daß ein "technikferner" Mensch beim Blick auf eine Grafik den Auswahl- und Verarbeitungsprozess verstehen kann, also versteht, welche Randbedingungen erfüllt sein müssen, damit ein Datensatz für die Abfrage berücksichtigt wird oder eben nicht, nach welchen Kriterien einzelne Attribute gewichtet oder ungewichtet in eine Summe eingehen etc.

Datenbanken lassen generell als Venn-Diagramme darstellen ( Mengendiagramm ? Wikipedia ), weil es letztendlich endliche Mengensysteme sind. Natürlich und ich denke, dass Du darauf hinaus möchtest, wäre wie sich die Mengen über die Zeit verändern.

Wenn Du also auf eine Tabelle eine Where Bedingung setzt, dann erzeugst Du eine Partition (Mengenlehre) ? Wikipedia der Menge