Diskussion:ANSI-SPARC-Architektur

> also der grafischen Benutzeroberfläche und dem API aus;

Es sollte nicht unbedingt "grafischen Benutzeroberfläche und dem API aus" heißen, sondern vielmehr auf die Anwendungsprogramme, die auf die DB über das DBMS zugreifen.

Nächstes mal bitte einfach machen ;-) Fragment 16:17, 7. Aug 2005 (CEST)

Erweiterung für verteilte Informationssysteme

In verteilten Informationssystemen erweitert man dieses Schema: Hinzu kommt ein Verteilungsschema und ein globales Konzeptionelles Schema (GKS), welches die lokalen konzeptionellen Schemata (LKS) zusammenfasst. Das Verteilungsschema setzt sich aus einem Fragmentierungsschema und einem Allokationsschema zusammen. Eine Grafik dazu wäre nicht schlecht. --Javaprog 12:50, 20. Mär 2006 (CET)

Implementierung in einem RDBMS (erledigt)

Der folgende Satz ist falsch: Das 3-Ebenen-Modell ist in aktuellen Datenbankmanagementsystemen (DBMS) zwar durch Sichten implementiert, ... In einem RDBMS ist ausschließlich die interne Sicht implementiert. Die anderen Sichten können vom Datendesigner durch Sichten (= Views) hergestellt werden, man entscheidet sich aber häufig dafür, die externe und die interne Sicht durch Schichten in der Anwendungsarchitektur herzustellen.

Der folgende Satz ist auch falsch: Üblicherweise benutzen Anwendungen direkt das konzeptuelle Schema, also Operationen auf den eigentlichen Tabellen, und nicht auf Sichten. Man handelt sich dadurch natürlich die zu erwartenden Nachteile (z.B. Verlust der logischen Datenunabhängigkeit) ein. Die Anwendungen nutzen meistens nicht das konzeptuelle Schema, sondern das interne Schema.

Die Anwendungen werden oft als Schichten-Architektur realisiert, wobei die unterste Schicht die DB-Zugriffsschicht ist. Die Schnittstellen der DB-Zugriffsschicht zur Geschäftslogik-Schicht ist aber keinesfalls zwangsläufig identisch mit der konzeptuellen Schicht im Datenhaushalt. --Julius-m 22:11, 10. Jul. 2007 (CEST)

Auch die folgende Aussage würde ich so nicht stehen lassen: Dies bedeutet, dass Änderungen an der Datenbankstruktur keine Auswirkungen auf die externe Ebene, also die Benutzer und Anwendungen haben. Solche Änderungen haben keine Auswirkungen auf die externe Ebene der Daten - das stimmt, aber sie haben oft Auswirkungen auf die Anwendungen (=Zugriffs-Software). Aus meiner Projekterfahrung weiß ich, dass Tuning-Massnahmen oft nicht nur mit dem Erstellen eines zusätzlichen Index bestehen, sondern dass die geforderte Performance oft nur durch gezielte Denormalisierungen und Herstellung von Redundanz möglich ist. Das hat dann Auswirkungen auf die Software-Komponenten, die Zugriffe auf die geänderten Tabellen enthalten. Wenn die Software eine eigene DB-Zugriffs-Schicht hat, dann erfordern solche Änderungen lediglich eine Anpassung der Zugriffsschicht und die restliche Software bleibt unverändert.

Danke an R.K.A.L.. Jetzt ist der Artikel wesentlich klarer in seiner Aussage. Meinen letzten Kritikpunkt habe ich selber im Text korrigiert: Das ANSI-SPARC-Modell beschreibt Ebenen der Datenhaltung. Hier kann jede einzelne Ebene geändert werden ohne die anderen Ebenen antasten zu müssen. Die Auswirkungen solcher Änderungen auf die Anwendungen (=Programme) sind eine ganz andere Frage. Eine Änderung an einer der drei Ebenen hat immer Auswirkungen auf die Anwendungen. --Julius-m 19:38, 26. Dez. 2007 (CET)

"Fapmaster Inc."

Zitat aus Artikel: "Die Architektur wurde 1975 vom Standards Planning and Requirements Committee (SPARC) der Fapmaster Inc. - (ANSI) wurde nur dem Namen hinzugefügt, damit es besser klingt - entwickelt und hat zum Ziel den Benutzer einer Datenbank vor nachteiligen Auswirkungen von Änderungen in der Datenbankstruktur zu schützen."

Dieser Satz klingt fragwürdig, vor allem wenn man "Fapmaster" in eine Suchmaschine eingegeben hat. "fapmaster inc." liefert gar keine Suchergebnisse. Bitte um Überprüfung. --80.226.1.7 09:11, 7. Okt. 2009 (CEST)