IDP - Section 3 - Datenbanktechnologie
Kopplung, Integration, Architekturmodell, DB-Entwurf, Semantische Info, Relationenmodell, Abbildung, SQL, Typische Transaktionsprobleme, Verteilung
Kopplung, Integration, Architekturmodell, DB-Entwurf, Semantische Info, Relationenmodell, Abbildung, SQL, Typische Transaktionsprobleme, Verteilung
-
- 1 / 29
-
Flashcards
Wofür braucht man Datenbanksysteme bzw. was sind deren Vorteile?
- Datenintegration: logisch zentralen Datenbestand
- Datenunabhängigkeit: Physische und logische Unabhängigkeit der Zugriffstrategie und internen Datenverwaltung
- Datenkonsistenz: physiche und logische Widerspruchsfreiheit
- Datenintegrität: Gewährleistung korrekten und vollständigen Abiildung der Benutzersicht
- Redundanzfreiheit: keine überflüssige Infos sowohl explizit (nur 1x gespeichert) und implizit (Element kann nicht abgleitet werden aus einem anderen)
- Transaktionsverwaltung: Datenbankoperationen führen von konsitentem zu konsistentem Zustand
Welche Ebenen unterscheidet man in der Datenbankarchitektur?
Wozu benötigt man ein Datenmodell?
• Modellierungsaspekt zur Beschreibung realer Sachverhalte in einem semantischen Informationsmodell sowie andererseits der
• Implementierungsaspekt zur systemtechnischen Realisierung anhand eines operationalen Modells.
Welche Aspekte sind auf der konzeptuellen Ebene zu unterscheiden?
logisch formale Gesamtsicht
Imlementierungsbedingte Restriktionen müssen nicht berücksichtigt werden
Welche Modellierungskonzepte besitzen semantische Datenmodelle?
Ziel der semantischen Ifnromationsmodellierung?
Zielsetzung der semantischen Informationsmodellierung ist die möglichst realitätsgetreue Abbildung realer Sachverhalte der Diskurswelt (interessierender Ausschnitt der realen Welt) auf ein Informationsmodell mit grösstmöglicher Semantik (Bedeutung).
1:n Beziehung "entwickelt-von" zu Konstrukteur
Die Kardinalität 1:n beschreibt die minimale und maximale Anzahl die ein Element diese Bezeihung eingehen kann. EIn bauteil wird von einem Konstrukteur entwickelt, ein Konstrukteur kann mehere Bauteile entwickelt haben.
Nenne 3 operationale Modell Strukturen:
- Hirarchische Datenmodell
- Netzwerkdatenmodell
- Relationenmodell
Alle drei Modelle sind als kommerziell eingeführte Datenbanktechnologien verfügbar.
Netzwerkmodell
Aufgrund ihres guten Laufzeitverhaltens bei der geometrischen Modellierung komplexer Bauteilstrukturen besitzen Netzwerkmodelle insbesondere im CAD-Bereich eine weite Verbreitung.
Nachteile des hirarchischen und Netzwerk Datenmodells:
Das hierarchische und das Netzwerkmodell weisen jedoch keine exakte Trennung der geforderten drei Abstraktionsebenen auf und sind hinsichtlich Datenabhängigkeit und Redundanzfreiheit ungenügend.
Charakteristisch ist weiterhin das prozedurale Navigieren in den Datenstrukturen, wobei jeweils angegeben werden muss, wie auf die Daten zugegriffen werden soll.
Auf welchem Modell beruhen heutige Datenbanksysteme?
Das Relationenmodell ist das beste da es redundanzfrei ist und Datenabhängikeiten gut darstellt.
Das von Codd vorgeschlagene Relationenmodell [Cod-70] ermöglicht eine strikte Trennung der logischen und physischen Ebene und besitzt dadurch erstmals eine vollständige Datenunabhängigkeit.
SQL
Structured Query Language
Pendants zwischen semantisch und relation
ENTITY = relationale Tabelle
sematisches ERM Atrribut = relationales Attribut
Relation bei Relationsmodell
Eine Relation besteht immer aus zwei wesentlichen Bestandteilen, dem Schema (Tabellenaufbau) und den Werteausprägungen (Tabelleninhalt). Das Schema ergibt sich aus der Abstraktion der Informationsanalyse im Mengendiagramm auf verallgemeinerte Objekttypen dessemantischen Modells. Die in der realen Welt existierenden konkreten Bauteile und Konstrukteure, welche im Mengendiagram durch Punkte dargestellt werden, ergeben die Werte bezüglich der relationalen Domänen (Attributwertebereiche). Eine Objektinstanz wird hierbei durch ein Tupel repräsentiert.
Relationmodell: Primärschlüssel
Der Primärschlüssel ist eine, evtl. unter mehreren Schlüsselkandidaten ausgewählte minimale Kombination von Attributen, die ein Tupelobjekt eindeutig identifizieren.
Relationmodell: Fremdschlüssel
Fremdschlüssel müssen dagegen nicht eindeutig sein, erfordern jedoch ein gleichwertiges Partnertupel im Primärschlüssel einer anderen Relation.
Anomaliene bei schlechtem Modellentwurf:
Einfüge-Anomalie: Neurer Tupeleintrag vo nteilweise unbekannten Attributwerten (nullwerten) ist nicht möglich, aber gewünscht
Lösch-Anomalie: Durch das éschen eines Tupels gehen ungewollt Infos verloren die benötigt werden
Änderungs-Anomalie: änderung mehrere Tupel muss gleichzeitg erfolgen sonst inkonsistenzen
Abbildung von ERM auf Relationsmodell:
Objekttyp ENTITY -> Relation
Merkmalsfunktion -> Attribut
binär-hirarchische Bezeihung -> Fremdschlüseldefinition
allgemeine Beziehung -> Relation mit den Schlüsselatributen der beteilgeten Objekten
rekursive Beziehung -> Relation mit den Schlüsselatribut des beteilgent Objekttyps bezeichnet mittels Rollenamen
Spezialiseirung 2 möglihckeiten: Horizontal, vertikal
Horizontal: Direkt Zugriff auf alle Spezielle TUpel ohne ein Join zu erfordern
Vertikal: Dierekter Zugriff auf die Gesammtheit aller tupel ohne ein Join zu erfordern
SQL Datenbankzugriff Syntax:
SELECT : Spaltenattribute
FROM: Tabellename
WHERE: Auswahlbedingung
Was ist SQL?
genormte Anfragsprache für rationale Datenbanksysteme
Dekripteive sprache: Programmierer mus nur angebn WAS für daten er will nicht WIE!
Datendefinition DDL, Datenmanipulation DML
Tabelle erzeugen SQL:
CREATE TABLE zpedb.Konstrukteur(
K# INTEGER NOT NULL,
Name VARCHAR(30) NOT NULL,
Abteilung VARCHAR(20) NOT NULL,
CONSTRAINT PK_K# PRIMARY KEY (K#) );
Tabelle Bauteil erzeugen:
CREATE TABLE zpedb.Bauteil(
Sachnummer VARCHAR(15) NOT NULL,
Benennung VARCHAR(25) NOT NULL,
Werkstoff VARCHAR(20),
K# INTEGER,
CONSTRAINT PK_Sachnummer PRIMARY KEY(Sachnummer)
);
Fremdschlüssel defineren von Bauteil auf Konstrukteur:
ALTER TABLE zpedb.Bauteil ADD
CONSTRAINT FK_Konstrukteur FOREIGN KEY (K#) REFERENCES
zpedb.Konstrukteur (K#) ON DELETE RESTRICT );
SQL Tupel einfügen:
INSERT INTO zpedb.Konstrukteur (K#, Name, Abteilung)
VALUES (1, ‚Müller‘, ‚ZPE‘);
INSERT INTO zpedb.Konstrukteur (K#, Name, Abteilung)
VALUES (2, ‚Huber‘, ‚ZPE‘);
SQL Tupel in Bauteil einfügen:
INSERT INTO zpedb.Bauteil (Sachnummer, Benennung,
Werkstoff, K#) VALUES (‚470-000 000.001‘, ‚Sportwagen‘,
‚-‘, 1);
INSERT INTO zpedb.Bauteil (Sachnummer, Benennung,
Werkstoff, K#) VALUES (‚470-000 200.001‘, ‚Schaltgetriebe‘,
‚-‘, 1);
INSERT INTO zpedb.Bauteil (Sachnummer, Benennung,
Werkstoff, K#) VALUES (‚470-000 210.001‘, ‚Motor‘, ‚-‘, 2);
INSERT INTO zpedb.Bauteil (Sachnummer, Benennung,
Werkstoff, K#) VALUES (‚470-000 201.002‘, ‚Getriebeflansch‘,
‚ST37‘, 2);
Transaktionsverwaltung SQL:
ACID Prinzipien:
Atomarität: Transaktion vollständig oder gar nöd ausgeführt
Konsistenz: Konsistenzbedingungen müssen am Ende wieder efüllt sein
Isolation: Korrektheit im Parallelbetriebt durch Isolation
Persistenz (Durability): Garantie für Dauerhaftiketi von Änderungen
Funktionen einer Transatkionsverwaltung
- Mehrbenutzerkontroller (Concurrency Control)
- Datensicherung (Recovery)