Datenwanksysteme: Logical Database Modelling

Logical Database

Wir haben únsere requirements
Wir wollen jetzt eine krasse Datenbank aufsetzen und dann auch noch ne krassere datenbank bauen

Key-Value
- naja halt das klassische key-value ding,
- jedes ding hat nen key, und dann kann man das so anordnen , keys nicht doppelt etc.
- Keine query sprachen (lol)
Document-Oriented-Data-Model
- Key-Value paare, wenn die daten semi-strukturiert sind
- Dokumente haben verschiedene Strukturen und sind sog. schemata
- Wir spezialisieren das key-value kram auf das "nötigste" damit man schneller suchen kann
- du kannst aber auch die dokumente durchsuchen, wenn man denn weiss wonach man sucht
- Diese art von datenbanken unterstützt normalerweise auch sowas wie collections etc.
- Viele unterstützen dann auch replikation und sharding, was sinnvoll für clustering ist
Graph Data Model
- Wir modellerien Daten die zusammenhängen
- Entities werden als knoten dargestellt und die verbindungen sind dann halt die kanten
- Es gibt zwie große datenmodelle
  - Ressource Description Framework (RDF)
  - Property Graph (Graph Databases) (Naja, graphendatenbanken / request formate wie sowas wie GraphQL)

Eine Relation ist ein Mathematisches konzept die an die "Gruppentheorie" anhängt
Das modell wurde von irgendwem bei IBM in den 70ern erfunden

Structure	Description
Relation Shema	Sieht so aus wie die Tabellennamen etc.
Attribute	Halt der Name der einzelnen spalten
Relation or Tuple	Ist verbunden mit einer Zeile im table \
Jede Relation repräsentiert fakten die mit einer "echten" entity oder beziehung zusammenhängen
Relation Key	Attribut oder Menge an attribute die die daten in der Zeile identifizieren
Relation State	Eine gewisse menge von Zeilen in der Tabelle

Ein relationsschema bezieht sich auf die Beschreibung der Daten gezeigt durch $R (A_{1}, A_{2}, ..., A_{n})$
Ein schema besteht aus teilen:
- Name der Relation, oder auch $R$
- Eine Menge an Attributen (oder eigenschaften) der Relation, auch $A_{n}$
Jedes Attribut $A_{i}$ hat eine Domain $D_{i}$ oder eine Liste an richtigen werten, auch als $A_{i}$ bekannt
- Der name des Attributes zeigt welche rolle es in der Domain spiel t
- Die Domain insgesamt ist eine Ansammlung an atomic (oder auch global unsichtbaren) daten
- Um die Domain anzugeben, können wir verschiedene datentypen bzw. werte nutzen
Der Grad bzw. die Arity von einem Relationsschema wird von der anzahll seiner attribute vorausgesetzt

Naja wenn wir uns das dann anschauen könnenwir sehen, dass uns das sehr an OOM sachen erinnert
Denn wir haben auf jeden fall die Strukturen von Klassen
§%15%§

Eine Relation $r$ von einem Relationsschema $r (R)$ ist eine Menge an $n$ -tuplen $r = (t_{1}, ..., t_{m})$
- Sprich wir können daten nur innerhalb dieeser Reichweite haben, und ausserhalb ist dann narnia
Jeder der $n$ -tupel ist eine geordnete liste von werten bei dennen halt jedes element ein teil von einer domain ist
$v_{i}$ ist immer ein "Null" wert
Forell ist eine Relation eine mathematische relation von dem grad $n$ auf den Domains, die zutreffend sind

Eine relation kann einfach daten bzw. keys von wo anderes importieren
sprich wenn wir z.b. sagen, dass wir die relationen von studenten haben, sprich $r (St u d e n t)$
- können wir sehen was für fächer usw. er studiert, und welche daten wie zusammen hängen

Jeder Touple repräsentiert etwas in unserer "virtuellen" welt
Jeder touple kann auch als statement bzw. fakt angesehen werdne
In unserem Relationsstatus können wir nur wahre aussagen haben, weils sonst halt keinen sinn macht

Constraints definieren "regeln" die schauen was und was nicht in einer Datenbank erlaubt sind
Constraints müssen immer valid sein, sonst passt was nicht. Man kann die sich ein wenig vorstellen wie so assert statements
Es gibt vier Typen von inherenten constraints die in jedem Relation-Model ausgedrückt werden können
- 1. Domain
- 1. Key
- 1. Entity Integrity
- 1. Referential integrity constraints

Bei jedem tuple muss ein wert von jedem attribut atomic sein und aus der domain stammen
Sprich jeder wert muss aus der domain stammen und in das passende Schema passen

Das sind subsets von attributen die einzigartig einen Tuple in einem relationsstate identifizieren
Wir haben Superkeys
- Die dinger sind eine Menge an attributen die folgenden conditions folgen
  - keine zwei touple können in der selben relation die selben werte für die attribute haben
  - Formell: $\forall t_{1}, t_{2} \in r (R) s . t . t_{1} \neq = t_{2}, it holds that t_{[} S K] \neq = t_{2} [S K]$
Schlüssel von dem Constraint ist ein "minimaler" superkey
- also praktisch ein superkey, der keine attribute entfernen und immernoch die selbe "einzigartigkeit" haben kann
- §%23%§
Jeder schlüssel ist ein superkey, aber nicht andersrum
- jedes subset von attributen mit einem key ist ein superkey
- aber ein superkey kann ein key sein (wenns denn minmal ist), das nuss aber nicht zutreffen (sofern es dann halt nicht minimal ist)
Wenn eine Relation mehrere Key-Kandidaten (haha) hat, wird einer als der primary key ausgewählt
- Das attribut das als primary key ausgewählt wurde wird unterstrichen
Diese Primary keys werden auch verwendet um tuples von anderen touples zu erreichen bzw. zu referenzieren
Wir wählen immer die kompaktesten keys, damit wir schön effizienz sind

Wir schauen uns ein relationsschema an
Da haben wir zwei schlüssel
die sind beide dann zusammen der superkey von unserem wert
Da allerdings noch mehr daten in unserer zeile sind, sind die zwei keys zusammen ein superkey, aber kein aussagender schlüssel
§%25%§

Das Primary-Key attribut ine inem relationsschema kann keine null-werte in der relation haben
§%16%§

Ein tuple in einer relation der auf eine Andere relation zeigt und auf eine bereits vorhandenen tuple in der relation verweisen muss
Tuples in einer referenzierenden relation haben foreign keys, die die PK attribute von einem anderen tuple, also einer anderen referenzeirten relation referenzieren
- $F K (R_{1}) = P K (R_{2})$

Wir wollen schauen, wie wir jetzt diese "Beziehungen" die wir uns in unserem magical dream land entity relationship model zusammengebastelt haben in einer Relationalen Datenbank zusammen passen
weil das doppel-oval ist, ist "semester" ein Element mit mehreren werten
Es gibt am ende verschiedene Grundrelationen mit denen wir sachen zusammenfügen können
- Binäre Relationen
  - Also relationen wo 2 bres involviert sind
  - Auch bekannt als ein 1:1 relationship
  - Sprich jede entity hat auch genau eine andere, verwandte entity
- Dann gibt es noch 1:N bzw. N:1 Relationships
  - Hier werden unterschiedlich viele sachen zusammengehangen, je nachdem wie das im Kontext passt
  - Wir haben z.b. 50 Papiere in einem Drucker, aber logischerweise nicht 50 Drucker mit einem Papier each, denn das wäre offensichtlich DOOF
- Neben solchen expliziten Relationen gibt es auch noch N:M Relationen
  - Hier können beliebig viele dinge mit beliebig vielen anderen dingen abhängen
  - Das ist sinnvoll, wenn z.b. große abhängigkeitsstrukturen oder fammilien oder so modelliert werden müssen, denn rein Theoretisch, kann jemand n kinder haben....