Datenbank: Unterschied zwischen den Versionen
Sebus (Diskussion | Beiträge) K |
K |
||
| (7 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt) | |||
| Zeile 9: | Zeile 9: | ||
== Lebensraum == | == Lebensraum == | ||
| − | Oft befinden sich diese Bänke an [[Haltestelle|Bushalte]]- und [[Straßenbahn]]stationen. Allerdings kann man sie auch in [[Park]]s und an anderen Orten antreffen. Sie leben friedlich neben dem [[Mensch]]en, sind für'n Arsch und haben sich auf der ganzen [[Welt]] in ihren | + | Oft befinden sich diese Bänke an [[Haltestelle|Bushalte]]- und [[Straßenbahn]]stationen. Allerdings kann man sie auch in [[Park]]s und an anderen Orten antreffen. Sie leben friedlich neben dem [[Mensch]]en, [[Lotus Notes|sind für'n Arsch]] und haben sich auf der ganzen [[Welt]] in ihren bevorzugten Regionen angesiedelt. |
== Erkennungsmerkmale == | == Erkennungsmerkmale == | ||
| Zeile 25: | Zeile 25: | ||
Typische [[Kommunikation]] in einer [[Firma]]:<br />[[Chef]]: ''„Wir brauchen auch eine SQL-Datenbank!“''<br />[[Angestellte]] denkt: ''„Weiß er wovon er spricht oder hat er das nur wieder irgendwo aufgeschnappt?“'' sagt: ''„OK, welche [[Farbe]] soll sie denn haben?“''<br />Chef: ''„Nun, ich denke [[gelb]] hat am meisten [[RAM]]!“'' | Typische [[Kommunikation]] in einer [[Firma]]:<br />[[Chef]]: ''„Wir brauchen auch eine SQL-Datenbank!“''<br />[[Angestellte]] denkt: ''„Weiß er wovon er spricht oder hat er das nur wieder irgendwo aufgeschnappt?“'' sagt: ''„OK, welche [[Farbe]] soll sie denn haben?“''<br />Chef: ''„Nun, ich denke [[gelb]] hat am meisten [[RAM]]!“'' | ||
| + | |||
| + | == Entity-Relationship Modell == | ||
| + | |||
| + | In der Theorie sind Datenbanken noch komplexer, als es eigentlich scheint. | ||
| + | Um eine einfachere Beschreibung von Datenbanken zu ermöglichen, entwickelte [[Heinrich]] Justin von Kot (wird "Codd" ausgesprochen) das sogenannte "Entity-Relationship Modell". Während seiner Promotion an der Volkshochschule Frankfurt-Bockenheim kam ihm die Idee, Leute, die sich mit Datenbanken beschäftigen (''Entities''), bräuchten eine feste Beziehung (''Relation'') zu einer [[Frau]], am besten zu einem ''Model''. | ||
| + | Somit könne man tausende [[Informatiker]] davon abhalten, ihre kostbare Zeit mit sinnlosen Angelegenheiten wie dem Studium der Datenbanken zu verschwenden, statt sich der Fortpflanzung zu widmen. | ||
| + | Heinrich Justin von Kot ließ im Jahre 1829 seine [[Idee]] auf deutschen Lehrplänen für das Fach Informatik niederschreiben. Er hoffte dadurch einen demographischen Wandel verhindern zu können. | ||
| + | Kots Gegenspieler, Alan Harper, versuchte 1951 erfolglos, diesen [[Plan]] zu vereiteln. | ||
| + | |||
| + | == DDL == | ||
| + | Dumpfe Date Loser - dient zur Qualifizierung der Datenden und verwirft dabei notwendigerweise nicht normalisierte [[Kandidat]]en. | ||
| + | |||
| + | == Zugriffskontrolle == | ||
| + | Besitzen mindestens zwei Entitäten adäquate Eigenschaften, so wird nach einem erfolgreichen Inner-Join zum vorhandenen Primärschlüssel ein Foreign-Key erzeugt. | ||
| + | Da bei solchen Vorgängen immer [[Auto]]-Commit aktiv ist, ist ein späteres [[Rollback]] aller folgenden Transaktionen nicht mehr möglich. | ||
| + | Wird im Nachgang durch mindestens eine der Entitäten eine vorher gesetzte unique-constraint Bedingung verletzt, führt dieses unweigerlich zur [[CO2|Emission]] mindestens einer [[Fehlermeldung]] seitens des Modells, in aller [[Regel]] jedoch zu einem Splitting der verknüpften Entities, wobei dann ein bei der Initialisierung gesetztes Inherit wirksam wird. | ||
Aktuelle Version vom 24. Juni 2016, 08:53 Uhr
Die Datenbank ist ein Ort zur Speicherung und Vermehrung von Daten. Dateninstitute gewähren bei der Anlage von Daten Zinsen in Höhe von derzeit 3 Prozent. Je mehr Daten gespart und zur Bank gebracht werden, desto besser für die Volkswirtschaft. Nachteilig für das Datensparen ist die Dateninflation (Gegenteil von Datenkompression).
Zur kurzfristigen Speicherung der Daten im Arbeitsspeicher sind eher verzettelte Listen geeignet.
Inhaltsverzeichnis
Datenbank [die],
Die Datenbank (DB) ist eine aus Daten bestehende Bank zum hinsetzen und daten.
Lebensraum
Oft befinden sich diese Bänke an Bushalte- und Straßenbahnstationen. Allerdings kann man sie auch in Parks und an anderen Orten antreffen. Sie leben friedlich neben dem Menschen, sind für'n Arsch und haben sich auf der ganzen Welt in ihren bevorzugten Regionen angesiedelt.
Erkennungsmerkmale
In der Regel sind Datenbanken von Informationen aller Art besetzt.
Kommunikation
Mit Botschaften wie:
- "Ich war hier am 10. Juni 753 v.Chr."
- "Schatz, ich liebe dich"
- "Christian, so nicht!"
versuchen sie mit der Menschheit in Kontakt zu treten. Derzeit wird ein Kommunikationssystem Mensch - Dat / Dat - Mensch entwickelt.
Typische Kommunikation in einer Firma:
Chef: „Wir brauchen auch eine SQL-Datenbank!“
Angestellte denkt: „Weiß er wovon er spricht oder hat er das nur wieder irgendwo aufgeschnappt?“ sagt: „OK, welche Farbe soll sie denn haben?“
Chef: „Nun, ich denke gelb hat am meisten RAM!“
Entity-Relationship Modell
In der Theorie sind Datenbanken noch komplexer, als es eigentlich scheint. Um eine einfachere Beschreibung von Datenbanken zu ermöglichen, entwickelte Heinrich Justin von Kot (wird "Codd" ausgesprochen) das sogenannte "Entity-Relationship Modell". Während seiner Promotion an der Volkshochschule Frankfurt-Bockenheim kam ihm die Idee, Leute, die sich mit Datenbanken beschäftigen (Entities), bräuchten eine feste Beziehung (Relation) zu einer Frau, am besten zu einem Model. Somit könne man tausende Informatiker davon abhalten, ihre kostbare Zeit mit sinnlosen Angelegenheiten wie dem Studium der Datenbanken zu verschwenden, statt sich der Fortpflanzung zu widmen. Heinrich Justin von Kot ließ im Jahre 1829 seine Idee auf deutschen Lehrplänen für das Fach Informatik niederschreiben. Er hoffte dadurch einen demographischen Wandel verhindern zu können. Kots Gegenspieler, Alan Harper, versuchte 1951 erfolglos, diesen Plan zu vereiteln.
DDL
Dumpfe Date Loser - dient zur Qualifizierung der Datenden und verwirft dabei notwendigerweise nicht normalisierte Kandidaten.
Zugriffskontrolle
Besitzen mindestens zwei Entitäten adäquate Eigenschaften, so wird nach einem erfolgreichen Inner-Join zum vorhandenen Primärschlüssel ein Foreign-Key erzeugt. Da bei solchen Vorgängen immer Auto-Commit aktiv ist, ist ein späteres Rollback aller folgenden Transaktionen nicht mehr möglich. Wird im Nachgang durch mindestens eine der Entitäten eine vorher gesetzte unique-constraint Bedingung verletzt, führt dieses unweigerlich zur Emission mindestens einer Fehlermeldung seitens des Modells, in aller Regel jedoch zu einem Splitting der verknüpften Entities, wobei dann ein bei der Initialisierung gesetztes Inherit wirksam wird.
