Eine Datenbank ist eine organisierte Datenerfassung heute normalerweise in der Digitalform. Die Daten werden normalerweise organisiert, um relevante Aspekte der Wirklichkeit (zum Beispiel, die Verfügbarkeit von Zimmern in Hotels) in einem Weg zu modellieren, der Prozesse unterstützt, die diese Information (zum Beispiel verlangen, ein Hotel mit Vakanzen findend).

Der Begriff Datenbank wird auf die Daten und ihre Unterstützen-Datenstrukturen, und nicht zum Datenbankverwaltungssystem (DBMS) richtig angewandt. Die Datenbankdatenerfassung mit DBMS wird ein Datenbanksystem genannt.

Das Begriff-Datenbanksystem deutet an, dass die Daten zu einem Niveau der Qualität geführt werden (gemessen in Bezug auf Genauigkeit, Verfügbarkeit, Brauchbarkeit und Elastizität) und das der Reihe nach häufig den Gebrauch eines Mehrzweckdatenbankverwaltungssystems (DBMS) einbezieht. Ein Mehrzweck-DBMS ist normalerweise ein kompliziertes Softwaresystem, das vielen Gebrauch-Anforderungen entspricht, und die Datenbanken, die er aufrechterhält, häufig groß und kompliziert sind. Die Anwendung von Datenbanken wird jetzt zu solch einem breiten Grad ausgebreitet, dass eigentlich sich jede Technologie und Produkt auf Datenbanken und DBMSs für seine Entwicklung und Kommerzialisierung verlassen, oder sogar solches eingebettetes darin haben können. Außerdem hängen Organisationen und Gesellschaften, vom kleinen bis großen, schwer von Datenbanken für ihre Operationen ab.

Weithin bekannte DBMSs schließen Orakel, IBM DB2, Microsoft SQL Server, Microsoft Access, PostgreSQL, MySQL und SQLite ein. Eine Datenbank ist über verschiedenen DBMS nicht allgemein tragbar, aber verschiedener DBMSs kann zu einem gewissen Grad durch das Verwenden von Standards wie SQL und ODBC zwischenfunktionieren, um zusammen eine einzelne Anwendung zu unterstützen. Ein DBMS muss auch wirksame Laufzeitausführung zur Verfügung stellen um (z.B, in Bezug auf die Leistung, Verfügbarkeit und Sicherheit) als viele Endbenutzer, wie erforderlich, richtig zu unterstützen.

Eine Weise, Datenbanken zu klassifizieren, schließt den Typ ihres Inhalts zum Beispiel ein: bibliografisch, Dokumententext, statistische oder multimediale Gegenstände. Ein anderer Weg ist durch ihr Anwendungsgebiet zum Beispiel: Buchhaltung, Musik-Zusammensetzungen, Kino, Bankwesen, Herstellung oder Versicherung.

Der Begriff Datenbank kann eingeengt werden, um besondere Aspekte der organisierten Datenerfassung anzugeben, und kann sich auf die logische Datenbank auf die physische Datenbank als Dateninhalt in der Computerdatenlagerung oder zu vielen anderen Datenbanksubdefinitionen beziehen.

Geschichte

Datenbankkonzept

Das Datenbankkonzept hat sich seit den 1960er Jahren entwickelt, um zunehmende Schwierigkeiten zu erleichtern, komplizierte Informationssysteme (normalerweise mit vielen gleichzeitigen Endbenutzern, und mit einem großen Betrag von verschiedenen Daten) zu entwerfen, zu bauen, und aufrechtzuerhalten. Es hat sich zusammen mit Datenbankverwaltungssystemen entwickelt, die das wirksame Berühren von Datenbanken ermöglichen. Obwohl die Begriffe Datenbank und DBMS verschiedene Entitäten definieren, sind sie untrennbar: Eigenschaften einer Datenbank werden durch sein Unterstützen DBMS und umgekehrt bestimmt. Das englische Wörterbuch von Oxford zitiert 1962 technischer Bericht als das erste, um den Begriff "Datenbank" zu gebrauchen. Mit dem Fortschritt in der Technologie in den Gebieten von Verarbeitern sind Computergedächtnis, Computerlagerung und Computernetze, die Größen, Fähigkeiten und Leistung von Datenbanken und ihrem jeweiligen DBMSs in Ordnungen von Umfängen gewachsen. Seit Jahrzehnten ist es unwahrscheinlich gewesen, dass ein kompliziertes Informationssystem effektiv ohne eine richtige durch einen DBMS unterstützte Datenbank gebaut werden kann. Die Anwendung von Datenbanken wird jetzt zu solch einem breiten Grad ausgebreitet, dass eigentlich sich jede Technologie und Produkt auf Datenbanken und DBMSs für seine Entwicklung und Kommerzialisierung verlassen, oder sogar solches eingebettetes darin haben können. Außerdem hängen Organisationen und Gesellschaften, vom kleinen bis großen, schwer von Datenbanken für ihre Operationen ab.

Keine weit akzeptierte genaue Definition besteht für DBMS. Jedoch muss ein System beträchtliche Funktionalität zur Verfügung stellen, um sich als ein DBMS zu qualifizieren. Entsprechend muss seine unterstützte Datenerfassung jeweiligen Brauchbarkeitsanforderungen (weit gehend definiert durch die Voraussetzungen unten) entsprechen, um sich als eine Datenbank zu qualifizieren. So werden eine Datenbank und sein Unterstützen DBMS hier durch eine Reihe allgemeiner Voraussetzungen definiert, die unten verzeichnet ist. Eigentlich alle entsprechen vorhandene reife DBMS Produkte diesen Anforderungen in reichem Maße, während weniger reif, entweder treffen sie oder laufen zusammen, um sie zu treffen.

Evolution der Datenbank und DBMS Technologie

:See auch Datenbankmanagement

Die Einführung des Begriffes Datenbank ist mit der Verfügbarkeit des Direktzugriffsspeichers (Platten und Trommeln) von der Mitte der 1960er Jahre vorwärts zusammengefallen. Der Begriff hat eine Unähnlichkeit mit den Band-basierten Systemen der Vergangenheit vertreten, das Erlauben hat interaktiven Gebrauch aber nicht tägliche Gruppe-Verarbeitung geteilt.

In den frühsten Datenbanksystemen war Leistungsfähigkeit vielleicht die primäre Sorge, aber es wurde bereits anerkannt, dass es andere wichtige Ziele gab. Eines der Schlüsselziele war, die Daten unabhängig der Logik von Anwendungsprogrammen zu machen, so dass dieselben Daten zu verschiedenen Anwendungen bereitgestellt werden konnten.

Die erste Generation von Datenbanksystemen war Navigations-, Anwendungen haben normalerweise auf Daten durch folgende Zeigestöcke von einer Aufzeichnung bis einen anderen zugegriffen. Die zwei Hauptdatenmodelle in dieser Zeit waren das hierarchische Modell, das durch das IMS System von IBM und das Modell von Codasyl (Netzmodell) verkörpert ist, durchgeführt in mehreren Produkten wie IDMS.

Das Verwandtschaftsmodell, zuerst vorgeschlagen 1970 von Edgar F. Codd, ist von dieser Tradition abgewichen, indem es darauf bestanden worden ist, dass Anwendungen nach Daten durch den Inhalt, aber nicht durch folgende Verbindungen suchen sollten. Das wurde notwendig betrachtet, um dem Inhalt der Datenbank zu erlauben, sich ohne das unveränderliche Neuschreiben von Anwendungen zu entwickeln. Verwandtschaftssysteme haben schwere Anforderungen auf in einer Prozession gehenden Mitteln, und erst als die Mitte der 1980er Jahre gelegt, dass Rechenhardware stark genug geworden ist, um ihnen zu erlauben, weit aufmarschiert zu werden. Bis zum Anfang der 1990er Jahre, jedoch, waren Verwandtschaftssysteme für alle groß angelegten Daten dominierend, die Anwendungen bearbeiten, und sie bleiben dominierend heute (2012) außer in Nische-Gebieten. Die dominierende Datenbanksprache ist der normale SQL für das Verwandtschaftsmodell, das Datenbanksprachen auch für andere Datenmodelle beeinflusst hat.

Weil das Verwandtschaftsmodell Suche aber nicht Navigation betont, macht es Beziehungen zwischen verschiedenen Entitäten ausführlich in der Form von Zeigestöcken nicht, aber vertritt sie ziemlich verwendende primäre Schlüssel und Auslandsschlüssel. Während das eine gute Basis für eine Anfragensprache ist, wird ihm als eine Modellieren-Sprache weniger gut angepasst. Aus diesem Grund ein verschiedenes Modell, das Entitätsbeziehungsmodell, das kurz später (1976), gewonnene Beliebtheit für das Datenbankdesign erschienen ist.

In der Periode da hat die Datenbanktechnologie der 1970er Jahre mit den zunehmenden Mitteln Schritt gehalten, die verfügbar von der Rechenplattform werden: namentlich die Eskalation in der Kapazität und Geschwindigkeit (und die Verminderung des Preises) der Plattenlagerung und der zunehmenden Kapazität des Hauptgedächtnisses. Das hat jemals größeren Datenbanken und höheren Durchflüssen ermöglicht, erreicht zu werden.

Die Starrheit des Verwandtschaftsmodells, in dem alle Daten in Tischen mit einer festen Struktur von Reihen und Säulen gehalten wird, ist als eine Beschränkung zunehmend gesehen worden, wenn man Information behandelt, die reicher oder in der Struktur verschiedener ist als die traditionellen Daten 'des Hauptbuch-Buches' von korporativen Informationssystemen: zum Beispiel Dokumentendatenbanken, Technikdatenbanken, Multimediadatenbanken oder Datenbanken in den molekularen Wissenschaften verwendet. Verschiedene Versuche sind gemacht worden, dieses Problem, viele von ihnen zu richten, sich unter Schlagzeilen solcher als Postverwandtschafts- oder NoSQL versammelnd. Zwei Entwicklungen des Zeichens sind die Gegenstand-Datenbank und die XML Datenbank. Die Verkäufer von Verwandtschaftsdatenbanken haben Konkurrenz von diesen neueren Modellen bekämpft, indem sie die Fähigkeiten zu ihren eigenen Produkten erweitern, eine breitere Vielfalt von Datentypen zu unterstützen.

Mehrzweck-DBMS

Ein DBMS hat sich zu einem komplizierten Softwaresystem entwickelt, und seine Entwicklung verlangt normalerweise Tausende von Person-Jahren des Entwicklungsaufwandes. Einige Mehrzweck-DBMSs, wie Orakel, Microsoft SQL Server, und IBM DB2, haben Steigungen seit dreißig Jahren oder mehr erlebt. Mehrzweck-DBMSs haben zum Ziel, so viele Anwendungen wie möglich zu befriedigen, der sie normalerweise noch komplizierter macht als Datenbanken des speziellen Zwecks. Jedoch macht die Tatsache, dass sie "vom Bord", sowie ihren amortisierten Kosten über viele Anwendungen und Beispiele verwendet werden können, sie eine attraktive Alternative (Gegen die ehemalige Entwicklung), wann auch immer sie Anforderungen einer Anwendung entsprechen.

Obwohl attraktiv, in vielen Fällen ist ein Mehrzweck-DBMS nicht immer die optimale Lösung: Wenn bestimmte Anwendungen mit vielen Betriebsbeispielen, jedem mit vielen Benutzern durchdringend sind, kann ein Mehrzweck-DBMS unnötigen oberirdischen und zu großen "Fußabdruck" (zu großer Betrag des unnötigen, nicht gebrauchten Softwarecodes) einführen. Solche Anwendungen rechtfertigen gewöhnlich gewidmete Entwicklung. Typische Beispiele sind E-Mail-Systeme, obwohl sie bestimmte DBMS Eigenschaften besitzen müssen: E-Mail-Systeme werden in einem Weg gebaut, der das E-Mail-Nachrichtenberühren und Handhaben optimiert, und bedeutende Teile einer DBMS Mehrzweckfunktionalität nicht brauchen.

Typen von Leuten beteiligt

Drei Typen von Leuten werden mit einem Mehrzweck-DBMS beteiligt:

1. DBMS Entwickler - Das sind die Leute, dass Design und das DBMS Produkt und die einzigen baut, die seinen Code berühren. Sie sind normalerweise die Angestellten eines DBMS Verkäufers (z.B, Orakel, IBM, Microsoft, Sybase), oder, im Fall von der Offenen Quelle DBMSs (z.B, MySQL), Freiwillige oder Leute, die von interessierten Gesellschaften und Organisationen unterstützt sind. Sie sind normalerweise erfahrene Systemprogrammierer. DBMS Entwicklung ist eine komplizierte Aufgabe, und einige der populären DBMSs sind unter der Entwicklung und Erhöhung gewesen (um auch Fortschritt in der Technologie zu folgen), seit Jahrzehnten.
2. Anwendungsentwickler und Datenbankverwalter - Das sind die Leute, dass Design und eine datenbankbasierte Anwendung baut, die den DBMS verwendet. Die letzten Gruppenmitglieder entwerfen die erforderliche Datenbank und erhalten sie aufrecht. Die ersten Gruppenmitglieder schreiben die erforderlichen Anwendungsprogramme, die die Anwendung umfasst. Beide sind mit dem DBMS Produkt gut vertraut und verwenden seine Benutzerschnittstellen (sowie gewöhnlich andere Werkzeuge) für ihre Arbeit. Manchmal wird die Anwendung selbst paketiert und als ein getrenntes Produkt verkauft, das den DBMS innen einschließen kann (sieh Eingebettete Datenbank; unterwerfen Sie richtigem DBMS das Genehmigen), oder verkauft getrennt als eine Erweiterung zum DBMS.
3. Die Endbenutzer der Anwendung (z.B, Buchhalter, Versicherungsleute, medizinische Ärzte, usw.) - wissen Diese Leute die Anwendung und seine Endbenutzer-Schnittstellen, aber brauchen nicht zu wissen noch den zu Grunde liegenden DBMS zu verstehen. So, obwohl sie die beabsichtigten und wichtigen Begünstigten eines DBMS sind, werden sie nur damit indirekt beteiligt.

Datenbankmaschinen und Geräte

In den 1970er Jahren und 1980er Jahren wurden Versuche gemacht, Datenbanksysteme mit der einheitlichen Hardware und Software zu bauen. Die zu Grunde liegende Philosophie war, dass solche Integration höhere Leistung an niedrigeren Kosten zur Verfügung stellen würde. Beispiele waren IBM System/38, das frühe Angebot von Teradata und die Datenbankmaschine von Britton Lee, Inc.

Eine andere Annäherung an die Hardware-Unterstützung für das Datenbankmanagement war das CAFS Gaspedal von ICL, ein Hardware-Plattenkontrolleur mit programmierbaren Suchfähigkeiten.

Auf lange Sicht waren diese Anstrengungen allgemein erfolglos, weil Spezialdatenbankmaschinen mit der schnellen Entwicklung und dem Fortschritt von Mehrzweckcomputern nicht Schritt halten konnten. So sind die meisten Datenbanksysteme heutzutage Softwaresysteme, die auf der Mehrzweckhardware mit der Mehrzweckcomputerdatenlagerung laufen. Jedoch wird diese Idee noch für bestimmte Anwendungen von einigen Gesellschaften wie Netezza und Oracle (Exadata) verfolgt.

Datenbankforschung

Datenbankforschung ist ein aktives und verschiedenes Gebiet, mit vielen Spezialisierungen, ausgeführt seit den frühen Tagen gewesen, sich mit dem Datenbankkonzept in den 1960er Jahren zu befassen. Es hat starke Bande mit der Datenbanktechnologie und den DBMS Produkten. Datenbankforschung hat an Forschungs- und Entwicklungsunternehmensgruppen stattgefunden (z.B, namentlich an IBM Research, der Technologien und Ideen eigentlich zu irgendwelchem DBMS vorhanden heute beigetragen hat), Forschungsinstitute und Akademie. Forschung ist sowohl durch die Theorie als auch durch Prototypen getan worden. Die Wechselwirkung zwischen Forschung und Datenbank hat sich bezogen Produktentwicklung ist zum Datenbankgebiet sehr produktiv gewesen, und viele zusammenhängende Schlüsselkonzepte und Technologien sind daraus erschienen. Bemerkenswert sind der Verwandtschafts- und die Entitätsbeziehungsmodelle, das Atomtransaktionskonzept und die verwandten Parallelitätskontrolltechniken, die Anfragensprachen und die Anfragenoptimierungsmethoden, der ÜBERFALL, und mehr. Forschung hat tiefen Einblick zu eigentlich allen Aspekten von Datenbanken gewährt, obwohl nicht immer pragmatisch, wirksam gewesen ist (und nicht kann und nicht immer sein sollte: Forschung ist in der Natur Forschungs-, und führt nicht immer zu akzeptierten oder nützlichen Ideen). Schließlich bestimmen Marktkräfte und echte Bedürfnisse die Auswahl an Problem-Lösungen und verwandten Technologien, auch unter denjenigen, die durch die Forschung vorgeschlagen sind. Jedoch, gelegentlich, nicht die besten und elegantesten Lösungsgewinne (z.B, SQL). Entlang ihrer Geschichte sind DBMSs und jeweilige Datenbanken in reichem Maße das Ergebnis solcher Forschung gewesen, während echte Produktvoraussetzungen und Herausforderungen Datenbankforschungsrichtungen und Teilbereiche ausgelöst haben.

Das Datenbankforschungsgebiet hat mehrere bemerkenswerte hingebungsvolle akademische Zeitschriften (z.B, ACM Transaktionen auf dem Datenbanksystem-TODS, den Daten und der Wissensverarbeitung-DKE, und mehr) und jährliche Konferenzen (z.B, ACM SIGMOD, ACM SCHOTEN, VLDB, IEEE ICDE, und mehr), sowie eine energische und ziemlich heterogene (unterworfen-kluge) Forschungsgemeinschaft überall auf der Welt.

Typ-Beispiele Database

Der folgende ist Beispiele von verschiedenen Datenbanktypen. Einige von ihnen sind nicht Hauptströmungstypen, aber die meisten von ihnen haben spezielle Aufmerksamkeit (z.B, in der Forschung) wegen Endbenutzer-Voraussetzungen erhalten. Einige, bestehen wie spezialisiert, DBMS Produkte, und einige ließen ihre Funktionalitätstypen in vorhandenem Mehrzweck-DBMSs vereinigen.

• Aktive Datenbank

:: Eine aktive Datenbank ist eine Datenbank, die eine Ereignis-gesteuerte Architektur einschließt, die auf Bedingungen sowohl innerhalb als auch außerhalb der Datenbank antworten kann. Möglicher Gebrauch schließt Sicherheitsüberwachung, das Alarmieren, das Statistiksammeln und die Genehmigung ein.

:: Die meisten modernen Verwandtschaftsdatenbanken schließen aktive Datenbankeigenschaften in die Form des Datenbankabzugs ein.

• Wolkendatenbank

:: Eine Wolkendatenbank ist eine Datenbank, die sich auf die Wolkentechnologie verlässt. Sowohl die Datenbank als auch die meisten seiner DBMS wohnen entfernt, "in der Wolke,", während seine Anwendungen von Programmierern sowohl entwickelt und später aufrechterhalten und von den Endbenutzern (der Anwendung) durch einen WWW-Browser verwertet werden und APIs Öffnen. Immer mehr erscheinen solche Datenbankprodukte, beide von neuen Verkäufern und durch eigentlich alle feststehenden Datenbankverkäufer.

• Datenlager

:: Datenlager archivieren Daten von betrieblichen Datenbanken und häufig von Außenquellen wie Marktforschungsunternehmen. Häufig erleben betriebliche Daten Transformation auf seinem Weg ins Lager, anonymized, wiederklassifiziert usw. zusammengefasst zu werden. Das Lager wird die Hauptquelle von Daten für den Gebrauch durch Betriebsleiter und andere Endbenutzer, die Zugang zu betrieblichen Daten nicht haben können. Zum Beispiel könnten Verkaufsdaten mit wöchentlichen Summen angesammelt und aus inneren Produktcodes umgewandelt werden, um UPCs zu verwenden, so dass es im Vergleich zu Daten von ACNIELSEN sein kann. Einige grundlegende und wesentliche Bestandteile der Datenlagerung schließen das Wiederbekommen, das Analysieren, und das Bergwerk von Daten, das Umwandeln, das Laden und die Betriebsdaten ein, um es für den weiteren Gebrauch bereitzustellen.

:: Operationen in einem Datenlager sind normalerweise mit Hauptteil-Datenmanipulation, und als solcher beschäftigt, es ist ungewöhnlich und ineffizient, um individuelle Reihen für die Aktualisierung ins Visier zu nehmen, einzufügen oder zu löschen. Stapeln Sie heimische Lader für Eingangsdaten auf und seien Sie sperrig SQL-Pässe für die Ansammlung sind die Norm.

• Verteilte Datenbank

:: Die Definition einer verteilten Datenbank ist breit, und kann in verschiedenen Bedeutungen verwertet werden. Im Allgemeinen bezieht es sich normalerweise auf eine DBMS Modularchitektur, die verschiedenen DBMS Beispielen erlaubt, als ein einzelner DBMS über Prozesse, Computer und Seiten zusammenzuarbeiten, während das Handhaben einer einzelnen Datenbank sich über vielfache Computer und verschiedene Seiten verteilt hat.

:: Beispiele sind Datenbanken von lokalen Arbeitsgruppen und Abteilungen an Regionalbüros, Filialen, Produktionsanlagen und anderen Arbeitsseiten. Diese Datenbanken können sowohl Segmente einschließen, die durch vielfache Seiten als auch Segmente geteilt sind, die zu einer Seite spezifisch sind und nur lokal in dieser Seite verwendet sind.

• Dokumentenorientierte Datenbank

:: Verwertet, um günstig zu versorgen, führen Sie, editieren Sie und bekommen Sie Dokumente wieder.

• Eingebettete Datenbank

:: Ein eingebettetes Datenbanksystem ist ein DBMS, der mit einer Anwendungssoftware dicht integriert wird, die Zugang zu versorgten Daten in einer Weise verlangt, wie der DBMS vor dem Endbenutzer der Anwendung "verborgen" wird und wenig oder keine andauernde Wartung verlangt. Es ist wirklich eine breite Technologiekategorie, die DBMSs mit sich unterscheidenden Eigenschaften und Zielmärkten einschließt. Der Begriff "eingebettete Datenbank" kann verwirrend sein, weil nur eine kleine Teilmenge von eingebetteten Datenbankprodukten in Realtime eingebettete Systeme wie Fernmeldeschalter und Verbraucherelektronik-Geräte verwendet wird.

• Endbenutzer-Datenbank

:: Diese Datenbanken bestehen aus von individuellen Endbenutzern entwickelten Daten. Beispiele von diesen sind Sammlungen von Dokumenten, Spreadsheets, Präsentationen, Multimedia und anderen Dateien. Mehrere Produkte bestehen, um solche Datenbanken zu unterstützen. Einige von ihnen sind viel einfacher als voll hat DBMSs, mit der elementareren DBMS Funktionalität (z.B befiedert, vielfache gleichzeitige Endbenutzer auf derselben Datenbank nicht unterstützend), mit grundlegenden Programmierschnittstellen und einem relativ kleinen "Fußabdruck" (nicht viel Code, um als in "regelmäßigen" Mehrzweckdatenbanken zu laufen). Jedoch kann auch verfügbarer Mehrzweck-DBMSs häufig zu solchem Zweck verwendet werden, wenn sie grundlegende Benutzerschnittstellen für aufrichtige Datenbankanwendungen zur Verfügung stellen (beschränkte Abfrage und Datenanzeige; keine echte Programmierung hat gebraucht), während man noch die Datenbankqualitäten und den Schutz genießt, den diese DBMSs zur Verfügung stellen können.

• Bundesdatenbank und Mehrdatenbank

:: Eine Bundesdatenbank ist eine einheitliche Datenbank, die mehrere verschiedene Datenbanken, jeden mit seinem eigenen DBMS umfasst. Es wird als eine einzelne Datenbank durch ein Bundesdatenbankverwaltungssystem (FDBMS) behandelt, der durchsichtig vielfachen autonomen DBMSs, vielleicht verschiedener Typen integriert (der es eine heterogene Datenbank macht), und sie mit einer einheitlichen Begriffsansicht versorgt. Die konstituierenden Datenbanken werden über das Computernetz miteinander verbunden und können geografisch dezentralisiert werden.

:: Einmal wird der Begriff Mehrdatenbank als ein Synonym zur Bundesdatenbank gebraucht, obwohl es auf einen weniger einheitlichen (z.B, ohne einen FDBMS und ein geführtes einheitliches Diagramm) Gruppe von Datenbanken verweisen kann, die in einer einzelnen Anwendung zusammenarbeiten. In diesem Fall normalerweise wird middleware für den Vertrieb verwendet, der normalerweise einen atomar begehen Protokoll (ACP) z.B einschließt, begehen die zweiphasigen Protokoll, um verteilte (globale) Transaktionen (gegen lokale Transaktionen zu erlauben, die auf einen einzelnen DBMS beschränkt sind) über die teilnehmenden Datenbanken.

• Graph-Datenbank

:: Eine Graph-Datenbank ist eine Art Datenbank von NoSQL, die Graph-Strukturen mit Knoten, Rändern und Eigenschaften verwendet, Information zu vertreten und zu versorgen. Allgemeine Graph-Datenbanken, die jeden Graphen versorgen können, sind von Spezialgraph-Datenbanken wie triplestores und Netzdatenbanken verschieden.

• Hypermediadatenbanken

:: Vom World Wide Web kann als eine Datenbank, obgleich eine Ausbreitung über Millionen von unabhängigen Rechensystemen gedacht werden. WWW-Browser "bearbeiten" diesen Daten eine Seite auf einmal, während Webkettenfahrzeuge und andere Software die Entsprechung von Datenbankindizes zur Verfügung stellen, um Suche und andere Tätigkeiten zu unterstützen.

• Datenbank im Gedächtnis

:: Eine Datenbank im Gedächtnis (IMDB; auch Hauptspeicherdatenbank oder MMDB) ist eine Datenbank, die in erster Linie im Hauptgedächtnis, aber normalerweise unterstützt durch die unvergängliche Computerdatenlagerung wohnt. Hauptspeicherdatenbanken sind schneller als Plattendatenbanken. Das Zugreifen auf Daten im Gedächtnis reduziert die Eingabe/Ausgabe-Lesen-Tätigkeit wenn, zum Beispiel die Daten fragend. In Anwendungen, wo Ansprechzeit wie Fernmeldenetzausrüstung kritisch ist, werden Hauptspeicherdatenbanken häufig verwendet.

• Kenntnisse-Basis

:: Eine Kenntnisse-Basis (abgekürztes KILOBYTE, Kilobyte oder Δ) ist eine spezielle Art der Datenbank für das Kenntnisse-Management, die Mittel für die computerisierte Sammlung, Organisation und Wiederauffindung von Kenntnissen zur Verfügung stellend. Auch eine Datenerfassung, die Probleme mit ihren Lösungen und verwandten Erfahrungen vertritt.

• Betriebliche Datenbank

:: Diese Datenbanken versorgen ausführliche Daten über die Operationen einer Organisation. Sie werden normalerweise durch den Gegenstand organisiert, bearbeiten relativ große Volumina von Aktualisierungen mit Transaktionen. Im Wesentlichen verwendet jede Hauptorganisation auf der Erde solche Datenbanken. Beispiele schließen Kundendatenbanken ein, die Kontakt, Kredit und demografische Information über Kunden eines Geschäfts, Personaldatenbanken registrieren, die Information wie Gehalt, Vorteile, Sachkenntnis-Daten über Angestellte, Unternehmensquelle halten, dieser Rekorddetails über Produktbestandteile, Teil-Warenbestand und Finanzdatenbanken planend, die das Geld der Organisation, Buchhaltung und Finanzverkehr nachgehen.

• Parallele Datenbank

:: Eine parallele Datenbank, die durch einen parallelen DBMS geführt ist, bemüht sich, Leistung durch parallelization für Aufgaben wie ladende Daten zu verbessern, Indizes bauend und Abfragen bewertend. Parallele Datenbanken verbessern Verarbeitung und Geschwindigkeiten des Eingangs/Produktion durch das Verwenden vielfacher in einer Prozession gehender Haupteinheiten (Zentraleinheiten) (einschließlich Mehrkernverarbeiter) und Lagerung in der Parallele. In der parallelen Verarbeitung werden viele Operationen gleichzeitig im Vergleich mit der folgenden Serienverarbeitung durchgeführt, wo Operationen ohne Zeitübergreifen durchgeführt werden.

:: Die DBMS parallelen Hauptarchitekturen (die durch die zu Grunde liegende Hardware-Architektur veranlasst werden, sind:

::* Geteilte Speicherarchitektur, wo vielfache Verarbeiter den Hauptspeicherraum, sowie die andere Datenlagerung teilen.

::* Geteilte Plattenarchitektur, wo jede in einer Prozession gehende Einheit (normalerweise aus vielfachen Verarbeitern bestehend), sein eigenes Hauptgedächtnis hat, aber alle Einheiten teilen die andere Lagerung.

::* Geteilt nichts Architektur, wo jede in einer Prozession gehende Einheit sein eigenes Hauptgedächtnis und andere Lagerung hat.

• Echtzeitdatenbank

Wenn eine DBMS Systemansprechbenutzerbitte in einem gegebenen Zeitabschnitt es als eine Echtzeitdatenbank betrachtet werden kann.

• Raumdatenbank

Eine Raumdatenbank kann die Daten mit mehrdimensionalen Eigenschaften versorgen. Die Abfragen auf solchen Daten schließen gestützte Abfragen der Position, wie ein, "wo das nächste Hotel in meinem Gebiet ist".

• Zeitliche Datenbank
• Datenbank der unstrukturierten Daten

:: Eine Datenbank der unstrukturierten Daten ist beabsichtigt, um auf eine lenksame und geschützte Weise verschiedene Gegenstände zu versorgen, die natürlich und günstig in gemeinsamen Datenbanken nicht passen. Es kann E-Mail-Nachrichten, Dokumente, Zeitschriften, Multimediagegenstände usw. einschließen. Der Name kann irreführend sein, da einige Gegenstände hoch strukturiert werden können. Jedoch baut die komplette mögliche Gegenstand-Sammlung ein vorherbestimmtes strukturiertes Fachwerk nicht ein. Meiste haben DBMSs gegründet jetzt unterstützen unstrukturierte Daten auf verschiedene Weisen, und neu hat DBMSs gewidmet erscheinen.

Hauptdatenbankgebrauch-Voraussetzungen

Der Hauptzweck einer Datenbank ist, das Informationssystem zur Verfügung zu stellen (in seinem weitesten Sinn), der es mit der Information die Systembedürfnisse gemäß seinen eigenen Voraussetzungen verwertet. Ein bestimmter breiter Satz von Voraussetzungen raffiniert diese allgemeine Absicht. Diese Datenbankvoraussetzungen übersetzen zu Voraussetzungen für den jeweiligen DBMS, um günstig zu erlauben, eine richtige Datenbank für die gegebene Anwendung zu bauen. Wenn diese Absicht durch einen DBMS entsprochen wird, dann können sich die Entwerfer und Baumeister der spezifischen Datenbank auf die Aspekte der Anwendung und nicht Geschäft mit Gebäude und dem Aufrechterhalten des zu Grunde liegenden DBMS konzentrieren. Außerdem, da ein DBMS kompliziert und teuer ist, um zu bauen und aufrechtzuerhalten, ist es nicht wirtschaftlich, um solch ein neues Werkzeug (DBMS) für jede Anwendung zu bauen. Eher wird es gewünscht, um ein flexibles Werkzeug zur Verfügung zu stellen, um Datenbanken für so viel wie möglich gegeben Anwendungen, d. h., ein Mehrzweck-DBMS zu behandeln.

Funktionelle Voraussetzungen

Bestimmten allgemeinen funktionellen Anforderungen muss in Verbindung mit einer Datenbank entsprochen werden. Sie beschreiben, was erforderlich ist, um in einer Datenbank für jede spezifische Anwendung definiert zu werden.

Das Definieren der Struktur von Daten: Das Datenmodellieren und die Datendefinitionssprachen

Die Datenbank muss auf einem Datenmodell basieren, das genug reich ist, um in der Datenbank Aspekte ganzen erforderlichen jeweiligen Anwendung zu beschreiben. Eine Datendefinitionssprache besteht, um die Datenbanken innerhalb des Datenmodells zu beschreiben. Solche Sprache ist normalerweise spezifisches Datenmodell.

Manipulierung der Daten: Datenmanipulationssprachen und Anfragensprachen

Ein Datenbankdatenmodell braucht Unterstützung durch eine genug reiche Datenmanipulationssprache, um alle Datenbankmanipulationen und Informationsgeneration (von den Daten), wie erforderlich, durch die jeweilige Anwendung zu erlauben. Solche Sprache ist normalerweise spezifisches Datenmodell.

Schutz der Daten: Das Setzen von Datenbanksicherheitstypen und Niveaus

Das DB braucht eingebaute Sicherheitsmittel, seinen Inhalt (und Benutzer) von Gefahren von nicht bevollmächtigten Benutzern (entweder Menschen oder Programme) zu schützen. Schutz wird auch von Typen des unbeabsichtigten Bruchs zur Verfügung gestellt. Sicherheitstypen und Niveaus sollten von den Datenbankeigentümern definiert werden.

Das Beschreiben von Prozessen, die die Daten verwenden: Arbeitsablauf und das Geschäftsprozess-Modellieren

Manipulierung von Datenbankdaten ist häufig mit Prozessen von mehreren voneinander abhängigen Schritten zu verschiedenen Zeiten verbunden (z.B, wenn die Wechselwirkungen der verschiedenen Leute beteiligt werden; z.B, eine Versicherungspolice erzeugend). Datenmanipulationssprachen sind normalerweise beabsichtigt, um zu beschreiben, was in einer Single solcher Schritt erforderlich ist. Das Befassen mit vielfachen Schritten verlangt normalerweise schreibende ziemlich komplizierte Programme. Die meisten Anwendungen werden mit allgemeinen Programmiersprachen und Softwareentwicklungswerkzeugen programmiert. Jedoch hat sich das Gebiet der Prozess-Beschreibung im Fachwerk des Arbeitsablaufs und der Geschäftsprozesse mit dem Unterstützen von Sprachen und Softwarepaketen entwickelt, die beträchtlich die Aufgaben vereinfachen. Traditionell ist dieses Fachwerk außer dem Spielraum von allgemeinem DBMSs gewesen, aber die Anwendung von ihnen ist gewöhnlich geworden, und häufig werden sie als Erweiterung DBMSs zur Verfügung gestellt.

Betriebliche Voraussetzungen

Betriebliche Voraussetzungen sind erforderlich, um durch eine Datenbank entsprochen zu werden, um eine Anwendung, wenn betrieblich, effektiv zu unterstützen. Obwohl es normalerweise erwartet werden kann, dass betrieblichen Anforderungen durch einen DBMS automatisch entsprochen wird, tatsächlich ist es nicht so in den meisten Fällen: Um entsprochen zu werden, sind wesentliche Arbeit des Designs und Einstimmung normalerweise von Datenbankverwaltern erforderlich. Das wird normalerweise durch spezifische Instruktionen/Operationen durch spezielle Datenbankbenutzerschnittstellen und Werkzeuge getan, und kann so als sekundäre funktionelle Voraussetzungen angesehen werden (die nicht weniger wichtig sind als die Vorwahl).

Verfügbarkeit

Ein DB sollte erforderliche Niveaus der Verfügbarkeit aufrechterhalten, d. h. das DB muss in einer Weise verfügbar sein, wie eine Handlung eines Benutzers außer einer bestimmten Zeitreihe vor dem Starten der Durchführung auf das DB nicht zu warten braucht. Verfügbarkeit bezieht sich auch auf den Misserfolg und die Wiederherstellung davon (sieh Wiederherstellung vom Misserfolg und der Katastrophe unten): Nach dem Misserfolg und während der Wiederherstellung sind normale Verfügbarkeitsänderungen und spezielle Maßnahmen erforderlich, um Verfügbarkeitsvoraussetzungen zu befriedigen.

Leistung

Die Handlungen von Benutzern auf das DB sollten innerhalb von erforderlichen Zeitreihen durchgeführt werden.

Isolierung zwischen Benutzern

Wenn vielfache Benutzer auf die Datenbank gleichzeitig zugreifen, sollten die Handlungen eines Benutzers ununterbrochen und durch Handlungen anderer Benutzer ungekünstelt sein. Diese gleichzeitigen Handlungen sollten die Konsistenz des DB aufrechterhalten (d. h., das DB von der Bestechung abhalten).

Wiederherstellung vom Misserfolg und der Katastrophe

Alle Computersysteme, einschließlich DBMSs, sind für Misserfolge aus vielen Gründen (sowohl Software als auch Hardware verbunden) anfällig. Misserfolge normalerweise korrupt das DB, normalerweise im Ausmaß, dass es unmöglich ist, es ohne spezielle Maßnahmen zu reparieren. Der DBMS sollte automatischen Wiederanlauf aus Misserfolg-Verfahren zur Verfügung stellen, die das DB reparieren und es in einen gut definierten Staat zurückgeben.

Unterstützen Sie und stellen Sie wieder her

Manchmal wird es gewünscht, um eine Datenbank einem vorherigen Staat zurückzubringen (aus vielen Gründen, z.B, Fälle, wenn die Datenbank verdorben wegen eines Softwarefehlers gefunden wird, oder wenn es mit falschen Daten aktualisiert worden ist). Um das zu erreichen, wird eine Aushilfsoperation gelegentlich oder unaufhörlich getan, wo jeder gewünschte Datenbankstaat (d. h., die Werte seiner Daten und ihres Einbettens in den Datenstrukturen der Datenbank) innerhalb von hingebungsvollen Aushilfsdateien behalten wird (viele Techniken bestehen, um das effektiv zu tun). Wenn dieser Staat erforderlich ist, d. h., wenn es von einem Datenbankverwalter dafür entschieden wird, die Datenbank diesem Staat zurückzubringen (z.B, durch das Spezifizieren dieses Staates durch einen gewünschten Punkt rechtzeitig, als die Datenbank in diesem Staat war), werden diese Dateien verwertet, um diesen Staat wieder herzustellen.

Datenunabhängigkeit

Datenunabhängigkeit gehört einem Lebenszyklus einer Datenbank (sieh Datenbank bauen, aufrechtzuerhalten, und unten zu stimmen). Es presst stark die Bequemlichkeit und Kosten zusammen, eine Anwendung und seine Datenbank aufrechtzuerhalten, und ist die Hauptmotivation für das Erscheinen und den Erfolg des Verwandtschaftsmodells, sowie die Konvergenz zu einer Architektur der gemeinsamen Datenbank gewesen. Im Allgemeinen bedeutet der Begriff "Datenunabhängigkeit", dass Änderungen in der Struktur der Datenbank Änderungen in den Computerprogrammen seiner Anwendung nicht verlangen, und dass Änderungen in der Datenbank an einem bestimmten architektonischen Niveau (sieh unten) die Niveaus der Datenbank oben nicht betreffen. Datenunabhängigkeit wird in reichem Maße in zeitgenössischem DBMS erreicht, aber es ist nicht völlig erreichbar, und an verschiedenen Graden für verschiedene Typen der Datenbank Strukturänderungen erreicht.

Hauptdatenbank funktionelle Gebiete

Die funktionellen Gebiete sind Gebiete und Themen, die sich entwickelt haben, um richtige Antworten und Lösungen der funktionellen Voraussetzungen oben zur Verfügung zu stellen.

Datenmodelle

Ein Datenmodell ist eine abstrakte Struktur, die die Mittel zur Verfügung stellt, spezifische Datenstrukturen effektiv zu beschreiben, musste eine Anwendung modellieren. Weil solch ein Datenmodell genügend ausdrucksvolle Macht braucht, die erforderlichen Aspekte von Anwendungen zu gewinnen. Diese Anwendungen sind häufig zu kommerziellen Gesellschaften und anderen Organisationen (wie Herstellung, menschliche Arbeitskräfte, Lager, Bankwesen, usw.) typisch . Für die wirksame Anwendung und das Berühren wird davon gewünscht, dass ein Datenmodell relativ einfach und intuitiv ist. Das kann im Konflikt mit der hohen ausdrucksvollen Macht sein musste sich mit bestimmten komplizierten Anwendungen befassen. So balanciert jedes populäre Mehrzweckdatenmodell gewöhnlich gut dazwischen, intuitiv und relativ einfach, und sehr kompliziert mit der hohen ausdrucksvollen Macht zu sein. Die Semantik der Anwendung wird gewöhnlich im Modell nicht ausführlich ausgedrückt, aber ziemlich implizit (und durch die Dokumentation ausführlich berichtet, die zum Modell äußerlich ist), und hat zu durch Datenartikel-Typ-Namen (z.B, "Teil-Zahl") und ihre Verbindungen (wie ausgedrückt, durch allgemeine Datenstruktur-Typen angedeutet, die durch jedes spezifische Modell zur Verfügung gestellt sind).

Frühe Datenmodelle

Diese Modelle waren in den 1960er Jahren, die 1970er Jahre populär, aber können heutzutage in erster Linie in alten Vermächtnis-Systemen gefunden werden. Sie werden in erster Linie charakterisiert, indem sie mit starken Verbindungen zwischen ihren logischen und physischen Darstellungen und Mängeln in der Datenunabhängigkeit Navigations-sind.

Hierarchisches Modell

In den Hierarchischen verschiedenen Musterrekordtypen (wirkliche Entitäten vertretend), werden in einer vorherbestimmten hierarchischen (baumähnlichen) Struktur eingebettet. Diese Hierarchie wird als die physische Ordnung von Aufzeichnungen in der Lagerung verwendet. Rekordzugang wird durch das Steuern durch die Datenstruktur mit mit dem folgenden Zugreifen verbundenen Zeigestöcken getan.

Dieses Modell ist in erster Linie von IBM IMS DBMS, einem der frühsten DBMSs unterstützt worden. Verschiedene Beschränkungen des Modells sind an später IMS Versionen durch zusätzliche logische der physischen Grundhierarchie auferlegte Hierarchien ersetzt worden.

Netzmodell

In diesem Modell wird eine hierarchische Beziehung zwischen zwei Rekordtypen (wirkliche Entitäten vertretend), durch die Satz-Konstruktion hergestellt. Ein Satz besteht aus verbundenen Listen des Rundschreibens, wo ein Rekordtyp, der Satz-Eigentümer oder Elternteil, einmal in jedem Kreis erscheint, und ein zweiter Rekordtyp, der Untergebene oder Kind, mehrmals in jedem Kreis erscheinen kann. Auf diese Weise kann eine Hierarchie zwischen irgendwelchen zwei Rekordtypen z.B gegründet werden, Typ A ist der Eigentümer von B. Zur gleichen Zeit kann ein anderer Satz definiert werden, wo B der Eigentümer von A ist. So umfassen alle Sätze einen allgemeinen geleiteten Graphen (Eigentumsrecht definiert eine Richtung), oder Netzkonstruktion. Der Zugang zu Aufzeichnungen ist irgendein folgend (gewöhnlich in jedem Rekordtyp), oder durch die Navigation im Rundschreiben hat Listen verbunden.

Dieses Modell ist allgemeiner und stark als das hierarchische, und ist am populärsten gewesen, bevor es durch das Verwandtschaftsmodell ersetzt wird. Es ist durch CODASYL standardisiert worden. Populäre DBMS Produkte, die es verwertet haben, waren der IDMS von Ganzem und Cullinet von Cincom Systemen.

Umgekehrtes Dateimodell

Eine umgekehrte Datei oder umgekehrter Index einer ersten Datei, durch ein Feld in dieser Datei (das Inversionsfeld), sind eine zweite Datei, in der dieses Feld der Schlüssel ist. Eine Aufzeichnung in der zweiten Datei schließt einen Schlüssel und Zeigestöcke zu Aufzeichnungen in der ersten Datei ein, wo das Inversionsfeld den Wert des Schlüssels hat. Das ist auch die logische Struktur von zeitgenössischen Datenbankindizes. Das zusammenhängende Umgekehrte Dateidatenmodell verwertet umgekehrte Dateien von primären Datenbankdateien zu effizient direkt Zugang hat Aufzeichnungen in diesen Dateien gebraucht.

Bemerkenswert, um dieses Datenmodell zu verwenden, ist der ADABAS DBMS von Software AG, eingeführt 1970. ADABAS hat beträchtliche Kundenbasis gewonnen und besteht und unterstützt bis heute. In den 1980er Jahren hat es das Verwandtschaftsmodell und SQL zusätzlich zu seinen ursprünglichen Werkzeugen und Sprachen angenommen.

Verwandtschaftsmodell

Das Verwandtschaftsmodell ist ein einfaches Modell, das Flexibilität zur Verfügung stellt. Es organisiert Daten, die auf der zweidimensionalen Reihe gestützt sind, die als Beziehungen oder Tische, wie verbunden, mit Datenbanken bekannt ist. Diese Beziehungen bestehen aus einem Kopfstück und einer Reihe der Null oder mehr Tupeln in der willkürlichen Ordnung. Das Kopfstück ist ein nicht eingeordneter Satz der Null oder mehr Attribute oder Säulen des Tisches. Die Tupel sind eine Reihe einzigartiger Attribute, die zu Werten oder den Reihen von Daten im Tisch kartografisch dargestellt ist. Daten können vereinigt über vielfache Tische mit einem Schlüssel. Ein Schlüssel ist eine Single, oder Satz von vielfachen, Attribut (E), das für beide Tische üblich ist. Der grösste Teil der mit dem Verwandtschaftsmodell vereinigten gemeinsamen Sprache ist Structured Query Language (SQL), obwohl es sich an einigen Stellen unterscheidet.

Entitätsbeziehungsmodell

Gegenstand-Modell

In ist das objektorientierte Paradigma in Gebieten wie Technik- und Raumdatenbanken, Fernmeldewesen und in verschiedenen wissenschaftlichen Gebieten angewandt worden. Das Konglomerat des Gegenstands orientierte Programmierung und Datenbanktechnologie hat zu dieser neuen Art der Datenbank geführt. Diese Datenbanken versuchen, die Datenbankwelt und die Anwendung programmierende Welt näher zusammen insbesondere durch das Sicherstellen zu bringen, dass die Datenbank dasselbe Typ-System wie das Anwendungsprogramm verwendet. Das hat zum Ziel, das oberirdische (manchmal gekennzeichnet als die Scheinwiderstand-Fehlanpassung) der sich umwandelnden Information zwischen seiner Darstellung in der Datenbank (zum Beispiel als Reihen in Tischen) und seiner Darstellung im Anwendungsprogramm (normalerweise als Gegenstände) zu vermeiden. Zur gleichen Zeit versuchen Gegenstand-Datenbanken, Schlüsselideen von der Gegenstand-Programmierung, wie encapsulation und polymorphism in die Welt von Datenbanken einzuführen.

Eine Vielfalt dieser Wege ist versucht worden, um Gegenstände in einer Datenbank zu versorgen. Einige Produkte haben sich dem Problem von der Anwendung programmierenden Seite, durch das Bilden der Gegenstände manipuliert durch das beharrliche Programm genähert. Das verlangt auch normalerweise die Hinzufügung einer Art Anfragensprache, da herkömmliche Programmiersprachen Sprachebene-Funktionalität nicht zur Verfügung stellen, um Gegenstände gestützt auf ihrem Informationsinhalt zu finden. Andere haben das Problem vom Datenbankende, durch das Definieren eines objektorientierten Datenmodells für die Datenbank und das Definieren einer Datenbankprogrammiersprache angegriffen, die volle Programmierfähigkeiten sowie traditionelle Anfragenmöglichkeiten erlaubt.

Wenden Sie Verwandtschaftsmodell ein

XML als ein Datenbankdatenmodell

Andere Datenbankmodelle

Produkte, die ein allgemeineres Datenmodell anbieten als das Verwandtschaftsmodell, werden manchmal als Postverwandtschafts-klassifiziert. Abwechselnde Begriffe schließen "hybride Datenbank", "Gegenstand-erhöhter RDBMS" und andere ein. Das Datenmodell in solchen Produkten vereinigt Beziehungen, aber wird durch den Informationsgrundsatz von E.F. Codd nicht beschränkt, der das verlangt

Einige dieser Erweiterungen auf das Verwandtschaftsmodell integrieren Konzepte von Technologien, die das Verwandtschaftsmodell zurückdatieren. Zum Beispiel erlauben sie Darstellung eines geleiteten Graphen mit Bäumen auf den Knoten. Die deutsche Gesellschaft sones führt dieses Konzept in seinem GraphDB durch.

Einige Postverwandtschaftsprodukte erweitern Verwandtschaftssysteme mit Nichtverwandtschaftseigenschaften. Andere sind in den ziemlich gleichen Platz durch das Hinzufügen von Verwandtschaftseigenschaften zu Vorverwandtschaftssystemen angekommen. Paradoxerweise erlaubt das Produkte, die, wie AUSWAHL und MUMPS historisch Vorverwandtschafts-sind, um einen plausiblen Anspruch zu erheben, Postverwandtschafts-zu sein.

Das Quellenraummodell (RSM) ist ein auf der mehrdimensionalen Klassifikation gestütztes Nichtverwandtschaftsdatenmodell.

Datenbanksprachen

Datenbanksprachen sind gewidmete Programmiersprachen, die geschneidert und zu verwertet sind

• definieren Sie eine Datenbank (d. h., seine spezifischen Datentypen und die Beziehungen unter ihnen),
• manipulieren Sie seinen Inhalt (z.B, fügen Sie neue Datenereignisse ein, und aktualisieren Sie oder löschen Sie vorhandene), und
• fragen Sie es (d. h., bitten Sie um Information: Schätzen Sie und bekommen Sie jede Information wieder, die auf seinen Daten gestützt ist).

Datenbanksprachen sind "Datenmodell spezifisch", d. h. jede Sprache nimmt an und basiert auf einer bestimmten Struktur der Daten (der sich normalerweise unter verschiedenen Datenmodellen unterscheidet). Sie haben normalerweise Befehle, Ausführung der gewünschten Operationen in der Datenbank anzuweisen. Jeder solcher Befehl ist zu einem komplizierten Ausdruck (Programm) auf einer regelmäßigen Programmiersprache gleichwertig, und so im hingebungsvollen (Datenbank) programmierend, Sprachen vereinfachen die Aufgabe von behandelnden Datenbanken beträchtlich. Ausdrücke auf einer Datenbanksprache werden (durch einen Bearbeiter oder Dolmetscher, als regelmäßige Programmiersprachen) zu einem richtigen Computerprogramm automatisch umgestaltet, das läuft, während es auf die Datenbank zugreift und die erforderlichen Ergebnisse zur Verfügung stellt. Der folgende ist bemerkenswerte Beispiele:

SQL für das Verwandtschaftsmodell

Eine Hauptverwandtschaftsmustersprache, die durch den ganzen Verwandtschafts-DBMSs und einen Standard unterstützt ist.

SQL war eine der ersten Handelssprachen für das Verwandtschaftsmodell. Trotz des nicht Haftens am Verwandtschaftsmodell, wie beschrieben, durch Codd ist es die am weitesten verwendete Datenbanksprache geworden. Obwohl häufig beschrieben, als, und ist in reichem Maße eine Aussagesprache, SQL schließt auch Verfahrenselemente ein. SQL ist ein Standard von American National Standards Institute (ANSI) 1986, und der Internationalen Organisation für Standards (ISO) 1987 geworden. Seitdem ist der Standard mehrere Male mit Komfortmerkmalen erhöht worden. Jedoch bestehen Probleme der SQL-Codebeweglichkeit zwischen RDBMS Hauptprodukten noch erwartet, des vollen Gehorsams, oder verschiedene Interpretationen des Standards zu fehlen. Unter den erwähnten Gründen sind die große Größe, und die unvollständige Spezifizierung des Standards, sowie das Verkäufer-Schloss - darin.

OQL für das Gegenstand-Modell

Ein Gegenstand-Mustersprachstandard (durch Object Data Management Group), der das Design von einigen der neueren Anfragensprachen wie JDOQL und EJB QL beeinflusst hat, obwohl sie als verschiedene Geschmäcke nach OQL nicht betrachtet werden können.

XQuery für das XML Modell

XQuery ist gestützte Datenbanksprache eines XML (auch hat XQL genannt).

Datenbankarchitektur

Datenbankarchitektur (um von der DBMS Architektur bemerkenswert zu sein) kann einigermaßen als eine Erweiterung des Datenmodellierens angesehen werden. Es wird verwendet, um auf Voraussetzungen von verschiedenen Endbenutzern von derselben Datenbank, sowie für andere Vorteile günstig zu antworten. Zum Beispiel braucht eine Finanzabteilung einer Gesellschaft die Zahlungsdetails aller Angestellten als ein Teil der Ausgaben der Gesellschaft, aber nicht anderer vieler Details über Angestellte, die das Interesse der Personalabteilung sind. So brauchen verschiedene Abteilungen verschiedene Ansichten von der Datenbank der Gesellschaft, das sowohl schließen die Zahlungen der Angestellten, vielleicht in einem verschiedenen Niveau des Details (als auch präsentiert in verschiedenen Sehformen) ein. Um solcher Anforderung effektiv zu entsprechen, besteht Datenbankarchitektur aus drei Niveaus: äußerlich, begrifflich und inner. Klar das Trennen der drei Niveaus war eine Haupteigenschaft der Verwandtschaftsdatenbankmusterdurchführungen, die Datenbanken des 21. Jahrhunderts beherrschen.

• Das Außenniveau definiert, wie jeder Endbenutzer-Typ die Organisation seiner jeweiligen relevanten Daten in der Datenbank, d. h., die verschiedenen erforderlichen Endbenutzer-Ansichten versteht. Eine einzelne Datenbank kann jede Zahl von Ansichten am Außenniveau haben.
• Das Begriffsniveau vereinigt die verschiedenen Außenansichten in eine zusammenhängende ganze, globale Ansicht. Es stellt den gemeinsamen Nenner aller Außenansichten zur Verfügung. Es umfasst erforderlichen allgemeinen Daten ganzen Endbenutzers, d. h., alle Daten, von denen jede Ansicht abgestammt/geschätzt werden kann. Es wird auf die einfachstmögliche Weise solcher allgemeinen Daten zur Verfügung gestellt, und umfasst das Rückgrat der Datenbank. Es ist außer dem Spielraum der verschiedenen Datenbankendbenutzer, und dient Datenbankanwendungsentwicklern und definiert von Datenbankverwaltern, die die Datenbank bauen.
• Das Innere Niveau (oder Physische Niveau) sind eigentlich ein Teil der Datenbankdurchführung innerhalb eines DBMS (sieh Durchführungsabteilung unten). Es ist mit Kosten, Leistung, Skalierbarkeit und anderen betrieblichen Sachen beschäftigt. Es befasst sich mit Lagerungslay-Out des Begriffsniveaus, stellt Unterstützen-Lagerungsstrukturen wie Indizes zur Verfügung, um Leistung zu erhöhen, und versorgt gelegentlich Daten von individuellen Ansichten (verwirklichte Ansichten), geschätzt von allgemeinen Daten, wenn Leistungsrechtfertigung für solche Überfülle besteht. Es erwägt Leistungsvoraussetzungen aller Außenansichten, vielleicht das Widersprechen im Versuch, den gesamten Datenbankgebrauch durch ganzen seinen Endgebrauch gemäß den Datenbankabsichten und Prioritäten zu optimieren.

Alle drei Niveaus werden aufrechterhalten und gemäß dem Ändern von Bedürfnissen von Datenbankverwaltern aktualisiert, die häufig auch am Datenbankdesign teilnehmen.

Die obengenannte dreistufige Datenbankarchitektur bezieht sich auch auf und durch das Konzept der Datenunabhängigkeit motiviert zu werden, die für die lange Zeit als ein gewünschtes Datenbankeigentum beschrieben worden ist und eine der größeren anfänglichen treibenden Kräfte des Verwandtschaftsmodells war. Im Zusammenhang der obengenannten Architektur bedeutet es, dass an einem bestimmten Niveau vorgenommene Änderungen Definitionen und Software nicht betreffen, die mit höheren Niveau-Schnittstellen entwickelt ist, und am höheren Niveau automatisch vereinigt werden. Zum Beispiel betreffen Änderungen im inneren Niveau Anwendungsprogramme schriftliche verwendende Begriffsniveau-Schnittstellen nicht, der wesentliche Änderungsarbeit spart, die sonst erforderlich wäre.

In der Zusammenfassung ist das begriffliche ein Niveau des Umwegs zwischen innerem und äußerlichem. Einerseits stellt es eine allgemeine Ansicht von der Datenbank zur Verfügung, die von verschiedenen Außenansicht-Strukturen unabhängig ist, und andererseits ist es durch Details dessen unkompliziert, wie die Daten versorgt oder (inneres Niveau) geführt werden. Im Prinzip können jedes Niveau und sogar jede Außenansicht, durch ein verschiedenes Datenmodell präsentiert werden. In der Praxis gewöhnlich verwendet ein gegebener DBMS dasselbe Datenmodell sowohl für das äußerliche als auch für die Begriffsniveaus (z.B, Verwandtschaftsmodell). Das innere Niveau, das innerhalb des DBMS verborgen wird und von seiner Durchführung abhängt (sieht Durchführungsabteilung unten), verlangt ein verschiedenes Niveau des Details und verwendet seine eigenen Datenstruktur-Typen, normalerweise naturgemäß anders als die Strukturen der Außen- und Begriffsniveaus, die DBMS Benutzern (z.B, die Datenmodelle oben) ausgestellt werden: Während die Außen- und Begriffsniveaus konzentriert werden und DBMS Benutzern dienen, ist die Sorge des inneren Niveaus wirksame Durchführungsdetails.

Datenbanksicherheit

Datenbanksicherheit befasst sich mit allen verschiedenen Aspekten, den Datenbankinhalt, seine Eigentümer und seine Benutzer zu schützen. Es erstreckt sich vom Schutz vom absichtlichen unerlaubten Datenbankgebrauch bis unbeabsichtigte Datenbankzugänge durch unerlaubte Entitäten (z.B, eine Person oder ein Computerprogramm).

Der folgende ist Hauptgebiete der Datenbanksicherheit (unter vielen anderen).

Zugriffskontrolle

Datenbankzugang kontrolliert Geschäfte mit dem Steuern, wem (eine Person oder ein bestimmtes Computerprogramm) dem Zugang was Information in der Datenbank erlaubt wird. Die Information kann spezifische Datenbankgegenstände (z.B, Rekordtypen, spezifische Aufzeichnungen, Datenstrukturen), bestimmte Berechnung über bestimmte Gegenstände (z.B, Anfragentypen oder spezifische Abfragen), oder das Verwenden spezifischer Zugriffspfade zum ersteren (z.B, mit spezifischen Indizes oder anderen Datenstrukturen umfassen, um auf Information zuzugreifen).

Datenbankzugriffssteuerungen werden durch den speziellen autorisiert (vom Datenbankeigentümer) Personal gesetzt, das hingebungsvolle geschützte Sicherheit DBMS Schnittstellen verwendet.

Datensicherheit

Die Definition der Datensicherheit ändert sich und kann mit anderen Datenbanksicherheitsaspekten überlappen. Weit gehend befasst es sich mit Schutz spezifischer Klötze von Daten, beide physisch (d. h., von der Bestechung, oder Zerstörung oder Eliminierung; sieh z.B Physische Sicherheit), oder die Interpretation von ihnen oder Teile von ihnen zur bedeutungsvollen Information (z.B, durch das Schauen auf die Schnuren von Bit, die sie umfassen, spezifische gültige Kreditkartennummern schließend; sieh z.B Datenverschlüsselung).

Datenbankrechnungskontrolle

Datenbankrechnungskontrolle ist in erster Linie mit Überwachung verbunden, dass kein Sicherheitsbruch, in allen Aspekten, geschehen ist. Wenn Sicherheitsbruch dann entdeckt wird, werden alle möglichen Verbesserungshandlungen genommen.

Datenbankdesign

Datenbankdesign wird vor dem Gebäude davon getan, um Bedarf von Endbenutzern innerhalb eines gegebenen application/information-system zu decken, den die Datenbank beabsichtigt ist, um zu unterstützen. Das Datenbankdesign definiert die erforderlichen Daten und Datenstrukturen, die solch eine Datenbank umfasst. Ein Design wird normalerweise gemäß den allgemeinen drei architektonischen Niveaus einer Datenbank ausgeführt (sieh Datenbankarchitektur oben). Erstens wird das Begriffsniveau entworfen, der das gesamte Bild/Ansicht der Datenbank definiert, und alle wirklichen Elemente (Entitäten) widerspiegelt, hat die Datenbank vor, sowie die Beziehungen unter ihnen zu modellieren. Obendrein wird das Außenniveau, verschiedene Ansichten von der Datenbank, gemäß (vielleicht völlig verschieden) Bedürfnisse nach spezifischen Endbenutzer-Typen entworfen. Mehr Außenansichten können später hinzugefügt werden. Außenansicht-Voraussetzungen können das Design des Begriffsniveaus modifizieren (d. h. Fügen Sie Entitäten und Beziehungen hinzu/entfernen Sie), aber gewöhnlich unterstützt ein gut bestimmtes Begriffsniveau für eine Anwendung gut die meisten erforderlichen Außenansichten. Die Begriffsansicht bestimmt auch das innere Niveau (der sich in erster Linie mit Datenlay-Out in der Lagerung befasst) in reichem Maße. Außenansicht-Voraussetzung kann Unterstützen-Lagerungsstrukturen, wie verwirklichte Ansichten und Indizes für die erhöhte Leistung hinzufügen. Normalerweise wird die innere Schicht für die Spitzenleistung auf eine durchschnittliche Weise optimiert, die Leistungsvoraussetzungen in Betracht zieht (vielleicht kollidierend) verschiedener Außenansichten gemäß ihrer ziemlichen Bedeutung. Während das Begriffs- und Außenniveau-Design gewöhnlich unabhängig von jedem DBMS getan werden kann (DBMS-unabhängige Designsoftwarepakete, bestehen vielleicht mit Schnittstellen zu einem spezifischen populären DBMSs), das innere Niveau-Design verlässt sich hoch auf die Fähigkeiten und innere Datenstruktur des spezifischen verwerteten DBMS (sieh die Durchführungsabteilung unten).

Eine allgemeine Weise, Begriffsniveau-Design auszuführen, soll das Entitätsbeziehungsmodell (ERM) verwenden (sowohl der grundlegende, als auch mit der möglichen Erhöhung, die es durchgesehen hat), da es eine aufrichtige, intuitive Wahrnehmung Elemente und Semantik einer Anwendung zur Verfügung stellt. Eine alternative Annäherung, die dem ERM vorangegangen ist, verwendet das Verwandtschaftsmodell und die Abhängigkeiten (mathematische Beziehungen) unter Daten, um die Datenbank zu normalisieren, d. h., die ("optimalen") Beziehungen (Datenaufzeichnung oder tupple Typen) in der Datenbank zu definieren. Obwohl ein großer Körper der Forschung für diese Methode besteht, ist es komplizierter, weniger intuitiv, und nicht wirksamer als die ERM Methode. So wird Normalisierung in der Praxis weniger verwertet als die ERM Methode.

Der ERM kann weniger fein sein als Normalisierung in mehreren Aspekten, aber es gewinnt die erforderlichen Hauptabhängigkeiten, die durch Schlüssel/Bezeichner von Entitäten und Beziehungen veranlasst werden. Auch der ERM schließt von Natur aus die wichtigen Einschließungsabhängigkeiten ein (d. h., ein Entitätsbeispiel, das nicht besteht (ist nicht ausführlich eingefügt worden), kann in einer Beziehung mit anderen Entitäten nicht erscheinen), die gewöhnlich in der Normalisierung ignoriert worden sind. Außerdem erlaubt der ERM Entitätstyp-Generalisation (Zu sein - eine Beziehung) und einbezogenes Eigentum (Attribut) Erbe (ähnlich zu dem hat im Gegenstand-Modell gefunden).

Ein anderer Aspekt des Datenbankdesigns ist seine Sicherheit. Es schließt beide Definieren-Zugriffskontrolle zu Datenbankgegenständen (z.B, Entitäten, Ansichten) sowie das Definieren von Sicherheitsniveaus und Methoden für die Daten selbst ein (Sieh Datenbanksicherheit oben).

Entitäten und Beziehungen

Die meisten Designmethoden der gemeinsamen Datenbank basieren auf dem Entitätsbeziehungsmodell (ERM oder ER Modell). Dieses Modell sieht die Welt auf eine vereinfachte, aber sehr starke Weise an: Es besteht aus "Entitäten" und den "Beziehungen" unter ihnen. Entsprechend besteht eine Datenbank aus der Entität und den Beziehungstypen, dem jedem mit definierten Attributen (Feldtypen) dass konkrete Musterentitäten und Beziehungen. Das Modellieren einer Datenbank gibt auf diese Weise normalerweise eine wirksame mit gewünschten Eigenschaften nach (als in einigen normalen Formen; sieh Normalisierung unten). Solche Modelle können zu jedem anderen Datenmodell übersetzt werden, das durch jeden spezifischen DBMS erforderlich ist, für eine wirksame Datenbank zu bauen.

Datenbanknormalisierung

Im Design einer Verwandtschaftsdatenbank wird der Prozess von organisierenden Datenbankbeziehungen, um Überfülle zu minimieren, Normalisierung genannt. Die Absicht ist, gut strukturierte Beziehungen zu erzeugen, so dass Hinzufügungen, Auswischen und Modifizierungen eines Feldes in gerade einer Beziehung (Tisch) gemacht werden können, ohne sich über das Äußere und die Aktualisierung desselben Feldes in anderen Beziehungen zu sorgen. Der Prozess ist algorithmisch und auf Abhängigkeiten basiert (mathematische Beziehungen), die unter den Feldtypen von Beziehungen bestehen. Das Prozess-Ergebnis bringt die Datenbankbeziehungen in eine bestimmte "normale Form". Mehrere normale Formen bestehen mit verschiedenen Eigenschaften.

Datenbankgebäude, das Aufrechterhalten und die Einstimmung

Nach dem Entwerfen einer Datenbank für eine Anwendung kommt die Bühne an, die Datenbank zu bauen. Normalerweise kann ein passender Mehrzweck-DBMS ausgewählt werden, um für diesen Zweck verwertet zu werden. Ein DBMS stellt die erforderlichen von Datenbankverwaltern zu verwertenden Benutzerschnittstellen zur Verfügung, um die Datenstrukturen der erforderlichen Anwendung innerhalb des jeweiligen Datenmodells des DBMS zu definieren. Andere Benutzerschnittstellen werden verwendet, um erforderliche DBMS Rahmen (wie Sicherheit verbunden, Lagerungszuteilungsrahmen, usw.) auszuwählen.

Wenn die Datenbank bereit ist (alle seine Datenstrukturen und andere erforderliche Bestandteile definiert werden), wird sie normalerweise mit den Daten der anfänglichen Anwendung bevölkert (Datenbankinitialisierung, die normalerweise ein verschiedenes Projekt ist; in vielem Fall-Verwenden spezialisierte DBMS-Schnittstellen, die Hauptteil-Einfügung unterstützen), vor dem Bilden davon betrieblich. In einigen Fällen wird die Datenbank betrieblich, während leer, von den Daten der Anwendung, und Daten werden entlang seiner Operation angesammelt.

Nach der Vollendung des Gebäudes kommt die Datenbank und Bildens davon betrieblich die Datenbankverwaltungsbühne an: Verschiedene Datenbankrahmen können Änderungen brauchen und für die bessere Leistung stimmend, die Datenstrukturen der Anwendung können geändert oder hinzugefügt werden, neue zusammenhängende Anwendungsprogramme können geschrieben werden, um zur Funktionalität der Anwendung usw. beizutragen.

Verschiedene Gebiete

Datenbankwanderung zwischen DBMSs

:See auch Datenbankwanderung im Datenfluss

Eine mit einem DBMS gebaute Datenbank ist zu einem anderen DBMS nicht tragbar (d. h. der andere DBMS kann es nicht führen). Jedoch in einigen Situationen ist es wünschenswert, sich zu bewegen, eine Datenbank von einem DBMS bis einen anderen abzuwandern. Die Gründe sind in erster Linie wirtschaftlich (verschiedener DBMSs kann verschiedene Gesamtkosten des Eigentumsrechts-TCO haben), funktionell, und betrieblich (kann verschiedener DBMSs verschiedene Fähigkeiten haben). Die Wanderung ist mit der Transformation der Datenbank von einem Typ DBMS bis einen anderen verbunden. Die Transformation sollte aufrechterhalten (wenn möglich) die Datenbank hat Anwendung (d. h., alle zusammenhängenden Anwendungsprogramme) intakt verbunden. So sollten die architektonischen und Begriffsaußenniveaus der Datenbank in der Transformation aufrechterhalten werden. Es kann gewünscht werden, dass auch einige Aspekte der Architektur inneres Niveau aufrechterhalten werden. Eine komplizierte oder große Datenbankwanderung kann ein kompliziertes und kostspieliges (ehemaliges) Projekt allein sein, das factored in die Entscheidung sein sollte abzuwandern. Das, obwohl Werkzeuge bestehen können, um Wanderung zwischen spezifischem DBMS zu helfen. Normalerweise stellt ein DBMS Verkäufer Werkzeuge zur Verfügung, um Importieren-Datenbanken von anderem populärem DBMSs zu helfen.

Durchführung: Datenbankverwaltungssysteme

oder Wie Datenbankgebrauch-Anforderungen entsprochen wird

Ein Datenbankverwaltungssystem (DBMS) ist ein System, das erlaubt, Datenbanken zu bauen und aufrechtzuerhalten, sowie ihre Daten zu verwerten und Information davon wiederzubekommen. Ein DBMS definiert den Datenbanktyp, den er, sowie seine Funktionalität und betriebliche Fähigkeiten unterstützt. Ein DBMS stellt die inneren Prozesse für Außenanwendungen zur Verfügung hat auf sie gebaut. Die Endbenutzer von einer solcher spezifischen Anwendung werden gewöhnlich nur zu dieser Anwendung ausgestellt und wirken mit dem DBMS nicht direkt aufeinander. So genießen Endbenutzer die Effekten des zu Grunde liegenden DBMS, aber seine internals sind für Endbenutzer völlig unsichtbar. Datenbankentwerfer und Datenbankverwalter wirken mit dem DBMS durch hingebungsvolle Schnittstellen aufeinander, um die Datenbanken der Anwendungen zu bauen und aufrechtzuerhalten, und so noch einige Kenntnisse zu brauchen und darüber verstehend, wie DBMSs funktionieren und die Außenschnittstellen der DBMS und stimmende Rahmen.

Ein DBMS besteht aus der Software, die Datenbanken bedient, Lagerung, Zugang, Sicherheit, Unterstützung und andere Möglichkeiten zur Verfügung stellend, erforderlichen Anforderungen zu entsprechen. DBMSs kann gemäß dem Datenbankmodell (En) kategorisiert werden, das sie, solch so Verwandtschafts- oder XML, der Typ (En) des Computers unterstützen, den sie unterstützen wie eine Server-Traube oder ein Mobiltelefon, die Anfragensprache (N), die auf die Datenbank, wie SQL oder XQuery, Leistungsumtausche, wie maximale Skala oder Höchstgeschwindigkeit oder andere zugreifen. Einige DBMSs bedecken mehr als einen Zugang in diesen Kategorien, z.B vielfache Anfragensprachen unterstützend. Datenbanksoftware unterstützt normalerweise die Offene Datenbankkonnektivität (ODBC) Standard, der der Datenbank erlaubt (einigermaßen) mit anderen Datenbanken zu integrieren.

Die Entwicklung eines reifen Mehrzweck-DBMS nimmt normalerweise mehrere Jahre und viele Arbeitsjahre. Entwickler von DBMS aktualisieren normalerweise ihr Produkt, um zu folgen und den Fortschritt im Computer und den Speichertechniken auszunutzen. Mehrere DBMS Produkte wie Orakel und IBM DB2 sind in der andauernden Entwicklung seit den 1980er Jahren der 1970er Jahre gewesen. Da DBMSs einen bedeutenden wirtschaftlichen Markt umfassen, ziehen Computer und Lagerungsverkäufer häufig DBMS Voraussetzungen in ihren eigenen Entwicklungsplänen in Betracht.

DBMS Architektur: DBMS Hauptbestandteile

DBMS Architektur gibt seine Bestandteile (einschließlich Beschreibungen ihrer Funktionen) und ihrer Schnittstellen an. DBMS Architektur ist von der Datenbankarchitektur verschieden. Der folgende ist DBMS Hauptbestandteile:

• DBMS Außenschnittstellen - Sie sind die Mittel, mit dem DBMS (beide Wege, zu und vom DBMS) zu kommunizieren, um alle für den DBMS erforderlichen Operationen durchzuführen. Diese können Operationen auf einer Datenbank oder Operationen sein, um den DBMS zu bedienen und zu führen. Zum Beispiel:

::-Direkte Datenbankoperationen: das Definieren von Datentypen, Zuweisen von Sicherheitsniveaus, Aktualisieren von Daten, Fragen der Datenbank, usw.

::-Operationen haben sich auf die DBMS Operation und das Management bezogen: Unterstützen Sie und, stellen Sie Datenbankwiederherstellung, Sicherheitsüberwachung, Datenbanklagerungszuteilung und Datenbanklay-Out-Konfigurationsüberwachung, Leistungsüberwachung und Einstimmung usw. wieder her.

:An Außenschnittstelle kann irgendein eine Benutzerschnittstelle (z.B, normalerweise für einen Datenbankverwalter), oder eine Anwendung, Schnittstelle programmierend (API) sein, die für die Kommunikation zwischen einem Anwendungsprogramm und dem DBMS verwendet ist.

• Datenbanksprachmotoren (oder Verarbeiter) - die Meisten Operationen auf Datenbanken werden durch den Ausdruck auf Datenbanksprachen durchgeführt (sieh oben). Sprachen bestehen für die Datendefinition, Datenmanipulation und Abfragen (z.B, SQL), sowie um verschiedene Aspekte der Sicherheit, und mehr anzugeben. Sprachausdrücke werden in einen DBMS durch richtige Schnittstellen gefüttert. Ein Sprachmotor bearbeitet die Sprachausdrücke (durch einen Bearbeiter oder Sprachdolmetscher), um die beabsichtigten Datenbankoperationen aus dem Ausdruck in einer Weise herauszuziehen, wie sie durch den DBMS durchgeführt werden können.
• Abfrage optimizer - Führt Anfragenoptimierung auf jeder Abfrage Durch, um dafür den effizientesten Anfragenplan (eine teilweise Ordnung (Baum) von Operationen) zu wählen, um durchgeführt zu werden, um das Anfragenergebnis zu schätzen.
• Datenbankmotor - Führt die erhaltenen Datenbankoperationen auf den Datenbankgegenständen normalerweise an ihrer Darstellung des höheren Niveaus Durch.
• Lagerungsmotor - übersetzt die Operationen zu auf niedriger Stufe Operationen auf den Lagerungsbit. In einigen Verweisungen wird der Lagerungsmotor als ein Teil des Datenbankmotors angesehen.
• Transaktionsmotor - zu Genauigkeits- und Zuverlässigkeitszwecken die meisten DBMS inneren Operationen wird kurz zusammengefasst in Transaktionen (sieh unten) durchgeführt. Transaktionen können auch äußerlich zum DBMS angegeben werden, um eine Gruppe von Operationen kurz zusammenzufassen. Der Transaktionsmotor verfolgt alle Transaktionen und führt ihre Ausführung gemäß den Transaktionsregeln (z.B, richtige Parallelitätskontrolle, und richtig begehen oder brechen für jeden ab).
• DBMS Management und Operationsbestandteil - Umfassen viele Bestandteile, die sich mit dem ganzen DBMS Management und betrieblichen Aspekten wie Leistungsüberwachung und Einstimmung befassen, unterstützen und, Wiederherstellung von Misserfolg, Sicherheitsmanagement und Überwachung, Datenbanklagerungszuteilung und Datenbanklagerungslay-Out-Überwachung usw. wieder herstellen.

Datenbanklagerung

Datenbanklagerung ist der Behälter der physischen Verkörperung einer Datenbank. Es umfasst das Innere (physische) Niveau in der Datenbankarchitektur. Es enthält auch die ganze Information erforderlich (z.B, metadata, "Daten über die Daten" und innere Datenstrukturen), um das Begriffsniveau und Außenniveau vom Inneren Niveau, wenn erforderlich, wieder aufzubauen. Es ist nicht ein Teil des DBMS, aber eher manipuliert durch den DBMS (durch seinen Lagerungsmotor; sieh oben), die Datenbank zu führen, die darin wohnt. Obwohl normalerweise zugegriffen, durch einen DBMS durch das zu Grunde liegende Betriebssystem (und häufig das Verwenden der Dateisysteme der Betriebssysteme als Zwischenglieder für das Lagerungslay-Out) sind Lagerungseigenschaften und Konfigurationseinstellung für die effiziente Operation des DBMS äußerst wichtig, und werden so von Datenbankverwaltern nah aufrechterhalten. Ein DBMS, während in der Operation, immer seine Datenbank hat, die in mehreren Typen der Lagerung (z.B, Gedächtnis und Außenlagerung) wohnt. Die Datenbankdaten und die zusätzliche erforderliche Information, vielleicht in sehr großen Beträgen, werden in Bit codiert. Daten wohnen normalerweise in der Lagerung in Strukturen, die völlig verschieden von der Weise aussehen, wie die Daten in den Begriffs- und Außenniveaus, aber auf Weisen schauen, die versuchen (das bestmögliche) die Rekonstruktion dieser Niveaus, wenn erforderlich, durch Benutzer und Programme zu optimieren, sowie um zusätzliche Typen der erforderlichen Information von den Daten (z.B zu schätzen, wenn sie die Datenbank fragen).

Im Prinzip kann die Datenbanklagerung als ein geradliniger Adressraum angesehen werden, wo jedes Bit von Daten seine einzigartige Adresse in diesem Adressraum hat. Praktisch nur ein sehr kleine Prozentsatz von Adressen wird als anfängliche Bezugspunkte behalten (der auch Lagerung verlangt), und auf die meisten Datenbankdaten durch den Umweg mit Versetzungsberechnungen (Entfernung in Bit von den Bezugspunkten) und Datenstrukturen zugegriffen wird, die Zugriffspfade definieren (Zeigestöcke verwendend), zu allen erforderlichen Daten auf die wirksame Weise, die für die erforderlichen Datenzugriffsoperationen optimiert ist.

Daten

Das Codieren der Daten und Fehlerkorrekturcodes

• Daten werden durch das Zuweisen von wenig Muster jedem Sprachalphabet-Charakter, Ziffer, anderen numerischen Mustern und Multimediagegenstand verschlüsselt. Viele Standards bestehen, um (z.B, ASCII, JPEG, MPEG-4) zu verschlüsseln.
• Durch das Hinzufügen von Bit zu jeder verschlüsselten Einheit erlaubt die Überfülle, sowohl Fehler in codierten Daten zu entdecken als auch sie gestützt auf mathematischen Algorithmen zu korrigieren. Fehler kommen regelmäßig in niedrigen Wahrscheinlichkeiten wegen des zufälligen Bit-Werts schnipsende oder "physische Bit-Erschöpfung vor," Verlust des physischen Bit in der Lagerung seine Fähigkeit, unterscheidbaren Wert (0 oder 1), oder wegen Fehler darin aufrechtzuerhalten, beerdigen oder Intracomputerkommunikation. Ein zufälliger Bit-Flip (z.B, wegen der zufälligen Radiation) wird normalerweise nach der Entdeckung korrigiert. Ein bisschen, oder eine Gruppe von schlecht funktionierenden physischen Bit (nicht immer ist das spezifische fehlerhafte Bit bekannt; Gruppendefinition hängt von spezifischem Speichergerät ab) wird normalerweise automatisch umzäunt, aus dem Gebrauch durch das Gerät genommen, und durch eine andere fungierende gleichwertige Gruppe im Gerät ersetzt, wo die korrigierten Bit-Werte (wenn möglich) wieder hergestellt werden. Die Methode der Zyklischen Redundanzprüfung (CRC) wird normalerweise in der Lagerung für die Fehlerentdeckung verwendet.

Datenkompression

Datenkompressionsmethoden erlauben in vielen Fällen, eine Schnur von Bit durch eine kürzere Bit-Schnur ("Kompresse") zu vertreten und die ursprüngliche Schnur wieder aufzubauen (dekomprimieren) wenn erforderlich. Das erlaubt, wesentlich weniger Lagerung (Zehnen von Prozenten) für viele Typen von Daten auf Kosten von mehr Berechnung (Kompresse zu verwerten und wenn erforderlich, zu dekomprimieren). Die Analyse des Umtauschs zwischen Lagerung kostensparend und Kosten der zusammenhängenden Berechnung und möglichen Verzögerungen in der Datenverfügbarkeit wird vor dem Entscheiden getan, ob man bestimmte Daten in einer Datenbank zusammengepresst hält oder nicht.

Datenkompression wird normalerweise durch die Datendefinitionsschnittstelle des DBMS kontrolliert, aber kann in einigen Fällen ein Verzug und automatisch sein.

Datenverschlüsselung

Für Sicherheitsgründe können bestimmte Typen von Daten (z.B, Kreditkarteninformation) encrypted in der Lagerung behalten werden, um die Möglichkeit der unerlaubten Informationsrekonstruktion aus Klötzen von Lagerungsschnellschüssen (genommen entweder über die ungeahnte Verwundbarkeit in einem DBMS, oder wahrscheinlicher, durch das Umleiten davon) zu verhindern.

Datenverschlüsselung wird normalerweise durch die Datendefinitionsschnittstelle des DBMS kontrolliert, aber kann in einigen Fällen ein Verzug und automatisch sein.

Datenlagerungstypen

Diese Sammlung von Bit beschreibt sowohl die enthaltenen Datenbankdaten als auch seinen zusammenhängenden metadata (d. h., Daten, der die enthaltenen Daten beschreibt und Computerprogrammen erlaubt, die Datenbankdaten richtig zu manipulieren). Die Größe einer Datenbank kann heutzutage Zehnen von Terabytes sein, wo ein Byte acht Bit ist. Die physische Verkörperung von wenig kann verschiedene vorhandene Technologien verwenden, während neue und verbesserte Technologien ständig unter der Entwicklung sind. Allgemeine Beispiele sind:

• Magnetisches Medium (z.B, in der Magnetischen Platte) - Orientierung des magnetischen Feldes in magnetischen Gebieten auf einer Oberfläche des Materials (zwei Orientierungsrichtungen, für 0 und 1).
• Dynamisches Gedächtnis des zufälligen Zugangs (DRAM) - Staat eines elektronischen Miniaturstromkreises, der aus wenigen Transistoren (unter Millionen heutzutage) in einem einheitlichen Stromkreis (zwei Staaten für 0 und 1) besteht.

Diese zwei Beispiele sind beziehungsweise für zwei Hauptlagerungstypen:

• Unvergängliche Lagerung kann seine Bit-Staaten (0s und 1s) ohne Versorgung der elektrischen Leistung aufrechterhalten, oder wenn Macht-Versorgung unterbrochen wird;
• Flüchtige Lagerung verliert seine Bit-Werte, wenn Macht-Versorgung unterbrochen wird (d. h. sein Inhalt wird gelöscht).

Hoch entwickelte Lagerungseinheiten, die tatsächlich wirksame hingebungsvolle parallele Computer sein können, die einen großen Betrag der unvergänglichen Lagerung unterstützen, müssen normalerweise auch Bestandteile mit der flüchtigen Lagerung einschließen. Einige solche Einheiten verwenden Batterien, die Macht seit mehreren Stunden im Falle der Außenmacht-Unterbrechung zur Verfügung stellen können (z.B, sieh den EMC Symmetrix), und erhalten Sie so den Inhalt der flüchtigen intakten Lagerungsteile aufrecht. Kurz bevor die Batterien solch eines Geräts ihre Macht verlieren, das Gerät normalerweise automatisch seinen flüchtigen zufriedenen Teil (in den unvergänglichen) Zurück- und stellt ab, um seine Daten zu schützen.

Datenbanken sind gewöhnlich (in Bezug auf die Wichtigkeit und erforderliche Investition in Mitteln, z.B, Zeit, Geld zu teuer, um sie zu bauen), um durch eine Macht-Unterbrechung verloren zu werden. So an jedem Punkt rechtzeitig wohnt der grösste Teil ihres Inhalts in der unvergänglichen Lagerung. Selbst wenn aus dem betrieblichen Grund sehr große Teile von ihnen in der flüchtigen Lagerung wohnen (z.B, Zehnen von Gigabytes im flüchtigen Gedächtnis, für Datenbanken im Gedächtnis), wird der grösste Teil davon in der unvergänglichen Lagerung unterstützt. Ein relativ kleiner Teil davon, das provisorisch unvergängliche Unterstützung nicht haben kann, kann durch richtige automatische Datenbankwiederherstellungsverfahren nach dem flüchtigen Lagerungsinhalt-Verlust wieder aufgebaut werden.

Mehr Beispiele von Lagerungstypen:

• Flüchtige Lagerung kann in Verarbeitern, Computergedächtnis (z.B, SCHLUCK) usw. gefunden werden.
• Unvergängliche Lagerungstypen schließen ROM, EPROM, Festplatte-Laufwerke, Blitz-Gedächtnis und Laufwerke, Lagerungsreihe usw. ein.

Lagerungsmetrik

Datenbanken verwenden immer mehrere Typen der Lagerung, wenn betrieblich (und hat mehrere wenn müßig einbezogen). Verschiedene Typen können sich in ihren Eigenschaften bedeutsam unterscheiden, und die optimale Mischung von Lagerungstypen wird durch die Typen und Mengen von Operationen beschlossen, dass jeder Lagerungstyp, sowie Rücksichten wie physischer Raum und Energieverbrauch und Verschwendung leisten muss (der kritisch für eine große Datenbank werden kann). Lagerungstypen können durch die folgenden Attribute kategorisiert werden:

• Flüchtig/unvergänglich.
• Kosten des Mediums (z.B, pro Megabyte), Kosten, um zu funktionieren (haben sich Kosten der Energie pro Einheitszeit verzehrt).
• Zugriffsgeschwindigkeit (z.B, Bytes pro Sekunde).
• Körnung — vom feinen bis rauen (z.B, Größe in Bytes der Zugriffsoperation).
• Zuverlässigkeit (die Wahrscheinlichkeit des spontanen Bit schätzen Änderung unter verschiedenen Bedingungen).
• Maximale mögliche Zahl dessen schreibt (jedes spezifischen Bit oder spezifischer Gruppe von Bit; konnte durch die verwendete Technologie beschränkt werden (z.B, "schreiben Sie, sobald" oder "zweimal schreiben"), oder wegen "physischer Bit-Erschöpfung," Verlust der Fähigkeit, zwischen 0, 1 Staaten wegen vieler Zustandsänderungen (z.B, im Blitz-Gedächtnis)) zu unterscheiden.
• Macht musste funktionieren (Energie pro Zeit; die Energie pro Byte hat zugegriffen), Energieeffizienz, Hitze, um sich zu zerstreuen.
• Packungsdichte (z.B, realistische Zahl von Bytes pro Volumen-Einheit)

Schutz des Speichergerät-Inhalts: Das Gerät-Widerspiegeln (Erwiderung) und ÜBERFALL

:See auch Plattenlagerungserwiderung

Während eine Gruppe der Bit-Funktionsstörung durch Fehlerentdeckungs- und Korrektur-Mechanismen aufgelöst werden kann (sieh oben), Speichergerät-Funktionsstörung verlangt verschiedene Lösungen. Die folgenden Lösungen werden allgemein verwendet und für die meisten Speichergeräte gültig:

• Das Gerät-Widerspiegeln (Erwiderung) - Eine allgemeine Lösung des Problems erhält ständig eine identische Kopie des Gerät-Inhalts auf einem anderen Gerät (normalerweise desselben Typs) aufrecht. Die Kehrseite ist, dass das die Lagerung verdoppelt, und beide Geräte (Kopien) gleichzeitig mit einigen oben und vielleicht einigen Verzögerungen aktualisiert werden müssen. Die Oberseite ist möglicher Begleitumstand, der derselben Datengruppe durch zwei unabhängige Prozesse gelesen ist, die Leistung vergrößert. Wenn eines der wiederholten Geräte entdeckt wird, um fehlerhaft zu sein, ist die andere Kopie noch betrieblich, und wird verwertet, um eine neue Kopie auf einem anderen Gerät (gewöhnlich verfügbar betrieblich in einer Lache von Hilfsgeräten für diesen Zweck) zu erzeugen.
• Überflüssige Reihe von unabhängigen Platten (ÜBERFALL) - Diese Methode verallgemeinert das Gerät, das oben widerspiegelt, indem es ein Gerät in einer Gruppe von N Geräten erlaubt wird, zu scheitern und durch den Inhalt ersetzt zu werden, wieder hergestellt (Widerspiegelndes Gerät ist ÜBERFALL mit N=2). ÜBERFALL-Gruppen von N=5 oder N=6 sind üblich. N> 2 spart Lagerung, wenn er sich mit N=2, auf Kosten von mehr Verarbeitung während beider regelmäßigen Operation (mit häufig der reduzierten Leistung) und fehlerhafter Gerät-Ersatz vergleicht.

Gerät widerspiegelnder und typischer ÜBERFALL wird entworfen, um einen Einzelgerät-Misserfolg in der ÜBERFALL-Gruppe von Geräten zu behandeln. Jedoch, wenn ein zweiter Misserfolg vorkommt, bevor die ÜBERFALL-Gruppe vom ersten Misserfolg völlig repariert wird, dann können Daten verloren werden. Die Wahrscheinlichkeit eines einzelnen Misserfolgs ist normalerweise klein. So ist die Wahrscheinlichkeit von zwei Misserfolgen in derselben ÜBERFALL-Gruppe in der Zeitnähe (ungefähr die Wahrscheinlichkeit quadratisch gemacht, d. h., multipliziert allein) viel kleiner. Wenn eine Datenbank sogar solche kleinere Wahrscheinlichkeit des Datenverlustes nicht dulden kann, dann wird die ÜBERFALL-Gruppe selbst (widergespiegelt) wiederholt. In vielen Fällen wird solches Widerspiegeln geografisch entfernt in einer verschiedenen Lagerungsreihe getan, um auch Wiederherstellung von Katastrophen zu behandeln (sieh Katastrophe-Wiederherstellung oben).

Datenbanklagerungslay-Out

Datenbankbit werden in der Lagerung in Datenstrukturen und Gruppierung gelegt, die sowohl bekannte wirksame Algorithmen ausnutzen kann, um sie und die Lagerung eigene Eigenschaften wiederzubekommen als auch zu manipulieren. Normalerweise ist die Lagerung selbst Design, um Anforderungen von verschiedenen Gebieten zu entsprechen, die umfassend Lagerung einschließlich Datenbanken verwerten. Ein DBMS in der Operation verwertet immer gleichzeitig mehrere Lagerungstypen (z.B, Gedächtnis und Außenlagerung) mit jeweiligen Lay-Out-Methoden.

Datenbanklagerungshierarchie

Eine Datenbank, während in der Operation, wohnt gleichzeitig in mehreren Typen der Lagerung. Durch die Natur von zeitgenössischen Computern wohnt der grösste Teil des Datenbankteils innerhalb eines Computers, der den DBMS veranstaltet (teilweise wiederholt) in der flüchtigen Lagerung. Daten (Stücke der Datenbank), die bearbeitet/manipuliert werden, wohnen innerhalb eines Verarbeiters vielleicht in den geheimen Lagern des Verarbeiters. Diese Daten werden von/geschrieben zum Gedächtnis, normalerweise durch einen Computerbus (so weit normalerweise flüchtige Lagerungsbestandteile) gelesen. Computergedächtnis teilt Daten (übertragen) Außenlagerung, normalerweise durch Standardlagerungsschnittstellen oder Netze (z.B, Faser-Kanal, iSCSI) mit. Eine Lagerungsreihe, eine allgemeine Außenlagerungseinheit, hat normalerweise Lagerungshierarchie davon eigen von einem schnellen geheimen Lager, normalerweise aus (flüchtig und schnell) SCHLUCK bestehend, der (wieder über Normanschlüsse) zu Laufwerken, vielleicht mit verschiedenen Geschwindigkeiten, wie Blitz-Laufwerke und magnetische (unvergängliche) Laufwerke verbunden wird. Die Laufwerke können mit magnetischen Bändern verbunden werden, auf denen normalerweise die am wenigsten aktiven Teile einer großen Datenbank, oder Datenbankaushilfsgenerationen wohnen können.

Normalerweise besteht eine Korrelation zurzeit zwischen Lagerungsgeschwindigkeit und Preis, während die schnellere Lagerung normalerweise flüchtig ist.

Datenstrukturen

Eine Datenstruktur ist eine abstrakte Konstruktion, die Daten in einer gut definierten Weise einbettet. Eine effiziente Datenstruktur erlaubt, die Daten auf effiziente Weisen zu manipulieren. Die Datenmanipulation kann Dateneinfügung, Auswischen, das Aktualisieren und die Wiederauffindung in verschiedenen Weisen einschließen. Ein bestimmter Datenstruktur-Typ kann in bestimmten Operationen sehr wirksam, und in anderen sehr unwirksam sein. Ein Datenstruktur-Typ wird nach der DBMS Entwicklung ausgewählt, um am besten die Operationen zu entsprechen, die für die Typen von Daten erforderlich sind, die es enthält. Der Typ der Datenstruktur, die für eine bestimmte Aufgabe normalerweise auch ausgewählt ist, zieht den Typ der Lagerung in Betracht, in der es wohnt (z.B, Geschwindigkeit des Zugangs, hat die minimale Größe des Lagerungsklotzes, usw. zugegriffen). In einer DBMSs Datenbank haben Verwalter die Flexibilität, um unter Optionen von Datenstrukturen auszuwählen, Benutzerdaten aus Leistungsgründen zu enthalten. Manchmal haben die Datenstrukturen selectable Rahmen, um die Datenbankleistung abzustimmen.

Datenbanken können Daten in vielen Datenstruktur-Typen versorgen. Allgemeine Beispiele sind der folgende:

• bestellte/nicht eingeordnete flache Dateien
• Hash-Tabellen
• B + Bäume
• ISAM
• Haufen

Anwendungsdaten und DBMS Daten

Ein typischer DBMS kann die Daten der Anwendung nicht versorgen, der er allein dient. Um die Anwendungsdaten zu behandeln, muss der DBMS das Daten in Datenstrukturen versorgen, die spezifische Daten durch sich umfassen. Außerdem braucht der DBMS seine eigenen Datenstrukturen und viele Typen von Buchhaltungsdaten wie Indizes und Klotz. Die DBMS Daten sind ein integraler Bestandteil der Datenbank und können einen wesentlichen Teil davon umfassen.

Das Datenbankindexieren

Das Indexieren ist eine Technik, um Datenbankleistung zu verbessern. Die vielen Typen von Indizes teilen das allgemeine Eigentum, dass sie das Bedürfnis reduzieren, jeden Zugang zu untersuchen, wenn sie eine Abfrage führen. In großen Datenbanken kann das Anfragenzeit/Kosten durch Größenordnungen reduzieren. Die einfachste Form des Index ist eine sortierte Liste von Werten, die mit einer binären Suche mit einer angrenzenden Verweisung auf die Position des Zugangs gesucht werden können, der dem Index hinter einem Buch analog ist. Dieselben Daten können vielfache Indizes haben (eine Mitarbeiterdatenbank konnte durch den Nachnamen und das Miete-Datum mit einem Inhaltsverzeichnis versehen werden.)

Indizes betreffen Leistung, aber nicht Ergebnisse. Datenbankentwerfer können hinzufügen oder Indizes entfernen, ohne Anwendungslogik zu ändern, Wartungskosten reduzierend, als die Datenbank wächst und sich Datenbankgebrauch entwickelt.

In Anbetracht einer besonderen Abfrage ist die Abfrage der DBM optimizer dafür verantwortlich, die effizienteste Strategie auszudenken, um das Zusammenbringen von Daten zu finden.

Indizes können Datenzugang beschleunigen, aber sie verbrauchen Raum in der Datenbank, und müssen jedes Mal aktualisiert werden, wenn die Daten verändert werden. Indizes können deshalb Datenzugang beschleunigen, aber Datenwartung verlangsamen. Diese zwei Eigenschaften bestimmen, ob ein gegebener Index der Kosten wert ist.

Das Datenbankdatensammeln

In vielen Fällen wird wesentliche Leistungsverbesserung gewonnen, wenn verschiedene Typen von Datenbankgegenständen, die gewöhnlich zusammen verwertet werden, in der Lagerung in der Nähe gelegt werden, gebündelt. Das erlaubt gewöhnlich, erforderliche verwandte Gegenstände von der Lagerung in der minimalen Zahl von Eingangsoperationen (jeder manchmal wesentlich zeitaufwendig) wiederzubekommen. Sogar für Datenbanken im Gedächtnis stellt das Sammeln Leistungsvorteil wegen der allgemeinen Anwendung von großen geheimen Lagern für Eingangsproduktionsoperationen im Gedächtnis mit dem ähnlichen resultierenden Verhalten zur Verfügung.

Zum Beispiel kann es vorteilhaft sein, um eine Aufzeichnung eines Artikels im Lager mit allen seinen jeweiligen Ordnungsaufzeichnungen zu bündeln. Die Entscheidung dessen, ob man bestimmte Gegenstände oder nicht bündelt von der Anwendungsstatistik der Gegenstände, Gegenstand-Größen, Größen der geheimen Lager, Lagerungstypen usw. abhängt. In einer Verwandtschaftsdatenbank, die die zwei jeweiligen Beziehungen "Sachen" und "Ordnungen" bündelt, läuft auf das Sparen der teuren Ausführung einer Verbindungslinie-Operation zwischen den zwei Beziehungen hinaus, wann auch immer solch eine Verbindungslinie in einer Abfrage erforderlich ist (das Verbindungslinie-Ergebnis ist bereits in der Lagerung durch das Sammeln bereit, verfügbar, um verwertet zu werden).

Datenbank hat Ansichten verwirklicht

Häufig wird Lagerungsüberfülle verwendet, um Leistung zu vergrößern. Ein allgemeines Beispiel versorgt verwirklichte Ansichten, die oft erforderliche Außenansichten sind. Speicherung solcher Außenansichten spart teure Computerwissenschaft von ihnen jedes Mal, wenn sie erforderlich sind.

Datenbank und Datenbank wenden Erwiderung ein

:See auch Erwiderung unter

Gelegentlich verwendet eine Datenbank Lagerungsüberfülle durch die Datenbankgegenstand-Erwiderung (mit einer oder mehr Kopien), um Datenverfügbarkeit zu vergrößern (sowohl um Leistung von gleichzeitigen vielfachen Endbenutzer-Zugängen zu demselben Datenbankgegenstand zu verbessern, als auch Elastizität in einem Fall des teilweisen Misserfolgs einer verteilten Datenbank zur Verfügung zu stellen). Aktualisierungen eines wiederholten Gegenstands müssen über die Gegenstand-Kopien synchronisiert werden. In vielen Fällen wird die komplette Datenbank wiederholt.

Datenbanktransaktionen

Als mit jedem Softwaresystem ist ein DBMS, der in einer fehlerhaften Rechenumgebung funktioniert, für Misserfolge von vielen Arten anfällig. Ein Misserfolg kann die jeweilige Datenbank verderben, wenn spezielle Maßnahmen nicht ergriffen werden, um das zu verhindern. Ein DBMS erreicht bestimmte Niveaus der Schuld-Toleranz, indem er Operationen innerhalb von Transaktionen kurz zusammengefasst wird. Das Konzept einer Datenbanktransaktion (oder Atomtransaktion) hat sich entwickelt, um beiden ein gut verstandenes Datenbanksystemverhalten in einer fehlerhaften Umgebung zu ermöglichen, wo Unfälle jede Zeit und Wiederherstellung von einem Unfall bis einen gut verstandenen Datenbankstaat zufällig können. Eine Datenbanktransaktion ist eine Einheit der Arbeit, normalerweise mehrere Operationen über eine Datenbank (z.B kurz zusammenfassend, einen Datenbankgegenstand, das Schreiben, Erwerben des Schlosses, usw. lesend) Eine Abstraktion, die in der Datenbank und auch den anderen Systemen unterstützt ist. Jede Transaktion hat Grenzen gut definiert, in Bezug auf die Ausführungen des Programms/Codes in diese Transaktion (bestimmt vom Programmierer der Transaktion über spezielle Transaktionsbefehle) eingeschlossen werden.

SAURE Regeln

Jede Datenbanktransaktion folgt den folgenden Regeln:

• Atomicity - Entweder die Effekten von allen oder bleibt keine seiner Operationen ("alle oder nichts" Semantik), wenn eine Transaktion (begangen oder abgebrochen beziehungsweise) vollendet wird. Mit anderen Worten zur Außenwelt scheint eine begangene Transaktion (durch seine Effekten auf die Datenbank), unteilbar, atomar zu sein, und eine abgebrochene Transaktion verlässt Effekten auf die Datenbank überhaupt nicht, als ob nie bestanden hat.
• Konsistenz - Jede Transaktion muss die Datenbank in einem konsequenten (richtigen) Staat verlassen, d. h., die vorher bestimmten Integritätsregeln der Datenbank (Einschränkungen auf und unter den Gegenständen der Datenbank) aufrechterhalten. Eine Transaktion muss eine Datenbank von einem konsequentem Staat bis einen anderen konsequenten Staat umgestalten (jedoch, es ist die Verantwortung des Programmierers der Transaktion sicherzustellen, dass die Transaktion selbst richtig ist, d. h., richtig durchführt, was es vorhat durchzuführen (aus dem Gesichtspunkt der Anwendung), während die vorherbestimmten Integritätsregeln durch den DBMS beachtet werden). So, da eine Datenbank normalerweise nur durch Transaktionen geändert werden kann, entsprechen Staaten ganzen Datenbank. Eine abgebrochene Transaktion ändert den Datenbankstaat nicht, von dem sie angefangen hat, als ob sie nie (atomicity oben) bestanden hat.
• Isolierung - Transaktionen können einander (als ein Endergebnis ihrer Ausführungen) nicht stören. Außerdem, gewöhnlich (je nachdem Parallelitätskontrollmethode) die Effekten einer unvollständigen Transaktion sind zu einer anderen Transaktion nicht sogar sichtbar. Versorgung der Isolierung ist die Hauptabsicht der Parallelitätskontrolle.
• Beständigkeit - Effekten von erfolgreichen (begangenen) Transaktionen müssen durch Unfälle (normalerweise durch die Aufnahme der Effekten der Transaktion und seines andauern, Ereignis in einem nichtflüchtigen Speicher begangen).

Isolierung, Parallelitätskontrolle und Blockierung

Isolierung stellt die Fähigkeit zu vielfachen Benutzern zur Verfügung, auf der Datenbank zur gleichen Zeit zu funktionieren, ohne die Daten zu verderben.

• Parallelitätskontrolle umfasst die zu Grunde liegenden Mechanismen in einem DBMS, die Isolierung behandeln und verwandte Genauigkeit versichern. Es wird durch die Datenbank- und Lagerungsmotoren schwer verwertet (sieh oben), sowohl die richtige Ausführung von gleichzeitigen Transaktionen, als auch (verschiedene Mechanismen) die Genauigkeit anderer DBMS-Prozesse zu versichern. Die Transaktionszusammenhängenden Mechanismen beschränken normalerweise das Datenbankdatenzugriffsoperationstiming (Transaktionslisten) zu bestimmten als die Termineigenschaften von Serializability und Recoverabiliry charakterisierten Ordnungen. Das Begrenzen der Datenbankzugriffsoperationsausführung bedeutet normalerweise reduzierte Leistung (Raten der Ausführung), und so werden Parallelitätskontrollmechanismen normalerweise entworfen, um die beste unter den Einschränkungen mögliche Leistung zur Verfügung zu stellen. Häufig, wenn möglich, ohne Genauigkeit zu schaden, wird das serializability Eigentum für die bessere Leistung in Verlegenheit gebracht. Jedoch kann Werthaltigkeit nicht in Verlegenheit gebracht werden, seit solchem läuft normalerweise auf eine schnelle Datenbankintegritätsübertretung hinaus.
• Blockierung ist die allgemeinste Transaktionsparallelitätskontrollmethode in DBMSs, verwendet, um sowohl serializability als auch Werthaltigkeit für die Genauigkeit zur Verfügung zu stellen. Um auf einen Datenbankgegenstand zuzugreifen, dass eine Transaktion zuerst ein Schloss für diesen Gegenstand erwerben muss. Je nachdem der Zugriffsoperationstyp (z.B, lesend oder einen Gegenstand schreibend) und auf dem Schloss-Typ, das Schloss erwerbend, blockiert und verschoben werden kann, wenn eine andere Transaktion ein Schloss für diesen Gegenstand hält.

Anfragenoptimierung

Eine Abfrage ist eine Bitte um die Information von einer Datenbank. Es kann so einfach sein wie "Entdeckung der Adresse einer Person mit SS# 123-123-1234," oder komplizierter wie "Entdeckung des durchschnittlichen Gehaltes aller angestellten verheirateten Männer in Kalifornien zwischen den Altern 30 bis 39, die weniger verdienen als ihre Frauen." Anfragenergebnisse werden durch das Zugreifen auf relevante Datenbankdaten und die Manipulierung davon in einem Weg erzeugt, der die gebetene Information nachgibt. Da Datenbankstrukturen, in den meisten Fällen, und besonders für nicht sehr einfache Abfragen kompliziert sind, können die erforderlichen Daten für eine Abfrage von einer Datenbank durch das Zugreifen darauf unterschiedlich, durch verschiedene Datenstrukturen, und in verschiedenen Ordnungen gesammelt werden. Jeder verschiedene Weg verlangt normalerweise verschiedene Verarbeitungszeit. Verarbeitungszeiten derselben Abfrage können große Abweichung von einem Bruchteil einer Sekunde zu Stunden haben, je nachdem der Weg ausgewählt hat. Der Zweck der Anfragenoptimierung, die ein automatisierter Prozess ist, soll die Weise finden, eine gegebene Abfrage in der minimalen Zeit zu bearbeiten. Die große mögliche Abweichung rechtfertigt rechtzeitig leistende Anfragenoptimierung, obwohl, die genaue optimale Weise findend, eine Abfrage unter allen Möglichkeiten durchzuführen, ist normalerweise sehr kompliziert, allein zeitaufwendig, kann zu kostspielig, und häufig praktisch unmöglich sein. So versucht Anfragenoptimierung normalerweise, dem Optimum durch das Vergleichen mehrerer Alternativen des gesunden Menschenverstands näher zu kommen, um in einer angemessenen Frist einen "genug guten" Plan zur Verfügung zu stellen, der normalerweise viel vom bestmöglichen Ergebnis nicht abgeht.

DBMS unterstützen für die Entwicklung und Wartung einer Datenbank und seiner Anwendung

Ein DBMS hat normalerweise vor, günstige Umgebung zur Verfügung zu stellen, um sich zu entwickeln und später eine um seinen jeweiligen Datenbanktyp gebaute Anwendung aufrechtzuerhalten. Ein DBMS entweder stellt solche Werkzeuge zur Verfügung, oder erlaubt Integration mit solchen Außenwerkzeugen. Beispiele für Werkzeuge beziehen sich auf Datenbankdesign, Anwendungsprogrammierung, Anwendungsprogramm-Wartung, Datenbankleistungsanalyse und Überwachung, Datenbankkonfigurationsüberwachung, DBMS Hardware-Konfiguration (ein DBMS, und verwandte Datenbank kann Computer, Netze und Lagerungseinheiten abmessen), und verwandte Datenbank kartografisch darstellend (besonders für einen verteilten DBMS), Lagerungszuteilung und Datenbanklay-Out-Überwachung, Lagerungswanderung, usw.

Siehe auch

• Vergleich von Verwandtschaftsdatenbankverwaltungssystemen
• Vergleich von Datenbankwerkzeugen
• Datenhierarchie
• Daten versorgen
• Datenbankzentrische Architektur
• Datenbank, die prüft
• Glasdatenbank, eine Sammlung von Glaszusammensetzungen und verwandten Eigenschaften

Weiterführende Literatur

• Ling Liu und Mehr gezähmte M. Özsu (Hrsg.). (2009). "Enzyklopädie von Datenbanksystemen, 4100 p. 60 illus. Internationale Standardbuchnummer 978-0-387-49616-0. Tisch des Inhalts, der an http://refworks.springer.com/mrw/index.php?id=1217 verfügbar

• Beynon-Davies, P. (2004). Datenbanksysteme. 3. Ausgabe. Palgrave, Houndmills, Basingstoke.
• Connolly, Thomas und Carolyn Begg. Datenbanksysteme. New York: Harlow, 2002.
• Grau, J. und Reuter, A. Transaktionsverarbeitung: Konzepte und Techniken, 1. Ausgabe, Herausgeber von Morgan Kaufmann, 1992.
• Kroenke, David M. und David J. Auer. Datenbankkonzepte. 3. Hrsg. New York: Prentice, 2007.
• Teorey, T.; Lightstone, S. und Nadeau, T. Das Datenbankmodellieren & Design: Logisches Design, 4. Ausgabe, Presse von Morgan Kaufmann, 2005. Internationale Standardbuchnummer 0-12-685352-5

Links