Frank Kalis

Inzwischen besitze ich eine ganze Reihe von Büchern von Joe Celko, und ich muss sagen, dass mit jedem Buch der Deja-Vu Effekt ansteigt.

Vieles von dem, was in "Thinking in sets" geboten wird, kann man in der einen oder anderen Form auch in früheren Büchern, und natürlich auch in den diversen Communities, in denen Celko präsent ist, nachlesen.

Ganze Geschichte »

Man muß nicht einmal besonders genau hinschauen, um zu sehen, daß die meisten Applikationen mit Daten in dieser oder jener Form arbeiten. Oftmals sind diese Daten in einer Datenbank gespeichert, so daß man davon ausgehen kann, daß die meisten Software Entwickler mehr oder weniger regelmäßig mit Datenbanken arbeiten. Nun ist aber Datenbankprogrammierung etwas anders als Applikationsprogrammierung und von daher ist es nicht selbstverständlich, daß ein guter Applikationsentwickler gleichzeitig auch ein guter Datenbankentwickler ist. Dabei spielt es übrigens keine Rolle, ob als Datenbanksystem eine Desktopdatenbank wie Microsoft Access zum Einsatz kommt oder ein ausgereifter relationaler Datenbank-Server wie der Microsoft SQL Server. Paradigmen, Grundsätze und Richtlinien, die für Applikations Entwicklung gelten, gelten nicht auch zwangsläufig für die Datenbankentwicklung und können teilweise sogar eher gegenläufig sein. Dennoch gibt es auch in der Datenbankentwicklung einen deutlichen Bedarf an Regeln und Richtlinien für die Entwicklung und hier kommt das vorliegende Buch ins Spiel. Sein Autor, Joe Celko, zählt zu den prominentesten Vertretern der Datenbank Community und hat einige der besten Bücher über SQL Programmierung im Allgemeinen geschrieben. Dieses Buch jedoch ist anders. Es zeigt einem nicht, wie man ein "besserer" SQL Entwickler wird, indem es Lösungen und Tricks zu SQL Rätseln und Brainteasern präsentiert. Dieses Buch will vermitteln, wie man in logischen und deklarativen Begriffen denkt und arbeitet.

Folgendes kann man in dem Buch lesen:

• Names and Data Elements
• Fonts, Punctuation, and Spacing
• Data Declaration Language
• Scales and Measurements Data Encoding Schemes
• Coding Choices
• How to use VIEWS
• How to write Stored Procedures
• Heuristics
• Thinking in SQL
• Resources
• Bibliography

Auf den über 200 Seiten präsentiert Celko seine Sicht eines Frameworks, innerhalb welchem Datenbankentwicklung erfolgen sollte. Sei dies eine Diskussion darüber, was eine gute Namenskonvention ausmacht oder wie SQL Code geschrieben und eingerückt werden sollte. Sei dies eine Diskussion darüber, ob Auto-Nummern (auch bekannt als SQL Server's IDENTITY Eigenschaft) ein guter Schlüssel sind oder wo im Code CHECK Einschränkung platziert werden sollten.

Einige der präsentierten Regeln sind (hoffentlich) gesunder Menschenverstand, für manche anderen existieren internationale Standards und weitere wiederum sind eher Celko-spezifisch. Sämtliche Regeln werden zusammen mit einer Begründung und gegebenenfalls Ausnahmesituationen für die jeweilige Regel angeführt. Dies macht aus dem Buch eher eine Art Nachschlagewerk, welches man im Zweifelsfall zu Rate zieht, als ein "normales" Buch, welches man Kapitel für Kapitel von vorne bis hinten liest. Auch wenn man in manchen Punkten nicht unbedingt mit Joe Celko übereinstimmen muß, kann man dieses Buch hervorragend als Grundlage nehmen, um darauf seine eigenen Programmierstil Richtlinien aufzubauen.

Zweifelsohne gibt es einen Bedarf an solchen Richtlinien, und so ist, zum Beispiel, die schlechteste Namenskonvention, immer noch besser als gar keine. Aber es macht das Leben eines Datenbankentwicklers (und, wahrscheinlich noch wichtiger, das Leben desjenigen, der den ursprünglichen Code pflegen muß) deutlich einfacher, wenn ein klarer und konsistenter Programmierstil angewendet wird. Viele der Regeln in diesem Buch sind nicht wirklich neu für Leute, die den Online Communities folgen, an denen Joe Celko ebenfalls partizipiert, aber dieses Buch fasst diese Regeln sehr schön an einem einzigen, greifbaren Ort zusammen und das allein bietet schon genug Anreiz zu Kauf.

SQL Programming Style Joe Celko 2005 Morgan Kaufmann 272 Seiten ISBN 0-12-088797-5

What exactly is first normal form?
What's the connection between relations and predicates?
What's semantic optimization?
What's a join dependency?
Why is semidifference important?
Why doesn't deferred integrity checking make sense?
What's a relational variable?
What's nonloss decomposition?
Can a relation have attributes whose values are relations?
What's the difference between SQL and the relational model?
Why is the information principle important?
How does XML fit in the relational model?

Provokante Fragen, nicht wahr?

Ganze Geschichte »

Vor ca. 2500 Jahren schrieb Sunzi ein Buch, welches mit den Worten beginnt.

"Die Kunst des Krieges ist für den Staat von entscheidender Bedeutung. Sie ist eine Angelegenheit von Leben und Tod, eine Straße, die zur Sicherheit oder in den Untergang führt. Deshalb darf sie unter keinen Umständen vernachlässigt werden."

Ganze Geschichte »

Hin und wieder stößt man in Online Communities auf Fragen wie "Kann ich Daten vor dem Datenbankadministrator verbergen?" oder "Wie kann ich verhindern, daß Systemadministratoren meine Daten lesen?" Und oft ist die Antwort darauf: "Einen Datenbankadministrator kann man nicht daran hindern, die Daten einer Datenbank einzusehen. Warum auch? Schließlich braucht der Administrator vollen Zugriff im Falle eines Falles. Und wenn man schon seinen Administratoren nicht mehr trauen kann, hat man wahrscheinlich noch ganz andere Probleme." oder "Wenn schon, dann sollten die Daten im Front-End verschlüsselt werden und danach in der Datenbank gespeichert werden. Datenbankverschlüsselung allein ist schwach."

Datensicherheit ist teilweise ein sträflich vernachlässigtes Thema. Zumindest was die Sicherheit anbetrifft, die nach der Firewall und Intrusion Detection Systemen kommt und sich unternehmensintern abspielt. Medienwirksamer sind zweifelsohne die spektakulären Nachrichten darüber, daß irgendjemand in irgendein Netzwerk eingedrungen ist und dort Schaden angerichtet hat. Nachrichten über "interne Hacker" gerade naturgemäß selten nach außen und an die Medien.
Der interne "Angreifer" hat den Vorteil, daß er sich bereits hinter dem äußeren Wall befindet, Zugriff auf das Netzwerk hat und auch mehr oder weniger ausgeprägte Kenntnisse über die Netzwerktopologie besitzt. Gerade als Datenbankadministrator ist man hier in einer sehr priviligierten Position. Nicht nur hat man bereits den Zugriff auf sämtliche in der Datenbank gespeicherten Daten, sondern als Admin ist man auch in der Lage, die Spuren einer solchen eventuellen Attacke zu verwischen. Kryptographie kann helfen, dieses latente Sicherheitsrisiko zu minimieren. Doch Datenbank-Kryptographie alleine ist nicht genug. Um ein Höchstmaß an Sicherheit zu erzielen muß man eine komplette kryptographische Infrastruktur errichten.

Damit ist im Groben der Inhalt dieses Buches wiedergegeben. Auf ca. 270 Seiten entwickelt der Autor solch eine kryptographische Infrastruktur bzw. gibt genügend Ideen, um eine solche in seiner eigenen IT-Landschaft zu erstellen oder Produkte von Drittanbietern auf ihre Zweckmäßigkeit einschätzen zu können.

Der Autor leitet Symantec's IT Applikations- und Datenbanksicherheits-Programm und sorgt in dieser Position dafür, daß die internen Systeme von Symantec sicher sind. Die Beispiele werden anhand von MySQL als Datenbanksystem und Java als Programmiersprache präsentiert, aber diese sollten ohne größere Schwierigkeiten auch auf andere Datenbanksysteme und Sprachen übertragbar sein. Der komplette Source Code seines Kryptographie Projektes ist downloadbar von der Webseite des Verlages.

Lesenswert ist dieses Buch vor allem für Leute, die an Projekten oder in Umgebungen arbeiten, für die Sicherheit die oberste Priorität ist. Seien es nun Systemarchitekten, Systemanalysten, Entwickler oder auch Risikomanager, die jedoch zumindest über Grundkenntnisse in der Kryptographie verfügen sollten.

Cryptography in the Database Kevin Kenan 2005 Addison-Wesley ISBN 0-321-32073-5

Man stelle sich man die folgende hypothetische Situation vor: Eine Firma existiert bereits seit Jahren und ist stetig über diesen Zeitraum gewachsen. Am Anfang war vielleicht ein UNIX System, ein Großrechner oder eine AS/400 auf der die ersten unternehmensweit vitalen Daten lagen. Über die Jahre hinweg tauchten andere Plattformen und Betriebssysteme wie Windows und/oder Linux, auf. Diese liefen dann auf den Rechnern der Anwender in den verschiedenen Abteilungen der Firma. Die Anwender in diesen Abteilungen adaptierten schnell die neuen Systeme und entwickelten ihre eigenen Lösungen für ihre jeweiligen Bedürfnisse. Die Anzahl der Schnittstellen zwischen den diversen System wuchs beständig und die Daten wurden redundant in zahlreichen Systemen in teilweise verschiedenen Aggregationsstufen gehalten. Da die Firma rasch wuchs, war nie genug Zeit vorhanden, die vorhandenen Systeme systematisch zu erfassen und zu dokumentieren. Niemand störte sich großartig an diesem Zustand. Falls die IT Abteilung überhaupt von diesen "Stealth" Systemen wußte, da nahezu in jeder Abteilung ein "Power User" in der Lage ist, eine Tabellenkalkulations- oder eine Desktop-Datenbank Lösung zu erstellen. So lange alles ohne Probleme läuft, stört sich niemand an diesem Chaos in der IT Infrastruktur. Aber wehe, wenn etwas mit einem Fehler abbricht. Im Zweifel haben die ursprünglichen Entwickler die Firma bereits vor Jahren verlassen und aufgrund der unzureichenden Dokumentation weiß niemand so ganz genau, was denn der Code eigentlich macht. Daher kommt es öfters mal vor, daß die Beseitigung eines Fehlers an ganz anderer Stelle nun zu einem neuen Fehler führt, da auch die Abhängigkeiten zwischen den einzelnen Systemen unbekannt sind. Die IT Abteilung ist kaum noch in der Lage, das Chaos unter Kontrolle zu halten und anstatt sich auf ihre eigentliche Aufgabe, der Optimierung von IT Prozessen, zu konzentrieren, spielt die Abteilung nur noch Feuerwehr und löscht einen Brand nach dem anderen. Wie...??? Das klingt nicht allzu hypothetisch? Das klingt vielleicht sogar bekannt?

Nun, ich glaube, daß es in der überwiegenden Mehrzahl aller Firmen mehr oder weniger so aussieht. Und genau hier setzt auch das vorliegende Buch an. Es befaßt sich nicht mit Datenbanken in dem Sinne, wie man durch Administration oder Entwicklung eines Datenbanksystems, eine Datenstrategie implementiert. Dieses Buch abstrahiert wesentlich stärker und betrachtet das Thema eher aus der Vogelperspektive. Es beschreibt die Vorteile, die eine homogene IT Infrastruktur bietet und die Vorteile, die die gesamte Firme hat, wenn man sich auf einige wenige Kerntechnologien beschränkt, um diese homogene Infrastruktur zu schaffen. Von daher sollte man auch keine spektakulären neuen Erkenntnisse erwarten. Es werden keine wirklich innovativen, tiefgreifenden Einblicke geboten, die man nicht sowieso haben sollte, sofern man als IT Mensch mit offenen Augen durch die Welt geht. Zugegebenermassen hilft es aber doch von Zeit zu Zeit immer mal wieder, darüber zu lesen.

Dieses Buch wird seine Leser polarisieren. Natürlich ist es aus der IT Perspektive heraus wünschenswert, sich auf einige wenige Kernsysteme konzentrieren zu können, um dadurch besseren allgemeinen Service leisten zu können. Dies aber in der Wirklichkeit zu erreichen ist gleichwohl äußerst schwer. Die Gründe dafür sind vielfältig. Sie beginnen mit der Nichtverfügbarkeit von IT System auf bestimmten Plattformen, bzw. falls sie verfügbar sind, bieten sie nicht die geforderte Funktionalität. Weiter geht's vielleicht damit, daß das Management nicht bereit ist, viel Geld für ein System auszugeben, welches die Kernsysteme unterstützt, wenn es auch andere Systeme gibt, die wesentlich weniger kosten, evtl. im Falle von Open Source, vielleicht sogar kostenlos sind, aber leider nur andere Technologien unterstützen. Darüberhinaus mag man vielleicht auch argumentieren, daß die Migration von System A auf System B eine nicht zu unterschätzende Aufgabe darstellt, die sehr zeit- und kostenintensiv ist und eine sorgfältige Vorbereitung erfordert. Zu guter Letzt gibt es auch gute Gründe für das Argument, daß eine Firma sich nicht 100% von einem einzigen Betriebssystem oder einem einzigen Datenbanksystem abhängig machen will und deshalb absichtlich mehrgleisig fährt. Es gibt noch viele weitere Gründe, die wahrscheinlich schon jeder mal gehört hat. Deshalb spare ich sie mir hier an dieser Stelle.

Es fällt mir nicht leicht, eine Empfehlung zu diesem Buch zu unterbreiten. Es ist sicherlich erstklassig geschrieben, gut lesbar und man merkt, daß die Autoren anerkannte Fachleute auf ihrem Gebiet sind. Der wahrscheinlich in den meisten Firmen vorherrschende Status Quo wird klar analysiert, aber die Schlußfolgerung, sich auf einige wenige Kernsysteme zu konzentrieren, ist nicht so einfach, wie in dem Buch beschrieben. Während es in der Theorie natürlich logisch und einleuchtend ist, ist die reale Welt myriadenfach komplexer in all ihren Facetten und so eine Entscheidung trifft man nicht so einfach, da sie eine Firma in ihrem Kern trifft.

Falls Sie IT Manager sind, der noch Argumente für seinen Kampf mit der Geschäftsführung sucht, werden Sie dieses Buch interessant und hilfreich finden. Falls Sie DBA oder Entwickler sind, machen Sie zwar nichts falsch, wenn Sie mal hin und wieder ein solches Buch lesen. Ich halte es aber nicht für eine notwendige Literatur, die Sie zwingend für Ihren Job brauchen. Und deshalb sollten Sie, wie eigentlich immer, sich dieses Buch vor einem Kauf genau ansehen.

Data Strategy von Adelman, Moss und Abai 2005 Addison-Wesley ISBN: 0-321-24099-5