DE202020005687U1

DE202020005687U1 - Gemeinsame Datennutzung bzw. Datenteilung und materilisierte Ansichten in Datenbanken

Info

Publication number: DE202020005687U1
Application number: DE202020005687.1U
Authority: DE
Original assignee: Snowflake Inc
Current assignee: Snowflake Inc
Priority date: 2019-05-31
Filing date: 2020-05-28
Publication date: 2022-01-24
Anticipated expiration: 2030-05-29
Also published as: US10891288B2; US11113278B2; US10628415B1; EP3942427A4; EP3942427A1; WO2020243317A1; CN112470141B; US11100103B2; US20210103587A1; US20210097076A1; US10997169B2; CN112470141A; US20200379993A1; KR20220127341A; KR20210134707A; US20200379997A1; US11113279B2; KR102440082B1; US20200379996A1

Abstract

System, das folgendes umfasst:
Mittel zum Definieren eines Teilungsobjekts in einem ersten Konto, wobei das Teilungsobjekt mit dem ersten Konto assoziierte Daten umfasst;
Mittel zum Gewähren kontoübergreifender Zugriffsrechte auf das Teilungsobjekt zu einem zweiten Konto, so dass das zweite Konto einen Zugriff auf das Teilungsobjekt hat, ohne das Teilungsobjekt zu kopieren;
Mittel zum Erzeugen einer materialisierten Ansicht über das Teilungsobjekt;
Mittel zum Updaten der mit dem ersten Konto assoziierten Daten; und
Mittel zum Identifizieren, ob die materialisierte Ansicht in Bezug auf das Teilungsobjekt veraltet ist, durch Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und des Teilungsobjekts.

Description

QUERVERWEIS AUF PRIORITÄTSANMELDUNG
Diese Anmeldung beansprucht die Priorität der US-Patentanmeldung mit der seriellen Nr. 16/428,367 , eingereicht am 31. Mai 2019, deren Inhalte hierdurch in ihrer Gesamtheit hierin durch Bezugnahme enthalten ist.
TECHNISCHES GEBIET
Die vorliegende Offenbarung bezieht sich auf Datenbanken und bezieht sich insbesondere auf gemeinsame Datennutzung bzw. Datenteilung und materialisierte Ansichten in Datenbanksystemen.
Um als Gebrauchsmuster geschützt und Gegenstand davon zu sein, gibt es gemäß den Erfordernissen des Gebrauchsmustergesetzes nur Vorrichtungen, wie sie in den beigefügten Ansprüchen definiert sind, aber keine Verfahren. In einem Fall, in welchem in der Beschreibung Bezug auf Verfahren genommen wird, dienen diese Bezugnahmen lediglich dazu, die Vorrichtung oder die Vorrichtungen darzustellen, für welche mit den enthaltenen Ansprüchen Schutz gesucht wird.
HINTERGRUND
Datenbanken werden weit verbreitet zur Datenspeicherung und für einen Zugriff bei Computeranwendungen verwendet. Ein Ziel einer Datenbankspeicherung ist es, enorme Summen an Informationen auf organisierte Weise bereitzustellen, so dass darauf zugegriffen, sie gemanagt und aktualisiert bzw. upgedatet werden können. In einer Datenbank können Daten in Zeilen, Spalten und Tabellen organisiert sein. Unterschiedliche Datenbankspeichersysteme können zum Speichern unterschiedlicher Typen von Inhalt verwendet werden, wie beispielsweise bibliographische, Volltext-, numerische und/oder Bild-Inhalte. Weiterhin können beim Computing unterschiedliche Datenbanksysteme gemäß dem Organisationsansatz der Datenbank klassifiziert werden. Es gibt viele unterschiedliche Typen von Datenbanken, einschließlich relationaler Datenbanken, verteilter Datenbanken, Cloud-Datenbanken, objektorientierter und anderer.
Datenbanken werden von verschiedenen Organisationen und Unternehmen zum Speichern von Information verwendet, auf die möglicherweise zugegriffen oder die analysiert werden muss. Bei einem Beispiel kann ein Einzelhandelsunternehmen eine Auflistung aller Verkaufstransaktionen in einer Datenbank speichern. Die Datenbank kann Information darüber, wann eine Transaktion stattfand, wo sie stattfand, Gesamtkosten der Transaktion, einen Identifizierer und/oder eine Beschreibung von allen Artikeln, die bei der Transaktion gekauft wurden, und so weiter enthalten. Dasselbe Einzelhandelsunternehmen kann zum Beispiel auch Information über Mitarbeiter in derselben Datenbank speichern, die Mitarbeiternamen, Mitarbeiterkontaktinformation, Mitarbeiterarbeitshistorie, Mitarbeitergehaltssatz und so weiter enthalten könnte. Abhängig von den Bedürfnissen dieses Einzelhandelsunternehmens können die Mitarbeiterinformation und die Transaktionsinformation in unterschiedlichen Tabellen derselben Datenbank gespeichert werden. Das Einzelhandelsunternehmen muss möglicherweise seine Datenbank „abfragen“, wenn es Information in Erfahrung bringen möchte, die in der Datenbank gespeichert ist. Dieses Einzelhandelsunternehmen möchte möglicherweise Daten über, zum Beispiel, die Namen aller Mitarbeiter, die in einem bestimmten Geschäft arbeiten, aller Mitarbeiter, die an einem bestimmten Datum arbeiten, alle Transaktionen für ein bestimmtes Produkt, die während eines bestimmten Zeitraums getätigt wurden, und so weiter finden.
Wenn das Einzelhandelsgeschäft seine Datenbank abfragen möchte, um bestimmte organisierte Information aus der Datenbank zu extrahieren, wird eine Abfrageanweisung gegenüber den Datenbankdaten ausgeführt. Die Abfrage bringt bestimmte Daten gemäß einem oder mehreren Abfrageprädikaten zurück, die anzeigen, welche Information durch die Abfrage zurückgebracht werden sollte. Die Abfrage extrahiert spezifische Daten aus der Datenbank und formatiert diese Daten in eine lesbare Form. Die Abfrage kann in einer Sprache geschrieben werden, die von der Datenbank verstanden wird, wie beispielsweise strukturierte Abfrage-Sprache („SQL“ (= Structured Query Language)), so dass die Datenbanksysteme bestimmen können, welche Daten lokalisiert werden sollten und wie sie zurückgebracht werden sollten. Die Abfrage kann irgendeine relevante Information anfordern, die in der Datenbank gespeichert ist. Wenn die geeigneten Daten gefunden werden können, um auf die Abfrage zu reagieren bzw. zu antworten, hat die Datenbank das Potential, komplexe Trends und Aktivitäten aufzudecken. Diese Leistungsfähigkeit kann nur durch die Verwendung einer erfolgreich ausgeführten Abfrage nutzbar gemacht werden.
In einigen Fällen möchten unterschiedliche Organisationen, Personen oder Unternehmen Datenbankdaten möglicherweise gemeinsam nutzen bzw. teilen. Zum Beispiel kann eine Organisation wertvolle Information in einer Datenbank gespeichert haben, die an Dritte vermarktet oder verkauft werden könnte. Die Organisation möchte möglicherweise Dritten ermöglichen, die Daten anzuschauen, die Daten zu durchsuchen und/oder Berichte über die Daten auszuführen bzw. zu erstellen. Bei herkömmlichen Verfahren werden Daten gemeinsam genutzt, indem die Daten in eine Speicherressource kopiert werden, auf die der Dritte zugreifen kann. Dies ermöglicht, dass der Dritte die Daten liest, durchsucht und Berichte über sie ausführt. Ein Kopieren von Daten ist jedoch zeit- und ressourcenintensiv und kann erhebliche Speicherressourcen verbrauchen. Zusätzlich werden, wenn die ursprünglichen Daten vom Eigentümer der Daten aktualisiert bzw. upgedated werden, diese Modifikationen nicht zu den kopierten Daten verbreitet bzw. weitergegeben.
In Anbetracht des Vorstehenden sind hierin Systeme, Verfahren und Vorrichtungen für eine unmittelbare bzw. sofortige und kopierfreie Datenteilung in einem mehrmandantenfähigen Datenbanksystem offenbart. Die hierin offenbarten Systeme, Verfahren und Vorrichtungen bieten Mittel zum Abfragen gemeinsam genutzter bzw. geteilter Daten, zum Erzeugen und Auffrischen materialisierter Ansichten über gemeinsam genutzte bzw. geteilte Daten und zum gemeinsamen Nutzen bzw. Teilen materialisierter Ansichten.
Figurenliste
Nicht beschränkende und nicht erschöpfende Implementierungen der vorliegenden Offenbarung werden unter Bezugnahme auf die folgenden Figuren beschrieben, wobei sich gleiche Bezugszeichen auf gleiche oder ähnliche Teile in allen der verschiedenen Ansichten beziehen, sofern nichts anderes spezifiziert ist. Vorteile der vorliegenden Offenbarung werden im Hinblick auf die folgende Beschreibung und die beigefügten Zeichnungen besser verstanden werden, wobei:

1 ein schematisches Blockdiagramm ist, das Konten in einer mehrmandantenfähigen Datenbank gemäß einer Ausführungsform darstellt;
2 ein schematisches Diagramm ist, das ein System zum Bereitstellen und Zugreifen auf Datenbankdienste gemäß einer Ausführungsform darstellt;
3 ein schematisches Diagramm ist, das eine mehrmandantenfähige Datenbank mit einer Trennung von Speicher- und Computer- bzw. Rechenressourcen gemäß einer Ausführungsform darstellt;
4 ein schematisches Blockdiagramm ist, das Objekthierarchien gemäß einer Ausführungsform darstellt;
5 ein schematisches Diagramm ist, das einen rollenbasierten Zugriff gemäß einer Ausführungsform darstellt;
6 ein schematisches Diagramm ist, das eine Nutzungsgewährung zwischen Rollen gemäß einer Ausführungsform darstellt;
7 ein schematisches Diagramm ist, das ein Teilungsobjekt gemäß einer Ausführungsform darstellt;
8 ein schematisches Diagramm ist, das kontoübergreifende Gewährungen gemäß einer Ausführungsform darstellt;
9 ein schematisches Blockdiagramm ist, das Komponenten einer Teilungskomponente gemäß einer Ausführungsform darstellt;
10 ein schematisches Diagramm eines Systems und eines Prozessablaufs zum Erzeugen einer materialisierten Ansicht über gemeinsam genutzte bzw. geteilte Daten gemäß einer Ausführungsform ist;
11 ein schematisches Diagramm eines Prozessablaufs zum Erzeugen und Auffrischen einer materialisierten Ansicht gemäß einer Ausführungsform ist;
12 ein schematisches Diagramm eines Prozessablaufs zum Aktualisieren bzw. Updaten einer Quellentabelle einer materialisierten Ansicht und zum Auffrischen der materialisierten Ansicht in Bezug auf ihre Quellentabelle gemäß einer Ausführungsform ist;
13 ein schematisches Diagramm einer materialisierten Ansicht gemäß einer Ausführungsform ist;
14 ein schematisches Blockdiagramm einer Datenverarbeitungsplattform einschließlich eines Computing-Service-Managers gemäß einer Ausführungsform ist;
15 ein schematisches Blockdiagramm eines Computing-Service-Managers gemäß einer Ausführungsform ist;
16 ein schematisches Blockdiagramm einer Ausführungsplattform gemäß einer Ausführungsform ist;
17 ein schematisches Blockdiagramm einer Datenbankverarbeitungsumgebung gemäß einer Ausführungsform ist;
18 ein schematisches Ablauf- bzw. Flussdiagramm eines Verfahrens zur kontoübergreifenden Erzeugung bzw. Generierung und Auffrischung einer materialisierten Ansicht in einem mehrmandantenfähigen Datenbanksystem gemäß einer Ausführungsform ist;
19 ein schematisches Ablauf- bzw. Flussdiagramm eines Verfahrens zur kontoübergreifenden gemeinsamen Nutzung bzw. Teilung einer materialisierten Ansicht in einem mehrmandantenfähigen Datenbanksystem gemäß einer Ausführungsform ist; und
20 ein Blockdiagramm ist, das ein Beispiel für eine Computervorrichtung oder ein -system darstellt, die oder das mit einer oder mehreren Ausführungsformen übereinstimmt, die hierin offenbart sind.

DETAILLIERTE BESCHREIBUNG
Hierin sind Systeme, Verfahren und Vorrichtungen zur kontoübergreifenden Generierung materialisierter Ansichten in einem mehrmandantenfähigen Datenbanksystem und weiterhin zur kontoübergreifenden gemeinsamen Nutzung bzw. Teilung materialisierter Ansichten offenbart. Ein Datenbanksystem kann mehrere Konten oder Clients haben, die jeweils eindeutige Datensätze innerhalb des Datenbanksystems speichern. Bei einer beispielhaften Implementierung kann das Datenbanksystem Daten für mehrere Unternehmen speichern und managen und kann jedes der mehreren Unternehmen sein eigenes Konto innerhalb des Datenbanksystems haben. In einigen Fällen kann es wünschenswert sein, zwei oder mehreren unterschiedlichen Konten eine gemeinsame Nutzung von Daten zu gestatten. Daten können zwischen einem Provider- bzw. Anbieterkonto geteilt werden, das die Daten besitzt und die Daten mit einem Empfängerkonto teilt. Die Daten können für das Empfängerkonto wertvoller sein, wenn das Empfängerkonto die Daten abfragen kann, um Berichte basierend auf den Daten zu erzeugen oder die Daten zu analysieren. Wenn das Empfängerkonto häufig dieselbe Abfrage an den Daten ausführt, kann das Empfängerkonto wünschen, eine materialisierte Ansicht für diese Abfrage zu erzeugen. Die materialisierte Ansicht ermöglicht es dem Empfängerkonto, Abfrageergebnisse über die Daten schnell zu erzeugen, ohne jedes Mal, wenn dieselbe Abfrage ausgeführt wird, alle der Daten zu lesen oder zu verarbeiten.
In Anbetracht des Vorstehenden ermöglichen die hierin offenbarten Systeme, Verfahren und Vorrichtungen eine Datenteilung zwischen Konten eines mehrmandantenfähigen Datenbanksystems. Die hierin offenbarten Systeme, Verfahren und Vorrichtungen ermöglichen weiterhin die kontoübergreifende Erzeugung und Auffrischung materialisierter Ansichten über gemeinsam genutzte bzw. geteilte Daten. Die hierin offenbarten Systeme, Verfahren und Vorrichtungen ermöglichen weiterhin die kontoübergreifende gemeinsame Nutzung und Auffrischung materialisierter Ansichten, so dass ein begrenzter Datenumfang zwischen Konten geteilt werden kann.
Bei einer beispielhaften Implementierung der vorliegenden Offenlegung könnte ein Konto einer mehrmandantenfähigen Datenbank mit einem Einzelhandelsgeschäft assoziiert sein, das Waren verkauft, die von einem Hersteller bereitgestellt werden. Der Hersteller und das Einzelhandelsgeschäft können jeweils ihr eigenes Konto innerhalb des mehrmandantenfähigen Datenbanksystems haben. Das Einzelhandelsgeschäft könnte Daten darüber speichern, welche Artikel und wie viele Artikel verkauft worden sind, die vom Hersteller geliefert wurden. Das Einzelhandelsgeschäft kann zusätzliche Daten speichern, wie beispielsweise wo die Artikel verkauft wurden, zu welchem Preis die Artikel verkauft wurden, ob die Artikel online oder in einem Einzelhandelsgeschäft gekauft wurden, Demografien dafür, welche Personen die Artikel kauften, und so weiter. Die vom Einzelhandelsgeschäft gespeicherten Daten können für den Hersteller von erheblichem Wert sein. Das Einzelhandelsgeschäft und der Hersteller könnten eine Vereinbarung treffen, damit der Hersteller auf Daten über seine Artikel zugreifen kann, die vom Einzelhandelsgeschäft verkauft wurden. Bei dieser beispielhaften Implementierung ist das Einzelhandelsgeschäft das Anbieterkonto, da das Einzelhandelsgeschäft die Verkaufsdaten für die Artikel besitzt. Der Hersteller ist das Empfängerkonto, da der Spielzeughersteller die Daten anschauen wird, die im Besitz des Einzelhandelsgeschäfts sind. Die Daten des Einzelhandelsgeschäfts werden innerhalb des mehrmandantenfähigen Datenbanksystems gespeichert. Das Einzelhandelsgeschäft bietet dem Hersteller kontoübergreifende Zugriffsrechte, die zulassen, dass der Hersteller die Daten über Verkäufe der Artikel des Herstellers liest. Das Einzelhandelsgeschäft kann den Hersteller daran hindern, irgendwelche andere Daten, wie beispielsweise Mitarbeiterdaten, Verkaufsdaten für andere Artikel und so weiter, anzuschauen. Der Hersteller kann die Daten im Besitz des Einzelhandelsgeschäfts anschauen und abfragen, die dem Hersteller zur Verfügung gestellt worden sind. Der Hersteller kann eine materialisierte Ansicht über die Daten erzeugen. Die materialisierte Ansicht speichert Abfrageergebnisse, damit der Hersteller die Daten schneller abfragen kann. Die materialisierte Ansicht kann automatisch aufgefrischt werden, um irgendwelche Updates bzw. Aktualisierungen widerzuspiegeln, die an ihrer Quellentabelle (d.h. der Tabelle im Besitz des Einzelhandelsgeschäfts) vorgenommen worden sind. Der Hersteller kann mehrere materialisierte Ansichten für mehrere unterschiedliche Abfragen erstellen, die im Allgemeinen vom Hersteller angefordert werden. Die materialisierten Ansichten können vom Hersteller privat erzeugt werden, so dass das Einzelhandelsgeschäft keinen Einblick hat, welche materialisierten Ansichten vom Hersteller erzeugt worden sind.
Bei einer weiteren Implementierung der Offenbarung und im Anschluss an das oben präsentierte beispielhafte Szenario kann das Einzelhandelsgeschäft wünschen, zusammenfassende Information mit dem Hersteller zu teilen, ohne dem Hersteller zu gestatten, die gesamte Information anzuschauen, die im Konto des Einzelhandelsgeschäfts in der mehrmandantenfähigen Datenbank gespeichert ist. Bei einer solchen Implementierung kann das Einzelhandelsgeschäft eine materialisierte Ansicht erzeugen und nur die materialisierte Ansicht mit dem Hersteller teilen. Beim beispielhaften Szenario könnte das Einzelhandelsgeschäft eine materialisierte Ansicht erzeugen, die anzeigt, wie viele unterschiedliche Artikel vom Einzelhandelsgeschäft zum Verkauf angeboten werden, die vom Hersteller hergestellt worden sind, wie viele Artikel über einen bestimmten Zeitraum hinweg verkauft worden sind, die vom Hersteller hergestellt wurden, einen Durchschnittspreis der vom Einzelhandelsgeschäft verkauften Artikel, die vom Hersteller hergestellt wurden, und so weiter. Es sollte eingesehen werden, dass die materialisierte Ansicht in Abhängigkeit von den Bedürfnissen der Datenbankkunden irgendeine relevante zusammenfassende Information liefern kann. Bei der beispielhaften Implementierung kann das Einzelhandelsgeschäft nur die materialisierte Ansicht mit dem Hersteller teilen, so dass der Hersteller die zusammenfassende Information anschauen kann, aber nicht die zugrunde liegenden Daten, das Schema, die Metadaten, die Datenorganisationsstruktur und so weiter anschauen kann. Bei der beispielhaften Implementierung kann das Einzelhandelsgeschäft veranlassen, dass die materialisierte Ansicht automatisch aufgefrischt wird, wenn die Quellentabelle für die materialisierte Ansicht geändert bzw. modifiziert oder aktualisiert bzw. upgedatet worden ist.
Die hierin offenbarten Systeme, Verfahren und Vorrichtungen bieten verbesserte Mittel für eine gemeinsame Nutzung von Daten, eine gemeinsame Nutzung materialisierter Ansichten, eine Erzeugung bzw. Generierung materialisierter Ansichten über gemeinsam genutzte Daten und eine automatische Aktualisierung materialisierter Ansichten über gemeinsam genutzte Daten. Solche Systeme, Verfahren und Vorrichtungen, wie sie hierin offenbart werden, bieten Datenbankkunden, die Daten gemeinsam nutzen und/oder Daten im Besitz einer anderen Partei lesen möchten, erhebliche Vorteile.
Eine materialisierte Ansicht ist ein Datenbankobjekt, das die Ergebnisse einer Abfrage speichert. Die materialisierte Ansicht wird basierend auf einer Quellentabelle erzeugt, die die Ergebnisse für die Abfrage liefert. Eine materialisierte Ansicht kann lokal in einer Cacheressource eines Ausführungsknotens gespeichert werden, so dass auf sie bei einer Verarbeitung der Abfrage schnell zugegriffen werden kann. Materialisierte Ansichten werden typischerweise aus Leistungsfähigkeitsgründen erzeugt, so dass Abfrageergebnisse schneller erhalten werden können und unter Verwendung von weniger Verarbeitungsressourcen berechnet werden können. Materialisierte Ansichten können eher als eine konkrete Tabelle als als eine Ansicht (in einem Cache) zwischengespeichert werden, so dass die materialisierte Ansicht aktualisiert werden kann, um irgendwelche an der Quellentabelle vorgenommenen Änderungen widerzuspiegeln. Die Quellentabelle kann anhand von Einfüge-, Lösch-, Aktualisierungs- und/oder Zusammenführungsbefehlen modifiziert werden, und diese Modifikationen können dazu führen, dass die materialisierte Ansicht in Bezug auf die Quellentabelle veraltet ist. Die materialisierte Ansicht ist in Bezug auf ihre Quellentabelle „veraltet“, wenn Änderungen an den Daten in der Quellentabelle vorgenommen worden sind, diese Änderungen jedoch noch nicht an die materialisierte Ansicht weitergegeben worden sind. Wenn die materialisierte Ansicht in Bezug auf die Quellentabelle veraltet ist, kann man sich nicht mehr allein auf die materialisierte Ansicht verlassen, um genaue Abfrageergebnisse zu bestimmen. Hierin offenbarte Ausführungsformen bieten verbesserte Mittel zum Erzeugen, Speichern und Auffrischen materialisierter Ansichten, so dass Abfragen über materialisierte Ansichten ausgeführt werden können, selbst wenn die materialisierte Ansicht in Bezug auf ihre Quellentabelle veraltet ist.
Eine Ausführungsform der Offenbarung ermöglicht eine kontoübergreifenden Datenteilung unter Verwendung sicherer Ansichten. Eine Ansicht kann als eine sichere Ansicht definiert sein, wenn sie spezifisch vorgesehen ist für Datenschutz oder dafür, einen Zugriff auf Daten zu beschränken, die nicht für alle Konten der zugrunde liegenden Tabelle freigelegt werden sollten. Daten könnten in einer sicheren Ansicht freigelegt werden, wenn zum Beispiel ein Konto einen Zugriff auf nur eine Teilmenge bzw. Untergruppe von Daten hat. Sichere Ansichten erlauben, dass ein Datenbankkonto einen beschränkten Datensatz für andere Konten oder Benutzer bzw. Anwender ohne die Möglichkeit freilegt, dass die zugrunde liegenden, unbeschränkten Daten für diese anderen Konten oder Benutzer freigelegt werden. Bei einer Ausführungsform kann ein Anbieterkonto einen kontoübergreifenden Zugriff auf seine Daten zu einem Empfängerkonto autorisieren. Das Anbieterkonto kann das Empfängerkonto darauf beschränken, nur bestimmte Daten anzuschauen, und kann das Empfängerkonto daran hindern, ein zugrunde liegendes Organisationsschema oder Statistiken über die Daten anzuschauen.
Bei einer Ausführungsform bietet eine sichere Ansicht im Vergleich mit einer regulären Ansicht mehrere Sicherheitsgarantien. Bei einer Ausführungsform legt die sichere Ansicht die Ansichtsdefinition für Nichteigentümer bzw. -besitzer der Ansicht nicht frei. Dies wirkt sich auf verschiedene Operationen aus, die auf das Datenwörterbuch zugreifen. Bei einer Ausführungsform legt die sichere Ansicht keine Information über irgendwelche zugrunde liegenden Daten der Ansicht frei, einschließlich der von der Ansicht verarbeiteten Datenmenge, der Tabellen, auf die von der Ansicht zugegriffen wird, und so weiter. Dies wirkt sich aus auf die Statistiken, die über die Anzahl von Bytes und in einer Abfrage gescannten Partitionen angezeigt werden, und das, was im Abfrageprofil für eine Abfrage angezeigt wird, die sich auf eine sichere Ansicht bezieht. Bei einer Ausführungsform legt die sichere Ansicht keine Daten aus Tabellen, auf die durch die Ansicht zugegriffen wird, die durch die Ansicht herausgefiltert werden, frei. Bei einer solchen Ausführungsform kann ein Kunden- bzw. Clientkonto, das mit einer nicht sicheren Ansicht assoziiert ist, auf Daten zugreifen, die herausgefiltert werden würden, indem Abfrageoptimierungen vorteilhaft genutzt werden, die dazu führen können, dass Benutzerausdrücke vor Sicherheitsausdrücken ausgewertet werden (z.B. Filter und Verbindungen). Bei einer solchen Ausführungsform kann, um diese Anforderung zu erreichen, der Satz von Abfrageoptimierungen, die auf eine Abfrage angewendet werden können, die eine sichere Ansicht enthält, beschränkt bzw. eingeschränkt werden, um zu garantieren, dass die Benutzerausdrücke, die Daten durchsickern lassen bzw. verlieren können, nicht ausgewertet werden, bevor die Ansicht gefiltert wird.
Bei einer Ausführungsform werden Daten im mehrmandantenfähigen Datenbanksystem über einer Vielzahl von gemeinsam genutzten Speichervorrichtungen gespeichert. Die Daten können in Tabellen gespeichert werden und die Daten in einer einzelnen Tabelle können weiterhin partitioniert oder getrennt in mehrere unveränderliche Speichervorrichtungen werden, die hierin als Mikropartition bezeichnet werden. Mikropartitionen sind unveränderliche Speichervorrichtungen, die nicht an Ort und Stelle aktualisiert werden können und regeneriert bzw. neu erzeugt werden müssen, wenn die darin gespeicherten Daten modifiziert werden. Eine Analogie zu den Mikropartitionen der Tabelle können unterschiedliche Lager- bzw. Speichergebäude innerhalb eines Speicherkomplexes sein. Bei der Analogie ähnelt der Speicherkomplex der Tabelle und ähnelt jedes separate Speichergebäude einer Mikropartition. Hunderttausende von Elementen sind über den gesamten Speicherkomplex gespeichert. Weil so viele Elemente bei dem Speicherkomplex angeordnet sind, ist es notwendig, die Elemente bzw. Artikel quer über die mehreren separaten Speichergebäude hinweg zu organisieren. Die Artikel können über mehrere separate Speicher- bzw. Lagergebäude hinweg durch irgendwelche Mittel, die Sinn machen, organisiert werden. Zum Beispiel kann ein Lagergebäude Kleidung lagern, kann ein anderes Lagergebäude Haushaltswaren lagern, kann ein anderes Lagergebäude Spielzeug lagern und so weiter. Jedes Lagergebäude kann beschriftet bzw. gekennzeichnet werden, damit die Artikel leichter zu finden sind. Wenn zum Beispiel eine Person einen Plüschteddybären finden möchte, wird die Person wissen, dass sie in das Lagergebäude gehen muss, das Spielzeug lagert. Das Lagergebäude, das Spielzeug lagert, kann weiterhin in Regalreihen organisiert sein. Das Spielzeug-Lagergebäude kann so organisiert sein, dass alle Plüschtiere in einer Regalreihe angeordnet sind. Daher kann die nach dem Plüschteddybären suchende Person wissen, dass sie das Gebäude besuchen muss, das Spielzeug lagert, und kann wissen, dass sie die Reihe besucht, die Plüschtiere lagert. Neben der Analogie zur Datenbanktechnologie kann jede Regalzeile im Lagergebäude der Lagerkomponente ähnlich zu einer Spalte von Datenbankdaten innerhalb einer Mikropartition der Tabelle sein. Die Beschriftungen bzw. Kennzeichnungen für jedes Lagergebäude und für jede Regalreihe sind ähnlich zu Metadaten in einem Datenbankkontext.
Wenn eine Transaktion an einer Tabelle ausgeführt wird, werden alle betroffenen Mikropartitionen in der Tabelle neu erstellt, um neue Mikropartitionen zu erzeugen, die die durch die Transaktion vorgenommenen Modifikationen bzw. Änderungen widerspiegeln. Nachdem eine Transaktion vollständig ausgeführt ist, können irgendwelche ursprünglichen Mikropartitionen, die neu erstellt wurden, aus der Datenbank entfernt werden. Nach jeder Transaktion, die an der Tabelle ausgeführt wird, wird eine neue Version der Tabelle erzeugt. Die Tabelle kann sich über eine Zeitperiode hinweg vielen Versionen unterziehen, wenn die Daten in der Tabelle vielen Änderungen unterzogen werden, wie beispielsweise Einfügungen, Löschungen, Aktualisierungen bzw. Updates und/oder Zusammenführungen. Jede Version der Tabelle kann Metadaten enthalten, die anzeigen, welche Transaktion die Tabelle erzeugte, wann die Transaktion bestellt wurde, wann die Transaktion vollständig ausgeführt wurde und wie die Transaktion eine oder mehrere Zeilen in der Tabelle änderte. Die offenbarten Systeme, Verfahren und Vorrichtungen für eine kostengünstige Tabellenversionierung können genutzt werden, um ein effizientes Mittel zum Aktualisieren von Tabellenmetadaten bereitzustellen, nachdem eine oder mehrere Änderungen (Transaktionen) an der Tabelle aufgetreten sind.
Die Mikropartition kann als Batcheinheit betrachtet werden, bei der jede Mikropartition zusammenhängende Speichereinheiten aufweist. Beispielsweise kann jede Mikropartition zwischen 50 MB und 500 MB unkomprimierter Daten enthalten (es ist zu beachten, dass die tatsächliche Größe in einem Speicher kleiner sein kann, da Daten komprimiert gespeichert sein können). Gruppen von Zeilen in Tabellen können in einzelne Mikropartitionen abgebildet werden, die spaltenweise organisiert sind. Diese Größe und diese Struktur ermöglichen eine extrem granulare Auswahl der zu scannenden Mikropartitionen, die aus Millionen oder sogar Hunderten von Millionen von Mikropartitionen bestehen können. Dieser granulare Auswahlprozess kann hierin als „Beschneiden“ bzw. „Bereinigen“ bzw. „Pruning“ basierend auf Metadaten bezeichnet werden. Pruning enthält ein Verwenden von Metadaten, um zu bestimmen, welche Teilbereiche einer Tabelle, einschließlich welche Mikropartitionen oder Mikropartitionsgruppierungen in der Tabelle, für eine Abfrage nicht relevant sind, und dann ein Vermeiden dieser nicht relevanten Mikropartitionen, wenn auf die Abfrage reagiert bzw. geantwortet wird, und ein Scannen von nur den relevanten Mikropartitionen, um auf die Abfrage zu antworten. Metadaten können automatisch über alle in einer Mikropartition gespeicherten Zeilen gesammelt werden, einschließlich: des Wertebereichs für jede der Spalten in der Mikropartition; der Anzahl von unterschiedlichen Werten; und/oder zusätzlicher Eigenschaften, die sowohl für eine Optimierung als auch für eine effiziente Abfrageverarbeitung verwendet werden. Bei einer Ausführungsform kann eine Mikropartitionierung automatisch an allen Tabellen durchgeführt werden. Zum Beispiel können Tabellen transparent partitioniert werden, indem die Reihenfolge verwendet wird, die beim Einfügen/Laden der Daten auftritt.
Mehrmandantenfähge Datenbanken oder mehrmandantenfähge universelle Datenbanken bzw. Datenlager unterstützen mehrere unterschiedliche Kundenkonten gleichzeitig. Als ein Beispiel ist 1 ein schematisches Blockdiagramm, das eine mehrmandantenfähge Datenbank oder eine universelle Datenbank darstellt, die viele unterschiedliche Kundenkonten A1, A2, A3, An etc. unterstützt. Kundenkonten können durch mehrere Sicherheitskontrollen getrennt sein, einschließlich unterschiedlicher einheitlicher Ressourcenzeiger (URLs (= Uniform Resource Locators)), um mit unterschiedlichen Berechtigungsdaten für einen Zugang bzw. Zugangsdaten zu verbinden, unterschiedlicher Datenspeicherorte (wie beispielsweise Amazon Web Services S3-Buckets) und unterschiedlicher Verschlüsselungsschlüssel auf Kontoebene. So kann es sein, dass jedem Kunden nur erlaubt wird, die eigenen Daten des Kunden zu sehen, zu lesen und/oder zu schreiben. Aufgrund des Designs kann es für einen Kunden unmöglich sein, Daten eines anderen Kunden zu sehen, zu lesen oder zu schreiben. In einigen Fällen ist die strenge Trennung von Kundenkonten das Rückgrat einer mehrmandantenfähigen universellen Datenbank oder eine Datenbanksystems.
In einigen Fällen kann es wünschenswert sein, eine kontoübergreifende Datenteilung und/oder die kontoübergreifende Erzeugung und Aktualisierung materialisierter Ansichten zuzulassen. Jedoch ermöglicht kein aktuelles mehrmandantenfähigen Datenbanksystem eine gemeinsame Nutzung bzw. Teilung von Daten zwischen unterschiedlichen Kundenkonten auf eine sofortige, kopierfreie und leicht kontrollierbare Weise.
Basierend auf dem Voranstehenden sind hierin Systeme, Verfahren und Vorrichtungen offenbart, die bei einer Ausführungsform zum Erzeugen, Aktualisieren und/oder Anschauen einer materialisierten Ansicht über geteilte Daten implementiert sein können. Die hierin offenbarten Systeme, Verfahren und Vorrichtungen bieten weiterhin Mittel zum Teilen materialisierter Ansichten. Die Daten können so geteilt werden, dass sie sofort zugänglich sind, ohne dass die Daten kopiert werden müssen. Die materialisierte Ansicht kann für mehrere Parteien zugänglich sein, ohne die materialisierte Ansicht zu kopieren. Einige Ausführungsformen bieten einen Zugriff auf Daten unter Verwendung fein abgestufter Steuerelemente, um eine Trennung von gewünschten Daten aufrechtzuerhalten, während ein Zugriff auf Daten zu gelassen ist, die ein Kunde zu teilen wünscht.
Hierin offenbarte Ausführungsformen stellen Systeme, Verfahren und Vorrichtungen zum Teilen eines „Teilungsobjekts“ oder eines „Datenbankobjekts“ zwischen einem Anbieterkonto und einem oder mehreren anderen Konten in einem Datenbanksystem bereit. Das Anbieterkonto teilt das Freigabe- bzw. Teilungsobjekt oder Datenbankobjekt mit dem einen oder mehreren anderen „Empfänger“-Konten. Das Anbieterkonto kann es einem oder mehreren Empfängerkonten ermöglichen, eine materialisierte Ansicht über die Daten des Anbieters anzuschauen und/oder zu erzeugen. Bei einer Ausführungsform kann das Teilungsobjekt oder Datenbankobjekt Datenbankdaten enthalten, wie beispielsweise in einer Tabelle der Datenbank, die dem Anbieterkonto gehört, gespeicherte Daten. Das Teilungsobjekt oder Datenbankobjekt kann Metadaten über Datenbankdaten enthalten, wie beispielsweise Minimum-/Maximumwerte für eine Tabelle oder Mikropartition einer Datenbank, zugrunde liegende strukturelle oder architektonische Details der Datenbankdaten und so weiter. Das Teilungsobjekt kann eine Auflistung aller anderen Konten enthalten, die kontoübergreifende Zugriffsrechte auf Elemente des Teilungsobjekts empfangen können. Die Auflistung kann zum Beispiel anzeigen, dass ein zweites Konto eine prozedurale Logik des Teilungsobjekts verwenden kann, ohne irgendeinen zugrunde liegenden Code, der die prozedurale Logik definiert, zu sehen. Die Auflistung kann weiterhin anzeigen, dass zum Beispiel ein drittes Konto Datenbankdaten einer oder mehrerer Tabellen verwenden kann, ohne irgendeine strukturelle Information oder irgendwelche Metadaten über die Datenbankdaten zu sehen. Die Auflistung kann irgendeine Kombination von Verwendungsprivilegien für Elemente des Teilungsobjekts anzeigen, einschließlich der Frage, ob sekundäre Konten Metadaten oder strukturelle Information für Datenbankdaten oder eine prozedurale Logik sehen können. Die Auflistung kann anzeigen, ob ein Empfängerkonto Rechte hat, eine materialisierte Ansicht über die Datenbankdaten des Anbieters zu erzeugen oder zu aktualisieren.
Eine detaillierte Beschreibung von Systemen und Verfahren, die mit Ausführungsformen der vorliegenden Offenbarung übereinstimmen, wird nachstehend bereitgestellt. Während einige Ausführungsformen beschrieben werden, sollte verstanden werden, dass diese Offenbarung nicht auf irgendeine einzelne Ausführungsform beschränkt ist, sondern stattdessen zahlreiche Alternativen, Modifikationen und Äquivalente umfasst. Zusätzlich können, während in der folgenden Beschreibung zahlreiche spezifische Details dargelegt sind, um ein gründliches Verständnis der hierin offenbarten Ausführungsformen bereitzustellen, einige Ausführungsformen ohne einige oder alle dieser Details ausgeführt werden. Darüber hinaus ist der Klarheit halber bestimmtes technisches Material, das im zugehörigen Stand der Technik bekannt ist, nicht detailliert beschrieben, um eine unnötige Verschleierung der Offenbarung zu vermeiden.
Nimmt man nun Bezug auf die Figuren, ist 1 ein schematisches Blockdiagramm, das eine mehrmandantenfähige Datenbank oder universelle Datenbank darstellt, die viele unterschiedliche Kundenkonten A1, A2, A3, An etc. unterstützt. Kundenkonten können durch mehrere Sicherheitskontrollen getrennt sein, einschließlich unterschiedlicher einheitlicher Ressourcenzeiger (URLs (= Uniform Resource Locators)), um mit unterschiedlichen Berechtigungsnachweisen für einen Zugang bzw. Zugangsdaten, unterschiedlichen Datenspeicherorten (wie beispielsweise Amazon Web Services S3-Buckets) und unterschiedlichen Verschlüsselungsschlüssel auf Kontoebene zu verbinden. So kann es jedem Kunden nur erlaubt sein, eigenen Daten des Kunden zu sehen, zu lesen und/oder zu schreiben. Aufgrund des Designs kann es für einen Kunden unmöglich sein, die Daten eines anderen Kunden zu sehen, zu lesen oder zu schreiben. In einigen Fällen ist die strenge Trennung von Kundenkonten das Rückgrat einer mehrmandantenfähigen universellen Datenbank oder eines mehrmandantenfähigen Datenbanksystems.
2 ist ein schematisches Diagramm eines Systems 200 zum Bereitstellen von Datenbankdaten oder -diensten und zum Zugreifen auf diese. Das System 200 enthält ein Datenbanksystem 202, einen oder mehrere Server 204 und ein Client-Computersystem 206. Das Datenbanksystem 202, der eine oder die mehreren Server 204 und/oder das Client-Computersystem 206 können über ein Netzwerk 208, wie beispielsweise das Internet, miteinander kommunizieren. Zum Beispiel kann oder können der eine oder die mehreren Server 204 und/oder das Client-Computersystem 206 über das Netzwerk 208 auf das Datenbanksystem 202 zugreifen, um eine Datenbank abzufragen und/oder Daten aus einer Datenbank zu empfangen. Die Daten aus der Datenbank können von dem einen oder den mehreren Servern 204 oder dem Client-Computersystem 206 für irgendeinen Typ von Computing- bzw. Computeranwendung verwendet werden. Bei einer Ausführungsform ist das Datenbanksystem 202 ein mehrmandantenfähiges Datenbanksystem, das Daten für eine Vielzahl unterschiedlicher Konten hostet.
Das Datenbanksystem 202 enthält eine Freigabe- bzw. Teilungskomponente 210 und einen Speicher 212. Der Speicher 212 kann Speichermedien zum Speichern von Daten enthalten. Zum Beispiel kann der Speicher 212 eine oder mehrere Speichervorrichtungen zum Speichern von Datenbanktabellen, Schemata, Verschlüsselungsschlüsseln, Datendateien oder irgendwelchen anderen Daten enthalten. Die Teilungskomponente 210 kann Hardware und/oder Software zum Ermöglichen einer kontoübergreifenden gemeinsamen Nutzung bzw. Teilung von Daten oder Diensten und/oder zum Assoziieren von Ansichtsprivilegien mit Daten oder Diensten. Zum Beispiel kann die Teilungskomponente 210 eine kontoübergreifende Erzeugung und Aktualisierung materialisierter Ansichten über geteilte Daten ermöglichen. Die Teilungskomponente 210 kann eine sichere Ansicht von Datenbankdaten definieren, so dass zwei oder mehr Konten gemeinsame Datenpunkte bestimmen können, ohne die Datenpunkte selbst oder irgendwelche andere Datenpunkte, die zwischen den Konten nicht gemeinsam sind, offenzulegen. Weiterhin kann zum Beispiel die Teilungskomponente 210 Abfragen/Anweisungen verarbeiten, die von entfernten Vorrichtungen empfangen werden, um auf geteilte Daten zuzugreifen oder Daten zu teilen. Die Abfragen/Anweisungen können von dem einen oder den mehreren Servern 204 oder dem Client-Computersystem 206 empfangen werden. Bei einer Ausführungsform ist die Teilungskomponente 210 konfiguriert, um ein Teilen von Daten zwischen Konten zuzulassen, ohne doppelte Kopien von Tabellen, Daten oder dergleichen außerhalb des Teilungskontos zu erstellen. Zum Beispiel kann die Teilungskomponente für einem Teilungskonto zugeteilte Computerressourcen zulassen, irgendwelche Abfragen oder Anweisungen durchzuführen, die durch eine fremdes Konto bereitgestellt sind.
Bei einer Ausführungsform sind Speicher- und Rechenressourcen für die mehrmandantenfähige Datenbank 100 logisch und/oder physisch getrennt. Bei einer Ausführungsform ist ein Speicher eine gemeinsame, gemeinsam genutzte Ressource quer über alle Konten. Rechenressourcen können unabhängig, pro Konto, als virtuelle Lager eingerichtet werden. Bei einer Ausführungsform ist ein virtuelles Lager eine Gruppe von Rechenknoten, die auf Daten in einer Speicherschicht zugreifen und ein Abfrageergebnis berechnen. Eine Trennung der Rechenknoten oder -ressourcen vom Speicher lässt ein unabhängiges Skalieren jeder Schicht zu. Ein Trennen von Speichern und Berechnen lässt auch zu, dass gemeinsam genutzte Daten von verschiedenen Konten unabhängig verarbeitet werden können, ohne dass die Berechnung in einem Konto die Berechnung in anderen Konten beeinflusst. Das bedeutet, dass es wenigstens bei einigen Ausführungsformen keinen Wettstreit zwischen den Computing- bzw. Computerressourcen gibt, wenn Abfragen an gemeinsam genutzten Daten ausgeführt werden.
3 ist ein schematisches Blockdiagramm einer mehrmandantenfähigen Datenbank 300, die eine Trennung von Speicher- und Rechen- bzw. Computerressourcen darstellt. Zum Beispiel kann die mehrmandantenfähige Datenbank 300 eine universelle Datenbank bzw. ein Datenlager sein, in der bzw. dem eine Vielzahl unterschiedlicher Konten (A1, A2, A3 bis An) gehostet sind. In 3 hat das Konto A1 drei virtuelle Lager in Betrieb, hat das Konto A2 ein virtuelles Lager in Betrieb und hat das Konto A3 kein virtuelles Lager in Betrieb. Bei einer Ausführungsform haben alle diese virtuellen Lager Zugriff auf die Speicherschicht, die von den Rechenknoten der virtuellen Lagerhäuser getrennt ist. Bei einer Ausführungsform können virtuelle Lager basierend auf einer aktuellen Arbeitsauslastung für ein Konto dynamisch bereitgestellt oder entfernt werden.
Bei einer Ausführungsform verwendet ein mehrmandantenfähiges Datenbanksystem 300 Objekthierarchien in Konten. Zum Beispiel kann jedes Kundenkonto Objekthierarchien enthalten. Objekthierarchien sind häufig in Datenbanken verwurzelt. Zum Beispiel können Datenbanken Schemata enthalten und können Schemata wiederum Objekte, wie beispielsweise Tabellen, Ansichten, Sequenzen, Dateiformate und Funktionen, enthalten. Jedes dieser Objekte dient einem speziellen Zweck: Tabellen speichern relationale oder halbstrukturierte Daten; Ansichten definieren logische Abstraktionen über die gespeicherten Daten; Sequenzen bieten Mittel, um ständig wachsende Zahlen zu erzeugen; Dateiformate definieren Wege, aufgenommene Datendateien zu zerlegen bzw. zu parsen; und Funktionen halten benutzerdefinierte Ausführungsprozeduren. Bei Ausführungsformen, wie sie hierin offenbart sind, können Ansichten mit sicheren benutzerdefinierten Funktionsdefinitionen assoziiert sein, so dass zugrunde liegenden Daten, die mit der Ansicht assoziiert sind, vor Nicht-Besitzerkonten verborgen sind, die Zugriff auf die Ansicht haben.
4 ist ein schematisches Blockdiagramm, das Objekthierarchien innerhalb von Kundenkonten darstellt. Spezifisch können Konten Hierarchien von Objekten enthalten, auf die in einer Datenbank Bezug genommen werden kann. Zum Beispiel enthält das Kundenkonto A1 zwei Datenbankobjekte D1 und D2. Das Datenbankobjekt D1 enthält ein Schemaobjekt S1, das wiederum ein Tabellenobjekt T1 und ein Ansichtsobjekt V1 enthält. Das Datenbankobjekt D2 enthält ein Schemaobjekt S2, das ein Funktionsobjekt F2, ein Sequenzobjekt Q2 und ein Tabellenobjekt T2 enthält. Das Kundenkonto A2 enthält ein Datenbankobjekt D3 mit Schemaobjekt S3 und Tabellenobjekt T3. Die Objekthierarchien können steuern, wie auf Objekte, Daten, Funktionen oder andere Information oder Dienste eines Kontos oder eines Datenbanksystems zugegriffen wird oder Bezug genommen wird.
Bei einer Ausführungsform implementiert ein Datenbanksystem eine rollenbasierte Zugriffssteuerung, um einen Zugriff auf Objekte in Kundenkonten zu regulieren. Im Allgemeinen besteht eine rollenbasierte Zugriffssteuerung aus zwei Grundprinzipien: Rollen und Berechtigungen. Bei einer Ausführungsform sind Rollen spezielle Objekte in einem Kundenkonto, die Benutzern bzw. Anwendern zugeordnet sind. Berechtigungen zwischen Rollen und Datenbankobjekten definieren, welche Privilegien eine Rolle an diesen Objekten hat. Zum Beispiel kann eine Rolle, die eine Verwendungsberechtigung an einer Datenbank hat, diese Datenbank „sehen“, wenn sie den Befehl „Datenbanken zeigen“ ausführt; eine Rolle, die eine Auswahlberechtigung an einer Tabelle hat, kann aus dieser Tabelle lesen, aber nicht zur Tabelle schreiben. Die Rolle würde eine Berechtigung an der Tabelle modifizieren müssen, um zu ihr schreiben zu können.
5 ist ein schematisches Blockdiagramm, das einen rollenbasierten Zugriff auf Objekte in Kundenkonten darstellt. Ein Kundenkonto A1 enthält eine Rolle R1, die Berechtigungen zu allen Objekten in der Objekthierarchie hat. Unter der Annahme, dass diese Berechtigungen Nutzungsberechtigungen zwischen R1 und D1, D2, S1, S2 und Auswahlberechtigungen zwischen R1 und T1, V1, F2, Q2, T2 sind, kann ein Benutzer mit aktivierter Rolle R1 alle Objekte sehen und Daten aus allen Tabellen, Ansichten und Sequenzen lesen und kann die Funktion F2 innerhalb des Kontos A1 ausführen. Das Kundenkonto A2 enthält eine Rolle R3, die Berechtigungen zu allen Objekten in der Objekthierarchie Berechtigungen hat. Unter der Annahme, dass diese Berechtigungen um Nutzungsberechtigungen zwischen R3 und D3, S3 sind und eine Berechtigung zwischen R3 und T3 auswählen, kann ein Benutzer mit aktivierter Rolle R3 alle Objekte sehen und Daten aus allen Tabellen, Ansichten und Sequenzen innerhalb des Kontos A2 lesen.
6 zeigt eine Nutzungsberechtigung zwischen Rollen. Mit einer rollenbasierten Zugriffssteuerung ist es auch möglich, eine Nutzung von einer Rolle zu einer anderen Rolle zu gewähren. Eine Rolle, die eine Verwendungs- bzw. Nutzungsberechtigung für eine andere Rolle hat, „erbt“ alle Zugriffsprivilegien der anderen Rolle. Zum Beispiel gibt es in der Rolle R2 eine Verwendungsberechtigung an der Rolle R1. Ein Benutzer (z.B. mit entsprechenden Autorisierungsdetails) mit aktivierter Rolle R2 kann alle Objekte sehen und aus ihnen lesen, da die Rolle R2 alle Berechtigungen von der Rolle R1 erbt.
7 ist ein schematisches Blockdiagramm, das ein Teilungsobjekt SH1 darstellt. Bei einer Ausführungsform ist das Teilungsobjekt eine Spalte von Daten quer über eine oder mehrere Tabellen und werden dem Teilungsobjekt kontoübergreifende Zugriffsrechte gewährt, so dass ein oder mehrere andere Konten eine materialisierte Ansicht über Daten im Teilungsobjekt erzeugen, anschauen und/oder aktualisieren können. Das Kundenkonto A1 enthält das Teilungsobjekt SH1. Das Teilungsobjekt SH1 hat im Kundenkonto A1 einen eindeutigen Namen „SH1“. Das Teilungsobjekt SH1 enthält eine Rolle R4 mit Berechtigungen zu einer Datenbank D2, einem Schema S2 und einer Tabelle T2. Die Berechtigungen an der Datenbank D2 und dem Schema S2 können Nutzungsberechtigungen sein und die Berechtigung an der Tabelle T2 kann eine ausgewählte Berechtigung sein. In diesem Fall würde die Tabelle T2 im Schema S2 in der Datenbank D2 schreibgeschützt geteilt werden. Das Teilungsobjekt SH1 enthält eine Liste mit Verweisen auf andere Kundenkonten, einschließlich Konto A2.
Nachdem das Teilungsobjekt erstellt ist, kann das Teilungsobjekt von einem im Teilungsobjekt aufgelisteten Empfängerkonto importiert oder referenziert werden. Zum Beispiel ist ein Importieren eines Teilungsobjekts aus einem Anbieterkonto von anderen Kundenkonten möglich. Ein Empfängerkonto kann einen Befehl ausführen, um alle verfügbaren Teilungsobjekte zum Importieren aufzulisten. Nur wenn ein Teilungsobjekt mit Verweisen erstellt wurde, die das Empfängerkonto enthielten, kann das Empfängerkonto das Teilungsobjekt auflisten und es anschließend importieren. Bei einer Ausführungsform werden Verweise auf ein Teilungsobjekt in einem anderen Konto immer durch einen Kontonamen qualifiziert. Zum Beispiel würde das Empfängerkonto A2 auf die Teilung SH1 im Anbieterkonto A1 mit dem beispielhaften qualifizierten Namen „A1.SH1“ Bezug nehmen.
Bei einer Ausführungsform kann ein Verarbeiten oder ein Importieren eines Teilungsobjekts folgendes enthalten: Erstellen eines Aliasobjekts im Empfängerkonto; Verbinden des Aliasobjekts mit dem am häufigsten geteilten Objekt im Anbieterkonto in der Objekthierarchie; Gewähren von Verwendungsprivilegien für eine Rolle im Empfängerkonto für das Aliasobjekt; und Gewähren von Verwendungsprivilegien für eine Rolle des Empfängerkontos für die im Teilungsobjekt enthaltene Rolle.
Bei einer Ausführungsform erstellt ein Empfängerkonto, das das Teilungsobjekt oder Daten importiert, ein Aliasobjekt. Ein Aliasobjekt ähnelt einem normalen Objekt in einem Kundenkonto. Ein Aliasobjekt hat seinen eigenen eindeutigen Namen, mit dem es identifiziert wird. Ein Aliasobjekt kann mit dem obersten Objekt in jeder Objekthierarchie verbunden sein, die gemeinsam genutzt bzw. geteilt wird. Wenn mehrere Objekthierarchien gemeinsam genutzt werden, können mehrere Aliasobjekte im Empfängerkonto erstellt werden. Wenn ein Aliasobjekt verwendet wird (z.B. Lesen aus dem Aliasobjekt, Schreiben in das Aliasobjekt), wird das Aliasobjekt intern durch das normale Objekt im Anbieter bzw. Providerkonto ersetzt, mit dem es verbunden ist. Auf diese Weise sind Aliasobjekte lediglich Proxy-Objekte normaler Objekte und keine doppelten bzw. duplizierten Objekte. Wenn sie somit aus einem Aliasobjekt lesen oder dorthin schreiben, wirken sich die Operationen auf das ursprüngliche Objekt aus, mit dem der Alias verbunden ist. Wie bei normalen Objekten wird dann, wenn ein Aliasobjekt erstellt wird, es für die aktivierte Rolle des Benutzers berechtigt.
Zusätzlich zum Aliasobjekt wird eine Gewährung zwischen einer Rolle im Empfängerkonto und der im Teilungsobjekt enthaltenen Rolle erstellt. Dies ist eine Nutzungsgewährung von Rolle zu Rolle quer über Kundenkonten hinweg. Eine rollenbasierte Zugriffssteuerung lässt nun zu, dass ein Benutzer im Empfängerkonto auf Objekte im Anbieterkonto zugreift.
8 ist ein schematisches Blockdiagramm, das logische Gewährungen und Verbindungen bzw. Verknüpfungen zwischen unterschiedlichen Konten darstellt. Ein Datenbank-Aliasobjekt D5 ist in einem Konto A2 erstellt. Der Datenbank-Alias D5 verweist über eine Verbindung bzw. einen Link L1 auf eine Datenbank D2. Eine Rolle R3 hat eine Verwendungsberechtigung bzw. -gewährung G1 an der Datenbank D5. Die Rolle R3 hat eine zweite Verwendungsberechtigung G2 zu einer Rolle R4 im Kundenkonto A1. Die Berechtigung G2 ist ein kontoübergreifender Berechtigung zwischen den Konten A1 und A2. Bei einer Ausführungsform lässt eine rollenbasierte Zugriffssteuerung zu, dass ein Benutzer im Konto A2 mit aktivierter Rolle R3 auf Daten im Konto A1 zugreift. Wenn zum Beispiel ein Benutzer im Konto A2 Daten in einer Tabelle T2 lesen möchte, lässt die rollenbasierte Zugriffssteuerung dies zu, weil die Rolle R3 eine Verwendungsberechtigung der Rolle R4 hat und die Rolle R4 wiederum eine Auswahlberechtigung an der Tabelle T2 hat. Anhand einer Veranschaulichung kann ein Benutzer mit aktivierter Rolle R3 auf T2 zugreifen, indem er eine Abfrage oder eine Auswahl ausführt, die auf „D5.S2.T2“ gerichtet ist.
Ein Verwenden von Objektaliasen und kontoübergreifenden Berechtigungen von einer Rolle im Empfängerkonto zu einer Rolle im Anbieterkonto lässt zu, dass Benutzer im Empfängerkonto auf Information im Anbieterkonto zugreifen. Auf diese Weise kann ein Datenbanksystem ein Teilen von Daten zwischen unterschiedlichen Kundenkonten auf eine sofortige, kopierfreie und leicht kontrollierbare Weise ermöglichen. Das Teilen kann sofort erfolgen, da Aliasobjekte und kontoübergreifende Berechtigungen in Millisekunden erstellt werden können. Das Teilen kann kopierfrei sein, da beim Prozess keine Daten dupliziert werden müssen. Zum Beispiel können alle Abfragen oder Auswahlen direkt an das gemeinsam genutzte Objekt im Anbieterkonto vorgenommen werden, ohne ein Duplikat im Empfängerkonto zu erstellen. Das Teilen ist auch einfach zu steuern, da es einfach zu verwendende Techniken einer rollenbasierten Zugriffssteuerung verwendet. Zusätzlich gibt es bei Ausführungsformen mit getrennter Speicherung und Berechnung keinen Wettstreit bzw. Konflikt zwischen Computerressourcen beim Ausführen von Abfragen an gemeinsam genutzten Daten. Somit können unterschiedliche virtuelle Lager in unterschiedlichen Kundenkonten gemeinsam genutzte Daten einzeln bzw. individuell verarbeiten. Zum Beispiel kann ein erstes virtuelles Lager für ein erstes Konto eine Datenbankabfrage oder -anweisung unter Verwendung von durch ein Anbieterkonto gemeinsam genutzten Daten verarbeiten und kann ein zweites virtuelles Lager für ein zweites Konto, oder das Anbieterkonto, eine Datenbankabfrage oder -anweisung unter Verwendung der gemeinsam genutzten Daten des Anbieterkontos verarbeiten.
9 ist ein schematisches Blockdiagramm einer Teilungskomponente 210. Die Teilungskomponente 210 enthält eine Komponente für kontoübergreifende Rechte 902, eine Aliaskomponente 904, eine Anforderungskomponente 906, eine Zugriffskomponente 908, eine Verarbeitungskomponente 910, eine Komponente für eine sichere Ansicht 912 und eine Komponente für eine materialisierte Ansicht 914. Die Komponenten 902-914 sind nur anhand eines Beispiels angegeben und es kann sein, dass nicht alle in allen Ausführungsformen enthalten sind. Zum Beispiel kann jede der Komponenten 902-914 in einer separaten Vorrichtung oder einem System enthalten sein oder als Teil davon implementiert sein.
Die Komponente für kontoübergreifende Rechte 902 ist konfiguriert, um Rechte oder Berechtigungen zwischen Konten zu erstellen und zu managen. Die Komponente für kontoübergreifende Rechte 902 kann ein Teilungsobjekt in einem Anbieterkonto erzeugen. Zum Beispiel kann ein Benutzer des Anbieterkontos eine Eingabe bereitstellen, die anzeigt, dass eine oder mehrere Ressourcen mit einem anderen Konto geteilt werden sollte oder sollten. Bei einer Ausführungsform kann der Benutzer eine Option auswählen, um ein neues Teilungsobjekts zu erstellen, so dass Ressourcen mit fremden Konten geteilt werden können. In Reaktion auf die Benutzereingabe kann die Komponente für kontoübergreifende Rechte 902 ein Teilungsobjekt im Anbieterkonto erstellen. Das Teilungsobjekt kann eine Rolle enthalten, für die Zugriffsrechte auf Ressourcen zum Teilen mit einem fremden Konto gewährt werden können. Das fremde Konto kann ein Kundenkonto oder ein anderes Konto enthalten, das vom Anbieterkonto getrennt ist. Zum Beispiel kann das fremde Konto ein anderes auf einem mehrmandantenfähigen Datenbanksystem gehostetes Konto sein.
Auf eine Erstellung hin können dem Teilungsobjekt Rechte zu einer oder mehreren Ressourcen innerhalb des Anbieterkontos gewährt werden. Die Ressourcen können eine Datenbank, ein Schema, eine Tabelle, eine Sequenz oder eine Funktion des Anbieterkontos enthalten. Zum Beispiel kann das Teilungsobjekt eine Rolle (d.h. eine Teilungsrolle) enthalten, der ein Recht gewährt wird, ein Datenspeicherobjekt, wie beispielsweise eine Datenbank, zu lesen, auszuwählen, abzufragen oder zu modifizieren. Dem Teilungsobjekt oder der Teilungsrolle im Teilungsobjekt können Rechte ähnlich dazu gewährt werden, wie Rechte anderen Rollen gewährt werden können, und zwar unter Verwendung einer rollenbasierten Zugriffssteuerung. Ein Benutzer kann dazu fähig sein, auf ein Konto zuzugreifen und der Teilungsrolle Rechte gewähren, so dass die Teilungsrolle auf Ressourcen zugreifen kann, für die beabsichtigt ist, dass sie mit fremden Konten geteilt werden. Bei einer Ausführungsform kann das Teilungsobjekt eine Liste von Objekten enthalten, und eine Zugriffsebene, für die die Teilungsrolle Rechte hat.
Das Teilungsobjekt kann auch spezifischen fremden Konten zur Verfügung gestellt oder damit verbunden werden. Zum Beispiel kann das Teilungsobjekt eine Liste von Konten speichern, die Rechte zu der Teilungsrolle oder dem Teilungsobjekt im Anbieterkonto haben. Ein Benutzer mit dem Anbieterkonto kann Konten zu der Liste von Konten hinzufügen oder diese entfernen. Zum Beispiel kann der Benutzer dazu fähig sein, die Liste zu modifizieren, um zu steuern, welche Konten auf über das Teilungsobjekt geteilte Objekte zugreifen können. Fremden Konten, die im Teilungsobjekt aufgelistet oder identifiziert sind, kann ein Zugriff auf Ressourcen mit Zugriffsrechten zugeteilt werden, die einer Teilungsrolle des Teilungsobjekts gewährt sind. Bei einer Ausführungsform kann ein spezifisches Konto eine Suche durchführen, um Teilungsobjekte oder Anbieterkonten zu identifizieren, die mit dem spezifischen Konto geteilt worden sind. Eine Liste von verfügbaren Teilungsobjekten kann von einem Benutzer des Empfängers oder eines spezifischen Kontos angeschaut werden.
Die Alias-Komponente 904 ist konfiguriert, um ein Alias für Daten oder ein Datenobjekt zu erzeugen, die oder das von einem separaten Konto gemeinsam genutzt werden oder wird. Zum Beispiel kann das Aliasobjekt in einem Empfängerkonto ein Aliasobjekt erstellen, das einer geteilten Ressource entspricht, die von einem Anbieterkonto gemeinsam genutzt wird. Bei einer Ausführungsform wird das Aliasobjekt in Reaktion darauf erstellt, dass ein Empfängerkonto eine geteilte Ressource akzeptiert oder versucht, zum ersten Mal auf eine geteilte Ressource zuzugreifen. Das Aliasobjekt kann als Alias für ein Datenobjekt für die höchste Objekthierarchie wirken, die vom Anbieterkonto geteilt bzw. gemeinsam genutzt wird (siehe z.B. 8, wo D5 ein Alias für D2 ist). Die Alias-Komponente 904 kann auch eine Verbindung zwischen dem Aliasobjekt und einem gemeinsam genutzten bzw. geteilten Objekt erzeugen (siehe z.B. 8, wo L1 die Verbindung zwischen D5 und D2 ist). Die Verbindung bzw. der Link kann in der Form eines Identifizierers oder eines Namens des ursprünglichen oder „echten“ bzw. „realen“ Objekts erstellt und/oder gespeichert werden. Zum Beispiel kann die Verbindung bzw. der Link L1 in 8 einen Identifizierer für D2 enthalten, gespeichert im Aliasobjekt D5, was einen eindeutigen systemweiten Namen enthält, wie beispielsweise „A1.D2“.
Die Alias-Komponente 904 kann einer Rolle im Empfängerkonto (dem Konto, mit dem das Anbieterkonto Daten oder Ressourcen geteilt hat) auch Zugriffsrechte auf das Aliasobjekt gewähren (siehe z.B. G1 der 8). Zusätzlich kann die Alias-Komponente 904 die Rolle im Empfängerkonto auch zu einer Teilungsrolle im Teilungsobjekt des Anbieterkontos berechtigen (siehe z.B. G2 der 8). Mit dem erstellten Aliasobjekt, einer Verbindung zwischen dem Aliasobjekt und einem Objekt im Anbieterkonto und Berechtigungen zu einer Rolle im Empfängerkonto kann das Empfängerkonto frei sein, Abfragen, Anweisungen auszuführen oder geteilte Daten oder Ressourcen im Anbieterkonto „zu sehen“.
Die Anforderungskomponente 906 ist konfiguriert, um eine Anforderung von einem Konto zu empfangen, um auf eine geteilte Ressource in einem anderen Konto zuzugreifen. Die Anforderung kann eine Datenbankabfrage, eine Auswahlanweisung oder ähnliches, um auf eine Ressource zuzugreifen, enthalten. Bei einer Ausführungsform enthält die Anforderung eine Anforderung, die zu einem Aliasobjekt des anfordernden Kontos gerichtet ist. Die Anforderungskomponente 906 kann eine Ressource identifizieren, mit der das Aliasobjekt verbunden ist, wie beispielsweise eine Datenbank oder Tabelle in einem Anbieterkonto. Die Anforderungskomponente 906 kann das verbundene Objekt basierend auf einem Identifizierer des Aliasobjekts identifizieren.
Die Anforderungskomponente 906 kann weiterhin konfiguriert sein, um eine Anforderung von einem Konto zu empfangen, um gemeinsame Datenpunkte zwischen zwei Konten zu zählen. Die Anforderungskomponente 906 kann mit einem ersten Konto assoziiert sein und kann eine Anforderung von einem zweiten Konto empfangen, um eine sichere Verbindung zwischen den zwei Konten zu erzeugen und zu bestimmen, wie viele und welche Datenpunkte zwischen den zwei Konten gemeinsam genutzt bzw. geteilt werden. Die Datenpunkte können von einem einzelnen Gegenstand oder einem Spaltenidentifizierer sein oder können von mehreren Gegenständen sein.
Die Zugriffskomponente 908 ist konfiguriert, um zu bestimmen, ob ein Konto Zugriff auf eine geteilte Ressource eines anderen Kontos hat. Wenn zum Beispiel ein erstes Konto einen Zugriff auf eine Ressource eines anderen, zweiten, Kontos anfordert, kann die Zugriffskomponente 908 bestimmen, ob das zweite Konto Zugriff auf das erste Konto gewährt hat. Die Zugriffskomponente 908 kann bestimmen, ob ein anforderndes Konto Zugriff hat, indem sie bestimmt, ob ein Teilungsobjekt das anfordernde Konto identifiziert. Zum Beispiel kann die Zugriffskomponente 908 prüfen, ob das anfordernde Konto in einer Liste von Konten vorhanden ist, die durch ein Teilungsobjekt gespeichert sind. Die Zugriffskomponente 908 kann auch prüfen, ob das Teilungsobjekt, das das anfordernde Konto identifiziert, Zugriffsrechte (z.B. Berechtigungen) auf die Empfängerdatenressource im Anbieterkonto hat.
Bei einer Ausführungsform kann die Zugriffskomponente 908 auf das Vorhandensein einer Gewährung bzw. Berechtigung von einer Teilungsrolle in einem Anbieterkonto zu einer anfordernden Rolle im anfordernden Konto prüfen. Die Zugriffskomponente 908 kann prüfen, ob eine Verbindung zwischen einem Aliasobjekt, zu dem eine Datenbankanforderung oder -anweisung gerichtet wurde, existiert oder ob eine Berechtigung zwischen einer anfordernden Rolle und dem Aliasobjekt existiert. Zum Beispiel kann die Zugriffskomponente 908 auf die Existenz oder das Vorhandensein von einem oder mehreren von L1, G1 und G2 prüfen, die in 8 dargestellt sind. Weiterhin kann die Zugriffskomponente 908 auf eine Gewährung bzw. Berechtigung zwischen einer Rolle in einem Teilungsobjekt zu einem Objekt (wie beispielsweise einer Tabelle oder Datenbank) des Anbieterkontos prüfen. Zum Beispiel kann die Zugriffskomponente 908 auf die Existenz einer Gewährung zwischen der Rolle R4 und der Datenbank D2 in 8 prüfen. Wenn die Zugriffskomponente 908 bestimmt, dass das anfordernde Konto Zugriff auf die geteilte Ressource hat, kann die Anforderung durch die Teilungskomponente 210 oder eine Verarbeitungskomponente 910 erfüllt werden. Wenn die Zugriffskomponente 908 bestimmt, dass das anfordernde Konto keine Rechte zu den angeforderten Daten oder dem Objekt hat, wird die Anforderung abgelehnt werden.
Die Verarbeitungskomponente 910 ist konfiguriert, um Datenbankanforderungen, -abfragen oder -anweisungen zu verarbeiten. Die Verarbeitungskomponente 910 kann eine Reaktion auf eine Anforderung von einem Kontos verarbeiten und bereitstellen, auf Daten oder Dienste in einem anderen Konto zuzugreifen oder diese zu nutzen. Bei einer Ausführungsform liefert die Verarbeitungskomponente 910 eine Reaktion bzw. Antwort auf eine Anforderung bzw. Anfrage, indem sie die Anforderung unter Verwendung von ursprünglichen Daten in einem Anbieterkonto verarbeitet, das sich vom anfordernden Konto unterscheidet. Zum Beispiel kann die Anforderung in Richtung zu einer Datenbank oder Tabelle gerichtet sein, die in einem ersten Konto oder für dieses gespeichert ist, und die Verarbeitungskomponente 910 kann die Anforderung unter Verwendung der Datenbank oder Tabelle des ersten Kontos verarbeiten und eine Antwort zu einem anfordernden, zweiten Konto zurückbringen.
Bei einer Ausführungsform führt die Verarbeitungskomponente 910 ein Verarbeiten von geteilten Daten durch, ohne eine duplizierte Tabelle oder eine andere Datenquelle im anfordernden Konto zu erstellen. Allgemein müssen Daten zuerst in ein Konto aufgenommen werden, das wünscht, diese Daten zu verarbeiten oder Operationen gegenüber den Daten durchzuführen. Die Verarbeitungskomponente 910 kann Verarbeitungszeit, Verzögerung und/oder Speicherressourcen einsparen, indem sie zulässt, dass ein Empfängerkonto auf geteilte Ressourcen in einem Anbieterkonto zugreift, ohne eine Kopie einer Datenressource im Empfängerkonto zu erstellen.
Die Verarbeitungskomponente 910 kann eine Verarbeitung derselben Daten unter Verwendung unterschiedlicher Verarbeitungsressourcen für unterschiedliche Konten durchführen. Zum Beispiel kann ein erstes virtuelles Lager für ein erstes Konto eine Datenbankabfrage oder -anweisung unter Verwendung von Daten, die von einem Anbieterkonto geteilt sind, verarbeiten und kann ein zweites virtuelles Lager für ein zweites Konto, oder das Anbieterkonto, eine Datenbankabfrage oder -anweisung unter Verwendung der geteilten Daten des Anbieterkontos verarbeiten. Ein Verwenden separater Verarbeitungsressourcen, um dieselben Daten zu verarbeiten, kann einen Konflikt für Verarbeitungsressourcen zwischen Konten verhindern. Die Verarbeitungsressourcen können dynamisch bereitgestellte Verarbeitungsressourcen enthalten. Bei einer Ausführungsform wird eine Verarbeiten geteilter Daten unter Verwendung eines virtuellen Lagers für das anfordernde Konto durchgeführt, auch wenn die Daten in einem Speicher für ein anderes Konto sein können.
Die Komponente für eine sichere Ansicht 912 ist konfiguriert, um eine sichere Ansicht für ein Teilungsobjekt, ein Datenfeld eines Teilungsobjekts, ein Datenfeld eines Datenbankobjekts und so weiter zu definieren. Bei einer Ausführungsform definiert die Komponente für eine sichere Ansicht 912 die sichere Ansicht mit einem SECURE(=SICHER)-Schlüsselwort in einem Ansichtsfeld und kann die SECURE(=SICHER)-Eigenschaft auf einer Ansicht unter Verwendung eines Befehls ALTER VIEW (=ANSICHT ÄNDERN) festlegen oder aufheben. Bei verschiedenen Ausführungsformen kann die Komponente für eine sichere Ansicht 912 solche Befehle nur bei der manuellen Anleitung eines Kundenkontos implementieren, oder sie kann konfiguriert sein, um solche Befehle automatisch zu implementieren. Die Komponente für eine sichere Ansicht 912 kann den Parser ändern, um das Secure-Schlüsselwort bzw. sichere Schlüsselwort vor dem Ansichtsnamen und der neuen Änderungsansichtsregel zu unterstützen. Bei einer Ausführungsform kann die Änderungsansichtsregel allgemeiner sein, um weitere Attribute auf Ansichtsebene zu enthalten. Im Hinblick auf eine Metadatenunterstützung können die Ansichten effektiv als Tabellen gespeichert werden und kann die Änderung ein Ändern eines Persistenzobjekts für Tabellendaten beinhalten, das ein sicheres Flag enthält, das anzeigt, ob die Ansicht eine sichere Ansicht ist (dies kann zusätzlich zu dem das sichere Tag umfassenden Ansichtstext implementiert sein). Die sichere benutzerdefinierte Funktionsdefinition (d.h. das Persistenzobjekt für Tabellendaten) kann vor Benutzern verborgen sein, die nicht der Eigentümer bzw. Besitzer der Ansicht sind. Bei einer solchen Ausführungsform wird ein Befehl, um Ansichten zu zeigen, Ergebnisse wie gewohnt zum Eigentümer der Ansicht zurückbringen, wird aber nicht die sichere benutzerdefinierte Funktionsdefinition zu einem zweiten Konto nicht vom Eigentümer, das Zugriff auf die Ansicht hat.
Die Komponente für eine sichere Ansicht 912 kann Transformationen eines Parsebaums ändern, wie z.B. eine Ansichtsverknüpfung bzw. -zusammenführung und Prädikat-Information. Die kanonische Implementierung kann ein Kommentieren von Abfrageblöcken enthalten, so dass die Abfrageblöcke als von einer sicheren Ansicht kommend bezeichnet sind. Bei einer solchen Implementierung können die Abfrageblöcke nicht mit externen Abfrageblöcken (z.B. Ansichtszusammenführung) oder Ausdrücken (z.B. über einen Filter-Pushdown) kombiniert werden.
Die Komponente für eine sichere Ansicht 912 kann den Abfrageplanbaum während einer Optimierung neu schreiben, z.B. während eines Filter-Pullups und/oder eines Filter-Pushdowns. Die Komponente für eine sichere Ansicht 912 kann konfiguriert sein, um sicherzustellen, dass kein Ausdruck, der nicht aus einer sicheren Ansicht stammt, unter die Ansichtsgrenzen gedrückt werden kann. Die Komponente für eine sichere Ansicht 912 kann konfiguriert sein, um dies durch Implementieren eines neuen Projektionstyps zu erreichen, der sich identisch zu einer Standardprojektion verhält, aber deshalb, weil er keine Standardprojektion ist, diesbezüglich fehlschlägt, zu irgendeiner der Regelvoraussetzungen für ein neues Schreiben zu passen. Als Ergebnis werden die relevanten Umschreibungen bzw. neuen Schreibungen nicht angewendet. Die Komponente für eine sichere Ansicht 912 kann konfiguriert sein, um zu identifizieren, welcher Projektionstyp zu erzeugen ist (z.B. eine Standardprojektion oder eine sichere Projektion), nachdem Abfrageblöcke als von einer sicheren benutzerdefinierten Funktionsdefinition stammend bezeichnet worden sind oder nicht.
Die Komponente für eine sichere Ansicht 912 ist konfiguriert, um eine Leistungsfähigkeit für sichere Ansichten in einem kopierfreien Datenteilungssystem zu optimieren. Bei verschiedenen auf dem Gebiet bzw. im Stand der Technik bekannten Ausführungsformen sind sichere Ansichten bekannt, die Verlust an Leistungsfähigkeit verursachen, der den Optimierer bezüglich eines Anwendens bestimmter Transformationen effektiv lähmen kann. Solche Ausführungsformen könnten verbessert werden, indem bestimmte Transformationen als sicher angesehen werden, wobei Sicherheit anzeigt, dass die Operationen, die transformiert werden, keinerlei Nebenwirkungen auf das System haben werden. Solche Nebenwirkungen können durch eine benutzerdefinierte Funktion (UDF (= User Defined Function)) verursacht werden, die Operationen durchführt, die unsichere Operationen nicht ohne weiteres identifizieren können, oder Operationen, die fehlschlagen und Information über den Datenwert offenlegen können, der den Fehler verursachte (z.B. beim Teilen durch Null oder irgendeiner ähnlichen Operation). Die Komponente für eine sichere Ansicht 912 kann Ausdrücke mit den Sicherheitseigenschaften des Ausdrucks kommentieren und dann Transformationen ermöglichen, die zulassen, dass ein Ausdruck durch eine Grenze einer sicheren Ansicht hindurchgedrückt wird, wenn der Ausdruck als sicher angesehen wird. Der Ausdruck kann als sicher angesehen werden, wenn bekannt ist, dass der Ausdruck keine Fehler erzeugt und der Ausdruck keine benutzerdefinierte Funktion (UDF (= User Defined Function)) enthält. Die Komponente für eine sichere Ansicht 912 kann bestimmen, ob der Ausdruck Fehler erzeugt, indem ein Framework für Ausdruckseigenschaften verwendet wird, wobei die Ausdruckseigenschaften einen Hinweis darauf speichern, ob ein Ausdruck Fehler erzeugen kann.
Die Komponente für materialisierte Ansicht 914 ist konfiguriert, um eine materialisierte Ansicht über geteilte Daten zu erzeugen und/oder zu aktualisieren bzw. upzudaten. Die Komponente für materialisierte Ansicht 914 ist weiterhin konfiguriert, um eine materialisierte Ansicht zuteilen, die eine Definition einer sicheren Ansicht haben kann. Die Komponente für materialisierte Ansicht 914 kann in Ausführungsressourcen integriert sein, die dem Anbieterkonto und/oder dem Empfängerkonto zugeteilt sind. Bei einer Ausführungsform autorisiert das Anbieterkonto ein Empfängerkonto, die Daten des Anbieterkontos anzuschauen. Das Anbieterkonto kann dem Empfängerkonto unbegrenzten Zugriff geben, um die Daten des Anbieterkontos anzuschauen, oder das Anbieterkonto kann dem Empfängerkonto die Autorisierung gewähren, seine Daten anzuschauen, und zwar mit einer Definition einer sicheren Ansicht. Die Definition einer sicheren Ansicht kann sicherstellen, dass nur Teilbereiche der Daten für das Empfängerkonto sichtbar sind und/oder dass kein zugrunde liegendes Schema über die Daten für das Empfängerkonto sichtbar ist. Bei einer Ausführungsform stellt das Anbieterkonto dem Empfängerkonto eine Autorisierung zur Verfügung, um eine bestimmte materialisierte Ansicht zu erzeugen, die über die Daten des Anbieters erzeugt wird. Das Anbieterkonto kann diese Autorisierung gewähren und dem Empfängerkonto dennoch verbieten, irgendwelche der tatsächlichen bzw. aktuellen Daten anzuschauen.
Die Komponente für materialisierte Ansicht 914 erzeugt die materialisierte Ansicht und frischt sie auf. Bei einer Ausführungsform erzeugt das Anbieterkonto die materialisierte Ansicht über seine eigenen Daten. Die Komponente für materialisierte Ansicht 914 kann die materialisierte Ansicht für das Anbieterkonto erzeugen. Die Komponente für materialisierte Ansicht 914 kann dem Empfängerkonto weiterhin kontoübergreifende Zugriffsrechte gewähren, so dass das Empfängerkonto die materialisierte Ansicht anschauen kann. Bei einer Ausführungsform fordert das Empfängerkonto die materialisierte Ansicht an und erzeugt die Komponente für materialisierte Ansicht 914 die materialisierte Ansicht. Bei einer solchen Ausführungsform kann die Komponente für materialisierte Ansicht in die Ausführungsplattform des Empfängerkontos integriert sein.
Die Komponente für materialisierte Ansicht 914 frischt die materialisierte Ansicht in Bezug auf ihre Quellentabelle auf. Bei einer Ausführungsform wird die materialisierte Ansicht von einem Empfängerkonto erzeugt und gespeichert und wird die Quellentabelle für die materialisierte Ansicht vom Anbieterkonto gespeichert und gemanagt. Wenn eine Aktualisierung an den Daten in der Quellentabelle vorgenommen wird, ist die Komponente für materialisierte Ansicht 914 konfiguriert, um die materialisierte Ansicht aufzufrischen, um die Aktualisierung zur materialisierten Ansicht auszubreiten bzw. weiterzugeben. Wenn die Quellentabelle aktualisiert worden ist und diese Aktualisierungen noch nicht zur materialisierten Ansicht weitergegeben worden ist, dann ist die materialisierte Ansicht in Bezug auf ihre Quellentabelle veraltet. Gemäß den hierin offenbarten Systemen, Verfahren und Vorrichtungen können Abfragen noch unter Verwendung einer veralteten materialisierten Ansicht ausgeführt werden, indem die materialisierte Ansicht mit ihrer Quellentabelle zusammengeführt bzw. verknüpft wird, um irgendwelche Diskrepanzen zwischen der materialisierten Ansicht und der Quellentabelle zu identifizieren. Die Komponente für materialisierte Ansicht 914 ist konfiguriert, um die materialisierte Ansicht mit ihrer Quellentabelle zu verknüpfen, um zu identifizieren, ob seit einer letzten Auffrischung der materialisierten Ansicht irgendwelche Aktualisierungen an der Quellentabelle vorgenommen worden sind.
Die Komponente für materialisierte Ansicht 914 ist konfiguriert, um eine materialisierte Ansicht gemeinsam zu nutzen bzw. zu teilen. Bei einer Ausführungsform teilt die Komponente für materialisierte Ansicht 914 eine materialisierte Ansicht mit einem anderen Konto in einer mehrmandantenfähigen Datenbank. Die Komponente für materialisierte Ansicht 914 kann veranlassen, dass die materialisierte Ansicht in Bezug auf ihre Quellentabelle automatisch aufgefrischt wird, so dass die geteilte Version der materialisierten Ansicht in Bezug auf Daten in der Quellentabelle auf dem neuesten Stand ist. Die materialisierte Ansicht kann mit dem anderen Konto geteilt werden, so dass das andere Konto nur Einblick in die in der materialisierten Ansicht enthaltenen Zusammenfassungsinformation hat und keinen Einblick in die Quellentabelle für die materialisierte Ansicht oder irgendein zugrunde liegendes Schema, Daten, Metadaten und so weiter hat.
10 ist ein schematisches Diagramm eines Systems 1000 zum Erzeugen einer materialisierten Ansicht über gemeinsam genutzte bzw. geteilte Daten. Die materialisierte Ansicht wird über gespeicherten Daten erzeugt, die mit einem Konto eines Providers bzw. Anbieters 1002 assoziiert sind. Das Konto des Anbieters 1002 enthält eine Anbieter-Ausführungsplattform 1004, die zum Ausführen von Aufgaben an den Daten des Anbieters 1002 konfiguriert ist. Auf die Daten des Anbieters 1002 wird von einem Konto eines Empfängers 1006 durch die Empfänger-Ausführungsplattform 1008 über ein Teilungsobjekt 1010 zugegriffen. Es sollte eingesehen werden, dass die Ausdrücke „Anbieter“ und „Empfänger“ nur zur Veranschaulichung dienen und alternativ als ein erstes Konto und ein zweites Konto, als ein Anbieter und ein Verbraucher und so weiter bezeichnet werden können. Eine materialisierte Ansicht 1012 kann über Daten in Daten des Teilungsobjekts 1010 entweder vom Anbieter 1002 oder vom Empfänger 1006 erzeugt werden. Eine Analyse basierend auf der materialisierten Ansicht 1014 kann entweder vom Anbieter 1002 oder vom Empfänger 1006 durchgeführt werden.
Bei einer Ausführungsform sind der Anbieter 1002 und der Empfänger 1006 unterschiedliche Konten, die mit demselben cloudbasierten Datenbankadministrator assoziiert sind. Bei einer Ausführungsform sind der Anbieter 1002 und der Empfänger 1006 mit unterschiedlichen cloudbasierten und/oder traditionellen Datenbanksystemen assoziiert. Der Anbieter 1002 enthält eine Anbieter-Ausführungsplattform 1004 mit einem oder mehreren Ausführungsknoten, die ein Verarbeiten von Aufgaben an den Datenbankdaten des Anbieters 1002 ausführen können, wobei die Datenbankdaten in einem mit dem Anbieter 1002 assoziierten Datenspeicher gespeichert sind. Auf ähnliche Weise enthält der Empfänger 1006 eine Empfänger-Ausführungsplattform 1008 mit einem oder mehreren Ausführungsknoten, die ein Verarbeiten von Aufgaben an den Datenbankdaten des Empfängers 1006 auszuführen können, wobei die Datenbankdaten auf einem mit dem Empfänger 1006 assoziierten Datenspeicher gespeichert sind. Der Datenspeicher kann einen cloudbasierten skalierbaren Speicher enthalten, so dass die Datenbankdaten über eine Vielzahl von gemeinsam genutzten Speichervorrichtungen verteilt sind, auf die durch eine Ausführungsplattform wie 1004 oder 1008 zugegriffen werden kann. Die materialisierte Ansicht 1012 wird entweder vom Anbieter 1002 oder vom Empfänger 1006 erzeugt. Wenn die materialisierte Ansicht 1012 vom Anbieter 1002 erzeugt wird, kann die Anbieter-Ausführungsplattform 1004 direkt auf Daten des Anbieters 1002 zugreifen. Wenn die materialisierte Ansicht 1012 vom Empfänger 1006 erzeugt wird, kann die Empfänger-Ausführungsplattform 1008 die materialisierte Ansicht 1012 durch Lesen von Daten im Teilungsobjekt 1010 erzeugen. Die Daten im Teilungsobjekt 1010 sind Eigentum des Anbieters 1002 und werden dem Empfänger 1006 zugänglich gemacht. Die Daten im Teilungsobjekt 1010 können eine Definition einer sicheren Ansicht haben.
Bei einer Ausführungsform ist das Teilungsobjekt 1010 durch den Anbieter 1002 definiert und dem Empfänger 1006 zur Verfügung gestellt. Das Teilungsobjekt 1010 ist ein sofortiges und kopierfreies Mittel für den Empfänger 1006, um auf Daten oder andere Objekte im Besitz des Anbieters 1002 zuzugreifen. Das Teilungsobjekt 1010 kann Daten, eine Tabelle, eine oder mehrere Mikropartitionen einer Tabelle, eine materialisierte Ansicht, eine Funktion, eine benutzerdefinierte Funktion, ein Schema und so weiter sein. Das Teilungsobjekt 1010 kann von der Anbieter-Ausführungsplattform 1004 definiert und der Empfänger-Ausführungsplattform 1008 zugänglich gemacht werden. Das Teilungsobjekt 1010 kann nur lesenden (und nicht schreibenden) Zugriff auf Daten des Anbieters 1002 bereitstellen, so dass die Empfänger-Ausführungsplattform 1008 Daten des Anbieters 1002 lesen kann, aber die Daten des Anbieters 1002 nicht aktualisieren oder etwas zu diesen hinzufügen kann. Das Teilungsobjekt 1010 kann eine Definition einer sicheren Ansicht enthalten, so dass die Empfänger-Ausführungsplattform 1008 zugrunde liegende Daten in der Basistabelle im Besitz des Anbieters 1002 nicht sehen kann.
Die materialisierte Ansicht 1012 kann entweder vom Anbieter 1002 und/oder vom Empfänger 1006 erzeugt werden. Der Anbieter 1002 kann eine materialisierte Ansicht direkt über seine im Festplatten- oder Cachespeicher gespeicherten Daten erzeugen. Der Anbieter 1002 kann die materialisierte Ansicht 1012 dem Empfänger 1006 direkt und/oder über das Teilungsobjekt 1010 zur Verfügung stellen. Die materialisierte Ansicht 1012 kann eine Definition einer sicheren Ansicht haben, so dass zugrunde liegende Daten von anderen Konten (einschließlich des Empfängers 1006) nicht gesehen werden können, aber das Ergebnis der materialisierten Ansicht gesehen werden kann. Der Empfänger 1006 kann die materialisierte Ansicht über Daten im Teilungsobjekt 1010 erzeugen. Bei einer Ausführungsform wird der Anbieter 1002 benachrichtigt, wenn ein anderes Konto, wie beispielsweise der Empfänger 1006, eine materialisierte Ansicht 1012 über Daten des Anbieters 1002 erzeugt. Bei einer Ausführungsform wird der Anbieter 1002 nicht benachrichtigt, wenn ein autorisiertes Konto des Empfängers 1006 eine materialisierte Ansicht 1012 über Daten innerhalb eines Teilungsobjekts 1010 erzeugt.
11 stellt ein schematisches Blockdiagramm eines Verfahrens- bzw. Prozessablaufs 1100 zum inkrementellen Aktualisieren bzw. Updaten einer materialisierten Ansicht dar. Der Prozessablauf 1100 kann von irgendeiner geeigneten Computervorrichtung ausgeführt werden, einschließlich zum Beispiel eines Computing-Service-Managers 1402 (siehe 14) und/oder einer Teilungskomponente 210. Der Prozessablauf 1100 enthält ein Erstellen einer materialisierten Ansicht bei 1102, wobei die materialisierte Ansicht auf einer Quellentabelle basiert. Der Prozessablauf 1100 umfasst ein Aktualisieren bzw. Updaten der Quellentabelle bei 1104, was ein Einfügen einer neuen Mikropartition in die Quellentabelle bei 1106 und/oder ein Entfernen einer gelöschten Mikropartition aus der Quellentabelle bei 1108 enthalten kann. Der Prozessablauf 1100 enthält ein Abfragen der materialisierten Ansicht und der Quellentabelle bei 1110. Ein Abfragen bei 1110 enthält ein Erkennen, ob irgendwelche Updates an der Quellentabelle aufgetreten sind, die in der materialisierten Ansicht nicht widergespiegelt bzw. berücksichtigt sind. Zum Beispiel kann eine neue Mikropartition zur Quellentabelle hinzugefügt sein, die der materialisierten Ansicht nicht hinzugefügt worden ist. Eine gelöschte Mikropartition kann aus der Quellentabelle entfernt sein, die noch in der materialisierten Ansicht verbleibt. Der Prozessablauf 1100 enthält ein Anwenden des Updates auf die materialisierte Ansicht bei 1112. Ein Anwenden des Updates 1112 kann ein Auffrischen der materialisierten Ansicht durch Einfügen der neuen Mikropartition in die materialisierte Ansicht bei 1114 und/oder ein Kompaktieren der materialisierten Ansicht durch Entfernen der gelöschten Mikropartition bei 1116 enthalten.
12 stellt ein schematisches Blockdiagramm eines beispielhaften Prozessablaufs 1200 zum inkrementellen Aktualisieren bzw. Updaten einer materialisierten Ansicht dar. Der Prozessablauf 1200 kann von irgendeiner geeigneten Computervorrichtung ausgeführt werden, einschließlich zum Beispiel eines Computing-Service-Managers 1402 (siehe 14) und/oder einer Teilungskomponente 210. Der Prozessablauf 1200 enthält ein Erzeugen einer materialisierten Ansicht bei 1202, die auf einer Quellentabelle basiert. Der Prozessablauf 1200 enthält ein Updaten der Quellentabelle bei 1204, was ein Einfügen einer Mikropartition bei 1206 und/oder ein Entfernen einer Mikropartition bei 1208 enthalten kann. Der Prozessablauf enthält ein Abfragen der materialisierten Ansicht und der Quellentabelle bei 1210, um Updates der Quellentabelle zu erkennen, die in der materialisierten Ansicht nicht widergespiegelt bzw. berücksichtigt sind. Der Prozessablauf 1200 enthält ein Anwenden des Updates auf die materialisierte Ansicht bei 1212.
Bei einer Ausführungsform ist die Quellentabelle im Besitz bzw. Eigentum eines Anbieterkontos und wird die materialisierte Ansicht bei 1202 von einem Empfängerkonto erzeugt. Die Quellentabelle kann quer über eine oder mehrere einer Vielzahl von gemeinsam genutzten Speichervorrichtungen gespeichert werden, die unter mehreren Konten in einem mehrmandantenfähigen Datenbanksystem gemeinsam genutzt bzw. geteilt werden. Das Anbieterkonto und das Empfängerkonto können jeweils Datenbankdaten innerhalb des Datenbanksystems speichern und managen. Das Anbieterkonto kann Datenbankdaten innerhalb des Datenbanksystems speichern und managen und das Empfängerkonto kann mit dem Datenbanksystem einzig zum Anschauen und/oder Abfragen von Daten verbunden sein, die im Besitz anderer Konten sind und/oder von diesen gemanagt werden, ohne irgendwelche eigene Daten zu speichern. Mit jedem des Anbieterkontos und des Empfängerkontos können separate Ausführungsressourcen assoziiert sein. Bei einer Ausführungsform ist die Quellentabelle mit dem Anbieterkonto assoziiert. Das Anbieterkonto stellt kontoübergreifende Zugriffsrechte für das Empfängerkonto bereit, so dass das Empfängerkonto die Daten in der Quellentabelle anschauen kann, einen Teilbereich der Daten in der Quellentabelle anschauen kann, eine materialisierte Ansicht über die Quellentabelle erzeugen kann, die Quellentabelle abfragen kann und/oder benutzerdefinierte Funktionen über die Quellentabelle ausführen kann. Das Anbieterkonto kann ein „Teilungsobjekt“ erzeugen, das irgendeines der vorgenannten Zugriffsrechte enthält.
Das Teilungsobjekt kann eine Definition einer sicheren Ansicht haben, so dass Teilbereiche der Quellentabelle vor dem Empfängerkonto verborgen sind. Das Empfängerkonto kann einen uneingeschränkten Zugriff auf die Quellentabelle haben, so dass das Empfängerkonto zugrunde liegende Daten, ein Schema, Organisationsstrukturen und so weiter anschauen kann. Das Empfängerkonto kann einen eingeschränkten Zugriff auf die Quellentabelle haben, so dass das Empfängerkonto nur ein Ergebnis einer Abfrage oder einer materialisierten Ansicht anschauen kann, ohne irgendwelche zugrunde liegenden Daten, ein Schema, Organisationsstrukturen und so weiter anzuschauen. Das Anbieterkonto kann die Zugriffsebene bestimmen, die dem Empfängerkonto gewährt wird, und die spezifischen Parameter des Zugriffs können auf den Typ von in der Quellentabelle gespeicherten Daten und die Anforderungen des Anbieterkontos zugeschnitten werden, um bestimmte Aspekte der Daten vor einem Anschauen verborgen zu halten.
Bei einer Ausführungsform wird die materialisierte Ansicht bei 1202 durch Ausführungsressourcen erzeugt, die dem Empfängerkonto zugeteilt sind, und/oder wird die materialisierte Ansicht von einem Benutzer angefordert, der mit dem Empfängerkonto assoziiert ist. Nachdem das Empfängerkonto das Teilungsobjekt vom Anbieterkonto empfangen hat, kann das Empfängerkonto einen Zugriff haben, um eine materialisierte Ansicht über die Quellentabelle zu erzeugen. Die vom Empfängerkonto erzeugte materialisierte Ansicht kann im Plattenspeicher oder Cachespeicher gespeichert werden, der dem Empfängerkonto zugeteilt ist. Die vom Empfängerkonto erzeugte materialisierte Ansicht kann im Plattenspeicher oder Cachespeicher gespeichert werden, der dem Anbieterkonto zugeteilt ist und dem Empfängerkonto zugänglich gemacht wird.
Bei einer Ausführungsform wird die materialisierte Ansicht bei 1202 durch Ausführungsressourcen erzeugt, die dem Anbieterkonto zugeteilt sind, und/oder wird die materialisierte Ansicht von einem Benutzer angefordert, der mit dem Anbieterkonto assoziiert ist. Die materialisierte Ansicht kann vom Anbieterkonto erzeugt und gemanagt und einem oder mehreren Empfängerkonten zugänglich gemacht werden. Bei einer Ausführungsform ist die materialisierte Ansicht selbst das Teilungsobjekt, auf das von einem oder mehreren Empfängerkonten zugegriffen werden kann.
Ungeachtet dessen, ob das Anbieterkonto oder das Empfängerkonto die materialisierte Ansicht erzeugte oder anforderte, wird die Quellentabelle vom Anbieterkonto bei 1203 aktualisiert bzw. upgedated. Die Quellentabelle kann im Besitz des Anbieterkontos sein und von diesem verwaltet werden und ein oder mehrere Empfängerkonten kann oder können einen nur lesenden Zugriff auf die Quellentabelle haben. Ein mit dem Anbieterkonto assoziierter Benutzer kann DML(Data Manipulation Language (=Datenbearbeitungssprache))-Befehle eingeben, um die Quellentabelle upzudaten. Solche DML-Befehle können veranlassen, dass neue Daten in die Quellentabelle eingefügt werden, können veranlassen, dass Daten aus der Quellentabelle gelöscht werden, können veranlassen, dass Daten verknüpft bzw. zusammengeführt werden, und/oder können veranlassen, dass Daten in der Quellentabelle upgedatet oder geändert werden. Bei einer Ausführungsform werden eine oder mehrere Mikropartitionen der Quellentabelle für jede Änderung, die an der Quellentabelle auftritt, neu erzeugt bzw. regeneriert. Zum Beispiel kann ein Einfügebefehl einfach veranlassen, dass eine oder mehrere neue Mikropartitionen erzeugt werden, ohne irgendwelche existierenden Mikropartitionen zu ändern. Ein Löschbefehl kann Zeilen aus der Quellentabelle entfernen und der Löschbefehl kann ausgeführt werden, indem eine oder mehrere Mikropartitionen neu erzeugt werden, so dass die gelöschten Zeilen aus der einen oder den mehreren Mikropartitionen entfernt werden. Ein Updatebefehl kann einen Dateneintrag in der Quellentabelle ändern und der Updatebefehl kann durch neues Erzeugen einer oder mehrerer Mikropartitionen ausgeführt werden, so dass die modifizierten Zeilen gelöscht und mit der upgedateten Information neu erzeugt werden. Wenn das Anbieterkonto die Quellentabelle bei 1204 updatet, kann dem Empfängerkonto eine Benachrichtigung bereitgestellt werden, dass die materialisierte Ansicht in Bezug auf die Quellentabelle nun veraltet ist. Die materialisierte Ansicht kann automatisch aufgefrischt werden, um irgendwelche an der Quellentabelle vorgenommenen Updates widerzuspiegeln.
Bei dem in 12 dargestellten Beispiel wird die materialisierte Ansicht bei 1202 durch Scannen einer Quellentabelle erzeugt. Die Quellentabelle enthält den Datensatz {1 2 3 4 5 6}, wie es dargestellt ist. Jedes der Bezugszeichen {1 2 3 4 5 6} kann eine Mikropartition innerhalb der Quellentabelle darstellen. Es sollte eingesehen werden, dass die Quellentabelle eine beliebige Anzahl von Mikropartitionen und viele Hunderte oder Tausende von Mikropartitionen enthalten kann. Die entsprechende materialisierte Ansicht enthält die Datensätze [1(1 2 3)] und [2(4 5 6)], die Mikropartitionen in der Datenbank anzeigen können, wobei die Mikropartitionen unveränderliche Speicherobjekte in der Datenbank sind. Die materialisierte Ansicht kann in den ersten Datensatz [1 (1 2 3)] und den zweiten Datensatz [2(4 5 6)] getrennt werden, da die materialisierte Ansicht zu viele Daten enthält, um in einem einzigen Datensatz gespeichert zu werden. Bei einer Ausführungsform werden die Größen der Datensätze basierend auf der Cache-Speicherkapazität in einem Ausführungsknoten bestimmt, der die materialisierte Ansicht verarbeiten wird. Jeder der Datensätze der materialisierten Ansicht, einschließlich [1(1 2 3)] und [2(4 5 6)], kann selbst eine unveränderliche Speichervorrichtung sein, die hierin als Mikropartition bezeichnet wird. Bei einer Ausführungsform wird der Quellentabellen-Datensatz {1 2 3 4 5 6} quer über einer oder mehreren Speichervorrichtungen gespeichert, die dem Anbieterkonto zugeteilt sind. Bei verschiedenen Ausführungsformen können die Datensätze der materialisierten Ansicht [1(1 2 3)] und [2(4 5 6)] quer über einer oder mehreren Speichervorrichtungen gespeichert sein, die dem Anbieterkonto oder dem Empfängerkonto zugeteilt sind. Wenn die Datasätze der materialisierten Ansicht in Speichervorrichtungen gespeichert sind, die dem Anbieterkonto zugeteilt sind, können die Datasätze der materialisierten Ansicht einem oder mehreren Empfängerkonten zugänglich gemacht werden, ohne die Datasätze der materialisierten Ansicht zu kopieren. Das Gegenteil ist richtig, so dass dann, wenn die Datensätze der materialisierten Ansicht in Speichervorrichtungen gespeichert sind, die dem Empfängerkonto zugeteilt sind, die Datensätze der materialisierten Ansicht dem Anbieterkonto und/oder einem oder mehreren zusätzlichen Empfängerkonten zugänglich gemacht werden können, ohne die Datensätze der materialisierten Ansicht zu kopieren.
Bei dem in 12 dargestellten Beispiel wird die Quellentabelle bei 1204 (siehe Δ1) durch Hinzufügen (+7) und Entfernen (-2) aktualisiert bzw. upgedated. Das Update an der Quellentabelle bei 1204 kann durch Ausführungsressourcen ausgeführt werden, die dem Anbieterkonto zugeteilt sind. Bei einer Ausführungsform hat nur das Anbieterkonto die Fähigkeit, Daten zur Quellentabelle zu schreiben. Zwei Mikropartitionen werden in die Quellentabelle bei 1206 (siehe Δ2) eingefügt, indem Hinzufügen bzw. Addieren (+8) und Addieren (+9) hinzugefügt werden. Zwei Mikropartitionen werden aus der Quellentabelle bei 1208 (siehe Δ3) durch Entfernen (-1) und (-3) entfernt. Wie es bei Δ (Delta) dargestellt ist, enthält das gesamte Update an der Quellentabelle {+7 +8 +9 -1 -2 -3}, die jedes der verschiedenen Updates (siehe Δ1, Δ2 und Δ3) enthält, die an der Quellentabelle vorgenommen sind. Das gesamte Update der Quellentabelle fügt Mikropartitionen mit den Nummern 7, 8 und 9 hinzu und löscht Mikropartitionen mit den Nummern 1, 2 und 3.
Bei dem in 12 dargestellten Beispiel werden die materialisierte Ansicht und die Quellentabelle bei 1210 abgefragt. Die Abfrage kann entweder vom Anbieterkonto oder vom Empfängerkonto angefordert werden. Das Empfängerkonto kann nur dann eine Abfrage über die Quellentabelle ausgeben, wenn das Empfängerkonto Zugriffsrechte hat, die es dem Empfängerkonto ermöglichen, die Daten in der Quellentabelle abzufragen. Die Verarbeitungszeit für die Abfrage kann über die materialisierte Ansicht beschleunigt werden. Da die Quellentabelle jedoch bei 1204 upgedated wurde, ist die materialisierte Ansicht in Bezug auf die Quellentabelle nicht mehr frisch bzw. neu. Eine Ausführung der Abfrage enthält ein Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und der Quellentabelle, um irgendwelche Modifikationen zu identifizieren, die an der Quellentabelle vorgenommen worden sind und nicht in der materialisierten Ansicht widergespiegelt werden bzw. berücksichtigt sind. Nachdem die materialisierte Ansicht und die Quellentabelle verknüpft worden sind, wird die materialisierte Ansicht gescannt, wird die Quellentabelle gescannt. Die Quellentabelle wird gescannt und Mikropartitionen mit den Nummern {7 8 9} werden in der Quellentabelle erkannt und diese Mikropartitionen werden in der materialisierten Ansicht nicht erkannt. Die materialisierte Ansicht wird gescannt und der Datensatz der materialisierten Ansicht [1 (1 2 3)] wird in der materialisierten Ansicht erkannt, wird aber nicht in der Quellentabelle erkannt. Dieser Datensatz der materialisierten Ansicht enthält Information über Mikropartitionen (1 2 3) in der Quellentabelle und Mikropartitionen (1 2 3) sind in der Quellentabelle nicht mehr vorhanden, da diese Mikropartitionen durch den Updatebefehl bei 1204 und den Löschbefehl bei 1208 entfernt wurden.
Bei dem in 12 dargestellten Beispiel wird das Update auf die materialisierte Ansicht bei 1212 angewendet. Das Update an der materialisierten Ansicht kann von Ausführungsressourcen ausgeführt werden, die dem Konto zugeteilt sind, das die materialisierte Ansicht anforderte und/oder erzeugte. Wenn die materialisierte Ansicht in Speicherressourcen gespeichert ist, die dem Anbieterkonto zugeteilt sind, dann kann die materialisierte Ansicht durch Ausführungsressourcen upgedated werden, die dem Anbieterkonto zugeteilt sind. Wenn die materialisierte Ansicht in Speicherressourcen gespeichert ist, die dem Empfängerkonto zugeteilt sind, dann kann die materialisierte Ansicht durch Ausführungsressourcen aufgefrischt werden, die dem Empfängerkonto zugeteilt sind. Die materialisierte Ansicht wird gescannt und das System erkennt die Datensätze der materialisierten Ansicht [1(1 2 3)] und [2(4 5 6)] und das System erkennt, dass ein Datensatz [1(1 2 3)] in der materialisierten Ansicht vorhanden ist, aber nicht in der Quellentabelle vorhanden ist. Das System bestimmt, dass der Datensatz der materialisierten Ansicht [1(1 2 3)] aus der materialisierten Ansicht entfernt werden sollte. Das System löscht den Datensatz [1 (1 2 3)], so dass der Datensatz der materialisierten Ansicht [2(4 5 6)] erhalten bleibt. Das System scannt die Quellentabelle und entdeckt, dass die Mikropartitionen {7 8 9} in der Quellentabelle vorhanden sind, dass aber keine Information über diese Mikropartitionen in der materialisierten Ansicht vorhanden ist. Das System updated die materialisierte Ansicht, damit sie Information über die Mikropartitionen {7 8 9} enthält. Die materialisierte Ansicht ist nun in Bezug auf die Quellentabelle aufgefrischt und enthält Information über die Mikropartitionen {4 5 6 7 8 9}. Die materialisierte Ansicht enthält nun zwei Datensätze, nämlich [2(4 5 6)] und [3(7 8 9)].
13 stellt beispielhafte Mikropartitionen einer Quellentabelle 1302 und einer basierend auf der Quellentabelle erzeugten beispielhaften materialisierten Ansicht 1304 dar. Die Quellentabelle 1302 unterzieht sich einer linearen Transformation, um eine Vielzahl von Mikropartitionen zu erzeugen (siehe Partition Nr. 7, Partition Nr. 12 und Partition Nr. 35). Die Vielzahl von Mikropartitionen kann eine einzelne Mikropartition der materialisierten Ansicht 1304 bei einer Ausführungsform erzeugen, wie es in 13 dargestellt ist. Die Mikropartitionen sind unveränderliche Speicherobjekte im Datenbanksystem. Bei einer Ausführungsform sind die Mikropartitionen als explizite Liste von Mikropartitionen dargestellt und bei bestimmten Ausführungsformen kann dies besonders kostspielig sein. Bei einer alternativen Ausführungsform sind die Mikropartitionen als eine Bereich von Mikropartitionen dargestellt. Bei einer bevorzugten Ausführungsform sind die Mikropartitionen als DML-Version dargestellt, die eine letzte Auffrischung und letzte Kompaktierung bzw. Verdichtung der Quellentabelle 1302 anzeigt.
Die beispielhafte Quellentabelle 1302 ist mit „Quellentabelle Nr. 243“ bezeichnet, um darzustellen, dass eine beliebige Anzahl von Quellentabellen verwendet werden kann, um die materialisierte Ansicht 1304 zu erzeugen, die materialisierte Ansicht 1304 kann jede der zahlreichen Quellentabellen indizieren (siehe die Spalte „Tabelle“ in der materialisierten Ansicht 1304) und/oder eine beliebige Anzahl zahlreicher materialisierter Ansichten kann für eine Anzahl von möglichen Quellentabellen erzeugt werden. Die Quellentabelle 1302 enthält drei Mikropartitionen, wie es bei der beispielhaften Ausführungsform in 13 dargestellt ist. Die drei Mikropartitionen der Quellentabelle 1302 enthalten Partition Nr. 7, Partition Nr. 12 und Partition Nr. 35. 13 stellt dar, dass die Mikropartitionen in der materialisierten Ansicht 1304 unter der Spalte „Partition“ indiziert sind. 13 stellt weiterhin dar, dass die materialisierte Ansicht 1304 eine einzelne Mikropartition enthält, die auf den drei Mikropartitionen der Quellentabelle 1302 basiert. Zusätzliche Mikropartitionen können zur materialisierten Ansicht 1304 hinzugefügt und/oder von der materialisierten Ansicht 1304 entfernt werden, wenn die materialisierte Ansicht 1304 inkrementell upgedated wird.
Die materialisierte Ansicht 1304 für die Quellentabelle enthält vier Spalten, wie es bei der beispielhaften Implementierung in 13 dargestellt ist. Die Partitionsspalte zeigt an, welche Mikropartition der Quellentabelle auf diese Zeile der materialisierten Ansicht 1304 anwendbar ist. Wie es beim Beispiel in 13 gezeigt ist, hat die Partitionsspalte Zeilen für Partitionsnummer 7, Partitionsnummer 12 und Partitionsnummer 35. Bei einigen Ausführungsformen können sich diese Partitionen auf Mikropartitionen beziehen, die unveränderliche Speichervorrichtungen bilden, die nicht an Ort und Stelle upgedated werden können. Die materialisierte Ansicht 1304 enthält eine Tabellenspalte, die einen Identifizierer für die Quellentabelle anzeigt. Bei dem in 13 dargestellten Beispiel ist der Identifizierer für die Quellentabelle die Zahl bzw. Nummer 243. Die materialisierte Ansicht 1304 enthält eine Spalte „Spalte 2“, die der „Spalte 2“ in der Quellentabelle entspricht. Bei dem in 13 dargestellten Beispiel kann Spalte 2 der Quellentabelle einen „M“-Eintrag oder einen „F“-Eintrag haben, um anzuzeigen, ob die in dieser Zeile identifizierte Person männlich oder weiblich ist. Es sollte eingesehen werden, dass die Daten bei der beispielhaften Spalte 2 irgendeine geeignete Information enthalten könnten. Allgemeine Dateneinträgen, die von Interesse sein können, enthalten zum Beispiel Namen, Adressen, identifizierende Information, Preisinformation, statistische Information, demografische Information, Deskriptorinformation und so weiter. Es sollte eingesehen werden, dass es keine Begrenzung dafür gibt, welche Daten in der Spalte gespeichert sind, und dass der in 13 dargestellte männliche/weibliche Identifizierer nur für beispielhafte Zwecke dient. Die materialisierte Ansicht 1304 enthält weiterhin eine Spalte SUMME. Die Spalte SUMME zeigt an, wie viele Einträge in jeder Partition einen „männlichen“ oder „weiblichen“ Identifizierer in Spalte 2 haben. Bei der beispielhaften Implementierung enthält die Partition 7 50.017 männliche und 37.565 weibliche Identifizierer. Die Partition 12 enthält 43.090 männliche Identifizierer und 27.001 weibliche Identifizierer; und die Partition 35 enthält 34.234 männliche Identifizierer und 65.743 weibliche Identifizierer. Es sollte eingesehen werden, dass die Spalte SUMME in der beispielhaften materialisierten Ansicht 1304 nur zu Illustrationszwecken dient. Die materialisierte Ansicht 1304 liefert nicht notwendigerweise Datensummen für die Quellentabelle, kann aber irgendeine gewünschte Metrik liefern. Die in der materialisierten Ansicht 1304 gezeigte Berechnung wird von auf einer Basis von Fall zu Fall basierend auf den Bedürfnissen der Partei bestimmt werden, die die materialisierte Ansicht anforderte.
Wie es in 13 dargestellt ist, sind die Metadaten zwischen der Quellentabelle 1302 und der materialisierten Ansicht 1304 konsistent. Die Metadaten der materialisierten Ansicht 1304 werden upgedated, um irgendwelche Updates an den Metadaten der Quellentabelle 1302 widerzuspiegeln.
14 ist ein Blockdiagramm, das eine beispielhafte Ausführungsform einer Datenverarbeitungsplattform 1400 darstellt. Wie es in 14 gezeigt ist, ist ein Computing-Service-Manager 1402 in Kommunikation mit einer Warteschlange 1404, einem Clientkonto 1408, Metadaten 1406 und einer Ausführungsplattform 1416. Bei einer Ausführungsform empfängt der Computing-Service-Manager 1402 keine direkten Kommunikationen von einem Clientkonto 1408 und empfängt nur Kommunikationen in Bezug auf Jobs aus der Warteschlange 1404. Bei besonderen Implementierungen kann der Computing-Service-Manager 1402 eine beliebige Anzahl von Clientkonten 208 unterstützen, wie beispielsweise Endbenutzer, die Datenspeicherung und Wiedergewinnungsanforderungen bereitstellen, Systemadministratoren, die die hier beschriebenen Systeme und Verfahren managen, und andere Komponenten/Vorrichtungen, die mit dem Computing-Service-Manager 1402 interagieren. Wie es hierin verwendet ist, kann Computing-Service-Manager 1402 auch als „globales Servicesystem“ bezeichnet werden, das verschiedene Funktionen ausführt, wie es hierin diskutiert ist.
Der Computing-Service-Manager 1402 ist in Kommunikation mit einer Warteschlange 1404. Die Warteschlange 1404 kann dem Computing-Service-Manager 1402 in Reaktion auf ein Trigger- bzw. Auslöser-Ereignis einen Job bzw. Auftrag bereitstellen. Ein oder mehrere Jobs können in der Warteschlange 1404 in einer Reihenfolge eines Empfangs und/oder einer Reihenfolge einer Priorität gespeichert werden und jeder von diesen einem oder mehreren Jobs kann zum Computing-Service-Manager 1402 kommuniziert werden, um geplant und ausgeführt zu werden. Die Warteschlange 1404 kann einen durchzuführenden Job basierend auf einem Auslöser-Ereignis bestimmen, wie beispielsweise die Aufnahme von Daten, das Löschen einer oder mehrerer Zeilen in einer Tabelle, das Aktualisieren bzw. Updaten einer oder mehrerer Zeilen in einer Tabelle, wobei eine materialisierte Ansicht in Bezug auf ihre Quellentabelle veraltet wird, wobei eine Tabelle einen vordefinierten Clusterbildungs-Schwellenwert erreicht, der anzeigt, dass die Tabelle neu gruppiert bzw. einer Clusterbildung unterzogen werden sollte, und so weiter. Bei einer Ausführungsform enthält die Warteschlange 1404 Einträge zum Auffrischen einer materialisierten Ansicht. Die Warteschlange 1404 kann Einträge zum Auffrischen einer materialisierten Ansicht enthalten, die über eine lokale Quellentabelle erzeugt wird (d.h. lokal zu demselben Konto, das den Computing-Service-Manager 1402 betreibt), und/oder zum Auffrischen einer materialisierten Ansicht, die über eine geteilte Quellentabelle erzeugt wird, die von einem anderen Konto gemanagt wird.
Der Computing-Service-Manager 1402 ist auch mit Metadaten 1406 gekoppelt, die mit der Gesamtheit von Daten assoziiert sind, die über die gesamte Datenverarbeitungsplattform 1400 hinweg gespeichert sind. Bei einigen Ausführungsformen enthalten Metadaten 1406 eine Zusammenfassung von Daten, die in entfernten Datenspeichersystemen gespeichert sind, sowie Daten, die aus einem lokalen Cache verfügbar sind. Zusätzlich können Metadaten 1406 Informationen diesbezüglich enthalten, wie Daten in den entfernten Datenspeichersystemen und den lokalen Caches organisiert sind. Metadaten 1406 lassen zu, dass Systeme und Dienste bestimmen, ob auf ein Stück von Daten zugegriffen werden muss, ohne die tatsächlichen Daten von einer Speichervorrichtung zu laden oder auf diese zuzugreifen.
Bei einer Ausführungsform können der Computing-Service-Manager 1402 und/oder die Warteschlange 1404 bestimmen, dass ein Job durchgeführt werden sollte, und zwar basierend auf den Metadaten 1406. Bei einer solchen Ausführungsform können/kann der Computing-Service-Manager 1402 und/oder die Warteschlange 1404 die Metadaten 1406 scannen und bestimmen, dass ein Job durchgeführt werden sollte, um eine Datenorganisation oder eine Datenbankleistungsfähigkeit zu verbessern. Zum Beispiel können/kann der Computing-Service-Manager 1402 und/oder die Warteschlange 1404 bestimmen, dass eine neue Version einer Quellentabelle für eine materialisierte Ansicht erzeugt worden ist und die materialisierte Ansicht nicht aufgefrischt worden ist, um die neue Version der Quellentabelle widerzuspiegeln. Die Metadaten 1406 können einen Transaktionsänderungs-Nachverfolgungsstrom enthalten, der anzeigt, wann die neue Version der Quellentabelle erzeugt und wann die materialisierte Ansicht zuletzt aufgefrischt wurde. Basierend auf diesem Transaktionsstrom der Metadaten 1406 können/kann der Computing-Service-Manager 1402 und/oder die Warteschlange 1404 bestimmen, dass ein Job durchgeführt werden sollte. Bei einer Ausführungsform bestimmt der Computing-Service-Manager 1402, dass ein Job durchgeführt werden sollte, und zwar basierend auf einem Auslöser-Ereignis, und speichert den Job in der Warteschlange 1404, bis der Computing-Service-Manager 1402 bereit ist, die Ausführung des Jobs zu planen und zu managen.
Der Computing-Service-Manager 1402 kann Regeln oder Parameter vom Clientkonto 1408 empfangen und solche Regeln oder Parameter können den Computing-Service-Manager 1402 beim Planen und Managen interner Jobs leiten. Das Clientkonto 1408 kann anzeigen, dass interne Jobs nur zu bestimmten Zeiten ausgeführt werden sollten oder nur eine festgelegte maximale Menge an Verarbeitungsressourcen nutzen sollten. Das Clientkonto 1408 kann weiterhin ein oder mehrere Auslöser-Ereignisse anzeigen, die den Computing-Service-Manager 1402 auffordern sollten, zu bestimmen, dass ein Job durchgeführt werden sollte. Das Clientkonto 1408 kann Parameter diesbezüglich liefern, wie viele Male eine Aufgabe erneut ausgeführt werden kann und/oder wann die Aufgabe erneut ausgeführt werden sollte.
Der Computing-Service-Manager 1402 ist weiterhin mit einer Ausführungsplattform 1416 gekoppelt, die mehrere Computerressourcen bereitstellt, die verschiedene Datenspeicherungs- und Datenwiedergewinnungsaufgaben ausführen, wie es nachstehend ausführlicher diskutiert ist. Die Ausführungsplattform 1416 ist mit mehreren Datenspeichervorrichtungen 1412a, 1412b und 1412n gekoppelt, die Teil einer Speicherplattform 1410 sind. Obwohl drei Datenspeichervorrichtungen 1412a, 1412b und 1412n in 14 gezeigt sind, ist die Ausführungsplattform 1416 in der Lage, mit irgendeiner Anzahl von Datenspeichervorrichtungen zu kommunizieren. Bei einigen Ausführungsformen sind die Datenspeichervorrichtungen 1412a, 1412b und 1412n cloudbasierte Speichervorrichtungen, die an einem oder mehreren geografischen Standorten angeordnet sind. Zum Beispiel können die Datenspeichervorrichtungen 1412a, 1412b und 1412n Teil einer Infrastruktur einer öffentlichen Cloud oder einer Infrastruktur einer privaten Cloud sein. Die Datenspeichervorrichtungen 1412a, 1412b und 1412n können Festplattenlaufwerke (HDDs), Festkörperspeicher (SSDs), Speichercluster, Amazon S3™-Speichersysteme oder irgendeine andere Datenspeichertechnologie sein. Zusätzlich kann die Speicherplattform 1410 verteilte Dateisysteme (wie beispielsweise Hadoop Distributed File Systems (HDFS)), Objektspeichersysteme und dergleichen enthalten.
Bei bestimmten Ausführungsformen sind die Kommunikationsverbindungen zwischen Computing-Service-Manager 1402, der Warteschlange 1404, den Metadaten 1406, dem Clientkonto 1408 und der Ausführungsplattform 1416 über ein oder mehrere Datenkommunikationsnetzwerke implementiert. Gleichermaßen werden die Kommunikationsverbindungen zwischen der Ausführungsplattform 1416 und den Datenspeichervorrichtungen 1412a-1412n in der Speicherplattform 1410 über ein oder mehrere Datenkommunikationsnetzwerke realisiert. Diese Datenkommunikationsnetzwerke können irgendein Kommunikationsprotokoll und irgendeinen Typ von Kommunikationsmedium verwenden. Bei einigen Ausführungsformen sind die Datenkommunikationsnetzwerke eine Kombination von zwei oder mehr Datenkommunikationsnetzwerken (oder Teilnetzwerken), die miteinander gekoppelt sind. In alternativen Ausführungsformen werden diese Kommunikationsverbindungen unter Verwendung von irgendeinem Typ von Kommunikationsmedium und irgendeinem Kommunikationsprotokoll implementiert.
Wie es in 14 gezeigt, sind die Datenspeichervorrichtungen 1412a, 1412b und 1412n von den Computerressourcen entkoppelt, die mit der Ausführungsplattform 1416 assoziiert sind. Diese Architektur unterstützt dynamische Änderungen an der Datenverarbeitungsplattform 1400 basierend auf den sich ändernden Datenspeicherungs-/Wiedergewinnungsanforderungen sowie den sich ändernden Anforderungen der Benutzer und Systeme, die auf die Datenverarbeitungsplattform 1400 zugreifen. Die Unterstützung dynamischer Änderungen lässt zu, dass sich die Datenverarbeitungsplattform 1400 in Reaktion auf sich ändernde Anforderungen an die Systeme und Komponenten innerhalb der Datenverarbeitungsplattform 1400 schnell skalieren. Die Entkopplung der Computerressourcen von den Datenspeichervorrichtungen unterstützt die Speicherung großer Datenmengen, ohne eine entsprechend große Menge an Computerressourcen zu erfordern. Gleichermaßen unterstützt diese Entkopplung von Ressourcen eine signifikante Erhöhung bezüglich der zu einer bestimmten Zeit verwendeten Computerressourcen, ohne eine entsprechende Erhöhung bezüglich der verfügbaren Datenspeicherressourcen zu erfordern.
Ein Computing-Service-Manager 1402, eine Warteschlange 1404, Metadaten 1406, ein Clientkonto 1408, eine Ausführungsplattform 1416 und eine Speicherplattform 1410 sind in 14 als einzelne Komponenten gezeigt. Der Computing-Service-Manager 1402, die Warteschlange 1404, die Metadaten 1406, das Clientkonto 1408, die Ausführungsplattform 1416 und die Speicherplattform 1410 können jedoch jeweils als verteiltes System implementiert werden (z.B. verteilt quer über mehrere Systeme/Plattformen bei mehreren geografischen Standorten). Zusätzlich können der Computing-Service-Manager 1402, die Metadaten 1406, die Ausführungsplattform 1416 und die Speicherplattform 1410 (unabhängig voneinander) in Abhängigkeit von Änderungen an den von der Warteschlange 1404 und/oder den Clientkonten 208 empfangenen Anforderungen und den sich ändernden Anforderungen der Datenverarbeitungsplattform 1400 nach oben oder nach unten skaliert werden. Somit ist bei den beschriebenen Ausführungsformen die Datenverarbeitungsplattform 1400 dynamisch und unterstützt regelmäßige Änderungen, um den aktuellen Datenverarbeitungsanforderungen gerecht zu werden.
Während eines typischen Betriebs verarbeitet die Datenverarbeitungsplattform 1400 mehrere Jobs, die von der Warteschlange 1404 empfangen oder durch den Computing-Service-Manager 1402 bestimmt werden. Diese Jobs werden vom Computing-Service-Manager 1402 geplant und gemanagt, um zu bestimmen, wann und wie der Job ausgeführt werden soll. Zum Beispiel kann der Computing-Service-Manager 1402 den Job in mehrere diskrete Aufgaben aufteilen und kann bestimmen, welche Daten nötig sind, um jede der mehreren diskreten auszuführen. Der Computing-Service-Manager 1402 kann jede der mehreren diskreten Aufgaben einem oder mehreren Knoten der Ausführungsplattform 1416 zuordnen, um die Aufgabe zu verarbeiten. Der Computing-Service-Manager 1402 kann bestimmen, welche Daten nötig sind, um eine Aufgabe zu verarbeiten, und weiterhin bestimmen, welche Knoten innerhalb der Ausführungsplattform 1416 am besten geeignet sind, um die Aufgabe zu verarbeiten. Einige Knoten können die Daten, die nötig sind, um die Aufgabe zu verarbeiten, bereits in einem Cache gespeichert haben und daher ein guter Kandidat zum Verarbeiten der Aufgabe sein. Die Metadaten 1406 unterstützen den Computing-Service-Manager 1402 beim Bestimmen, welche Knoten in der Ausführungsplattform 1416 bereits wenigstens einen Teilbereich der Daten, die nötig sind, um die Aufgabe zu verarbeiten, in einem Cache gespeichert bzw. zwischengespeichert haben. Ein oder mehrere Knoten in der Ausführungsplattform 1416 verarbeiten die Aufgabe unter Verwendung von Daten, die durch die Knoten in einem Cache gespeichert sind, und, wenn es notwendig ist, Daten, die aus der Speicherplattform 1410 wiedergewonnen sind. Es ist wünschenswert, so viele Daten wie möglich aus Caches innerhalb der Ausführungsplattform 1416 wiederzugewinnen, da die Wiedergewinnungsgeschwindigkeit typischerweise viel schneller als ein Wiedergewinnen von Daten von der Speicherplattform 1410 ist.
Wie es in 14 gezeigt ist, trennt die Datenverarbeitungsplattform 1400 die Ausführungsplattform 1416 von der Speicherplattform 1410. Bei dieser Anordnung arbeiten die Verarbeitungsressourcen und Cacheressourcen in der Ausführungsplattform 1416 unabhängig von den Datenspeicherressourcen 1412a-1412n in der Speicherplattform 1410. Somit sind die Computerressourcen und Cacheressourcen nicht auf spezifische Datenspeicherressourcen 1412a-1412n beschränkt. Stattdessen können alle Computerressourcen und alle Cacheressourcen Daten von irgendeiner der Datenspeicherressourcen in der Speicherplattform 1410 wiedergewinnen und dorthin speichern. Zusätzlich unterstützt die Datenverarbeitungsplattform 1400 das Hinzufügen neuer Computerressourcen und Cacheressourcen zur Ausführungsplattform 1416, ohne irgendwelche Änderungen an der Speicherplattform 1410 zu erfordern. Gleichermaßen unterstützt die Datenverarbeitungsplattform 1400 das Hinzufügen von Datenspeicherressourcen zur Speicherplattform 1410, ohne irgendwelche Änderungen an Knoten in der Ausführungsplattform 1416 zu erfordern.
15 ist ein Blockdiagramm, das eine Ausführungsform des Computing-Service-Managers 1402 darstellt. Wie es in 15 gezeigt ist, enthält der Computing-Service-Manager 1402 einen Zugriffsmanager 1502 und einen Schlüsselmanager 1504, die mit einer Datenspeichervorrichtung 1506 gekoppelt sind. Der Zugriffsmanager 1502 handhabt Authentifizierungs- und Autorisierungsaufgaben für die hierin beschriebenen Systeme. Der Schlüsselmanager 1504 managt eine Speicherung und eine Authentifizierung von Schlüsseln, die während Authentifizierungs- und Autorisierungsaufgaben verwendet werden. Zum Beispiel manage der Zugriffsmanager 1502 und der Schlüsselmanager 1504 die Schlüssel, die verwendet werden, um auf Daten zuzugreifen, die in entfernten Speichervorrichtungen gespeichert sind (z.B. Datenspeichervorrichtungen in der Speicherplattform 1410). Wie es hierin verwendet ist, können die entfernten Speichervorrichtungen auch als „persistente Speichervorrichtungen“ oder „gemeinsam genutzte Speichervorrichtungen“ bezeichnet werden. Ein Anforderungsverarbeitungsdienst 1508 managt empfangene Datenspeicheranforderungen und Datenwiedergewinnungsanforderungen (z.B. an Datenbankdaten durchzuführende Jobs). Zum Beispiel kann der Anforderungsverarbeitungsdienst 1508 die Daten bestimmen, die nötig sind, um die empfangene Datenspeicheranforderung oder Datenwiedergewinnungsanforderung zu verarbeiten. Die nötigen Daten können in einem Cache innerhalb der Ausführungsplattform 1416 (wie nachstehend detaillierter diskutiert wird) oder in einer Datenspeichervorrichtung in der Speicherplattform 1410 gespeichert werden. Ein Managementkonsolendienst 1510 unterstützt einen Zugriff auf verschiedene Systeme und Prozesse durch Administratoren und andere Systemmanager. Zusätzlich kann der Managementkonsolendienst 1510 eine Anforderung empfangen, um einen Job auszuführen und die Arbeitsauslastung auf dem System zu überwachen.
Der Computing-Service-Manager 1402 enthält auch einen Job-Compiler 1512, einen Job-Optimierer 1514 und einen Job-Ausführer 1510. Der Job-Compiler 1512 zergliedert bzw. parst einen Job in mehrere diskrete Aufgaben und erzeugt den Ausführungscode für jede der mehreren diskreten Aufgaben. Der Job-Optimierer 1514 bestimmt das beste Verfahren, um die mehreren diskreten Aufgaben auszuführen, und zwar basierend auf den Daten, für die es nötig ist, verarbeitet zu werden. Der Job-Optimierer 1514 handhabt auch verschiedene Datenbereinigungsoperationen und andere Datenoptimierungstechniken, um die Geschwindigkeit und Effizienz eines Ausführens des Jobs zu verbessern. Der Job-Ausführer 1516 führt den Ausführungscode für Jobs aus, die von der Warteschlange 1404 empfangen oder durch den Computing-Service-Manager 1402 bestimmt werden.
Ein Job-Planer und -Koordinator 1518 sendet empfangene Jobs zu den geeigneten Diensten oder Systemen zur Kompilierung, Optimierung und Entsendung zur Ausführungsplattform 1416. Zum Beispiel können Jobs priorisiert und in dieser priorisierten Reihenfolge verarbeitet werden. Bei einer Ausführungsform bestimmt der Job-Planer und -Koordinator 1518 eine Priorität für interne Jobs, die vom Computing-Service-Manager 1402 geplant sind, mit anderen Jobs „von außen“, wie beispielsweise Benutzerabfragen, die von anderen Systemen in der Datenbank geplant sein können, aber dieselben Verarbeitungsressourcen in der Ausführungsplattform 1416 verwenden können. Bei einigen Ausführungsformen identifiziert der Job-Planer und -Koordinator 1518 bestimmte Knoten in der Ausführungsplattform 1416 oder ordnet sie zu, um bestimmte Aufgaben zu verarbeiten. Ein Manger eines virtuellen Lagers 1520 managt die Operation bzw. den Betrieb mehrerer virtueller Lager, die in der Ausführungsplattform 1416 implementiert sind. Wie es nachstehend diskutiert wird, enthält jedes virtuelle Lager mehrere Ausführungsknoten, die jeweils einen Cache und einen Prozessor enthalten.
Zusätzlich enthält der Computing-Service-Manager 1402 einen Konfigurations- und Metadaten-Manager 1522, der die Information managt, die sich auf die Daten bezieht, die in den entfernten Datenspeichervorrichtungen und in den lokalen Caches (d.h. den Caches in der Ausführungsplattform 1416) gespeichert sind. Wie es nachstehend detaillierter diskutiert wird, verwendet der Konfigurations- und Metadaten-Manager 1522 die Metadaten, um zu bestimmen, auf welche Datendateien zugegriffen werden muss, um Daten zum Verarbeiten einer bestimmten Aufgabe oder eines bestimmten Jobs wiederzugewinnen. Ein Überwachungs- und Arbeitslast-Analysierer 1524 beaufsichtigt durch den Computing-Service-Manager 1402 durchgeführte Prozesse und managt die Verteilung von Aufgaben (z.B. Arbeitslast) quer über die virtuellen Lager und Ausführungsknoten in der Ausführungsplattform 1416. Der Überwachungs- und Arbeitslast-Analysierer 1524 verteilt auch Aufgaben neu, wie es nötig ist, basierend auf sich ändernden Arbeitslasten über der gesamten Datenverarbeitungsplattform 1400 und kann weiterhin Aufgaben basierend auf einer Abfragearbeitslast eines Benutzers (d.h. „von extern“) neu verteilen, die auch durch die Ausführungsplattform 1416 verarbeitet werden kann. Der Konfigurations- und Metadaten-Manager 1522 und der Überwachungs- und Arbeitslast-Analysierer 1524 sind mit einer Datenspeichervorrichtung 1526 gekoppelt. Die Datenspeichervorrichtungen 1506 und 1526 in 15 stellen irgendwelche Datenspeichervorrichtungen innerhalb der Datenverarbeitungsplattform 1400 dar. Zum Beispiel können die Datenspeichervorrichtungen 1506 und 1526 Caches in der Ausführungsplattform 1416, Speichervorrichtungen in der Speicherplattform 1410 oder irgendeine andere Speichervorrichtung darstellen.
Der Computing-Service-Manager 1402 enthält auch eine Teilungskomponente 210, wie es hierin offenbart ist. Die Teilungskomponente 210 ist konfiguriert, um kontoübergreifende Zugriffsrechte bereitzustellen, und kann weiterhin konfiguriert sein, um kontoübergreifende materialisierte Ansichten zu erzeugen und upzudaten.
16 ist ein Blockdiagramm, das eine Ausführungsform einer Ausführungsplattform 1416 darstellt. Wie es in 16 gezeigt ist, enthält die Ausführungsplattform 1416 mehrere virtuelle Lager, einschließlich eines virtuellen Lagers 1, eines virtuellen Lagers 2 und eines virtuellen Lagers n. Jedes virtuelle Lager enthält mehrere Ausführungsknoten, die jeweils einen Datencache und einen Prozessor enthalten. Die virtuellen Lager können mehrere Aufgaben parallel ausführen, indem sie die mehreren Ausführungsknoten verwenden. Wie es hierin diskutiert ist, kann die Ausführungsplattform 1416 neue virtuelle Lager hinzufügen und existierende bzw. vorhandene virtuelle Lager fallenlassen, und zwar in Echtzeit basierend auf den aktuellen Verarbeitungsanforderungen der Systeme und Benutzer. Diese Flexibilität lässt zu, dass die Ausführungsplattform 1416 schnell große Mengen an Computerressourcen nutzt, wenn es nötig, ohne dazu gezwungen zu sein, fortgesetzt für diese Computerressourcen zu bezahlen, wenn sie nicht mehr benötigt werden. Alle virtuellen Lager können auf Daten von irgendeiner Datenspeichervorrichtung (z.B. irgendeiner Speichervorrichtung in der Speicherplattform 1410) zugreifen.
Obwohl jedes in 16 gezeigte virtuelle Lager drei Ausführungsknoten enthält, kann ein bestimmtes virtuelles Lager irgendeine Anzahl von Ausführungsknoten enthalten. Weiterhin ist die Anzahl von Ausführungsknoten in einem virtuellen Lager dynamisch, so dass neue Ausführungsknoten erstellt werden, wenn zusätzlicher Bedarf vorhanden ist, und existierende Ausführungsknoten gelöscht werden, wenn sie nicht mehr benötigt werden.
Jedes virtuelle Lager ist in der Lage, auf irgendeine der in 14 gezeigten Datenspeichervorrichtungen 1412a-1412n zuzugreifen. Somit sind die virtuellen Lager nicht notwendigerweise einer bestimmten Datenspeichervorrichtung 1412a-1412n zugeordnet und können stattdessen auf Daten von irgendeiner der Datenspeichervorrichtungen 1412a-1412n innerhalb der Speicherplattform 1410 zugreifen. Gleichermaßen kann jeder der in 16 gezeigten Ausführungsknoten auf Daten von irgendeiner der Datenspeichervorrichtungen 1412a-1412n zugreifen. Bei einigen Ausführungsformen kann ein bestimmtes virtuelles Lager oder ein bestimmter Ausführungsknoten temporär einer spezifischen Datenspeichervorrichtung zugeordnet sein, aber das virtuelle Lager oder der Ausführungsknoten kann später auf Daten von irgendeiner anderen Datenspeichervorrichtung zugreifen.
Bei dem Beispiel der 16 enthält das virtuelle Lager 1 drei Ausführungsknoten 1602a, 1602b und 1602n. Der Ausführungsknoten 1602a enthält einen Cache 1604a und einen Prozessor 1606a. Der Ausführungsknoten 1602b enthält einen Cache 1604b und einen Prozessor 1606b. Der Ausführungsknoten 1602n enthält einen Cache 1604n und einen Prozessor 1606n. Jeder Ausführungsknoten 1602a, 1602b und 1602n ist mit einer Verarbeitung von einer oder mehreren Datenspeicherungs- und/oder Datenwiedergewinnungsaufgaben assoziiert. Zum Beispiel kann ein virtuelles Lager Datenspeicherungs- und Datenwiedergewinnungsaufgaben verarbeiten, die mit einem internen Dienst assoziiert sind, wie beispielsweise einem Clusterbildungsdienst, einem Auffrischungsdienst für materialisierte Ansichten, einem Dateikompaktierungsdienst, einem Speicherungsprozedurdienst oder einem Datei-Upgradedienst. Bei anderen Implementierungen kann ein bestimmtes virtuelles Lager Datenspeicherungs- und Datenwiedergewinnungsaufgaben verarbeiten, die mit einem bestimmten Datenspeichersystem oder einer bestimmten Kategorie von Daten assoziiert sind.
Ähnlich dem oben diskutierten virtuellen Lager 1 enthält das virtuelle Lager 2 drei Ausführungsknoten 1612a, 1612b und 1612n. Der Ausführungsknoten 1612a enthält einen Cache 1614a und einen Prozessor 1616a. Der Ausführungsknoten 1612n enthält einen Cache 1614n und einen Prozessor 1616n. Der Ausführungsknoten 1612n enthält einen Cache 1614n und einen Prozessor 1616n. Zusätzlich enthält das virtuelle Lager 3 drei Ausführungsknoten 1622a, 1622b und 1622n. Der Ausführungsknoten 1622a enthält einen Cache 1624a und einen Prozessor 1626a. Der Ausführungsknoten 1622b enthält einen Cache 1624b und einen Prozessor 1626b. Der Ausführungsknoten 1622n enthält einen Cache 1624n und einen Prozessor 1626n.
Bei einigen Ausführungsformen sind die in 16 gezeigten Ausführungsknoten zustandslos in Bezug auf die Daten, die die Ausführungsknoten im Cache speichern bzw. zwischenspeichern. Zum Beispiel speichern diese Ausführungsknoten Zustandsinformation über den Ausführungsknoten oder die Daten, die von einem bestimmten Ausführungsknoten zwischengespeichert werden, nicht oder halten sie nicht auf andere Weise. Somit kann im Fall eines Fehlers bzw. Ausfalls eines Ausführungsknotens der fehlerhafte bzw. ausgefallene Knoten transparent durch einen anderen Knoten ersetzt werden. Da es keine Zustandsinformation gibt, die mit dem fehlerhaften Ausführungsknoten assoziiert ist, kann der neue (Ersatz-) Ausführungsknoten den ausgefallenen Knoten auf einfache Weise ersetzen, ohne sich Gedanken über eine Neuerstellung eines bestimmten Zustands machen zu müssen.
Obwohl die in 16 gezeigten Ausführungsknoten jeweils einen Datencache und einen Prozessor enthalten, können alternative Ausführungsformen Ausführungsknoten enthalten, die irgendeine Anzahl von Prozessoren und irgendeine Anzahl von Caches enthalten. Zusätzlich können die Caches bezüglich der Größe zwischen den unterschiedlichen Ausführungsknoten variieren. Die in 16 gezeigten Caches speichern im lokalen Ausführungsknoten Daten, die von einer oder mehreren Datenspeichervorrichtungen in der Speicherplattform 1410 wiedergewonnen wurden. Somit reduzieren oder eliminieren die Caches die Engpassprobleme, die bei Plattformen auftreten, die konsistent Daten von entfernten Speichersystemen wiedergewinnen. Anstatt eines wiederholten Zugreifens auf Daten von den entfernten Speichervorrichtungen aus, greifen die hierin beschriebenen Systeme und Verfahren auf Daten von den Caches in den Ausführungsknoten zu, was signifikant schneller ist und das oben diskutierte Engpassproblem vermeidet. Bei einigen Ausführungsformen sind die Caches unter Verwendung von Hochgeschwindigkeits-Speichervorrichtungen implementiert, die einen schnellen Zugriff auf die zwischengespeicherten Daten ermöglichen. Jeder Cache kann Daten von irgendeiner der Speichervorrichtungen in der Speicherplattform 1410 speichern.
Weiterhin können die Cacheressourcen und Computerressourcen zwischen unterschiedlichen Ausführungsknoten variieren. Zum Beispiel kann ein Ausführungsknoten signifikante Computerressourcen und minimale Cacheressourcen enthalten, was den Ausführungsknoten für Aufgaben nützlich macht, die signifikante Computerressourcen erfordern. Ein anderer Ausführungsknoten kann signifikante Cacheressourcen und minimale Computerressourcen enthalten, was diesen Ausführungsknoten für Aufgaben nützlich macht, die das Zwischenspeichern großer Datenmengen erfordern. Ein noch weiterer Ausführungsknoten kann Cacheressourcen enthalten, die schnellere Eingabe-Ausgabe-Operationen bereitstellen, die für Aufgaben nützlich sind, die ein schnelles Scannen großer Datenmengen erfordern. Bei einigen Ausführungsformen werden die mit einem bestimmten Ausführungsknoten assoziierten Cacheressourcen und Computerressourcen beim Erstellen des Ausführungsknotens basierend auf den erwarteten Aufgaben bestimmt, die vom Ausführungsknoten durchgeführt werden sollen.
Zusätzlich können sich die mit einem bestimmten Ausführungsknoten assoziierten Cacheressourcen und Computerressourcen basierend auf einer Änderung von durch den Ausführungsknoten durchgeführten Aufgaben im Laufe der Zeit ändern. Zum Beispiel kann ein Ausführungsknoten mehreren Verarbeitungsressourcen zugeordnet werden, wenn die durch den Ausführungsknoten durchgeführten Aufgaben prozessorintensiver werden. Gleichermaßen kann ein Ausführungsknoten mehreren Cacheressourcen zugeordnet werden, wenn die durch den Ausführungsknoten durchgeführten Aufgaben eine größere Cachekapazität erfordern.
Obwohl die virtuellen Lager 1, 2 und n mit derselben Ausführungsplattform 1416 assoziiert sind, können die virtuellen Lager unter Verwendung von mehreren Computersystemen an mehreren geografischen Standorten implementiert werden. Zum Beispiel kann das virtuelle Lager 1 durch ein Computersystem an einem ersten geografischen Standort implementiert werden, während die virtuellen Lager 2 und n durch ein anderes Computersystem an einem zweiten geografischen Standort implementiert werden. Bei einigen Ausführungsformen sind diese unterschiedlichen Computersysteme cloudbasierte Computersysteme, die durch ein oder mehrere unterschiedliche Unternehmen unterhalten werden.
Zusätzlich ist jedes virtuelle Lager in 16 derart gezeigt, dass es mehrere Ausführungsknoten hat. Die mit jedem virtuellen Lager assoziierten mehreren Ausführungsknoten können unter Verwendung mehrerer Computersysteme an mehreren geografischen Standorten implementiert werden. Zum Beispiel implementiert eine Instanz des virtuellen Lagers Warehouse 1 die Ausführungsknoten 1602a und 1602b auf einer Computerplattform an einem geografischen Standort und implementiert den Ausführungsknoten 1602n auf einer anderen Computerplattform an einem anderen geografischen Standort. Ein Auswählen bestimmter Computersysteme, um einen Ausführungsknoten zu implementieren, kann von verschiedenen Faktoren abhängen, wie beispielsweise dem Ausmaß von Ressourcen, die für einen bestimmten Ausführungsknoten nötig sind (z.B. Verarbeitungsressourcenanforderungen und Cacheanforderungen), den Ressourcen, die bei bestimmten Computersystemen verfügbar sind, Kommunikationsfähigkeiten von Netzwerken innerhalb eines geografischen Standorts oder zwischen geografischen Standorten und welche Computersystemen bereits andere Ausführungsknoten im virtuellen Lager implementieren.
Die Ausführungsplattform 1416 ist auch fehlertolerant. Wenn zum Beispiel ein virtuelles Lager ausfällt, wird dieses virtuelle Lager schnell durch ein anderes virtuelles Lager an einem anderen geografischen Standort ersetzt.
Eine bestimmte Ausführungsplattform 1416 kann irgendeine Anzahl von virtuellen Lagern umfassen. Zusätzlich ist die Anzahl von virtuellen Lagern in einer bestimmten Ausführungsplattform dynamisch, so dass neue virtuelle Lager erstellt werden, wenn zusätzliche Verarbeitungs- und/oder Cachespeicherungs- bzw. Zwischenspeicherungs-Ressourcen nötig sind. Gleichermaßen können existierende virtuelle Lager gelöscht werden, wenn die mit dem virtuellen Lager assoziierten Ressourcen nicht mehr nötig sind.
Bei einigen Ausführungsformen können die virtuellen Lager an denselben Daten in der Speicherplattform 1410 arbeiten, hat aber jedes virtuelle Lager seine eigenen Ausführungsknoten mit unabhängigen Verarbeitungs- und Cachespeicherungs-Ressourcen. Diese Konfiguration lässt zu, dass Anforderungen an unterschiedlichen virtuellen Lagern unabhängig und ohne Interferenzen zwischen den Anforderungen verarbeitet werden. Diese unabhängige Verarbeitung, kombiniert mit der Fähigkeit, virtuelle Lager dynamisch hinzuzufügen und zu entfernen, unterstützt das Hinzufügen neuer Verarbeitungskapazitäten für neue Benutzer, ohne die von den existierenden Benutzern beobachtete Leistungsfähigkeit zu beeinflussen bzw. beeinträchtigen.
Bei einer Ausführungsform werden individuelle Ausführungsplattformen 1416 unterschiedlichen Konten in der mehrmandantenfähigen Datenbank 100 zugeteilt. Dies kann sicherstellen, dass im Cache in den individuellen Ausführungsplattformen 1416 gespeicherte Daten nur für das assoziierte Konto zugänglich gemacht werden. Die Größe jeder individuellen Ausführungsplattform 1416 kann auf die Verarbeitungsanforderungen jedes Kontos in der mehrmandantenfähigen Datenbank 100 zugeschnitten werden. Bei einer Ausführungsform hat ein Provider- bzw. Anbieterkonto seine eigene Ausführungsplattform 1416 und hat ein Empfängerkonto seine eigene Ausführungsplattform 1416. Bei einer Ausführungsform empfängt ein Empfängerkonto ein Teilungsobjekt vom Anbieterkonto, das es dem Empfängerkonto ermöglicht, eine materialisierte Ansicht über Daten zu erzeugen, die im Besitz des Anbieterkontos sind. Die Ausführungsplattform 1416 des Empfängerkontos kann die materialisierte Ansicht erzeugen. Wenn ein Update an der Quellentabelle für die materialisierte Ansicht (d.h. die Daten im Besitz des Anbieterkontos) vorgenommen wird, wird die Ausführungsplattform 1416 des Anbieterkontos das Update ausführen. Wenn das Empfängerkonto die materialisierte Ansicht erzeugte, dann kann die Ausführungsplattform 1416 des Empfängerkontos zum Auffrischen der materialisierten Ansicht in Bezug auf ihre Quellentabelle verantwortlich sein.
17 ist ein Blockdiagramm, das eine beispielhafte Betriebsumgebung 1700 mit der Warteschlange 1404 in Kommunikation mit mehreren virtuellen Lagern unter einem Manager für virtuelle Lager 1702 darstellt. In der Umgebung 1700 hat die Warteschlange 1404 Zugriff auf mehrere geteilte Speichervorrichtungen der Datenbank 1706a, 1706b, 1706c, 1706d, 1706e und 1706n über mehrere virtuelle Lager 1704a, 1704b und 1704n. Obwohl es in 17 nicht gezeigt ist, kann die Warteschlange 1404 über den Computing-Service-Manager 1402 auf die virtuellen Lager 1704a, 1704b und 1704n zugreifen (siehe 1). Bei bestimmten Ausführungsformen sind die Datenbanken 1706a-1706n in der Speicherplattform 1410 enthalten und sind durch irgendein in der Ausführungsplattform 1416 implementiertes virtuelles Lager zugänglich. Bei einigen Ausführungsformen kann die Warteschlange 1404 unter Verwendung eines Datenkommunikationsnetzwerks, wie beispielsweise das Internet, auf eines der virtuellen Lager 1704a-1704n zugreifen. Bei einigen Implementierungen kann ein Clientkonto spezifizieren, dass die Warteschlange 1404 (konfiguriert zum Speichern interner Jobs, die abgeschlossen werden sollen) zu einer bestimmten Zeit mit einem bestimmten virtuellen Lager 1704a-1704n interagieren sollte.
Bei einer Ausführungsform (wie sie dargestellt ist) kann jedes virtuelle Lager 1704a-1704n mit allen Datenbanken 1706a-1706n kommunizieren. Bei einigen Ausführungsformen ist jedes virtuelle Lager 1704a-1704n konfiguriert, um mit einer Untergruppe bzw. Teilmenge aller Datenbanken 1706a-1706n zu kommunizieren. Bei einer solchen Ausgestaltung kann ein mit einem Datensatz assoziiertes einzelnes Clientkonto alle Datenwiedergewinnungs- und Datenspeicherungsanforderungen über ein einzelnes virtuelles Lager und/oder zu einer bestimmten Teilmenge der Datenbanken 1706a-1706n senden. Weiterhin ist dort, wo ein bestimmtes virtuelles Lager 1704a-1704n konfiguriert ist, um mit einer spezifischen Teilmenge der Datenbanken 1706a-1706n zu kommunizieren, die Konfiguration dynamisch. Zum Beispiel kann das virtuelle Lager 1704a konfiguriert sein, um mit einer ersten Teilmenge der Datenbanken 1706a-1706n zu kommunizieren, und kann später neu konfiguriert werden, um mit einer zweiten Teilmenge der Datenbanken 1706a-1706n zu kommunizieren.
Bei einer Ausführungsform sendet die Warteschlange 1404 Datenwiedergewinnungs-, Datenspeicherungs- und Datenverarbeitungsanforderungen zum Manager für virtuelle Lager 1702, der die Anforderungen zu einem geeigneten virtuellen Lager 1704a-1704n führt. Bei einigen Implementierungen stellt der Manager für virtuelle Lager 1702 eine dynamische Zuordnung von Jobs zu den virtuellen Lagern 1704a-1704n bereit.
Bei einigen Ausführungsformen erstellen fehlertolerante Systeme ein neues virtuelles Lager in Reaktion auf einen Fehler bzw. Ausfall eines virtuellen Lagers. Das neue virtuelle Lager kann in derselben Gruppe virtueller Lager sein oder kann in einer anderen Gruppe virtueller Lager an einem anderen geografischen Standort erstellt werden.
Die hierin beschriebenen Systeme und Verfahren lassen als Dienst zu, der von Computing- (oder Verarbeitungs-) Ressourcen getrennt ist, dass Daten gespeichert werden und auf sie zugegriffen wird. Auch wenn keine Computerressourcen von der Ausführungsplattform 1416 zugeteilt worden sind, stehen Daten einem virtuellen Lager zur Verfügung, ohne ein erneutes Laden der Daten aus einer entfernten Datenquelle zu erfordern. Somit sind Daten unabhängig von der Zuteilung von mit den Daten assoziierten Computerressourcen verfügbar. Die beschriebenen Systeme und Verfahren sind bei irgendeinem Typ von Daten nützlich. Bei bestimmten Ausführungsformen werden Daten in einem strukturierten, optimierten Format gespeichert. Die Entkopplung des Datenspeicherungs-/-zugriffsdienstes von den Computingdiensten vereinfacht auch die gemeinsame Nutzung bzw. Teilung von Daten unter unterschiedlichen Benutzern und Gruppen. Wie es hierin diskutiert ist, kann jedes virtuelle Lager auf irgendwelche Daten zugreifen, für welche es Zugriffsberechtigungen hat, auch zu derselben Zeit, zu welcher andere virtuelle Lager auf dieselben Daten zugreifen. Diese Architektur unterstützt ein Ausführen von Abfragen, ohne dass tatsächliche bzw. aktuelle Daten im lokalen Cache gespeichert sind. Die hierin beschriebenen Systeme und Verfahren sind zu einer transparenten dynamischen Datenbewegung fähig, die Daten, wie es nötig ist, von einer entfernten Speichervorrichtung auf eine Weise zu einem lokalen Cache bewegt, die für den Benutzer des Systems transparent ist. Weiterhin unterstützt diese Architektur eine gemeinsame Nutzung bzw. Teilung von Daten ohne vorherige Datenbewegung, da irgendein virtuelles Lager aufgrund der Entkopplung des Datenspeicherdienstes vom Computingdienst auf irgendwelche Daten zugreifen kann.
18 ist ein schematisches Blockdiagramm eines Verfahrens 1800 zur kontoübergreifenden Erzeugung einer materialisierten Ansicht in einem mehrmandantenfähigen Datenbanksystem. Das Verfahren 1800 kann durch irgendeine geeigneten Computervorrichtung, wie beispielsweise eine Computing-Service-Manager 1402, eine Teilungskomponente 210 und/oder eine Komponente für materialisierte Ansicht 914 ausgeführt werden. Das Verfahren 1800 kann durch Verarbeitungsressourcen herumgetragen bzw. ausgeführt werden, die einem ersten Konto und/oder einem zweiten Konto zugeteilt sind.
Das Verfahren 1800 beginnt und eine Computerressource definiert bei 1802 ein Teilungsobjekt in einem ersten Konto. Das Teilungsobjekt enthält mit dem ersten Konto assoziierte Daten. Das Verfahren 1800 enthält bei 1804 ein Gewähren von kontoübergreifenden Zugriffsrechten für das Teilungsobjekt einem zweiten Konto, so dass das zweite Konto einen Zugriff auf das Teilungsobjekt hat, ohne das Teilungsobjekt zu kopieren. Das Verfahren 1800 enthält bei 1806 ein Erzeugen einer materialisierten Ansicht über das Teilungsobjekt. Das Verfahren 1800 enthält bei 1808 ein Updaten der mit dem ersten Konto assoziierten Daten. Das Verfahren 1800 enthält bei 1810 ein Identifizieren, ob die materialisierte Ansicht in Bezug auf das Teilungsobjekt veraltet ist, durch Zusammenführen bzw. Verknüpfen der materialisierten Ansicht und des Teilungsobjekts.
19 ist ein schematisches Blockdiagramm eines Verfahrens 1900 zum kontoübergreifenden Teilen einer materialisierten Ansicht in einem mehrmandantenfähigen Datenbanksystem. Das Verfahren 1900 kann durch irgendeine geeignete Computervorrichtung, wie beispielsweise einen Computing-Service-Manager 1402, eine Teilungskomponente 210 und/oder eine Komponente für materialisierte Ansicht 914, ausgeführt werden. Das Verfahren 1900 kann durch Verarbeitungsressourcen herumgetragen bzw. ausgeführt werden, die einem ersten und/oder einem zweiten Konto zugeteilt sind.
Das Verfahren 1900 beginnt und eine Computerressource definiert bei 1902 eine materialisierte Ansicht über eine Quellentabelle, die mit einem ersten Konto einer mehrmandantenfähigen Datenbank assoziiert ist. Das Verfahren 1900 wird fortgesetzt und eine Computerressource definiert bei 1904 kontoübergreifende Zugriffsrechte auf die materialisierte Ansicht zu einem zweiten Konto, so dass das zweite Konto die materialisierte Ansicht lesen kann, ohne die materialisierte Ansicht zu kopieren. Das Verfahren 1900 wird fortgesetzt und eine Computerressource modifiziert bei 1906 die Quellentabelle für die materialisierte Ansicht. Das Verfahren 1900 wird fortgesetzt und eine Computerressource identifiziert bei 1908, ob die materialisierte Ansicht in Bezug auf die Quellentabelle veraltet ist, durch Zusammenführen bzw. Verknüpfen der materialisierten Ansicht und der Quellentabelle.
20 ist ein Blockdiagramm, das eine beispielhafte Computervorrichtung 2000 darstellt. Bei einigen Ausführungsformen wird die Computervorrichtung 2000 verwendet, um eines oder mehrere der hierin diskutierten Systeme und Komponenten zu implementieren. Weiterhin kann die Computervorrichtung 2000 mit jedem der hierin beschriebenen Systeme und Komponenten interagieren. Demgemäß kann die Computervorrichtung 2000 verwendet werden, um verschiedene Prozeduren bzw. Verfahren und Aufgaben auszuführen, wie beispielsweise diejenigen, die hierin diskutiert sind. Die Computervorrichtung 2000 kann als Server, Client oder jede andere Computing- bzw. Computereinheit fungieren. Die Computervorrichtung 2000 kann irgendeine einer Vielzahl von Computervorrichtungen sein, wie beispielsweise ein Desktop-Computer, ein Notebook-Computer, ein Servercomputer, ein Handheld-Computer, ein Tablet und dergleichen.
Die Computervorrichtung 2000 enthält einen oder mehrere Prozessoren 2002, eine oder mehrere Speichervorrichtungen 2004, eine oder mehrere Schnittstellen 2006, eine oder mehrere Massenspeichervorrichtungen 2008 und eine oder mehrere Eingabe-/Ausgabe-(I/O-)Vorrichtungen (E/A) 2010, von welchen alle mit einem Bus 2012 gekoppelt sind. Der (Die) Prozessor(en) 2002 enthält (enthalten) einen oder mehrere Prozessoren oder Steuerungen, die Anweisungen ausführen, die in der (den) Speichervorrichtung(en) 2004 und/oder der (den) Massenspeichervorrichtung(en) 2008 gespeichert sind. Der (Die) Prozessor(en) 2002 kann (können) auch verschiedene Typen von computerlesbaren Medien enthalten, wie beispielsweise einen Cachespeicher.
Die Speichervorrichtung(en) 2004 enthält (enthalten) verschiedene computerlesbare Medien, wie beispielsweise einen flüchtigen Speicher (z.B. einen Direktzugriffsspeicher (RAM)) und/oder einen nichtflüchtigen Speicher (z.B. einen Nurlesespeicher (ROM)). Die Speichervorrichtung(en) 2004 kann (können) auch einen wiederbeschreibbaren ROM enthalten, wie beispielsweise einen Flash-Speicher.
Die Massenspeichervorrichtung(en) 2008 enthält (enthalten) verschiedene computerlesbare Medien, wie beispielsweise Magnetbänder, Magnetplatten, optische Platten, einen Festkörperspeicher (z.B. einen Flash-Speicher) und so weiter. Verschiedene Laufwerke können auch in der (den) Massenspeichervorrichtung(en) 2008 enthalten sein, um ein Lesen von und/oder ein Schreiben zu den verschiedenen computerlesbaren Medien zu ermöglichen. Die Massenspeichervorrichtung(en) 2008 enthält (enthalten) Wechselmedien bzw. -datenträger und/oder nicht entfernbare Medien bzw. Datenträger.
Die I/O-Vorrichtung(en) 2010 enthält (enthalten) verschiedene Vorrichtungen, die zulassen, Daten und/oder andere Information zur der Computervorrichtung 2000 einzugeben oder daraus wiederzugewinnen. Beispiele für die I/O-Vorrichtung(en) 2010 enthalten Cursorsteuerungsvorrichtung, Tastaturen, Kleintastaturen, Mikrofone, Monitore oder andere Anzeigevorrichtungen, Lautsprecher, Drucker, Netzwerkschnittstellenkarten, Modems, Objektive, CCDs oder andere Bilderfassungsvorrichtungen und dergleichen.
Die Schnittstelle(n) 2006 enthält (enthalten) verschiedene Schnittstellen, die zulassen, dass die Computervorrichtung 2000 mit anderen Systemen, Vorrichtungen oder Computerumgebungen interagiert. Beispiele für die Schnittstelle(n) 2006 enthalten irgendeine Anzahl unterschiedlicher Netzwerkschnittstellen, wie beispielsweise Schnittstellen zu lokalen Netzwerken (LANs), Weitverkehrsnetzwerken (WANs), drahtlosen Netzwerken und dem Internet.
Der Bus 2012 lässt zu, dass der (die) Prozessor(en) 2002, die Speichervorrichtung(en) 2004, die Schnittstelle(n) 2006, die Massenspeichervorrichtung(en) 2008 und die I/O-Vorrichtung(en) 2010 miteinander sowie mit anderen Vorrichtungen oder Komponenten, die mit Bus 2012 gekoppelt sind, kommunizieren. Der Bus 2012 stellt einen oder mehrere von mehreren Typen von Busstrukturen dar, wie beispielsweise einen Systembus, einen PCI-Bus, einen IEEE-1394-Bus, einen USB-Bus und so weiter.
Zu Darstellungszwecken sind Programme und andere ausführbare Programmkomponenten hierin als diskrete Blöcke dargestellt, obwohl es verstanden wird, dass sich solche Programme und Komponenten zu verschiedenen Zeiten in unterschiedlichen Speicherkomponenten der Computervorrichtung 2000 befinden können und durch den (die) Prozessor(en) 2002 ausgeführt werden. Alternativ können die hierin beschriebenen Systeme und Verfahren in Hardware oder einer Kombination aus Hardware, Software und/oder Firmware implementiert sein. Zum Beispiel kann eine oder können mehrere anwendungsspezifische integrierte Schaltungen (ASICs) programmiert werden, um eines oder mehrere der hierin beschriebenen Systeme und Verfahren auszuführen. Wie sie hierin verwendet sind, sollen die Begriffe „Modul“ oder „Komponente“ die Implementierungsvorrichtung zum Erreichen eines Prozesses, wie beispielsweise durch Hardware oder eine Kombination aus Hardware, Software und/oder Firmware, zu Zwecken eines Durchführens von allen oder Teilen der hierin offenbarten Operationen vermitteln.
Beispiele
Die folgenden Beispiele gehören zu weiteren Ausführungsformen.
Beispiel 1 ist ein System zur kontoübergreifenden Datenteilung in einer mehrmandantenfähigen Datenbank. Das System enthält Mittel zum Definieren eines Teilungsobjekts in einem ersten Konto, wobei das Teilungsobjekt mit dem ersten Konto assoziierte Daten umfasst. Das System enthält Mittel zum Gewähren von kontoübergreifenden Zugriffsrechten auf das Teilungsobjekt für ein zweites Konto, so dass das zweite Konto Zugriff auf das Teilungsobjekt hat, ohne das Teilungsobjekt zu kopieren. Das System enthält Mittel zum Erzeugen einer materialisierten Ansicht über das Teilungsobjekt. Das System enthält Mittel zum Updaten der mit dem ersten Konto assoziierten Daten. Das System enthält Mittel zum Identifizieren, ob die materialisierte Ansicht in Bezug auf das Teilungsobjekt veraltet ist, durch Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und des Teilungsobjekts.
Beispiel 2 ist ein System wie beim Beispiel 1, wobei die Mittel zum Identifizieren, ob die materialisierte Ansicht in Bezug auf das Teilungsobjekt veraltet ist, folgendes umfasst: Mittel zum Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und des Teilungsobjekts; Mittel zum Identifizieren, ob Daten im Teilungsobjekt seit einer letzten Auffrischung der materialisierten Ansicht modifiziert worden sind, wobei die Daten im Teilungsobjekt durch eines oder mehreres von einem Updaten, einem Löschen oder einem Einfügen modifiziert sein können; und Mittel zum Auffrischen der materialisierten Ansicht in Bezug auf das Teilungsobjekt in Reaktion auf ein Identifizieren einer Modifikation am Teilungsobjekt seit der letzten Auffrischung der materialisierten Ansicht.
Beispiel 3 ist ein System wie bei einem der Beispiele 1-2, das weiterhin Mittel zum Abfragen des Teilungsobjekts umfasst, wobei die Mittel zum Abfragen folgendes umfassen: Mittel zum Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und des Teilungsobjekts; und Mittel zum Ausführen der Abfrage basierend auf Information in der materialisierten Ansicht und irgendwelchen seit einer letzten Auffrischung der materialisierten Ansicht am Teilungsobjekt vorgenommenen Modifikationen.
Beispiel 4 ist ein System wie bei einem der Beispiele 1-3, das weiterhin folgendes umfasst: Mittel zum Speichern der mit dem ersten Konto assoziierten Daten quer über eine oder mehrere einer Vielzahl von gemeinsam genutzten bzw. geteilten Speichervorrichtungen; Mittel zum Definieren einer mit dem ersten Konto assoziierten Ausführungsplattform, das einen Lesezugriff und einen Schreibzugriff für die mit dem ersten Konto assoziierten Daten hat; und Mittel zum Definieren einer mit dem zweiten Konto assoziierten Ausführungsplattform, das einen Lesezugriff auf das Teilungsobjekt hat.
Beispiel 5 ist ein System wie bei einem der Beispiele 1-4, wobei: die Mittel zum Erzeugen der materialisierten Ansicht über das Teilungsobjekt in der mit dem zweiten Konto assoziierten Ausführungsplattform eingebunden bzw. enthalten sind; die Mittel zum Updaten der mit dem ersten Konto assoziierten Daten in der mit dem ersten Konto assoziierten Ausführungsplattform eingebunden bzw. enthalten sind; und die Mittel zum Identifizieren, ob die materialisierte Ansicht in Bezug auf das Teilungsobjekt veraltet ist, in der mit dem zweiten Konto assoziierten Ausführungsplattform eingebunden bzw. enthalten sind.
Beispiel 6 ist ein System wie bei einem der Beispiele 1-5, das weiterhin Mittel zum Definieren einer Definition einer sicheren Ansicht für die materialisierte Ansicht umfasst, wobei die Mittel zum Definieren der Definition einer sicheren Ansicht eines oder mehreres von folgendem umfassen: Mittel zum Gewähren eine Lesezugriffs und eines Schreibzugriffs auf die materialisierte Ansicht dem zweiten Konto; Mittel zum Gewähren eines Lesezugriffs auf die materialisierte Ansicht dem ersten Konto; oder Mittel zum Ausblenden bzw. Verstecken der materialisierten Ansicht vor dem ersten Konto, so dass das erste Konto keinen Einblick diesbezüglich hat, ob die materialisierte Ansicht erzeugt wurde.
Beispiel 7 ist ein System wie bei einem der Beispiele 1-6, das weiterhin Mittel zum Definieren von Ansichtsprivilegien für die kontoübergreifenden Zugriffsrechte auf das Teilungsobjekt umfasst, so dass ein zugrunde liegendes Detail des Teilungsobjekts eine Definition einer sicheren Ansicht umfasst, wobei das zugrunde liegende Detail des Teilungsobjekts eines oder mehrere von folgenden umfasst: ein Datenfeld im Teilungsobjekt; eine Datenspalte im Teilungsobjekt; ein strukturelles Element einer zugrunde liegenden Tabelle des Teilungsobjekts; oder eine Datenmenge im Teilungsobjekt.
Beispiel 8 ist ein System wie bei einem der Beispiele 1-7, wobei die Mittel zum Definieren der Ansichtsprivilegien für die kontoübergreifenden Zugriffsrechte auf das Teilungsobjekt Mittel zum Ausblenden bzw. Verstecken der Ansichtsprivilegien vor dem zweiten Konto und Mittel zum Sichtbarmachen der Ansichtsprivilegien für das erste Konto umfassen.
Beispiel 9 ist ein System wie bei einem der Beispiele 1-8, wobei die Mittel zum Definieren des Teilungsobjekts eines oder mehreres von folgendem umfassen: Mittel zum Definieren eines Objektnamens, der für das erste Konto eindeutig ist; Mittel zum Definieren einer Objektrolle; oder Mittel zum Erzeugen einer Referenzliste, die eine Liste von einem oder mehreren Konten enthält, die berechtigt sind zum Empfangen kontoübergreifender Zugriffsrechte auf das Teilungsobjekt.
Beispiel 10 ist ein System wie bei einem der Beispiele 1-9, das weiterhin folgendes umfasst: Mittel zum Empfangen einer Anforderung vom zweiten Konto, um eine materialisierte Ansicht über bestimmte mit dem ersten Konto assoziierte Daten zu erzeugen; Mittel zum Identifizieren, ob die bestimmten Daten im Teilungsobjekt enthalten sind; Mittel zum Gewähren einer Autorisierung dem zweiten Konto, um die materialisierte Ansicht über die bestimmten Daten zu erzeugen; und Mittel zum Bereitstellen einer Benachrichtigung zum ersten Konto, die anzeigt, dass das zweite Konto eine Autorisierung, um die materialisierte Ansicht über die bestimmten Daten zu erzeugen, empfing.
Beispiel 11 ist ein Verfahren zur kontoübergreifenden Datenteilung in einer mehrmandantenfähigen Datenbank. Das Verfahren enthält ein Definieren eines Teilungsobjekts in einem ersten Konto, wobei das Teilungsobjekt mit dem ersten Konto assoziierte Daten umfasst. Das Verfahren enthält eine Gewähren kontoübergreifender Zugriffsrechte auf das Teilungsobjekt für ein zweites Konto, so dass das zweite Konto Zugriff auf das Teilungsobjekt hat, ohne das Teilungsobjekt zu kopieren. Das Verfahren enthält ein Erzeugen einer materialisierten Ansicht über das Teilungsobjekt. Das Verfahren enthält ein Updaten der mit dem ersten Konto assoziierten Daten. Das Verfahren enthält ein Identifizieren, ob die materialisierte Ansicht in Bezug auf das Teilungsobjekt veraltet ist, durch Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und des Teilungsobjekts.
Beispiel 12 ist ein Verfahren wie beim Beispiel 11, wobei ein Identifizieren, ob die materialisierte Ansicht in Bezug auf das Teilungsobjekt veraltet ist, folgendes umfasst: Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und des Teilungsobjekts; Identifizieren, ob Daten im Teilungsobjekt seit einer letzten Auffrischung der materialisierten Ansicht modifiziert worden sind, wobei die Daten im Teilungsobjekt durch eines oder mehreres von einem Updaten, einem Löschen oder einem Einfügen modifiziert sein können; und Auffrischen der materialisierten Ansicht in Bezug auf das Teilungsobjekt in Reaktion auf das Identifizieren einer Modifikation am Teilungsobjekt seit der letzten Auffrischung der materialisierten Ansicht.
Beispiel 13 ist ein Verfahren wie bei einem der Beispiele 11-12, das weiterhin ein Abfragen des Teilungsobjekts durch folgendes umfasst: Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und des Teilungsobjekts; und Ausführen der Abfrage basierend auf Information in der materialisierten Ansicht und irgendeiner seit einer letzten Auffrischung der materialisierten Ansicht am Teilungsobjekt vorgenommenen Modifikation.
Beispiel 14 ist ein Verfahren wie bei einem der Beispiele 11-13, das weiterhin folgendes umfasst: Speichern der mit dem ersten Konto assoziierten Daten quer über eine oder mehrere einer Vielzahl von gemeinsam genutzten bzw. geteilten Speichervorrichtungen; Definieren einer mit dem ersten Konto assoziierten Ausführungsplattform, das einen Lesezugriff und einen Schreibzugriff für die mit dem ersten Konto assoziierten Daten hat; und Definieren einer mit dem zweiten Konto assoziierten Ausführungsplattform, das einen Lesezugriff auf das Teilungsobjekt hat.
Beispiel 15 ist ein Verfahren wie bei einem der Beispiele 11-14, wobei: das Erzeugen der materialisierten Ansicht über das Teilungsobjekt durch die mit dem zweiten Konto assoziierte Ausführungsplattform verarbeitet wird; das Updaten der mit dem ersten Konto assoziierten Daten durch die mit dem ersten Konto assoziierte Ausführungsplattform verarbeitet wird; und das Identifizieren, ob die materialisierte Ansicht in Bezug auf das Teilungsobjekt veraltet ist, durch die mit dem zweiten Konto assoziierte Ausführungsplattform verarbeitet wird.
Beispiel 16 ist ein Prozessor, der konfigurierbar ist, um Anweisungen auszuführen, die in einem nicht transitorischen bzw. nichtflüchtigen computerlesbaren Speichermedium gespeichert sind, wobei die Anweisungen folgendes umfassen: Definieren eines Teilungsobjekts in einem ersten Konto, wobei das Teilungsobjekt mit dem ersten Konto assoziierte Daten umfasst; Gewähren von kontoübergreifenden Zugriffsrechten auf das Teilungsobjekt für ein zweites Konto, so dass das zweite Konto Zugriff auf das Teilungsobjekt hat, ohne das Teilungsobjekt zu kopieren; Erzeugen einer materialisierten Ansicht über das Teilungsobjekt; Updaten der mit dem ersten Konto assoziierten Daten; und Identifizieren, ob die materialisierte Ansicht in Bezug auf das Teilungsobjekt veraltet ist, durch Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und des Teilungsobjekts.
Beispiel 17 ist ein Prozessor wie beim Beispiel 16, wobei das Identifizieren, ob die materialisierte Ansicht in Bezug auf das Teilungsobjekt veraltet ist, folgendes umfasst: Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und des Teilungsobjekts; Identifizieren, ob Daten im Teilungsobjekt seit einer letzten Auffrischung der materialisierten Ansicht modifiziert worden sind, wobei die Daten im Teilungsobjekt durch eines oder mehreres von einem Updaten, einem Löschen oder einem Einfügen modifiziert sein können; und Auffrischen der materialisierten Ansicht in Bezug auf das Teilungsobjekt in Reaktion auf das Identifizieren einer Modifikation am Teilungsobjekt seit der letzten Auffrischung der materialisierten Ansicht.
Beispiel 18 ist ein Prozessor wie bei einem der Beispiele 16-17, wobei die Anweisungen weiterhin ein Abfragen des Teilungsobjekts durch folgendes umfassen: Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und des Teilungsobjekts; und Ausführen der Abfrage basierend auf Information in der materialisierten Ansicht und irgendwelchen seit einer letzten Auffrischung der materialisierten Ansicht am Teilungsobjekt vorgenommenen Modifikationen.
Beispiel 19 ist ein Prozessor wie bei einem der Beispiele 16-18, wobei die Anweisungen weiterhin ein Definieren einer Definition einer sicheren Ansicht für die materialisierte Ansicht durch eines oder mehreres von folgendem umfassen: Gewährung eines Lesezugriffs und eines Schreibzugriffs auf die materialisierte Ansicht für das zweite Konto; Gewähren eines Lesezugriffs auf die materialisierte Ansicht für das erste Konto; oder Ausblenden bzw. Verstecken der materialisierten Ansicht vor dem ersten Konto, so dass das erste Konto keinen Einblick diesbezüglich hat, ob die materialisierte Ansicht erzeugt wurde.
Beispiel 20 ist ein Prozessor wie bei einem der Beispiele 16-19, wobei die Anweisungen weiterhin ein Definieren von Ansichtsprivilegien für die kontoübergreifenden Zugriffsrechte auf das Teilungsobjekt umfassen, so dass ein zugrunde liegendes Detail des Teilungsobjekts eine Definition einer sicheren Ansicht umfasst, wobei das zugrunde liegende Detail des Teilungsobjekts eines oder mehreres von folgendem umfasst: ein Datenfeld im Teilungsobjekt; eine Datenspalte im Teilungsobjekt; ein strukturelles Element einer zugrunde liegenden Tabelle des Teilungsobjekts; oder eine Datenmenge im Teilungsobjekt.
Beispiel 21 ist ein System zur kontoübergreifenden Teilung einer materialisierten Ansicht in einer mehrmandantenfähigen Datenbank. Das System enthält Mittel zum Definieren einer materialisierten Ansicht über eine Quellentabelle, wobei die Quellentabelle mit einem ersten Konto der mehrmandantenfähigen Datenbank assoziiert ist. Das System enthält Mittel zum Definieren von kontoübergreifenden Zugriffsrechten auf die materialisierte Ansicht zu einem zweiten Konto, so dass das zweite Konto einen Zugriff hat, um die materialisierte Ansicht zu lesen. Das System enthält Mittel zum Modifizieren der Quellentabelle für die materialisierte Ansicht. Das System enthält Mittel zum Identifizieren, ob die materialisierte Ansicht in Bezug auf die Quellentabelle veraltet ist, durch Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und der Quellentabelle.
Beispiel 22 ist ein System wie beim Beispiel 21, wobei die Mittel zum Definieren der kontoübergreifenden Zugriffsrechte auf die materialisierte Ansicht weiterhin Mittel zum Definieren der kontoübergreifenden Zugriffsrechte umfassen, so dass das zweite Konto keinen Zugriff hat, um die Quellentabelle für die materialisierte Ansicht zu lesen oder zur Quellentabelle für die materialisierte Ansicht zu schreiben.
Beispiel 23 ist ein System wie bei einem der Beispiele 21-22, wobei die Mittel zum Identifizieren, ob die materialisierte Ansicht in Bezug auf die Quellentabelle veraltet ist, folgendes umfassen: Mittel zum Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und der Quellentabelle; und Mittel zum Identifizieren, ob Daten in der Quellentabelle seit einer letzten Auffrischung der materialisierten Ansicht modifiziert worden sind; wobei das System weiterhin Mittel zum Auffrischen der materialisierten Ansicht in Bezug auf die materialisierte Ansicht in Bezug auf die Quellentabelle in Reaktion auf ein Identifizieren einer Modifikation an der Quellentabelle seit der letzten Auffrischung der materialisierten Ansicht umfasst.
Beispiel 24 ist ein System wie bei einem der Beispiele 21-23, das weiterhin folgendes umfasst: Mittel zum Speichern der mit dem ersten Konto assoziierten Quellentabelle quer über eine oder mehrere einer Vielzahl von über die mehrmandantenfähige Datenbank gemeinsam genutzten bzw. geteilten Speichervorrichtungen; Mittel zum Definieren einer mit dem ersten Konto assoziierten Ausführungsplattform, das einen Lesezugriff und einen Schreibzugriff auf die Quellentabelle für die materialisierte Ansicht hat; und Mittel zum Definieren einer mit dem zweiten Konto assoziierten Ausführungsplattform, das einen Lesezugriff auf die materialisierte Ansicht hat.
Beispiel 25 ist ein System wie bei einem der Beispiele 21-24, wobei: die mit dem ersten Konto assoziierte Ausführungsplattform die Mittel zum Definieren der materialisierten Ansicht enthält; und die mit dem ersten Konto assoziierte Ausführungsplattform die Mittel zum Modifizieren der Quellentabelle für die materialisierte Ansicht enthält.
Beispiel 26 ist ein System wie bei einem der Beispiele 21-25, das weiterhin Mittel zum Definieren von Ansichtsprivilegien für die kontoübergreifenden Zugriffsrechte auf die materialisierte Ansicht umfasst, so dass ein zugrunde liegendes Detail der Quellentabelle für die materialisierte Ansicht eine Definition einer sicheren Ansicht umfasst, wobei das zugrunde liegende Detail der Quellentabelle eines oder mehreres von folgendem umfasst: ein Datenfeld in der Quellentabelle; eine Datenspalte in der Quellentabelle; ein strukturelles Element der Quellentabelle; eine Datenmenge in der Quellentabelle; Metadaten für die Quellentabelle; oder ein Transaktionsprotokoll von an der Quellentabelle vorgenommenen Modifikationen.
Beispiel 27 ist ein System wie bei einem der Beispiele 21-26, wobei die Mittel zum Definieren der Ansichtsprivilegien für die kontoübergreifenden Zugriffsrechte auf die materialisierte Ansicht Mittel zum Ausblenden bzw. Verstecken der Ansichtsprivilegien vor dem zweiten Konto und Mittel zum Sichtbarmachen der Ansichtsprivilegien für das erste Konto umfassen.
Beispiel 28 ist ein System wie bei einem der Beispiele 21-27, das weiterhin Mittel zum Definieren einer Referenzliste umfasst, die eine Liste von einem oder mehreren Konten umfasst, die zum Empfangen kontoübergreifender Zugriffsrechte auf die materialisierte Ansicht berechtigt sind.
Beispiel 29 ist ein System wie bei einem der Beispiele 21-28, das weiterhin folgendes umfasst: Mittel zum Empfangen einer Anforderung vom zweiten Konto, um die materialisierte Ansicht über bestimmte in der Quellentabelle gespeicherte Daten zu erzeugen; Mittel zum Bereitstellen der Anforderung zum ersten Konto zur Genehmigung oder Ablehnung; und Mittel zum Bereitstellen einer Benachrichtigung zum zweiten Konto, die anzeigt, ob die Anforderung durch das erste Konto genehmigt oder abgelehnt wurde.
Beispiel 30 ist ein System wie bei einem der Beispiele 21-29, das weiterhin Mittel zum Bereitstellen einer Benachrichtigung zum zweiten Konto umfasst, die anzeigt, dass die materialisierte Ansicht in Bezug auf die Quellentabelle veraltet ist, in Reaktion auf ein Identifizieren, dass die materialisierte Ansicht in Bezug auf die Quellentabelle veraltet ist.
Beispiel 31 ist ein Verfahren zur kontoübergreifenden Teilung einer materialisierten Ansicht in einer mehrmandantenfähigen Datenbank. Das Verfahren enthält ein Definieren einer materialisierten Ansicht über eine Quellentabelle, wobei die Quellentabelle mit einem ersten Konto der mehrmandantenfähigen Datenbank assoziiert ist. Das Verfahren enthält ein Definieren von kontoübergreifenden Zugriffsrechten auf die materialisierte Ansicht für ein zweites Konto, so dass das zweite Konto einen Zugriff hat, um die materialisierte Ansicht zu lesen. Das Verfahren enthält ein Modifizieren der Quellentabelle für die materialisierte Ansicht. Das Verfahren enthält ein Identifizieren, ob die materialisierte Ansicht in Bezug auf die Quellentabelle veraltet ist, durch Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und der Quellentabelle.
Beispiel 32 ist ein Verfahren wie beim Beispiel 31, wobei ein Definieren der kontoübergreifenden Zugriffsrechte auf die materialisierte Ansicht weiterhin ein Definieren der kontoübergreifenden Zugriffsrechte umfasst, so dass das zweite Konto keinen Zugriff hat, um die Quellentabelle für die materialisierte Ansicht zu lesen oder zur Quellentabelle für die materialisierte Ansicht zu schreiben.
Beispiel 33 ist ein Verfahren wie bei einem der Beispiele 31-32, wobei ein Identifizierung, ob die materialisierte Ansicht in Bezug auf die Quellentabelle veraltet ist, folgendes umfasst: Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und der Quellentabelle; und Identifizieren, ob Daten in der Quellentabelle seit einer letzten Auffrischung der materialisierten Ansicht modifiziert worden sind; wobei das Verfahren weiterhin ein Auffrischen der materialisierten Ansicht in Bezug auf die Quellentabelle in Reaktion auf ein Identifizieren einer Modifikation an die Quellentabelle seit der letzten Auffrischung der materialisierten Ansicht umfasst.
Beispiel 34 ist ein Verfahren wie bei einem der Beispiele 31-33, das weiterhin ein Definieren von Ansichtsprivilegien für die kontoübergreifenden Zugriffsrechte auf die materialisierte Ansicht umfasst, so dass ein zugrunde liegendes Detail der Quellentabelle für die materialisierte Ansicht eine Definition einer sicheren Ansicht umfasst, wobei das zugrunde liegende Detail der Quellentabelle eines oder mehreres von folgendem umfasst: ein Datenfeld in der Quellentabelle; eine Datenspalte in der Quellentabelle; ein strukturelles Element der Quellentabelle; eine Datenmenge in der Quellentabelle; Metadaten für die Quellentabelle; oder ein Transaktionsprotokoll von an der Quellentabelle vorgenommenen Modifikationen.
Beispiel 35 ist ein Verfahren wie bei einem der Beispiele 31-34, das weiterhin ein Definieren einer Referenzliste umfasst, die eine Liste von einem oder mehreren Konten umfasst, die zum Empfangen kontoübergreifender Zugriffsrechte auf die materialisierte Ansicht berechtigt sind.
Beispiel 36 ist ein Prozessor, der konfigurierbar ist, um Anweisungen auszuführen, die auf nicht transitorischen bzw. nichtflüchtigen computerlesbaren Speichermedien gespeichert sind. Die Anweisungen enthalten ein Definieren einer materialisierten Ansicht über eine Quellentabelle, wobei die Quellentabelle mit einem ersten Konto der mehrmandantenfähigen Datenbank assoziiert ist. Die Anweisungen enthalten ein Definieren von kontoübergreifenden Zugriffsrechten auf die materialisierte Ansicht zu einem zweiten Konto bzw. für ein zweites Konto, so dass das zweite Konto einen Zugriff hat, um die materialisierte Ansicht zu lesen. Die Anweisungen enthalten ein Modifizieren der Quellentabelle für die materialisierte Ansicht. Die Anweisungen enthalten ein Identifizieren, ob die materialisierte Ansicht in Bezug auf die Quellentabelle veraltet ist, durch Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und der Quellentabelle.
Beispiel 37 ist ein Prozessor wie beim Beispiel 36, wobei ein Definieren der kontoübergreifenden Zugriffsrechte auf die materialisierte Ansicht weiterhin ein Definieren der kontoübergreifenden Zugriffsrechte umfasst, so dass das zweite Konto keinen Zugriff hat, um die Quellentabelle für die materialisierte Ansicht zu lesen oder zur Quellentabelle für die materialisierte Ansicht zu schreiben.
Beispiel 38 ist ein Prozessor wie bei einem der Beispiele 36-37, wobei ein Identifizieren, ob die materialisierte Ansicht in Bezug auf die Quellentabelle veraltet ist, folgendes umfasst: Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und der Quellentabelle; und Identifizieren, ob Daten in der Quellentabelle seit einer letzten Auffrischung der materialisierten Ansicht modifiziert worden sind; wobei die Anweisungen weiterhin ein Auffrischen der materialisierten Ansicht in Bezug auf die Quellentabelle in Reaktion auf ein Identifizieren einer Modifikation an die Quellentabelle seit der letzten Auffrischung der materialisierten Ansicht umfassen.
Beispiel 39 ist ein Prozessor wie bei einem der Beispiele 36-38, wobei die Anweisungen weiterhin ein Definieren von Ansichtsprivilegien für die kontoübergreifenden Zugriffsrechte auf die materialisierte Ansicht umfassen, so dass ein zugrunde liegendes Detail der Quellentabelle für die materialisierte Ansicht eine Definition einer sicheren Ansicht umfasst, wobei das zugrunde liegende Detail der Quellentabelle eines oder mehreres von folgendem umfasst: ein Datenfeld in der Quellentabelle; eine Datenspalte in der Quellentabelle; ein strukturelles Element der Quellentabelle; eine Datenmenge in der Quellentabelle; Metadaten für die Quellentabelle; oder ein Transaktionsprotokoll von an der Quellentabelle vorgenommenen Modifikationen.
Beispiel 40 ist ein Prozessor wie bei einem der Beispiele 36-39, wobei die Anweisungen weiterhin ein Definieren einer Referenzliste umfassen, die eine Liste von einem oder mehreren Konten umfasst, die zum Empfangen von kontoübergreifenden Zugriffsrechten auf die materialisierte Ansicht berechtigt sind.
Beispiel 41 ist eine Vorrichtung, die Mittel enthält, um ein Verfahren durchzuführen oder eine Vorrichtung oder ein System zu realisieren, wie bei einem der Beispiele 1-40.
Beispiel 42 ist ein maschinenlesbarer Speicher einschließlich maschinenlesbarer Anweisungen, um dann, wenn sie ausgeführt werden, ein Verfahren zu implementieren oder eine Vorrichtung zu realisieren von einem der Beispiele 1-40.
Bei einem weiteren Beispiel gibt es Systeme, Computerprogramme und Vorrichtungen zum Erzeugen und Updaten kontoübergreifender materialisierter Ansichten in mehrmandantenfähigen Datenbanksystemen. Ein Computerprogramm umfasst Anweisungen, die dann, wenn sie durch einen oder mehrere Prozessoren ausgeführt werden, veranlassen, dass der eine oder die mehreren Prozessoren Operationen durchführen, wobei die Operationen ein Definieren eines Teilungsobjekts in einem ersten Konto enthalten, wobei das Teilungsobjekt mit dem ersten Konto assoziierte Daten enthält. Die Operationen enthalten weiterhin ein Gewähren von kontoübergreifenden Zugriffsrechten auf das Teilungsobjekt für ein zweites Konto, so dass das zweite Konto einen Zugriff auf das Teilungsobjekt hat, ohne das Teilungsobjekt zu kopieren. Die Operationen enthalten weiterhin ein Erzeugen einer materialisierten Ansicht über das Teilungsobjekt. Die Operationen enthalten weiterhin ein Updaten der mit dem ersten Konto assoziierten Daten. Die Operationen enthalten weiterhin ein Identifizieren, ob die materialisierte Ansicht in Bezug auf das Teilungsobjekt veraltet ist, durch Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und des Teilungsobjekts.
Verschiedene Techniken oder bestimmte Aspekte oder Teilbereiche davon können die Form eines Programmcodes (d.h. von Anweisungen) annehmen, der in materiellen Medien, wie beispielsweise Disketten, CD-ROMs, Festplatten, einem nichtflüchtigen computerlesbaren Speichermedium oder irgendeinem anderen maschinenlesbaren Speichermedium verkörpert ist, wobei dann, wenn der Programmcode in eine Maschine, wie beispielsweise einen Computer, geladen und durch diese ausgeführt wird, die Maschine eine Vorrichtung zum Ausführen bzw. Praktizieren der verschiedenen Techniken wird. In dem Falle einer Ausführung des Programmcode auf programmierbaren Computern kann die Computervorrichtung einen Prozessor, ein durch den Prozessor lesbares Speichermedium (einschließlich eines flüchtigen und nichtflüchtigen Speichers und/oder von Speicherelementen), wenigstens eine Eingabevorrichtung und wenigstens eine Ausgabevorrichtung enthalten. Der flüchtige und der nichtflüchtige Speicher und/oder die Speicherelemente können ein RAM, ein EPROM, ein Flash-Laufwerk, ein optisches Laufwerk, eine magnetische Festplatte oder ein anderes Medium zum Speichern elektronischer Daten sein. Ein oder mehrere Programme, die die hierin beschriebenen verschiedenen Techniken implementieren oder verwenden können, können eine Anwendungsprogrammierschnittstelle (API), wiederverwendbare Steuerungen und dergleichen verwenden. Solche Programme können in einer verfahrens- oder objektorientierten Programmier-Hochsprache implementiert werden, um mit einem Computersystem zu kommunizieren. Das/die Programm(e) kann/können jedoch in Assembler- oder Maschinensprache implementiert werden, wie es erwünscht ist. In jedem Fall kann die Sprache eine kompilierte oder interpretierte Sprache sein und mit Hardwareimplementierungen kombiniert werden.
Es sollte verstanden werden, dass viele der in dieser Spezifikation beschriebenen Funktionseinheiten als eine oder mehrere Komponenten implementiert werden können, was ein Ausdruck ist, der verwendet wird, um ihre Implementierungsunabhängigkeit besonders hervorzuheben. Zum Beispiel kann eine Komponente als Hardwareschaltung implementiert werden, die anwendungsspezifische VLSI-(= Very Large Scale Integration)Schaltungen oder Gate-Arrays, Standardhalbleiter wie Logikchips, Transistoren, oder andere diskrete Komponenten umfasst. Eine Komponente kann auch in programmierbaren Hardwarevorrichtungen wie feldprogrammierbaren Gate-Arrays, programmierbarer Zellenlogik bzw. Arraylogik, programmierbaren Logikvorrichtungen oder dergleichen implementiert sein.
Die Komponenten können auch in Software zur Ausführung durch verschiedene Typen von Prozessoren implementiert werden. Eine identifizierte Komponente von ausführbarem Code kann zum Beispiel einen oder mehrere physische oder logische Blöcke von Computeranweisungen umfassen, die zum Beispiel als ein Objekt, eine Prozedur oder eine Funktion organisiert sein können. Nichtsdestoweniger müssen die ausführbaren einer identifizierten Komponente nicht physisch zusammen angeordnet sein, sondern können unterschiedliche Anweisungen umfassen, die an verschiedenen Orten gespeichert sind und dann, wenn sie logisch miteinander verbunden sind, die Komponente bilden und den angegebenen Zweck für die Komponente erreichen.
Tatsächlich kann eine Komponente eines ausführbaren Codes eine einzelne Anweisung oder viele Anweisungen sein, und sie kann sogar über mehrere verschiedene Codesegmente, zwischen verschiedenen Programmen, und über mehrere Speichervorrichtungen verteilt sein. Gleichermaßen können Betriebsdaten hierin innerhalb von Komponenten identifiziert und dargestellt werden und können in irgendeiner geeigneten Form verkörpert sein und innerhalb von irgendeinem geeigneten Typ von Datenstruktur organisiert sein. Die Betriebsdaten können als einzelner Datensatz gesammelt werden oder können über verschiedene Standorte, einschließlich verschiedene Speichervorrichtungen, verteilt werden und können wenigstens teilweise nur als elektronische Signale auf einem System oder einem Netzwerk existieren. Die Komponenten können passiv oder aktiv sein, einschließlich Agenten, die betreibbar sind, um erwünschte Funktionen durchzuführen.
Eine Bezugnahme in dieser Spezifikation auf „ein Beispiel“ bedeutet, dass ein in Verbindung mit dem Beispiel beschriebenes Merkmal, eine Struktur oder eine Charakteristik in wenigstens einer Ausführungsform der vorliegenden Offenbarung enthalten ist. Daher beziehen sich die Erscheinungen des Ausdrucks „bei einem Beispiel“ an verschiedenen Stellen in dieser Spezifikation nicht unbedingt alle auf dieselbe Ausführungsform.
Wie es hierin verwendet ist, kann eine Vielzahl von Elementen, Strukturelementen, Kompositionselementen und/oder Materialien aus Gründen der Bequemlichkeit in einer gemeinsamen Liste dargestellt werden. Diese Listen sollten jedoch so ausgelegt werden, dass jedes Element der Liste einzeln als separates und eindeutiges Element identifiziert wird. Daher sollte kein einzelnes Element einer solchen Liste als faktisches Äquivalent zu einem anderen Element derselben Liste ausgelegt werden, das allein auf seiner Darstellung in einer gemeinsamen Gruppe ohne gegenteilige Anhaltspunkte beruht. Darüber hinaus können hierin verschiedene Ausführungsformen und Beispiele der vorliegenden Offenbarung zusammen mit Alternativen für die verschiedenen Komponenten davon erwähnt werden. Es versteht sich, dass solche Ausführungsformen, Beispiele und Alternativen nicht als de facto Äquivalente zueinander auszulegen sind, sondern als separate und autonome Darstellungen der vorliegenden Offenbarung zu betrachten sind.
Obwohl das Voranstehende aus Gründen der Klarheit ausführlich beschrieben wurde, wird es offensichtlich sein, dass bestimmte Änderungen und Modifikationen vorgenommen werden können, ohne von den Grundsätzen abzuweichen. Es sollte beachtet werden, dass es viele alternative Möglichkeiten gibt, sowohl die hier beschriebenen Prozesse als auch die hier beschriebenen Vorrichtungen zu implementieren. Dementsprechend sind die vorliegenden Ausführungsformen als illustrativ und nicht als beschränkend zu betrachten.
Fachleute dem Gebiet werden zu schätzen wissen, dass viele Änderungen an den Details der oben beschriebenen Ausführungsformen vorgenommen werden können, ohne von den zugrunde liegenden Prinzipien der Offenbarung abzuweichen. Der Schutzumfang dieser Offenbarung sollte daher nur durch die folgenden Ansprüche bestimmt sein.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 16/428367 [0001]

Claims

System, das folgendes umfasst: Mittel zum Definieren eines Teilungsobjekts in einem ersten Konto, wobei das Teilungsobjekt mit dem ersten Konto assoziierte Daten umfasst; Mittel zum Gewähren kontoübergreifender Zugriffsrechte auf das Teilungsobjekt zu einem zweiten Konto, so dass das zweite Konto einen Zugriff auf das Teilungsobjekt hat, ohne das Teilungsobjekt zu kopieren; Mittel zum Erzeugen einer materialisierten Ansicht über das Teilungsobjekt; Mittel zum Updaten der mit dem ersten Konto assoziierten Daten; und Mittel zum Identifizieren, ob die materialisierte Ansicht in Bezug auf das Teilungsobjekt veraltet ist, durch Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und des Teilungsobjekts.
System nach Anspruch 1, wobei die Mittel zum Identifizieren, ob die materialisierte Ansicht in Bezug auf das Teilungsobjekt veraltet ist, folgendes umfassen: Mittel zum Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und des Teilungsobjekts; Mittel zum Identifizieren, ob Daten im Teilungsobjekt seit einer letzten Auffrischung der materialisierten Ansicht modifiziert worden sind; und Mittel zum Auffrischen der materialisierten Ansicht in Bezug auf das Teilungsobjekt in Reaktion auf ein Identifizieren einer Modifikation am Teilungsobjekt seit der letzten Auffrischung der materialisierten Ansicht.
System nach Anspruch 1, das weiterhin Mittel zum Abfragen des Teilungsobjekts umfasst, wobei die Mittel zum Abfragen folgendes umfassen: Mittel zum Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und des Teilungsobjekts; und Mittel zum Ausführen der Abfrage basierend auf Information in der materialisierten Ansicht und irgendwelchen seit einer letzten Auffrischung der materialisierten Ansicht am Teilungsobjekt vorgenommenen Modifikationen.
System nach Anspruch 1, das weiterhin folgendes umfasst: Mittel zum Speichern der mit dem ersten Konto assoziierten Daten quer über eine oder mehrere einer Vielzahl von gemeinsam genutzten bzw. geteilten Speichervorrichtungen; Mittel zum Definieren einer mit dem ersten Konto assoziierten Ausführungsplattform, das einen Lesezugriff und einen Schreibzugriff für die mit dem ersten Konto assoziierten Daten hat; und Mittel zum Definieren einer mit dem zweiten Konto assoziierten Ausführungsplattform, das einen Lesezugriff auf das Teilungsobjekt hat.
System nach Anspruch 4, wobei: die mit dem zweiten Konto assoziierte Ausführungsplattform die Mittel zum Erzeugen der materialisierten Ansicht über das Teilungsobjekt enthält; die mit dem ersten Konto assoziierte Ausführungsplattform die Mittel zum Updaten der mit dem ersten Konto assoziierten Daten enthält; und die mit dem zweiten Konto assoziierte Ausführungsplattform die Mittel zum Identifizieren, ob die materialisierte Ansicht in Bezug auf das Teilungsobjekt veraltet ist, enthält.
System nach Anspruch 1, das weiterhin Mittel zum Definieren einer Definition einer sicheren Ansicht für die materialisierte Ansicht umfasst, wobei die Mittel zum Definieren der Definition einer sicheren Ansicht eines oder mehreres von folgendem umfassen: Mittel zum Gewähren eines Lesezugriffs und eines Schreibzugriffs auf die materialisierte Ansicht für das zweite Konto; Mittel zum Gewähren eines Lesezugriffs auf die materialisierte Ansicht für das erste Konto; oder Mittel zum Ausblenden bzw. Verstecken der materialisierten Ansicht vor dem ersten Konto, so dass das erste Konto keinen Einblick diesbezüglich hat, ob die materialisierte Ansicht erzeugt wurde.
System nach Anspruch 1, das weiterhin Mittel zum Definieren von Ansichtsprivilegien für die kontoübergreifenden Zugriffsrechte auf das Anteilsobjekt umfasst, so dass ein zugrunde liegendes Detail des Teilungsobjekts eine Definition einer sicheren Ansicht umfasst, wobei das zugrunde liegende Detail des Teilungsobjekts eines oder mehreres von folgendem umfasst: ein Datenfeld im Teilungsobjekt; eine Datenspalte im Teilungsobjekt; ein strukturelles Element einer zugrunde liegenden Tabelle des Teilungsobjekts; oder eine Datenmenge im Teilungsobjekt.
System nach Anspruch 7, wobei die Mittel zum Definieren der Ansichtsprivilegien für die kontoübergreifenden Zugriffsrechte auf das Teilungsobjekt Mittel zum Ausblenden bzw. Verstecken der Ansichtsprivilegien vor dem zweiten Konto und Mittel zum Sichtbarmachen der Ansichtsprivilegien für das erste Konto umfassen.
System nach Anspruch 1, wobei die Mittel zum Definieren des Teilungsobjekts eines oder mehreres von folgendem umfasst: Mittel zum Definieren eines Objektnamens, der für das erste Konto eindeutig ist; Mittel zum Definieren einer Objektrolle; oder Mittel zum Erzeugen einer Referenzliste, die eine Liste von einem oder mehreren Konten enthält, die zum Empfangen von kontoübergreifenden Zugriffsrechten auf das Teilungsobjekt berechtigt sind.
System nach Anspruch 1, das weiterhin folgendes umfasst: Mittel zum Empfangen einer Anforderung vom zweiten Konto, um eine materialisierte Ansicht über bestimmte mit dem ersten Konto assoziierte Daten zu erzeugen; Mittel zum Identifizieren, ob die bestimmten Daten im Teilungsobjekt enthalten sind; Mittel zum Gewähren einer Autorisierung für das zweite Konto, um die materialisierte Ansicht über die bestimmten Daten zu erzeugen; und Mittel zum Bereitstellen einer Benachrichtigung zum ersten Konto, die anzeigt, dass das zweite Konto eine Autorisierung, um die materialisierte Ansicht über die bestimmten Daten zu erzeugen, empfing.
Computerprogramm, das Anweisungen umfasst, die dann, wenn sie durch einen oder mehrere Prozessoren ausgeführt werden, veranlassen, dass der eine oder die mehreren Prozessoren Operationen durchführen, wobei die Operationen folgendes umfassen: Definieren eines Teilungsobjekts in einem ersten Konto, wobei das Teilungsobjekt mit dem ersten Konto assoziierte Daten umfasst; Gewähren von kontoübergreifenden Zugriffsrechten auf das Teilungsobjekt zu einem zweiten Konto, so dass das zweite Konto einen Zugriff auf das Teilungsobjekt hat, ohne das Teilungsobjekt zu kopieren; Erzeugen einer materialisierten Ansicht über das Teilungsobjekt; Updaten der mit dem ersten Konto assoziierten Daten; und Identifizieren, ob die materialisierte Ansicht in Bezug auf das Teilungsobjekt veraltet ist, durch Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und des Teilungsobjekts.
Computerprogramm nach Anspruch 11, wobei ein Identifizieren, ob die materialisierte Ansicht in Bezug auf den Anteilsgegenstand veraltet ist, folgendes umfasst: Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und des Teilungsobjekts; Identifizieren, ob Daten im Teilungsobjekt seit einer letzten Auffrischung der materialisierten Ansicht modifiziert worden sind, wobei die Daten im Teilungsobjekt durch eines oder mehreres von einem Updaten, einem Löschen oder einem Einfügen modifiziert sein können; und Auffrischen der materialisierten Ansicht in Bezug auf das Teilungsobjekt in Reaktion auf ein Identifizierung einer Modifikation am Teilungsobjekt seit der letzten Auffrischung der materialisierten Ansicht.
Computerprogramm nach Anspruch 11, wobei die Operationen weiterhin ein Abfragen des Teilungsobjekts durch folgendes umfassen: Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und des Teilungsobjekts; und Ausführen der Abfrage basierend auf Information in der materialisierten Ansicht und irgendwelchen seit einer letzten Auffrischung der materialisierten Ansicht am Teilungsobjekt vorgenommenen Modifikationen.
Computerprogramm nach Anspruch 11, wobei die Operationen weiterhin folgendes umfassen: Speichern der mit dem ersten Konto assoziierten Daten quer über eine oder mehrere einer Vielzahl von gemeinsam genutzten bzw. geteilten Speichervorrichtungen; Definieren einer mit dem ersten Konto assoziierten Ausführungsplattform, das einen Lesezugriff und einen Schreibzugriff für die mit dem ersten Konto assoziierten Daten hat; und Definieren einer mit dem zweiten Konto assoziierten Ausführungsplattform, das einen Lesezugriff auf das Teilungsobjekt hat.
Computerprogramm nach Anspruch 14, wobei: das Erzeugen der materialisierten Ansicht über das Teilungsobjekt durch die mit dem zweiten Konto assoziierte Ausführungsplattform verarbeitet wird; das Updaten der mit dem ersten Konto assoziierten Daten durch die mit dem ersten Konto assoziierte Ausführungsplattform verarbeitet wird; und das Identifizieren, ob die materialisierte Ansicht in Bezug auf das Teilungsobjekt veraltet ist, durch die mit dem zweiten Konto assoziierte Ausführungsplattform verarbeitet wird.
Computerprogramm nach Anspruch 11, wobei die Operationen weiterhin folgendes umfassen: Definieren einer Definition einer sicheren Ansicht für die materialisierte Ansicht, wobei die Definition einer sicheren Ansicht eines oder mehreres von folgendem umfasst: Gewähren eines Lesezugriffs und eines Schreibzugriffs auf die materialisierte Ansicht für das zweite Konto; Gewähren eines Lesezugriffs auf die materialisierte Ansicht für das erste Konto; oder Ausblenden bzw. Verstecken der materialisierten Ansicht vor dem ersten Konto, so dass das erste Konto keinen Einblick diesbezüglich hat, ob die materialisierte Ansicht erzeugt wurde.
Computerprogramm nach Anspruch 11, wobei die Operationen weiterhin folgendes umfassen: Definieren von Ansichtsprivilegien für die kontoübergreifenden Zugriffsrechte auf das Teilungsobjekt, so dass ein zugrunde liegendes Detail des Teilungsobjekts eine Definition einer sicheren Ansicht umfasst, wobei das zugrunde liegende Detail des Teilungsobjekts eines oder mehreres von folgendem umfasst: ein Datenfeld im Teilungsobjekt; eine Datenspalte im Teilungsobjekt; ein strukturelles Element einer zugrunde liegenden Tabelle des Teilungsobjekts; oder eine Datenmenge im Teilungsobjekt.
Computerprogramm nach Anspruch 17, wobei ein Definieren der Ansichtsprivilegien für die kontoübergreifenden Zugriffsrechte auf das Teilungsobjekt weiterhin ein Ausblenden bzw. Verstecken der Ansichtsprivilegien vor dem zweiten Konto und ein Sichtbarmachen der Ansichtsprivilegien für das erste Konto umfasst.
Computerprogramm nach Anspruch 11, wobei ein Definieren des Teilungsobjekts eines oder mehreres von folgendem umfasst: Definieren eines Objektnamens, der für das erste Konto eindeutig ist; Definieren einer Objektrolle; oder Erzeugen einer Referenzliste, die eine Liste von einem oder mehreren Konten umfasst, die zum Empfangen von kontoübergreifenden Zugriffsrechten auf das Teilungsobjekt berechtigt sind.
Computerprogramm nach Anspruch 11, wobei die Operationen weiterhin folgendes umfassen: Empfangen einer Anforderung vom zweiten Konto, um eine materialisierte Ansicht über bestimmte mit dem ersten Konto assoziierte Daten zu erzeugen; Identifizieren, ob die bestimmten Daten im Teilungsobjekt enthalten sind; Gewähren einer Autorisierung für das zweite Konto, um die materialisierte Ansicht über die bestimmten Daten zu erzeugen; und Bereitstellen einer Benachrichtigung zum ersten Konto, das anzeigt, dass das zweite Konto eine Autorisierung, um die materialisierte Ansicht über die bestimmten Daten zu erzeugen, empfing.
Prozessor, der konfigurierbar ist, um Anweisungen auszuführen, die in einem computerlesbaren Speichermedium gespeichert sind, wobei die Anweisungen folgendes umfassen: Definieren eines Teilungsobjekts in einem ersten Konto, wobei das Teilungsobjekt mit dem ersten Konto assoziierte Daten umfasst; Gewähren von kontoübergreifenden Zugriffsrechten auf das Teilungsobjekt zu einem zweiten Konto, so dass das zweite Konto einen Zugriff auf das Teilungsobjekt hat, ohne das Teilungsobjekt zu kopieren; Erzeugen einer materialisierten Ansicht über das Teilungsobjekt; Updaten der mit dem ersten Konto assoziierten Daten; und Identifizieren, ob die materialisierte Ansicht in Bezug auf das Teilungsobjekt veraltet ist, durch Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und des Teilungsobjekts.
Prozessor nach Anspruch 21, wobei ein Identifizieren, ob die materialisierte Ansicht in Bezug auf das Anteilsobjekt veraltet ist, folgendes umfasst: Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und des Teilungsobjekts; Identifizieren, ob Daten im Teilungsobjekt seit einer letzten Auffrischung der materialisierten Ansicht modifiziert worden ist, wobei die Daten im Teilungsobjekt durch eines oder mehreres von einem Updaten, einem Löschen oder einem Einfügen modifiziert sein können; und Auffrischen der materialisierten Ansicht in Bezug auf das Teilungsobjekt in Reaktion auf ein Identifizieren einer Modifikation am Teilungsobjekt seit der letzten Auffrischung der materialisierten Ansicht.
Prozessor nach Anspruch 21, wobei die Anweisungen weiterhin ein Abfragen des Teilungsobjekt durch folgendes umfassen: Verknüpfen bzw. Zusammenführen der materialisierten Ansicht und des Teilungsobjekts; und Ausführen der Abfrage basierend auf Information in der materialisierten Ansicht und irgendwelchen seit einer letzten Auffrischung der materialisierten Ansicht am Teilungsobjekt vorgenommenen Modifikationen.
Prozessor nach Anspruch 21, wobei die Anweisungen weiterhin ein Definieren einer Definition einer sicheren Ansicht für die materialisierte Ansicht durch eines oder mehreres von folgendem umfassen: Gewähren eines Lesezugriffs und eines Schreibzugriffs auf die materialisierte Ansicht für das zweite Konto; Gewähren eines Lesezugriffs auf die materialisierte Ansicht für das erste Konto; oder Ausblenden bzw. Verstecken der materialisierten Ansicht vor dem ersten Konto, so dass das erste Konto keinen Einblick diesbezüglich hat, ob die materialisierte Ansicht erzeugt wurde.
Prozessor nach Anspruch 21, wobei die Anweisungen weiterhin ein Definieren von Ansichtsprivilegien für die kontoübergreifenden Zugriffsrechte auf das Teilungsobjekt umfassen, so dass ein zugrunde liegendes Detail des Teilungsobjekts eine Definition einer sicheren Ansicht umfasst, wobei das zugrunde liegende Detail des Teilungsobjekts eines oder mehreres von folgendem umfasst: ein Datenfeld im Teilungsobjekt; eine Datenspalte im Teilungsobjekt; ein strukturelles Element einer zugrunde liegenden Tabelle des Teilungsobjekts; oder eine Datenmenge im Teilungsobjekt.
Prozessor nach Anspruch 25, wobei eine Definieren der Ansichtsprivilegien für die kontoübergreifenden Zugriffsrechte auf das Teilungsobjekt weiterhin ein Ausblenden bzw. Verstecken der Ansichtsprivilegien vor dem zweiten Konto und das Sichtbarmachen der Ansichtsprivilegien für das erste Konto umfasst.
Prozessor nach Anspruch 21, wobei ein Definieren des Teilungsobjekts eines oder mehreres von folgendem umfasst: Definieren eines Objektnamens, der für das erste Konto eindeutig ist; Definieren einer Objektrolle; oder Erzeugen einer Referenzliste, die eine Liste von einem oder mehreren Konten enthält, die zum Empfangen von kontoübergreifenden Zugriffsrechten auf das Teilungsobjekt berechtigt sind.
Prozessor nach Anspruch 21, wobei die Anweisungen weiterhin folgendes umfassen: Empfangen einer Anforderung vom zweiten Konto, um eine materialisierte Ansicht über bestimmte mit dem ersten Konto assoziierte Daten zu erzeugen; Identifizieren, ob die bestimmten Daten im Teilungsobjekt enthalten sind; Gewähren einer Autorisierung für das zweite Konto, um die materialisierte Ansicht über die bestimmten Daten zu erzeugen; und Bereitstellen einer Benachrichtigung zum ersten Konto, die anzeigt, dass das zweite Konto die Autorisierung, um die materialisierte Ansicht über die bestimmten Daten zu erzeugen, empfing.