Schlagwort-Archive: Datenbanken

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. 😉

Checklisten

Unsere Weltreise wirft ihre Schatten voraus: Anke berichtet von der Vorbesprechung zur Bildungsreise nach Japan, zu der außer uns wohl nur Lehrerinnen fahren. Reiseleiter Chris hat uns eine Checkliste und viele nützliche Tipps gegeben. Andreas’ Cousin Rudi und seine Frau Olivia sind gerade in Neuseeland und bloggen von dort. Da werden sicher auch viele interessante Sachen für uns dabei sein.

Für unsere Reise ist noch ganz schön viel zu planen und die To-Do-Liste soll natürlich mit einer Datenbank umgesetzt werden. Andreas erklärt Anke, dass ein relationales Datenbank-Management-System Daten in Tabellen speichert und was DML, DDL und SQL bedeuten. Anke wundert sich, dass es relationale Datenbanken erst seit 1970 gibt.

Zu dem, was Andreas heute über Datenbanken erzählt hat, hat er vor anderthalb Jahren schon mal was gebloggt.

Intro und Outro sind wie immer von der großartigen Band Revolte Tanzbein, denen wir nochmals danken, dass wir “Panama” dafür benutzen dürfen. Unser Dank geht auch an unseren Freund David Göbel, der unser Logo gestaltet hat.

Statt Outtakes gibt es diesmal ein kurzes Zitat aus dem Hörbuch “Der Aufstieg und Fall des D.O.D.O.” von Neal Stephenson und Nicole Galland. Wir hoffen, dass Euer Verhältnis zu Datenbanken anders ist als das der Romanfiguren und Ihr uns viel Feedback (und positive Bewertungen) gebt.

Trailer

Wir stellen uns und unseren neuen Podcast vor.

Wir wollen auf eine Weltreise gehen und Japan, Neuseeland, Australien und Kanada besuchen.

Unser Plan ist, dass wir nicht nur über unsere Erlebnisse berichten, sondern auch über Datenbanken sprechen.

Unser Dank geht an die großartige Band Revolte Tanzbein dafür, dass wir Ihren Song “Panama” als Intro benutzen dürfen sowie an unseren Freund David Göbel, der unser Logo gestaltet hat.

Das MySQL-Kuriositätenkabinett

Zusammengesetzte Fremdschlüssel

Zusammengesetzte Primärschlüssel kommen in der Datenbankwelt allerorten vor, z.B. in Beziehungstabellen. Zusammengesetzte Fremdschlüssel sind seltener, werden aber naturgemäß gebraucht, wenn auf eine Tabelle mit zusammengesetztem Primärschlüssel referenziert werden soll.

Die Syntax für die Erstellung von zusammengesetzten Fremdschlüsseln ist analog zu zusammengesetzten Primärschlüsseln.

Gegeben seien beispielhaft die folgenden Tabellen:

CREATE TABLE `raum` (
 `Buchstabe` char(1) NOT NULL,
 `RaumNr` decimal(3,2) NOT NULL,
 PRIMARY KEY (`Buchstabe`,`RaumNr`)
);

CREATE TABLE `findetstatt` (
 `Nr` int(11) DEFAULT NULL,
 `Belegnr` int(11) DEFAULT NULL,
 `Abk` varchar(5) DEFAULT NULL,
 `RaumNr` decimal(3,2) DEFAULT NULL,
 `Buchstabe` char(1) DEFAULT NULL
);

Ein zusammengesetzter Fremdschlüssel, der von von “findetstatt” auf “raum” verweist, wird nun erstellt mit:

alter table findetstatt add foreign key(buchstabe, raumnr) references raum(buchstabe,raumnr);

Falle: Error 1215

Zu beachten ist, dass die Reihenfolge, in der die Spalten des Fremdschlüssels angegeben werden, der Reihenfolge entsprechen muss wie sie in der Definition des Primärschlüssels, auf den sich der Fremdschlüssel bezieht, angegeben ist. Wird dies nicht beachtet, quittiert MySQL das mit einer nichtssagenden Fehlermeldung.

mysql> alter table findetstatt add foreign key(raumnr,buchstabe) references raum(raumnr,buchstabe);
ERROR 1215 (HY000): Cannot add foreign key constraint

Das gleiche passiert, wenn man auf die Idee kommt, nur die Spalte “RaumNr” mit einem Fremdschlüssel-Constraint zu belegen, da sich dieser dann auf den zweiten Teil des Primärschlüssels in der Tabelle “raum” bezieht:

mysql> alter table findetstatt add foreign key(raumnr) references raum(raumnr);
ERROR 1215 (HY000): Cannot add foreign key constraint

Wird nur der erste Teil eines mehrteiligen Primärschlüssels referenziert, ist das problemlos möglich, z.B.:

alter table findetstatt add foreign key(buchstabe) references raum(buchstabe);

 

Datenbanken, Teil 2: Das Entity-Relationship-Modell

Im ersten Teil der Serie haben wir festgestellt, dass der Einsatz von Datenbanken eine gute Sache ist, da sich der Entwickler nicht mehr mit den Grundfunktionen der Datenspeicherung befassen muss. Allerdings konnten wir auch schon erkennen, dass eine sinnvolle Datenmodellierung essenziell ist. Oder anders gesagt:

One does not simply create a database

Bevor ein sinnvoller Datenbankentwurf beginnen kann, ist es zunächst entscheidend, sich über den Ausschnitt der realen Welt, der abgebildet werden soll, im Klaren zu sein. Dazu empfiehlt sich das von Peter Chen 1976 vorgestellte Entity-Relationship-Modell, das Entitäten, also Dinge der realen Welt, ihre Eigenschaften und Beziehungen zwischen diesen beschreibt. In diesem Artikel werden wir uns mit den Grundlagen dieses Modells beschäftigen. Im Lehrbuch von Kemper und Eickler wird das Entity-Relationship-Modell in Kapitel 2 besprochen.

Da die eigentliche Datenspeicherung in den gängigen DBMS allerdings nach dem relationalen Modell, also in Tabellenform, erfolgt, müssen wir uns auch damit beschäftigen, wie man ein Entity-Relationship-Modell in das relationale Modell umwandelt. Dies ist in vielen Fällen recht umkompliziert und führt zu guten Datenbankschemata, die die im ersten Artikel der Serie beleuchteten Probleme wie Redundanzen nicht aufweisen.

Datenbanken, Teil 2: Das Entity-Relationship-Modell weiterlesen

Datenbanken, Teil 1

tl;dr

Datenbanken sind toll, weil sie die Grundaufgaben der Datenspeicherung übernehmen und man sich nicht mehr selber darum kümmern muss.

Datenbanken

Seit einiger Zeit unterrichte ich an der Hochschule Furtwangen im Studiengang Wirtschaftsinformatik das Fach Datenbanken. Im Laufe der Zeit ist dabei einiges an Vorlesungsmaterial, Übungsaufgaben und Notizen zu Eigenheiten von Software angefallen. Auch ein Podcast war dabei. Bisher war mein Material aber nur hochschulöffentlich. Außerdem gibt es bisher – außer den Slides – noch kein Skript zu meiner Vorlesung. Zeit, das alles mal zu ändern und die Notizen zu meiner Vorlesung in Form zu bringen und bei der Gelegenheit ins Blog zu stellen.

Aber ganz zu Anfang gilt es erst mal zu klären, warum man sich denn überhaupt mit Datenbanken befassen sollte. Oder anders gesagt:

Databases – Y U no use simple text file?

Um diese Frage zu klären, schauen wir uns ein – scheinbar – einfaches Beispiel an: eine Adressliste. Was kann da schon schiefgehen?

Datenbanken, Teil 1 weiterlesen