Die Datenbank

Wir arbeiten ausschließlich mit relationalen Datenbanken wie MSSQL oder ORACLE. Diese umfassen je System aktuell

  • > 1.000 Tabellen
  • > 9.000 Spalten
  • > 3.000 Fremdschlüssel

Enorme Vorteile von relationalen Datenbanken

  • einfaches Datenmodell
  • Datenkonsistenz (bei normalisierten Modellen), da Änderungen zentral und nur an einer Stelle erfolgen
  • Verknüpfung über Inhalte
  • Durch gleichberechtigte Relationen sind Einstiegspunkte beliebig
  • Durch die Zerlegung aller Objekt in Einzelteile werden die Daten mengenorientiert verarbeitet. Damit können komplizierte und komplexe Abfragen auf große Datenmengen und mächtige Operationen erfolgen
  • Hohes Maß an Datenunabhängigkeit: Die Navigation obliegt völlig dem Datenbanksystem und ist damit einfach für den Nutzer
  • Standardisierte einheitliche Datenbanksprache für mehrere Anbieter

Jede B2B Plattform benötigt drei Systeme auf zwei oder drei Standorte verteilt

LOCAL

  • hier, im Herzen von München, entwickeln wir in der DMZ unsere Software

STAGE

  • hier Testen unsere Kunden Ihre Plattformen außerhalb der DMZ. Nach Freigabe wird es auf

LIVE

  • gespielt und ist damit für alle - sofern es kein geschlossenes B2B-System ist - sichtbar.

Die Herausforderung bei Datenbankmigrationen

Es werden neue Prozesse für unsere Kunden gemeinsam definiert. Diese entwickeln wir zunächst Local. Dazu muss ggf. das Datenmodell verändert bzw. erweitert werden. Dabei legen wir neue

  • Tabellen
  • Fremdschlüsseln
  • Indizes 

an. Diese müssen im laufenden Betrieb auf Stage und später auf Live kommen, ohne, dass eine Unterbrechung stattfindet und das möglichst effizient.

Und genau da kommen die Nachteile von relationalen Datenbanken zum Tragen

  • Entstehung semantischer Lücken: Entity-Typen werden in Tabellen abgelegt. Diese semantische Beziehungen zwischen Entitäten, wie sie im Entity-Relationship-Modell definiert werden, können in einem Relationenmodell nicht explizit ausgedrückt werden
  • Is-a- und Part-of-Beziehungen lassen sich ebenfalls nicht ausdrücken, da es im klassischen Relationenmodell nicht möglich ist, den Tupeln wiederum Sub-Tupel zuzuordnen.
  • Keine Unterscheidung von Identitäts- und Kompatibilitätsspalten
  • Deklaration von nur wenigen Datentypen möglich
  • Die bei der Normalisierung erforderliche Zerlegung der Daten in Einzelteile erschwert inhaltlich und unter Performance-Gesichtspunkten die Suche nach komplexeren Zusammenhängen: Daten, die getrennt voneinander gespeichert werden, müssen auf der Anwendungsebene in Form von Joins wieder zusammengeführt werden.
  • Es lässt sich wenig Wissen über die Regeln und Funktionen speichern, die mit den Daten verbunden sind.

Fazit

Datenmodell-Migrationen sind aufwendig

Die Lösung um nur Vorteile zu gewinnen

Unsere selbstbeschreibende Datenbanken mittels Metamodellen

Um alle o.g. Nachteilen in der Praxis auszuräumen haben wir ein Metamodell entwickelt, welches sich selbst beschreibt und mit virtuellen Datentypen angereichert ist.

Hier einige Beispiele:

Virtueller Datentyp bei IconParc 

  • eindeutiger Schlüssel (unique_key & als Identitätspalte gekennzeichnet)
  • Boolsches Flag (boolean_flag)
  • Objektname (name)
  • Primärschlüssel (objid)
  • Beschreibung (description)
  • Ersteller des Objects (creator)
  • Bearbeiter des Objects (updater) als 

... entspricht dem realen Datentyp bei MSSQL

  • varchar(50), not null + unique index
  • integer, not null
  • varchar(50), not null
  • integer, not null + primary index
  • text, nullable
  • integer, not null + foreign key to users
  • integer, not null + foreign key to users

Damit erfolgt die Migration extrem schnell, zielsicher und fehlerfrei.

 

Nicht nur das, sondern wir können auch die Inhalte problemlos systemübergreifend überführen, da wir Identitäts- sowie Kompatibilitätsdaten kennen und diese heranziehen können. 

Und wir können größere Migrationen auch automatisiert zu einem bestimmten System ausführen lassen, zum Beispiel in der Nacht, damit unter Tags die Performance nicht beeinträchtigt wird.

 

Um Fehler zu vermeiden, werden alle Datenbanken auf allen Systemen stündlich gecrawlt und so das Metamodell mit den real existierenden Datenbanken gegengecheckt.

Was unsere Kunden davon haben?

Maximale Agilität, Flexibilität, Effizienz
für extrem schnelles Wachstum

Ausgewählte Case Studies

Aktuelle Broschüren

Unsere selbstbeschreibende Datenbank mittels Metamodell

Inhaltsverzeichnis
    Der Elevator Pitch:
    IconParc in zweieinhalb Minuten erklärt


    - oder -

    12 GRÜNDE
    Ihre digitale Lösung von IconParc entwerfen
    und bauen zu lassen
    Was auch immer Ihr Digitalisierungsvorhaben ist

    Sprechen Sie mit uns.