Benutzer-Werkzeuge

Webseiten-Werkzeuge


praktikum_informationssysteme

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
praktikum_informationssysteme [2014/12/09 16:18]
web1423
praktikum_informationssysteme [2015/02/23 09:29] (aktuell)
Zeile 20: Zeile 20:
 </​code>​ </​code>​
  
-  ​Sichten sind wichtig, da die Daten immer aktuell sind, da sie keine echten Tabellen sind. So können andere Nutzer nur auf Teildaten einer Tabelle einfach zugreifen.+Sichten sind wichtig, da die Daten immer aktuell sind, da sie keine echten Tabellen sind. So können andere Nutzer nur auf Teildaten einer Tabelle einfach zugreifen.
  
 <code sql> <code sql>
Zeile 36: Zeile 36:
 </​code>​ </​code>​
  
-  ​Jedes mal soll bei insert automatisch eine Anzahl in LogAnz gelogged werden.+Jedes mal soll bei insert automatisch eine Anzahl in LogAnz gelogged werden.
  
 <code sql> <code sql>
Zeile 44: Zeile 44:
 </​code>​ </​code>​
  
-  ​also kann weggelassen werden, da also Standard ist. \\ Test:+also kann weggelassen werden, da also Standard ist. \\ Test:
  
 <code sql> <code sql>
Zeile 52: Zeile 52:
 </​code>​ </​code>​
  
-  ​Nun soll als Regel die ID aus Gegenstand, die bei insert erstellt wird auch in LogAnz erstellt werden. Dazu brauchen wir virtuelle Tabellen (new, old). New enthält die Werte und Spalten, die neu beim Abarbeiten der Regel hinzugekommen sind. Old sammelt die Werte, die von insert und delete betroffen waren. Bei update lassen sich beide Regeln benutzen. Zuerst wird die zuvor erstellte Regel entfernt und eine neue Tabelle Log erstellt:+Nun soll als Regel die ID aus Gegenstand, die bei insert erstellt wird auch in LogAnz erstellt werden. Dazu brauchen wir virtuelle Tabellen (new, old). **New**  ​enthält die Werte und Spalten, die neu beim Abarbeiten der Regel hinzugekommen sind. **Old**  ​sammelt die Werte, die von insert und delete betroffen waren. Bei update lassen sich beide Regeln benutzen. Zuerst wird die zuvor erstellte Regel entfernt und eine neue Tabelle Log erstellt:
  
 <code sql> <code sql>
Zeile 65: Zeile 65:
 </​code>​ </​code>​
  
-  ​Man kann bei Sichten kein insert anwenden, da es ja nur die (Teil-)Darstellung einer Tabelle ist. Möglich ist es, indem man via Regel in die eigentliche Tabelle einfügt:+Man kann bei Sichten kein insert anwenden, da es ja nur die (Teil-)Darstellung einer Tabelle ist. Möglich ist es, indem man via Regel in die eigentliche Tabelle einfügt:
  
 <code sql> <code sql>
Zeile 73: Zeile 73:
 </​code>​ </​code>​
  
-  ​Delete Regel lautet (bei der Where Bedingungen bietet sich immer der Primary Key an. Eigentlich müssten via and Bedingung alle Spalten definiert werden (old.Wochentag and …):+Delete Regel lautet (bei der Where Bedingungen bietet sich immer der Primary Key an. Eigentlich müssten via and Bedingung alle Spalten definiert werden (old.Wochentag and …):
  
 <code sql> <code sql>
Zeile 81: Zeile 81:
 </​code>​ </​code>​
  
-  ​Update:+Update:
  
 <code sql> <code sql>
Zeile 95: Zeile 95:
 </​code>​ </​code>​
  
-  ​Test:+Test:
  
 <code sql> <code sql>
Zeile 106: Zeile 106:
 </​code>​ </​code>​
  
-  ​Was macht folgende Regel:+Was macht folgende Regel:
  
 <code sql> <code sql>
Zeile 114: Zeile 114:
 </​code>​ </​code>​
  
-  ​Bei jedem Einfügen wird eine weitere Zeile einfügen und so weiter… D.h. diese Regel ist rekursiv. Mit do instead wird die Tabelle nicht überlaufen,​ da nur der zweite Teil der Regel ausgeführt wird. Instead wird das Problem allerdings vertagen, da gewartet wird.+Bei jedem Einfügen wird eine weitere Zeile einfügen und so weiter… D.h. diese Regel ist rekursiv. Mit do instead wird die Tabelle nicht überlaufen,​ da nur der zweite Teil der Regel ausgeführt wird. Instead wird das Problem allerdings vertagen, da gewartet wird.
  
 ===== Schlüssel ===== ===== Schlüssel =====
Zeile 132: Zeile 132:
 </​code>​ </​code>​
  
-  ​Update beider Tabellen führt zu Problem, da Integritätsprüfung erst nach kurz vor dem commit ausgeführt werden soll:+Update beider Tabellen führt zu Problem, da Integritätsprüfung erst nach kurz vor dem commit ausgeführt werden soll:
  
 <code sql> <code sql>
Zeile 141: Zeile 141:
 </​code>​ </​code>​
  
-  ​Daher muss bei der Definition des foreign key die Bedingung deferrable initially deferred gesetzt werden:+Daher muss bei der Definition des foreign key die Bedingung deferrable initially deferred gesetzt werden:
  
 <code sql> <code sql>
Zeile 149: Zeile 149:
 </​code>​ </​code>​
  
-  ​Zweite Variante: Definieren der Fremschlüsselbedingung als verzögerbar,​ aber sofort standardmäßig als sofort-ausführend,​ um dannbeim Ausführen einer Transaktion zu definieren, dass die Bedingung verzögert werden soll.+Zweite Variante: Definieren der Fremschlüsselbedingung als verzögerbar,​ aber sofort standardmäßig als sofort-ausführend,​ um dannbeim Ausführen einer Transaktion zu definieren, dass die Bedingung verzögert werden soll.
  
 <code sql> <code sql>
Zeile 173: Zeile 173:
 </​code>​ </​code>​
  
-  ​Beispiel 2. Fenster (parallel):+Beispiel 2. Fenster (parallel):
  
 <code sql> <code sql>
Zeile 180: Zeile 180:
 </​code>​ </​code>​
  
-  ​Mit jeweils select * from WS14 sehen wir bereits die eingefügten Werte. Was passiert nun, sobald commit; eingegeben wird? Per Voreinstellung wissen andere Transaktionen,​ was gerade passiert. \\ Es werden zwei Transaktionen geöffnet und jeweils werden bei einem Insert die gleichen Primary Keys eingegeben. Ein Insert funktioniert,​ beim zweiten wird das Prozedere angehalten, da die eine Transaktion wartet, ob die andere committed oder aborted. Je nach dem, was nun passiert, meldet die andere Transaktion einen Fehler oder einen Erfolg.+Mit jeweils select * from WS14 sehen wir bereits die eingefügten Werte. Was passiert nun, sobald commit; eingegeben wird? Per Voreinstellung wissen andere Transaktionen,​ was gerade passiert. \\ Es werden zwei Transaktionen geöffnet und jeweils werden bei einem Insert die gleichen Primary Keys eingegeben. Ein Insert funktioniert,​ beim zweiten wird das Prozedere angehalten, da die eine Transaktion wartet, ob die andere committed oder aborted. Je nach dem, was nun passiert, meldet die andere Transaktion einen Fehler oder einen Erfolg.
  
 ==== Isolationsgrade ==== ==== Isolationsgrade ====
Zeile 186: Zeile 186:
 Voreinstellung für Transaktionen ist read committed . <note tip>​Isolationsgrade bestimmen, was andere Transaktionen von dem was um sie herum passiert, sehen können.</​note>​ Voreinstellung für Transaktionen ist read committed . <note tip>​Isolationsgrade bestimmen, was andere Transaktionen von dem was um sie herum passiert, sehen können.</​note>​
  
-  * read committed: andere Transaktionen können Lesen, was passiert. +  * read committed: andere Transaktionen können Lesen, was passiert, aber lost update problem
-  * serializable:​ Abschotten der Transaktionen von der Außenwelt, so als wären sie hintereinander ausgeführt worden, aber lost update problem.+  * serializable:​ Abschotten der Transaktionen von der Außenwelt, so als wären sie hintereinander ausgeführt worden.
  
 <code sql> <code sql>
Zeile 196: Zeile 196:
 </​code>​ </​code>​
  
-  ​Obwohl eine Transaktion mit commit; abgeschlossen wird, sieht die andere Transaktion bei serializable das nicht. Was passiert nun bei einem update-Befehl in zwei Transaktionen,​ die das gleiche updaten wollen? Mit serializable wartet die andere Transaktion,​ was die erste macht, d.h. hier kommt auch ein Error, wenn die erste Transaktion committed. \\ Bei read committed kommt kein Fehler, sondern es wird ein update ausgeführt,​ aber die erste Transaktion hat das update erfolgreich ausgeführt (lost update Problem).+Obwohl eine Transaktion mit commit; abgeschlossen wird, sieht die andere Transaktion bei serializable das nicht. Was passiert nun bei einem update-Befehl in zwei Transaktionen,​ die das gleiche updaten wollen? Mit serializable wartet die andere Transaktion,​ was die erste macht, d.h. hier kommt auch ein Error, wenn die erste Transaktion committed. \\ Bei read committed kommt kein Fehler, sondern es wird ein update ausgeführt,​ aber die erste Transaktion hat das update erfolgreich ausgeführt (lost update Problem).
  
 ==== Sperren ==== ==== Sperren ====
Zeile 246: Zeile 246:
 </​code>​ </​code>​
  
-  ​Transaktion 2+Transaktion 2
  
 <code sql> <code sql>
Zeile 297: Zeile 297:
 </​code>​ </​code>​
  
-  ​Table-OID: Eindeutige Nummer für Tabellen.+Table-OID: Eindeutige Nummer für Tabellen.
  
 <code sql> <code sql>
Zeile 303: Zeile 303:
 </​code>​ </​code>​
  
-  ​Aber Zahlen sind wirr, d.h. es gibt auch Systemtabellen,​ die die Namen der jeweiligen Tabellen ausgeben.+Aber Zahlen sind wirr, d.h. es gibt auch Systemtabellen,​ die die Namen der jeweiligen Tabellen ausgeben.
  
 <code sql> <code sql>
-SELECT relname AS Tabelle, Uni_Bedienstet* FROM Uni_Bedienstet,​ pg_class+SELECT relname AS Tabelle, Uni_Bedienstet* FROM Uni_Bedienstet,​ pg_class
 WHERE Uni_Bedienstet.tableoid = pg_class.oid;​ WHERE Uni_Bedienstet.tableoid = pg_class.oid;​
 </​code>​ </​code>​
Zeile 333: Zeile 333:
 </​code>​ </​code>​
  
-  ​Möglichkeit 2:+Möglichkeit 2:
  
 <code sql> <code sql>
Zeile 356: Zeile 356:
 </​code>​ </​code>​
  
-  ​Erweiterung round:+Erweiterung round:
  
 <code sql> <code sql>
Zeile 384: Zeile 384:
 </​code>​ </​code>​
  
-  ​Aufgabe 2: Eine Funktion soll 2 String auf Ähnlichkeit überprüfen und die unterschiedlichen Stellen sollen als Anzahl ausgegeben werden. ⇒ akin+Aufgabe 2: Eine Funktion soll 2 String auf Ähnlichkeit überprüfen und die unterschiedlichen Stellen sollen als Anzahl ausgegeben werden. ⇒ akin
  
   * abs: absolute Zahl   * abs: absolute Zahl
Zeile 432: Zeile 432:
 </​code>​ </​code>​
  
-  ​Möglich sind dann Abfragen der Art select * from Artikel where Hersteller ~= '​Maierhofer';​+Möglich sind dann Abfragen der Art select * from Artikel where Hersteller ~= '​Maierhofer';​
  
 ===== Trigger ===== ===== Trigger =====
Zeile 448: Zeile 448:
 </​code>​ </​code>​
  
-  ​Daraus wird nun der Trigger erstellt:+Daraus wird nun der Trigger erstellt:
  
 <code sql> <code sql>
Zeile 473: Zeile 473:
 </​code>​ </​code>​
  
-  ​Erstellen der Funktion und des Triggers:+Erstellen der Funktion und des Triggers:
  
 <code sql> <code sql>
Zeile 534: Zeile 534:
 </​code>​ </​code>​
  
-  ​Test mit Löschen eines 14 Uhr Termins, wobei 2 14 Uhr Termine existieren, wovon nur einer mit wichtig markiert ist: Kein Termin wird gelöscht, da ein Befehl in SQL ganz oder gar nicht ausgeführt wird.+Test mit Löschen eines 14 Uhr Termins, wobei 2 14 Uhr Termine existieren, wovon nur einer mit wichtig markiert ist: Kein Termin wird gelöscht, da ein Befehl in SQL ganz oder gar nicht ausgeführt wird.
  
 +===== PHP und Datenbanken =====
 +
 +In einer Datei auf dem Server, die auf html endet, kann nur html Code eingefügt werden, d.h. .php als Dateiendung notwendig.
 +
 +==== PHP Grundlagen ====
 +
 +  * PHP aufrufen: <?php , PHP   ​beenden:​ ?>
 +  * Textausgabe:​ echo "​String"​. In der Textausgabe mit echo kann sowohl ein normaler String als auch HTML oder Javascript Code stehen. Um in einem solchen String ein Hochkommata oder andere Programmiercodes einzufügen,​ muss davor ein \ stehen. **Einfache Hochkommata** meinen: Nimm alles wörtlich, d.h. \n wird kein Zeilenumbruch ausgeben. Aber mittels Konkatenation kann \n hinzugefügt werden: echo '<​sdfsdf>'​ . "​\n";​
 +  * Zeilenumbruch:​ \n
 +  * Variablen definieren: $[Variablenname]
 +  * Konkatenation:​ Was in Java ein + ist, ist in php ein Punkt
 +
 +Funktion definieren:
 +
 +<code php>
 +function verdoppeln($wert)
 +
 +{ return $wert * 2;
 + }
 +
 +</​code>​
 +==== Formular erstellen ====
 +
 +Jedes Formular braucht ein action und method Attribut. input type sorgt für Eingabefelder. Der Absendebutton wird über input type="​submit"​ hinzugefügt.
 +
 +Bei action in Form ist angegeben: <?php echo $_SERVER['​PHP_SELF'​];​ ?>
 +
 +  * $_SERVER: Ein Array, in dem viele Servereigenschaften gespeichert sind
 +  * ​['​PHP_SELF'​]:​ Array an der Position PHP_SELF wird aufgerufen (Array-Zeile ist mit Namen gekennzeichnet). PHP_SELF beschreibt die derzeitige PHP-Datei, also wird die gerade aufgerufene PHP-Datei aufgerufen.
 +  * $_POST: Ebenfalls ein Arraystandard,​ in dem Zeilen aus dem Array ausgegeben werden, die via Post Methode bei Forms übergeben wurden. Diese Zeilen heissen wie die input Elemente.
 +
 +==== Verbindung aufbauen und Anfragen ====
 +
 +
 +  * Wichtig: Encoding der Datenbank muss das selbe Encoding der PHP-Ausgabe haben.
 +  * Verbindung herstellen: [$conn=]pg_connect("​host=gowron.fim.uni-passau.de dbname=roeder user=roeder password=0815"​);​
 +  * Anfrage an Datenbank: pg_query($conn. "​select * from Wein;"​);​
 +  * Tabellenbesonderheiten von php: pg_num_rows (zeilenanzahl),​ pg_num_fields (spaltenanzahl)
 +  * Ergebnis einer Tabellenzelle:​ pg_fetch_result($variable,​ $i, $j);
 +  * Überschrift einer Spalte: pg_field_name
praktikum_informationssysteme.1418138287.txt.gz · Zuletzt geändert: 2015/02/23 09:29 (Externe Bearbeitung)