Vorlesung X - 04.05.01 - isabel
Werbung
Einführung in Datenbanken Semester: IV HTWM (Hochschule für Technik und Wirtschaft Mittweida – University of applied sciences) Fach: Datenbanken I Semester: 4 Vorlesender: Prof. Stübner Datenbanken I Seite Autor: Drost, Isabel (if99p1) 1 Einführung in Datenbanken Semester: IV Vorlesung X - 04.05.01 ............................................................................................................4 The Check Constraint: ...................................................................................................................... 4 The Unique Key- Constraint ............................................................................................................. 4 The PrimaryKey – Constraint: ......................................................................................................... 4 The ForeignKey – Constraint: .......................................................................................................... 4 Conclusion: ......................................................................................................................................... 4 Selbstreferenzierung:......................................................................................................................... 5 Constraint hinzufügen:...................................................................................................................... 5 Constraint löschen: ............................................................................................................................ 5 Constraint Stati:................................................................................................................................. 5 Disabling Constraints: ..................................................................................................................................... 5 Enable Constraints:.......................................................................................................................................... 5 Exceptions Tabelle nutzen:................................................................................................................ 5 Deferred Constraints (aufgeschobene Constraints):....................................................................... 6 Circular References: .......................................................................................................................... 6 DML-Methoden: ................................................................................................................................ 6 Constraint – Informationen holen:................................................................................................... 6 Constraint Typen: .............................................................................................................................. 6 Transactions – ACID Prinzip....................................................................................................7 DatenbankTransaktionen.................................................................................................................. 7 How to Survive in a RDB ..........................................................................................................9 Die Semantik der Datenbank:........................................................................................................... 9 Problem Lösen: ................................................................................................................................ 10 Das data dictionary – ein Tool für Profis....................................................................................... 10 Codds 12 Regeln ............................................................................................................................... 10 Normalisierungstheorie...........................................................................................................12 Zweck: ............................................................................................................................................... 12 Mutationsanomalien ........................................................................................................................ 12 Probleme bei normalisierten DB..................................................................................................... 14 Extreme bei der Normlisierung ...................................................................................................... 14 Empfohlene Vorgehensweise........................................................................................................... 14 Zusammenfassung:..................................................................................................................14 Relationales Modell.......................................................................................................................... 14 Praktischer Aspekt ...................................................................................................................14 Vom Problem zur Query ................................................................................................................. 14 Interpretation ................................................................................................................................................. 15 Transformation .............................................................................................................................................. 15 Formalisierung............................................................................................................................................... 15 SQL - Text..................................................................................................................................................... 15 Seite Autor: Drost, Isabel (if99p1) 2 Einführung in Datenbanken Semester: IV Testphase ....................................................................................................................................................... 15 Seite Autor: Drost, Isabel (if99p1) 3 Einführung in Datenbanken Semester: IV Vorlesung X - 04.05.01 The Check Constraint: • • condition, die jede Zeile erfüllen muß Nicht erlaubt sind: - Referrenzen zu Pseudospalten (Currval, nextval, Lvl, Rownum) - Referrenzen zu Sysate, uid, user, userenv – Funktionen - Queries, die sich auf Inhalte anderer Spalten beziehen The Unique Key- Constraint (CanditateKey) Ist der PrimaryKey als Identifikator/ ForeignKey schon vergeben, kann ich einen UniqueKey verwenden. • • auf Table- oder auf SpaltenLvl. Zu definieren create table [ ... ] constraint dept_dname_uk UNIQUE (dname); The PrimaryKey – Constraint: • • • • • Wirkung entspricht der von Unique Frei ausgewählter Schlüssel Kann unmittelbar auf die Spaltendef. Folgen, wenn es sich nur um eine Spalte handelt Kombinationen von Spalten möglich Create table [ ... ] Constraint dept_deptno_pk Primary Key(deptno) The ForeignKey – Constraint: • • • • • • PrimaryKey kann in fremder Tabelle als ForeignKey eingesetzt werden, z.B. zum Verbinden zweier Tabelle Es kann dann in jener Spalte keine Einträge geben, die es in der Elterntabelle nicht als PrimaryKey gibt Create table [ ... ] Constraint emp_deptno ForeignKey (deptno) References dept (deptno)); ForeignKey – Definiert die Spalte in der Kindtabelle, auf tableConstraintLvl Referenz – Identifiziert Elterntabelle und Spalte On Delete Cascade: Lösche ich Eltern, fliegen auch Kinder weg Conclusion: 1. 2. 3. ChildTable wird nach Parent kreiert Parent wird NACH Child gelöscht Key im Parent können nicht verändert/ gelöscht werden, solange sie noch im Kind referrenziert werden Will ich in der ElternTabelle nur den Inhalt/ die Referrenzen ändern will: ForeignKeys ausschalten Bei Manipulationen Locks der Kindtabellen vermeiden. Bei Manipulationen am Kind muß Parent online sein. Prozeduraler Test: Habe ich keine ForeignKeys, kann ich die Integrietät periodisch checken: Select *from emp Where deptno not in (Select deptno From dept); Seite Autor: Drost, Isabel (if99p1) 4 Einführung in Datenbanken Semester: IV Selbstreferenzierung: ForeignKey kann sich auf PrimaryKey der eigenen Tabelle beziehen, z.B. emp(mgr)=emp2(empno) • dabei muß aber eine bestimmte Reihenfolge beim Einfügen eingehalten werden Constraint hinzufügen: Siehe Folien Constraint löschen: • • Nur den Constraint löschen: - über alter table [tablename] Drop Constraint [ConstraintName] Gesamte Tabelle mitsamst referenzierten foreignKeys löschen: - über Drop table [tablename] cascade Constraints; Constraint Stati: Disabled Enabled novalidate Enabled validate DB DB DB Disabling Constraints: • • • • gehört in den alter table Befehl erst foreignKeys, dann PrimaryKeys ändern - alter table [tablename] disable Constraint [constraintname] Cascade; UniqueIndexes dropped, nonunique ones nicht Keys werden über Indexes abgehandelt Nonunique brauchen für Performancezwecke nicht weggeworfen werden PerformanceTip: erst KeyCheck ausschalten, alles einfügen,dann Check über gesamte Tabelle durchführen – Suche wird nicht bei jedem Einfügen durchgeführt Enable Constraints: • • • • EingabeCheck, Eingabe- und New Data nicht Inhalts- Inhaltscheck check Via alter table ... enable Constraint ... Indexe werden beim Einschalten der Constraints „PrimaryK“ und „ „ automatisch angelegt enable validate: - Folge: Tabelle wird gelockt - Arbeit mit Unique (Daten müssen widerspruchsfrei sein) oder nonunique Index enable nonvalidate: - nur wenn ich mir sicher bin, dass die eingegebenen Daten widerspruchsfrei sind - Tabelle wird nicht gelockt - Performancekritische Entscheidung zwischen validate und nonvalidate Exceptions Tabelle nutzen: 1. 2. 3. Kreieren der Tabelle (Scriptname: utlexcpt.sql) Alter table mit exceptionClause ausführen ... Seite Autor: Drost, Isabel (if99p1) 5 Einführung in Datenbanken Semester: IV Deferred Constraints (aufgeschobene Constraints): Nondeferred: sofort ausgeführt, jede Datenmanipulation wird sofort gecheckt Deferred: später, wenn Transaktion beendet ist • Arbeit beim Einfügen, Ändern mit dem Aus-/ Einschalten der Constraints wird abgenommen • Ist Constraint nicht korrekt im Ergebnis: Rollback Circular References: Referenzen von einer Tabelle auf eine andere und zurück DML-Methoden: 1. 2. 3. 4. disable/ enable Dummy Objects verwenden (unsauber) Deferred (zu bevorzugen) On delete cascade (lösche Kinder mit den Eltern) Um tables zu löschen, muß ich erst deren Constraint ausschalten, ansonsten brauche ich eine Art Cascade. Constraint – Informationen holen: • • • • • aus Datadict darin gibt es eine Constraintstabelle -> tabellenweise ziemlich umfangreich Select Constraint_name, constraint_type search_conditions Frome user_constraints Where table_name=‘emp‘ (Constraints angucken) colums zu constraints angucken: Select constaint_name, column_name from user_cons_columns where table_name=‘emp‘ Ergibt Relation: Pfeil zwischen zwei Tabellen Constraint Typen: • • • • • Check, not Null PrimaryKey ForeignKey Unique Views – with check option Seite Autor: Drost, Isabel (if99p1) 6 Einführung in Datenbanken Semester: IV Transactions – ACID Prinzip • • • • Atomar: entweder alles oder nix Konsitenz: gehe von einen konsitenten in den nächsten konsitenten Zustand über Isolation: Läuft isoliert von anderen zugreifenden Transaktionen (bei gleichzeitigen Transaktionen dürfen diese sich gegeseitig nicht beeinflußen – sie laufen also nacheinander ab) Dauerhaftigkeit – das was in der Transaktion geändert wurde, überlebt (auch einen Rechnerabsturz – Realisierung: Transaktion ist abgeschlossen, wenn sie auf die Platte geschrieben wurde, allerdings ins Rollbacksegment von Oracle, bei Rechnerneustart wird das was dort steht, zurückgeholt) DatenbankTransaktionen • Beinhalten: - DML statements die eine konsitente Datenveränderung vornehmen - Einem DDL-statement - Einem DCL-statement • Beendet durch: - Commit, Rollback - DDL oder DCL statement wird ausgeführt (automatischer commit) - errors, exit (=logout), system crash • Vorteile von Comit und Rollback: - stellen Datenkonsitenz sicher - Datenveränderungen vorher angucken, bevor die Änderungen permanent gemacht werden - logisch zusammengehörige Befehle werden zusammengefasst • Transaktionen kontrollieren: - erfolgt über savepoints, zu denen ich zurückhüpfen kann Transaktion insert commit update savepoint a insert delete savepoint b • Implizites Transaktionen: - automat. commit: DDL – statement DCL – statement (Datacontrol, z.B. Passwortänderung) Exit z.B. von SQL+ - abnormaler Ablauf (abnormales Beenden vonn SQL+, systemFehler ...) • state of a data bbefor commit oder Rollback: - Datenbank wird gepuffert > Rollback ist möglich - Select statement nutzen, um die Resultate der DML – Ops zu kontrollieren - Andere User können nich sehen, was ich ändere, bevor ein commit abgeschickt wurde - Bestimmte Zeilen werden für’s Editieren durch andere Nutzer gelockt Seite Autor: Drost, Isabel (if99p1) 7 Einführung in Datenbanken Semester: IV • Datastate after commit - Datenänderungen permanent gemacht - verheriger Datenbankstatus verloren - alle User sehen die Ergebnisse - Locks auf bestimmte Zeilen werden freigegeben (les- / änderbar) - Savepoints werden auch verworfen Transaktionen/ Locks beziehen sich nicht auf den Nutzer, sondern auf seine Session, locke ich mich also zweimal ein, sind beide Fenster völlig unabhängig voneinander somit werden Änderungen auch dann erst sichtbar, wenn ich ein commit gebe • state of data after Rollback - datenänderungen rückgängig gemacht • Arbeit mit einem Savepoint - Savepoint [name] erstellt savepoint - Roll back to [savepoint] geht dahin zurück - geht nur eine DML schief, kann ich mit Rollback einen Schritt zurückgehen - Oracle8 implementiert einen impliziten Savepoint - alle anderen Änderungen bleiben erhalten • Konsitenz beim Lesen - garantiert konsitenten Blick auf die Daten (solange ich am Ändern bin, sieht es der andere nicht) - Änderungen von einem User dürfen nicht mit den Änderungen eines anderen Users in Konflikt stehen - Leser warten nicht, bis der Schreiberling fertig ist - Schreiberlinge warten nicht auf die Lesenden • Anomalien - dirty read: Scott gibt Bond ein – King liest und sieht Bond – Scott gibt rollback – King sucht Bond (Bei Oracle nicht möglich, da Änderung sichtbar, wenn commit - non – repeatable read king liest king aus – scott feuert king – king findet king nicht mehr -> findet den King nicht mehr Vermeiden von non-repeatable read: king lockt die table im exklusiven Modus – Scott kann king noch nicht löschen – erst wenn King sein commit gibt, kann Scott die Änderung vornehmen - Phantom Scott will gucken,ob emp# schon vergeben – ist sie nicht – in der Zwischenzeit greift sich die 7 – Update von Scott seiner Seite nicht mehr möglich Besser: lock table emp in exclusive mode; <is empno 7 frei> <insert with 7>; Jetzt kriegt King die Fehlerausschrift, dass die 7 nicht mehr da ist: Scott war eher da • Locking - verhindert, dass sich einzelne Transaktionen gegenseitig beeinträchtigen - normal vom System ausgeführt - nutzen automatischerdings das niedrigste Lvl. an Restriktionen - werden während der Dauer der Transaktion gehalten (commit setzt sie zurück) - Zwei Basismodi: exclusive (es kann nicht gelesen werden), shared (lesen aber nicht schreiben, schneller, kann tlw. zu Problemen führen) Deadlocks können produziert werden. Am einfachsten erkennt dies das System anhand eines Timers. Kommen bestimmte Prozesse über längere Zeit nicht voran, so werden alle beteiligten geschlachtet und assynchron gestartet. Vermeidung auch aufgrund von Reihenfolgen: habe ich Tabelle a noch nicht, kriege ich b auch nicht ... Wird kritisch bei verteilten Systemen (is datt nu ein Deadlock, oder is nur das Netz mal wieder lahm???) • DML: Insert, update, delete Seite Autor: Drost, Isabel (if99p1) 8 Einführung in Datenbanken Semester: IV (vorsicht – klausur) How to Survive in a RDB Wie finde ich die Karte zu Datenbank – das relationale Diagram Komponenten: Entities Attribute Relationships 1) Select * From cat; ergibt die Entities (die Tabellen) 2) DESC emp ...; oder Select * from emp; ergibt Attribute zu den Tabellen 3) Das eigentliche Problem sind die Relationships – semantische Lücke Suche Beziehung zwischen Primärschlüssel/ CandidateKey und Foreign Key 1. Gucke Dir Constraints an, wenn welche definiert wurden (im Datadictionary -> select * from dict; - ziemlich umfangreich) Hinweis: 3 Kategorien (ALL_ / DBA_ / USER_) existieren User ist das, was mir gehört, all zusätzlich das, was ich geerbt habe Ich habe aber nur meinen Account, nicht den vom Besitzer -> suche also unter all. Select *from dict whre table_name like ‚ALL_CONS%‘; für die Constraints Select * from ALL_Constraints um die Constraints herauszufinden Hinweis: wähle über die Where-Klausel genauer aus, z.B. where c=r (Constraintstype = foreignKey) lass Dir so wenig wie nötig ausgeben 2. Informelle Beschreibung: Select * from all_tab_comments; Select * from all_column_comments; ergibt Wissen über die Tabelle von außerhalb, z.B. über die Kommentare in der Tabelle 3. Syntaktische Analyse 1. Keys sind für gewöhnlich NOT NULL 2. artificial Keys sind meist nützlicher (laufende Nummern etc.) 3. Related attributes sollten den gleichen Datentyp haben 4. meist sind verbundene Attributenamen ähnlich oder gar gleich 5. Die Attribute sollten in gewissen Grenzen die gleichen Daten beinhalten 6. Die zur Verbindung genutzten Attribute sollten aus verschiedenen Spalten stammen und passende Daten enthalten. Die Semantik der Datenbank: • • • • Zeichen einer Datenbank sind lediglich syntaktisch will ich die Datenbanksemantik verstehen, brauche ich ein Stück menschl. Verstand, Logik und Erfahrung Ich muß davon ausgehen können, dass die Information, die ich suche, auch in der DB steht entspricht eine DB dem Stand der Kunst, enthält sie keine Redundanz • • • • Wir müssen die Information, die wir suchen exakt an einer bestimmten Stelle stehen Kann ich zu jenem Zeitpunkt, den Zweck der DB zu erkennen? Kann ich zu ihr selber Aufgaben stellen? wenn ja – habe ich die DB verstanden. Seite Autor: Drost, Isabel (if99p1) 9 Einführung in Datenbanken Semester: IV Problem Lösen: • • • • • Vorbedingung: Kenntnis von SQL (z.B. über entsprechende Aufbereitung von Bsp.Abfragen) Wichtiges in den Aufgaben unterstreichen. Eliza-Technik (nach J. Weizenbaum – Psychaterprogramm): ich kriege nur Aufgaben, die mit der DB lösbar sind Mache Dir eine Vorstellung davon, wie das Ergebnis aussehen muß (Wie heißen die Spaltennamen? Wieviele Spalten brauche ich? Brauche ich ein Order By oder ähnliches?) Syntaktische Analyse: - Select *From cat; (mache Dir ein Bild von dem Teil der DB, den Du brauchst) - Select *From <interessting table>; - Guck, ob Du Keys findest – vor allem künstliche, was könnte ein foreign/ primaryKey sein? Diese erkennt man z.B. am NOT NULL, Primaries liegen meist an erster Stelle in der Tabellendefinition. Zahlen deuten auf künstliche Schlüssel. Bei PrimaryKeys sind alle Werte unterschiedlich – unique Index deutet auf Unterschiedlichkeit hin. - ForeignKeys meist ebenfalls NOT NULL und in Form einer Zahl. Wo zeigt er hin? (anhand von Kommentaren oder sich die Tabellen angucken oder als Vermutung ergründen, diese anhand - übereinstimmender Datentypen nachweisen. - Weiterhin: Select empno from emp; Select repid from customer; - stimmen sie überein. - Select repid form customer where repid not in (select empno From emp); -> gibt es Fremde IDs in emp, die es in customer nicht drinstehen.) - (select job From emp, customer whrere empno=repid;) – durch wen werden die Kunden betreut? Duch Salesperson. - Guck in die Kommentare Select *from all_call_comments where table_name=‘customer‘; und suche in all nach all dem, was dem owner gehört (where owner=‘ ...‘;) Das data dictionary – ein Tool für Profis • • • Select *from all_constraints Where table_name=‘interestingTable’ and owner=‘interestingOwner‘ and Constraint in ‚R,P‘; Problem dabei sind Constraintnamen, die vom System vergeben wurden (z.B.: Customer_FK:sys_c001662) Select *from all_cons_columns whrer constraint_name=‘sys_c001662‘; um wirklich nachzuweisen, wohin dieser ForeignKey (FK) zeigt. (hier z.B. emp(empno)=repid) Ergebnis: Wir haben die repid – die Informationen über den Salesperson liefert und mir sagt, wer wen betreut. Außerdem haben wir die CustomerID, die mit der RepID übereinstimmt. Was wir noch brauchen könnten die Bestellungen sein. Es muß also noch eine Tabelle für die Bestellungen geben. (z.B. ord) Dort gucke ich mit Desc ord, wie die Tabelle aussieht, dadrin habe ich auch eine custID (eine ID des Käufers) und einen Preis des Produktes. Resultatselect: select custid, sum(total) from ord goup by custid; -> Verkäufe pro Kunde select repid, sum(total) from ord o, customer c where o.custid=c.custid group by repid; -> Verkäufe pro salesman select empno, ename, sum(total) from emp, customer c, ord o where empno=repid and c.custid=custid group by empno, ename order by 3 Desc -> Verkäufe pro salesman, geordnet nach Verkäufen, Namen der Salespersons werden mit ausgegeben Codds 12 Regeln • Ausgangspunkt ist die Forderung, dass jedes DBMS, das behauptet relational zu sein, die gesamte Dabenbank wie im relationalen Modell spezifiziert, verwalten muß (z.B. mengenbasierter Zugriff) 1) Informationsregel: Jede Infromation in einer relationalen DAtenbank wird ausschließlich auf einer logischen Ebene und in genau einer Weise – durch Werte in Relationen – dargestellt. Seite 10 Autor: Drost, Isabel (if99p1) Einführung in Datenbanken Semester: IV 2) Garantierter Zugriff Jedes einzelne Datum (atomarer Wert) in einer relationalen DAtenbank ist immer durch eine logische Kombination aus Relationsnamen, Primary Key und Spaltenname selektierbar. 3) Systematische Behandlung fehlender Informationen (Nullwerte) In einem relationalen System werden unabhängig vom Datentyp Indikatoren untersttzt, die auf einer logischen Ebene fehlende Inforamtionen repräsentieren. Diese Indikatoren sind verschieden von der leeren ZK oder einer ZK aus Leerzeichen un verschieden von Null oder irgendeiner Zahl. 4) Ein Onlinekatalog/ Data Dictionary Die Beschreibung der DB (Meta – Daten) erfolgt auf log. Ebene, genau wie die Darstellung gewöhnlicher Daten, so dass autorisierte Benutzer genau dieselbe Abfragesprache zu rUntersuchung dieser Daben auch bei regulären Daten anwenden können - > DB verwaltet sich selbst. Bei Oracle stehen die Informationen in sog. SYS-tables, diese sehe ich nur, wenn ich als Sys eingeloggt bin. Haben als Anhang ein $ hinter dem Vorsatz 5) Allumfassende Sprache: Ein rlat. DBMS muß zumindest eine Sprache unterstützen, wobei: a) Statements über eine wohldef. Syntax in Form von Zeichenketten auszudrücken sind (keine graphische Manipulation, dabei gibt es aber immer Befehle, die graph. nicht machbar sind (entweder äußerst umständl. oder einige Befehle sind nicht ausführbar) b) allumfassend, indem sie folgendes erfüllt: - Daten Definition - ViewDefinition - DatenManipulation (interaktiv/ Programme) - Integritätsregeln - Autoriesierung - Transaktionspakete (commit/ rollback) 6) Datenänderung durch Views: Das DBMS enhält einen Algor., der mind. so leistungsfähig ist, wie VU-1alpha (das, was Codd selber konnte) um zum Def. zeitpkt. einer einfachen View festzulegen, ab es in dieser View eerlaubt ist, Tupel einzufügen oder zu löschen, und welche Spalten verändert werden dürfen. Das Resultat dieser Untersuchung wird im SystemKatalog abgelegt. In diesem Sinne sind alle heutigen DB nicht relational. 7) High Level insert, update und delete: Die Fähikeit, eine BAsis-Op oder eine Erg.-Relation wie einen einfachen Operanden zu handhaben, trifft nicht nur für das Selektieren von Daten, sonder nach für das Einfügen, Ändern und Löschen von Daten zu. (create table auf Basis eines Selects aus der alten DB) 8) Physische Datenunabhängigkeit: Anwendungsprogramme und anwenderoberfläche bleiben logisch unbeeinträchtige, wenn Veränderungen an der Speicherstrucktur oder der Zugriffsmehode vorgenommen werden. (Oberfläche hat nix mit der darunterliegenden HW zu tun) 9) Logische Datenunabhängigkeit: Anwendungsprogramme und Anwenderoberflächen bleiben logisch unbeeinträchtigt von intformationserhaltenden Veränderungen and en Basisrelationen, wenn es thoretisch mögich ist, diese Unabhängikeit zu gewährleisten -> Views 10) Integritätsunabhängigkeit Inte.bedingungen, die spezifisch für eine DB sind, müssen mit Hilfe der realtionalen Datenbeschreibungssprache definierbar und im System-Katalog (nicht in den Anwendungsprog.) abgelegt sind. (Grund für Verstöße: Geschwindigkeit, Nichtdefinierbarkeit der Integritäten in SQL) Seite 11 Autor: Drost, Isabel (if99p1) Einführung in Datenbanken Semester: IV 11) Verteilungsunabhängigkeit Ein relationales DBMS ist verteilungsunabhängig. Schneide die DB in bestimmte Teile und lege diese auf verschiedenen Servern ab. Diese Verteilung geht dabei soweit, dass ich Teile von Tabellen aufteile (z.B. emp nach departments aufteilen; oder bestimmte Spalten von Tabellen kommen an verschiedene Server, dabei muß aber jeder Teil den PrimaryKey haben) 12) Unterwanderungsverbot: Fall ein realtionales System über eine „low-level“-Sprache (ein Datensatz zu einem Zeitpunkt, z.B. C++), so kann diese „low-Lvl“-Sprache nicht dazu benutzt werden, die in der „high-Lvl“-Sprache (mehrer Datensätze zu einem Zeitpunkt, z.B. SQL) ausgedrückten Integritätsregeln und Constraints zu verletzen oder zu umgehen. (dBase wäre in diesem Sinne nicht mehr relational) Normalisierungstheorie [lat. Norma=Winkelmaß] Zweck: • • • Vermeidung von Redundanz und Mutationsanomalien (=Redundanz) soweit wie möglich Längere Lebenszeit des DB-Modells Besseres Verständnis des log. Modells (für Außenstehende und Zugreifende) Mutationsanomalien • • Logische Redundanz Mutaions Anomalie: unnormale Behandlung von Daten bei deren Veränderung oder Löschung Beispiel: - Insert-Anomlie Bei einer Buchausleihe werde die Tel.nummer mit erfasst (zusätzlich zu UserID, Signatur). Folge ist, ich gehe zu Ausleihe, lege das Buch vor und muß außer Signatur die Telefonnummer mit angeben, Schwierigkeit ergibt sich, wenn ich meine Telefonnummer nicht kenne. - update-Anomalie Ändert sich die Telefonnummer, müssen alle betroffenen Ausleihen geändert werden. Läßt sich noch mit einem updateBefehl machen, ist aber nicht anhand der Zeilenanzahl prüfbar: diese hängt davon ab, wieviele Bücher ich ausgeliehen habe. - delete-Anomlie Bei der Rückgabe der letzten entliehenen Bücher geht die Information über die Telefonnummer wieder verloren. Ergibt zusätzliche Arbeit und Verwirrung und Fehlern, die ich nicht so schnell mitkriege und beseitigen kann. Seite 12 Autor: Drost, Isabel (if99p1) Einführung in Datenbanken Semester: IV FreitagsVO – Normalisierung Seite 13 Autor: Drost, Isabel (if99p1) Einführung in Datenbanken Semester: IV Probleme bei normalisierten DB • • • extreme Normlaisierung (BinärRelation) macht das Datenmodell unlesbar Viel Join – wenig Performance (Randbemerkung: Joins via MergeSort implementiert) Verlust semantischer Details (ich habe zwei Tabellen – gehören sie zusammen? Wenn ja, wie gehören sie zusammen? Dieses Problem tritt vor allem bei Normalisierung, sprich Trennung der Tabellen auf.) Extreme bei der Normlisierung • Binärrelation • Universalrelation Beide Gegensätze sind nicht emphelenswert. Empfohlene Vorgehensweise • • Normalisierung soweit wie möglich, Ergebnis ist das logische Schema. tritt ein merklicher Geschwindigkeitsverlust auf, nimm Normalisierungen zurück, bis die gewünschte Rechenzeit erreicht ist. Prüfe mit jedem neuen System nach, ob Du nicht doch etwas mehr normalisieren kannst, ohne Leistung einzubüßen. Dazu ist in Oracle eine Zeitmessung möglich und eine Beurteilung des vorliegenden Systems nötig. (zum Beispiel für den wissenschaftlichen Aspekt einer Diplomarbeit hilfreich ;-) ) Zusammenfassung: Relationales Modell • • • • • • • Deskriptive Queries: NonProzedurale Sprache SQL Vollständigkeit und Abgeschlossenheit: Führe ich auf einer Relation eine Operation aus, erhalte ich wieder eine Relation Adäquat: alle Strukturen, die ich definiere, kann ich auch zugreifen; alles ist abfragbar Optimierbarkeit: Nicht jede Query ist so schnell wie eine andere äquivalente, ein ordentliches System optimiert meine Queries auf Geschwindigkeit und behält sich vor, Queries auch umzustellen (wobei sie semantisch gleich bleiben). Ich kann diese Optimierung aber auch per Hand abschalten. Effiziente Implementierung: O(n2) (Aufwand wird sich höchstens quadrieren) Sicherheit: Jede Operation wird sicher terminieren (theoretisch) – keine Endlosschleife möglich. Praktisch gehen dem zwei Dinge entgegen: System ist in C++/ Java oder was auch immer programmiert – ist da ein Bug drin, schon habe ich eine Endlosschleife. Weitere Möglichkeit wären Deadlocks, aus Platzmangel z.B. bei "order By" – Abfragen. Preis für diese Sicherheit ist, dass die Konstrukte, die Endlosschleifen produzieren können, wurden aus SQL herausgelassen. Eingeschränkte Berechenbarkeit: weniger als das, was Turingberechenbar ist (keine Schleifen, Sprünge ...) Dies läßt sich ausmerzen, indem ich die DB in eine "normale" Programmiersprache eingebettet wird und somit SQL erweitert wird. Oracle nutzt z.B. PL/SQL, wobei das PL (Procedural Logic) Schleifen etc. enthält. Praktischer Aspekt Vom Problem zur Query 1. 2. 3. 4. 5. Interpretation: Präzisierung der umgangsprachlichen Formulierung des Problems aus der Diskurswelt. Transformieren: logisch präzise Beschreibung im Kontext des konzeptionellen Schemas Formalisieren: Ausdruck mit Mitteln des relationalen Modells im Kontext des logischen Schemas (Spalten – Tabellennamen, Schlüssel ...) Gernerieren: SQL-Text (Syntax) Test: Plausibiletät (Semantik) Seite 14 Autor: Drost, Isabel (if99p1) Einführung in Datenbanken Semester: IV Interpretation • • Vagheit der natürlichen Sprache (Abk., Beispiel: "Geben Sie die Gehaltsliste aus!" => select sal from emp;) Fokusierender Sprachgebrauch, d.h. Betonung von Wichtigem, Weglassen von Unwichtigem Transformation • • Knappe und logisch präzise Darstellung unter Verwendung mit Bezug auf konzeptuelles Schema. Beipiel: Durchschnittliches Einkommen der Beschäftigten in NY, die Verkäufer bzw. Analytiker sind: Formalisierung • • • Was will ich sehen? Woher kriege ich das? Unter welcher Bedingung kriege ich das? SQL - Text 3 Select Was 2 From Woher 1 Where/ Group/ Having ... Unter welchen Bedingungen Am besten von vornherein ein paar Spalten mehr anzeigen lassen, um herauszufinden, ob meine Bedingung richtig formuliert wurde. Testphase • • • Löst diese (syntaktisch richtige) Query das Problem wirklich (vollständig)? Ist die Lösung überhaupt plausibel (z.B. Stichproben). Beachte: eine falsche Query kann ein richtiges Resultat erzeugen! Seite 15 Autor: Drost, Isabel (if99p1) Einführung in Datenbanken Semester: IV DatenbankAnwendung Graphische Oberfläche Datenbank Werkzeuge: 4GL, 3GL, OOP Datenbank kann verteilt sein Zugriff auf die DB via Internet, Intranet, ohne Netz. Tasks: • • • Anwendungsentwicklung Installation, Administration (kreiren von Logins, Backups, ...) Verwenden von der Applikation Schwerpunkte können in allen drei Teilen liegen (Ausgefeilte graph. Oberfläche, Ausgewählter Zugriff übers Internet; Ausgefeilte, verteilte Datenbank, Synchronisation; Vorstellung über BackupMöglichkeiten; Ergononmie in einer Oberfläche – Wie soll die Oberfläche aussehen, wie sollen die Farben verteilt sind (z.B. Oberfläche für Sehbehinderte etc.) ) Datenbankinterface 1. 2. SQL+ Syntax (kann vom Durchnittsanwender nicht erwartet werden) GUI GUI Design - Look and Feel (ransetzen und losmachen können) Context Sensitive Help (Fkt. Taste F1, Hints pro Feld) Drag&Drop Clipboard Graphical Application User Interface 1) 2) 3) 4) Cosmetic => Akzeptanz 60 – 85% des Gesamtprojektes/ -aufwandes alle Constraints, die bis dahin nicht in der DB stehen, müssen da mit rein Oberfläche wenig portabel => Argument für Java Oberflächenprogrammierung <> oberflächlicher Programmierung Was liegt zwischen Anwendung und Database 1) Oberflächenwerkzeuge vom Datenbankhersteller (z.B. Developer bei Oracle) 2) Third Party Werkzeuge (Delphi, PowerBuilder) Delphi: unterstützen soviele Datenbanken wie möglich und stellen Oberflächen zu einer beliebigen Datenbank untendrunter zur Verfügung 3) Verteilte Anwendungen (Java) Seite 16 Autor: Drost, Isabel (if99p1) Einführung in Datenbanken Semester: IV Objektorientierte Methode/ ~Methode • • • graphisches Nutzerinterface zur Applikationsentwicklung (Oberfläche zusammenklicken) Eigenschaften der Objekte definierne (Oberfläche mit Fkt. versehen) Methoden aufrufen (eventHandler) Warum objektorientiert? Günstig für die Entwicklung von graph. Oberflächen. Nutzung von Java/ JBuilder • • • • • Container kreiren Komponenten in die Container Eigenschaften der Komponenten setzen EventHandler verbinden layouts und constraints setzen (Motif, ...) Events siehe Krüger – AWT • Action-, Adjustment, Item, Text-, ComponentEvent als Kind vom AWT-Event • Container, Focus- Input-, Paint-, Window-, Key-, Mouseevent vom Component Event (wir brauchen mehr als das AWT anbietet, z.B. zur Tabellendarstellung) Datenbankverbindung 1) embedded SQL (statisch, frühe Bindung, Precompiler) Statement in die Oberfläche einbetten – für gewöhnlich nicht so einfach möglich a) statisch – early binding ... Precompiler nimmt die SQLanweisungen und wandelt sie in C oder was auch immer um b) dynamic SQL – late binding ... Nachteil: Kaum Syntaxchecks. Erst, wenn ich bei der Ausführung auf die Query treffe, wird sie übersetzt. Vorteil: Queries dynamisch zusammenbastelbar c) Oracle Call Interface (OCI) – alle Zugänge zur DB auf unterstem Niveau – auf Systemebene (kaum Portabilität für andere DB und nur für systemnahe Programmierer) 2) Javavariante a) JDK von SUN (Gundausstattung) b) Ergänzung durch JavaBeans (vorgefertigte Programmmodule, z.B. vorgefertigte Tabellenbehandlung) c) JBuilder (Inprise – Borland), JDeveloper von Oracle als Entwicklungstools d) JDBC (Javasoft – Java DB Connectivity) realisiert den Zugang zur Datenbank (egal welcher), Gewähr dafür, dass die Oberfläche unabhängig von der DB auf die Daten zugreifen kann. Oracle: eigene virtuelle Maschine (Aurora) für die DB, geamte DB in Java programmiert; Agreement zwischen Oracle und Sun: alles, was Oracle entwickelt, wird automatisch zum Javastandard; 3) Open DB Connectivity Protocols a) ODBC (MS) b) JDBC (Java) c) IIOP (Corba d) HTTP (Html, Java-Servlets, Java Server Pages) Seite 17 Autor: Drost, Isabel (if99p1)
