Schlagwort-Archive: Datenbanken

Kängurus

Wir sind von Auckland nach Melbourne geflogen und haben uns dort über einen Taxifahrer geärgert. Die Stadt an sich ist aber toll, sie hat das größte Straßenbahnnetz der Welt und in der Innenstadt sind die auch noch für lau. Wir erzählen von den Museen und einer Podiumsdiskussion über Cyber-Security, bei der uns die 14jährige Tamara Baker von den Socken gehauen hat.

Außerdem sind im Zoo im Melbourne ganz tolle Kängurus, die den ganzen Tag chillen und sich ab und zu kraulen lassen.

Danach sind wir mit dem Zug nach Adelaide gefahren, wo es viel Grün und eine O-Bahn gibt.

Andreas erklärt Anke dann noch, was ein schwacher Entitätstyp ist und dass, wenn ein Haus abgerissen wird, auch alle Räume darin verschwinden. Anke erklärt Andreas, dass eine Person nicht ihre eigene Mutter sein kann.

Zealandia

Wir reisen in wenigen Stunden aus Neuseeland ab und erzählen, was wir noch so gemacht haben, wie wir das Land insgesamt fanden und ob es für einen Plan B taugt, sollte daheim alles schief laufen.

Wir reden über Wellington, den Vertrag von Waitangi von 1840, die Unabhängigkeitserklärung von 1835 und die Einführung des aktiven Frauenwahlrechts in Neuseeland 1893. Außerdem geht es über den Kontinent Zealandia, das Naturschutzgebiet Zealandia und die Nationalbibliothek, wo wir Qix gezockt haben. Von Wellington ging es mit KiwiRail nach Auckland, der Reisebericht mit Bildern dazu ist im Blog.

Im Datenbanken-Teil geht es um mehrstellige Beziehungen. In den Vorlesungsfolien sind die Diagramme dazu.

Für die Intro- und Outro-Musik gebührt nach wie vor unser Dank der Band Revolte Tanzbein, die uns erlaubt haben, Ihr Stück Panama zu spielen.

Datenbanken, Teil 4: Eins-zu-Eins-Beziehungen

Teil 2 der Serie über Datenbanken, in dem es um das Entity-Relationship-Modell ging, liegt nun schon ungefähr 2 Jahre zurück, aber relationale Datenbanken haben natürlich nichts von ihrer Aktualität eingebüßt und in der Zwischenzeit haben wir in unserem Podcast darüber berichtet. Bisher haben wir 1:N- und N:M-Beziehungen betrachtet. In diesem Teil geht es weiter, denn mit den Beziehungen ist es manchmal kompliziert.

Dieser vierte Teil der Serie setzt Kenntnisse der Grundbegriffe des E/R-Modells und der Umsetzung von 1:N- und N:M-Beziehungen ins relationale Modell voraus. In den ersten drei Teilen der Serie wurden diese erklärt.

Beispiele für 1:1-Beziehungstypen; Quelle;
CC-BY-SA 2.5 Maximilian Dörrbecker

Für 1:N- und N:M-Beziehungen wurde im vorherigen Teil bereits diskutiert, wie die Umsetzung ins relationale Modell erfolgt. 1:N-Beziehungen können am einfachsten mit einer Fremdschlüsselspalte auf der N-Seite umgesetzt werden während für N:M-Beziehungen immer eine Beziehungstabelle notwendig ist.

1:1-Beziehungen

Eine weitere Beziehungsart zwischen zwei Entitätstypen ist die 1:1-Beziehung. Betrachten wir zunächst als Beispiel die Beziehung zwischen einer Person und ihrem Ausweis.

Eine Person besitzt nur einen Ausweis und ein Ausweis gehört zu einer Person. Wir gehen in dem Beispiel weiterhin davon aus, dass jede Person in der Datenbank auch einen Ausweis besitzt und es nur personalisierte Ausweise gibt.

Datenbanken, Teil 4: Eins-zu-Eins-Beziehungen weiterlesen

Datenbanken, Teil 3: Tabellen erstellen mit SQL

Im zweiten Teil der Serie über Datenbanken, der zugegebenermaßen schon etwas zurück liegt, hatte ich versprochen, im folgenden Teil der Serie zu zeigen, wie man in der Praxis mit SQL Tabellen erstellt. Dieses Versprechen will ich nun hiermit einlösen. In der ersten Staffel unseres Podcasts haben uns in der Zwischenzeit allerdings auch schon mit SQL beschäftigt.

SQL ist eine weit verbreitete Sprache für relationale Datenbankmanagementsysteme und umfasst, wie im ersten Teil schon erwähnt, sowohl eine Abfragesprache (Query Language) wie auch Sprachen zum Einfügen und Löschen von Daten (Data Manipulation Langauge) und zum Anlegen eines Datenbankschemas (Data Definition Language). SQL wird von vielen aktuellen relationalen Datenbankmanagementsystemen (DBMS) verstanden. Ein weit verbreitetes und kostenloses DBMS ist MySQL. Die Codebeispiele in diesem und den folgenden Teilen beziehen sich, sofern nichts anderes angegeben ist, auf MySQL. Da SQL aber weitgehend standardisiert ist, sollten sie auch in anderen DBMS funktionieren.

Datenbanken, Teil 3: Tabellen erstellen mit SQL weiterlesen

Das Licht, das von Maui ausstrahlt

Wir sind weiter in Neuseeland und berichten kurz von Rotorua (wo der Vulkan qualmt), Taupo (wo es geregnet hat) und vor allem von Napier, wo sich ein Campus des Eastern Institute of Technology befindet und wo es auch sonst recht schön ist. Die Innenstadt wurde nach einem verheerenden Erdbeben 1931 recht konsequent im Stil des Art Deco wieder aufgebaut. Danach waren wir noch kurz in Gisborne (da ist auch ein Campus des EIT) und mit unserem gemieteten Semi-SUV bei einem Drive-in-Wasserfall.

Andreas rührt die Werbetrommel für ein Auslandssemester in Neuseeland. Für Studierende, die das machen wollen, ist die erste Anlaufstelle das International Center (auch International Office oder akademisches Auslandsamt genannt) der eigenen Uni (zum Beispiel das der Hochschule Furtwangen, wenn man zufällig dort studiert). Und dann sollte man schauen, ob es vielleicht irgendwo Fördermöglichkeiten gibt.

Im Datenbanken-Teil geht es über 1:1-Beziehungen und wie man sie in Tabellen umsetzt. Die (min,max)-Notation im E/R-Diagramm hilft, genauer einzuschätzen, welche Variante die beste ist. Als neues SQL-Schlüsselwort kommt UNIQUE dazu. Ein Blog-Beitrag mit den E/R-Diagrammen zum heutigen Thema wird noch nachgereicht.

Onsen

oder: was bisher geschah

Wir verlassen in Kürze Japan und lassen unsere Erlebnisse Revue passieren.

Unsere letzten zwei Stationen, über die wir bisher noch nicht berichtet haben, waren Shizuoka und Niigata. Die Fotos von unserem Ausflug mit der Oigawa Railway von Shizuoka aus sind schon im Blog und Fotos von Niigata reichen wir alsbald nach. Wenn Ihr in Niigata seid (muss man aber nicht), dann besucht die Saito-Residenz (muss man dann, wenn man schon in Niigata ist). Und geht ruhig mal zum Hochhaus “Media Ship” und dann ganz nach oben.

Wir fassen unsere Erlebnisse zusammen und diskutieren, was wir in Japan besonders gut fanden und was nicht so. Unser Fazit: Wir fanden es fast uneingeschränkt toll, Japan ist ein sehr interessantes Land für Besucher und definitiv eine (oder mehrere) Reise(n) wert! Ob wir aber gerne dauerhaft hier leben wollen würden, ist durchaus fraglich. Hört rein und findet heraus, warum wir das denken.

Im Datenbanken-Bereich fassen wir das in den vorherigen Folgen gehörte zusammen. Das wären die Grundbegriffe, das E/R-Modell mit 1:N- und N:M-Beziehungen und wie man es ins relationale Modell wandelt sowie Primär- und Fremdschlüssel. An SQL-Befehlen hatten wir bisher CREATE, ALTER, DROP, INSERT, DELETE, UPDATE und SELECT. Damit kommt man schon ein Stück weit, aber in den nächsten Folgen besprechen wir noch weitere Beziehungstypen und außerdem werden wir bestimmt noch viel Spaß mit SELECT haben.

Wir freuen uns immer über Feedback! Wir steigen aber gleich ins Flugzeug und es wird einen Tag dauern, bis wir Kommentare freischalten können.

Zuuug!

Wir haben jetzt JR-Railpässe und sind damit schon eine Menge durch Japan gefahren. Wir erzählen von Kyoto, Nara, Hiroshima und Kobe. Außerdem haben wir ein paar Sounds aus Japan mitgebracht.

Das Geraschel bei dem Shinkansen-Tonbeispiel stammt übrigens von japanischen Mitreisenden, die ihre Bento-Boxen ausgepackt haben. 🙂

Und hier noch die Erklärung zu den Umziehbrettchen.

Andreas erklärt Anke mal wieder was über Datenbanken. Konkret geht es heute darum, wie man N:M-Beziehungen aus dem E/R-Modell in Tabellen umsetzt und wie das mit SQL geht. Auch über dieses Thema kann man noch in Andreas’ Blogbeitrag von früher nachlesen.

Und hier wieder was Anke in MySQL eingegeben hat:

mysql> show tables;
+----------------+
| Tables_in_todo |
+----------------+
| Person |
| Todoeintrag |
+----------------+
2 rows in set (0,00 sec)

mysql> select * from Person;
+------------------+---------+----------+
| IdentifierPerson | Name | Nachname |
+------------------+---------+----------+
| 1 | Andreas | Hess |
+------------------+---------+----------+
1 row in set (0,00 sec)

mysql> select * from Todoeintrag;
+-----------------------+--------------------+------------+-------------------+------------------+
| IdentifierTodoeintrag | Text | Prioritaet | Faelligkeitsdatum | IdentifierPerson |
+-----------------------+--------------------+------------+-------------------+------------------+
| 1 | Handgepäck packen | 10 | 2019-04-10 | 1 |
+-----------------------+--------------------+------------+-------------------+------------------+
1 row in set (0,00 sec)

mysql> alter table Todoeintrag drop column identifierPerson;
ERROR 1828 (HY000): Cannot drop column 'IdentifierPerson': needed in a foreign key constraint 'todoeintrag_ibfk_1'

mysql> alter table Todoeintrag drop constraint todoeintrag_ibfk_1;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'constraint todoeintrag_ibfk_1' at line 1

mysql> alter table Todoeintrag drop foreign key todoeintrag_ibfk_1;
Query OK, 0 rows affected (0,01 sec)
Records: 0 Duplicates: 0 Warnings: 0

mysql> alter table Todoeintrag drop column identifierPerson;
Query OK, 0 rows affected (0,06 sec)
Records: 0 Duplicates: 0 Warnings: 0

mysql> create table zustaendigfuer (IdentifierTodoeintrag integer, IdentifierPerson integer, foreign key (IdentifierTodoeintrag) references Todoeintrag(IdentifierTodoeintrag), foreign key (IdentifierPerson) references Person(IdentifierPerson), primary key (IdentifierTodoeintrag, IdentifierPerson));
Query OK, 0 rows affected (0,01 sec)

mysql> insert into zustaendigfuer values (1,1);
Query OK, 1 row affected (0,01 sec)

mysql> select * from zustaendigfuer;
+-----------------------+------------------+
| IdentifierTodoeintrag | IdentifierPerson |
+-----------------------+------------------+
| 1 | 1 |
+-----------------------+------------------+
1 row in set (0,00 sec)

mysql> insert into zustaendigfuer values (1,1);
ERROR 1062 (23000): Duplicate entry '1-1' for key 'PRIMARY'

mysql> insert into zustaendigfuer values (1,2);
ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (todo.zustaendigfuer, CONSTRAINT zustaendigfuer_ibfk_2 FOREIGN KEY (IdentifierPerson) REFERENCES person (identifierperson))

mysql> alter table zustaendigfuer add column Stunden time;
Query OK, 0 rows affected (0,05 sec)
Records: 0 Duplicates: 0 Warnings: 0

mysql> select * from zustaendigfuer;
+-----------------------+------------------+---------+
| IdentifierTodoeintrag | IdentifierPerson | Stunden |
+-----------------------+------------------+---------+
| 1 | 1 | NULL |
+-----------------------+------------------+---------+
1 row in set (0,00 sec)

mysql> update zustaendigfuer set Stunden='02:00:00' where IdentifierTodoeintrag=1 AND IdentifierPerson=1;
Query OK, 1 row affected (0,01 sec)
Rows matched: 1 Changed: 1 Warnings: 0

mysql> select * from zustaendigfuer;
+-----------------------+------------------+----------+
| IdentifierTodoeintrag | IdentifierPerson | Stunden |
+-----------------------+------------------+----------+
| 1 | 1 | 02:00:00 |
+-----------------------+------------------+----------+
1 row in set (0,00 sec)

mysql> update zustaendigfuer set Stunden='26:00' where IdentifierTodoeintrag=1 AND IdentifierPerson=1;
Query OK, 1 row affected (0,01 sec)
Rows matched: 1 Changed: 1 Warnings: 0

mysql> select * from zustaendigfuer;
+-----------------------+------------------+----------+
| IdentifierTodoeintrag | IdentifierPerson | Stunden |
+-----------------------+------------------+----------+
| 1 | 1 | 26:00:00 |
+-----------------------+------------------+----------+
1 row in set (0,00 sec)

Jetzt wird’s ernst!

Der Tag der Abreise rückt näher: Am Donnerstag fliegen wir nach Tokio und unsere Weltreise geht los. Wir sind leicht nervös.

Die beste Nachbarin der Welt wird sich während unserer Abwesenheit um unsere Meerschweinchen (Ein stetiger Quell der Freude!) kümmern und hat jetzt schon für uns Streu und Heu eingekauft.

Derweil war Andreas in Kiel, mit unserem Freund Florian, der an der dortigen Fachhochschule Lehrbeauftragter ist, im Computermuseum und fand es echt gut!

Die Reisevorbereitungen sind in vollem Gange und inzwischen ist schon vieles vorausgeplant. Kanada hat sich als ausgesprochen teuer erwiesen. Für Neuseeland sieht es momentan so aus, dass wir wohl auf der Nordinsel bleiben, da es auf Südinsel zu dieser Jahreszeit kalt und verregnet sein wird und außerdem der Coastal Pacific nicht fährt.

Im Datenbanken-Teil sind wir bei der Umsetzung vom Entity-Relationship-Modell ins relationale Modell, also in Tabellen, angelangt. Das ist in diesem Blogeintrag von Andreas erklärt. Kurz gefasst: Aus Entitätstypen werden Tabellen, die Attribute werden zu Spalten. Für jede Tabellen sollte es einen Identifier geben, einen Primärschlüssel. Wenn sich kein Attribut dafür anbietet, nimmt man einen künstlichen Schlüssel, den man vom DBMS generieren lässt. 1:N-Beziehungen können mit einer zusätzlichen Spalte, einem Fremdschlüssel, in der Tabelle auf der N-Seite umgesetzt werden.

Für die Spalten muss man Datentypen festlegen. Wichtige Datentypen in SQL sind:

INTEGER – Ganzzahlen
NUMERIC(n,m), DECIMAL(n,m) – Dezimalzahlen mit Längenangabe (Stellen insgesamt, Nachkommastellen)
FLOAT(n), DOUBLE, REAL – Gleitkommazahlen (ist oftmals keine gute Idee, mehr dazu später)
CHARACTER(n), VARCHAR(n) – Zeichenketten (mit Längenangabe)
DATE, TIME, DATETIME, TIMESTAMP – Datum und Uhrzeit
CLOB, BLOB – große Texte, große Daten
BOOLEAN – wahr/falsch

Und hier ist, was Anke während der Aufnahme als Übung mit MySQL gemacht hat:

mysql> create database todo;
Query OK, 1 row affected (0,43 sec)


mysql> use todo;
Database changed

mysql> create table Person (IdentifierPerson integer primary key auto_increment, Name varchar(20) not null, Nachname varchar(30) not null);
Query OK, 0 rows affected (0,44 sec)

mysql> create table Todoeintrag (IdentifierTodoeintrag integer primary key auto_increment, Text varchar(200) not null, Prioritaet integer, Faelligkeitsdatum date, IdentifierPerson integer not null, Foreign key (IdentifierPerson) references Person(IdentifierPerson));
Query OK, 0 rows affected (0,09 sec)

mysql> insert into Person values (null, "Andreas", "Hess");
Query OK, 1 row affected (0,12 sec)


mysql> select * from Person;
+------------------+---------+----------+
| IdentifierPerson | Name    | Nachname |
+------------------+---------+----------+
|                1 | Andreas | Hess     |
+------------------+---------+----------+
1 row in set (0,03 sec)

mysql> insert into Todoeintrag values (null, "Handgepäck packen", 10, "2019-04-10", 1);
Query OK, 1 row affected (0,04 sec)


mysql> select * from Todoeintrag;
+-----------------------+--------------------+------------+-------------------+------------------+
| IdentifierTodoeintrag | Text               | Prioritaet | Faelligkeitsdatum | IdentifierPerson |
+-----------------------+--------------------+------------+-------------------+------------------+
|                     1 | Handgepäck packen  |         10 | 2019-04-10        |                1 |
+-----------------------+--------------------+------------+-------------------+------------------+
1 row in set (0,00 sec)


mysql> insert into Todoeintrag values (null, "Handgepäck packen", 10, "2019-04-10", 5);
ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (`todo`.`todoeintrag`, CONSTRAINT `todoeintrag_ibfk_1` FOREIGN KEY (`IdentifierPerson`) REFERENCES `person` (`identifierperson`))

Dienstreisen

Anke und Andreas berichten von Dienstreisen nach Dublin und Leipzig. Andreas ist dabei viel mit Straßenbahnen gefahren. Da kommen bestimmt noch ein paar Bilder davon ins Blog.

Auch was die Reisevorbereitungen angeht hat sich einiges getan. Anke hat ein System eingeführt, das für jeden Wochentag eine kleine Tasche vorsieht. Die Bildungsreise nach Japan wurde abgesagt, wir organisieren jetzt selbst. Anke will die Haseninsel in der Nähe von Hiroshima besuchen.

Im Datenbanken-Teil erklärt Andreas das Entity-Relationship-Modell. Da hat er auch schon mal was drüber gebloggt. Wer also ein Entity-Relationship-Diagramm auch mal sehen will, sollte sich diesen Artikel mal zu Gemüte führen. Das E/R-Diagramm, über das Andreas in dieser Folge spricht, hat er auch gebloggt. Seine Vorlesungsfolien darüber sind dort auch verlinkt. Der Artikel von damals gibt auch für die nächste Episode noch was her, anschließend muss Andreas wohl im Blog nachlegen.

Ansonsten fährt Andreas niemals in den Straßen von Tokio. Er arbeitet nämlich für die badische Regierung. In seiner Position wäre das also wenig ratsam. 😉