Der beseelte Kosmos als
relationale Datenbank |
||||||
[1] An
einer anderen Stelle 
wurden einige Fragen nach der Natur von Seelen und
insbesondere den Möglichkeiten ihrer Wechselwirkungen
mit der materiellen Welt aufgeworfen. |
||||||
| [2] An dieser Stelle sollen Fragen zur Beziehung von Seelen und der materiellen Realität unter Verwendung datenbanktechnischer Begrifflichkeiten beschrieben werden. Die Kosmos wird dabei in der Metapher einer Datenbank betrachtet. Was man gemeinhin als Datenbank bezeichnet ist sehr viel mehr als bloß ein Speicher von Datenmengen. Datenbanken bilden die Realität in tabellarischen Strukturen ab. Datenbanken erzwingen die Einhaltung bestimmter Regeln bezüglich der Daten, die man speichern kann. Darüber hinaus können Datenbanken auch Datenzugriffe regeln. | Die alten Griechen glaubten der
ganze Kosmos sei beseelt. Aber was Seelen bewirken
können, das ließen sie offen. |
|||||
| [3] Zunächst müssen wir uns der Frage nach der "Ontologie", das heißt dem Wesen, von Raum, Zeit und Materie zuwenden. | Der Kosmos als Groupware? |
|||||
Die Modellierung der Raumstruktur |
||||||
| [4] Physiker verwenden zur Beschreibung der Realität Begriffe wie Raum, Zeit, Teilchen sowie Zustände von Teilchen wie etwa Impuls, Masse oder Spin. Wie hängen diese Begriffe zusammen? Von vielen denkbaren Lösungen werden zwei herausgegriffen. | ||||||
| [5]
Bezüglich seiner Raumstruktur können wir uns den Kosmos
unter anderem auf zwei Weisen vorstellen.
Abbildung 1: Gerasterter und stetiger Kosmos im Vergleich Die Abbildung oben zeigt links die Vorstellung eines in feste Quaderelemente aufgeteilten Kosmos. Jeder Quader kann durch drei ganze Zahlen eindeutig bestimmt werden wie zum Beispiel: 3, 4, 1. Die Zahlen wären sozusagen die Koordinaten. Zwischen zwei benachbarte Quader passt kein dritter Quader: der Raum ist unstetig, also gestückelt. Auf der rechten Seite sehen wir ein aufgespanntes Koordinatensystem. In diesem Koordinatensystem könnte die Lage von Teilchen eindeutig über die Angabe von drei Zahlen beschrieben werden. Sind als Koordinaten Zahlen mit beliebigen Nachkommastellen erlaubt, so kann man von einem stetigen Raum sprechen, denn zwischen zwei Punkte im Raum passt immer noch ein Punkt dazwischen. Die empirische Physik kann heute noch keine endgültige Antwort geben, ob der Raum gestückelt ist oder aber stetig. Nach der Quantentheorie sollte er gestückelt sein, nach Einsteins Relativitätstheorie hingegen stetig. |
Quantenpyhsik oder
Relativitätstheorie? Die beiden Theorien lassen sich
mathematisch nicht vereinigen, weil sie gegensätzliche
Annahmen über die Stetigkeit von Raum und Zeit treffen. |
|||||
| [6] Ohne besondere Begründung nehmen wir einmal an, der Raum sei gestückelt, um endlich mit der Erstellung einer Datenbankstruktur beginnen zu können. Als erste Datenentität definieren wir "Raumelement": | ||||||
Abbildung 2: Die Datenentität "Raumelement" |
<= Die blaue Kopfzeile gibt den Namen der Tabelle, bzw. der Datenentität an. | |||||
| [7] Ein Raumelement muss von seiner Größe her definiert sein. Die Attribute mit dem Namen "Elementarlänge" beschreibt die Länge, Breite und Höhe eines Raumelementes. Dabei wird unterstellt, dass Länge, Höhe und Breite stets gleich groß sind. Eine weitere willkürliche Annahme. Wir greifen auf die vermutete "Elementarlänge" zurück, wie sie in einem Physikbuch genannt wird (siehe Zitat rechts). Desweiteren wird jeder Datensatz der Tabelle "Raumelement" über einen eindeutigen Schlüssel, die sogenannte ID (Identifier) angesprochen. Die Datenbank vergibt diese ID-Nummer automatisch und stellt sicher, dass es innherhalb einer Tabelle niemals zwei Datenzsätze mit der gleichen ID gibt. Dies dient zur eindeutigen Bezeichnung von Datensätzen. Die Koordinaten geben die Lage der Raumelemente wieder und sollen den Datentyp "Ganzzahl" (Integer) haben. Die abstrakte Datenentität "Raumelent" sähe als konkrete Tabelle dann zum Beispiel wie folgt aus: | <=
Gestückelter Raum?
|
|||||
Abbildung 3: Beispielhafte Tabelle "Raumelement" |
<= Eine Beispielinstanz der Entität "Raumelement" | |||||
[8] In der Realität entspräche das dann den folgenden Raumelementen des Kosmos:
Abbildung 4: Tabelle "Raumelement" visualisiert |
<= Der kosmische Raum als Quadermodell | |||||
| [9] Nimmt man die Mechanismen einer Datenbank ernst, so muss man grundsätzlich davon ausgehen, aus datenbanktechnisch möglich Aktionen auch durchgeführt werden dürfen. Am Beispiel der Elementarlänge sehen wir, wie schnell dies zu merkwürdigen Effekten führen kann. Wir haben bisher nirgends festgelegt, ob der Zahlenwert der Elementarlänge für jedes Raumelement gleich sein muss und wir wollen dies auch jetzt nicht tun. Das aber heisst, dass jedes Raumelement eine eigene Größe haben kann. Man müsste dann also mit einem Kosmos wie etwas dem folgenden rechnen: | ||||||
Abbildung 5: Kosmos mit unterschiedlichen Elementarlängen |
<= Raumelemente mit unterschiedlichen Größen sind erlaubt. | |||||
| [10] Nun könnte man vortrefflich darüber streiten, was denn der Raum zwischen den Raumelementen eigentlich sein soll. Wie hat man ihn zu interpretieren? Wir wollen an dieser Stelle aber dieser schwierigen ontologischen Frage dadurch ausweichen, dass wir einfach fordern, dass die Elementarlänge für jedes Raumelement gleich groß sein soll. | <= Ontologischer Unfug | |||||
Die Modellierung der Zeit |
||||||
| [11] Nachdem wir dem Kosmos eine von vielen denkbaren Raumstrukturen gegeben haben, wenden wir uns nun der Zeit zu. Immerhin scheint sich der Kosmos ja zu verändern und da macht es durchaus Sinn, von Zeit zu reden. | ||||||
| [12] Gleich taucht schon eine schwierige Frage auf: Sollen alle Raumelemente gemeinsam eine Zeit zugeordnet bekommen oder sollen einzelne Raumelemente unterschiedliche Zeiten haben dürfen? Wir legen hier willkürlich fest, dass jedes Raumelement eine eigene Zeit haben darf. Albert Einsteins Relativitätstheorie legt ja nahe, dass verschiedene Objekte unterschiedliche Zeitabläufen unterliegen können, nämlich in Abhängigkeit von ihren jeweiligen Geschwindigkeiten. | <= Gemeinsame Zeit für alle Raumelemente? | |||||
| [13] Von welchem Datentyp soll die Zeit sein? Lassen wir nur Ganzzahlen zu, dann wäre die Zeit gestückelt, lassen wir aber alle reellen Zahlen zu, so wäre die Zeit kontinuierlich. Wieder muss eine willkürliche Entscheidung getroffen werden. Wir greifen dabei die Erfahrung des mittelalterlichen, christlichen Mystikers Eckehart auf und legen einfach fest, dass die Zeit ebenso wie der Raum gestückelt sei. Die Zeit ist vom Datentyp "Integer". Unser Datenbankmodell von der Raumzeit sieht dann wie folgt aus: | Zitat von Meister Eckehart (1260-1329): "Nichts hindert die Seele so sehr an der Erkenntnis Gottes als Raum und Zeit. Zeit und Raum sind Stücke. Gott ist Eines." Quelle:Vom Wunder der Seele, Seite 60. | |||||
Abbildung 6: Die Berücksichtigung der Zeit und Datentypen |
<= Die vollständige Modellierung der Raumzeit | |||||
| [14] Das Datenbankschema lässt vollkommen offen, welche Zeitpunkte wir einzelnen Raumelementen zuordnen. Die Datenbank lässt es also durchaus zu, dass ein Raumelement irgendwo im Rathaus von Aurich einen Zeitpunkt kurz vor Christi Geburt hat währenddessen ein Raumelement im bretonischen Örtchen Loctudu einen Zeitpunkt irgendwann im Erdzeitalter Kambrium hat. Wir werden dieses Problem später wieder aufgreifen. Die Datenbank soll solche Konstellationen durchaus zulassen. | <= Raumelemente können beliebige Zeiten haben. | |||||
| [15] Bevor wir die Modellierung der Raumzeit abschließen, muss noch sichergestellt werden, dass sich zwei beliebige Datensätze (=Zeilen) aus der Tabelle "Raumelement" immer in ihren Raumkoordinaten unterscheiden. Hierzu stellen professionelle Datenbanken wie etwa von der Firma Oracle einen sogenannten "Unique Constraint" zur Verfügung: Die Datenbank überprüft, dass sich die Einträge bestimmter Attribute eindeutig voneinander unterscheiden lassen. Wir legen also einen Unique Constraint über die drei Attribute x-Koordinate, y-Koordinate und z-Koordinate. Sollte irgendjemand versuchen, zwei Raumelemente mit genau gleichen Raumkoordinaten in die Datenbank zu schreiben, dann würde die Datenbank eine Fehlermeldung ausgeben und die Operation verhindern. Wir wollen an diese Stelle nicht darüber nachdenken, was eine Datenbankfehlermeldung in der Realität sein soll. | <= Raumelemente müssen sich unterscheiden: Unique Constraint. | |||||
| [16] Hier sei die Modellierung von Raum und Zeit in einer Datenbank abgeschlossen und wir wenden uns nun der Modellierung von Materie, Energie oder ganz allgemein "Zuständen" von Raumelementen zu. | ||||||
Die Modellierung von "Materie" als Zustand |
||||||
| [17] Eine Welt die nur aus zeitbezogenen Raumelementen bestünde wäre wie Fernseher ohne Programm: es würde nichts in ihr passieren. Mit den Raumelementen muss etwas geschehen, sie müssen sich verändern können und womöglich auch untereinander wechselwirken. | ||||||
| [18] In einer physikalischen Betrachtung der Realität ist die Rede von einer Fülle verschiedener Teilchen: Elektronen, Positronen, Quarks, Photonen und viele mehr. Diese Teilchen sind die Träger des kosmischen Geschehens. Sie können sich bewegen, miteinander kollidieren, sie können miteinander verschmelzen oder in andere Teilchen zerfallen. Wir müssen sie jetzt in unser Datenbankschema einbauen. Auch dazu müssen wir wieder eine Reihe willkürlicher Annahmen treffen. | Das Weltbild der klassischen Physik |
|||||
| [19] Wieviele Teilchen gibt es? Unendlich viele? Oder lässt sich der ganze Teilchenzoo auf wenige Teilchen reduzieren? Und wieviele unterschiedliche Zustände können diese Teilchen annehmen? Wir wollen uns der Hoffnung reduktionstisch denkender Physiker anschließen und von einer begrenzten Anzahl von Teilchentypen ausgehen. Darüberhinaus übertragen wir die Vorstellung einer Stückelung, wie sie Quantenphysik nahelegt, auch auf Eigenschaften von Teilchen: Also kann Elektron nur bestimmte, gestückelte, Ladungen tragen oder nur eine bestimmte Anzahl klar unterscheidbarer Spins annehmen. | ||||||
| [20] In der Tat deuten verschiedene mathematische Modellierungen, die man unter dem Sammelbegriff "Stringtheorien" zusammenfasst, an, dass es nur einige wenige Teilchen, eben die Strings (Fäden), gibt. Und diese wenigen Teilchen können nur ganz bestimmte Schwingungszustände annehmen. Es sind ganzzahlige Vielfache der Grundschwingung. |  Buchtipp:Brian Greene über die
Superstringtheorie (Das elegante Universum) |
|||||
| [21] Wir können also jetzt unser Datenbankschema um zwei weitere Entitäten, bzw. Tabellen, erweitern: Teilchenart und Teilchenzustand. | ||||||
| [22] In der Tabelle mit dem Namen Teilchenart hinterlegen wir alle Teilchen, die es in der Welt geben soll. In der Tabelle Teilchenzustand wird dann festgelegt, in welchen Raumelementen welche Teilchentypen mit welchem Zustand vorhanden sind. | ||||||
Abbildung 7: Die Verknüpfung von Teilchen, Zuständen und Raumelementen |
||||||
| [23] Die Abbildung oben besagt Folgendes: In der Tabelle mit dem Namen Teilchenzustand werden Raumelemente mit Teilchentypen und Zuständen verknüpft. Das heisst, in dieser Tabelle wird festgelegt, ob in einem bestimmten Raumelement zu einem bestimmten Zeitpunkt ein Teilchen einer bestimmten Art in einem bestimmten Zustand existiert oder nicht. Die Einsen und der Buchstabe "n" an den Verbindungslinien besagen, dass eine Teilchenart, repräsentiert durch seine ID-Nummer in beliebig vielen (Anzahl n) Verknüpfungen in der Tabelle Teilchenzustand auftreten darf. Dies ist eine sogenannte Verknüpfung der Art 1:n. Ein Raumelement, vertreten durch seine ID, hingegen darf nur genau einmal in der Verknüpfungstabelle Teilchenzustand auftreten. Somit ist sichergestellt, dass in einem Raumelement immer nur genau ein Teilchen mit genau einem Zustand existieren kann. Diese Art der Verknüpfung nennt man 1:1. Darüber hinaus legt das obige Schema noch fest, dass nicht alle Raumelemente des Kosmos in der Datenbank abgebildet werden müssen. Die Datenbank erzwingt mitnichten, dass alle theoretisch möglichen Raumelemente auch tatsächlich mit Werten versehen. Auch macht das Datenbankschema keine Aussage dazu, ob bestimmte Datensätze gelöscht werden dürfen oder nicht. | <= Zustände von Teilchen in Raumelementen | |||||
| [24] An dieser Stelle endet die Modellierung eines unbeseelten Kosmos als Datenbankschema. In dem obigen Schema können beliebige Gesamtzustände eines in jederlei Hinsicht gestückelten Kosmos abgebildet werden. Das Datenbankschema selbst sagt aber noch nichts darüber, wie der Kosmos von einem Zustand zum nächsten kommt. Dies zu regeln ist Aufgabe der Naturgesetze. | ||||||
Die Modellierung der Naturgesetze in Triggern |
||||||
| [25] In der Regel benutzt man Datenbanken zum geregelten Speichern von Daten und nicht unbedingt dazu, Programme auf ihnen zu schreiben. Programme werden üblicherweise in Dateien abgelegt. Das Programm greift dann nach einem Aufruf auf die Datenbank zu und manipuliert gegebenenfalls die dortigen Daten. Für komplexe Datenbankanwendungen trennt man also in der Regel die Datenspeicherung im engeren Sinne von deren Bearbeitung durch spezielle Anwendungen. Dies macht insbesondere dann Sinn, wenn verschiedene Anwendungen auf einen gemeinsamen Datenbestand zugreifen sollen und die Programmierer der Anwendungen Probleme haben, sich dauerhauft abzustimmen um somit die korrekte Benutzung des gemeinsamen Datenbestandes zu garantieren. In so einem Fall wird die Pflege der Daten durch Regeln übernommen, die auf der Datenbank selbst realisiert sind. Die Datenbank verweigert dann nötigenenfalls eine nicht erlaubte Manipulation, wenn diese von einer externen Anwendung versucht wird. In diesem Sinne wollen wir auch unseren kosmischen Datenbestand möglichst gut gegen unerwünschte Manipulationen schützen und programmieren die Naturgesetze unmittelbar auf der Datenbank. Programme auf der Datenbank nennt man "Trigger". | <= Datenbanktrigger statt Anwendungen in Dateiformat | |||||
| [26] Die Trigger müssen also regeln, wie die Inhalte der Datenbank ihre Zustände ändern. Im Hinblick auf später einzuführende Endanwender der Datenbank soll festgelegt werden, dass sich die Zustände der Datenbankinhalte auf eine halbwegs nachvollziehbare Weise ändern. | ||||||
| [27] Nachvollziehbar soll heißen, dass es eine erkennbare Kausalität gibt. "Nachvollziehbar" heißt aber auch "grundsätzlich vorhersagbar". Ebenfalls im Hinblick auf die später einzuführenden Endanwender der Datenbank soll es jedoch begrenzte Möglichkeiten einer Einflussnahme geben. Jeder Endanwender soll das Geschehen, welches in der Datenbank erzeugt wird, etwas mitgestalten dürfen. Dazu dürfen die Naturgesetz-Trigger nicht zu starr programmiert sein. Neben der Kausalität programmieren wir etwas Pseudo-Zufall hinein. Hinter dem Pseudo-Zufall können sich dann die Endwander unbemerkt verstecken und unerkannte Manipulationen von Datenbeständen vornehmen. Ein guter Kompromiß zwischen kausalitätsbasierter Nachvollziehbarkeit und benutzerfreundlichen Gestaltungsfreiräumen ist die Formel: | <=
Nachvollziehbar und trotzdem gestaltungsoffen
|
|||||
Statistisch nachvollziehbar und im Einzelfall unbestimmt |
Das Wesen der Quantenphysik |
|||||
| [28] Wenden wir uns jetzt einem konkreten Fall zu. Es soll etwas mit einem Raumelement geschehen. Entweder soll eine neue Teilchenart in das gleichnamige Datenbankfeld eingespielt werden oder der Zustand soll sich ändern oder aber beides soll passieren. Wir wollen dabei der Forderung gerecht werden, dass diese Art einer Änderung nach gewissen Regelmäßigkeiten erfolgt. Wir könnten zum Beispiel sagen, dass eine neue Teilchenart nur in Abhängeit der aktuell in dem Datenfeld vorhanden Teilchenart eingefügt werden darf: Grüne Teilchen dürfen nur durch gelbe und rote, nicht aber durch blaue oder graue Teilchen ersetzt werden. Auch mit dem Zustand könnten wir so verfahren: Für grüne und gelbe Teilchen ist ein Zustand immer gleich dem Durchschnitt dem ganzzahligen Anteil der Zustände der 1000 nächstliegenden Nachbarraumelemente. Für alle andersfarbigen Teilchen ist der Zustand gleich dem ganzzahligen Anteil des Durchschnittes der 500 nächstliegenden Raumelemente. Hat sich einmal ein Zustand geändert, so müssen gegebenfalls die Zustände benachbarter Raumelemente aktualisiert werden. | ||||||
| [29] Was aber ist mit unserer Forderung, dass die später einzuführenden Endanwender selbst auch etwas mitgestalten dürfen? Dazu müssen wir doch die Regeln etwas aufweichen. Das kann zweckmäßigerweise über deren Formulierung als Wahrscheinlichkeitsgesetze passieren: | Ein Mechanismus zur Vermischung von Zufall,
Gesetzlichkeit und Einflussnahme |
|||||
| ... | ||||||
Literatur über die Welt als Computersimulation Wolfram, S.: A New Kind of Science. Wolfram Media, Champaign. 1197 Seiten. Erschienen: 2002. ISBN: 1579550088 Lem, S.: Sterntagebücher.
Polnischer Originaltitel: Dzienniki Gwiazdowe, erschienen
um 1971. Arendes, L.: Quantenmechanik aus der Sicht des Computerweltbildes. Auf der Internetseite: http://home.t-online.de/home/Lothar.Arendes/cwb.htm |
Stephen Wolfram modelliert die Welt als Zellularautomaten.
|
|||||
|
|
