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
SLA
Service-Level-Agreement
legen die Rahmenbedingungen eines Servicevertrages fest
z.B. Entstör Dauer, Art des Supports, Ausfallzeiten
es ist für wiederkehrende Dienstleistungen / Vertragsbedingungen zwischen Serviceanbieter und Servicekunden
OLA
Operation Level Agreement
eine Vereinbarung zwischen den Teilbereichen dieses
IT-Dienstleisters, um das SLA zu erfüllen
UC
Underpinning Contract
ein Vertrag zwischen einem Service Provider und einem externen Dienstleister über die Erbringung eines unterstützenden Service, mit dessen Hilfe der Service Provider einen Kundenservice anbieten kann
müssen deshalb mit den auf die Kunden ausgerichteten Service Level Agreements in Übereinstimmung stehen
Workaround
kurzfristige Lösung, die nicht das Problem beseitigt
Configuration Item
der in der Service-Anfrage zu bearbeitende Gegenstand oder Software
RACI
Responsible Accountable Consulting Information
Operationsverantwortlicher Prozessverantwortlicher Operativ Verantwortlicher Information
Reaktives Problemmanagement
auftretende Incidents werden nachträglich geklärt
Proaktives Problemmanagement
Fehler vermeiden, durch Beispielsweise regelmäßige Updates
Kulanz
freiwilliger kostenloser Service
Helpdesk
Betreuung von Kunden bei IT-Störungen an einem extra eingerichteten Arbeitsplatz
IT-Outsourcing
Verlagerung einer bisher internen Funktion an einen Dienstleistungsanbieter
Frequently asked Questions (FAQ)
Beschreibung häufig nachgesuchter Begriffe oder Fragen auf Webseiten
Field-Service, vor Ort Service, In-Side-Management
Ausführung von Dienstleistungen beim Kunden
Gewährleistungs- oder Garantieservice: Kostenloser Service in den ersten 24 Monaten oder länger, wenn vereinbart
Serviceportfolio oder Servicekatalog
Sammelbegriff für das Angebot von IT-Dienstleistungen eines Unternehmens
Inhalte SLA
Zielsetzung
Wer ist Teil des Vertrags
Leistungen des Auftragnehmers
Vertragsdauer und Kündigung
Art und Umfang der Leistung
Weisungsfreiheit
Auftragserfüllung
Vergütung
Service-Level
Vertragsstrafen/Schadenersatz/Sanktionsmöglichkeiten
Wartungszeiten
Reporting und Messkriterien
Haftung
Sonstige Bestimmungen
Erfüllungsort
Anforderungen Problem Management
Probleme müssen mittels Trendanalysen identifiziert und registriert werden
Probleme müssen untersucht werden, um Maßnahmen zu ihrer Beseitigung oder zur Reduzierung ihrer Auswirkungen auf Services zu identifizieren
wenn ein Problem nicht dauerhaft beseitigt wird, muss das Problem als bekannter Fehler erfasst werden, zusammen mit Maßnahmen wie effektiven Workarounds oder Umgehungslösungen
aktuelle Informationen über bekannte Fehler und effektive Workarounds müssen gepflegt werden
Eingang von Events über das Remote Management System:
Informationen, Warnings und Exeptions
Tickets kommen über:
Ticketsystem
Mail
Telefon
persönlich
Incidents werden priorisiert nach:
Urgency
Impact
danach wird die erste Hilfe angeboten
ist dies nicht wirksam wird es hierarchisch oder funktional eskaliert
Incident & Service Request Management (ISRM)
alle Incidents und Service-Requests müssen auf konsistente Art und Weise erfasst, klassifiziert und priorisiert werden
die Priorisierung von Incidents und Service-Requests muss die in den SLAs festgelegten Service-Ziele berücksichtigen
die Eskalation und der Abschluss von Incidents und Service-Requests muss auf konsistente Art und Weise erfolgen
Eingebundene Personen müssen Zugang zu relevanten Informationen, wie bekannten Fehlern und anderen Informationen haben
Anwender müssen über Fortschritt ihrer Incidents und Requests auf dem Laufenden gehalten werden
Es muss klare Festlegungen zur Ermittlung von Major Incidents sowie zum konsistenten Umgang mit ihnen existieren
Anforderung an den Prozess der Annahme von Kundenproblemen
Geordnete Annahme des Kundengespräches, Kontaktdaten, Art des Problems…
Priorisierung der eingehenden Kundenanfragen
Allgemein zugängliche Daten. Ticketsystem, Known Error Database, Kundendaten, Configuration Items (was ist vor Ort installiert?)
Problemlösung dokumentieren
Benachrichtigung des Kunden, bei Ticketöffnung, Ticketänderung, Ticketschließung
Vier-seiten-Kommunikationsmodell
Sachebene
die reinen Informationen, die in der Nachricht enthalten sind
Selbstoffenbarungsebene
was die Nachricht über den Sender offenbart
Beziehungsebene
was die Nachricht über die Beziehung zwischen Sender und Empfänger aussagt
Appellebene
welche Wirkung der Sender mit seiner Nachricht erzielen möchte
Verbale und paraverbale Kommunikation
Verbale Kommunikation
Worte die gesagt werden
Paraverbal
Tonhöhe
Lautstärke
Tempo und Sprechpausen
Betonung und Aussprache
Sprachmelodie
hierarchische Eskalation
den Incident an jemanden mit Entscheidungsgewalt weiterzugeben
funktionale Eskalation
den Incident an jemanden mit dem nötigen Fachwissen weiterzuleiten
issue tracking system
Computersoftwarepaket, das Problemlisten verwaltet und pflegt
knowledge base
Selbstbedienungs-Onlinebibliothek mit Informationen zu einem Produkt, einer Dienstleistung, einer Abteilung oder einem Thema
