SQL + BWL - Teil 2 Flashcards
Daten einfügen
INSERT INTO tabellenname
[attributname1, attributname2, …]
VALUES
(wert1, wert2, …);
Spalte in der Datenbank hinzufügen
ALTER TABLE tabellenname
ADD COLUMN (attributname12 TYP);
Daten ändern
UPDATE tabellenname
SET attribut1 = wert1, attribut2 = wert2, …
WHERE bedingung
Daten löschen
DELETE FROM tabellenname
WHERE bedingung
Datenbank erstellen
CREATE DATABASE [IF NOT EXISTS] datenbankname;
USE datenbankname;
CREATE TABLE [IF NOT EXISTS] tabellenname
(Attribut1 Datentyp Constraints, Attribut2 Datentyp Constraints, …,
PRIMARY KEY (AttributPrimärschlüssel), FOREIGN KEY
(AttributFremdschlüssel) REFERENCES verknüpftetabelle
(AttributPrimärschlüssel));
Constraints:
NOT NULL
erlaubt keine Nullwerte bzw. leeren Attributwerte
UNIQUE
erlaubt nur Attributwerte, die sich nicht doppeln
DEFAULT
legt einen vorgegebenen Wert für das Attribut fest, wenn nichts anderes festgelegt wird
AUTO_INCREMENT
erhöht den Wert des Attributs automatisch um eins
ALTER TABLE tabellenname + …
Für eine neue Spalte:
ADD Spaltenname Dateityp
Für das Löschen einer Spalte:
DROP COLUMN Spaltenname
Für das Ändern der Bezeichnung einer Tabelle:
RENAME neuerTabellenname
Für das Ändern der Bezeichnung einer Spalte:
RENAME COLUMN alterSpaltenname TO neuerSpaltennam
Vergleich durch 2 Tabellen
SELECT nachname, vorname, strasse, hausnr, plz, ort
FROM fahrschueler, orte
WHERE fahrschueler.ortnr = orte.ortnr;
JOIN (Inner Join)
SELECT
product.name AS product_name
category. Name AS category_name
FROM product
JOIN category ON product.category_id = category.id;
Update -Anomalie
bei einem Update werden nicht alle betroffenen Attributwerte geändert
Dateninkonsistenzen
Lösch-Anomalie
bei einer Löschung gehen ungewollt Daten verloren
Einfüge-Anomalie
Daten können nicht eingefügt werden
Atomisierung
alle Daten werden soweit aufgespalten wie möglich und nötig
Normalform einhalten! verhindert Probleme
- Normalform
eine Datenbank ist atomisiert und enthalt pro Attribut nur eine Information
- Normalform
alle Attribute sind funktional (direkt) abhängig von gesamte Primär Schlüssel und nicht von Teilen von ihm
2 tablice koje su međusobno povezane, ali promjena jedne tablice ne utjece na drugu tablicu
- Normalform
jedes nicht Schlüssel Attribut hangt nur von Primär Schlüssel und nicht von einem anderem Nicht Schlüsselattribut ab
eine schlechtere Performance und mehr Speicherverbrauch
Entity-Relationship-Modell
- eine Mitarbeiter leitet mehrere Projekte
- eine Projekt leitet nur 1 Person
Kardinalitäten
1:1
1 Datensatz gehört zu einem anderen Datensatz
genau eine Entität exakt einer anderen Entität zugeordnet
1:n
1 Datensatz kann Verbindung mit mehreren (dem N-Teil) Datensätzen haben
einer Entität auf der einen Seite der Beziehung (Main) stehen keine, eine oder mehrere Entitäten auf der anderen Seite (Detail) gegenüber
m:n
Dies sollte in 1:1 und 1:n umgemodelt werden, alternativ n:1
Auf beiden Seiten können beliebig viele Entitäten in Beziehung zueinanderstehen
Relation Modell
CREATE tabelle_01
(atribut_01 TYP, …,
PRIMARY KEY (attribut_PS),
FOREIGN KEY (attribut_FS) REFERENCES tabelle_02 (PS));
Event
eine Systemseitige Nachricht
sie kann Handeln erfordern oder eine reine Information sein
ein Event kann auch ein Incident werden/mit sich bringen Informationen, Warnungen und Exeption
Incident/Major Incident
Vorfall, der einem Ausfall der Vertragsmäßigen Leistung bedeutet
Major: Hochpriorisierte Incidents
Problem
(Potenziell) wiederkehrende Incidents
Service Request
eine Anfrage, die kein sofortiges Handeln erforderlich macht
in der Regel eine Anfrage des Servicekunden für Problembehebungen oder Quality-of-Life-Änderungen / Planbare Kundenanfrage, oft über den vertraglichen Rahmen hinaus
Eskalation
Heraufstufung an den Second Level Support
