Baumansicht

[frankg]

Hallo TheOmega!

Zitat von theomega:

Hallo Leute
jetzt wirds ein bischen komplex, gesucht wird ein SQL-Statement oder ein Code.

Naja, so komplex wirds auch wieder nicht

Zitat von theomega:

Ich habe 4 Tabellen:

1. sachbuch:
- sbid (PRIMARY_KEY)
- sbnr (VAR_CHAR)

2. gliederung:
- glid (PRIMARY_KEY)
- glnr (VAR_CHAR)
- sbnr (VAR_CHAR)

3. funktion:
- fnid (PRIMARY_KEY)
- fnnr (VAR_CHAR)
- glnr (VAR_CHAR)

4. konto
- knid (PRIMARY_KEY)
- knnr (VAR_CHAR)
- fnnr (VAR_CHAR)

Ich hab das hier mal aufgezeichnet...



Was mir an Deinem Datenbankdesign aufgefallen ist, ist dass Du zwar Primärschlüssel verwendest (z.B. sbid), dann aber von der anderen Tabelle aus einen Fremdschlüssel auf das Feld sbnr verwendest. Das hat zwei grosse Nachteile:

• 1. Das Datenbanksystem kann nicht überprüfen, ob der in sbnr eingefügte Wert eindeutig ist (naja, kannst Du schon über UNIQUE machen, ist aber meiner Meinung nach hier unnötig). Sobald Du z.B. zwei Sachbücher mit derselben Information im Feld sbnr hast, hat Dein Datenbankmodell verloren.
  
  2. Wenn Du dafür sorgst, dass der Wert im Feld sbnr UNIQUE ist, dann hast Du redundante Informationen, weil Du in einem Datensatz ja zwei mal einen eindeutige Wert stehen hast.

Fremdschlüssel sollten in einem stimmigen, robuten Datenbank-Design immer auf Primärschlüssel einer Tabelle bezogen sein.

Ich würde das Problem folgendermassen lösen:



Nun sind alle Fremdschlüssel mit Primärschlüsseln verknüpft. Wenn Du nun noch mit Foreign Key Constraints arbeitest (ein Foreign Key Constraint definiert die Beziehung zwischen den Tabellen als Regel in der Datenbank, d.h. Du kannst in ein Foreign Key Feld keinen Wert mehr eintragen, der nicht bereits als Primary Key in der anderen Tabelle verwendet wird), dann hast Du ein absolut bombensicheres Datenbankmodell, weil es dann nicht mehr möglich ist Datensätze anzugeben, die nicht richtig verknüpft sind.

Zitat von theomega:

So:
Immer gleichnamige Felder sind verknüpft. Es ist aber nicht eine 1:1 verknüpfung sondern 1:n es können also in einem Sachbuch mehrere Gliederungen vorhanden sein und auch in den anderen Tabellen.

Bis jetzt habe ich das extrem umständlich gelößt, und habe für einen kleinen Baum knapp 160 Query gebraucht. Das ist viel zu viel, das sollte doch auch mit einem und einem INNER oder OUTER Join funktionieren. Nur irgendwie steig ich nicht so komplett durch.

160 Querys sind wirklich ein bisschen viel. Ich würde es mit der folgenden Query versuchen (Inner Join).

SQL-Code:

SELECT
  *
FROM
  SACHBUCH SB,
  GLIEDERUNG GL,
  FUNKTION FK,
  KONTO KO
WHERE
  (SB.SACHBUCH_ID = GL.SACHBUCH_ID) AND
  (GL.GLIEDERUNG_ID = FK.GLIEDERUNG_ID) AND
  (FK.FUNKTION_ID = KO.FUNKTION_ID);

Das ist zwar Oracle SQL, müsste unter Firebird aber auch funktionieren. Der angegebene SQL Befehl funktioniert aber nur für Datensätze, die auch über einen Fremdschlüssel verfügen, gibt es einen Datensatz, der keinen Wert im Feld Fremdschlüssel hat, so wird dieser aufgrund des verwendeten Inner-Joins (Ist sogar ein Equi-Join, weil die PK und FK Felder gleich heissen) nicht angezeigt. In diesem Fall musst Du einen Outer-Join verwenden. Wenn ich die Problemstellung allerdings richtig verstanden habe kann dieser Fall nicht vorkommen. Ich würde an Deiner Stelle diese Query dann als View in der Datenbank abspeichern. So kannst Du dann recht bequem über
SELECT * FROM myView; Auf die grosse Tabelle zugreifen. Natürlich kannst Du den View dann auch mit ner WHERE Klausel filtern.

Zitat von theomega:

Datenbank-Anwendung ist Firebird über die Interbase-Kompos. Delphi ist 7.

Nacher sollen die Daten in einem Treeview angezeigt werden.

Wie gesagt, meine Domäne ist Oracle und MS SQL, aber ich denke das sollte auch unter Firebird funktionieren.

Zitat von theomega:

Vielen Dank

Keine Ursache

Viele Grüsse

Frank