<sub class="descriptionSection">09-11-2024 05:53:pm // #Tag // [[Databases]]</sub> ____ ## Motivation eines DBS ### Aus Sicht des Betriebssystems - Daten werden nicht verschachtelt abgelegt und können Filesystem overhead umgehen => Effizienzsteigerung ### Aus Sicht der Anwendungsentwicklung - Daten werden Dateisystem unabhängig abgelegt => Flexible Datenstruktur - Alrogirthmen zum Suchen, Sortieren und Filtern müssen nicht vom Betriebssystem gestellt werden (Diese variieren auch von System zu System) => Unabhängige Daten - Ad-Hoc Abfragen sind möglich, es muss kein weiterer Programmieraufwand für sie betrieben werden - Anwendung kann datenunabhängig aufgebaut werden, da sie nicht von einer Datenstruktur gebunden ist - DBS eliminieren das requirement von Dateninseln => Es ist leichter Redundante Daten zu vermeiden (Weniger Anomalien) - Gleichzeitiger Zugriff ist leicht (keine lockfiles, etc.) - Zentrale Auswertung ist leicht (ein SQL Statement) ### Aus Sicht des Datenschutzes - Viele Möglichkeiten der Access Control - Löschen der Daten ist leicht ## Integrierte Informationsverarbeitung Ziel der Integrierten Informationsverarbeitung ist es, die verarbeitung und Speicherung der Daten so einfach wie möglich zu machen. Sie besteht aus den Bestandteilen Datenintegration und Vorgangsintegration. - Ziel der Datenintegration: Einheitliche Datenbasis schaffen die von allen Prozessen eines Betriebes verwendet wird - Die Logik der Geschäftsprozesse wird in Betrieblichen Anwendungen umgesetzt, die dann auf diese Datenebasis Zugreifen ## DBS Besteht aus: - Einer oder mehreren Datenbanken. (DBs enhalten logisch zusammengehörige Daten eines Sachgebiets) - Dem DBMS was die DBs managed und die Schnittstelle zwsichen Nutzer Apps und Daten darstellt ### DBMS Ist die Software die Datenbanken verwaltet. Zu den Aufgaben gehören: - Anlegen und Löschen von Datenbanken - Speicherung, Änderung und das Löschen von Daten - Abfragen und Auswerten von Daten aus den Datenbanken - Verwaltung von Benutzern und deren Zugriffsrechten Kommunikation zwsichen DBMS und Apps erfolgt über SQL Es Arbeitet nach diesem Schema: ![[Pasted image 20241110120853.png]] Eine Abfrage läuft so: 1. Eine Anwendung stellt einen Request an das DBMS 2. Das DBMS sucht im Externen Schema nach Usern, etc. Validiert quasi die Anfrage und ob die App berechtigt ist zu zu greifen 3. Das DBMS sucht dann im Konzeptionellen Schema nach den logischen Zusammenhängen der Daten + ob sie überhaupt gespeichert wurden. Hier wird das SQL validiert 4. Dann holt es vom internem Schema die **location** der Daten auf der Platte 5. Dann frägt das DBMS vom Betriebssystem an, das die Daten in den RAM geladen werden 6. Das OS sucht dann in den Speicherorten und tut sie in den Systempuffer (RAM) 7. Das DBMS bekommt sobald das fertig ist einen Interrupt und übergibt die Daten aus dem Systempuffer der Anwendung ## Arten von DBS - Relational DBS - Am weitesten verbreitete Art - Speichert Daten in Tabellen welche Relationen zueinander haben können - No-SQL DBS - Speichert Daten in nicht-relationalen tabellen - Graph DBS - Speichert Daten in Knoten ab, die dann verschiedene Beziehungen zusammen haben können über Edges - Key-Value DBS - Speichert Daten sehr einfach, mit nur einem Key ab der dann values haben kann (JSON basically) - Document Store - Kann alle möglichen Daten unstrukturiert abspeichern und dann wiedergeben. - Z.B kann Photos, XML und JSON in der selben Tabelle speichern ## ANSI-Sparc Ansi-Sparc ist ein Modell nach dem DBS Systeme aufgebaut werden. Es hat diese Ebenen: - Externe Ebene, ermöglicht Usern + Anwendern - Konzeptionelle Ebene: Beschreibt beziehungen und welche Daten wie gespeichert werden + Metadaten - Interne Ebene: Lässt DBMS physisch Daten abspeichern ### Vorteile ANSI-Sparc Das Ansi Sparc Modell ist äußert resilent und stabil, da: - physische Änderungen am speichermedium nichts an den höheren Ebenen ändern - Die Konzeptionelle Ebene getrennt ist, und somit bei änderungen an einer Application oder Datenformat, nicht alle anderen auch geändert werden müssen ## Datenanomalien Es gibt drei Datenanomalien: - Änderungs-Anomalie: - Tritt auf wenn dieselben Daten, redundant an unterschiedlichen Stellen gespeichert werden und bei einer Änderung nicht alle geupdated werden - Einfüg-Anomalie - Tritt auf, wenn Daten eingeben werden müssen aber nicht bekannt sind - Lösch Anomalie - Tritt auf wenn man alle Daten in einem Datensatz löscht, aber dadurch auch andere Daten gelöscht werden, was dann aber nicht gewollt war ### Datenredundanz Datenredundanz ist das vermeidbare mehrmalige abspeichern von Daten / Datensätzen in einer Datenbank. ## Entities in Relationeln DBS Entitäten sind einheitliche Daten die immer gleich sind und zusammen gespeichert werden. Diese können dann relations zu anderen Entitäten haben. Jede Entität **muss immer** alle definierten Entitätsattribute haben ### Entitätsattribute Sind eigenschaften (also Daten) einer Entität ### Entitätsmengen Eine Entitätsmenge ist die Summe aller entitäten von einem Typ. Entitätsmengen werden oft in einer Tabelle zusammen gefasst. ### Entitätsbeziehungen Entitätsmengen können beziehungen zu anderen Entitätsmengen haben. Es gibt 3 Verschiedene Arten von Beziehungen: - 1 zu 1 Beziehungen: - Jeder Entität in der Menge kann nur **eine** andere Entität in der anderen Menge zugeordnet werden - 1 zu n Beziehungen: - Jeder Entität in der ersten Menge können unendlich viele (oder null) entitäten zugewiesen werden. - n zu m Beziehungen: - Jeder Entität in der ersten Menge können n andere entitäten zugewiesen werden, welche dann auch n beziehungen in die erste Menge haben können Siehe auch [[Spezielle Assoziationen]] ## DBs / DBMS Datenbanken können verschieden Architekturen annehmen. Aus der Ansi-Sparc Architektur ergeben sich verschiedene Möglichkeiten für den Aufbau eines DBS (abhängig von Netzwerk-Struktur, Leistung des Netzwerks, Reliability Anforderungen etc) ### Zentralisiertes DBS Ein Zentralisiertes DBS hat einen Mainframe, auf dem **eine** Anwendung läuft. Auf diesen Mainframe greifen dann alle Clients zu: ![[Pasted image 20241008081923.png]] #### Vorteile - Hoch Zentralisiert => Besser Wartbar - Einfache Verwaltung #### Nachteile - Mainframe teuer => Hohe Kosten - Niedrige Ausfallsicherheit - Hohe Netzwerkanforderungen unter Stoßzeiten ### Verteiltes DBS Wird eingesetzt, wenn man riesen große Datenmengen hat und ein Server diese nicht mehr verarbeiten kann. Kann auch Ausfallsicherheit stärken und netzwerkauslastung verringern. Verteiltes DBS meint einfach nur den logischen zusammenschluss von Teil-Datenbanken (oder vollen Datenbanken) die entwerder ein einem Datacenter stehen oder in verschiedene Länder / Städte verteilt sind: ![[Pasted image 20241008082344.png]] #### Vorteile - Entlastet Netzwerk (in bestimmten bedingungen) - Hohe Fehlerresistenz #### Nachteile - Hohe Komplexität - Hohe Kosten - Nur Schwere Sicherung möglich - Unvorhersehbare Abfrage Zeiten (wenn Daten in anderem DBS verteilt sind) - Kann zu komischen Anomalien führen wenn Knoten ausfällt ### Client-Server Architektur Ist heutzutage der de-facto standard und auch am einfachsten zu managen. Hier hat man einen Server der immer Bereit ist die Daten zu liefern und der client kann dann on-demand abfragen - Client und Server können auf gleichem rechner sein - Client und Server können auch im Netzwerk Verteilt sein ![[Pasted image 20241008083149.png]] #### Vorteile - Weit genutzt - Viel Doku verfügbar - Viele Profis die sich damit auskennen - Niedrige Kosten beim richtigem aufsetzen - Wenig unbekannte Anomalien - Viel Auswahlmöglichkeiten #### Nachteile - Für sehr bestimmte use cases nicht ausreichend - Kann unzureichend sein für große systeme (Scaling ist schwer bei manchen DBS, z.B Postgresql) ## ER-Diagramme Ein Entity Relationship Diagramm (ER-Diagramm) stellt die Zusammenhänge zwischen Entitätsmengen und deren Attributen graphisch dar: ![[Pasted image 20241014092127.png]] Im Diagramm werden außerdem die Beziehungseigenschaften (1zu1, etc) festgelegt.