Die letzten zehn Jahre haben uns gezeigt, dass der Datenbank zu hohe Priorität zugesprochen wurde. Die meisten Diskussionen drehten sich um das Datenmodell, statt um Geschäftsprozesse und Vorgänge. Kein Wunder, denn klassische SQL-Datenbanken erzwingen diese Vorgehensweise von uns. In dieser Session zeigt der MongoDB-Experte Gregor Biswanger eine zeitgemäße Alternative mit NoSQL und wie durch ein Umdenken auch ein Booster in unsere Architektur einfließt bezüglich Produktivität, Flexibilität und Performance.

1. Fachmodell-First
Einstieg in das NoSQL-Schema-Design
Gregor Biswanger | Freier Berater, Trainer, Autor und Sprecher
about.me/gregor.biswanger

2. Über mich
▪ Freier Berater, Trainer und Autor
▪ Schwerpunkte: Softwarearchitektur, Web und
Cross-Plattform Entwicklung mit JavaScript
▪ Technologieberater für die Intel Developer Zone
▪ Internationaler Sprecher auf Konferenzen und
User Groups
▪ Freier Autor für heise.de, dotnetpro,
WindowsDeveloper und viele weitere
Fachmagazine
▪ Video-Trainer bei video2brain und Microsoft
Gregor Biswanger
Microsoft MVP, Intel Black Belt &
Intel Software Innovator
cross-platform-blog.de
about.me/gregor.biswanger

3. Mein Versprechen…

4. Durch NoSQL erhalten wir ein Booster in unsere
Architektur bezüglich Produktivität,
Flexibilität und Performance.

5. Unser Reiseplan
▪ Was ist schlecht an relationalen
Datenbanken
▪ Einführung in NoSQL
▪ Dokumentenorientierte Datenbank
▪ Dokumentenorientiert modellieren
▪ Gemeinsam ein Beispiel modellieren
▪ Domain-Driven Design und
das Fachmodell
▪ Fazit

6. Relationale Datenbanken
machen mich Aggro!

7. Relationale Datenbanken sind nicht
für Entwickler gemacht

8. Sie geben sich als König
in der Architektur aus

9. Der Datenbank wird zu hohe Priorität zugesprochen und
die meisten Diskussionen drehen sich um die Datenbank
und das Datenmodell statt um Geschäftsprozesse und -
vorgänge.

10. Weil Sie es uns durch Ihre
Regeln aufzwingen.

11. Das Datenbank-Schema wird zur…

12. Londoner U-Bahn Karte

13. Entwickler
Relationale
Datenbank
O/R-Mapper

14. Das macht die Entwickler
traurig

15. Retrain your relational brain…

16. NoSQL
=
Not Only SQL

17. NoSQL Datenbanken verfolgen einen
nicht-relationalen Ansatz.

18. Sie brechen damit die lange Geschichte
relationaler Datenbanken.

19. Diese benötigen keine festgelegten
Tabellenschemata und versuchen
Joins zu vermeiden.

20. NoSQL-Datenbanken können
horizontal skalieren.

21. Die Ziele der
NoSQL-Bewegung

22. Verwaltung von unstrukturierten Daten

23. Stark
vernetzten Daten

24. Schnellen
Strukturänderungen

25. Großen Datenmengen

26. Unterscheidung nach Datenmodell und Leistung
Datenmodell Leistung Skalierbarkeit Flexibilität Komplexität Funktionalität
Key–Value Hoch Hoch Hoch Keine Unterschiedlich
(keine)
Spaltenorientiert Hoch Hoch Mittel Gering Minimal
Dokumentenorientiert Hoch Unterschiedlich (Hoch) Hoch Gering Unterschiedlich
(gering)
Graphbasiert Unterschiedlich Unterschiedlich Hoch Hoch Graphentheorie
Relational Unterschiedlich Unterschiedlich Gering Mittel Relationale
Algebra
Quelle: https://de.wikipedia.org/wiki/NoSQL
Datenmodell Leistung Skalierbarkeit Flexibilität Komplexität Funktionalität
Key–Value Hoch Hoch Hoch Keine Unterschiedlich
(keine)
Spaltenorientiert Hoch Hoch Mittel Gering Minimal
Dokumentenorientiert Hoch Unterschiedlich (Hoch) Hoch Gering Unterschiedlich
(gering)
Graphbasiert Unterschiedlich Unterschiedlich Hoch Hoch Graphentheorie
Relational Unterschiedlich Unterschiedlich Gering Mittel Relationale
Algebra

27. Dokumentenorientierte
Datenbank

28. Eine relationale Datenbank besteht aus
Datenbanktabellen, die einem festen
Datenbankschema unterliegen.

29. Modeling data, the relational way

30. Eine dokumentenorientierte Datenbank
besteht aus einzelnen Dokumenten mit einem
eindeutigen Identifikator.

31. Modeling data, the document way
{
"id": "0ec1ab0c-de08-4e42-...",
"addresses": [
{ "street": "sesamstraße",
"city": "gotham city" }
],
"contractdetails": [
{ "type": "home": "detail": "555-1212" },
{ "type": "email": "detail": "no@no.com" }
],
...
}

32. SQL
NoSQL
Data normalization
Come as you are

33. Relationale Daten sind wie das
recherchieren von Informationen

34. Dokumentenorientiere Daten
bieten alle benötigten Informationen

35. Dokumentenorientiert
modellieren

36. Dokumentenorientierte Datenbanken meinen NICHT,
das es keine relationale Daten geben darf.

37. „Design with No-Reference first“

38. Oder auch…

39. „Design with embedded first“

40. Im Allgemeinen bietet die Einbettung von Daten
eine bessere Leistung für Leseoperationen.

41. Eingebettete Datenmodelle ermöglichen
die Aktualisierung der zugehörigen Daten in
einem atomaren Schreibvorgang.

42. Integriert oder Referenziert?

43. Eingebettete Datenmodelle verwenden, wenn:
▪ Bei One-to-One-Beziehungen zwischen Entitäten.
▪ Bei One-to-Many-Beziehungen zwischen Entitäten.
▪ In diesen Beziehungen werden die "vielen" oder untergeordneten
Dokumente immer zusammen mit dem "ein" oder den
übergeordneten Dokumenten angezeigt.

44. Referenzierte Datenmodelle verwenden, wenn:
▪ Ein Einbetten würde zu einer Duplizierung von Daten führen, würde
jedoch keine ausreichenden Leseleistungsvorteile bieten, um die
Auswirkungen der Duplizierung zu überwiegen.
▪ Komplexere Many-to-Many-Beziehungen.
▪ Große hierarchische Datensätze.

45. Mein NoSQL Dokumenten-
Schema Kompass für Dich!

46. Dokumenten-Schema Kompass
Immer Manchmal Selten
Integriert x x x
Referenziert x x
Wie oft werden die Daten zusammen benutzt?

47. Dokumenten-Schema Kompass
Weniger als 100 Mehr als 100 Tausend
Integriert x x
Referenziert x x
Wie groß ist der Datensatz?

48. Dokumenten-Schema Kompass
Nie / Selten Gelegentlich Konstant
Integriert x x
Referenziert x x
Wie oft ändern sich die Daten?

49. Das Beispiel:
Rezeptdatenbank

52. Aktueller Stand

53. Optimierter Stand
Datenbankspezifisch
Datenbankspezifisch
Datenbankspezifisch
Zusammenfügen in
Datentyp: Zutat
Datentyp: Quelle
Datentyp: Tag
Datentyp: Rezept
(Root-Document)

54. Weniger als 100 Mehr als 100 Tausend
X
Wie groß ist der Datensatz?
Immer Manchmal Selten
Wie oft werden die Daten zusammen benutzt?
Nie / Selten Gelegentlich Konstant
X
Wie oft ändern sich die Daten?
Analyse vom Datentyp: Rezept

55. Vergleich mit dem Dokumenten-Schema Kompass
Immer Manchmal Selten
Integriert x x x
Referenziert x x
Wie oft werden die Daten zusammen benutzt?
Weniger als 100 Mehr als 100 Tausend
Integriert x x
Referenziert x x
Wie groß ist der Datensatz?
Nie / Selten Gelegentlich Konstant
Integriert x x
Referenziert x x
Wie oft ändern sich die Daten?

56. interface Rezept {
titel: string;
beschreibung: string;
seitenzahl?: number;
anzahlPersonen?: number;
}
Zu Dokument

57. Weniger als 100 Mehr als 100 Tausend
X
Wie groß ist der Datensatz?
Immer Manchmal Selten
X
Wie oft werden die Daten zusammen benutzt?
Nie / Selten Gelegentlich Konstant
X
Wie oft ändern sich die Daten?
Analyse vom Datentyp: Tag

58. Vergleich mit dem Dokumenten-Schema Kompass
Immer Manchmal Selten
Integriert x x x
Referenziert x x
Wie oft werden die Daten zusammen benutzt?
Weniger als 100 Mehr als 100 Tausend
Integriert x x
Referenziert x x
Wie groß ist der Datensatz?
Nie / Selten Gelegentlich Konstant
Integriert x x
Referenziert x x
Wie oft ändern sich die Daten?

59. interface Rezept {
titel: string;
beschreibung: string;
seitenzahl?: number;
anzahlPersonen?: number;
tags?: Tag[];
}
interface Tag {
titel: string;
}
Zu Dokument

60. Weniger als 100 Mehr als 100 Tausend
X
Wie groß ist der Datensatz?
Immer Manchmal Selten
X
Wie oft werden die Daten zusammen benutzt?
Nie / Selten Gelegentlich Konstant
X
Wie oft ändern sich die Daten?
Analyse vom Datentyp: Zutat

61. Vergleich mit dem Dokumenten-Schema Kompass
Immer Manchmal Selten
Integriert x x x
Referenziert x x
Wie oft werden die Daten zusammen benutzt?
Weniger als 100 Mehr als 100 Tausend
Integriert x x
Referenziert x x
Wie groß ist der Datensatz?
Nie / Selten Gelegentlich Konstant
Integriert x x
Referenziert x x
Wie oft ändern sich die Daten?

62. interface Rezept {
titel: string;
beschreibung: string;
seitenzahl?: number;
anzahlPersonen?: number;
tags?: Tag[];
zutaten?: Zutat[];
}
interface Tag {
titel: string;
}
interface Zutat {
stueck: number;
lebensmittel: string;
einheit?: string;
}
Zu Dokument

63. Weniger als 100 Mehr als 100 Tausend
X
Wie groß ist der Datensatz?
Immer Manchmal Selten
X
Wie oft werden die Daten zusammen benutzt?
Nie / Selten Gelegentlich Konstant
X
Wie oft ändern sich die Daten?
Analyse vom Datentyp: Quelle

64. Vergleich mit dem Dokumenten-Schema Kompass
Immer Manchmal Selten
Integriert x x x
Referenziert x x
Wie oft werden die Daten zusammen benutzt?
Weniger als 100 Mehr als 100 Tausend
Integriert x x
Referenziert x x
Wie groß ist der Datensatz?
Nie / Selten Gelegentlich Konstant
Integriert x x
Referenziert x x
Wie oft ändern sich die Daten?

65. interface Rezept {
titel: string;
beschreibung: string;
seitenzahl?: number;
anzahlPersonen?: number;
quelle: Quelle;
tags?: Tag[];
zutaten?: Zutat[];
}
interface Quelle {
titel: string;
standort?: string;
kurzbezeichnung?: string;
herkunft?: string;
anzahlRezepteGeschaetzt?: number;
}
interface Tag {
titel: string;
}
interface Zutat {
stueck: number;
lebensmittel: string;
einheit?: string;
}
Zu Dokument

66. Rezept
-----------------------------------
Titel
Beschreibung
…
Quelle
…
Tags
Zutaten
Tag
…
Zutat
…

67. Unterschiedliche Beziehungen behandeln in
dokumentenorientierten Datenbanken

68. Abfrage von Array-Werten ohne Duplikationen
> db.foo.save({ tags: ['Eierspeisen', 'Backstube'] })
> db.foo.save({ tags: ['Eierspeisen', 'Eingelegtes', 'Beilagen'] } )
> db.foo.save({ tags: ['Buttermischungen', 'Beilagen'] } )
> db.foo.distinct("tags")
[
"Backstube",
"Eierspeisen",
"Beilagen",
"Eingelegtes",
"Buttermischungen"
]
>

69. Anfragen für Array Felder
> db.foo.save({ _id: 1, "things" : [ 1, 2, 3 ] });
> db.foo.save({ _id: 2, "things" : [ 2, 3 ] });
> db.foo.save({ _id: 3, "things" : [ 3 ] });
> db.foo.save({ _id: 4, "things" : [ 1, 3 ] });
> db.foo.find({ things: 1 })
{ "_id" : 1, "things" : [ 1, 2, 3 ] }
{ "_id" : 4, "things" : [ 1, 3 ] }
>
Wichtig! Mongo ist Case-Sensitive.

70. Dot Notation
> db.foo.save({ _id: 1, "info" : { "canFly": false } });
> db.foo.save({ _id: 2, "info" : { "canFly": false } });
> db.foo.save({ _id: 3, "info" : { "canFly": true } });
> db.foo.save({ _id: 4, "info" : { "canFly": false } });
> db.foo.find({ "info.canFly": true })
{ "_id": 3, "info": { "canFly": true }}
>
▪ Ein Query kann ebenfalls Hierarchische Bedingungen beinhalten.
▪ Diese werden als String-Wert angeben.
▪ Wichtig! Mongo ist Case-Sensitive.

71. And-Kombination ebenfalls möglich
> db.foo.save({ _id: 1, "info": { "canFly": false } });
> db.foo.save({ _id: 2, "info": { "canFly": false } });
> db.foo.save({ _id: 3, "name": "Sample", "info": { "canFly": true } });
> db.foo.save({ _id: 4, "info" : { "canFly": false } });
> db.foo.find({ "name": "Sample", "info.canFly": true })
{ "_id": 3, "name": "Sample", "info": { "canFly": true }}
>
Das Komma steht hierbei als And-Operator.

72. Referenzierte Dokumente abfragen mit dem integrierten
Aggregation-Framework und der $lookup-Funktion
Dokumentation und Beispiel unter:
https://docs.mongodb.com/manual/reference/operator/aggregation/lookup/

73. Domain-Driven Design
und das Fachmodell

74. Was ist DDD?

75. Domain-Driven Design (DDD) ist eine Herangehensweise an
die Modellierung komplexer, objektorientierter Software.
Quelle: wikipedia.de

76. Die Modellierung der Software wird dabei maßgeblich von den
umzusetzenden Fachlichkeiten der Anwendungsdomäne
beeinflusst.
Quelle: wikipedia.de

77. Domain = Fachlichkeit

78. Der Kunde Der Entwickler
Business-Experte Business-Experte
Fachlichkeit == Code
und Struktur
Eine „Common Language“ aufbauen!

79. Quelle:http://bonkersworld.net/object-world

80. Entwickler geben sich nicht genug Mühe, die
Objekte und Operationen so zu benennen, dass
die Namen zu den fachlichen Aufgaben passen.

81. Das führt zu einer großen Lücke zwischen dem
mentalen Modell, das die Anwender haben, und der
Software, die die Entwickler den Anwendern liefern.

82. Was macht der folgende Code?

84. Fachmodell / Domain Model
▪ Um also ein einheitliches Verständnis zwischen diesen
Gruppen (Domänenexperte und Entwickler) zu schaffen,
wird ein Modell der Domäne etabliert
▪ Ein Model ist eine auf bestimmte Zwecke ausgerichtete
vereinfachende Beschreibung der Wirklichkeit

85. Anemic domain model
▪ Unter DDD ein Anti-Pattern
▪ Trennt Datenstruktur und Funktionen
▪ Kein „richtiges“ objektorientiertes programmieren
▪ Braucht eigene Business-Logic-Schicht
▪ Macht ein Domain Model schwerer zu verstehen

86. Die Onion Architecture
Domain Model
(Core)
User Interface
(ASP.NET MVC, WPF etc.)
Tests
(BDD)
Services
Infrastructure
Application Services
Domain Services

87. Habt mehr Fokus
auf das Fachmodell

88. Fazit

89. NoSQL
is NOT a
Silver Bullet!

90. Use the right tool for
the right job!

91. Polyglot persistence gehört der Zukunft!

92. „NoSQL gibt uns
mehr Freiheiten,
dafür tragen wir mehr
Verantwortung“

94. http://about.me/Gregor.Biswanger
I´m looking forward to get your feedback
Thank you!