Datenmodell Vorlagen

Bitte beachten

Datenmodel Templates/Vorlagen können nur aus Datenbanken mit MapEdit Datenmodel erzeugt werden.
Map3D/Topobase Datenbanken werden nicht unterstützt.

Warnung

Vor jedem Datenstrukturupdate mit einer Datenmodell Vorlage MUSS ZWINGEND ein Backup der Datenbank gemacht werden!
Der Update löscht/ändert wenn notwendig Views/Tabellen/Spalten. D.h. Änderungen/Erweiterungen an der Datenstruktur von Endanwendern werden damit ggf. auch gelöscht! MuM übernimmt keinen Haftung für Verluste solcher Daten !

Wozu sind Datenmodell Vorlagen gut?

Datenmodell Vorlangen werden dazu verwendet um versionierte Kopien eines Datenmodells zu erzeugen, weiter zu geben und aktuell zu halten.

Beispiel:
Sie sind eine Gemeinde A und haben eine Datenbank Baustellenverwaltung erzeugt. Ihre Nachbargemeinde B findet Ihre Datenbank fantastisch und will diese für deren Baustellen verwenden.

Sie könnten nun die Datenbank exportieren, die Nachbargemeinde B kann diese dann importieren und dann alle Daten Tabellen (Baustellen Daten) leeren um die eigenen Daten zu verwalten.

Nun erweitern Sie 2 Monate später ihre Datenbank um weitere Tabellen, Label Definitionen, Views ect. Die Gemeinde B hätte nun auch gerne diese neuen Änderungen. Nun wird es Problematisch da die Gemeinde B ja nun bereits Daten in deren Datenbank hat. Ein Export/Import funktioniert nun also nicht mehr. D.h. die Gemeinde B müsste nun händisch die neuen Tabellen/Label Definitionen/Views ect. in ihrer Datenbank anlegen.

Um diese Problem und andere zu lösen, wurden die Datenmodel Vorlagen erschaffen. Statt Datenbanken zu exportieren/importieren erzeugt man aus der Vorhandenen Datenbank eine Datenmodell Vorlage Datei mit der Version 1.

Diese Datei gibt man an der Gemeinde B und diese erzeugt damit ihre Datenbank. Wenn nun zu einem späteren Zeitpunkt die Gemeinde A Änderungen am Datenmodell macht aktualisiert Sie die Datenmodell Vorlage auf den neusten stand, dadurch entsteht die Version 2 und gibt diese an Gemeinde B.

Gemeinde B wendet dann die Datenmodell Vorlage auf ihre bereits existierende Datenbank an und alle Änderungen werden auf diese übertragen.

Ein anderer Einsatz von Vorlagen ist wenn sie eine Test Datenbank und eine Produktions Datenbank haben. Sprich sie erstellen ihr Datenmodell auf der Test Datenbank und wollen die Änderungen erst später auf die Produktions Datenbank übertragen.

Kurz Überblick

• Datenbank übergreifend (Oracle, Postgres, SQLite)
• Vorlage wir aus vorhandener DB Struktur erzeugt
• Nur für MapEdit Datenmodelle, nicht für Topobase/Map
• Enthält keine Feature Daten
• Enthält Kennungslistenwerte, Relationen, Label Definitionen, Utility Modelle, Topologien
• Anwender Kennungslisten ab ID 10000
• Anwender Label Definition ab ID 10000
• Tabelle ME_DATAMODEL enthält alle Model Ids
• Datentypenänderung unterstützt
• Vorsicht bei SQLs in Label Definitionen/Views.
• Vom Anwender händisch angelegte Trigger, Synonyme, Functions und Stored Procedures
  werden nicht übernommen!

Datenbank übergreifend (Oracle, Postgres, SQLite)

Vorlagen können dazu genutzt werden um Datenmodell Datenbank übergreifend zu erzeugen. D.h. Sie können ein Datenmodell mit einer Oracle Datenbank erzeugen und dies dann verwenden um eine Postgres oder SQLite Datenbank mit dem gleichen Datenmodel zu erzeugen.

Vorgehen zum Anlegen einer Vorlage

AppBuilder starten. Datenbanken -> Datenmodell Vorlagen -> Neu
Name vergeben
Datenbankverbindung auswählen
Beschreibung eingeben

"Update ist Pflicht" ?

Die Vorlage wird dann erzeugt und man sieht in zwei Ansichten (Registern) den Inhalt der Datenmodelvorlage.

Simple View

Zeigt einem die Änderungen als Text an. Die Informationen sind hierbei etwas gekürzt. z.B. werden Datenbank Felder die nicht vom Kunden angelegt wurden sondern vom System nicht angezeigt. Der Kunde sieht also nur die Felder die er selbst angelegt hat. Der Kunde legt z.B. eine Punkt Feature Tabelle an und ein Feld "Mein_feld".
In der Liste werden dann alle System Felder wie FID, DATE_CREATED usw, nicht aufgelistet sondern nur "mein_Feld".
Damit ist das ganze übersichtlicher.
Die Ansicht zeigt einem zuerst die letzte Version an und danach rückwärts die vorigen Versionen.

Extended View

Zeigt die Änderungen im Tabellenformat an. Man kann hier zum Beispiel sortieren und filtern nach version. Hier sieht man genau was passiert ist mit allen Details. Also, welcher Datensatz wurde bei Kennungslisten eingefügt oder verändert usw.

Weitergabe der Vorlage für Benutzer des Datenmodels

Um die Vorlage an Dritte weiterzugeben drücken Sie den "Herunterladen" Knopf. Die dabei erzeugte Datei kann dann wiederum auf einem anderen System mit dem "Hochladen" Knopf importiert werden.

Der Empfänger der Datenmodel Datei kann diese nicht editieren.

Warnung

Geben Sie immer nur die *.datamodel Datei weiter. Die Datei *.unlock darf nicht an den Benutzer weitergegeben werden. Kopieren Sie also manuell keine anderen Dateien ausser der *.datamodel Dateien des vom MapEdit Server vom Repository Verzeichnis "Repositories\Default\DataModels" zu einem anderen Rechner. (Weitere Erläuterungen im nächsten Kapitel)

Weitergabe der Vorlage für Autoren des Datenmodels

Die originale, Ausgangs Datenmodell Vorlage sollte immer nur auf einem MapEdit Server existieren und nur dort gepflegt werden da ansonsten Versionskonflikte entstehen können.

Ab 23.1.149 können weitergegebene Vorlagen nur noch geändert werden wenn zur Vorlage Datei eine zugehörige *.unlock Datei im gleichen Verzeichnis wie die Daten Model Vorlage Datei vorhanden ist.

Wenn man die Vorlage also auf einem anderen MapEdit Server bearbeiten werden soll dann muss die *.unlock Datei auf den MapEdit Server kopiert werden und im Idealfall vom Original MapEdit Server gelöscht werden. Damit kann man verhindern das die Datei an zwei Stellen geändert wird und damit zwei Versionen der Datei entstehen.

Versionskonflikte vermeiden.

Wie entsteht ein Versions Konflikt?

Ein Konflikt entsteht immer dann wenn an einer Kopie der original Daten model Datei geändert wird.

Die Firma "Heinzelmann GIS Systeme" erstellt auf ihrem Firmen MapEdit Server eine neue Daten model Datei "LANDSCHAFT.datamodel" und bearbeitet diese. Die aktuelle Version der Datei ist die Version 3 und es wurde die Tabelle BAUM mit den Spalten NAME und ALTER angelegt.

Nun gibt die Firma die Daten model Datei an den Kunden "Stadtwerke Europa" weiter da diese das Datenmodel auch anpassen will. Diese Kopiert diese auf ihren eigenen MapEdit Server. Nun fügt dieser die Tabelle BUSCH hinzu und die Version 4 entsteht. Da die Firma Europaweit arbeitet werden nun 50 Datenbanken mit dieser Daten model Vorlage auf die Version 4 upgedated.

Die Datei wird aber nun nicht zurück an "Heinzelmann GIS Systeme" geschickt!!

Nun fügt die Firma "Heinzelmann GIS Systeme" in ihrer Datei und Software
die Tabelle STRASSE hinzu und auch dort entsteht die Version 4.

D.h. beide Firmen haben nun ein Datenmodel "LANDSCHAFT.datamodel" mit einer Version 4. Jedoch mit verschiedenem Inhalt und somit ist ein Versions Konflikt entstanden.

Nun veröffentlicht die Firma "Heinzelmann GIS Systeme" eine neue Version ihrer Software und ihrer Datenmodel Datei.

Der Kunde "Stadtwerke Europa" installiert diese neue Software und die Datenmodel Datei und updated ihre Datenbanken. Da die Datenbank ja bereits die Version 4 hat, führt das System somit keinen Update durch und die Tabelle STRASSE wird nicht angelegt und die Software stürzt ab.

Wie kann diese verhindert werden? Was lief hier falsch?

Die Original Datei hätte nie von "Stadtwerke Europa" geändert werden dürfen.

A) Wenn der Kunde "Stadtwerke Europa" nur neue Tabellen hinzufügen und keine Attribute vorhandener Tabellen ändern will kann er eine neue Leere Datenbank anlegen die nur diese neuen Tabellen hat und aus diesem legt er dann eine eigene unabhängiges Datenmodelvorlage an. Diese eigene Datenmodelvorlage wendet er dann auf die LANDSCHAFT Datenbanken an.

B) Der Kunde "Stadtwerke Europa" will Attribute zu vorhandenen Tabellen hinzufügen und auch neue Tabellen anlegen. Er muss dazu eine neue eigene Datenmodel Vorlage aus der LANDSCHAFT Datenbanken erzeugen die seine Änderungen beinhaltet.

Diese Vorlage enthält dann die Inhalte von "Heinzelmann GIS Systeme" und seine eigenen. Auf seine LANDSCHAFT Datenbanken muss er dann immer zuerst die jeweilige neuste Version der Datenmodel Vorlage von "Heinzelmann GIS Systeme" anwenden und danach seine eigene Datenmodel Vorlage.

Anwenden der Vorlage

Es gibt zwei Möglichkeiten:

1. Man legt eine neue Datenbank an und am Ende frägt es einen ob und welche Vorlage man anwenden will.

2. Man hat eine vorhandene Datenbank und will dort eine Vorlage dazufügen.
   Dazu bei den Verbindungen auf die Datenstrukturansicht gehen, Kartei "Mehr". Dort gibt es eine Funktion "Datenmodell Vorlage anwenden".

   

Sollten Fehler beim Anwenden der Vorlage auftreten werden diese in einem Log File und in der Tabelle ME_DATAMODEL_UPDATE_LOG in der jeweiligen Datenbank geloggt.

Updaten der Vorlage auf den neusten Stand

Wenn man das Datenmodel (die Datenbank) geändert hat muss man die Datenmodel Vorlage auf den neusten Stand bringen so das die Aenderungen der Datenbank in die Vorlage einfliessen. Drücken Sie dazu den Knopf "Vorlage updaten". Es wird dann eine neue Version erzeugt und die Änderungen angezeigt.

Updaten der aus der Vorlage erzeugten Datenbanken auf den neusten Stand der Vorlage

Drücken Sie dazu den "Vorlage anwenden" Knopf. Es werden Ihnen alle Datenbanken angezeigt die das Datenmodell verwenden. Wenn Sie einzelne Datenbanken nicht updaten wollen können Sie bei der jeweiligen Datenbank den Haken bei "Update" entfernen.
Drücken Sie dann den "Anwenden" Knopf. Hierbei die letzten Versions Änderungen angewendet.

Der Knopf "Apply All Versions" erzwingt das alle Versionen nochmals auf die Datenbank angewendet werden. Diese Funktion sollte nur in Ausnahmefällen und nur wenn wirklich nötig genutzt werden und wenn man genau weis was man tut.

Wenn sie alle Datenbanken aller Datenmodell auf einen Schlag updaten wollen können Sie dies mit dem Knopf "Apply all Templates" durchführen. Diesen Knopf finden Sie im Baum wenn sie auf Datenbanken->Datenmodelvorlagen klicken.

Trigger, Synonyme, Sequenzen, Functions, Stored Procedures, Packages etc

Trigger, Synonyme, Sequenzen, Functions, Stored Procedures und Packages die vom Anwender selbst angelegt wurden werden nicht in die Vorlage übernommen da diese nicht Datenbankübergreifend funktionieren.

MapEdit verwendet statt serverseitigen Trigger, softwareseitige Feature Rules. Diese sind dann für allen Datenbanktypen die exakt gleichen.

Einzig zur Vergabe der nächsten FID werden von MapEdit Trigger und eine Sequence angelegt. Diese werden beim Anwender der Vorlage automatisch angelegt.

Views

Beachten Sie das Views die z.B. mit Oracle angelegt wurden nicht zwangsläufig in Postgres oder SQLite funktionieren da die verschiedenen Datenbanktypen verschiedene Funktionen und keine einheitliche SQL Syntax haben.

Nur einfache Views funktionieren ggf. in allen Datenbank Typen.

Sie können für jeden Datenbank typ einen eigenen View SQL angeben. Klicken Sie dazu im AppBuilder auf den jeweiligen View und klicken Sie dann "SQL bearbeiten" und dann "Definition for Migrations". Hier können Sie dann für jeden Datenbank Typen einen Datenbank Spezifischen SQL angeben. Aktivieren Sie dazu "Overwrite SQL" und geben Sie den Datenbank spezifischen SQL für den View ein.

Views und Tabellen die händisch angelegt wurden und nicht über die AppBuilder Oberfläche müssen registriert werden, ansonsten werden Sie nicht in die Vorlage übernommen. Klicken Sie dazu auf das Thema/Topic in das der View aufgenommen werden soll und klicken Sie dann auf "View/Tabelle Registrieren".

Warnung

Benutzen Sie keine Views die auf andere Views zugreifen!
Siehe:
Achtung mit Views die andere Views benutzen
https://help.mapedit.de/docs/dokumentation/MapEdit-AppBuilder/database-connections/structure/views/#achtung-mit-views-die-andere-views-benutzen

Kennungslisten

Alle Datensätze aller Domain/Kenunngslisten Tabellen werden in die Vorlage übernommen.

Wenn der Kunde die Vorlage auf seine Datenbank anwendet werden bei ihm die Datensätze erzeugt bzw auf den neusten Stand upgedated.

Ausserdem wird beim Kunden in jeder Kennungsliste ein Datensatz mit der ID=10000 Value="DO NOT USE" angelegt.

Das wird deshalb gemacht das wenn der Kunde eigene Kennungslisten Datensätze anlegt, das seine eigenen Datensätze bei 10001 anfangen. Damit haben Kennungslisten die aus der Datenmodel Vorlage kommen eine eindeutige ID.

Dieser ID=10000 Datensatz wird in der Datenbank die als Vorlage für das Datenmodel dient nicht angelegt.

ACHTUNG:
Man darf diese dort auch nicht anlegen. Das könnte passieren wenn jemand ein Vorlage auf so eine Vorlage Datenbank anwendet.......

Der Kunde sollte nie Kennungslisten Eintrage unter 10000 eingeben! Die Kann eigentlich auch nur passieren wenn er nicht die UI des AppBuilder oder Generic Masken benutzt sondern händisch via SQL mit Gewalt Datensätze einfügt.

Die Datenmodell GUID

Wenn man eine neue Fachschale macht dann braucht diese zur Erkennung fuer Datenstruktur Updates und zur verwendung mit Plugins eine eindeutige Daten Model Id.

Diese ID ist eine GUID und wird in der Tabelle ME_DATAMODEL verwaltet.

Das vorgehen ist folgenderweise:

Man legt die neue Fachschalen Datenbank an und erzeugt die gewuenschte Datenstruktur.

Danach legt man eine Datenmodell vorlagen auf diese Datenbank an. Diese Vorlage dient dann spaeter zum Updaten und anlegen neuer Datenbanken. Der Name der Vorlage muss sprechende das Datenmodel beschrieben. z.B. "MUM_ELECTRIC" fuer das Strom datenmodel.

Beim anlegen der Datenmodell vorlagen wird dann automatisch in der Datenbank die man als vorlage nimmt ein Eintrag in ME_DATAMODEL erzeugt. Diese GUID ist sehr sehr wichtig!! Diese wird einem beim anlegen angezeigt.

Diese ID stellt nachher die Verbindung zu dem Fachschalen Plugin dar. d.h. wenn diese ID nicht die gleiche ist dann funktioniert das Plugin nicht und auch der Datenstruktur update!!

ACHTUNG: Es darf je Fachschale nur genau eine Datenmodellvorlagen geben!!! Wenn man eine zweite Vorlage anlegt dann wird ein weitere eintrag in ME_DATAMODEL angelegt. d.h. dort sind dann zwei eintrage und es gibt dann auch chaos wil nun nicht mehr eindeutig klar ist welches die richtige ist.

Also immer nur eine originale Datenbank und Datenbank vorlage verwalten!!

Im Fall das die Datenbankvorlage verloren geht, kann diese neu angelegt werden in dem man die GUID in den Dialog eingibt.

Anmerkung: Ein Kunde kann die Datenmodel vorlagen auch dazu verwenden eine Datenbanken weiter zu geben. Diese Kundendatenbank koennte ggf. mehrere Datenmodelle beinhalten z.b. Gas, Wasser und Strom in einer DB. d.h. es kann also tatsaechlich sein da es mehrere eintrage in ME_DATAMODEL gibt.

Warnung

Datenmodel Dateien dürfen nicht einfach kopiert werden um neue Datenmodelle daraus zu erzeugen, ansonsten steht dort die gleiche GUIID

Hinweis

Die Datenmodel GUID und die Version wird, wenn man eine Vorlage auf eine Datenbank anwendet in der Tabelle ME_DATAMODEL gespeichert.

Beispiel:
SQL> select * from ME_DATAMODEL

Synchronisieren von ausgewählten Feature Tabellen

ab 22.2.98

Sie können die Datensätze einzelner Feature Tabellen in die Vorlage übernehmen. Dadurch können Sie Datensätze synchron halten.

Die Feature Tabelle benötigt dazu eine eindeutige Spalte die "nicht null" und einen Eindeutigkeitsindex hat. Diese Spalte darf nicht die FID sein!

Beispiel: Wenn die Tabelle keine Datensätze enthält:

• Legen Sie in der Tabelle eine neue Text Spalte an
• Vergeben Sie einen Namen, z.B. "NAME"
• Aktivieren Sie die Option "Eindeutig"
• Deaktivieren Sie die Option "Optional"

Wenn die Tabelle bereits Datensätze enthält dann:

• Legen Sie in der Tabelle eine neue Text Spalte an
• Vergeben Sie einen Namen, z.B. "NAME"
• Deaktivieren Sie die Option "Optional"
• Füllen Sie die Spalte NAME mit eindeutigen Werten (z.B. via SQL)
• Unter Tabelle->Indexe klicken Sie auf hinzufügen, aktivieren sie den hacken vor der Spalte NAME und aktivieren Sie "Create Unique index". und dann OK.

Gehen Sie dann auf "Tabelle->Einstellungen Daten Model Vorlage".

• Aktivieren Sie die Option "Diese Tabelle synchronisieren"
• Wählen Sie die neu angelegte Spalte "NAME" bei "Eindeutige Sync Spalte" aus.

Beim nächsten Update/Erzeugen der Datenmodel Vorlage werden dann alle neuen und geänderten Datensätze in die Vorlage übernommen. Werden Datensätze gelöscht dann werden diese beim nächsten update der Datenmodel Vorlage als gelöscht markiert und beim anwenden der Vorlage aus der Zieldatenbank entfernt.

Beachten Sie das die FID der Datensätze nicht übernommen wird sondern neu vergeben wird. D.h. Relationen auf diese FIDs gehen in der Zieldatenbank verloren. Verwenden Sie deshalb zur Verknüpfung von Synchronisierten Tabellen nie die FID sondern z.B. die extra angelegte Eindeutige Spalte (im Beispiel "NAME")

Warnung

Beachten Sie das wenn ihre Tabelle sehr viele Datensätze hat, das dann der update entsprechen lange dauern wird und das die Datenmodel Vorlagendatei und die Zieldatenbank entsprechenden Speicherplatz für diese Daten benötigt!

Warnung

Wenn Sie mit der Variantenplanung arbeiten, denken Sie bitte daran das diese Daten in jede Planungsdatenbank übernommen werden und sich der Speicherplatz dadurch multipliziert. Gehen Sie also sparsam mit dieser Option um und bedenken Sie vorab die Folgen. D.h. wenn Sie eine Tabelle synchronisieren die 1 Millionen Datensätze hat und Sie haben 2000 Planungsdatenbanken, dann benötigen Sie für 2000 Planungsdatenbanken den Festplatten platz für je 1 Millionen. Sprich den Platz für 2000 Millionen Datensätze. Dadurch kann ggf. die Festplatte ihrer Datenbank zulaufen.

Exportieren

Hiermit kann die Vorlage heruntergeladen werden und dann an anderer Anwender weitergegeben werden.

Letzte Version entfernen

Hiermit können alle Änderungen der jeweils letzte Version entfernt werden.
Dies kann vorkommen wenn man Fehler festgestellt hat die man nicht weitergeben will.

Wenn die letzte Version bereits eine gelöschte Version ist, wird die nächste, nicht gelöschte Version, gelöscht.

Die Versionsnummer wird hier jeweils immer beibehalten und nicht wiederverwendet, nur der Inhalt wird entfernt. Dies ist zur Sicherheit so da ansonsten wenn jemand bereits diese Version erhalten hat bei demjenigen kein Update durchgeführt werden würde.

Vorlage anwenden

Mit dieser Funktion können alle Datenbanken die die Vorlage (ein Datenmodel) verwenden auf die aktuellste Version gebracht werden.

Log

Öffnet das Verzeichnis in dem die Log Dateien gespeichert werden. Diese sind Maschinen abhaengig!

Fehler werden ggf. in der Tabelle ME_DATAMODEL_UPDATE_LOG in der jeweiligen Datenbank geloggt.
View Definition werden vor dem Löschen/Ändern auch hier geloggt.

Datenmodell übergreifende Funktionen

Klicken Sie im Repository Baum auf "Datenbanken->Datenmodell Vorlagen" um übergreifende Funktionen zu sehen.

Neue Vorlage anlegen

Mit Neu wird ein neue Vorlage angelegt (Keine Datenbank). Die Vorlage ist eine Datei in der beschrieben ist, wie die Datenstruktur aussieht. Darin sind keine Daten enthalten außer: Daten die Teil der Struktur sind, wie Relationen, Label Definitionen, Kennungslisten Werte, Utility Modelle, Topologien etc. Die eigentlichen Datensätze von Featureklassen  wie z.Bsp. GEBAEUDE oder FLURSTUECKE sind darin nicht vorhanden. Man könnte also eine neue Datenbank entwerfen, zum Beispiel Fachschale Baustellen und macht dann aus dieser Datenbank eine Vorlage. Aus dieser Vorlage könnte dann eine neue Datenbank angelegt werden.

Importieren

Mit dieser Funktion können Sie eine Vorlagen Datei ins Repository hochladen / importieren.

Apply all Templates / Alle Vorlagen anwenden

Mit dieser Funktion können alle Datenbanken aller Datenmodelle auf die aktuellste Version gebracht werden.

Log

Öffnet das Verzeichnis in dem die Log Dateien gespeichert werden. Diese sind Maschinen abhaengig!

Fehler werden auch in der Tabelle ME_DATAMODEL_UPDATE_LOG in der jeweiligen Datenbank geloggt.

Version von gelöschten Spalten ändern

Hiermit kann das löschen von Spalten nachträglich in eine andere Version verschoben werden.

Bedenken Sie das diese Aktion keine Auswirkung auf Datenbanken auf welche die Vorlage bereits angewendet wurde hat.

Aktivieren Sie das Register "Extended View" und wählen Sie "Columns (Extended Infos)".
Finden Sie die Zeile in der die Spalte gelöscht wurde. Sie erkennen gelöschte Spalten am Mode "DELETE". Doppelklicken Sie die Zeile und wählen Sie "CHANGE VERSION".

Wählen Sie die Version aus, in die der Lösch Befehl verschoben werden soll.

Diese Funktion kann nützlich sein wenn eine Vorlage für Oracle erzeugt wurde und später für Postgres verwendet wird. In Oracle können Spalten gelöscht werden die noch in Views verwendet werden, in Postgres nicht. Die kann zu Problemen führen die durch das verschieben des Löschens in eine andere Version gelöst werden können.

Titel von Tabellen, Spalten und Themen

Die Titel von Tabellen, Spalten und Themen werden bei einem Update nicht mehr ersetzt. D.h. nur neue Tabellen/Spalten/Themen werden aus der Vorlage übernommen.

Viele Benutzter wollen diese Titel auf eigene Einstellungen setzen und wollen nicht das diese durch eine Modell Update verändern werden.

Nachteil:
Wenn gewollt der Titel hinterher geändert werden soll, z.B. wegen eines Schreibfehlers, ist dies nun nicht mehr über den Model Update möglich.

Workaround: Ein SQL Script bereitstellen und diese nachträglich laufen lassen.

Datenformat ".DataModel" Dateien

Die DataModel Dateien werden als gezippte JSON Dateien gespeichert. Die DatenModel Vorlage muss mindestens einmal im AppBuilder angezeigt werden damit es vom alten binären Format in das JSON Format umgewandelt wird.

Die JSON Datei sollten Sie nur bearbeiten wenn Sie genau wissen was Sie tun und wenn Sie das genaue Format der Datei einhalten wie Feldnamen, Gross/Klein-Schreibung etc, anderen Falls wird das öffnen im AppBuilder bzw der Datenupdate fehlschlagen.

Wir übernehmen keinen Support für Fehler die durch eigene manuelle Änderungen an der Datei vorgenommen wurde.

Erzeugen Sie vor dem ändern der Datei immer eine Datensicherung der Datei.

Zum zippen muss immer das ZIP Format verwendet werden (nicht 7zip Format oder anderes) ansonsten schlägt das Laden fehl.

Warnung

Bedenken Sie das alle Änderungen in der Datei keine Auswirkung auf Datenbanken hat auf die die Vorlage bereits angewendet wurde. D.h. wenn Sie neue Spalten/Tabellen etc dort anlegen sind diese bei bereits vorhandenen Datenbanken dann nicht vorhanden und das anlegen von Views etc wird dann fehlschlagen. Vermeiden Sie das händische editieren der Datei und tun Sie das nur in Ausnahmefällen.

Vorgehen:

Exportieren Sie das Datenmodel und speichern Sie die Datei auf ihrer Festplatte in einem neuen Temporären Verzeichnis das sonst keine Dateien enthält.

Entzippen Sie nun die ".datamodel" Datei, z.B. mit 7-Zip.

Sie finden dann eine Datei "*.datamodel.json"

Warnung

Bitte entzippen Sie die Datei NIE direkt im Ordner "C:\inetpub\wwwroot\MumGeoData\Repositories\Default\DataModels". In diesem Verzeichnis dürfen keine Unterordner oder andere Datei erstellt werden.

Diese Datei können Sie nun mit einem Text editor bearbeiten.

Siehe auch:
https://help.mapedit.de/docs/dokumentation/MapEdit-AppBuilder/more/ViewJson

Nach dem bearbeiten muss die "*.datamodel.json" wieder gezippt werden.

Löschen Sie die Datei ".datamodel" so das nur noch die Datei ".datamodel.json" vorhanden ist.

Benutzen Sie dann 7-zip im Datei Explorer um die Datei zu zippen.

Warnung

Zum zippen muss immer das ZIP Format verwendet werden, nicht das 7zip Format oder anderes, ansonsten schlägt das Laden fehl. In der Zip Datei darf die Datei auch nicht in einem Unterordner sein!

Benennen Sie nun die Datei "*.datamodel.json.zip" um in ".datamodel"

Im AppBuilder Importieren Sie nun die "*.datamodel" Datei

Ich benutzte eine Vorlage die jemand anders erzeugt hat und will diese erweitern

Siehe auch "Versionskonflikte vermeiden" oben.

Das beste Vorgehen ist:

• Eine eigenen Datenbank "A" auf Grundlage der "fremd" Vorlage erzeugen.
• Aus dieser Datenbank "A" eine eigene Vorlage erzeugen.
• Darauf achten das wenn das "original" Datenmodel sich aendert das dann jeweils auch die eigene Vorlage aktualisiert werden muss.

Was bedeutet "inherited" hinter dem Datenmodellname?

inherited = vererbt

Das mit inherited markierte Datenmodell ist das Ausgangsdatenmodel.
In Beispiel wurde aus dem Datenmodel MUM_ELECTRIC ein eigenes Datenmodell MY_STROM_VORLAGE erzeugt.
D.h. das Modell MY_STROM_VORLAGE basiert auf dem Datenmodell MUM_ELECTRIC.
Wenn das MUM_ELECTRIC sich ändert muss zuerst das Datenmodell MY_STROM_VORLAGE mit der MUM_ELECTRIC Vorlage aktualisiert werden und dann der Enduser mit dem neuen stand der MY_STROM_VORLAGE Datenmodell Vorlage.