1 Solution
Accepted Solutions
Hallo Frau Hewera-Harz,
ich glaube, dass das Problem hier ist, dass hier zwischen technischen Definitionen und den verschiedenen Anwendungsfällen unterschieden werden muss.
Die technische Definition kann relativ einfach ausgedrückt werden:
Es gibt einen Tabellenraum, also den Raum in der Datenbank, der die entsprechenden Tabellen umschließt und in den einzelnen Datenbanken unterschiedlich benannt wird (Schema, Datenbank,...). In FirstSpirit wird dieser Raum Schema genannt. Und zwar sowohl in der Konfiguration des Layers (also der Anbindung der Datenbank) als auch im SiteArchitect (für die Darstellung der Tabellen)
Um einen entsprechenden Tabellenraum anzulegen, benötigt man in der Datenbank DBA Rechte (also administrative Rechte), welche häufig Anwendungen nicht gegeben werden.
Wenn FirstSpirit entsprechende Rechte bekommt, so kann die Layerdefinition so angelegt werden, dass dort kein Schema angegeben wird. Dann wird FirstSpirit für jedes mit diesem Layer verknüpfte Datenbankschema einen neuen Tabellenraum anlegen. Im Umkehrschluß bedeutet dies aber auch, dass die Layerkonfiguration nicht auf einen spezifischen Tabellenraum zeigt. Diese Layerkonfiguration wird, aufgrund der benötigten Rechte, DBA Layer genannt.
Wenn in der Konfiguration des Layers direkt auf einen entsprechenden Tabellenraum zeigt, so werden deutlich weniger Rechte in der Datenbank benötigt, um diesen sinnvoll nutzen zu können. Da dies die übliche Konfiguration bei vielen Kunden ist, haben wir diesen Layer "Standardlayer" genannt.
Dieser Layer hat die Eigenschaft, dass er genau auf einen Tabellenraum zeigt, es über diesen also direkt möglich ist, entsprechende Tabellen zu identifizieren.
Der "normale" Anwendungsfall für Standard-Layer ist nun, dass ein Datenbank-Administrator für jedes Schema in jedem Projekt einen entsprechenden Tabellenraum in der Datenbank anlegt und dann entsprechende Standardlayer in FirstSpirit erzeugt werden, die auf diesen Tabellenraum zeigen.
In die Projekte werden diese Standardlayer normalerweise schreibend eingebunden, so dass über FirstSpirit dann Tabellen und Datensätze in der Datenbank angelegt werden können.
Im Gegensatz zu den DBA-Layern kann man Standardlayer aber auch dazu benutzen, bereits vorhandene Daten aus einer Datenbank auszulesen, da diese ja direkt auf einen entsprechenden Tabellenraum in der Datenbank zeigen.
Hierbei handelt es sich normalerweise um Daten, die aus einer anderen Anwendung stammen (z.B. Personalstammblätter) und die in dem FirstSpirit Projekt genutzt werden sollen.
Dies ist die Nutzungsweise, die in FirstSpirit als "externe Datenbank" bezeichnet wird.
In Abgrenzung zu diesem Begriff werden Datenbanken, die unter FirstSpirit Kontrolle stehen, auch häufig als interne Datenbank bezeichnet.
Und schließlich gibt es noch den Sonderfall, den Sie beschreiben - Sie nutzen eine Datenbank in einem zentralen Projekt (also eine schreibend angebundene, "interne Datenbank") und wollen diese in anderen Projekten zusätzlich einbinden. Dort müssen Sie diese "interne Datenbank" lesend einbinden (also genauso wie oben beschreiben für "externe Datenbanken"). Dies ist die Stelle, an der die Begriffe sich mischen. Hier wird nun die "interne Datenbank" aus dem Quellprojekt in den Zielprojekten als "externe Datenbank" bezeichnet, obwohl diese Datenbank nur Daten beinhaltet, die unter FirstSpirit Kontrolle stehen.
Ich hoffe, dass ich mit dieser kurzen Abhandlung die Begrifflichkeiten etwas deutlicher machen konnte und dass diese nicht zu weiterer Verwirrung führt 
Viele Grüsse aus Dortmund,
Holger Höbbel
Hallo Frau Hewera-Harz,
ich glaube, dass das Problem hier ist, dass hier zwischen technischen Definitionen und den verschiedenen Anwendungsfällen unterschieden werden muss.
Die technische Definition kann relativ einfach ausgedrückt werden:
Es gibt einen Tabellenraum, also den Raum in der Datenbank, der die entsprechenden Tabellen umschließt und in den einzelnen Datenbanken unterschiedlich benannt wird (Schema, Datenbank,...). In FirstSpirit wird dieser Raum Schema genannt. Und zwar sowohl in der Konfiguration des Layers (also der Anbindung der Datenbank) als auch im SiteArchitect (für die Darstellung der Tabellen)
Um einen entsprechenden Tabellenraum anzulegen, benötigt man in der Datenbank DBA Rechte (also administrative Rechte), welche häufig Anwendungen nicht gegeben werden.
Wenn FirstSpirit entsprechende Rechte bekommt, so kann die Layerdefinition so angelegt werden, dass dort kein Schema angegeben wird. Dann wird FirstSpirit für jedes mit diesem Layer verknüpfte Datenbankschema einen neuen Tabellenraum anlegen. Im Umkehrschluß bedeutet dies aber auch, dass die Layerkonfiguration nicht auf einen spezifischen Tabellenraum zeigt. Diese Layerkonfiguration wird, aufgrund der benötigten Rechte, DBA Layer genannt.
Wenn in der Konfiguration des Layers direkt auf einen entsprechenden Tabellenraum zeigt, so werden deutlich weniger Rechte in der Datenbank benötigt, um diesen sinnvoll nutzen zu können. Da dies die übliche Konfiguration bei vielen Kunden ist, haben wir diesen Layer "Standardlayer" genannt.
Dieser Layer hat die Eigenschaft, dass er genau auf einen Tabellenraum zeigt, es über diesen also direkt möglich ist, entsprechende Tabellen zu identifizieren.
Der "normale" Anwendungsfall für Standard-Layer ist nun, dass ein Datenbank-Administrator für jedes Schema in jedem Projekt einen entsprechenden Tabellenraum in der Datenbank anlegt und dann entsprechende Standardlayer in FirstSpirit erzeugt werden, die auf diesen Tabellenraum zeigen.
In die Projekte werden diese Standardlayer normalerweise schreibend eingebunden, so dass über FirstSpirit dann Tabellen und Datensätze in der Datenbank angelegt werden können.
Im Gegensatz zu den DBA-Layern kann man Standardlayer aber auch dazu benutzen, bereits vorhandene Daten aus einer Datenbank auszulesen, da diese ja direkt auf einen entsprechenden Tabellenraum in der Datenbank zeigen.
Hierbei handelt es sich normalerweise um Daten, die aus einer anderen Anwendung stammen (z.B. Personalstammblätter) und die in dem FirstSpirit Projekt genutzt werden sollen.
Dies ist die Nutzungsweise, die in FirstSpirit als "externe Datenbank" bezeichnet wird.
In Abgrenzung zu diesem Begriff werden Datenbanken, die unter FirstSpirit Kontrolle stehen, auch häufig als interne Datenbank bezeichnet.
Und schließlich gibt es noch den Sonderfall, den Sie beschreiben - Sie nutzen eine Datenbank in einem zentralen Projekt (also eine schreibend angebundene, "interne Datenbank") und wollen diese in anderen Projekten zusätzlich einbinden. Dort müssen Sie diese "interne Datenbank" lesend einbinden (also genauso wie oben beschreiben für "externe Datenbanken"). Dies ist die Stelle, an der die Begriffe sich mischen. Hier wird nun die "interne Datenbank" aus dem Quellprojekt in den Zielprojekten als "externe Datenbank" bezeichnet, obwohl diese Datenbank nur Daten beinhaltet, die unter FirstSpirit Kontrolle stehen.
Ich hoffe, dass ich mit dieser kurzen Abhandlung die Begrifflichkeiten etwas deutlicher machen konnte und dass diese nicht zu weiterer Verwirrung führt
Viele Grüsse aus Dortmund,
Holger Höbbel
Hallo Herr Höbbel,
nein, Ihre Erläuterungen haben nicht zu weiteren Verwirrungen geführt 
.
Im Gegenteil.
Vielen Dank für Ihre Mühe, diesen Sachverhalt so detailliert darzulegen.
Ich ziehe daraus den Schluss, dass die Verwendung des DBA-Layers "günstiger" ist, wenn die entsprechenden Rechte auf der DB vorhanden sind, weil dann der Aufwand für das Anlegen der Schemata in der DB und der jeweiligen Datenbank-Layer in FS entfällt und es keine Probleme mit gleichnamigen Tabellen geben kann.
Danke und Grüße aus Wuppertal
Petra Hewera-Harz
