Objektrelationale und erweiterbare Datenbanksysteme Erweiterbarkeit SQL 1999 Objektrelationale
Objekt-relationale und erweiterbare Datenbanksysteme =Erweiterbarkeit =SQL: 1999 =Objekt-relationale Modellierung
Konzepte objekt-relationaler Datenbanken = Große Objekte (Large OBjects, LOBs) =Datentypen, die es erlauben, sehr große Attributwerte, bspw. Multimedia-Daten, zu speichern. Typische Größe: Gigabyte-Bereich. = Mengenwertige Attribute =Einem Tupel (Objekt) wird in einem Attribut eine Menge von Werten zugeordnet =Damit ist es beispielsweise möglich, der Relation Studenten ein mengenwertiges Attribut Progr. Sprachen. Kenntnisse zuzuordnen. =Schachtelung / Entschachtelung in der Anfragesprache 2
Konzepte objekt-relationaler Datenbanken = Geschachtelte Relationen (NF 2) =Geschachtelte Relationen gehen einen Schritt weiter als mengenwertige Attributen und erlauben Attribute, die selbst wiederum Relationen sind. =Beispiel: Relation Studenten enthält Attribut absolvierte. Prüfungen, unter dem die Menge von Prüfungen. Tupeln gespeichert ist. =Jedes Tupel dieser geschachtelten Relation besteht selbst wieder aus Attributen, wie z. B. Note und Prüfer. = Benutzer-definierte Typen =Objekt-relationale Datenbanksysteme unterstützen die Definition von anwendungsspezifischen Typen – oft userdefined types (UDTs) genannt. =Unterscheidet zwischen wert-basierten (Attribute Type) und Objekt-Typen (Row Type). 3
Konzepte objekt-relationaler Datenbanken = Referenzen = Attribute können direkte Referenzen auf Tupel/Objekte (derselben oder anderer Relationen) als Wert haben. = Zwang zur Nutzung von Fremdschlüsseln zur Realisierung von Beziehungen aufgehoben. = Insbesondere kann ein Attribut eine Menge von Referenzen als Wert haben, so dass man auch N: M-Beziehungen ohne separate Beziehungsrelation repräsentieren kann = Beispiel: Studenten. hört ist eine Menge von Referenzen auf Vorlesungen = Objektidentität = Referenzen setzen natürlich voraus, dass man Objekte (Tupel) anhand einer unveränderlichen Objektidentität eindeutig identifizieren kann = Pfadausdrücke = Referenzattribute führen unweigerlich zur Notwendigkeit, Pfadausdrücke in der Anfragesprache zu unterstützen (implizite (Self-)Joins). 4
Konzepte objekt-relationaler Datenbanken = Vererbung =Komplex strukturierten Typen können Eigenschaften von einem Obertyp erben. =Weiterhin kann man Relationen als Unterrelation einer Oberrelation definieren. =Alle Tupel der Unter-Relation sind dann implizit auch in der Ober-Relation enthalten. =Damit wird das Konzept der Generalisierung/Spezialisierung realisiert. = Operationen =Können Objekttypen zugeordnet werden =Einfache Operationen können direkt in SQL implementiert werden =Komplexere werden in einer Host-Sprache „extern“ realisiert =Java, C, PLSQL (Oracle-spezifisch), C++, etc. 5
Standardisierung in SQL: 1999 = SQL 2 bzw. SQL: 1992 =Derzeit realisierter Standard der kommerziellen relationalen Datenbanksysteme =Vorsicht: verschiedene Stufen der Einhaltung =Entry level ist die schwächste Stufe = SQL: 1999 =Objekt-relationale Erweiterungen =Trigger =Stored Procedures =Erweiterte Anfragesprache = Viele Systeme haben schon ihre eigene proprietäre Syntax (und Semantik) realisiert 6
Große Objekte: Large Objects = CLOB = In einem Character Large OBject werden lange Texte gespeichert. = Der Vorteil gegenüber entsprechend langen varchar(. . . ) Datentypen liegt in der verbesserten Leistungsfähigkeit, da die Datenbanksysteme für den Zugriff vom Anwendungsprogramm auf die LOBs spezielle Verfahren (sogenannte Locator, oft Referenzen in das Dateisystem des OS) anbieten. = BLOB = In den Binary Large Objects speichert man solche Anwendungsdaten, die vom Datenbanksystem nicht interpretiert sondern nur gespeichert bzw. archiviert werden sollen. = NCLOB = CLOBs sind auf Texte mit 1 -Byte Character-Daten beschränkt. Für die Speicherung von Texten mit Sonderzeichen, z. B. Unicode-Texten müssen deshalb sogenannte National Character Large Objects (NCLOBs) verwendet werden = In DB 2 heißt dieser Datentyp (anders als im SSQL: 1999 Standard) DBCLOB -- als Abkürzung für Double Byte Character Large OBject 7
Beispiel-Anwendung von LOBs CREATE TABLE Professoren ( Pers. Nr INTEGER PRIMARY KEY, Name VARCHAR(30) NOT NULL, Rang CHARACTER(2) CHECK (Rang IN ('C 2', 'C 3', 'C 4')), Raum INTEGER UNIQUE, Passfoto BLOB(2 M), Lebenslauf CLOB(75 K) ); • Separater Speicherort für LOBs (hier: Oracle-Syntax): LOB (Lebenslauf) STORE AS ( TABLESPACE Lebensläufe STORAGE (INITIAL 50 M NEXT 50 M) ); 8
Einfache benutzer-definierte Typen: Distinct Types = SQL DBMS unterstützen bereits eine Vielzahl atomarer Datentypen (INTEGER, CHAR, DECIMAL, NUMERIC, …) = Viele Typen in Anwendungen sind jedoch oft spezifischer = Die Modellierung mit vordefinierten Typen kann problematisch sein: SELECT * FROM Studenten s WHERE s. Stundenlohn > s. Vordiplom. Note; =Vergleich bzgl. des Typsystems zulässig (Attribute Stundenlohn und Vordiplom. Note implementiert durch DECIMAL(3, 2)). 9
Einfache benutzer-definierte Typen: Distinct Types = Erzeugung eines benutzer-definierten Typs, der sich 1: 1 auf vordefinierten SQL-Typ abbilden läßt: CREATE DISTINCT TYPE Noten. Typ AS DECIMAL(3, 2) WITH COMPARISONS; =Ein Vergleich von Werten der Typen DECIMAL(3, 2) und Noten. Typ wird durch das Typsystem verboten (distinct type). = Fehlt noch: Zuordnung von Operationen zu Noten. Typ 10
Einfache benutzer-definierte Typen: Distinct Types CREATE DISTINCT TYPE Noten. Typ AS DECIMAL (3, 2) WITH COMPARISONS; CREATE FUNCTION Noten. Durchschnitt(Noten. Typ) RETURNS Noten. Typ SOURCE AVG(DECIMAL()); CREATE TABLE Pruefen ( Matr. Nr INT, Vorl. Nr INT, Pers. Nr INT, Noten. Typ); Explizites Casting INSERT INTO Pruefen VALUES (28106, 5001, 2126, Noten. Typ(1. 00)); INSERT INTO Pruefen VALUES (25403, 5041, 2125, Noten. Typ(2. 00)); INSERT INTO Pruefen VALUES (27550, 4630, 2137, Noten. Typ(2. 00)); SELECT Noten. Durchschnitt(Note) AS Uni. Schnitt FROM Pruefen; 11
Konvertierungen zwischen Noten-Typen CREATE DISTINCT TYPE US_Noten. Typ AS DECIMAL (3, 2) WITH COMPARISONS; CREATE FUNCTION USnach. D_SQL(us US_Noten. Typ) RETURNS Noten. Typ RETURN (CASE WHEN DECIMAL(us) < 1. 0 THEN Noten. Typ(5. 0) WHEN DECIMAL(us) < 1. 5 THEN Noten. Typ(4. 0) WHEN DECIMAL(us) < 2. 5 THEN Noten. Typ(3. 0) WHEN DECIMAL(us) < 3. 5 THEN Noten. Typ(2. 0) ELSE Noten. Typ(1. 0) END); CREATE TABLE Transfer. Von. Amerika ( Matr. Nr INT, Vorl. Nr INT, Universitaet VARCHAR(30), Note US_Noten. Typ); 12
Anwendung der Konvertierung in einer Anfrage INSERT INTO Transfer. Von. Amerika VALUES (28106, 5041, "Univ. Southern California", US_Noten. Typ(4. 00)); SELECT Matr. Nr, Noten. Durchschnitt(Note) FROM ( (SELECT Note, Matr. Nr FROM Pruefen) UNION (SELECT USnach. D_SQL(Note) AS Note, Matr. Nr FROM Transfer. Von. Amerika) ) AS Alle. Pruefungen GROUP BY Matr. Nr 13
Table Functions: Import externer Datenquellen als Tabellen = Erweiterbare SQL-Systeme (hier: DB 2) bieten zusätzlich die Möglichkeit, externe Quellen (etwa Files, Ausgaben anderer Prozesse), in Form von relationalen Tabellen zu importieren. =Eine derartige benutzer-definierte Funktion (table function) liefert damit ganze Tabellen (nicht einzelne atomare Attributwerte) an das SQL-System. =Das Ergebnis eines table function-Aufrufes kann in SQLAnfragen wie eine Relation (oder View) genutzt werden. =Häufige Bezeichnung: wrapper = Beispiel externe Quelle: ASCII-File (CSV: comma separated values) 1, foo <NL> 2, bar <NL> 14
Table Functions: Import externer Datenquellen als Tabellen = Ziel: Import des Ergebnisses einer Web-Anfrage (Suchmaschine) als relationale Tabelle. Table function: Biographien: STRING -> {[ URL: VARCHAR(40), Sprache: VARCHAR(20), Ranking: DECIMAL ]} SELECT bio. URL, bio. Ranking FROM TABLE(Biographien('Sokrates')) AS bio WHERE bio. Sprache = 'Englisch' ORDER BY bio. Ranking; SELECT FROM WHERE ORDER BY prof. Name, bio. URL, bio. Ranking Professoren AS prof, TABLE(Biographien(prof. Name)) AS bio. Sprache = 'German' prof. Name, bio. Ranking; 15
Realisierung (Deklaration) einer Table Function CREATE FUNCTION Biographien(VARCHAR(20)) RETURNS TABLE (URL VARCHAR(40), Sprache VARCHAR(20), Ranking DECIMAL) EXTERNAL NAME '/usr/. . /Wrappers/Biographien. o' LANGUAGE C PARAMETER STYLE DB 2 SQL NOT DETERMINISTIC NO EXTERNAL ACTION FENCED NO SCRATCHPAD NO FINAL CALL CARDINALITY 20; 16
Table Functions: Call Types = Die externe Routine wird vom DBMS mit einem Status-Flag aufgerufen, das anzeigt, wie die Auswertung der umgebenden SQL-Query voranschreitet: =SQLUDF_FIRST =SQLUDF_OPEN =SQLUDF_FETCH =SQLUDF_CLOSE =SQLUDF_FINAL (Routine kann "letztes Tupel" signalisieren) = Dies simuliert das klassische Iterator-basierte Auswertungsprinzip, das die SQL-Engine auch auf ihre internen Operatoren anwendet 17
Uni-Schema voraussetzen Nachfolger Vorgänger Matr. Nr Name Semester N Studenten N N hören M Fachgebiet 1 Assistenten N arbeiten. Für N SWS Titel lesen prüfen Pers. Nr Name Vorlesungen M Note M Vorl. Nr 1 1 Professoren Pers. Nr Name Rang Raum 18
19
Benutzer-definierte Objekt-Typen = Ganz analog zum Objektmodell in OODBMS, akzeptieren SQL: 1999 DBMS die Definition strukturierter Objekte, in denen Daten (Attribute) und Verhalten (Methoden, hier: member functions) gemeinsam deklariert und manipuliert werden CREATE [ OR REPLACE ] TYPE OT AS ( … ); = Weiterhin können Vererbungsbeziehungen (Spezialisierung, Generalisierung) zwischen Objekt-Typen realisiert werden = Das ORDBMS verwaltet Objektidentiät und implementiert Referenzen (REF OT) 20
Objekt-Typ-Definitionen (Oracle) Hier: implementiere die Vererbungsbeziehung Professoren is-a Angestellte noch "manuell" CREATE OR REPLACE TYPE Professoren. Typ AS ( Pers. Nr NUMBER, Name VARCHAR(20), Rang CHAR(2), Raum NUMBER, MEMBER FUNCTION Notenschnitt RETURN NUMBER, MEMBER FUNCTION Gehalt RETURN NUMBER ) CREATE OR REPLACE TYPE Assistenten. Typ AS ( Pers. Nr NUMBER, Name VARCHAR(20), Fachgebiet VARCHAR(20), Boss REF Professoren. Typ, MEMBER FUNCTION Gehalt RETURN NUMBER ) 21
Implementierung der Operationen eines Objekt-Typs CREATE OR REPLACE TYPE BODY Professoren. Typ AS MEMBER FUNCTION Notenschnitt RETURN NUMBER IS BEGIN /* Finde alle Prüfungen des/r Profs und ermittle den Durchschnitt */ END; MEMBER FUNCTION Gehalt RETURN NUMBER IS BEGIN RETURN 1000. 0; /* Einheitsgehalt für alle */ END; 22
Tabellen für Objekt-Typen (Extents) definiert implizit die Spalten der Tabelle CREATE TABLE Professoren. Tab OF Professoren. Typ (Pers. Nr PRIMARY KEY) ; INSERT INTO Professoren. Tab INSERT INTO Professoren. Tab VALUES (2125, 'Sokrates' , 'C 4', 226 ); VALUES (2126, 'Russel' , 'C 4', 232 ); VALUES (2127, 'Kopernikus', 'C 3', 310 ); VALUES (2133, 'Popper' , 'C 3', 52 ); VALUES (2134, 'Augustinus', 'C 3', 309 ); VALUES (2136, 'Curie' , 'C 4', 36 ); VALUES (2137, 'Kant' , 'C 4', 7 ); 23
Objekt-Typ-Definitionen und eingebettete Referenzen (1: n, m: n) Implementiere die Menge der Voraussetzungen einer Vorlesung durch eine eingebettete Tabelle, die Referenzen auf Vorlesungen enthält: CREATE OR REPLACE TYPE Vorl. Ref. Listen. Typ AS TABLE OF REF (Vorlesungen. Typ); / CREATE OR REPLACE TYPE Vorlesungen. Typ AS ( Vorl. Nr NUMBER, Titel VARCHAR(20), SWS NUMBER, gelesen. Von REF Professoren. Typ, Voraussetzungen Vorl. Ref. Listen. Typ, MEMBER FUNCTION Durchfall. Quote RETURN NUMBER, MEMBER FUNCTION Anz. Hoerer RETURN NUMBER ) 24
Tabellarische Darstellung eines Vorlesungen. Typ-Objekts 25
Anlegen der Tabellen(!) für Objekte des Typs Vorlesungen. Typ = Die Voraussetzungen aller Vorlesungen werden in einer geschachtelten Tabelle (Vorgaenger. Tab) aufbewahrt: CREATE TABLE Vorlesungen. Tab OF Vorlesungen. Typ NESTED TABLE Voraussetzungen STORE AS Vorgaenger. Tab; = Das ORDBMS verwaltet dabei automatisch die Beziehung von Tupeln aus Vorgaenger. Tab zum übergeordneten Vorlesungen. Tab. Tupel (s. nächste Folie). =Clustering = Achtung: Hier vermischen sich konzeptuelle und interne Ebene. 26
Tabelle Vorlesungen. Tab und geschachtelte Tabelle Vorgaenger. Tab 27
Einfügen von Vorlesungen. Typ-Objekten INSERT INTO Vorlesungen. Tab SELECT 5041, 'Ethik', 4, REF(p), Vorlesungs. Listen. Typ() FROM Professoren. Tab p WHERE Name = 'Sokrates'; Lokalisiere Professoren-Objekt mittels wert-basiertem Schlüssel INSERT INTO Vorlesungen. Tab SELECT 5216, 'Bioethik', 2, REF(p), Vorl. Ref. Listen. Typ() FROM Professoren. Tab p Leere geschachtelte WHERE Name = 'Russel'; Relation INSERT INTO TABLE (SELECT nachf. Voraussetzungen FROM Vorlesungen. Tab nachf WHERE nachf. Titel = 'Bioethik') SELECT REF(vorg) FROM Vorlesungen. Tab vorg WHERE vorg. Titel = 'Ethik'; 28
Objekt-Typen und tatsächlich eingebettete Objekte (<> Referenzen!) = Zur Modellierung von Aggregationen (sog. Kompositionen) mit =exklusiver 1: N-Zuordnung von Subobjekten =existenzabhängiger Zuordnung (Schachtelung schwacher Entities im übergeordneten Entity) 29
Geschachtelte Objekt-Typen führen zu geschachtelten Relationen CREATE OR REPLACE TYPE Pruefungen. Typ AS ( Inhalt REF Vorlesungen. Typ, Pruefer REF Professoren. Typ, Note DECIMAL(3, 2), Datum DATE, MEMBER FUNCTION verschieben(neuer. Termin DATE) RETURN DATE); CREATE OR REPLACE TYPE Pruefungs. Listen. Typ AS TABLE OF Pruefungen. Typ; CREATE OR REPLACE TYPE Studenten. Typ AS ( Matr. Nr NUMBER, kein REF( )! Name VARCHAR(20), Semester NUMBER, hört Vorl. Ref. Listen. Typ, absolvierte. Prüfungen Pruefungs. Listen. Typ, MEMBER FUNCTION Notenschnitt RETURN NUMBER, MEMBER FUNCTION Summe. Wochenstunden RETURN NUMBER); 30
Anlegen und Bevölkern der Tabelle für Studenten. Typ CREATE TABLE Studenten. Tab OF Studenten. Typ (Matr. Nr PRIMARY KEY) NESTED TABLE hört STORE AS Belegungs. Tab NESTED TABLE absolvierte. Prüfungen STORE AS Examens. Tab; INSERT INTO Studenten. Tab VALUES (24002, 'Xenokrates', 18, Vorl. Ref. Listen. Typ(), Pruefungs. Listen. Typ()); INSERT INTO Studenten. Tab VALUES (29120, 'Theophrastos', 2, Vorl. Ref. Listen. Typ( ), Pruefungs. Listen. Typ()); INSERT INTO TABLE (SELECT s. hört FROM Studenten. Tab s WHERE s. Matr. Nr = 29120) SELECT REF(v) FROM Vorlesungen. Tab v WHERE v. gelesen. Von->Name = 'Sokrates'; 31
Einfügen in geschachtelte Tabellen (Zuordnung Prüfungen/Studenten) INSERT INTO TABLE (SELECT s. absolvierte. Prüfungen FROM Studenten. Tab s WHERE s. Matr. Nr = 29120) VALUES ((SELECT REF(v) FROM Vorlesungen. Tab v WHERE v. Titel='Maeeutik'), (SELECT REF(p) FROM Professoren. Tab p WHERE p. Name='Sokrates'), 1. 3, SYSDATE); INSERT INTO TABLE (SELECT s. absolvierte. Prüfungen FROM Studenten. Tab s WHERE s. Matr. Nr = 29120) VALUES ((SELECT REF(v) FROM Vorlesungen. Tab v WHERE v. Titel='Ethik'), (SELECT REF(p) FROM Professoren. Tab p WHERE p. Name='Sokrates'), 1. 7, SYSDATE); 32
Darstellung der Studenten. Tab ( : Referenzen ) 33
Anfragen auf geschachtelten Relationen SELECT s. Name, p. Note FROM Studenten. Tab s, TABLE(s. absolvierte. Prüfungen) p; NAME NOTE ----------Theophrastos 1. 3 Theophrastos 1. 7 SQL: 1999 (Oracle: '. ') SELECT s. Name, p. Pruefer->Name, p. Inhalt->Titel, p. Note FROM Studenten. Tab s, TABLE(s. absolvierte. Prüfungen) p; NAME PRUEFER. NAME INHALT. TITEL NOTE ------------------------- ------Theophrastos Sokrates Maeeutik 1. 3 Theophrastos Sokrates Ethik 1. 7 34
Vererbung in ORDBMS: Spezialisierung von Objekt-Typen = Implementiere die Spezialisierungsbeziehung zwischen Angestellten und Professoren (Assistenten) = Zunächst auf der Typebene (Substituierbarkeit): CREATE TYPE Angestellten. Typ AS (Pers. Nr INT, Name VARCHAR(20)) NOT INSTANTIABLE; Generelle Angestellte dürfen nicht erzeugt werden CREATE TYPE Professoren. Typ UNDER Angestellten. Typ AS (Rang CHAR(2), Spezialisierung auf Typebene Raum INT); CREATE TYPE Assistenten. Typ UNDER Angestellten. Typ AS (Fachgebiet VARCHAR(20), Boss REF(Professoren. Typ)); 35
Spezializierung und Inklusion von Tabellen CREATE TABLE Angestellten. Tab OF Angestellten. Typ; Inklusion auf Tabellebene CREATE TABLE Professoren. Tab OF Professoren. Typ UNDER Angestellten. Tab INHERIT SELECT PRIVILEGES; CREATE TABLE Assistenten. Tab OF Assistenten. Typ UNDER Angestellten. Tab INHERIT SELECT PRIVILEGES; Die Semantik der Inklusion durch Spezialisierung entspricht damit der folgenden SQL View-Definition: CREATE VIEW Angestellten. Tab AS SELECT Pers. Nr, Name FROM Professoren. Tab UNION ALL SELECT Pers. Nr, Name From Assistenten. Tab; 36
Vererbung in ORDBMS: Einfügungen in "Unterrelationen" INSERT INTO Professoren. Tab (Pers. Nr, Name, Rang, Raum) VALUES (2125, 'Sokrates', 'C 4', 226), (2126, 'Russel', 'C 4', 232), (2137, 'Curie', 'C 4', 7); INSERT INTO Assistenten. Tab (Pers. Nr, Name, Fachgebiet, Boss) VALUES (3002, 'Platon', 'Ideenlehre', SELECT REF(p) FROM Professoren. Tab p WHERE p. Pers. Nr = 2125), (3003, 'Aristoteles', 'Syllogistik', SELECT REF(p) FROM Professoren. Tab p WHERE p. Pers. Nr = 2125), (3004, 'Wittgenstein', 'Sprachtheorie', SELECT REF(p) FROM Professoren. Tab p WHERE p. Pers. Nr = 216); SELECT a. Pers. Nr, a. Name FROM Angestellten. Tab Ergebnis enthält sechs Tupel! 37
Benutzer-definierte Column Types (hier: DB 2 -Syntax) = Benutzer-definierte Objekt-Typen lassen sich auch als Attribute in regulären Tabellen einbetten. =Beispiel: Definiere einen allg. Noten. Typ, leite davon die spezifischeren Typen US_Noten. Typ und D_Noten. Typ ab: CREATE TYPE Noten. Typ AS ( Num. Wert DECIMAL(3, 2), String. Wert VARCHAR(20), Land VARCHAR(20) ); CREATE TYPE US_Noten. Typ UNDER Noten. Typ AS ( With. Honors CHAR(1) ); CREATE TYPE D_Noten. Typ UNDER Noten. Typ AS ( Lateinisch VARCHAR(20) ); 38
Benutzer-definierte Column Types = Es gilt weiterhin das Prinzip der Substituierbarkeit: ein spezifischer Subtyp darf in der Rolle der generellen Typs auftreten: CREATE TABLE Leistungen ( Teilnehmer. In VARCHAR(20), Lehrveranstaltung VARCHAR(20), Noten. Typ ); = Auf die Felder eines strukturierten Column Types wird mittels '. . ' (SQL: 1999: '. ') zugegriffen: SELECT Teilnehmer. In, Lehrveranstaltung, Note. . Land, Note. . Num. Wert FROM Leistungen 39
Benutzer-definierte Column Types (Konstruktoren) = Bevölkern der Tabelle Leistungen und Instantiierung strukturierter Typen (setter-Methoden sind impliziert definiert): INSERT INTO Leistungen VALUES ( 'Feuerbach', 'Java', US_Noten. Typ(). . Land('USA'). . Num. Wert(4. 0). . String. Wert('excellent'). . with. Honors('y') ); INSERT INTO Leistungen VALUES ( 'Feuerbach', 'C++', D_Noten. Typ(). . Land('USA'). . Num. Wert(1. 0). . String. Wert('sehr gut'). . Lateinisch('summa cum laude') ); 40
Test auf dynamische Typen = In SQL: 1999 läßt sich der dynamische Typ eines Ausdrucks mittels IS [ NOT ] OF ( t 1, t 2, … ) testen: SELECT Teilnehmer. In, Note. . Num. Wert FROM Leistungen WHERE Note IS OF ( US_Noten. Typ ); selektiert ein Tupel =Achtung: Note. . with. Honors wäre nicht typkorrekt. (Warum? ) SELECT Teilnehmer. In, TREAT(Note AS US_Noten. Typ). . with. Honors FROM Leistungen WHERE Note IS OF ( US_Noten. Typ ); SELECT Teilnehmer. In, CASE WHEN Note IS OF ( US_Noten. Typ ) THEN TREAT(Note AS US_Noten. Typ). . with. Honors ELSE '? ' END AS Honors FROM Leistungen 41
- Slides: 41