DBIS-2016-SQL-DML

Datenmanipulation mit SQL
DML
Wintersemester 16/17
DBIS
1
Übersicht
• Anweisungen für Datenänderung:
• INSERT
• UPDATE
• DELETE
• Anweisungen für Datenzugriff:
• SELECT
• CREATE / DROP VIEW (Konzeptuelle Ebene)
• DML-Anweisungen sind mengenorientiert: Mit einer Anweisungen
kann mehr als ein Tupel eingefügt, geändert, gelöscht oder
gelesen werden
Wintersemester 16/17
DBIS
2
Der „INSERT“- Befehl
• Befehl zum Einfügen von Datensätzen in eine Tabelle
• Ausprägungsformen
• Einfügen von Tupeln als Konstanten
• Einfügen von Tupeln aus einem Abfrageergebnis (SFW-Klausel)
• Beispiele im Folgenden (zunächst) für Buch und Ausleihe:
CREATE TABLE Buch (
InvNr INTEGER NOT NULL,
Titel VARCHAR(30),
ISBN CHAR(5),
Autor VARCHAR(40),
PRIMARY KEY (InvNr))
Wintersemester 16/17
CREATE TABLE Ausleihe (
InvNr INTEGER NOT NULL,
Name VARCHAR(20),
PRIMARY KEY (InvNr),
FOREIGN KEY (InvNr)
REFERENCES Buch(InvNr))
DBIS
3
INSERT – Tupel als Konstanten I
• Syntax:
INSERT INTO Basisrelationenname [(Spaltenname_1, ..., Spaltenname_k)]
VALUES (Wert_11, ..., Wert_k1) [, ...,
(Wert_1n, ..., Wert_kn)]
• Beispiel 1: Einfügen eines Tupels in Relation „Buch“
INSERT INTO Buch (InvNr, Titel, ISBN, Autor)
VALUES (1201,'Objektbanken','3-111','Heuer')
• Beispiel 2: Einfügen eines unvollständigen Tupels in Relation „Buch“
INSERT INTO Buch (InvNr, ISBN)
VALUES (4867,'3-221')
 Werte für „Autor“ und „Titel“ werden auf NULL gesetzt!
Wintersemester 16/17
DBIS
4
INSERT – Tupel als Konstanten II
• Beispiel 3: Einfügen eines Tupels in Relation „Buch“ ohne Inventarnummer
INSERT INTO Buch (Titel, ISBN, Autor)
VALUES ('Modula-4','3-222','Wirth')
• Fehlermeldung, da NULL-Wert für InvNr nicht erlaubt (Primärschlüssel!)
• Beispiel 4: Weglassen der Attributliste bei der INTO-Klausel
INSERT INTO Buch
VALUES (4710,'Modula-4','3-222','Wirth')
• Werte der VALUES-Klausel werden den Attributen in der Reihenfolge
zugeordnet, wie sie beim CREATE-Statement aufgeführt waren
• 4711  InvNr, 'Modula-4'  Titel, '3-222'  ISBN, 'Wirth'  Autor
Wintersemester 16/17
DBIS
5
INSERT – Tupel als Konstanten III
• Beispiel 5: Einfügen eines Tupels in Relation „Ausleihe“
INSERT INTO Ausleihe
VALUES (0815,'Liebisch')
• Anweisung scheitert, wenn kein zugehöriger Primärschlüsselwert (InvNr
= 0815) in Relation „Buch“ existiert (Fremdschlüssel-Beziehung)
• Beispiel 6: Einfügen von zwei Tupeln in Relation „Ausleihe“
INSERT INTO Ausleihe (InvNr, Name)
VALUES (1201,'Liebisch'), (4710,'Küspert')
Wintersemester 16/17
DBIS
6
INSERT – Tupel als SFW-Klausel I
• Syntax:
INSERT INTO Basisrelationenname [(Spaltenname_1, ..., Spaltenname_k)]
<lesende SQL-Anfrage>
• Wirkung:
• Ergebnis der lesenden SQL-Anfrage wird in die angegebene Relation
eingefügt
•
Abgeschlossenheit: SELECT-Anfrage liefert wieder eine Menge
•
Mengenorientiertheit: INSERT-Operation kann Mengen verarbeiten
• Voraussetzung sind strukturell gleiche Relationen
•
Identische Anzahl von Attributen
•
Kompatibilität der Attribut-Wertebereiche
•
Reihenfolge der Attribute wichtig oder explizite Benennung
• SQL-Anfrage kann beliebig komplex sein
Wintersemester 16/17
DBIS
7
INSERT – Tupel als SFW-Klausel II
• Beispiel 7: Verdopplung der Tupel in Relation „Ausleihe“
INSERT INTO Ausleihe
SELECT * FROM Ausleihe
• Selektion aller Tupel (= *) aus Relation „Ausleihe“ als Menge
• Einfügen der Tupelmenge in Relation „Ausleihe“
• Anweisung scheitert wegen Primärschlüssel-Verletzung
Wintersemester 16/17
DBIS
8
INSERT – Tupel als SFW-Klausel III
• Beispiel 8: Kopieren von Inhalten verschiedener Tabellen
• Angenommen, es gibt zusätzlich eine Relation Ausleihe_alt mit denjenigen
Büchern, die schon länger als 2 Jahre ausgeliehen sind
• Inhalt dieser Relation soll nun, damit er nicht in Vergessenheit gerät, wieder in
Relation Ausleihe übernommen werden
INSERT INTO Ausleihe (InvNr, Name)
SELECT InvNr_alt, Name_alt FROM Ausleihe_Alt
• Anweisung fügt alle Tupel aus Relation „Ausleihe_alt” in Relation „Ausleihe”
ein (Kopieren)
Wintersemester 16/17
DBIS
9
Der „UPDATE“- Befehl
• Syntax:
UPDATE Basisrelationenname
SET Spaltenname_1 = Ausdruck_1 [, Spaltenname_k = Ausdruck_k]
[WHERE Bedingung]
• Wirkung:
• In allen Tupeln von Basisrelationenname, welche die (optionale) Bedingung
erfüllen, werden die Attributwerte der Spaltenname_i wie angegeben ersetzt
• Ausdruck_i: Konstante, Attribut, SFW-Ausdruck (Subselect)
Wintersemester 16/17
DBIS
10
UPDATE – Beispiele I
• Beispiel 1: Der Titel des Buches mit der InvNr = 1201 („Objektbanken“)
soll in „Objektdatenbanken“ geändert werden
UPDATE Buch
SET
Titel = 'Objektdatenbanken'
WHERE
InvNr = 1201
• Anweisung ändert immer nur ein einzelnes Tupel, weil InvNr als
Primärschlüssel definiert ist
Wintersemester 16/17
DBIS
11
UPDATE – Beispiele II
• Beispiel 2: Alternative Anweisung für Beispiel 1
UPDATE Buch
SET
Titel = 'Objektdatenbanken'
WHERE
Titel = 'Objektbanken'
• Anweisung ändert datenabhängig ein oder mehrere Tupel, je nach
dem wieviele Tupel den Titel 'Objektbanken' haben
• Beispiel 3: Für alle Bücher mit InvNr > 1000 soll der Autor auf „Dr.
Seltsam“ gesetzt werden (Explizites Mengen-Update)
UPDATE Buch
SET
Autor = 'Dr. Seltsam'
WHERE
InvNr > 1000
Wintersemester 16/17
DBIS
12
UPDATE – Beispiele III
• Beispiel 4: Gib allen Angestellten der Relation
Angest(PNr, Name, Gehalt, ...) eine Gehaltserhöhung um 1000,- EUR
UPDATE Angest
SET
Gehalt = Gehalt + 1000
• Beispiel 5: Für alle Bücher soll die InvNr auf 9999 gesetzt werden
UPDATE Buch
SET
InvNr = 9999
• WHERE-Klausel nicht benötigt, da alle Tupel der Relation zu ändern sind
• Operation verletzt Konsistenz („Duplicate key“) und wird vom DBMS nicht
ausgeführt / ungeschehen gemacht
Wintersemester 16/17
DBIS
13
UPDATE – Beispiele IV
• Beispiel 6: Das Buch mit InvNr = 1201 soll den gleichen Titel bekommen
wie das Buch mit InvNr = 4710
UPDATE Buch
SET
Titel = (SELECT Titel FROM Buch WHERE InvNr = 4710)
WHERE
InvNr = 1201
• Subselect holt den Titel zum Buch mit InvNr = 4710
• Ergebnis wird als Titel für das Buch mit InvNr = 1201 gesetzt
Wintersemester 16/17
DBIS
14
Der „DELETE“- Befehl
• Syntax:
DELETE
FROM
Basisrelationenname
[WHERE Bedingung]
• Wirkung:
• Alle Tupel in Basisrelationenname, welche die (optionale) Bedingung erfüllen,
werden gelöscht
• Relationsschema bleibt unverändert (im Gegensatz zu DROP TABLE)
Wintersemester 16/17
DBIS
15
DELETE – Beispiele I
• Beispiel 1: Das von Hr. Meyer ausgeliehene Buch mit InvNr = 4711
wurde zurückgegeben und soll aus der Relation „Ausleihe“ gelöscht
werden
DELETE
FROM
Ausleihe
WHERE
InvNr = 4711
• Alternative Bedingung (Name = 'Meyer') löscht eventuell mehr
Wintersemester 16/17
DBIS
16
DELETE – Beispiele II
• Beispiel 2: Löschung des gesamten Inhalts der Relation „Ausleihe“
DELETE
FROM
Ausleihe
• Beispiel 3: Kann eine DELETE-Anweisung zur Integritätsverletzung
führen (analog zu „Duplikate key“ beim UPDATE)?
DELETE
FROM
Buch
WHERE
Titel = 'Objektdatenbanken'
• Verletzung der Fremdschlüsselbeziehung zwischen Ausleihe und Buch
(Fremdschlüsselwert 4710 für Ausleihe.InvNr würde ins „Leere zeigen“)
• Zurückweisung der Operation
Wintersemester 16/17
DBIS
17
Der „SELECT“- Befehl I
• Fundamentales Konstrukt für den DB-Zugriff mit SQL zur Datenermittlung
ist die SELECT-FROM-WHERE-Klausel (SFW-Klausel)
• SELECT:
• Festlegung der Ergebnisstruktur (Projektionsliste) einer Anfrage
• Welche Tabellenspalten soll die Anfrage liefern?
• FROM:
• Festlegung der Datenherkunft für die Anfrage
• Welche Relationen werden zur Beantwortung der Anfrage benötigt?
• WHERE:
• Festlegung der Selektionsbedingung
• Welche Daten (Tupel) sollen genau ermittelt werden?
• Wie erfolgt ggf. eine Datenverknüpfung über mehrere Relationen (impliziter Join,
expliziter JOIN-Operator seit SQL-92)?
Wintersemester 16/17
DBIS
18
Der „SELECT“- Befehl II
• Ergänzung der SFW-Klausel durch weitere Klauseln
• GROUP BY (Gruppierung)
• HAVING (Bedingung für gruppierte Daten)
• ORDER BY (Sortierung der Ergebnisdaten)
ALL
variable
SELECT
ziel-liste
FROM
relation
,
DISTINCT
WHERE
where-Bedingung
GROUP BY
attr-ref
,
HAVING
have-Bedingung
ORDER BY
attr-ref
ASC
DESC
,
nur die Ergebnisdarstellung betreffend
Wintersemester 16/17
DBIS
19
Der „SELECT“- Befehl III
Grundlage für nachfolgende Beispiele:
CREATE TABLE Angest (
AngNr INTEGER PRIMARY KEY,
Name VARCHAR(30),
Wohnort VARCHAR(40),
Beruf VARCHAR(40),
AbtNr INTEGER,
Jahresurlaub INTEGER,
Resturlaub INTEGER)
CREATE TABLE Projekt (
ProNr INTEGER PRIMARY KEY ,
PName VARCHAR(30),
Beschreibung VARCHAR(50),
PLeiter INTEGER)
ANGEST
n
Prozent
Mitarbeit
m
PROJEKT
Wintersemester 16/17
DBIS
CREATE TABLE Mitarbeit (
ProNr INTEGER ,
AngNr INTEGER,
Prozent INTEGER,
PRIMARY KEY (ProNr, AngNr),
FOREIGN KEY (ProNr) REFERENCES
Projekt(ProNr),
FOREIGN KEY (AngNr) REFERENCES
Angest(AngNr))
20
SELECT – Beispiele I
• Beispiel 1: Gesucht sind alle Angestellten jeweils mit Name und Wohnort
die in einer Abteilung mit AbtNr>3 arbeiten. Ausgabe soll nach Name
absteigend sortiert erfolgen und Duplikate sollen nicht eliminiert werden.
SELECT ALL Name, Wohnort
FROM
Angest
WHERE
AbtNr > 3
ORDER BY
Name DESC
• Ergebnis:
• Schlüsselwort ALL erzeugt Multimenge, welche Duplikate erlaubt
• Streng genommen nicht mehr Teil des „rein relationalen“ Modells
• Abweichungen in SQL und Produkten (Performance, Funktionalität)
Wintersemester 16/17
DBIS
21
SELECT – Beispiele II
• Beispiel 2: Gib alle Angestellten aus, die von Beruf 'Hundezüchter' sind
(Selektion)
• Variante 1
SELECT ALL
AngNr, Name, Wohnort, Beruf,
AbtNr, Jahresurlaub, Resturlaub
FROM
Angest
WHERE
Beruf = 'Hundezüchter'
• Variante 2 (ALL ist Default, kann also weggelassen werden)
SELECT
AngNr, Name, Wohnort, Beruf,
AbtNr, Jahresurlaub, Resturlaub
FROM
Angest
WHERE
Beruf = 'Hundezüchter'
Wintersemester 16/17
DBIS
22
SELECT – Beispiele III
• Variante 3 (enthält die Zielliste alle Attribute der Eingangsrelation, darf
statt dessen  geschrieben werden)
SELECT *
FROM
Angest
WHERE
Beruf = 'Hundezüchter'
• DISTINCT in der SELECT-Klausel sorgt für Duplikatelimination
• Verwendung im Beispiel 2 möglich, aber unnötig
• DBMS sollte diese Angabe ignorieren, wenn in der Zielliste der
Primärschlüssel enthalten ist
Wintersemester 16/17
DBIS
23
SELECT – Beispiele IV
• Beispiel 3: Gib für alle Angestellten Beruf und Wohnort aus und zwar in
dieser Reihenfolge (Projektion, „mehr“ als Algebra)
• Variante 1 (WHERE-Klausel entfällt, da alle Angestellten gefragt sind,
alternativ ist „WHERE true“ möglich)
SELECT Beruf, Wohnort
FROM
Angest
• Attributreihenfolge in der Ergebnisrelation bedeutungslos aus „streng
relationaler Sicht“ aber Wesentlich für die Ausgabe/Darstellung zum
Benutzer
Wintersemester 16/17
DBIS
24
SELECT – Beispiele V
• Verwendung von DISTINCT diesmal relevant!
SELECT DISTINCT Beruf, Wohnort
FROM
Angest
• DBMS müsste Duplikate eliminieren, weil der Primärschlüssel (AngNr) im
Ergebnis fehlt
• Duplikatprüfung in der Regel auf sortierter Ergebnisrelation
• Ausgabe dann vermutlich auch sortiert, als Anwender nicht darauf
verlassen sondern bei Bedarf explizit anfordern (ORDER BY)!
Wintersemester 16/17
DBIS
25
SELECT – Beispiele VI
• Beispiel 4: Gib die Namen aller Angestellten mit AbtNr zwischen 2 und 6
aus (Projektion und Selektion)
• Variante 1
SELECT
Name
FROM
Angest
WHERE
AbtNr >= 2 AND AbtNr <= 6
• Variante 2
…WHERE
AbtNr BETWEEN 2 AND 6
• Variante 3
…WHERE
AbtNr IN (2,3,4,5,6)
• Nach IN folgt Multimenge atomarer Werte (die natürlich auch einelementig
oder leer sein darf) oder ein SFW-Ausdruck
Wintersemester 16/17
DBIS
26
SELECT – Beispiele VII
• Beispiel 5: Gib die Attribute Name und Wohnort der Angest-Relation
aufsteigend sortiert nach den Werten des Attributs Name aus
SELECT
Name, Wohnort
FROM
Angest
ORDER BY
Name ASC
• Die ASC-Angabe kann weggelassen werden, da Default
• In welcher Reihenfolge erscheinen die Werte
für Wohnort in der Ausgabe?
 unsortiert bzw. „zufällige“ Reihenfolge
Wintersemester 16/17
DBIS
Name
Abeln
Abeln
Dittrich
Dittrich
Dittrich
Kühne
Kühne
Kühne
Wohnort
Karlsruhe
Mannheim
Jena
Augsburg
Zittau
Zwickau
Leipzig
Leipzig
27
SELECT – Beispiele VIII
• Beispiel 6: Erzeuge eine Ausgabe wie bei Beispiel 5, jedoch sollen
innerhalb einer Namensangabe in der Ausgabe die Wohnorte absteigend
sortiert sein
SELECT
Name, Wohnort
FROM
Angest
ORDER BY Name, Wohnort DESC
Name
Abeln
Abeln
Dittrich
Dittrich
Dittrich
Kühne
Kühne
Kühne
Wohnort
Mannheim
Karlsruhe
Zittau
Jena
Augsburg
Zwickau
Leipzig
Leipzig
• Name 1. Sortierkriterium (1. Priorität),
Wohnort sei 2. Sortierkriterium (2. Priorität)
• Reihenfolge der Sortierkriterien in ORDER BY ist wesentlich!
Wintersemester 16/17
DBIS
28
SELECT – Beispiele IX
• Beispiel 7: Gib die Namen aller Angestellten sowie die Summe von
Jahresurlaub und Resturlaub aus, absteigend sortiert nach dieser Summe
(Existenz der Attribute in Angest vorausgesetzt)
SELECT
Name, Jahresurlaub + Resturlaub
FROM
Angest
ORDER BY
(Jahresurlaub + Resturlaub) DESC
SELECT
Name, Jahresurlaub + Resturlaub
FROM
Angest
ORDER BY
2 DESC
• ORDER BY-Klausel erlaubt die Verwendung einer Attributnummer statt eines
Attributnamens (Position des Attributs in der Zielliste)
• Sinnvoll beim Sortieren komplexer arithmetischer Ausdrücke, die auch in der
Zielliste vorkommen (erspart Redundanz!)
Wintersemester 16/17
DBIS
29
SELECT – Beispiele X
• Beispiel 8: Verwendung von eingebauten Funktionen in SQL, vordefiniert
sind u.a. COUNT, SUM, AVG, MIN, MAX (eigene Funktionen ebenfalls
möglich)
• Wieviele Mitarbeiter arbeiten in unserer Firma?
SELECT COUNT(*)
FROM
Angest
• Wieviele Mitarbeiter wohnen in Erfurt?
SELECT COUNT(*)
FROM
Angest
WHERE
Wohnort = 'Erfurt'
Wintersemester 16/17
DBIS
30
SELECT – Beispiele XI
• Wie lautet die maximale Abteilungsnummer?
SELECT MAX(AbtNr)
FROM
Angest
• Wieviel Tage Resturlaub haben alle Mitarbeiter insgesamt noch?
SELECT SUM(Resturlaub)
FROM
Angest
Wintersemester 16/17
DBIS
31
SELECT – Beispiele XII
• Verwendung von eingebauten Funktionen im Zusammenhang mit der
GROUP BY Klausel
• Beispiel 9: Gib eine Liste der Wohnorte zusammen mit dem
durchschnittlichen Resturlaub der Mitarbeiter aus, die jeweils an diesem
Ort wohnen
SELECT
Wohnort, AVG(Resturlaub) AS MittelResturlaub
FROM
Angest
GROUP BY Wohnort
• Durchschnittsbildung (AVG) wird nicht auf die gesamte Angest-Relation
einmal angewandt, sondern jeweils für eine Gruppierung (Mitarbeiter mit
gleichem Wohnort)
Wintersemester 16/17
DBIS
32
SELECT – Beispiele XIII
SELECT
Wohnort, AVG(Resturlaub) AS MittelResturlaub
FROM
Angest
GROUP BY Wohnort
Wohnort
Aachen
Aachen
Berlin
Erfurt
Erfurt
Erfurt
Resturlaub
14
10
8
6
12
9
Wintersemester 16/17
1. Gruppe (AVG = 12)
2. Gruppe (AVG = 8)
Wohnort
Resturlaub
Aachen
12
Berlin
8
Erfurt
9
3. Gruppe (AVG = 9)
DBIS
33
Ausführungsreihenfolge SFW-Anfrage
1. SELECT ... FROM ... WHERE ... (ohne „built-in functions“)
2. GROUP BY ...
3. „built-in functions“ (SUM, AVG, MAX, ...)
4. HAVING
5. ORDER BY
Wintersemester 16/17
DBIS
34
SELECT – Beispiele XIV
• Formulierung von Gruppierungs-Nebenbedingungen / Auswahl
bestimmter Gruppen
• Beispiel 10: Gib eine Liste der Wohnorte zusammen mit dem
durchschnittlichen und gesamten Resturlaub der Mitarbeiter aus, die
jeweils an diesem Ort wohnen, nicht von Beruf Ingenieur sind und dies
nur für Orte mit mindestens 2 Mitarbeitern
SELECT
Wohnort, AVG(Resturlaub), SUM(Resturlaub)
FROM
Angest
WHERE
Beruf <> 'Ingenieur'
GROUP BY
Wohnort
HAVING
COUNT(*)>=2
Wintersemester 16/17
DBIS
35
SELECT – Beispiele XV
• Beispiel 11: Gib mir jenen Angestellten, der den geringsten Resturlaub
aufweist (soll für eine Beförderung vorgeschlagen werden)
• Variante 1
SELECT
*
FROM
Angest
ORDER BY
Resturlaub
• Liefert gesuchten Angestellten als erstes Tupel
• Zusätzlich aber auch alle anderen Angestellten!
Wintersemester 16/17
DBIS
36
SELECT – Beispiele XVI
• Beispiel 12: Gib mir jenen Angestellten, der den geringsten Resturlaub
aufweist (soll für eine Beförderung vorgeschlagen werden)
• Variante 2
SELECT *
FROM
Angest
WHERE
Resturlaub = (SELECT MIN(Resturlaub) FROM Angest)
• Ausdruck in der WHERE-Bedingung (Subquery) liefert einen Wert
• Bezugnahme in der Subquery „zufällig“ auf gleiche Relation wie in der
Anfrage selbst (Angest)
• Vertiefung von Subquery und multirelationale Anfragen folgt noch
Wintersemester 16/17
DBIS
37
SELECT – Beispiele XVII
• Beispiel 13: Formulierung von unscharfen Suchanfragen (pattern
matching), beispielweise:
„Gib mir die Namen der Angestellten, die vom Beruf Tierzüchter sind“
• Variante 1
SELECT Name
FROM
Angest
WHERE
Beruf = 'Züchter'
• Anfrage liefert keinen Treffer, da 'Züchter' <> 'Hundezüchter'
Wintersemester 16/17
DBIS
38
SELECT – Beispiele XVIII
• Variante 2
SELECT Name
FROM
Angest
WHERE
Beruf = 'Hundezüchter'
• Anfrage liefert 2 Treffer, aber andere Tierzüchter fehlen (z.B. Katzen)
• Variante 3
SELECT Name
FROM
Angest
WHERE
Beruf LIKE '%züchter'
• Anfrage sucht in Spalte „Beruf“ nach allen Attributwerten, die auf 'züchter'
enden
Wintersemester 16/17
DBIS
39
Allgemeines zum Vergleichoperator LIKE
• Anwendbar auf CHARACTER-Attribute fester oder variabler Länge
• Zwei Markierungszeichen („wild cards“):
• An der durch % (Prozentzeichen) markierten Stelle können beliebig viele (auch keine!) zu
ignorierende Zeichen stehen
• An der durch _ (Unterstrich) markierten Stelle wird genau ein Zeichen ignoriert
• % und _ dürfen in einem Suchausdruck beliebiger gemischt vorkommen
• Bsp: Wohnort LIKE 'H%b_rg' liefert Treffer bei Hamburg, Hammelburg, Heidelberg, Humburg,
Hbirg - nicht aber bei Hbrg oder Humbug
• Bsp: Name LIKE 'M_ _er' liefert Treffer bei Meier, Maier, Meyer, Mayer, aber auch bei Mauer etc.
• LIKE darf negiert werden (NOT LIKE)
• Bsp: „Gib mir die Namen aller Angestellten, die vom Beruf nicht Tierzüchter sind“
SELECT Name FROM Angest
WHERE
Wintersemester 16/17
Beruf NOT LIKE '%züchter'
DBIS
40
SELECT – Beispiele XIX
• Phonetische Suche (ähnliche Aussprache) ist im SQL-Standard nicht
abgedeckt, aber in Produkten teilweise vorhanden
• LIKE kennt keine Wortgrenzen
• Textsemantik: Wo hört ein Wort auf, wo ein Satz etc.
• Reines „pattern matching“, das den gesamten Character-Attributwert als eine
unstrukturierte Zeichenkette auffasst und durchsucht
• Anfragen der Art „Finde alle Angestellten, wo im Attribut Stellenbeschreibung
das Wort Datenbank auftritt“ nicht so einfach zu stellen
• Realisierung von LIKE durch das DBMS
• Erfordert häufig sequentielle(!) Suche im Datenbestand (tupelweise)
• Lediglich bei Endmarkierung (z.B. 'Datenbank%' oder 'Datenban_') kann
eventuell vorhandener Baum-Index benutzt werden
Wintersemester 16/17
DBIS
41