Was alternative Datenbanken jenseits von Skalierung bieten. NoSQL Datenbanken bieten sich an, um hochskalierende Anwendungen auf Hunderten von Nodes zu realisieren. Stimmt. Das ist aber nicht alles. Nicht-relationale Datenbanken bieten jenseits von Performanz interessante Features, die man auch in Projekten gebrauchen kann, die nicht die Nutzerzahlen von Twitter und Facebook erreichen. Dieser Vortrag greift Aspekte wie Schemafreiheit, Multi-Model-Datemodellierung und "Database as application server" auf und zeigt, wie man diese sinnvoll in Projekten einsetzen kann und was dabei zu beachten ist.
Performance-Analyse von Oracle-Datenbanken mit PanoramaPeter Ramm
Panorama ermöglich schnelle Analyse des Betriebsverhaltens von Oracle-DB mit diversen Workflows als Alternative zum manuellen Hantieren mit SQL-Skripten.
Es unterstützt ebenso die detaillierte Analyse zurückliegender Ereignisse plus diverse andere Funktionen, die ich teilweise in anderen etablierten Tools vermisste.
Einführung aus den Perspektiven Site Builder, Developer, Themer & Community
http://www.drupal-austria.at/veranstaltungen/drupal-roadshow-klagenfurt
Christian Ziegler
Wolfgang Ziegler
Nico Grienauer
Josef Dabernig
Was alternative Datenbanken jenseits von Skalierung bieten. NoSQL Datenbanken bieten sich an, um hochskalierende Anwendungen auf Hunderten von Nodes zu realisieren. Stimmt. Das ist aber nicht alles. Nicht-relationale Datenbanken bieten jenseits von Performanz interessante Features, die man auch in Projekten gebrauchen kann, die nicht die Nutzerzahlen von Twitter und Facebook erreichen. Dieser Vortrag greift Aspekte wie Schemafreiheit, Multi-Model-Datemodellierung und "Database as application server" auf und zeigt, wie man diese sinnvoll in Projekten einsetzen kann und was dabei zu beachten ist.
Performance-Analyse von Oracle-Datenbanken mit PanoramaPeter Ramm
Panorama ermöglich schnelle Analyse des Betriebsverhaltens von Oracle-DB mit diversen Workflows als Alternative zum manuellen Hantieren mit SQL-Skripten.
Es unterstützt ebenso die detaillierte Analyse zurückliegender Ereignisse plus diverse andere Funktionen, die ich teilweise in anderen etablierten Tools vermisste.
Einführung aus den Perspektiven Site Builder, Developer, Themer & Community
http://www.drupal-austria.at/veranstaltungen/drupal-roadshow-klagenfurt
Christian Ziegler
Wolfgang Ziegler
Nico Grienauer
Josef Dabernig
Oracle-DB: Panorama-Sampler - Eigenes Workload Repository für PanoramaPeter Ramm
Panorama-Sampler erlaubt die rückwirkende Bewertung von Betriebszuständen der Oracle-DB durch aktive Aufzeichnung der Historie.
Ähnlich dem AWR der Enterprise Edition werden diverse Aspekte protokolliert, inkl. Session- und SQL-Historie.
Rückwirkende Betrachtungen werden somit möglich ohne Lizenzierung des Diagnostics Pack und damit auch nutzbar für Standard Edition.
Der Datenbank-Backup ist gemacht - was nun?FromDual GmbH
* Datenbank-Backup – welcher Zweck?
* Tauglichkeit des Backup, Verifikation
* Echtdaten vollständig nutzen
* Dem Datenschutz genügen
* Material für die Entwicklung
* Automatisierung
Hand auf's Herz: Wusstest Du, dass Taylor die Work-Life-Balance erfunden hat?
Vermutlich nicht. Da ist im Laufe der Geschichte ein bisschen was schief gelaufen und verloren gegangen.
Damit das so nicht nochmal passiert, stelle ich die Frage: Was können Agilisten vom Taylorismus über New Work lernen?
Auf jeden Fall, wie eine eigentlich gute Idee, die aus moralisch integeren Motiven heraus sinnvolle und praktikable Konzepte beschreibt, kaputt geht. Denn vieles, was den Taylorismus zu dem hat werden lassen, das wir heute wieder aus der Arbeitswelt entfernen möchten, passiert genau jetzt auf die gleiche Weise wieder mit Bergmanns Ideen.
Dieser Vortrag ist mitnichten ein Plädoyer für eine Rückkehr zum Taylorismus, ebensowenig eines für Bergmanns New-Work-Ideen. Ich werde aber aus den Büchern beider vorlesen und zeigen, dass sie mit ihrem Bild von Arbeit gar nicht weit voneinander entfernt sind. Und warum das Verstehen um die Evolution des Taylorismus umso wichtiger ist, wenn New Work Realität werden soll.
Conway’s Law & Soziologie in der Software-ArchitekturGerrit Beine
Mit diesem Vortrag soll Conway’s Law aus einer Perspektive betrachtet werden, die in der IT üblicherweise gar nicht vorkommt: Systemtheorie & Konstruktivismus. Was denken Software-Architekten über Software- Architekten, die Software-Architekten beim Systemdesign beobachten? Und warum beeinflusst uns das mehr, als die Anzahl der Teile aus denen unsere Organisation besteht? Was unterscheidet eigentlich ein IT-System von einem sozialen System?
Beyond User Stories - Backlogs priorisieren, wenn es anspruchsvoll wirdGerrit Beine
Die Entscheidungen, die ein Product Owner bei der Priorisierung des Backlogs treffen muss, sind alles andere als einfach.
Was ist wichtiger: Security oder Usability?
Kommt als nächstes ein weiteres Feature oder werden technische Schulden abgebaut?
Welche der drei Funktionen soll als erstes realisiert werden?
In diesem Vortrag werden Wege vorgestellt, wie man diese Entscheidungen treffen kann und zwischen den hunderten Anforderungen nicht die Balance verliert.
Angeknüpft wird immer dort, wo die gängigen Modelle wie Business Modelling, Value Proposition oder Story Mapping aufhören - immer geleitet von der Frage: Wie kann eine Product Ownerin all die Ideen, Wünsche und Notwendigkeiten operationalisieren?
Dabei geht es auch um Anschlussfähigkeit agiler Anforderungsprozesse in klassischen Organisationen, mit all den anspruchsvollen Rahmenbedingungen, die Product Ownership in solchen Umgebungen mit sich bringt.
Was lernen die Zuhörer in dem Vortrag?
Wie funktionieren Backlog-Strukturen aus einer Anforderungsperspektive?
Wie funktioniert ein Anforderungsprozess, der ein Backlog strukturiert füllt?
Was macht das Scrum-Team in Anforderungsmanagement?
Wie treffe ich als Product Owner Entscheidungen zu Anforderungen?
Was passiert mit alten Anforderungen?
Wie balanciere ich konkurrierende Anforderungen aus?
Gut genug - Rahmenbedingungen für agile ArchitekturenGerrit Beine
Das elfte Prinzip des agilen Manifests besagt, dass die besten Architekturen in selbstorganisierten Teams entstehen. Aber wann benötigen wir die besten Architekturen? Und wie entstehen eigentlich Architekturen, die gut genug sind?
Dieser Vortrag ist eine kritische Auseinandersetzung mit der nicht immer leichten Beziehung zwischen agiler Softwareentwicklung und Softwarearchitektur. Es geht um den Architectural Runway, Architektur-Kanban und Tiger-Teams. Es geht um Communities of Practise, Senior-Softwarearchitekten und die Grenzen der Selbstorganisation. Und um Schwarmintelligenz und Schwarmdummheit in der Architektur. Darum, wie gute Architekten Patterns bauen und mit Optionen jonglieren. Es geht um die Frage, ob ein Scrum-Team einen Architekten benötigt und wie diese Rolle skaliert werden kann, wenn das Projekt zu groß wird. Außerdem beantworte ich noch die Frage, was Softwarearchitekten von Thales von Milet über den Handel mit Olivenöl lernen können und warum sie nicht alles wissen müssen.
Beyond Agile – Ungewissheit mit der Real Option Theory meisternGerrit Beine
Ungewissheit und Unsicherheit sind im Projektgeschäft ständige Begleiter. Wie geht man damit um, und wie gelingt es, sie als Chance zu nutzen? Der Vortrag nähert sich dem Thema, indem wichtige Fragestellungen – wie etwa: Wie erkenne ich Ungewissheiten? In welcher Beziehung stehen Ungewissheiten in Projekten zu Wissen und Unwissen? Wann ist der richtige Moment, eine Ungewissheit aufzulösen? – erörtert werden.
Backlog Priorisierung 2020: Wertmodelle & Simulationen von Intangibles zur Pr...Gerrit Beine
Die richtige Priorisierung von Aufgaben ist entscheidend für den Projekterfolg. Der Vortrag demonstriert, wie mit Wertmodellen und Monte-Carlo-Simulationen Projektanforderungen optimal – am Kundennutzen orientiert – priorisiert werden. Als Beispiele dienen Softwareprojekte, in denen auch weiche Faktoren als Werttreiber eine wichtige Rolle spielen.
Backlog Priorisierung mit Cost of Delay & Monte Carlo SimulationenGerrit Beine
Das fünfte agile Wertepaar: Simulieren und Lernen über Planen und Schätzen
Die Entscheidungen, die ein Product Owner bei der Priorisierung des Backlogs treffen muss, sind alles andere als einfach.
Was ist wichtiger: Security oder Usability?
Kommt als nächstes ein weiteres Feature oder werden technische Schulden abgebaut?
Welche der drei Funktionen soll als erstes realisiert werden?
In diesem Vortrag wird ein Weg vorgestellt, der diese Entscheidungen leichter macht.
Dabei kommen zwei einfache Werkzeuge zum Einsatz: Wertmodelle und Monte Carlo-Simulationen.
Wertmodelle erlauben es, ein Thema hinsichtlich verschiedener Werttreiber zu erfassen und zu beschreiben.
Sie stellen eine elegante Möglichkeit dar, weiche Themen wie Usability und Security gegenüber von echten Features zu bewerten.
Damit eröffnen sie ganz neue Aspekte im Austausch mit Kunden und Anwendern.
Gleichzeitig bilden sie eine hervorragende Grundlage dafür, ein Backlog mit Hilfe einer Simulation zu priorisieren.
Priorisierungen, die auf einem solchen Weg entstehen, zeigen häufig überraschende Effekte und führen nicht selten zu besseren Entscheidungen.
Das macht diese Simulationen zu einer perfekten Ergänzung von Story Maps und anderen inhaltlich orientierten Methoden.
Feedback von Kunden und Anwendern zum gelieferten Produkt verbessert kontinuierlich das Wertmodell.
Diese Verbesserungen des Wertemodells wirken sich wiederum unmittelbar auf die Priorisierung des Backlogs aus und machen die Priorisierung zu einer leichten Aufgabe, die permanent passiert.
Im Vortrag wird anhand eines realen Großprojektes erklärt, wie Product Owner ein Wertmodell erstellen können,
wie es zur Simulation verwendet und wie daraus ein lernenes Wertmodell wird.
Die bisher einzige bekannte Methode, um den Wirkungsgrad von Führungskräften zu bewerten. Alle DAX-Unternehmen setzen es bereits ein. An den Fortune 500 arbeite ich gerade.
Der Product Owner ist maßgeblich für den Erfolg eines Projektes verantwortlich.
Warum der Product Owner für agile Projekte eine größere Bedeutung hat als ein Projektleiter und warum es für Projektleiter einen Karriereschritt bedeutet, Product Owner zu werden, möchte dieser Vortrag deutlich machen.
Dabei werden sowohl die unterschiedlichen Herangehensweisen des Projektmanagements gegenübergestellt als auch die Aspekte beleuchtet, die Product Owner gegenüber Projektleitern im Vorteil sein lassen.
Oracle-DB: Panorama-Sampler - Eigenes Workload Repository für PanoramaPeter Ramm
Panorama-Sampler erlaubt die rückwirkende Bewertung von Betriebszuständen der Oracle-DB durch aktive Aufzeichnung der Historie.
Ähnlich dem AWR der Enterprise Edition werden diverse Aspekte protokolliert, inkl. Session- und SQL-Historie.
Rückwirkende Betrachtungen werden somit möglich ohne Lizenzierung des Diagnostics Pack und damit auch nutzbar für Standard Edition.
Der Datenbank-Backup ist gemacht - was nun?FromDual GmbH
* Datenbank-Backup – welcher Zweck?
* Tauglichkeit des Backup, Verifikation
* Echtdaten vollständig nutzen
* Dem Datenschutz genügen
* Material für die Entwicklung
* Automatisierung
Hand auf's Herz: Wusstest Du, dass Taylor die Work-Life-Balance erfunden hat?
Vermutlich nicht. Da ist im Laufe der Geschichte ein bisschen was schief gelaufen und verloren gegangen.
Damit das so nicht nochmal passiert, stelle ich die Frage: Was können Agilisten vom Taylorismus über New Work lernen?
Auf jeden Fall, wie eine eigentlich gute Idee, die aus moralisch integeren Motiven heraus sinnvolle und praktikable Konzepte beschreibt, kaputt geht. Denn vieles, was den Taylorismus zu dem hat werden lassen, das wir heute wieder aus der Arbeitswelt entfernen möchten, passiert genau jetzt auf die gleiche Weise wieder mit Bergmanns Ideen.
Dieser Vortrag ist mitnichten ein Plädoyer für eine Rückkehr zum Taylorismus, ebensowenig eines für Bergmanns New-Work-Ideen. Ich werde aber aus den Büchern beider vorlesen und zeigen, dass sie mit ihrem Bild von Arbeit gar nicht weit voneinander entfernt sind. Und warum das Verstehen um die Evolution des Taylorismus umso wichtiger ist, wenn New Work Realität werden soll.
Conway’s Law & Soziologie in der Software-ArchitekturGerrit Beine
Mit diesem Vortrag soll Conway’s Law aus einer Perspektive betrachtet werden, die in der IT üblicherweise gar nicht vorkommt: Systemtheorie & Konstruktivismus. Was denken Software-Architekten über Software- Architekten, die Software-Architekten beim Systemdesign beobachten? Und warum beeinflusst uns das mehr, als die Anzahl der Teile aus denen unsere Organisation besteht? Was unterscheidet eigentlich ein IT-System von einem sozialen System?
Beyond User Stories - Backlogs priorisieren, wenn es anspruchsvoll wirdGerrit Beine
Die Entscheidungen, die ein Product Owner bei der Priorisierung des Backlogs treffen muss, sind alles andere als einfach.
Was ist wichtiger: Security oder Usability?
Kommt als nächstes ein weiteres Feature oder werden technische Schulden abgebaut?
Welche der drei Funktionen soll als erstes realisiert werden?
In diesem Vortrag werden Wege vorgestellt, wie man diese Entscheidungen treffen kann und zwischen den hunderten Anforderungen nicht die Balance verliert.
Angeknüpft wird immer dort, wo die gängigen Modelle wie Business Modelling, Value Proposition oder Story Mapping aufhören - immer geleitet von der Frage: Wie kann eine Product Ownerin all die Ideen, Wünsche und Notwendigkeiten operationalisieren?
Dabei geht es auch um Anschlussfähigkeit agiler Anforderungsprozesse in klassischen Organisationen, mit all den anspruchsvollen Rahmenbedingungen, die Product Ownership in solchen Umgebungen mit sich bringt.
Was lernen die Zuhörer in dem Vortrag?
Wie funktionieren Backlog-Strukturen aus einer Anforderungsperspektive?
Wie funktioniert ein Anforderungsprozess, der ein Backlog strukturiert füllt?
Was macht das Scrum-Team in Anforderungsmanagement?
Wie treffe ich als Product Owner Entscheidungen zu Anforderungen?
Was passiert mit alten Anforderungen?
Wie balanciere ich konkurrierende Anforderungen aus?
Gut genug - Rahmenbedingungen für agile ArchitekturenGerrit Beine
Das elfte Prinzip des agilen Manifests besagt, dass die besten Architekturen in selbstorganisierten Teams entstehen. Aber wann benötigen wir die besten Architekturen? Und wie entstehen eigentlich Architekturen, die gut genug sind?
Dieser Vortrag ist eine kritische Auseinandersetzung mit der nicht immer leichten Beziehung zwischen agiler Softwareentwicklung und Softwarearchitektur. Es geht um den Architectural Runway, Architektur-Kanban und Tiger-Teams. Es geht um Communities of Practise, Senior-Softwarearchitekten und die Grenzen der Selbstorganisation. Und um Schwarmintelligenz und Schwarmdummheit in der Architektur. Darum, wie gute Architekten Patterns bauen und mit Optionen jonglieren. Es geht um die Frage, ob ein Scrum-Team einen Architekten benötigt und wie diese Rolle skaliert werden kann, wenn das Projekt zu groß wird. Außerdem beantworte ich noch die Frage, was Softwarearchitekten von Thales von Milet über den Handel mit Olivenöl lernen können und warum sie nicht alles wissen müssen.
Beyond Agile – Ungewissheit mit der Real Option Theory meisternGerrit Beine
Ungewissheit und Unsicherheit sind im Projektgeschäft ständige Begleiter. Wie geht man damit um, und wie gelingt es, sie als Chance zu nutzen? Der Vortrag nähert sich dem Thema, indem wichtige Fragestellungen – wie etwa: Wie erkenne ich Ungewissheiten? In welcher Beziehung stehen Ungewissheiten in Projekten zu Wissen und Unwissen? Wann ist der richtige Moment, eine Ungewissheit aufzulösen? – erörtert werden.
Backlog Priorisierung 2020: Wertmodelle & Simulationen von Intangibles zur Pr...Gerrit Beine
Die richtige Priorisierung von Aufgaben ist entscheidend für den Projekterfolg. Der Vortrag demonstriert, wie mit Wertmodellen und Monte-Carlo-Simulationen Projektanforderungen optimal – am Kundennutzen orientiert – priorisiert werden. Als Beispiele dienen Softwareprojekte, in denen auch weiche Faktoren als Werttreiber eine wichtige Rolle spielen.
Backlog Priorisierung mit Cost of Delay & Monte Carlo SimulationenGerrit Beine
Das fünfte agile Wertepaar: Simulieren und Lernen über Planen und Schätzen
Die Entscheidungen, die ein Product Owner bei der Priorisierung des Backlogs treffen muss, sind alles andere als einfach.
Was ist wichtiger: Security oder Usability?
Kommt als nächstes ein weiteres Feature oder werden technische Schulden abgebaut?
Welche der drei Funktionen soll als erstes realisiert werden?
In diesem Vortrag wird ein Weg vorgestellt, der diese Entscheidungen leichter macht.
Dabei kommen zwei einfache Werkzeuge zum Einsatz: Wertmodelle und Monte Carlo-Simulationen.
Wertmodelle erlauben es, ein Thema hinsichtlich verschiedener Werttreiber zu erfassen und zu beschreiben.
Sie stellen eine elegante Möglichkeit dar, weiche Themen wie Usability und Security gegenüber von echten Features zu bewerten.
Damit eröffnen sie ganz neue Aspekte im Austausch mit Kunden und Anwendern.
Gleichzeitig bilden sie eine hervorragende Grundlage dafür, ein Backlog mit Hilfe einer Simulation zu priorisieren.
Priorisierungen, die auf einem solchen Weg entstehen, zeigen häufig überraschende Effekte und führen nicht selten zu besseren Entscheidungen.
Das macht diese Simulationen zu einer perfekten Ergänzung von Story Maps und anderen inhaltlich orientierten Methoden.
Feedback von Kunden und Anwendern zum gelieferten Produkt verbessert kontinuierlich das Wertmodell.
Diese Verbesserungen des Wertemodells wirken sich wiederum unmittelbar auf die Priorisierung des Backlogs aus und machen die Priorisierung zu einer leichten Aufgabe, die permanent passiert.
Im Vortrag wird anhand eines realen Großprojektes erklärt, wie Product Owner ein Wertmodell erstellen können,
wie es zur Simulation verwendet und wie daraus ein lernenes Wertmodell wird.
Die bisher einzige bekannte Methode, um den Wirkungsgrad von Führungskräften zu bewerten. Alle DAX-Unternehmen setzen es bereits ein. An den Fortune 500 arbeite ich gerade.
Der Product Owner ist maßgeblich für den Erfolg eines Projektes verantwortlich.
Warum der Product Owner für agile Projekte eine größere Bedeutung hat als ein Projektleiter und warum es für Projektleiter einen Karriereschritt bedeutet, Product Owner zu werden, möchte dieser Vortrag deutlich machen.
Dabei werden sowohl die unterschiedlichen Herangehensweisen des Projektmanagements gegenübergestellt als auch die Aspekte beleuchtet, die Product Owner gegenüber Projektleitern im Vorteil sein lassen.
Der Product Owner ist sicherlich die am häufigsten unterschätzte Rolle aus der agilen Welt. Dabei ist der Product Owner maßgeblich für den Erfolg eines Projektes verantwortlich. Warum der Product Owner für Projekt eine größere Bedeutung hat, als ein Projektleiter, warum es für Projektleiter einen Karriereschritt bedeutet, Product Owner zu werden und was diese Veränderung für Unternehmen bedeutet, möchte dieser Vortrag deutlich machen. Dabei werden sowohl die unterschiedlichen Herangehensweisen des wertorientierten und planorientierten Projektmanagements gegenübergestellt als auch die Methoden und Werkzeuge beleuchtet, die Product Owner gegenüber Projektleitern im Vorteil sein lassen.
Software-Architekturen sind stetigem Wandel ausgesetzt. Irgendwann muss DIE (unbekannte) Anforderung vom Software-Architekten berücksichtigt werden. Wie kann man diesem unvorhersehbarem Ereignis begegnen? Nicholas Nassim Taleb (Antifragilität: Anleitung für eine Welt, die wir nicht verstehen) hat aufgezeigt, dass solche Ereignisse die Grundlage zur Verbesserung sein können. Seine Thesen werden auf die Software-Architekturarbeit übertragen. Das Wissen über das Nichtwissen ist eine Grundvoraussetzung, genauso wie der bewusste Umgang mit Risiken und Chancen. Antifragilität ist ein Qualitätsaspekt des Software-Entwicklungsprozesses und nicht der entwickelten Software-Architektur. Agilität in der Software-Entwicklung bekommt damit eine neue Qualität und kann von Antifragilität profitieren.
Als Software-Architekten balancieren wir ständig auf dem Grat der Entscheidungen. Und nur allzu oft bewahrheitet sich, dass die Software-Architektur die Summe teurer Entscheidungen ist: Technische Schulden geißeln uns. An etlichen Stellen wird bereits der Ruf laut, dass der Begriff der technischen Schuld überholt ist – der von Anfang an falsch war. Die Suche nach einer neuen Metapher hat begonnen, wohin sie führt, wird sich zeigen.
Diese Keynote geht genau in die andere Richtung und zeigt, warum der Begriff der technischen Schuld genau ins Schwarze trifft. Es wird deutlich, dass eine Diskussion über die Zukunft von Software-Systemen mit Menschen, die keinen IT-Hintergrund haben, eine Brücke benötigt, die die Welten der Ökonomie und der IT zusammenführt. Abgerundet wird der Beitrag mit einer Methode zum Management technischer Schulden, die sich bereits in vielen agilen Projekten bewährt hat.
Als Software-Architekten balancieren wir ständig auf dem Grat der Entscheidungen. Und nur allzu oft bewahrheitet sich, dass die Software-Architektur die Summe teurer Entscheidungen ist: Technische Schulden geißeln uns. An etlichen Stellen wird bereits der Ruf laut, dass der Begriff der technischen Schuld überholt ist – der von Anfang an falsch war. Die Suche nach einer neuen Metapher hat begonnen, wohin sie führt, wird sich zeigen.
Diese Keynote geht genau in die andere Richtung und zeigt, warum der Begriff der technischen Schuld genau ins Schwarze trifft. Es wird deutlich, dass eine Diskussion über die Zukunft von Software-Systemen mit Menschen, die keinen IT-Hintergrund haben, eine Brücke benötigt, die die Welten der Ökonomie und der IT zusammenführt. Abgerundet wird der Beitrag mit einer Methode zum Management technischer Schulden, die sich bereits in vielen agilen Projekten bewährt hat.
Als Product Owner hat man die Verantwortung für den ökonomischen und fachlichen Erfolg eines Projektes. Und eine ganze Menge Werkzeuge, die in keinem der üblichen Product Owner-Seminare vorgestellt werden. Dieser Vortrag geht auf eben jene Werkzeuge ein, die dem Product Owner das Leben erleichtern, ökonomische Entscheidungen ermöglichen und Brücken zwischen agilen Teams, Kunden, Investoren jenseits von User Stories bauen.
Lessons Learned
- Wie kann ich als Product Owner ökonomische Aspekte meines Projektes bewerten und qualifizierte Entscheidungen treffen?
- Wie kann ich mein Team dazu bewegen, technische Entscheidungen, anhand von ökonomischen Faktoren zu bewerten?
- Wie wende ich Ideen wie Cost of Delay praktisch an, wie spreche ich mit Entwicklern, Kunden, Managern und Investoren darüber?
2. 24.03.2009 Semistrukturierte Daten in relationalen Datenbanken 2
Inhalt
● Semistrukturierte Daten - bisher
● Idee des dynamischen Datenmodells
● Erfahrungen
● Perspektiven
3. 24.03.2009 Semistrukturierte Daten in relationalen Datenbanken 3
Semistrukturierte Daten
● Keine allgemeine Struktur
● Tragen selbst Strukturinformationen
● Kein allgemeines ERD möglich, weil
– Objekte unterscheiden sich
– Objekte besitzen unbekannte Attribute
– Objekte können komplett abweichen
4. 24.03.2009 Semistrukturierte Daten in relationalen Datenbanken 4
Bisherige Ansätze
● Wenn man nur einen Hammer kennt...
● Speicherung in RDB statt XML, LDAP
● Neue Attribute durch neue Tabellenspalten
● Probleme
– Keine sauberen Updates möglich
– Langsam, da viele NULL-Werte
5. 24.03.2009 Semistrukturierte Daten in relationalen Datenbanken 5
Bisherige Ansätze
● Lösung 1
– Ergänzte Attribute in zusätzlicher Tabelle
– Zwei Tabellen pro Entität
– Extreme Performanceeinbußen (Joins!)
● Lösung 2
– Auslieferung vordefinierte „Anwenderspalten“
– begrenzte Anzahl, Datentypen
6. 24.03.2009 Semistrukturierte Daten in relationalen Datenbanken 6
Idee des dynamischen Datenmodell
● 2006 während Diplomarbeit entstanden
● Aufgabe: Reengineering einer Artikeldatenbank
● Extrem viele semistrukturierte Daten
● Technologische Basis:
– .NET 2.0
– NHibernate
– MS SQL Server 2005
7. 24.03.2009 Semistrukturierte Daten in relationalen Datenbanken 7
Idee des dynamischen Datenmodell
● Daten nicht anhand ihrer Struktur speicher
● Metamodell des ERD in SQL ablegen:
– Typen
– Entitäten
– Attribute
– Objekte
– Wertetabellen für primitive Typen
9. 24.03.2009 Semistrukturierte Daten in relationalen Datenbanken 9
Idee des dynamischen Datenmodell
● Vorteile
– Extrem schnelle Updates
– Konstante Zahl von Tabellen
● Nachteile
– Extrem komplexe Queries
– Unglaublich langsame Joins
10. 24.03.2009 Semistrukturierte Daten in relationalen Datenbanken 10
Idee des dynamischen Datenmodell
● Lösungen für die Nachteile
– Views für Klassen dynamisch erzeugen
– Mit INSTEAD-OF Triggern wie Tabellen nutzen
– Umschreiben der CUD-Statements
– Neuanlage der Views bei Änderung der Klasse
– Einführung von Vererbung
– Updatesicherheit durch Editierflags
11. 24.03.2009 Semistrukturierte Daten in relationalen Datenbanken 11
Erfahrungen
● Erster Performancetest
– 1 Million Artikeldaten schreiben: 30 Stunden
– *gnarz*
– Logging von NHibernate abschalten
– 1 Million Artikeldaten schreiben: 3 Minuten
– *strahl*
12. 24.03.2009 Semistrukturierte Daten in relationalen Datenbanken 12
Erfahrungen
● Anwendung auf SQL Server 2005
– Keine spürbaren Performancenachteile
– Getestet auf Minimal-System (512 MB RAM)
● Einschränkungen
– Notwendigkeit von INSTEAD-OF Triggern o.ä.
– Stored Procedures von Triggern erzeugbar
– PostgreSQL, MS SQL Server 2005
13. 24.03.2009 Semistrukturierte Daten in relationalen Datenbanken 13
Ausblick
● Vergleich mit LDAP Extensible Object
● Objekte mit mehreren Klassen
● Portierung auf zusätzliche DBMS
● Untersuchungen zur Performance