Weiterlesen »]]> In der objektorientierten Programmierung bedeutung Speicherung in einer Datenbank – egal, ob MySQL, MS-SQL, PostGreSQL oder eben auch SQLite – nahezu immer ein Mapping von Objektdaten zu relationen Daten und umgekehrt.

In der Praxis ist es hilfreich, wenn man für jedes seiner Business Objects eine Hilfsklasse hat, die sich um genau diese Konvertierung kümmert. Doch was wäre, wenn diese Hilfsklasse noch einen kleinen Tick mehr könnte – zum Beispiel den Lesezugriff beschleunigen?

Die klassischen Arbeiten an einer Datenbank: das CRUD-Prinzip

Wenn man mit einer Datenbank arbeitet, führt man in den meisten Fällen eine der vier großen und wichtigen Operationen aus, die in der IT-Welt unter dem Synonym CRUD bekannt sind. Das steht für:

Create
Read
Update
Delete

Anders ausgedrückt also: Datenobjekte erstellen, einlesen, aktualisieren und löschen. Als ich mir bei meinem aktuellen Projekt – eine Hilfs-App für Arcane-Codex-Gamemaster, so eine Art “Nachschlagewerk” – überlegt habe, wie da mit den Daten umgegangen wird, bin ich zu folgender Erkenntnis gelangt:

Erstellen und Aktualisieren von Daten kommt natürlich vor, aber immer nur im Einzeltakt; es wird jetzt mal eine Info in der Datenbank angelegt, eine aktualisiert – und vielleicht auch mal eine gelöscht. Das dürfte sogar noch seltener vorkommen, und immer bezieht sich diese Operation auf ein einzelnes Datenobjekt.

Lesezugriff hingegen – nun, das sollte sehr häufig vorkommen; die Daten werden ja auch an Listviews gebunden (und wenn der Screen in den Pausemodus geht und zurückkehrt auf den Schirm, müssen die Daten wieder gelesen werden, weil sie sich ja geändert haben könnten). Lesezugriff erfolgt also viel häufiger als die anderen Zugriffe, und – noch dazu – meist nicht nur auf einzelnen Objekten, sondern gleich auf ganzen Sammlungen gleichartiger Objekte. Das wäre also der ideale Zeitpunkt, um den Zugriff zu optimieren; schließlich besteht ja gerade bei einer SQLite-Datenbank die Crux darin, dass jeder Lese- oder Schreibzugriff das Öffnen einer physikalischen Datei zur Folge hat.

Die Lösung: ein Cache für die Objekte

Meine Hilfsklasse hat daher einen Cache implementiert – beim ersten Versuch, die Daten einzulesen, wird der Cache auf null geprüft. Ist das der Fall, werden einmalig alle Daten aus der Datenbank in den Cache gelesen. Werden dann Daten über die Hilfsklasse abgefragt (alle oder einzeln), werden diese aus dem Cache genommen.

Der Nachteil ist natürlich: Neue Objekte muss ich nicht nur in die Datenbank, sondern auch in den Cache schreiben; Objekte löschen müssen ebenfalls in DB und Cache erfolgen, ebenso das aktualisieren von Objekten. Wie ich oben aber schon ausgeführt habe: Diese Operationen kommen nicht oft vor und betreffen auch nur Einzelobjekte, keine ganzen Sammlungen; der Mehraufwand durch den Cache ist in diesem Fall vernachlässigbar.

Ein konkretes Beispiel aus meinem Programm

Ich speichere in meinem Programm Informationen über Regionen. Dazu habe ich eine Business-Klasse namens Region – ich gehe hier gar nicht auf die Details ein, die sind zweitrangig. Wichtig ist zu wissen: Die Region hat die drei Datenfelder id, name und description (mit den jeweiligen Gettern/Settern), außerdem gibt es – um Aktualisierungen zu vereinfachen – eine copyOver-Methode, der man ein anderes Region-Objekt übergibt und die dann einfach name und description von dem anderen Objekt für das aktuelle übernimmt.

Meine Hilfsklasse zum Einlesen von Regionen ist die RegionData. Diese Klasse wiederum beinhaltet eine innere Klasse namens DBHelper, die indirekt von SQLiteOpenHelper abgeleitet ist. (Indirekt deshalb, weil ich nochmal eine Basisklasse drüber gezogen habe, die sich um onCreate und onUpdate kümmert und die in allen Hilfsklassen zu Business-Objekten vorkommt; Details warum ich das gemacht habe, gibt es in diesem Artikel.)

Ich gebe jetzt hier nicht die ganze Klasse RegionData wieder, aber einen Teil des Codes, um zu zeigen, worauf es ankommt:

public class RegionData extends BaseBusinessData {
   private static final String          TAG           = RegionData.class.getSimpleName();
   // FINALs for DB
   private static final String          TABLE         = "Regions";
   // fields
   private DbHelper                     dbHelper;
   private String[]                     allColumns    = { C_ID, C_NAME, C_DESCRIPTION };
   private Context                      context;
   private static Region                unknownRegion;
   // Object Cache
   private static HashMap<Long, Region> regions       = null;

   public RegionData(Context context) {
      this.dbHelper = new DbHelper(context);
      /** initiate the regions from db, if it hasn't happened already */
      if (regions == null)
         mapAllRegions();
      this.context = context;
      if (unknownRegion == null) {
         /** build an unknown region to hand out, just in case we're asked for an inexistent id */
         Log.d(TAG, "building unknown Region");
         unknownRegion = new Region();
         unknownRegion.setId(-1);
         unknownRegion.setName(context.getString(R.string.unknownRegion));
      }
      Log.d(TAG, "onCreated");
   }

   /**
    * @param id
    *           of the Region we are looking for
    * @return Name of the Region
    */
   public String getRegionNameById(long id) {
      if (regions.containsKey(id)) {
         return regions.get(id).getName();
      }
      return unknownRegion.getName();
   }

   public Region createRegion(String name, String description) {
      ContentValues values = new ContentValues();
      values.put(C_NAME, name);
      values.put(C_DESCRIPTION, description);
      long id = this.dbHelper.insert(values);
      Region r = this.dbHelper.getById(id);
      regions.put(r.getId(), r);
      Log.d(TAG, "created Region in DB and in Map");
      return r;
   }

   public Region getRegionById(Long id) {
      if (regions.containsKey(id))
         return regions.get(id);
      return unknownRegion;
   }

   public void deleteRegion(Region r) {
      if (regions.containsKey(r.getId())) {
         this.dbHelper.deleteById(r.getId());
         regions.remove(r.getId());
         Log.d(TAG, "deleted Region in DB and in Map");
      }
   }

   public void updateRegion(Region r) {
      if (regions.containsKey(r.getId())) {
         this.dbHelper.updateRegion(r);
         // also update the info in our Map.
         Region origin = regions.get(r.getId());
         origin.copyFrom(r);
         Log.d(TAG, "updated Region in DB and in Map");
      }
   }

   /**
    * enforces RegionData to re-read the content from the database on next access. Useful after importing a new database
    * from sdcard.
    */
   public static void clearCache() {
      regions = null;
   }

   /** get Regions as sorted ArrayList */
   public ArrayList<Region> getAllRegions() {
      if (regions == null)
         mapAllRegions();
      ArrayList<Region> temp = new ArrayList<Region>(regions.values());
      Collections.sort(temp);
      return temp;
   }

   /** experimental: get Regions as Map, not ArrayList */
   private void mapAllRegions() {
      regions = new HashMap<Long, Region>();
      Cursor c = this.dbHelper.getAll();
      c.moveToFirst();
      while (!c.isAfterLast()) {
         Region r = this.dbHelper.cursorToRegion(c);
         regions.put(r.getId(), r);
         c.moveToNext();
      }
      c.close();
      this.dbHelper.close();
      // now sort it in alphabetical order!
      Log.d(TAG, "mappedAllRegions");
   }

   /**
    * Inner Class DbHelper - derived from SqLiteOpenHelper
    */
   private class DbHelper extends BaseSQLiteOpenHelper {

   }

}

Der Klassencode oben ist etwas gekürzt. Man sieht aber sehr gut, wie beim Create, Update und Delete die Änderungen sowohl an der DB, als auch am Cache nachvollzogen werden. (Die Klasse DbHelper oben ist leer, die hat in der Realität natürlich Code dort stehen; der tut aber hier nichts zur Sache.)

Die Methode mapAllRegions erstellt den Cache (in Form einer HashMap): Alle Regionen werden hier drin abgelegt und auf ihre ID gemappt, diese stellt den Schlüssel dar. (Daher hat die HashMap auch den Typ HashMap<Long, Region> – weil Long der Schlüsseltyp ist.)

Wie man sieht, im Lesezugriff wird die Datenbank erst gar nicht bemüht. Dafür hab ich eine unknownRegion, die ich zurückliefere, falls nichts passendes gefunden werdne kann. (Was eigentlich nicht passieren sollte, aber man weiß ja nie – also wird das sicherheitshalber mal so gemacht.)

Achtung Falle: statisch!

Eines ist noch wichtig: Der Cache oben ist als static deklariert, das heißt: Wir haben es mit einer Klassenvariable zu tun, nicht mit einer Instanzvariable. Und das ist auch sehr wichtig! Denn anderenfalls würde jedes Mal, wenn ein Teil des Programms eine neue Instanz von RegionData initiiert, auch ein komplett neuer Cache erstellt werden – damit wäre erstens der Sinn und Zweck des Ganzen weg (wird ja DOCH wieder komplett aus der DB gelesen), zweitens wäre das auch unsinnig, weil die Daten dann mehrfach im Arbeitsspeicher wären.

Zum Schluss

Ich hoffe, diese Ausführungen helfen dem einen oder anderen weiter. Beim nächsten Mal erzähl ich dann davon, wie ich den Cache zur Bindung der Daten an eine ListView (mittels SimpleAdapter) benutze. Und danach erzähle ich vielleicht von der Location, die an eine Region gebunden ist – und wie ich den Cache dort so benutze, dass ich daraus Daten generiere, die für den Einsatz eines SimpleExpendableDataAdapter (für eine ExpandableListView) gedacht sind.

Weiterlesen »]]> Zur Zeit beschäftige ich mich mit der Entwicklung von Android Apps. Das macht nicht nur sehr viel Spaß (Interface in XML schreiben? Eaaasy, and good looking to *g*), man stößt auch manchmal auf “interessante” Dinge. Zum Beispiel die Sache mit dem SqLiteOpenHelper und mehreren Tabellen in einer Datenbank.

Eine feine Sache – prinzipiell – ist ja die Klasse SqLiteOpenHelper für solche Fälle, in denen man eine einfache Datenbank in Sachen Persistenz haben will. Das ist auch deshalb besonders schön, weil der Install-Mechanismus von Android bei der Neuinstallation einer App die bereits bestehende Datenbank nicht löscht, sondern ggf. so lässt, wie sie ist. Es ist Sache des Entwicklers, bei einer Änderung des Schemas ggf. die Tabellen in der Datenbank zu ändern.

Natürlich ist SqLiteOpenHelper nur dann sinnvoll und hilfreich, wenn man seine eigene Helfer-Klasse davon ableitet und die Klasse entsprechend in Hinsicht auf seine Objekte, die man persistent speichern will, anpasst. Irgendwo im Internet – leider finde ich den Link nicht mehr – habe ich gelesen, dass man pro Tabelle eine eigene Helferklasse haben sollte. Yeah, gute Idee – nicht.

Das Problem ist folgendes: Die erste Tabelle wird von der ersten Helferklasse angelegt, die zweite nicht mehr. Warum? Weil SqLiteOpenHelper nur nachguckt, ob die Datenbank existiert – einzelne Klassen spielen für ihn keine Rolle.

Mit dem Problem hatte ich zu kämpfen, als ich auf den nächsten Hinweis stießt, dass man eigentlich nur eine SqLiteOpenHelper-Version haben sollte, die sich um alle Tabellen kümmern muss. Und das ist auch richtig, die Schema-Nummer der Datenbank ist schließlich wieder spezifisch für die Datenbank, nicht für eine einzelne Tabelle.

Nun hatte ich aber schon zwei Helferklassen, die teilweise gleiche Methoden (mit leicht geänderten Parametern) implementiert hatten. Beide Klassen existieren übrigens nur als private Klassen innerhalb einer Datenklasse. Ich hab, ganz konkret, Daten in einer Klasse namens Location gespeichert; dazu gibt es eine Hilfsklasse namens LocationData, die nach außen hin – für die gesamte App – Daten über die gespeicherten Locations bereitststellt, und innerhalb eine abgeleitete SqLiteOpenHelper-Klasse verwendet, um den Zugriff auf die Datenbank zu vereinfachen.

Das Ganze hab ich aber auch nochmal für Region und RegionData mit ihrer jeweiligen Hilfsklasse. Beide zusammenwürfeln? Geht nicht (jeweils private Klassen), und beide Hilfsklassen mit ihren überladenen Methoden zusammenstecken – das geht schon, aber dann ist die Klasse wirklich überladen. Und wie wird das erst, wenn die nächsten beiden Datentypen (NPC und Player) noch hinzukommen? Da wäre diese SqLiteOpenHelper-Klasse wirklich überfrachtet.

Ich habe mich für die – aus Sicht der Objektorientierung – logischste Variante entschieden: Ich habe eine neue (öffentliche) Klasse namens BasisSQLiteHelper geschrieben (abgeleitet von SqLiteOpenHelper), die sich um das Scheman kümmert und die Funktion onCreate und onUpgrade zur Verfügung stellt. Dort wird sich um die Erstellung aller Tabellen gekümmert, aber sonst sind keine Funktionen implementiert.

Meine beiden inneren Hilfsklassen hingegen haben ihren Ursprung geändert: Sie erben jetzt von der oben genannten Basisklasse, und müssen deshalb auch weder onCreate noch onUpgrade implementieren. Die kümmern sich nur um die jeweils spezifischen Funktionen für ihre Klassen (wie zum Beispiel cursorToLocation oder cursorToRegion).

Problem gelöst: Eine Klasse für alle Tabellen, und trotzdem für jedes Business Object eine eigene (Unter-)Hilfsklasse. Ich bin zufrieden.

Weiterlesen »]]> Mir ist da heute auf dem Heimweg etwas merkwürdiges ein- oder vielmehr aufgefallen: Unterschiedliche Religionen aus verschiedenen Epochen und Regionen teilen eine bestimmte Sichtweise – ein Weltenbild, wenn man so sagen will. Und es kommt noch besser: Ich erkenne Parallelen zur Psychoanalytik von Sigmund Freud.

Bereit für ein paar Häresien?

Christliche Weltsicht

Fangen wir mal mit dem Christentum an – ich unterstelle dem geneigtem Leser, dass ihm oder ihr diese Religion einigermaßen vertraut sein dürfte. Ein guter Startpunkt also für diese kleine Gedankenreise.

Als Christ weiß man, dass man – wenn man gut war – nach dem Ableben in den Himmel kommt. Oder in die Hölle, wenn man ein besonders schlechter Mensch war (z. B. ein Banker, ein Politiker oder ein Versicherungsvertreter). Hier existieren also drei verschiedene Welten in der Vorstellung des Christen: Oben der Himmel, unten die Hölle – und dazwischen wir. Der Himmel will uns erlösen, auch wenn seine Methoden dafür manchmal etwas merkwürdig sind. Zum Beispiel Abraham, der von Gott aufgefordert wird, seinen Sohn Isaak zu opfern. Der Ausgang der (zum Glück nicht erfolgten) Opferung spielt hier nun erstmal keine Rolle. Ich glaube aber, dass dieses Beispiel meine Behauptung über merkwürdige Methoden ganz gut untermauert.

Unten lauern der Satan und seine Schergen auf unsere Seelen. (Hui, für unsere Freunde bei RTL lässt sich daraus ganz gut eine Alliteration machen: der seelenhungrige Satan. Aber lassen wir Alliterationen fallen, über “Bauer sucht Frau” rege ich mich ein anderes Mal auf.) Er ist daran interessiert, uns zu verführen, und teilweise macht er uns dabei Angebote, die man kaum ablehnen kann. (Als Vergleich hierzu lasse ich die Bibel mal außen vor und verweise statt dessen auf Goethes Faust.)

In der Hölle hausen ja Dämonen, bei denen es sich – die meisten dürften das wissen – um gefallene Engel handelt. Weniger bekannt ist die Tatsache, dass die gefallenen Engel (der Sündenfall: ein Engel liegt bei einer Menschenfrau) Kinder zeugten, die Riesen gleich über die Erde streiften und manchmal die Helden des Altertums darstellten, oder auch die Schergen. Vermutlich war Goliath ein Nachkomme dieser Gefallenenkinder, aber das ist jetzt meine persönliche Theorie. (Der Hinweis auf die Kinder findet sich in der Bibel, aber mehr zum Sündenfall findet man im angelischen Evangelium, das zu den Apokryphen gehört.)

Wir haben hier also ein Drei-Welten-Modell:

• Himmel: oben, Gott, das Gute
• Erde: dazwischen, Menschen, werden von beiden Seiten beeinflusst
• Hölle: unten, Dämonen, das Böse

Wer das für total innovativ hält, sieht sich getäuscht: Das gab’s doch schon mal… [Merkt euch an dieser Stelle bitte mal, dass unten die Dämonen hausen, deren Kinder als Riesen gelten. Darauf kommen wir später noch mal zurück.]

Hellas, Zeus: die Weltsicht der griechischen Mythologie

Alle Welt spricht ja von der Griechenlandkrise, uns interessiert hier jetzt aber erstmal die griechische Mythologie. Denn auch dort finden wir dieses Drei-Welten-Modell: Oben, das ist in der griechischen Mythologie der Olymp, dort wohnen die Götter. Der Olymp ist im übrigen ein Berg; dass hohe Berge als Wohnstätte der Götter gelten, kennen wir auch in Deutschland. So verdankt der Donnersberg seinen Namen Donar, dem germanischen Donnergott (bei dem es sich um Thor handelt, so wie Wotan niemand anderes ist als Odin – aber zur nordischen Mythologie kommen wir noch).

Wir haben also oben die Götter – der Olymp kann wohl als Analogon zum christlichen Himmel gesehen werden. Im Christentum heißt es ja, dass gute Menschen in den Himmel eingehen – in der griechischen Mythologie wurde gesagt, dass die verdientesten Krieger in den Olymp gerufen werden, um an der Seite der Götter zu kämpfen. Die Götter, so heißt es, spielen mit den Menschen – aber im Allgemeinen geht man davon aus, dass sie den Menschen Gutes wollen.

Wenn es ein Oben gibt, gibt es auch ein Unten: die Unterwelt, Hades genannt. In der griechischen Mythologie wird diese vom Zerberus bewacht, dem dreiköpfigen Höllenhund. Und in die Unterwelt wurden die Titanen verbannt, mit denen die Götter erbittert Krieg führen. Man beachte: Titanen. Könnte man da auch Riesen sagen? Ich spiele hier natürlich auf die Riesen an, die ich beim Christentum erwähnt habe. Auf die kommen wir gleich noch mal.

Zwischen Olymp und Hades liegt dann die Welt der Sterblichen, also die – nennen wir es mal so – Erde. Hier haben wir schon wieder das gleiche Drei-Welten-Modell:

• Olymp: oben, die Götter, das Gute
• Erde: dazwischen, Menschen, Spielball der Götter und Titanen
• Hades: unten, die Titaten, das Böse (die Vernichter)

Wo die Asen saßen

Springen wir weiter nur nordischen Mythologie. Ich lass jetzt mal die germanischen Namen (Donar, Wotan, etc.) außen vor und konzentriere mich auf die Bezeichnungen der isländischen Etta, die in den meisten Fällen geläufiger sein dürften.

Hier haben wir Asgard – die Heimstatt der Götter, hoch oben, verbunden mit der Welt der Sterblichen durch die Regenbogenbrücke. Asgard verdankt seinen Namen den Göttern, die dort wohnen: die Asen. (Eigentlich waren die Wanen zuerst da, aber die Asen als Emporkömmlinge haben sich nach vorne gekämpft, bis es zu einem Waffenstillstand kam, dann hat man noch ein paar Leute ausgetauscht als Zeichen gegenseitigen Respekts – so ist der Wächter der Regenbogenbrücke, Heimdall, eigentlich ein Wane und kein Ase – und dann haben sich die Wanen vom Göttergeschäft zurückgezogen.) Auch hier, wie bei den Göttern des Olymp: Man spielt manchmal mit den Menschen, aber prinzipiell wollen die Götter den Menschen Gutes. Odin hat sich schließlich 7 Tage lang an der Weltenesche Yggdrasil aufgehängt, um das Geheimnis der Runen zu erlernen, auf dass er die Runen den Menschen bringen konnte…

Die Menschen leben wieder in der Dazwischen-Welt, hier Midgard genannt. Das “Mid” etwas mit “Mitte” zu tun hat, kann man sich eigentlich schon denken, oder? Und natürlich kommen auch hier die guten Menschen (in diesem Fall: die besten Krieger) zu den Göttern, genauer gesagt nach Walhalla, Odins Heimstatt, wo sich die Krieger für die letzte Schlacht bereit machen. (Vermutlich indem sie saufen und fressen, was der Wanst aushält.)

Unten gibt es dann Utgard – die Heimstatt der Riesen. (DA! Da sind sie wieder: die Riesen. So wie die Titanen.) Die Riesen sind Weltenzerstörer, und die Götter beschützen die Menschen vor ihnen.

Also haben wir wieder das gleiche System:

• Asgard: oben, Götter, die Guten
• Midgard: dazwischen, die Menschen
• Utgard: unten, Riesen, die Bösen

Was sagt uns das?

Klar dürfte jetzt ja sein, dass wir es hier mit einen Übereinstimmungen zu tun haben. (Es gibt auch in jeder Religion ein Weltuntergangsszenario – Ragnarök, die Götterdämmerung, in der nordischen Mythologie, oder auch das Jüngste Gericht, etc. pp. – aber damit will ich mich im Moment nicht beschäftigen.)

Die interessante Frage ist: Woher kommt dieses Drei-Welten-Modell? (Die Drei ist ja ohnehin eine beliebte und bedeutungsschwangere Zahl; die heilige Dreifaltigkeit ist auch nicht durch Zufall entstanden.) Eine Möglichkeit wäre natürlich, dass die einen bei den anderen “abgeschrieben” haben. (Sagt man dazu nicht neudeutsch auch “geguttenbergt”?) Oder es gibt eine gemeinsame Urreligion, auf deren Wurzeln das alles basiert?

Oder aber – und das ist die spannendere Alternative – dieses Modell hat sich in den jeweiligen Religionen unabhängig von anderen Religionen entwickelt. Wenn dem so ist, muss man sich aber fragen, wie es dazu kommt. Möglicherweise liegt diesem ganzen Gerüst eine universale Wahrheit zu Grunde, die von verschiedenen Menschen zu verschiedenen Zeiten erkannt wurde und darin eingeflossen ist.

Ich halte letztere Variante nicht nur für die spannendere, sondern auch für die wahrscheinlichere – und ich glaube nicht, dass diese drei Welten oder Schichten etwas mit dem Aufbau der physischen Welt zu tun haben. Ich glaube, es geht dabei eher um den Geist, um das Wesen des Menschen. Ich will es mal anders formulieren, wie man – meiner Meinung nach – diese drei Schichten sehen kann:

• Oben/das Gute: Diese Schicht ist die moralische Instanz, es geht um das “Seelenheil”, die Errettung. Es geht darum, das richtige zu tun.
• Mitte/der Mensch: Er ist den Einflüssen von Unten und Oben ausgesetzt. Beide Seiten wollen ihn in ihre Richtung ziehen, seinen Lebensweg beinflussen, aber es obliegt letztlich dem Menschen, was und vor allem wie er es tut. Er hat die letzte Entscheidung zu treffen.
• Unten/das Böse: Diese Schicht ist das Gegenstück zur Moral – hier geht es um Lust und Triebe, um Verführung. Tue, was du für richtig hältst, es ist dein Leben!

Wenn man sich das so anguckt, ergibt das einen gewissen Sinn, oder? Vor allem, weil wir etwas derartiges ja schon kennen: Das nennt sich die “zweite Topik” (oder auch Strukturmodell der Psyche) und wurde so schon von Sigmund Freud aufgestellt. Nur nennt er seine drei Schichten nicht Gut, Mensch, Böse – sondern so:

• Über-Ich (Moral)
• Ich (Kontroll)
• Es (Lustprinzip)

 Fazit

Ich persönlich glaube, dass das der allen Religionen zugrunde liegende Kern ist: Die Erkenntnis, dass der Mensch per se die Anlage zum Bösen ebenso wie zum Guten mitbringt. Es liegt an jedem Einzelnen, welcher Seite er sich zuwendet. Anders ausgedrückt: Es liegt an uns allen, diese Welt besser zu machen.

Soll heißen: Wirtschaftsbosse müssen nicht unbedingt eine EK-Rendite von 20 % und mehr erreichen, wenn man dafür unmoralisches tun muss (z. B. massenhafte Entlassungen, oder stabilitätsgefährdende Spekulationen an den Weltmärkten). Man hat auch die Wahl, sich moralisch zu verhalten (und dann eben halt etwas weniger Gewinn zu machen, so what…)

Also möchte ich zum Abschluss nochmal Goethe zitieren (dieses Mal aber nicht aus Faust):

Edel sei der Mensch, hilfreich und gut!
Denn das allein unterscheidet ihn von allen Wesen, die wir kennen.

Weiterlesen »]]> Die deutsche Politik lässt nicht locker: Innenminister Friedrich beharrt weiterhin darauf, dass die Vorratsdatenspeicherung wichtig sei im Kampf gegen Terrorismus. Und Terrorismus ist eine so große Gefahr, dass wir alle doch einsehen, dass deshalb auch mal Bürgerrechte beschnitten werden – nicht wahr? Hier die schockierende Wahrheit…

Bevor ich jetzt gleich die Katze aus dem Sack lasse, will ich erstmal noch ein bisschen was klarstellen zur Vorratsdatenspeicherung. Bisher kann mir nämlich noch keiner klar und offen darlegen, wie die Terrorakte verhindern soll. Ihr Hauptzweck besteht ja auch darin, NACH dem schrecklichen Ereignis zur Aufklärung und Aufarbeitung eingesetzt zu werden. Das ist löblich, aber wenn das Kind im Brunnen ist, lässt sich dieser Sturz nicht nachträglich dadurch heilen, dass man einen Deckel auf den Brunnen nagelt. (Und wenn man das schon tut, sollte man das Kind vorher wenigstens rausholen…)

Terror ist böse! Terror ist allgegenwärtig! Terror ist die größte Gefahr unserer Zeit!

Was auch immer die Politiker versuchen durchzudrücken – sie entschulden ihr Handeln gerne mit dem Gebot der Not. So ist das zum Beispiel beim Thema der Neuner-Kommission, die fiskalpolitische Entscheidungen höchster Tragweite vom Parlament fernhalten soll. So ist das auch beim digitalen Lauschangriff, ob nun Bundestrojaner oder Vorratsdatenspeicherung: Ist die Not nur groß genug, akzeptiert das Wahlviehvolk alles.

Und womit könnte man mehr Angst schüren und Unterstützung erbetteln als mit Terror? Zum medialen Schreckgespenst hochstilisiert ist er das Lieblingsthema der Politiker. Aber wie gefährlich ist der Terror wirklich?

Die nackte Wahrheit, oder auch: Fakten, Fakten, Fakten…

Vielleicht wussten Sie es noch nicht, aber es gibt in den USA ein National Counterterrorism Center, das sich intensiv mit Terrorismus auseinander setzt. Mal abgesehen von Todesmeldungen über Osama Bin Laden veröffentlichen die auch jedes Jahr einen Report – zum Beispiel den 2010 NCTC Report on Terrorism (hier als PDF verlinkt).

Ladies and Gentleman, ich bitte Sie, Ihre Aufmerksamkeit auf Seite 21 der PDF-Datei (im Dokument Seitennummer 12) zu lenken. Dort gibt es eine schöne Grafik, die ich hier auch nochmal einfüge für alle, die sich jetzt nicht durch die PDF wühlen wollen:

Der rote Balken sind die Menschen, die 2010 bei Terror-Attacken starben, die blauen Balken sind die dafür notwendigen Attacken. Aus diesem Chart können wir einiges lernen – mal angefangen bei der Tatsache, dass Terroristen in Europa und Eurasia (das ist unsere Region) wohl ziemlich dämlich sind. Sie brauchten 704 Anschläge für 355 Tote – ganz grob vereinfacht stirbt nur bei jeder zweiten Terrorattacke ein Mensch (ein einziger). Nicht wirklich effizient, da sind sie in Afrika besser. Obwohl ich ja glaube, dass dort auch viele Terrorregimes ihre Hand mit im Spiel haben.

Was lernen wir aber noch? Richtig: 2010 gab es weltweit 13.186 Todesopfer bei Terrorattacken. In Europa und Eurasia waren das 355. Scheinbar lohnt sich diese Region nicht für Terror. (Ostasien und Pazifik muss genauso unattraktiv sein.)

Boah! 355 Tote durch Terror? In nur einem einzigen Jahr? Welch furchtbare Katastrophe, da müssen wir sofort die Bürgerrechte beschneiden und mit allem dagegen halten!

Sollen wir es mal relativieren?

Ich verweise zunächst mal auf die Seite Verkehrstod bei Wikipedia (deren statistische Zahlen stimmen, ich nehm deshalb Wikipedia, weil dort viele Zahlen auf einer Seite schön übersichtlich zusammengepackt sind). Demnach gab es allein in Deutschland im Jahr 2010 3.648 Todesfälle im Straßenverkehr – also mehr als zehnmal soviel Tode wie im gleichen Zeitraum in ganz Europa und Eurasien durch Terror.

Auf der Wikipedia-Seite gibt es auch eine Tabelle mit einem europäischen Vergleich; leider ist dort das aktuellste Jahr 2005, nicht 2010. Es sollte aber trotzdem ausreichen: Die europäischen Länder zusammengerechnet (da ist Eurasien jetzt noch gar nicht mit dabei) kamen im Jahr 2005 auf mehr als 40.000 Verkehrstode (nach der Tabelle bei Wikipedia: 40.504, sofern ich mich jetzt nicht verrechnet hab).

Das ist mehr als das 110-fache der Terrortoten von oben (und Eurasien ist, wie gesagt, bei den Verkehrstoten noch gar nicht drin). Muss ich das wirklich noch näher erläutern? Ich glaube nicht.

Fazit

Ich möchte keinesfalls behaupten, dass Terrorismus KEINE ernstzunehmende Gefahr ist. Die ist er natürlich, und wir müssen den Kampf gegen ihn aufnehmen – keine Frage. Aber bitte, liebe Politiker: Tut das im Rahmen der normalen politischen Gepflogenheiten. Es gibt keinen Grund, unsere Bürgerrechte zu beschneiden.

Und hört endlich auf, Terror als überdimensionales Schreckgespenst aufzublasen. Ich glaube, die Abwehrmechanismen funktionieren auch so ganz gut; und in einigen anderen Fällen haben sich die Ermittlungsbehörden so dämlich angestellt, dass die Vorratsdatenspeicherung denen auch nicht mehr geholfen hätte. (Stichwort: “Nationalsozialistischer Untergrund” – dort waren Behördenineffizienz und mangelnde Abstimmung der Grund für ein Jahrzehnt Versagen. An den Daten lag’s jedenfalls nicht.)