Als PDF, PPTX herunterladen
![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" }
],
...
}](https://image.slidesharecdn.com/einstiegindasnosql-schema-design-190228150127/75/Fachmodell-First-Einstieg-in-das-NoSQL-Schema-Design-31-2048.jpg)
![interface Rezept {
titel: string;
beschreibung: string;
seitenzahl?: number;
anzahlPersonen?: number;
tags?: Tag[];
}
interface Tag {
titel: string;
}
Zu Dokument](https://image.slidesharecdn.com/einstiegindasnosql-schema-design-190228150127/75/Fachmodell-First-Einstieg-in-das-NoSQL-Schema-Design-59-2048.jpg)
![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](https://image.slidesharecdn.com/einstiegindasnosql-schema-design-190228150127/75/Fachmodell-First-Einstieg-in-das-NoSQL-Schema-Design-62-2048.jpg)
![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](https://image.slidesharecdn.com/einstiegindasnosql-schema-design-190228150127/75/Fachmodell-First-Einstieg-in-das-NoSQL-Schema-Design-65-2048.jpg)
![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"
]
>](https://image.slidesharecdn.com/einstiegindasnosql-schema-design-190228150127/75/Fachmodell-First-Einstieg-in-das-NoSQL-Schema-Design-68-2048.jpg)
![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.](https://image.slidesharecdn.com/einstiegindasnosql-schema-design-190228150127/75/Fachmodell-First-Einstieg-in-das-NoSQL-Schema-Design-69-2048.jpg)
Hochgeladen vonGregor Biswanger
Fachmodell-First: Einstieg in das NoSQL-Schema-Design
Das Dokument von Gregor Biswanger erläutert die Vorteile und Herausforderungen von NoSQL-Datenbanken im Vergleich zu relationalen Datenbanken, mit Fokus auf die Dokumentenorientierung und das Domain-Driven Design. Es wird betont, dass NoSQL durch Flexibilität, Skalierbarkeit und eine bessere Anpassung an unstrukturierte Daten eine effektivere Datenarchitektur ermöglichen kann. Abschließend wird darauf hingewiesen, dass NoSQL nicht als universelle Lösung betrachtet werden sollte und eine sorgfältige Auswahl der Datenbanktechnologie wichtig ist.
Fachmodell-First: Einstieg in das NoSQL-Schema-Design
- 1. Fachmodell-First Einstieg in dasNoSQL-Schema-Design Gregor Biswanger | Freier Berater, Trainer, Autor und Sprecher about.me/gregor.biswanger
- 2. Über mich ▪ FreierBerater, 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.
- 4. Durch NoSQL erhaltenwir ein Booster in unsere Architektur bezüglich Produktivität, Flexibilität und Performance.
- 5. Unser Reiseplan ▪ Wasist schlecht an relationalen Datenbanken ▪ Einführung in NoSQL ▪ Dokumentenorientierte Datenbank ▪ Dokumentenorientiert modellieren ▪ Gemeinsam ein Beispiel modellieren ▪ Domain-Driven Design und das Fachmodell ▪ Fazit
- 6.
- 7. Relationale Datenbanken sindnicht für Entwickler gemacht
- 8. Sie geben sichals König in der Architektur aus
- 9. Der Datenbank wirdzu 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 esuns durch Ihre Regeln aufzwingen.
- 11.
- 12.
- 13.
- 14. Das macht dieEntwickler traurig
- 15. Retrain your relationalbrain…
- 16.
- 17. NoSQL Datenbanken verfolgeneinen nicht-relationalen Ansatz.
- 18. Sie brechen damitdie lange Geschichte relationaler Datenbanken.
- 19. Diese benötigen keinefestgelegten Tabellenschemata und versuchen Joins zu vermeiden.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26. Unterscheidung nach Datenmodellund 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.
- 28. Eine relationale Datenbankbesteht aus Datenbanktabellen, die einem festen Datenbankschema unterliegen.
- 29. Modeling data, therelational way
- 30. Eine dokumentenorientierte Datenbank bestehtaus einzelnen Dokumenten mit einem eindeutigen Identifikator.
- 31. Modeling data, thedocument 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.
- 33. Relationale Daten sindwie das recherchieren von Informationen
- 34. Dokumentenorientiere Daten bieten allebenötigten Informationen
- 35.
- 36. Dokumentenorientierte Datenbanken meinenNICHT, das es keine relationale Daten geben darf.
- 37.
- 38.
- 39. „Design with embeddedfirst“
- 40. Im Allgemeinen bietetdie Einbettung von Daten eine bessere Leistung für Leseoperationen.
- 41. Eingebettete Datenmodelle ermöglichen dieAktualisierung der zugehörigen Daten in einem atomaren Schreibvorgang.
- 42.
- 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- SchemaKompass für Dich!
- 46. Dokumenten-Schema Kompass Immer ManchmalSelten Integriert x x x Referenziert x x Wie oft werden die Daten zusammen benutzt?
- 47. Dokumenten-Schema Kompass Weniger als100 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.
- 52.
- 53. Optimierter Stand Datenbankspezifisch Datenbankspezifisch Datenbankspezifisch Zusammenfügen in Datentyp:Zutat Datentyp: Quelle Datentyp: Tag Datentyp: Rezept (Root-Document)
- 54. Weniger als 100Mehr 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 demDokumenten-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 100Mehr 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 demDokumenten-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 100Mehr 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 demDokumenten-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 100Mehr 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 demDokumenten-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.
- 67. Unterschiedliche Beziehungen behandelnin dokumentenorientierten Datenbanken
- 68. Abfrage von Array-Wertenohne 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 ArrayFelder > 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 abfragenmit 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 dasFachmodell
- 74.
- 75. Domain-Driven Design (DDD)ist eine Herangehensweise an die Modellierung komplexer, objektorientierter Software. Quelle: wikipedia.de
- 76. Die Modellierung derSoftware wird dabei maßgeblich von den umzusetzenden Fachlichkeiten der Anwendungsdomäne beeinflusst. Quelle: wikipedia.de
- 77.
- 78. Der Kunde DerEntwickler Business-Experte Business-Experte Fachlichkeit == Code und Struktur Eine „Common Language“ aufbauen!
- 79.
- 80. Entwickler geben sichnicht genug Mühe, die Objekte und Operationen so zu benennen, dass die Namen zu den fachlichen Aufgaben passen.
- 81. Das führt zueiner großen Lücke zwischen dem mentalen Modell, das die Anwender haben, und der Software, die die Entwickler den Anwendern liefern.
- 82. Was macht derfolgende Code?
- 84. Fachmodell / DomainModel ▪ 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 DomainModel (Core) User Interface (ASP.NET MVC, WPF etc.) Tests (BDD) Services Infrastructure Application Services Domain Services
- 87. Habt mehr Fokus aufdas Fachmodell
- 88.
- 89. NoSQL is NOT a SilverBullet!
- 90. Use the righttool for the right job!
- 91. Polyglot persistence gehörtder Zukunft!
- 92. „NoSQL gibt uns mehrFreiheiten, dafür tragen wir mehr Verantwortung“
- 94. http://about.me/Gregor.Biswanger I´m looking forwardto get your feedback Thank you!