Bitte wählen Sie die Bereiche, die Sie exportieren möchten:
Alle Weitere Themen SchulungenSchulung NoSQL-Datenmodellierung: Patterns und Anti-Patterns
Schulung NoSQL-Datenmodellierung: Patterns und Anti-Patterns
Query-Driven Design, Denormalisierung, Partitionierung und Eventual Consistency
2 Tage / S6888
Neues SeminarSchulungsformen
Offene Schulung
- 2 Tage
- 5 gesicherte Termine
- Köln / Online
- 1.440,00 p. P. zzgl. MwSt.
- Dritter Mitarbeitende kostenfrei
- Learning & Networking in einem. Garantierte Durchführung ab 1 Teilnehmenden.
Präsenz Online
Inhouse-/Firmenschulung
- 2 Tage - anpassbar
- Termin nach Wunsch
- In Ihrem Hause oder bei der GFU
- Preis nach Angebot
- Lernumgebung in der Cloud
- Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
Präsenz Online Hybrid
Individualschulung
- 2 Tage - anpassbar
- Termin nach Wunsch
- In Ihrem Hause oder bei der GFU
- Preis nach Angebot
- Lernumgebung in der Cloud
- 1 Teilnehmender = Fokus aufs Fachliche und maximaler Raum für individuelle Fragen.
Präsenz Online Hybrid
Beschreibung
Der häufigste Fehler bei NoSQL-Projekten passiert nicht im Betrieb, nicht im Code, nicht in der Konfiguration - sondern im Datenmodell . Entwickler mit SQL-Hintergrund normalisieren ihre Daten in dritte Normalform, legen Fremdschlüssel an und erwarten JOINs. Dann stellen sie fest: MongoDB hat keine JOINs (nur $lookup - langsam), Cassandra verbietet Queries ohne Partition Key, Redis hat kein Schema und Neo4j denkt in Beziehungen statt Tabellen. Das Ergebnis: Applikationen, die bei 100.000 Datensätzen gut laufen und bei 10 Millionen zusammenbrechen.
NoSQL-Datenmodellierung folgt einem anderen Prinzip: Queries first, Schema second. Erst definieren, welche Fragen die Applikation beantwortet (Access Patterns). Dann das Datenmodell so bauen, dass jede Frage mit einer einzigen, schnellen Operation beantwortet wird - auch wenn das Denormalisierung, Datenduplikation und mehrere Darstellungen derselben Daten bedeutet. In SQL ist Redundanz ein Designfehler. In NoSQL ist Redundanz das Designprinzip.
Dieses Seminar lehrt nicht ein Tool, sondern eine Denkweise - die Denkweise, die in MongoDB, Cassandra, Redis, DynamoDB und Neo4j gleichermaßen gilt. Wer diese Denkweise versteht, modelliert in jedem NoSQL-System besser. Wer sie nicht versteht, baut in jedem NoSQL-System dieselben Fehler.
NoSQL-Datenmodellierung folgt einem anderen Prinzip: Queries first, Schema second. Erst definieren, welche Fragen die Applikation beantwortet (Access Patterns). Dann das Datenmodell so bauen, dass jede Frage mit einer einzigen, schnellen Operation beantwortet wird - auch wenn das Denormalisierung, Datenduplikation und mehrere Darstellungen derselben Daten bedeutet. In SQL ist Redundanz ein Designfehler. In NoSQL ist Redundanz das Designprinzip.
Dieses Seminar lehrt nicht ein Tool, sondern eine Denkweise - die Denkweise, die in MongoDB, Cassandra, Redis, DynamoDB und Neo4j gleichermaßen gilt. Wer diese Denkweise versteht, modelliert in jedem NoSQL-System besser. Wer sie nicht versteht, baut in jedem NoSQL-System dieselben Fehler.
Schulungsziel
Jede teilnehmende Person verlässt das Seminar mit dem Verständnis des Query-Driven-Design-Prinzips (das in allen NoSQL-Systemen gilt), der Fähigkeit, Modellierungspatterns für 4 NoSQL-Kategorien anzuwenden (Document, Wide-Column, Key-Value, Graph), dem Erkennen und Vermeiden typischer Anti-Patterns (relationales Denken, unbegrenztes Wachstum, Hotspots, fehlende Denormalisierung), einem Polyglot-Persistence-Architektur-Entwurf für die eigene Domäne und dem Bewusstsein für Eventual Consistency als Gestaltungsaufgabe.
Details
Inhalt
Tag 1: Grundprinzipien und Document/Wide-Column-Modellierung
1. Von SQL zu NoSQL: Der Paradigmenwechsel
4. Key-Value Modellierung: Redis-Patterns
Eventual Consistency gestalten (30 Min):
1. Von SQL zu NoSQL: Der Paradigmenwechsel
- Ziele und Erwartungen der Teilnehmenden
- Klärung individueller Lernziele und Erwartungen für ein praxisnahes und relevantes Seminar
- Relationales Denken: Entitäten identifizieren -> Normalisieren (1NF, 2NF, 3NF) -> Beziehungen über Fremdschlüssel -> Queries per JOIN zusammensetzen. Optimiert für: Datenintegrität, Speichereffizienz, flexible Ad-hoc-Queries. Funktioniert bei: Transaktionssysteme, ERP, Buchhaltung, regulierte Umgebungen.
- NoSQL-Denken: Access Patterns identifizieren -> Für jedes Pattern eine optimale Datenstruktur entwerfen -> Denormalisieren -> Daten duplizieren -> Schreibaufwand akzeptieren für schnelle Reads. Optimiert für: Lese-Performance, horizontale Skalierung, vorhersagbare Latenz. Funktioniert bei: Web-Scale, IoT, Echtzeit, Caching, Empfehlungen.
- Die 5 Grundregeln: (1) Queries zuerst, Schema danach, (2) Denormalisierung ist kein Anti-Pattern, (3) Datenduplikation ist der Preis für Lese-Performance, (4) Schreiben ist billiger als Joinen, (5) Eventual Consistency ist ein Feature, kein Bug.
- Wann SQL, wann NoSQL, wann beides? Entscheidungsmatrix: Datenstruktur (fest vs. flexibel), Konsistenzanforderung (strikt vs. eventual), Skalierungsbedarf (vertikal vs. horizontal), Query-Komplexität (ad-hoc vs. vordefiniert), Beziehungsdichte (flach vs. hochvernetzt). Polyglot Persistence: SQL für Transaktionen + MongoDB für Content + Redis für Cache + Neo4j für Empfehlungen.
- Praxis-Übung: Seminar-Domäne (E-Commerce: Produkte, Kunden, Bestellungen, Bewertungen, Empfehlungen) analysieren. Access Patterns auflisten (15+ Queries). Für jede Query bewerten: relationale DB oder NoSQL? Welcher NoSQL-Typ? Ergebnis: Polyglot-Persistence-Architektur-Skizze.
- Embedding vs. Referencing: Embedding (Subdokument im Elterndokument) für 1:1 und 1:wenige-Beziehungen, die zusammen gelesen werden. Referencing (ID-Verweis) für 1:viele und viele:viele, die unabhängig gelesen werden. Faustregel: „Wenn du die Daten immer zusammen brauchst -> embed. Wenn du sie unabhängig brauchst -> reference."
- Patterns: Subset Pattern (nur die letzten 10 Bewertungen im Produkt-Dokument, vollständige History in separater Collection), Computed Pattern (berechnete Werte vorberechnen und speichern: Durchschnittsbewertung, Bestellsumme - statt bei jedem Read berechnen), Bucket Pattern (Zeitreihendaten in Zeitfenster-Dokumenten gruppieren: 1 Dokument = 1 Stunde Sensordaten statt 1 Dokument pro Messpunkt), Extended Reference (häufig benötigte Felder des referenzierten Dokuments kopieren: Kundenname in Bestellung statt JOIN auf Kunden-Collection), Schema Versioning (Dokumente mit verschiedenen Schema-Versionen koexistieren - schema_version Feld).
- Anti-Patterns: Unbegrenztes Array-Wachstum (z.B. alle Follower als Array im User-Dokument -> 16 MB Document-Limit), übermäßiges Referencing (MongoDB als relationale DB missbrauchen -> N+1-Query-Problem), fehlende Indizes auf Query-Felder, $lookup als JOIN-Ersatz in Performance-kritischen Pfaden.
- Praxis-Übung: Produkt-Katalog modellieren: Produkt mit eingebetteten Varianten (Embedding), Produktbewertungen (Subset Pattern: letzte 5 eingebettet, Rest in separater Collection), Bestellung mit Extended Reference (Kundenname + Produktname kopiert statt referenziert). Anti-Pattern provozieren: Array mit 100.000 Einträgen -> Performance-Einbruch messen -> mit Bucket Pattern lösen.
- Partition Key Design: Der Partition Key bestimmt, auf welchem Node die Daten liegen UND welche Queries möglich sind. Falsch gewählt = Hotspots (ein Node bekommt 90 % der Last) oder unmögliche Queries (ALLOW FILTERING). Richtig gewählt = gleichmäßige Verteilung + schnelle Reads.
- Clustering Columns: Sortierung innerhalb der Partition. Bestimmt die Reihenfolge der Ergebnisse ohne ORDER BY. Compound Clustering Keys für mehrdimensionale Sortierung (z.B. year DESC, month DESC, day DESC für Zeitreihen).
- Patterns: Time-Series (Partition per Device + Zeitfenster, Clustering per Timestamp), Reverse-Lookup (separate Tabelle für Reverse-Queries: orders_by_customer + orders_by_product), Materialized View (automatisch aktualisierte Denormalisierung - mit Einschränkungen), Wide Row (wenige Partitionen mit vielen Clustering Rows - für sortierte Listen).
- Anti-Patterns: Single-Partition-Hotspot (z.B. Partition Key = Land -> Deutschland bekommt 80 % der Writes), unbegrenzte Partition-Größe (alle Events eines Users seit 2015 in einer Partition -> > 100 MB -> Performance-Einbruch), sekundäre Indizes auf High-Cardinality-Spalten, ALLOW FILTERING in Produktion.
- Partition-Sizing: Berechnung: Anzahl Rows × Durchschnittliche Row-Größe < 100 MB. Compound Partition Keys für Zeitfenster (z.B. (sensor_id, year_month) statt nur sensor_id).
- Praxis-Übung: IoT-Sensordaten modellieren: 5 Queries definieren (letzte Werte pro Sensor, Werte eines Sensors im Zeitfenster, Alarme pro Anlage, Durchschnitt pro Tag, alle Sensoren eines Standorts). Für jede Query eine Tabelle entwerfen. Partition-Sizing berechnen. Anti-Pattern provozieren: Single-Partition mit 1 Million Rows -> Latenz messen -> mit Compound Key lösen.
4. Key-Value Modellierung: Redis-Patterns
- Redis-Datenstrukturen als Modellierungswerkzeug: Nicht nur Key-Value - Redis hat Strings, Hashes, Lists, Sets, Sorted Sets, Streams, HyperLogLog, Bitmaps. Jede Datenstruktur löst ein spezifisches Modellierungsproblem.
- Patterns: Cache-Aside (Datenbank-Read -> in Redis cachen -> nächster Read aus Redis), Session Store (Hash pro User-Session: HSET session:abc user_id 42 role admin last_active 2026-04-20), Leaderboard (Sorted Set: ZADD leaderboard 1500 "alice" 1200 "bob" -> ZREVRANGE leaderboard 0 9 = Top 10), Rate Limiter (String mit INCR + EXPIRE: INCR api:user:42:requests -> EXPIRE api:user:42:requests 60), Pub/Sub für Echtzeit-Events, Streams für Event-Logs (append-only, Consumer Groups).
- Anti-Patterns: Redis als Primärdatenbank (kein Durability-Default, keine Ad-hoc-Queries), riesige Einzelkeys (> 1 MB -> Latenz-Spikes), fehlendes TTL (Speicher wächst unbegrenzt), Key-Namenskonvention fehlt (Chaos bei 100.000+ Keys).
- Key-Naming-Konventionen: Hierarchisch mit Doppelpunkt: object-type:id:field -> user:42:profile, session:abc123, cache:product:99. Für Scan, Monitoring und Debugging essentiell.
- Praxis-Übung: E-Commerce-Patterns implementieren: Product Cache (Hash), User Session (Hash mit TTL), Bestseller-Leaderboard (Sorted Set), API Rate Limiter (INCR + EXPIRE), Recently Viewed Products (List mit LPUSH + LTRIM). Anti-Pattern: einen 5 MB String-Key erstellen -> Latenz messen -> in Hash-Struktur ummodellieren.
- Denken in Beziehungen: Im Graphmodell sind Beziehungen genauso wichtig wie Entitäten. Nodes (Entitäten mit Labels und Properties), Relationships (typisierte, gerichtete Verbindungen mit Properties), Patterns (Pfade durch den Graphen). „Wer kennt wen, der etwas gekauft hat, das ähnlich ist zu dem, was ich angeschaut habe" -> ein Cypher-Query, keine 5 JOINs.
- Modellierungs-Patterns: Property Graph (Nodes + Relationships + Properties - der Neo4j-Standard), Intermediate Nodes (Beziehung mit vielen Attributen -> eigenen Node für die Beziehung: z.B. Person -[:WORKED_AT]-> Employment -[:AT]-> Company statt Person -[:WORKED_AT {from: ..., to: ..., role: ...}]-> Company), Temporal Modeling (zeitliche Beziehungen: VALID_FROM, VALID_TO auf Relationships), Hierarchien (Baumstrukturen: PART_OF, REPORTS_TO, CHILD_OF).
- Anti-Patterns: Dense Nodes (ein Node mit 10 Millionen Beziehungen -> „Supernode" -> Traversal-Performance bricht ein), relationales Denken (Nodes als Tabellen, Properties als Spalten, keine Beziehungen -> Graph-Vorteil verschenkt), Properties statt Relationships (z.B. user.friends = ["alice", "bob"] statt User -[:FRIEND]-> User), fehlende Relationship-Typen (alle Beziehungen heißen RELATED_TO).
- Wann Graph, wann nicht: Graph für: Empfehlungen, Fraud Detection, Netzwerkanalyse, Knowledge Graphs, Access Control, Supply Chain. Nicht für: einfache CRUD, Zeitreihen, Volltextsuche, aggregierte Analytics.
- Praxis-Übung: Empfehlungssystem modellieren: Customers, Products, Categories, Reviews als Nodes. PURCHASED, REVIEWED, BELONGS_TO, SIMILAR_TO als Relationships. 3 Cypher-Queries: „Kunden, die auch gekauft haben", „Produkte mit ähnlichen Bewertungen", „Kürzester Pfad zwischen zwei Kunden". Anti-Pattern: Supernode provozieren (1 Category-Node mit 100.000 Produkt-Beziehungen) -> Traversal-Latenz messen.
Eventual Consistency gestalten (30 Min):
- Konsistenz-Modelle: Strong Consistency (nach Write sofort überall aktuell - SQL, Cassandra CL=ALL), Eventual Consistency (nach Write irgendwann überall aktuell - Cassandra CL=ONE, MongoDB Replica Set Reads von Secondary), Causal Consistency (Schreibreihenfolge wird pro Session garantiert - MongoDB Causal Sessions).
- Patterns für Eventual Consistency: Read-Your-Own-Writes (Client liest nach Write vom Primary), Monotonic Reads (Client liest nie ältere Version als zuvor gesehen), Conflict Resolution (Last-Write-Wins, Merge, Application-Level Resolution), Compensation (wenn inkonsistente Daten erkannt werden -> korrigieren statt verhindern).
- Eventual Consistency in der UI: Optimistic UI (Aktion sofort anzeigen, im Hintergrund synchronisieren), Stale-Data-Indikatoren (Zeitstempel anzeigen: „Stand: vor 3 Sekunden"), Retry bei Conflict.
- Die richtige DB für den richtigen Workload: Transaktionen -> PostgreSQL, Content/Katalog -> MongoDB, Cache/Sessions -> Redis, Zeitreihen -> Cassandra/TimescaleDB, Beziehungen/Empfehlungen -> Neo4j, Suche -> Elasticsearch, Vektor/KI -> pgvector/Weaviate.
- Synchronisierung zwischen Systemen: Change Data Capture (Debezium), Event-basiert (Kafka), Application-Level Sync, Materialized Views. Trade-offs: Latenz, Konsistenz, Komplexität.
- Phase 1 - Eigene Domäne modellieren (25 Min): Eigene Geschäftsdomäne wählen (oder vorgegebenes Szenario). 10 Access Patterns auflisten. Für jedes Pattern: NoSQL-Typ wählen, Datenmodell entwerfen, Denormalisierung und Duplikation dokumentieren. Polyglot-Persistence-Architektur zeichnen.
- Phase 2 - Peer-Review (15 Min): Datenmodell vorstellen. Feedback: Sind die Partition Keys richtig? Gibt es unbegrenzt wachsende Dokumente? Fehlt ein Index? Ist die Denormalisierung ausreichend? Stresstest: „10× mehr Daten - skaliert das Modell?" „Ein neues Access Pattern wird gefordert - wie viel Umbau?"
Zielgruppe & Vorkenntnisse
- Entwickler mit SQL-Hintergrund: Die auf NoSQL-Projekte umsteigen und die Denkweise „Tabellen normalisieren, dann Queries schreiben" ablegen müssen.
- Backend-Architekten und Tech Leads: Die Datenmodell-Entscheidungen für NoSQL-Systeme treffen und Review-Kompetenz aufbauen.
- Data Engineers: Die Datenmodelle für mehrere NoSQL-Typen gleichzeitig entwerfen (Polyglot Persistence: MongoDB für CRUD + Cassandra für Zeitreihen + Redis für Cache + Neo4j für Beziehungen).
- Entwickler, die NoSQL bereits nutzen: Die Performance-Probleme und Skalierungsgrenzen haben und die Ursache im Datenmodell vermuten.
Abgrenzung: Dieses Seminar behandelt Datenmodellierungs-Prinzipien und -Patterns toolübergreifend - nicht die Administration eines spezifischen Systems (dafür: MongoDB S2492, Redis S3458, Cassandra geplant 3T, Neo4j S3700), nicht allgemeine NoSQL-Einführung (dafür: S3499, 3T).
Ihre Schulung
In Präsenz | Online |
|---|---|
| Lernmethode | |
Ausgewogene Mischung aus Theorie und praktischen Übungen auf persönlichem Schulungs-PC. | Wie auch bei unseren Präsenz-Seminaren: Ausgewogene Mischung aus Theorie und praktischen Übungen. Trainer durchgehend präsent. |
| Unterlagen | |
Seminarunterlagen oder Fachbuch inklusive. Das Fachbuch wählt der Trainer passend zum Seminar aus - Ihren individuellen Buch-Wunsch berücksichtigen wir auf Nachfrage gerne. | Seminarunterlagen oder Fachbuch inklusive (via DHL). Das Fachbuch wählt der Trainer passend zum Seminar aus - Ihren individuellen Buch-Wunsch berücksichtigen wir auf Nachfrage gerne. |
| Arbeitsmaterialien | |
DIN A4 Block, Notizblock, Kugelschreiber, USB-Stick, Textmarker, Post-its | |
| Teilnahmezertifikat | |
Nach Abschluss des Seminars erhalten Sie das Teilnahmezertifikat inkl. Inhaltsverzeichnis per E-Mail als PDF. | |
Organisation
In Präsenz | Online | |
|---|---|---|
| Teilnehmendenzahl | ||
min. 1, max. 8 Personen | ||
| Garantierte Durchführung | ||
Ab 1 Teilnehmenden* | ||
| Schulungszeiten | ||
| ||
| Ort der Schulung | ||
 GFU SchulungszentrumAm Grauen Stein 27 51105 Köln-Deutz oder online im Virtual Classroom oder europaweit bei Ihnen als Inhouse-Schulung Um ein optimales Raumklima zu gewährleisten, haben wir das Schulungszentrum mit 17 hochmodernen Trotec TAC V+ Luftreinigern ausgestattet. Diese innovative Filtertechnologie (H14 zertifiziert nach DIN EN1822) sorgt dafür, dass die Raumluft mehrfach pro Stunde umgewälzt wird und Schadstoffe zu 99.995% im HEPA-Filter abgeschieden und infektiöse Aerosole abgetötet werden. Zusätzlich sind alle Räume mit CO2-Ampeln ausgestattet, um jederzeit eine hervorragende Luftqualität sicherzustellen. | ||
| Räumlichkeiten | ||
Helle und modern ausgestattete Räume mit perfekter Infrastruktur | Bequem aus dem Homeoffice von überall | |
| Preisvorteil | ||
Dritter Mitarbeitende nimmt kostenfrei teil. Eventuell anfallende Prüfungskosten für den dritten Teilnehmenden werden zusätzlich berechnet. Hinweis: Um den Erfolg der Schulung zu gewährleisten, sollte auch der dritte Teilnehmende die erwarteten Vorkenntnisse mitbringen. | ||
| All-Inclusive | ||
Gebäck, Snacks und Getränke ganztägig, Mittagessen im eigenen Restaurant, täglich 6 Menüs, auch vegetarisch | Eine Auswahl unserer Frühstücks-Snacks und Nervennahrungs-Highlights senden wir Ihnen mit den Seminarunterlagen via DHL zu. | |
| Barrierefreiheit | ||
Das GFU-Schulungszentrum (Am Grauen Stein 27) ist barrierefrei | - | |
Buchen ohne Risiko
| Rechnungsstellung |
Erst nach dem erfolgreichen Seminar. Keine Vorkasse. |
| Stornierung |
Kostenfrei bis zum Vortag des Seminars |
| Vormerken statt buchen |
Sichern Sie sich unverbindlich Ihren Seminarplatz schon vor der Buchung - auch wenn Sie selbst nicht berechtigt sind zu buchen |
Kostenfreie Services
In Präsenz | Online |
|---|---|
|
|
Buchungsmöglichkeiten
Online oder in Präsenz teilnehmen
Sie können sowohl Online als auch in Präsenz am Seminar teilnehmen. Klicken Sie bei Ihrer Buchung oder Anfrage einfach die entsprechende Option an.
Gesicherte offene Termine
| Termin | Ort | Preis | ||
|---|---|---|---|---|
| 10.08.-11.08.2026 Plätze vorhanden Köln / Online 1.440,00 | Köln / Online | 1.440,00 | Buchen Vormerken | |
| 12.10.-13.10.2026 Plätze vorhanden Köln / Online 1.440,00 | Köln / Online | 1.440,00 | Buchen Vormerken | |
| 14.12.-15.12.2026 Plätze vorhanden Köln / Online 1.440,00 | Köln / Online | 1.440,00 | Buchen Vormerken | |
| 2027 | ||||
| 19.04.-20.04.2027 Plätze vorhanden Köln / Online 1.440,00 | Köln / Online | 1.440,00 | Buchen Vormerken | |
| 21.06.-22.06.2027 Plätze vorhanden Köln / Online 1.440,00 | Köln / Online | 1.440,00 | Buchen Vormerken | |
Inhouse-/Firmenschulung
- Lernumgebung in der Cloud
- Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
Präsenz Online Hybrid
Individualschulung
- Lernumgebung in der Cloud
- 1 Teilnehmender = Fokus aufs Fachliche und maximaler Raum für individuelle Fragen.
Präsenz Online Hybrid
Nachbetreuung
Unterstützung nach der Schulung durch
individuelle Nachbetreuung
FAQ für Offene Schulungen
Welche Schulungsform ist ideal für mich?
- Alle folgenden Schulungsformen können auch Online als Virtual Classroom durchgeführt werden.
- Eine Offene Schulung findet zu einem festgelegten Zeitpunkt im voll ausgestatteten Schulungszentrum oder Online/Remote statt. Sie treffen auf Teilnehmende anderer Unternehmen und profitieren vom direkten Wissensaustausch.
- Eine Inhouse-/Firmen-Schulung geht auf die individuellen Bedürfnisse Ihres Unternehmens ein. Sie erhalten eine kostenfreie Beratung von Ihrem Seminarleiter und können Inhalte und Dauer auf Ihren Schulungsbedarf anpassen. Inhouse-Schulungen können Europaweit durchgeführt werden.
- Bei einer Individual-Schulung erhalten Sie eine 1-zu-1 Betreuung und bestimmen Inhalt, Zeit und Lerntempo. Der Dozent passt sich Ihren Wünschen und Bedürfnissen an.
Wie kann ich an einer Online Schulung teilnehmen?
Sie können unsere Schulungen auch als Remote Schulung im Virtual Classroom anfragen.
In drei Schritten zum Online Seminar im Virtual Classroom:
- Seminar auswählen und auf "Buchen" klicken
- Wählen Sie bei "Wie möchten Sie teilnehmen?" einfach "Online" aus.
- Formular ausfüllen und über den Button "Jetzt buchen" absenden.
Unser Kundenservice meldet sich bei Ihnen mit der Buchungsbestätigung.
Was ist ein Virtual Classroom?
Unsere Online Schulungen finden im Virtual Classroom statt. Ein Virtual Classroom bündelt mehrere Werkzeuge, wie Audio-Konferenz, Text-Chat, Interaktives Whiteboard, oder Application Sharing.
Vorteile von Virtual Classroom:
- Sie erhalten 1 zu 1 die gleiche Lernumgebung, die Sie auch vor Ort bei uns vorfinden
- Die technische Vorbereitung wird von den GFU-Technikern vorgenommen
- Sie erhalten remote Zugriff auf Ihren persönlichen Schulungs-PC im GFU-Seminarraum
- Die Virtual Classroom Lösung lässt sich auch im Browser betreiben
- Die GFU-Technik leistet wie gewohnt Soforthilfe bei Problemen
- Die Schulungsunterlagen bekommen Sie via DHL zugeschickt
- Sie sparen Reisekosten und Zeit
Welche gesicherten Termine gibt es?
- 10. Aug. - 11. Aug. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 12. Okt. - 13. Okt. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 14. Dez. - 15. Dez. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 19. Apr. - 20. Apr. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 21. Jun. - 22. Jun. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- Auch als Inhouse-Schulung, bundesweit mit Termin nach Wunsch und individuellen Inhalten
- Buchen ohne Risiko! Kostenfreie Stornierung bis zum Vortag des Seminars
Das GFU-Sorglos-Paket
Die Seminare der GFU finden in angenehmer Atmosphäre statt und sind perfekt organisiert. Profitieren Sie von dem Rundum-Service der GFU!
Shuttle-Service
Machen Sie sich keinen Kopf um die Anreise! Unser Shuttle fährt Sie. Oder Sie parken einfach auf einem extra für Sie reservierten Parkplatz.
Hotelreservierung
Hotelzimmer gesucht? Wir organisieren Ihnen eins. Ihr Vorteil: Sie sparen Zeit und Geld!
Kostenfreies Storno
Stornierung bei offenen Seminaren kostenfrei bis einen Tag vor Schulungsbeginn.
Technik-Support
Unsere Techniker sind immer zur Stelle, egal ob online oder vor Ort.