Datenbanktechnologie im Digitalen Produkt
3. Anfragesprache SQL
Um dem operationalen Aspekt zur systemtechnischen Umsetzung und Nutzung der vorgängig diskutierten Datenmodelle Rechnung tragen zu können, wird ein Mechanismus zum Schreiben und Lesen von Objektinstanzen benötigt, eine sogenannte Anfragesprache. Charak-teristisch für semantische Datenmodelle ist, dass sie zwar eine reich-haltige semantische Ausdrucksfähigkeit besitzen, aber leider über keinerlei Anfragesprache verfügen. „Semantische Datenbanksys-teme“ existieren somit nicht.
Seit einigen Jahren sind zunehmend Entwicklungen im Bereich objektorientierter Datenbanksysteme (OODBMS) zu verzeichnen [ABD-89, Dit-92, Dit-95, Nor-93], die ein semantisches Datenmodell unterstützen und zudem eine Anfragesprache besitzen. Objektorien-tierte Datenbanksysteme können daher als systemtechnische Realisie-rung semantischer Datenmodelle angesehen werden. Bis heute weisen OODBMS jedoch noch eine Reihe von Unzulänglichkeiten auf (z.B. Concurrency Control), weshalb sie bislang für den produktiven Einsatz in PLM-Systemen nur sehr selten eingesetzt werden. Als ope-rationales Modell wird daher fast ausschliesslich das Relationenmodell verwendet.
Die genormte relationale Anfragesprache Sprache SQL (Structured Query Language) [ANS-86] hat wesentlichen Anteil am grossen Erfolg des Relationenmodells. Im Gegensatz zur Vorgehensweise herkömmli-cher 3GL-Programmiersprachen (C, Pascal, Fortran etc), die ein proze-durales Navigieren in den Datenstrukturen unter Berücksichtigung physischer Speicherstrukturen erfordern (Programmierer muss sagen wie auf Daten zugegriffen werden soll), benötigt SQL nur noch des-kriptive Angaben (Programmierer muss lediglich sagen, was für Daten abgefragt werden sollen). Das Grundgerüst für Datenbankzugriffe beruht dabei auf der folgenden Syntax:
Aufgrund der vollständigen Datenunabhängigkeit des Relationenmo-dells, sind hierbei keinerlei Kenntnisse über den physischen Speiche-rungsort der Objektdaten erforderlich, d.h. der
Anwendungsprogram-SELECT Spaltenattribute
FROM Tabellenname
WHERE Auswahlbedingung
Tabelle (T008dbtZ) Standard Anfragesyntax
mierer braucht sich darum nicht zu kümmern. Da sich der physische Speicherungsort im Programmcode nicht widerspiegelt, muss derselbe bei Änderungen der physischen Speicherorganisation auch nicht modifiziert werden.
In funktioneller Hinsicht besteht eine Datenbankanfragesprache aus den folgenden beiden Haupt-komponenten:
• Datendefinition (Data Definition Language, DDL),
• Datenmanipulation(Data Manipulation Language, DML).
Die Datendefinition ermöglicht den Aufbau eines Datenbankschemas entsprechend einem vorgängig festgelegten Datenmodellentwurf.
Hieraus folgt eine exakte Definition der Datenstrukturen, die in einer Datenbank abgelegt werden können.
Im Anschluss hieran können einzelne Objektinstanzen (Tupel) mit Hilfe der Datenmanipulation in die Datenbank eingegeben, d.h.
erzeugt werden sowie gegebenenfalls wieder gelesen, modifiziert oder auch gelöscht werden. Grundfunktionen der Datenmanipulation sind somit das Erzeugen, Lesen, Modifizieren und Löschen von Objek-ten (engl. Insert, Select, Update, Delete).
Zur exemplarischen Verdeutlichung sind in Tabelle T005dbtZ einige repräsentative Beipiele für SQL-Statements angegeben, die sich auf das Modellschema in Bild B006dbtZ beziehen.
Aktion SQL-Statement
Tabelle Konstrukteur erzeugen
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 er-zeugen
CREATE TABLE zpedb.Bauteil(
Sachnummer VARCHAR(15) NOT NULL, Benennung VARCHAR(25) NOT NULL, Werkstoff VARCHAR(20),
K# INTEGER,
CONSTRAINT PK_Sachnummer PRIMARY KEY(Sachnum-mer) );
Fremdschlüssel defi-nieren von Bauteil auf Konstrukteur
ALTER TABLE zpedb.Bauteil ADD
CONSTRAINT FK_Konstrukteur FOREIGN KEY (K#) REFE-RENCES zpedb.Konstrukteur (K#) ON DELETE RESTRICT );
Tupel in Konstruk-teur 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‘);
Tabelle (T005dbtZ) Beispiele für SQL-Statements
Die in Tabelle T005dbtZ angeführten SQL-Statements können entwe-der interaktiv abgesetzt oder aber in eine Wirtsprache (z.B. C oder Pascal) eingebettet werden („embedded SQL“). Für Applikationsent-wicklungen ist dies zwingend erforderlich, da SQL als rein deskriptive Datenbankanfragesprache über keine prozeduralen Programmie-rungskonstrukte verfügt (if... then..., repeat... until... etc.). Ein solches C-Programm mit embedded SQL-Statements (Endung *.csql) muss dann zunächst durch Precompilieren in herkömmlichen C-Code über-setzt werden, welcher daraufhin wie ein gewöhnliches Programm noch kompiliert und gelinkt werden muss.
Aufgrund der bereits mehrfach erwähnten Datenunabhängigkeit benötigen SQL-Statements und damit auch embedded SQL-Metho-denprogramme keinerlei Anpassung bei einer Reorganisation der phy-sischen Speicherungsstruktur einer Datenbank (z.B. Hinzufügen/
Wechsel einer Disk hat keinerlei Einfluss auf SQL-Statements, da diese keine Zugriffspfade beinhalten, vgl. Tab. 3.3).
Das Konzept des dynamischen SQL ermöglicht eine effiziente Pro-grammentwicklung sowie eine grösstmögliche Flexibilität für die Anwendung. Zum Zeitpunkt der Programmentwicklung müssen hier-bei die Argumente für die SQL-Statements (Spaltennamen, Tabellen-namen, Auswahlbedingungen etc.) noch nicht bekannt sein und
Tupel in Bauteil ein-fü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‘, ‚Schaltgetrie-be‘, ‚-‘, 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‘, ‚Getriebe-flansch‘, ‚ST37‘, 2);
Tupel von Bauteil anzeigen
SELECT * FROM zpedb.Bauteil;
Konstrukteure der Abteilung ZPE anzei-gen
SELECT NAME FROM zpedb. Konstrukteur WHERE Abtei-lung = ‚ZPE‘;
Bauteil-Tupel anzei-gen, die von Kon-strukteur Müller stammen (Join-Ab-frage)
SELECT (Sachnummer, Benennung, Werkstoff, K.Name) FROM zpedb.Bauteil B, zpedb.Konstrukteur K WHERE B.K#
= K.K# AND Name = ‚Müller‘;
Tupel löschen DELETE FROM zpedb.Bauteil WHERE Benennung = ‚Motor‘;
Aktion SQL-Statement
Tabelle (T005dbtZ) Beispiele für SQL-Statements
angegeben („hart codiert“) werden, sondern können - ähnlich einer Programmvariablen - erst zur Laufzeit spezifiziert werden.
Als Beispiel sei die in Tabelle T005dbtZ angeführte Abfrage aller Konstrukteure der Abteilung ‚ZPE‘ genannt, wo mit dynamischem SQL der Wert ‚ZPE‘ nicht als Wert ins Programm codiert werden muss, son-dern eine Variable definiert wird. Dieser Variable kann dann zur Lauf-zeit durch Benutzereingabe der Wert ‚ZPE‘ zugewiesen werden oder auch ein abweichender Wert, wie z.B. ‚ETH‘, wodurch das einmal pro-grammierte SQL-Statement für mehrere verschiedene Abfragen nutz-bar wird.
In vielen Fällen erfordern Benutzerzugriffe tabellenübergreifende bzw. tabellenverknüpfende Datenbankabfragen, die als Verbundope-rationen (engl. Join) bezeichnet werden und häufig mittels dynami-schem SQL implementiert werden. Hierbei müssen zwei Arten von Join-Operationen unterschieden werden, die in der Regel erheblich voneinander abweichende Ergebnisse liefern:
Bild B010dbtZ und Bild B011dbtZ verdeutlichen den prinzipiellen Unterschied beider Join-Arten anhand dem Anwendungsbeispiel in Bild B006dbtZ. In der überwiegenden Mehrzahl der Fälle wird der Grund für einen Join in einer Fremdschlüsseldefinition begründet sein, die aufgrund ihrer Semantik fast immer eine Abfrage mittels natürli-chem Verbund bedingt.
kartesisches Produkt Tabellen werden ungeachtet von Attributwerten miteinan-der „multipliziert“, wodurch sich die resultierende Tupelzahl aus dem Produkt der Tupel sämtlicher beteiligter Tabellen er-gibt
natürlicher Verbund Tabellen werden über Wertegleicheit von Partnertupeln mit-einander „verbunden“, wodurch sich die resultierende Tu-pelzahl immer kleiner oder höchstens gleich der höchsten Tupelzahl der beteiligten Tabellen ergibt.
Tabelle (T006dbtZ) Zwei Arten von Join-Operationen
Bild (B010dbtZ) Tabellen-Join als kartesisches Produkt
Bild (B011dbtZ) Tabellen-Join als natürlicher Verbund
ZPE SELECTSachnummer, Bennenung, Werkstoff, Name, Abteilung FROMBauteil, Konstrukteur
WHERESachnummerLIKE'470' Ergebnis:
Tabellen-Join als kartesisches Produkt (jeder mit jedem)
Sachnummer Benennung Werkstoff 470-000 000.001
Tabellen-Join als natürlicher Verbund (nur Partnertupel mit entsprechendem Referenzwert)
Sachnummer Benennung Werkstoff 470-000 000.001
SELECTSachnummer, Bennenung, Werkstoff, Name, Abteilung FROMBauteil, Konstrukteur
WHERESachnummerLIKE'470'ANDBauteil.K#=Konstrukteur.K#
3.1. Triggerfunktionalität von SQL
Die modellinhärenten Integritätsbedingungen des Relationenmodells in Tabelle T002dbtZ werden wie bereits erwähnt vom Datenbanksys-tem automatisch sichergestellt. Für den Fall, dass eine der Integritäts-bedingungen verletzt werden sollte, muss das Datenbanksystem geeignete Gegenmassnahmen treffen.
Eine Verletzung der Eindeutigkeit von Primärschlüsselwerten (Entity Integrity) muss von Beginn an unterbunden werden, so dass Insert- oder Update-Versuche mit derartigen Konsequenzen prinzipiell immer fehlschlagen müssen.
Sollte jedoch die Referential Integrity verletzt werden (durch Löschen oder Modifizieren eines referenzierten Parent-Tupels), kann von seiten der Anwendung ein unterschiedliches Verhalten wün-schenswert sein. Anhand sogenannter Trigger lässt sich dies für Fremdschlüsseldefinitionen definieren, wobei gemäss Bild B012dbtZ drei Möglichkeiten bestehen.
Bild (B012dbtZ) Triggermöglichkeiten einer Fremdschlüsseldefinition
Als Default für Fremdschlüsseldefinitionen verwenden Datenbanksys-teme in der Regel den Trigger ON DELETE RESTRICT, der sich für sämt-liche Beziehungen anbietet. Für Spezialisierungen (is_a-Beziehungen) ist dagegen häufig ON DELETE CASCADE vorzuziehen.
Vorteilhaft an solchen Triggerdefinitionen sind nicht nur die Verein-fachungen für den Applikationsprogrammierer, sondern auch die dar-aus resultierende grössere Integrität des Datenbankschemas.
Sachnummer Benennung Werkstoff 470-000 000.001
K# Name Abteilung 1
Child Tabelle Parent Tabelle