imported>1234qwer1234qwer4: Kommaregeln der deutschen Sprache#Infinitivgruppe (via JWB)

2026-03-06T21:16:28Z

Kommaregeln der deutschen Sprache#Infinitivgruppe (via JWB)

Neue Seite

'''Relationale-Datenbank-Muster''' sind [[Muster]], die im Entwurf [[Relationale Datenbank|relationaler Datenbanken]] eingesetzt werden.

== Grundlegende Tabellentypen ==
; Referenztabelle
: Eine Referenztabelle ist eine Tabelle, die über die Zeit relativ konstant bleibt und relativ wenige Spalten aufweist. Häufig anzutreffen sind dabei Key-Value-Referenztabellen mit nur zwei Spalten. Als Schlüssel sollten hierbei Zeichenfolgen verwendet werden, um [[Relationale Algebra#Join|Joins]] zu vermeiden.<ref name="keys">{{Internetquelle |url=http://database-programmer.blogspot.co.at/2008/01/database-skills-sane-approach-to.html |titel=Database Skills: A Sane Approach To Choosing Primary Keys |datum=2008-01-14 |werk=The Database Programmer |zugriff=2013-03-06 |sprache=en}}</ref>
; Mastertabelle
: Eine Mastertabelle ist eine Tabelle, welche die Eigenschaften eines Objektes (Person, Adresse etc.) in getrennten Spalten ablegt. Kleine Mastertabellen sollten hierbei mit einer eindeutigen [[Zeichenfolge]]; bei großen Mastertabellen und Mastertabellen, deren Inhalt sich oft ändert, sollte eine [[Integer (Datentyp)|Ganzzahl]] als Schlüssel angelegt werden.<ref name="keys" />
; Transaktionstabelle
: Eine Transaktionstabelle ist eine Tabelle die Interaktionen oder Ereignisse zwischen Mastertabellen speichert. Beispielsweise eine Liste von Objekten, die ein Kunde in einen Warenkorb gelegt hat. Als Schlüssel sollten automatisch generierte Ganzzahlen verwendet werden.<ref name="keys" />
; Querverweistabelle
: Eine Querverweistabelle ist eine Tabelle in der die Beziehungen zwischen Mastertabellen gespeichert werden. In Querverweistabellen werden n:n-Beziehungen in mehreren Zeilen abgebildet. Als Schlüssel sollte eine Kombination aus mehreren Spalten gewählt werden.<ref name="keys" />

== Erweiterte Tabellentypen ==
; Begrenzte Transaktion
: Als begrenzte Transaktion bezeichnet man eine Einschränkung auf einer Tabelle, die definiert welche Transaktionen wann zulässig sind. Dieses Muster kann eingesetzt werden um entsprechende Prüfungen auf der Anwendungsseite zu reduzieren und um die Sicherheit der Datenbank vor falsch implementierten Anwendungen zu erhöhen.<ref>{{Internetquelle |url=http://database-programmer.blogspot.co.at/2008/01/table-design-pattern-limited.html |titel=Table Design Pattern: Limited Transaction |sprache=en |datum=2008-02-27 |zugriff=2013-03-06 |werk=The Database Programmer}}</ref>
; Vergänglicher Primärschlüssel
: werden eingesetzt, wenn sich eine Eigenschaft eines Objektes als Primärschlüssel anbietet (z. B. eine [[Kundennummer]]), diese sich jedoch möglicherweise ändert. In diesem Fall kann die entsprechende Eigenschaft zwar als Primärschlüssel verwendet werden, Änderungen müssen jedoch in einer [[#History-Tabelle|History-Tabelle]] protokolliert werden um auch eine nachträgliche Zuordnung gewährleisten zu können.<ref>{{Internetquelle |url=http://database-programmer.blogspot.co.at/2008/02/primary-key-that-wasnt.html |titel=The Primary Key That Wasn’t |sprache=en |datum=2008-02-24 |zugriff=2013-03-06 |werk=The Database Programmer}}</ref>

== Muster für Fremdschlüssel ==
; Fremdschlüsselbegrenzung
: bezeichnet es, wenn das Löschen eines Eintrags (Zeile) aus einer Tabelle die mit dem Eintrag verknüpften Einträge (in einer anderen Tabelle) nicht mit löscht. Die Fremdschlüsselbegrenzung ist somit das Gegenteil der [[#Fremdschlüsselkaskade|Fremdschlüsselkaskade]].
: In [[SQL]] wird eine Fremdschlüsselbegrenzung mit dem Befehl <syntaxhighlight lang="SQL" inline>DELETE RESTRICT</syntaxhighlight> angestoßen. Dieses Verhalten ist bei den meisten Datenbankimplementierungen das Standardverhalten, wenn nur der Befehl <syntaxhighlight lang="SQL" inline>DELETE</syntaxhighlight> alleine angegeben wird.<ref name="fkey">{{Internetquelle |url=http://database-programmer.blogspot.co.at/2008/07/different-foreign-keys-for-different.html |titel=Different Foreign Keys for Different Tables |sprache=en |werk=The Database Programmer |datum=2008-07-27 |zugriff=2013-03-06}}</ref>
; Fremdschlüsselkaskade
: Eine '''Fremdschlüsselkaskade''' ist das Gegenteil der [[#Fremdschlüsselbegrenzung|Fremdschlüsselbegrenzung]]. Beim Löschen eines Eintrags werden die mit dem Eintrag verknüpften Einträge mitgelöscht.
: In SQL wird eine Fremdschlüsselbegrenzung mit dem Befehl <syntaxhighlight lang="SQL" inline>DELETE CASCADE</syntaxhighlight> angestoßen.<ref name="fkey" />
; Querverweisvalidierung
: Eine Querverweisvalidierung wird eingesetzt, wenn Spalten in einer Mastertabelle eine bestimmte [[Relation (Datenbank)|Relation]] miteinander aufweisen müssen. Diese Relation wird in einer getrennten Querverweistabelle gespeichert. Durch die getrennte Querverweistabelle wird zwar der Ressourcenverbrauch der Datenbank erhöht, der Einsatz ist jedoch nötig, um die Gültigkeit der Daten prüfen zu können.<ref>{{Internetquelle |url=http://database-programmer.blogspot.co.at/2008/01/table-design-patterns-cross-reference.html |titel=Table Design Patterns: Cross-Reference Validation |sprache=en |werk=The Database Programmer |datum=2008-01-20 |zugriff=2013-03-06}}</ref>

== Sicherheitsmuster ==
; Schreibgeschützte Lookup-Tabelle
: Eine '''schreibgeschützte Lookup-Tabelle''' ist eine Tabelle die eine Zuordnung zwischen zwei Tabellen definiert, deren Inhalt zwar allgemein abgefragt werden kann, jedoch nur von bestimmten Rollen bzw. Gruppen bearbeitet werden darf. Ein Beispiel ist die Verknüpfung von bestimmten Produkten mit einem [[Rabatt]].<ref>{{Internetquelle |url=http://database-programmer.blogspot.co.at/2008/05/introducing-database-security.html |titel=Introducing Database Security |werk=The Database Programmer |sprache=en |datum=2008-05-11 |zugriff=2013-03-07}}</ref>

== Denormalisierungsmuster ==
{{Hauptartikel|Normalisierung_(Datenbank)|Denormalisierung|titel1=Normalisierung}}
Denormalisierungsmuster ermöglichen die Denormalisierung einer Datenbank zum Zweck der Verbesserung des Laufzeitverhaltens.

; Fetching
: Beim Fetching werden Daten aus einer Tabelle in eine andere (temporäre) Tabelle (z. B. eine [[#Transaktionstabelle|Transaktionstabelle]]) kopiert. Hierbei ist darauf zu achten, dass eine Änderung in der Quelltabelle nicht automatisch in die Zieltabelle übernommen wird.
; Vorweggenommene Aggregation
: {{Hauptartikel|Denormalisierung#Vorweggenommene_Aggregation|titel1=Vorweggenommene Aggregation}}
: Bei der '''vorweggenommenen Aggregation''' werden Werte aus verschiedenen Quellen bereits im Voraus im Zuge einer (lang laufenden) [[Stapelverarbeitung]] berechnet und in einer weiteren Tabelle zwischengespeichert. Die Werte werden dabei nicht bei jeder Abfrage neu berechnet, sondern erst im Zuge der nächsten Stapelverarbeitung. Der Vorteil ist, dass der Zugriff deutlich schneller ist und die Ressourcen der Datenbank geschont werden. Nachteilig wirkt sich aus, dass vor kurzem getätigte Änderungen an in der Berechnung nicht berücksichtigt sind.
; Erweiterung
: Eine Erweiterung der Tabelle liegt dann vor, wenn eine Spalte in der Tabelle durch die Berechnung aus anderen Spalten gebildet wird. Hierdurch muss die Berechnung nicht bei jeder Abfrage erneut durchgeführt werden, sondern erst wenn sich der Eintrag ändert.

== Objekt-Relationale Verhaltensmuster ==
{{Hauptartikel|Objektrelationale Abbildung}}
; Tabelle pro Vererbungshierarchie
: (englisch: ''Single Table Inheritance'') verwendet eine einzige Tabelle für jede Klasse, um einen Klassenbaum in einer Datenbank abzubilden.<ref name="PoEAA" />
; Tabelle pro Unterklasse
: (englisch: ''Class Table Inheritance'') verwendet eine eigene Tabelle für jede konkrete oder abstrakte Klasse, um einen Klassenbaum in einer Datenbank abzubilden.<ref name="PoEAA" />
; Tabelle pro konkrete Klasse
: (englisch: ''Concrete Table Inheritance'') verwendet eine eigene Tabelle für jede konkrete Klasse, um einen Klassenbaum in einer Datenbank abzubilden.<ref name="PoEAA" />

<gallery>
Single Table Inheritance.svg|Tabelle pro Vererbungshierarchie
Class Table Inheritance.svg|Tabelle pro Unterklasse
Concrete Table Inheritance.svg|Tabelle pro konkrete Klasse
</gallery>

''siehe auch:'' [[Relationale-Datenbank-Muster]], [[Entwurfsmuster]]

== Verteilungsmuster ==
Bei den Verteilungsmustern wird im Wesentlichen zwischen [[#Single-Server|keiner Verteilung]], Replikation und [[#Fragmentierung|Fragmentierung]] (englisch: ''Sharding'') unterschieden:
* Die Replikation nimmt dieselben Teile der Daten und kopiert diese auf mehrere Server, um eine höhere Ausfallsicherheit zu gewährleisten.
* Die Fragmentierung verteilt unterschiedliche Teile der Daten und verteilt diese über mehrere Server, um eine bessere Lastenverteilung zu gewährleisten.
Die Replikation kann hierbei mit Fragmentierung kombiniert werden. Zudem unterscheidet man bei der Replikation zwischen der [[#Master/Slave-Replikation|Master/Slave-Replikation]] und der [[#Peer-to-Peer-Replikation|Peer-to-Peer-Replikation]].

{|
| [[Datei:Single-Server-Replikation.svg|mini|175px|Single-Server-„Verteilung“]]
| [[Datei:Fragmentierung.svg|mini|155px|Verteilung durch Fragmentierung]]
| [[Datei:Master-Slave-Replikation.svg|mini|257px|Verteilung mit Master/Slave-Replikation]]
| [[Datei:P2P-Replikation.svg|mini|272px|Verteilung mit Peer-to-Peer Replikation]]
|}

=== Single-Server ===
{{Hauptartikel|Datenbankserver}}
Das einfachste Verteilungsmuster ist keine Verteilung. Die Datenbank läuft vollständig auf einem einzelnen Server, der sämtliche Schreib- und Lesezugriffe behandelt. Der Vorteil dieses Musters ist es, dass der Server einfach zu warten ist. Updates, Datensicherungen, Reparaturen, Upgrades etc. lassen sich bei diesem Muster zentral behandeln.<ref name="NoSQL" />

Zudem müssen Softwareentwickler keine aufwändige Logik implementieren um Probleme mit der [[Konsistenz (Datenspeicherung)#Verteilte Systeme|Konsistenz]], [[Verfügbarkeit]] oder [[Partition (Datenbank)|Partitionierung]] zu behandeln (''siehe auch:'' [[CAP-Theorem]]).

Diese Variante bietet sich auch besonders bei [[Graphdatenbank]]en an, da Latenzen durch den Zugriff von Daten über das Netzwerk vermieden werden.

=== Fragmentierung ===
{{Hauptartikel|Denormalisierung#Fragmentierung|titel1=Fragmentierung}}
Bei der Fragmentierung (englisch: ''Sharding'') werden unterschiedliche Datenbanken bzw. voneinander unabhängige Teile der Datenbank auf verschiedene Server, die ''Shards'', verteilt.<ref name="NoSQL" />

Hierdurch ergibt sich eine bessere Lastverteilung. Zudem fallen bei einem Ausfall des Servers nicht alle Applikationen aus, sondern nur jene die auf die jeweiligen Daten zugreifen oder schreiben müssen.

Da die Lese-und-Schreibzugriffe für jeweils bestimmte Daten vom jeweiligen Shard alleine bearbeitet werden, ergibt sich keine Inkonsistenz der Daten.

=== Federation ===
Als Federation bezeichnet man einen Spezialfall der [[#Fragmentierung|Fragmentierung]], bei dem ein zentraler Server, ''federation root'' genannt, die Verteilung der einzelnen Shards automatisch bestimmt.

=== Master/Slave-Replikation ===
Bei der Master/Slave-Replikation übernimmt ein zentraler Server, der ''Master'', alle Schreibzugriffe auf die Datenbank. Anschließend werden die Änderungen auf die anderen Server, den ''Slaves'' (Sklaven) übermittelt. Wenn der Master-Server ausfallen sollte, kann ein Slave die Rolle des Masters übernehmen.<ref name="NoSQL" />

Da es etwas dauert, bis die Änderungen von den Slave-Servern übernommen werden, kann es kurzzeitig zu Dateninkonsistenzen kommen.

Alle Server ermöglichen Lesezugriffe, wodurch es bei Lesezugriffen zu einer Lastverteilung kommt. Da Schreibzugriffe jedoch zentral bearbeitet werden, stellt der Master einen Flaschenhals dar.

=== Peer-to-Peer-Replikation ===
Bei der Peer-to-Peer-Replikation, sind alle Server über ein [[Peer-to-Peer]]-Netzwerk verbunden. Jeder Server übernimmt sowohl Schreib- als auch Lesezugriffe. Schreibzugriffe werden hierbei mit allen Servern synchronisiert.<ref name="NoSQL" />

Da es jedoch einige Zeit dauert, bis die Schreibzugriffe synchronisiert werden, kann es bei diesem Modell zu Dateninkonsistenzen kommen. Dieser Effekt tritt hier besonders zutage, wenn die [[Netzwerkverbindung]] zwischen zwei Standorten ausfällt.

Der Vorteil dieser Konfiguration ist, dass eine besonders hohe Ausfallsicherheit gegeben ist. Der Wegfall einzelner Peers führt nicht zu einem Datenverlust. Zudem ist dieses Modell leicht horizontal skalierbar, da bei Engpässen einfach weitere (kostengünstige) Rechner hinzugefügt werden können.

Die Peer-to-Peer-Replikation ist in der Softwareentwicklung und der Wartung (Updates, Backups etc.) besonders aufwändig und bedarf daher einer guten Planung seitens des Betreibers.

=== Fragmentierung mit Master-Slave-Replikation ===
Die Fragmentierung und Master-Slave-Replikation kann auch kombiniert werden. Hierbei werden für jeden Datentyp ein Master bestimmt und auf mehrere andere Server, welche hierbei dem Master als Slaves dienen, repliziert. Ein Server kann hierbei die Rolle des Masters für einen Datentyp und die Rolle des Slave für andere Datentypen gleichzeitig übernehmen.<ref name="NoSQL" />

=== Fragmentierung mit Peer-to-Peer-Replikation ===
Als letzte Möglichkeit bietet sich noch die Fragmentierung eines Peer-to-Peer-Netzwerkes an. Hierbei werden mehrere Server zusammengefasst um sich als Peer-to-Peer-Netzwerk um einen bestimmten Datentyp zu kümmern. Jeder Server kann hierbei Teil von mehreren Peer-to-Peer-Netzwerken sein und somit unterschiedliche Datentypen behandeln.<ref name="NoSQL" />

== Weitere Muster ==
; Auflösungsmuster
: Das Auflösungsmuster wird eingesetzt, wenn ein Wert aus verschiedenen Quellen kommen bzw. berechnet werden kann und entschieden werden muss, welche Quelle gewählt wird bzw. welches Berechnungsmodell anzuwenden ist.<ref>{{Internetquelle |url=http://database-programmer.blogspot.co.at/2008/04/advanced-table-design-resolutions.html |titel=Advanced Table Design: Resolutions |werk=The Database Programmer |datum=2008-04-20 |zugriff=2013-03-07 |sprache=en}}</ref>
; History-Tabelle
: Eine History-Tabelle ist eine Tabelle die Änderungen protokolliert. Durch diese Tabelle sind Änderungen nachvollziehbar und der ursprüngliche Zustand der überwachten Tabelle wiederherstellbar.<ref>{{Internetquelle |url=http://database-programmer.blogspot.co.at/2008/07/history-tables.html |titel=History Tables |werk=The Database Programmer |datum=2008-07-20 |zugriff=2013-03-07 |sprache=en}}</ref> Ein Beispiel für eine History-Tabelle ist die „Versionsgeschichte“ der [[Wikipedia]], in der Änderungen in Form von [[Diff]]-Elementen gespeichert werden.
: ''siehe auch:'' [[Versionsverwaltung]]
; Abhängigkeitsseqenzierung
: Bei einer Abhängigkeitsseqenzierung muss eine Reihe von Befehlen in einer Sequenz abgearbeitet werden. Da einige Befehle vom Ergebnis anderer Befehle abhängig sein können, muss die korrekte Reihenfolge mit Hilfe eines [[Gerichteter Analysegraph|gerichteten Analysegraphen]] (englisch: ''directed analytic graph'') ermittelt und in einer eigenen Tabelle abgebildet werden.<ref>{{Internetquelle |url=http://database-programmer.blogspot.co.at/2008/08/advanced-algorithm-sequencing.html |titel=Advanced Algorithm: Sequencing Dependencies |werk=The Database Programmer |datum=2008-08-25 |zugriff=2013-03-07 |sprache=en}}</ref>
; Sicheres Passwortrücksetzen
: Die Datenbank muss ein sicheres Zurücksetzen des [[Passwort]]es erlauben, falls der Benutzer das Passwort vergessen hat. Das Passwort darf weder im Klartext oder wiederherstellbar in der Datenbank gespeichert werden, noch darf das Passwort des Benutzers über einen unsicheren Kanal (z. B. etwa in einer [[E-Mail]] oder eine nicht mit [[Transport Layer Security|SSL]] verschlüsselte [[Webseite]]) übermittelt werden.<ref>{{Internetquelle |url=http://database-programmer.blogspot.co.at/2008/09/advanced-table-design-secure-password.html |titel=Advanced Table Design: Secure Password Resets |werk=The Database Programmer |datum=2008-11-07 |zugriff=2013-03-07 |sprache=en}}</ref>

== Antimuster ==
{{Hauptartikel|Anti-Pattern}}
; Umgekehrter Fremdschlüssel
Ein umgekehrter Fremdschlüssel ({{enS|reverse foreign key}}) entsteht, wenn ein bestimmter Eintrag einer Tabelle einen bestimmten Eintrag in einer anderen Tabelle verhindern soll. Ein '''Umgekehrter Fremdschlüssel''' sieht auf den ersten Blick oft wie ein [[Primärschlüssel]] aus.<ref>{{Internetquelle |url=http://database-programmer.blogspot.co.at/2008/02/false-patterns-such-as-reverse-foreign.html |titel=False Patterns Such as The Reverse Foreign Key |sprache=en |werk=The Database Programmer |datum=2008-02-03 |zugriff=2013-03-07}}</ref>

== Literatur ==
* {{Literatur
|Autor=Scott J. Ambler, Pramodkumar J. Sadalage
|Titel=Refactoring Databases: Evolutionary Database Design
|Verlag=[[Prentice Hall]], [[Addison-Wesley]]
|Ort=
|Datum=2011
|ISBN=978-0-321-77451-4
|Seiten=384
|Sprache=en}}
* {{Literatur
|Autor=Scott J. Ambler
|Titel=Agile Database Techniques
|Verlag=[[John Wiley & Sons]]
|Ort=
|Datum=2003
|ISBN=978-0-471-20283-7
|Seiten=480
|Sprache=en}}
* {{Literatur
|Autor=Len Silverston
|Titel=The Data Model Resource Book: Volume 1: A Library of Universal Data Models for All Enterprises
|Verlag=John Wiley & Sons
|Ort=
|Datum=2001
|ISBN=978-0-471-38023-8
|Seiten=560
|Sprache=en}}
* {{Literatur
|Autor=Len Silverston
|Titel=The Data Model Resource Book: Volume 2: A Library of Universal Data Models by Industry Types
|Verlag=John Wiley & Sons
|Ort=
|Datum=2001
|ISBN=978-0-471-35348-5
|Seiten=576
|Sprache=en}}
* {{Literatur
|Autor=Len Silverston, Paul Agnew
|Titel=The Data Model Resource Book: Volume 3: Universal Patterns for Data Modeling
|Verlag=John Wiley & Sons
|Ort=
|Datum=2009
|ISBN=978-0-470-17845-4
|Seiten=648
|Sprache=en}}

== Weblinks ==
* {{Internetquelle
|url=http://www.codeproject.com/Articles/359654/11-important-database-designing-rules-which-I-foll
|titel=11 important database designing rules which I follow
|sprache=en
|werk=[[The Code Project]]
|autor=Shivprasad Koirala
|datum=2012-09-07
|zugriff=2013-03-07}}

== Einzelnachweise ==
<references>
<ref name="PoEAA">
{{Literatur
|Autor=Martin Fowler
|Titel=Patterns of Enterprise Application Architecture
|Verlag=Addison-Wesley-Longman
|Ort=Amsterdam
|Datum=2002
|ISBN=0-321-12742-0}}
</ref>
<ref name="NoSQL">
{{Literatur
|Autor=Pramodkumar J. Sadalage, [[Martin Fowler]]
|Titel=NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence
|Verlag=Addison-Wesley
|Ort=Amsterdam
|Datum=2012
|ISBN=978-0-321-82662-6
|Sprache=en}}
</ref>
</references>

[[Kategorie:Softwarearchitektur]]
[[Kategorie:Datenbanken]]

Datenbank-Muster - Versionsgeschichte

imported>1234qwer1234qwer4: Kommaregeln der deutschen Sprache#Infinitivgruppe (via JWB)