Schlagwort-Archive: Hochschule

Geflasht!

Unserer Weltreise hat begonnen und wir sind tatsächlich in Tokio!

Unsere Vorbereitung mit einer To-Do-Liste mit *zig* Einträgen hat nur bedingt was gebracht, denn, wie es in unserem Outro immer heißt: “Irgendwas läuft schief!” Wir haben unsere JR Railpässe daheim vergessen.

Das hat uns nicht davon abgehalten, uns von Tokio flashen zu lassen. Wir berichten von japanischen Toiletten, einer Speisekarte, von der wir nichts verstanden haben, einem Tempel in Asakusa und koreanischer Popkultur in Shin-Okubo.

Im Blog zeigen wir dazu Fotos, die uns noch lange erfreuen werden und ganz am Schluss spielen wir für ein paar Sekunden jenen K-Pop an, mit dem wir beim Mittagessen beschallt wurden. (“Yes or Yes” von “Twice”).

Ach ja, und in dieser Episode gibt es ausnahmsweise mal gar nix über Datenbanken. Wir müssen bei all den Eindrücken unser Hirn erst wieder frei kriegen, bevor dort wieder was über Entities, Relationships und SQL rein passt.

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.

Cyberbull

Wenn Ihr mal ne spannende Serie schauen wollt, schaut Euch Designated Survivor an, aber bitte nur die erste Staffel.

Wenn Ihr ne schlechte Serie schauen wollt, schaut Euch auch Designated Survivor an, aber diesmal die zweite Staffel.

Diese Serie bekommt von mir nicht nur die Auszeichnung für das größtmögliche Qualitätsgefälle, sondern auch den Preis für den größten jemals gemessenen Bullshit in Szenen mit Computerbezug.

Dass Bildschirminhalte nicht so eine große Rolle spielen, so lange es irgendwie kompliziert und doch cool aussieht, ist nichts neues. Auch dass mittels Magie aus einem Satellitenbild eine hoch aufgelöste Frontalaufnahme eines Verdächtigen entsteht, ist im Fernsehen schon lange Standard. Dass dieses Bild dann “Pixel für Pixel” mit den Datenbanken abgeglichen wird, ist schon eine Spezialität. Einen einzelnen weißen, schwarzen oder bunten Punkt in einer Datenbank zu suchen, das bringt sicher viel. Aber egal, das geht vielleicht noch als unglückliche Formulierung durch.

Anekdoten aus Designated Survivor

Ein wenig später freut sich der IT-Crack Chuck, dass er die Firewall des Laptops eines Verdächtigen überwunden hat. Da staunt der Laie und der Fachmann wundert sich. Warum hat sich Chuck die Mühe gemacht, die Firewall, die den Rechner vor unbefugtem Zugriff aus dem Netzwerk schützen soll, zu überwinden, wenn das Gerät direkt vor ihm auf dem Tisch steht?

Aber vielleicht ist es auch nur des Wortwitzes wegen: Der Laptop geht wenige Augenblicke später in Flammen auf, weil der böse Besitzer “den Akku gehackt” hat. Vielleicht hätte das FBI doch lieber einen IT-Forensiker anstellen sollen, der sich mit sowas auskennt.

Eher ein Schmankerl für Kenner war dann noch, dass der selbe Chuck Erkenntnisse über eine Auktion von Alan-Turing-Memorabilia gewinnt, bei der unter anderem eine Turing-Maschine versteigert wurde. Da wurde der Käufer wohl betrogen, handelt es sich bei einer Turing-Maschine doch um ein mathematisches Konstrukt, ein rein theoretisches Gebilde, nicht um ein physisch existierendes Gerät.

Warum ärgert mich das?

Eigentlich finde ich sowas ja ganz amüsant, besonders weil es gerade in dieser Serie so unglaublich übertrieben absurd ist, wenn man sich auch nur ein bisschen mit der Materie auskennt.

Doch das Problem ist, dass sich so beim Zuschauer ein falsches Bild von Computertechnik, von Sicherheitslücken und von Angriffen auf IT-Systeme verfestigt. Wenn etwas nur oft genug im Fernsehen gezeigt wird, und wenn es auch in einer Action-Serie ist, besteht leider die Gefahr, dass es irgendwann jemand für bare Münze nimmt.

Anstatt sich von solchem Cyber-Zauber beeindrucken zu lassen, sollten sich Computernutzer (d.h. wir alle!) lieber auch mal mit echter IT-Sicherheit befassen. Wer sich auch nur ansatzweise von dem Bild inspirieren lässt, das in dieser TV-Serie vermittelt wird, schwebt in Gefahr, die realen und alltäglichen Bedrohungsszenarien zu ignorieren.

Die letzte Konsequenz davon sieht man auch in dem aktuellen Fall von “Doxing“, bei dem personenbezogene Daten von etwa 1000 Menschen, darunter viele Politiker, veröffentlicht wurden. Mehr Kompetenz im Umgang mit IT-Systemen ist notwendig, um die Ursachen zu verstehen und solche Vorfälle in Zukunft zu vermeiden. Nimmt man dagegen zu viel von dem Mumpitz zu sich, wie er in Designated Survivor und anderen Action-Serien vorkommt, dann kommen leider so kompetenzbefreite Ideen wie die des “Hack-Back” auf den Tisch, statt generell die (defensive) IT-Sicherheit zu stärken. Letzteres könnte natürlich als Nebeneffekt dazu führen, dass der Bundestrojaner dann nicht mehr läuft. Ob man das deshalb nicht will?

Die Realität ist spannender!

Dass die Realität sehr viel spannender ist als Cyber-Bullshit, sieht man übrigens jedes Jahr beim Chaos Communication Congress. Dieses Jahr wurde da unter anderem gezeigt, wie man über Fax in Firmennetze einbrechen kann, es wurde die biometrische Identifikation mit Venenerkennung durch eine Attrappe überwunden und es wurde gezeigt, wie man Geldautomaten um ihren Inhalt erleichtern kann.

Man sich übrigens durchaus an der Realität orientieren und trotzdem daraus eine spannende Serie stricken! Mein Schlusswort ist deshalb: Wenn Ihr mal ne spannende Serie mit mehr Cyber, aber weniger Bullshit sehen wollt, dann schaut Euch Mr. Robot an!