Ich kann in der AdventureWorks-Datenbank sehen, dass verschiedene Schemas zum Gruppieren von Tabellen verwendet werden. Warum ist das getan (Sicherheit, ...?) Und gibt es Best Practices, die ich finden kann?
thx, Lieven Cardoen
Als Manager von Business Intelligence setzen wir auf ein Schema für die logische Gruppierung und Verwaltung von Sicherheit. Hier sind einige Fälle, wie wir das Schema verwenden:
LOGISCHE ORGANISATION
Wir haben eine allgemeine Datenbank, die von SSIS-Paketen nur für das Staging von Daten geladen wird, bevor wir unseren operativen Datenspeicher (ODS) laden. In dieser Datenbank sind mit Ausnahme des Schemas alle Objekte in der Struktur (Tabellennamen, Spaltennamen, Datentypen, Nullwert usw.) ihrer ursprünglichen Quelle identisch. Wir verwenden das Schema, um das ursprüngliche Quellsystem der Tabelle anzugeben. In einigen seltenen Fällen haben zwei verschiedene Datenbanken Tabellen mit dem gleichen Namen und das Schema ermöglicht es uns, weiterhin den ursprünglichen Namen in der Staging-Datenbank zu verwenden.
In jeder Datenbank auf unseren BI-Servern hat jedes Teammitglied das Schema test_username. Wenn wir Testobjekte in einer Datenbank erstellen, können Sie leicht verfolgen, wer das Objekt erstellt hat. Es macht es auch viel einfacher, die Testobjekte später zu löschen, da jeder weiß, wer was gemacht hat. Offen gesagt reicht es zu wissen, dass wir es geschafft haben, zu wissen, dass es sicher gelöscht werden kann, besonders wenn wir uns nicht erinnern können, wann oder warum wir es gemacht haben!
In unserer Datencontroller-Datenbank verlassen wir uns auf ein Schema, um verschiedene Arten von Prozessen zwischen Berichten, etl und generischen Ressourcen zu trennen.
In unserem Star-Schema-Data-Warehouse sind alle Objekte in Dimensions- und Fakteschemata unterteilt.
Wenn wir Daten an andere Abteilungsserver senden, machen wir alle BI-Objekte auf ihren Servern dazu, das Schema bi zu verwenden. Dies macht es wirklich einfach zu wissen, Bi lädt und pflegt die Tabelle, auch wenn es nicht auf unserem Server ist. Wenn der Zielserver keine 2008/2005 SQL Server-Box ist, wird der Tabelle ein Präfix bi _.
Wenn es darauf ankommt, verwenden wir ein Schema für eine logische Organisation, wenn wir ein Präfix oder Suffix an ein Objekt angehängt hätten, um es in Abwesenheit eines Schemas zu organisieren. Allerdings gibt es einige Fälle, in denen wir kein Schema auf unseren BI-Servern verwenden. In unserer WorkingDB ist alles dbo. Unsere WorkingDB wird wie TempDB verwendet, um temporäre Tabellen zu erstellen, aber diese Tabellen sind temporäre Tabellen, von denen wir wissen, dass sie jedes Mal erstellt werden, wenn ein ETL-Prozess ausgeführt wird. Die besondere Eigenschaft von WorkingDB ist, dass wir niemals die Datenbank sichern und alle ETL-Prozesse, die die Datenbank verwenden, müssen in der Lage sein, ihre Objekte bei Abwesenheit der Tabelle von Grund auf neu zu erstellen. In diesem Fall waren wir der Ansicht, dass die Verwendung des Schemas KEINEN organisatorischen Wert hinzufügte, da wir die Objekte nicht außerhalb ihres temporären ETL-Prozesses verwenden.
SICHERHEIT
Da wir eine BI-Gruppe sind, bauen und unterstützen wir unsere eigenen Anwendungen im Allgemeinen nicht. Wir verwenden fast ausschließlich Anwendungen anderer Leute und bringen Daten aus ihren Backend-Datenbanken auf unseren Server. Wir haben jedoch eine Datenbank namens bi_applications, die das Back-End für eine Vielzahl von kleinen CRUD-Anwendungen ist. Bei diesen Anwendungen handelt es sich in der Regel um Dateneingabeformulare, die wir dem Unternehmen zur Verfügung stellen, damit sie Daten erfassen können, die wir andernfalls in BI verwalten müssten. Es ist eine Möglichkeit, Daten, die in Produktionsanwendungen enthalten sein müssen, in BI zu importieren, während wir darauf warten, dass unsere Anwendungsoptimierungen mit niedriger Priorität in den zukünftigen Entwicklungslisten Staub aufwirbeln. Jede Anwendung hat ein eigenes Schema und das Anwendungskonto, das zum Aktualisieren der zugrunde liegenden Tabellen verwendet wird, hat NUR Zugriff auf Objekte des zugehörigen Schemas. Dies macht es sehr einfach, die einzelnen Anwendungen zu verstehen, zu sichern und zu pflegen.
In einigen Fällen habe ich Powerusern direkten Datenbankzugriff auf unsere Tabellen oder gespeicherten Prozeduren gewährt. Wir verwenden ein Schema, das mit Rollen kombiniert ist, um die Objekte zu sichern. Wir gewähren dem Schema Berechtigungen und Benutzer werden zu Rollen hinzugefügt. Dies ermöglicht uns, leicht zu verstehen, welche Objekte von wem benutzt werden, ohne dass wir uns durch Rollen hindurcharbeiten müssen, um es herauszufinden.
Kurz gesagt, wir verwenden das Schema für Sicherheitszwecke, wenn wir wahrscheinlich in Erwägung gezogen hätten, die Objekte in ihre eigenen Datenbanken zu trennen und zu erwarten, dass eine Anwendung oder ein Benutzer außerhalb von BI auf unsere Datenbanken zugreift.
Obwohl dies nicht die besten Geschäftspraktiken für Anwendungsentwickler sind, hoffe ich, dass meine bi-Use-Cases Ihnen helfen können, über einige der Möglichkeiten nachzudenken, wie Sie das Schema am Ende Ihres Unternehmens verwenden können.
Tags und Links sql-server schema