ilid2db ist eine in Java erstellte Programmfamilie, die zurzeit ili2pg, -ili2fgdb, ili2gpkg, ili2ora, ili2mssql, ili2mysql und ili2h2gis umfasst.
-Damit kann eine -Interlis-Transferdatei (itf oder xtf) einem Interlis-Modell entsprechend -(ili) mittels 1:1-Transfer in eine Datenbank (PostgreSQL/Postgis bzw. -GeoPackage) gelesen werden oder aus der Datenbank mittels einem 1:1-Transfer -eine solche Transferdatei erstellt werden. Folgende Funktionen sind möglich:
-Folgende Transferformate werden unterstĂŒtzt:
-Beim Schemaimport (--schemaimport) wird anhand des INTERLIS Modells das -Datenbankschema angelegt.
-Diverse Optionen beeinflussen die Abbildung.
-Den Geometrien kann mittels Parameter ein EPSG-Code zugewiesen werden. -Die Geometrie-Attribute können optional indexiert werden.
-Beispiel:
--java -jar ili2gpkg.jar --schemaimport --dbfile mogis.gpkg path/to/dm01av.ili --
Der Import (--import) schreibt alle Objekte (im Sinne der eigentlichen Daten) -der Transferdatei in die Datenbank.
-Diverse Optionen beeinflussen, was mit den bestehenden Daten in der DB geschieht.
-Area- und Surface-Geometrien werden bei Interlis 1 polygoniert.
-Kreisbögen werden als Kreisbögen importiert und somit nicht segmentiert -(oder können optional auch segmentiert werden).
-Beispiel:
--java -jar ili2gpkg.jar --import --dbfile mogis.gpkg path/to/data.xtf --
Der Export (--export) schreibt alle Daten aus der Datenbank in eine -Transferdatei.
-Mit weiteren Optionen wird gesteuert, welche Daten aus der Datenbank exportiert -werden.
-Genau einer der Parameter --models, --topics, --baskets oder --dataset -muss zwingend verwendet werden, um die zu exportierenden DB-Records auszuwÀhlen.
-Der Parameter --exportModels definiert das Export-Modell, indem die Daten -exportiert werden (der Parameter ist also keine Alternative, -sondern ein Zusatz fĂŒr --models, --topics, --baskets oder --dataset). -Als Export-Modelle sind Basis-Modelle (also z.B. Bundes-Modell -statt Kantons-Modell) oder ĂŒbersetzte Modelle (also z.B. DM_IT statt DM_DE) zulĂ€ssig. -Ohne die Option --exportModels werden die Daten so wie sie erfasst sind -(bzw. importiert wurden), exportiert.
-Geometrien vom Typ Area und Surface werden bei Interlis 1 wÀhrend dem -Export in Linien umgewandelt.
-Beispiel:
--java -jar ili2gpkg.jar --export --models DM01 --dbfile mogis.gpkg path/to/output.xtf --
Die Log-Meldungen sollen dem Benutzer zeigen, was das Programm macht. -Am Anfang erscheinen Angaben zur Programm-Version. -Falls das Programm ohne Fehler durchlÀuft, wird das am Ende ausgegeben.:
--Info: ili2fgdb-3.10.7-20170823 -... -Info: compile models... -... -Info: ...export done --
Bei einem Fehler wird das am Ende des Programms vermerkt. Der eigentliche -Fehler wird aber in der Regel schon frĂŒher ausgegeben.:
--Info: ili2fgdb-3.10.7-20170823 -... -Info: compile models... -... -Error: DM01.Bodenbedeckung.BoFlaeche_Geometrie: intersection tids 48, 48 -... -Error: ...import failed --
Um fehlerhaften Daten zu importieren (um sie danach (z.B. im GIS) zu flicken), muss mindestens die -Validierung ausgeschaltet werden (--disableValidation). Das DB Schema muss -aber auch so angelegt werden, dass fehlerhafte Werte als Text importiert werden können (--sqlColsAsText) -bzw. durch NULL ersetzt werden können (--sqlEnableNull). -Und die Programmlogik fĂŒr den Datenimport muss die Fehler -tolerieren (--skipReferenceErrors und --skipGeometryErrors), so dass -z.B. eine Referenz auf ein nicht vorhandenes Objekt ignoriert wird.
-Um solche Daten zu importieren (um sie danach zu flicken):
--java -jar ili2gpkg.jar --schemaimport --sqlEnableNull --sqlColsAsText --dbfile mogis.gpkg path/to/mo.ili -java -jar ili2gpkg.jar --import --skipReferenceErrors --skipGeometryErrors --disableValidation --dbfile mogis.gpkg path/to/data.xtf --
Bei ITF (Interlis 1): Fehlerhafte AREA Attribute können fĂŒr -den ganzen Datensatz nicht als Polygone -gelesen werden, weil ein Programm nicht erkennen kann, welche Linien und -Punkte falsch sind (Punkt und/oder Linie zu viel oder zu wenig; Linie zu kurz oder zu lang); -und somit nicht erkennen kann, bei welchem Polygon der Fehler ist. -Dass diese Daten nicht gelesen werden können, hat also nicht in erster Linie -mit der Validierung zu tun, sondern damit, dass aus den Linien+Punkten -keine Polygone gebildet werden können. Die Polygonbildung muss also -ausgeschaltet werden (--skipPolygonBuilding).
-Um solche Daten zu importieren (um sie danach zu flicken):
--java -jar ili2gpkg.jar --schemaimport --sqlEnableNull --sqlColsAsText --skipPolygonBuilding --dbfile mogis.gpkg path/to/mo.ili -java -jar ili2gpkg.jar --import --skipReferenceErrors --skipPolygonBuilding --skipGeometryErrors --disableValidation --dbfile mogis.gpkg path/to/data.itf --
Das Programm setzt Java 1.6 voraus.
-PostGIS: Als Datenbank muss mindestens PostgreSQL 8.3 und PostGIS -1.5 vorhanden sein. Falls das Interlis Datenmodell INTERLIS.UUIDOID als -OID verwendet, wird die Funktion uuid_generate_v4() verwendet. -Dazu muss die PostgreSQL-Erweiterung uuid-ossp konfiguriert sein -(CREATE EXTENSION "uuid-ossp";). Mit der Option --setupPgExt -erstellt ili2pg die fehlenden notwendigen Erweiterungen.
-FileGDB: Es muss Visual Studio 2015 C and C++ Runtimes -installiert sein. Je nach Java Version (Die Java Version ist massgebend, nicht die Windows Version) muss -die 32-bit oder 64-bit Version dieser Laufzeitbibliothek installiert sein. Falls diese Laufzeitbibliothek nicht -installiert ist, gibt es einen Fehler beim laden der FileGDB.dll. -Zur Laufzeit entpackt ili2fgdb zwei DLLs/Shared-Libraries und lÀdt -diese. Der Benutzer benötigt also die Berechtigungen, um diese Bibliotheken zu -laden.
-GeoPackage: Zur Laufzeit entpackt ili2gpkg eine DLL/Shared-Library und lÀdt -diese. Der Benutzer benötigt also die Berechtigungen, um die Bibliothek zu laden.
-GNU Lesser General Public License
-In den folgenden Abschnitten wird die Funktionsweise anhand einzelner -AnwendungsfĂ€lle beispielhaft beschrieben. Die detaillierte Beschreibung -einzelner Funktionen ist im Kapitel âReferenzâ zu finden.
-Die Tabellen existieren nicht und sollen in der Datenbank angelegt -werden (--schemaimport).
-PostGIS: java -jar ili2pg.jar --schemaimport --dbdatabase mogis ---dbusr julia --dbpwd romeo path/to/dm01.ili
-GeoPackage: java -jar ili2gpkg.jar --schemaimport --dbfile -mogis.gpkg path/to/dm01.ili
-FileGDB: java -jar ili2fgdb.jar --schemaimport --dbfile -mogis.gdb path/to/dm01.ili
-Es werden keine Daten importiert, sondern nur die leeren Tabellen -angelegt.
-PostGIS: Die leeren Tabellen werden im Default-Schema des Benutzers -julia angelegt. Die Geometrie-Spalten werden in der Tabelle -public.geometry_columns registriert.
-Als Host wird der lokale Rechner angenommen und fĂŒr die Verbindung zur -Datenbank der Standard-Port.
-GeoPackage: Die Geometrie-Spalten werden in den Tabellen -gpkg_contents und gpkg_geometry_columns registriert.
-Falls die Datei mogis.gpkg noch nicht existiert, wird sie erzeugt und -mit den fĂŒr GeoPackage nötigen Metatabellen initialisiert. -Falls die Datei schon existiert, werden die Tabellen ergĂ€nzt.
-FileGDB: Falls die Datei mogis.gdb noch nicht existiert, wird sie erzeugt. -Falls die Datei schon existiert, werden die Tabellen ergÀnzt.
-Das gewĂŒnschte Schema und die Tabellen existieren nicht und es soll das -DB-Schema und -Datenmodell angelegt werden:
-PostGIS: java -jar ili2pg.jar --schemaimport --dbdatabase mogis ---dbschema dm01av --dbusr julia --dbpwd romeo path/to/dm01.ili
-Es werden keine Daten importiert, sondern nur das Schema dm01av (--dbschema dm01av) und die -leeren Tabellen angelegt. Die Geometrie-Spalten werden in der Tabelle -public.geometry_columns registriert.
-Die Tabellen existieren nicht und sollen in der Datenbank angelegt -werden. Es werden keine Daten importiert, sondern nur die leeren Tabellen -angelegt:
-PostGIS: java -jar ili2pg.jar --schemaimport --dbhost ofaioi4531 --dbport -5432 --dbdatabase mogis --dbusr julia --dbpwd romeo ---createEnumTabs --createBasketCol --log path/to/logfile path/to/dm01.ili
-GeoPackage: java -jar ili2gpkg.jar --schemaimport --dbfile mogis.gpkg ---createEnumTabs --createBasketCol --log path/to/logfile path/to/dm01.ili
-FileGDB: java -jar ili2fgdb.jar --schemaimport --dbfile mogis.gdb ---createEnumTabs --createBasketCol --log path/to/logfile path/to/dm01.ili
-Alle Tabellen werden in der Datenbank erstellt. -Die Geometrie-Spalten werden registriert. Als Primary-Key -wird ein zusĂ€tzliches Attribut erstellt (t_id). ZusĂ€tzlich wir ein -t_basket Attribut erstellt (--createBasketCol). Dieses zeigt als FremdschlĂŒssel auf eine -Meta-Hilfstabelle (Importdatum, Benutzer, Modellname, Pfad der -Itf-Datei).
-Die AufzÀhltypen werden in Lookup-Tables abgebildet (--createEnumTabs).
-Es wird ein Logfile angelegt (--log path/to/logfile). -Dieses enthÀlt Zeitpunkt des Schemaimports, Name -des Benutzers, Datenbankparameter (ohne Passwort), Name (ganzer Pfade) -der Ili-Datei, sÀmtliche Namen der importierten Tabellen. AllfÀllige Fehlermeldungen -(bei Importabbruch) werden auch in die Logdatei geschrieben.
-Enumerations werden zusĂ€tzlich als Textattribut hinzugefĂŒgt:
-PostGIS: java -jar ili2pg.jar --schemaimport --createEnumTxtCol ---dbdatabase mogis --dbusr julia --dbpwd romeo path/to/dm01.ili
-GeoPackage: java -jar ili2gpkg.jar --schemaimport --createEnumTxtCol ---dbfile mogis.gpkg path/to/dm01.ili
-FileGDB: java -jar ili2fgdb.jar --schemaimport --createEnumTxtCol ---dbfile mogis.gdb path/to/dm01.ili
-Das Modell wird in die Datenbank importiert. Es werden keine Daten importiert, sondern nur die leeren Tabellen -angelegt. -ZusĂ€tzlich werden die -Attribute vom Typ Enumeration in ihrer TextreprĂ€sentation (Attribut -âartâ = 0 â âart_txtâ = âGebaeudeâ) hinzugefĂŒgt (--createEnumTxtCol).
-Den Geometrien wird ein spezieller SRS (Spatial Reference System) -Identifikator hinzugefĂŒgt:
-PostGIS: java -jar ili2pg.jar --schemaimport --defaultSrsAuth EPSG ---defaultSrsCode 2056 --dbdatabase mogis --dbusr julia --dbpwd romeo -path/to/dm01.ili
-GeoPackage: java -jar ili2gpkg.jar --schemaimport --defaultSrsAuth EPSG ---defaultSrsCode 2056 --dbfile mogis.gpkg path/to/dm01.ili
-FileGDB: java -jar ili2fgdb.jar --schemaimport --defaultSrsAuth EPSG ---defaultSrsCode 2056 --dbfile mogis.gdb path/to/dm01.ili
-Das Modell wird in die Datenbank importiert. Es werden keine Daten importiert, sondern nur die leeren Tabellen -angelegt. -ZusĂ€tzlich wird jeder -Geometrie eine SRS-ID (EPSG-Code 2056) hinzugefĂŒgt -(--defaultSrsAuth EPSG --defaultSrsCode 2056). -Ebenfalls wird derselbe Identifikator fĂŒr -die Registrierung der Geometriespalten in den Metatabellen der Datenbank -benutzt.
-Geometrien werden indexiert:
-PostGIS: java -jar ili2pg.jar --schemaimport --createGeomIdx --dbdatabase -mogis --dbusr julia --dbpwd romeo path/to/dm01.ili
-GeoPackage: java -jar ili2gpkg.jar --schemaimport --createGeomIdx --dbfile -mogis.gpkg path/to/dm01.ili
-Das Modell wird in die Datenbank importiert. Es werden keine Daten importiert, sondern nur die leeren Tabellen -angelegt. -Die Geometrien werden -indexiert (--createGeomIdx).
-FileGDB: Die Geometrien sind grundsÀtzlich immer indexiert.
-Die Tabellen existieren bereits und der Inhalt der Tabellen soll -erweitert werden (--import):
-PostGIS: java -jar ili2pg.jar --import --dbdatabase mogis --dbusr -julia --dbpwd romeo path/to/260100.itf
-GeoPackage: java -jar ili2gpkg.jar --import --dbfile mogis.gpkg -path/to/260100.itf
-FileGDB: java -jar ili2fgdb.jar --import --dbfile mogis.gdb -path/to/260100.itf
-Das Itf 260100.itf wird importiert und die Daten den bereits vorhanden -Tabellen hinzugefĂŒgt. Die Tabellen können zusĂ€tzliche Attribute -enthalten (z.B. bfsnr, datum etc.), welche beim Import leer bleiben.
-Die Tabellen existieren bereits und der Inhalt der Tabellen soll durch -den Inhalt des itf ersetzt werden (--import):
-PostGIS: java -jar ili2pg.jar --import --deleteData --dbdatabase -mogis --dbusr julia --dbpwd romeo --log path/to/logfile path/to/260100.itf
-GeoPackage: java -jar ili2gpkg.jar --import --deleteData --dbfile -mogis.gpkg --log path/to/logfile path/to/260100.itf
-FileGDB: java -jar ili2fgdb.jar --import --deleteData --dbfile -mogis.gdb --log path/to/logfile path/to/260100.itf
-Das Itf 260100.itf wird importiert und die bestehenden Daten in den -bereits vorhanden Tabellen gelöscht (--deleteData). Die Tabellen können zusÀtzliche -Attribute enthalten (z.B. bfsnr, datum etc.), welche beim Import leer -bleiben.
-Es wird ein Logfile angelegt (--log path/to/logfile). Dieses enthÀlt Zeitpunkt des Imports, Name -des Benutzers, Datenbankparameter (ohne Passwort), Name (ganzer Pfade) -der Ili- und Itf-Datei, sÀmtliche Namen der importierten Tabellen inkl. -Anzahl der importierten Elemente pro Tabelle. AllfÀllige Fehlermeldungen -(bei Importabbruch) werden auch in die Logdatei geschrieben.
-Tauchen beim Import des Itf Fehler auf (z. B. mangelnde -ModellkonformitÀt oder verletzte Constraints in der DB), bricht der -Import ab.
-PostGIS, GeoPackage: Bei einem Fehler werden keine Daten importiert, -d.h. der Import in die Datenbank ist ein einzelner Commit.
-FileGDB: Da die FileGDB keine Transaktionen unterstĂŒtzt, werden die Daten -teilweise importiert, und die FileGDB befindet sich danach evtl. in einem -inkonsistenten Zustand.
-Die Tabellen werden aus der Datenbank in eine Interlis 1-Transfer-Datei -geschrieben (--export):
-PostGIS: java -jar ili2pg.jar --export --models DM01AV --dbhost -ofaioi4531 --dbport 5432 --dbdatabase mogis --dbusr julia --dbpwd romeo -path/to/output.itf
-GeoPackage: java -jar ili2gpkg.jar --export --models DM01AV --dbfile -mogis.gpkg path/to/output.itf
-FileGDB: java -jar ili2fgdb.jar --export --models DM01AV --dbfile -mogis.gdb path/to/output.itf
-Die Daten aller Tabellen des Interlis-Modells DM01AV (--models DM01AV) -werden in die -Interlis 1-Transferdatei output.itf geschrieben. Fehlende Tabellen in -der Datenbank werden dementsprechend als leere Tabellen oder gar nicht -(gemĂ€ss Definition im Datenmodell) in die Datei geschrieben. Fehlende -Attribute in einer Datenbanktabelle werden mit einem â@â substituiert.
-Anhand des Parameters --models wird definiert, welche Daten exportiert -werden. Alternativ kann auch der Parameter --topics, --baskets oder --dataset -verwendet werden, um die zu exportierenden Daten auszuwÀhlen. Einer -dieser Parameter muss also zwingend beim Export angegeben werden.
-Die Tabellen werden aus der Datenbank in eine Interlis 2-Transfer-Datei -geschrieben (--export):
-PostGIS: java -jar ili2pg.jar --export --models DM01AV --dbhost -ofaioi4531 --dbport 5432 --dbdatabase mogis --dbusr julia --dbpwd romeo -path/to/output.xtf
-GeoPackage: java -jar ili2gpkg.jar --export --models DM01AV --dbfile -mogis.gpkg path/to/output.xtf
-FileGDB: java -jar ili2fgdb.jar --export --models DM01AV --dbfile -mogis.gdb path/to/output.xtf
-Die Daten aller Tabellen des Interlis-Modells DM01AV (--models DM01AV) -werden in die -Interlis 2-Transferdatei output.xtf geschrieben. Fehlende Tabellen und -Attribute in der Datenbank werden gar nicht in die Datei geschrieben.
-Anhand des Parameters --models wird definiert, welche Daten exportiert -werden. Alternativ kann auch der Parameter --topics, --baskets oder --dataset -verwendet werden, um die zu exportierenden Daten auszuwÀhlen. Einer -dieser Parameter muss also zwingend beim Export angegeben werden.
-Die Daten in der Datenbank werden anhand des Interlis-Modells geprĂŒft (--validate):
-PostGIS: java -jar ili2pg.jar --validate --models DM01AV --dbhost -ofaioi4531 --dbport 5432 --dbdatabase mogis --dbusr julia --dbpwd romeo
-GeoPackage: java -jar ili2gpkg.jar --validate --models DM01AV --dbfile -mogis.gpkg
-FileGDB: java -jar ili2fgdb.jar --validate --models DM01AV --dbfile -mogis.gdb
-Anhand des Parameters --models wird definiert, welche Daten geprĂŒft -werden. Alternativ kann auch der Parameter --topics, --baskets oder --dataset -verwendet werden, um die zu prĂŒfenden Daten auszuwĂ€hlen. Einer -dieser Parameter muss also zwingend beim PrĂŒfen angegeben werden.
-Die von ili2b 4.x benutzten Schemaabbildungsregeln sind zum Teil nicht -kompatibel mit den Regeln von ili2db 3.x. -Das einfachste fĂŒr die Datenmigration ist darum:
-Ab ili2db 4.1 gibt es eine Option --export3 um Daten aus einer mit 3.x angelegten -DB zu exportieren.
-Die wichtigsten Optionen, um zu 3.x kompatibles Verhalten zu erhalten sind:
-Die Tabellen existieren nicht und sollen in der Datenbank angelegt -werden und die Daten sollen importiert werden (--import):
-PostGIS: java -jar ili2pg.jar --import --doSchemaImport --dbhost ofaioi4531 --dbport -5432 --dbdatabase mogis --dbusr julia --dbpwd romeo ---createEnumTabs --createBasketCol --log path/to/logfile path/to/260100.itf
-GeoPackage: java -jar ili2gpkg.jar --import --doSchemaImport --dbfile mogis.gpkg ---createEnumTabs --createBasketCol --log path/to/logfile path/to/260100.itf
-FileGDB: java -jar ili2fgdb.jar --import --doSchemaImport --dbfile mogis.gdb ---createEnumTabs --createBasketCol --log path/to/logfile path/to/260100.itf
-Alle Tabellen werden in der Datenbank erstellt (--doSchemaImport) und das Itf 260100.itf -importiert. Die Geometrie-Spalten werden registriert. Als Primary-Key -wird ein zusĂ€tzliches Attribut erstellt (t_id). ZusĂ€tzlich wir ein -t_basket Attribut erstellt (--createBasketCol). Dieses zeigt als FremdschlĂŒssel auf eine -Meta-Hilfstabelle (Importdatum, Benutzer, Modellname, Pfad der -Itf-Datei).
-Die AufzÀhltypen werden in Lookup-Tables abgebildet (--createEnumTabs).
-Es wird ein Logfile angelegt (--log path/to/logfile). Dieses enthÀlt Zeitpunkt des Imports, Name -des Benutzers, Datenbankparameter (ohne Passwort), Name (ganzer Pfade) -der Ili- und Itf-Datei, sÀmtliche Namen der importierten Tabellen inkl. -Anzahl der importierten Elemente pro Tabelle. AllfÀllige Fehlermeldungen -(bei Importabbruch) werden auch in die Logdatei geschrieben.
-In den folgenden Abschnitten werden einzelne Aspekte detailliert, aber -isoliert, beschrieben. Die Funktionsweise als Ganzes wird anhand -einzelner AnwendungsfĂ€lle beispielhaft im Kapitel âFunktionsweiseâ -(weiter oben) beschrieben.
-Die Dokumentation gilt grundsĂ€tzlich fĂŒr alle ili2xy Varianten, ausser es -gibt einen spezifischen Hinweis auf PostGIS, GeoPackage oder FileGDB.
-PostGIS: java -jar ili2pg.jar [Options] [file]
-GeoPackage: java -jar ili2gpkg.jar [Options] [file]
-FileGDB: java -jar ili2fgdb.jar [Options] [file]
-Der RĂŒckgabewert ist wie folgt:
----
-- 0 import/export ok, keine Fehler festgestellt
-- !0 import/export nicht ok, Fehler festgestellt
-
Optionen:
-| Option | -Beschreibung | -|||
|---|---|---|---|---|
| --import | -Importiert Daten aus einer Transferdatei in die Datenbank. -Die Tabellen werden implizit auch angelegt, falls sie noch nicht vorhanden sind (siehe Kapitel Abbildungsregeln). Falls die Tabellen in der Datenbank schon vorhanden sind, können sie zusÀtzliche Spalten enthalten (z.B. bfsnr, datum etc.), welche beim Import leer bleiben. -Falls beim Import ein Datensatz-Identifikator (--dataset) definiert wird, darf dieser Datensatz-Identifikator in der Datenbank noch nicht vorhanden sein. Um die bestehenden Daten zu ersetzen, kann die Option --replace verwendet werden. -TODO Die Tabellen sind schon vorhanden (und entsprechen (nicht) der ili-Klasse) - |
-|||
| --update | -Aktualisiert die Daten in der Datenbank anhand einer Transferdatei, d.h. neue Objekte werden eingefĂŒgt, bestehende Objekte werden aktualisiert und in der Transferdatei nicht mehr vorhandene Objekte werden gelöscht. Diese Funktion bedingt, dass das Datenbankschema mit der Option --createBasketCol erstellt wurde, und dass die Klassen und Topics eine stabile OID haben. | -|||
| --replace | -Ersetzt die Daten in der Datenbank anhand eines Datensatz-Identifikators (--dataset) mit den Daten aus einer Transferdatei. Diese Funktion bedingt, dass das Datenbankschema mit der Option --createBasketCol erstellt wurde. | -|||
| --delete | -Löscht die Daten in der Datenbank anhand eines Datensatz-Identifikators (--dataset). Diese Funktion bedingt, dass das Datenbankschema mit der Option --createBasketCol erstellt wurde. | -|||
| --export | -Exportiert Daten aus der Datenbank in eine Transferdatei. -Mit dem Parameter --models, --topics, --baskets oder --dataset wird definiert, welche Daten exportiert werden. -Existieren zum gegeben Modell (--models) oder Topic (--topics) in der DB keine Daten, wird ohne Fehlermeldung eine leere Transferdatei erstellt. -Wird eine Datensatz (--dataset) oder Basket (--baskets) bezeichnet, der in der DB nicht vorhanden ist, bricht der Export mit einem Fehler ab. -Ob die Daten im Interlis 1-, Interlis 2- oder GML-Format geschrieben werden, ergibt sich aus der Dateinamenserweiterung der Ausgabedatei. FĂŒr eine Interlis 1-Transferdatei muss die Erweiterung .itf verwendet werden. FĂŒr eine GML-Transferdatei muss die Erweiterung .gml verwendet werden. -Die Optionen --topics und --baskets bedingen, dass das Datenbankschema mit der Option --createBasketCol erstellt wurde. - |
-|||
| --export3 | -Exportiert Daten aus einer Datenbank die mit ili2db 3.x angelegt wurde in eine Transferdatei. | -|||
| --validate | -PrĂŒft die Daten in der Datenbank (ohne Export in eine Transferdatei). -Mit dem Parameter --models, --topics, --baskets oder --dataset wird definiert, welche Daten geprĂŒft werden. -Die Optionen --topics und --baskets bedingen, dass das Datenbankschema mit der Option --createBasketCol erstellt wurde. - |
-|||
| --schemaimport | -Erstellt die Tabellenstruktur in der Datenbank (siehe Kapitel Abbildungsregeln). | -|||
| --iliMetaAttrs filename | -Name der Konfigurationsdatei, die zusÀtzliche Interlis-Metaattribute enthÀlt (Meta-Attribute, die in den ili-Dateien nicht enthalten sind). -Die Konfigurationsdatei ist Zeilenorientiert und besteht aus Abschnitten. Pro Modellelement gibt es einen Abschnitt. Der Abschnitt beginnt mit dem qualifizierten Elementnamen in eckigen Klammern. Innerhalb des Abschnitts sind die Metaattribute zu diesem Modellelement. Beispiel: --[Model1.Topic1.Structure1] -MetaAttr1=AttrValue1 -MetaAttr2=AttrValue2 -[Model1.Topic1.ClassA.AttrB] -MetaAttrN=AttrValueN -- |
-|||
| --validConfig filename | -Name der Konfigurationsdatei, die fĂŒr die Validierung verwendet werden soll. | -|||
| --disableValidation | -Schaltet die Validierung der Daten aus. | -|||
| --disableAreaValidation | -Schaltet die Validierung der AREA Topologie aus. | -|||
| --forceTypeValidation | -BeschrÀnkt die Aufweichung der Validierung mittels --validConfig auf "multiplicity". | -|||
| --dbhost host | -PostGIS: Der hostname der Datenbank. Default ist localhost. | -|||
| --dbport port | -PostGIS: Die Port-Nummer, unter der die Datenbank angesprochen warden kann. Default ist 5432. | -|||
| --dbdatabase database | -PostGIS: Der Name der Datenbank. | -|||
| --dbusr username | -PostGIS: Der Benutzername fĂŒr den Datenbankzugang und EintrĂ€ge in Metatabellen. -GeoPackage: Der Benutzername fĂŒr EintrĂ€ge in Metatabellen. - |
-|||
| --dbpwd password | -PostGIS: Das Passwort fĂŒr den Datenbankzugriff. | -|||
| --dbparams filename | -Datei (UTF-8 codiert) mit zusĂ€tzlichen Parametern fĂŒr den Datenbankzugriff. Einfaches zeilenorientiertes Format mit Parameter=Wert pro Zeile. Die möglichen Parameter sind beim jeweiligen JDBC Treiber beschrieben. | -|||
| --dbschema schema | -PostGIS: Definiert den Namen des Datenbank-Schemas. Default ist kein Wert, d.h. das aktuelle Schema des Benutzers der mit âuser definiert wird. | -|||
| --dbfile filename | -GeoPackage: Name der GeoPackage-Datei. -FileGDB: Name der ESRI File Geodatabase-Datei. - |
-|||
| --setupPgExt | -PostGIS: erstellt postgreql Erweiterungen 'uuid-ossp' und 'postgis' (falls noch nicht vorhanden) | -|||
| --disableRounding | -Beim Import und Export werden die Daten per Default gerundet gem. Angaben im Modell. Mit dieser Option findet keine Rundung statt. | -|||
| --deleteData | -bei einem Datenimport (--import) werden alle Daten in den existierenden/benutzten Tabellen gelöscht (Mit DELETE, die Tabellenstruktur bleibt unverÀndert). | -|||
| --defaultSrsAuth auth | -SRS Authority fĂŒr Geometriespalten, wo sich dieser Wert nicht ermitteln lĂ€sst (fĂŒr ili1 und ili2.3 immer der Fall). Gross-/Kleinschreibung ist signifikant. Default ist EPSG | -|||
| --defaultSrsCode code | -SRS Code fĂŒr Geometriespalten, wo sich dieser Wert nicht ermitteln lĂ€sst. Kein Default | -|||
| --modelSrsCode model=epsgCode | -SRS Code fĂŒr Geometriespalten des gegebenen Modells, wo sich dieser Wert nicht pro Attribut ermitteln lĂ€sst. Mehrere Definitionen können durch Strichpunkt getrennt wrden, z.B.: --modelSrsCode ModelA=2056;ModelB=21781 | -|||
| --fgdbXyResolution value | -FileGDB: XY-Auflösung fĂŒr Geometriespalten | -|||
| --fgdbXyTolerance value | -FileGDB: XY-Toleranz fĂŒr Geometriespalten | -|||
| --modeldir path | -Dateipfade, die Modell-Dateien (ili-Dateien) enthalten. Mehrere Pfade können durch Semikolon â;â getrennt werden. Es sind auch URLs von Modell-Repositories möglich. Default ist -%ILI_FROM_DB;%XTF_DIR;http://models.interlis.ch/;%JAR_DIR -Es werden folgende Platzhalter unterstĂŒtzt: -%ILI_FROM_DB ist ein Platzhalter fĂŒr die in der Datenbank vorhandenen Modelle (in der Tabelle t_ili2db_model). -%XTF_DIR ist ein Platzhalter fĂŒr das Verzeichnis mit der Transferdatei. -%JAR_DIR ist ein Platzhalter fĂŒr das Verzeichnis des ili2db Programms (ili2pg.jar bzw. ili2gpkg.jar Datei). -%ILI_FROM_DB sollte i.d.R. der erste Pfad sein (damit mehrere Imports und Exports das selbe Modell verwenden). -Der erste Modellname (Hauptmodell), zu dem ili2db die ili-Datei sucht, ist nicht von der INTERLIS-Sprachversion abhĂ€ngig. Es wird in folgender Reihenfolge nach einer ili-Datei gesucht: zuerst INTERLIS 2.3, dann 1.0 und zuletzt 2.2. -Beim Auflösen eines IMPORTs wird die INTERLIS Sprachversion des Hauptmodells berĂŒcksichtigt, so dass also z.B. das Modell Units fĂŒr ili2.2 oder ili2.3 unterschieden wird. - |
-|||
| --models modelname | -Namen des Modells (nicht zwingend identisch mit dem Dateinamen!), fĂŒr das die Tabellenstruktur in der Datenbank erstellt werden soll. Mehrere Modellnamen können durch Semikolon â;â getrennt werden. Normalerweise muss der Namen nicht angegeben werden, und das Programm ermittelt den Wert automatisch aus den Daten. Wird beim --schemaimport nur eine ili-Datei als file angegeben, wird der Name des letzten Modells aus dieser ili-Datei als modelname genommen. | -|||
| --dataset name | -Name/Identifikator des Datensatzes (Kurzform fĂŒr mehrere BIDs). Kann z.B. eine BFSNr oder ein KantonskĂŒrzel sein. Beim Daten Export können mehrere Datensatznamen durch Semikolon â;â getrennt werden. Bedingt die Option --createBasketCol. | -|||
| --baskets BID | -BID der Baskets, die importiert, exportiert oder validiert werden sollen. Mehrere BIDs können durch Semikolon â;â getrennt werden. | -|||
| --topics topicname | -Topic-Namen der Baskets, die importiert, exportiert oder validiert werden sollen. Mehrere Namen können durch Semikolon â;â getrennt werden. Es muss der qualifizierte Topic-Name (Model.Topic) verwendet werden. | -|||
| --createscript filename | -Erstellt zusÀtzlich zur Tabellenstruktur in der Datenbank ein SQL-Skript um die Tabellenstruktur unabhÀngig vom Programm erstellen zu können. Das Skript wird zusÀtzlich zu den Tabellen in der Datenbank erzeugt, d.h. es ist nicht möglich, nur das Skript zu erstellen (ohne Datenbank). | -|||
| --dropscript filename | -Erstellt ein SQL-Skript um die Tabellenstruktur unabhÀngig vom Programm löschen zu können. | -|||
| --preScript filename | -SQL-Skript, das vor dem (Schema-)Import/Export ausgefĂŒhrt wird. | -|||
| --postScript filename | -SQL-Skript, das nach dem (Schema-)Import/Export ausgefĂŒhrt wird. | -|||
| --noSmartMapping | -Alle strukturellen Abbildungsoptimierungen werden ausgeschaltet. (s.a. --smart1Inheritance, --coalesceCatalogueRef, --coalesceMultiSurface, --coalesceMultiLine, --coalesceMultiPoint, --expandMultilingual, --expandLocalised, --coalesceArray) | -|||
| --smart1Inheritance | -Bildet die Vererbungshierarchie mit einer dymamischen Strategie ab. FĂŒr Klassen, die referenziert werden und deren Basisklassen nicht mit einer NewClass-Strategie abgebildet werden, wird die NewClass-Strategie verwendet. Abstrakte Klassen werden mit einer SubClass-Strategie abgebildet. Konkrete Klassen, ohne Basisklasse oder deren direkte Basisklassen mit einer SubClass-Strategie abgebildet werden, werden mit einer NewClass-Strategie abgebildet. Alle anderen Klassen werden mit einer SuperClass-Strategie abgebildet. | -|||
| --smart2Inheritance | -Bildet die Vererbungshierarchie mit einer dymamischen Strategie ab. Abstrakte Klassen werden mit einer SubClass-Strategie abgebildet. Konkrete Klassen werden mit einer NewAndSubClass-Strategie abgebildet. | -|||
| --coalesceCatalogueRef | -Strukturattribute deren maximale KardinalitĂ€t 1 ist, deren Basistyp CHBase:CatalogueReference oder CHBase:MandatoryCatalogueReference ist und die ausser âReferenceâ keine weiteren Attribute haben, werden direkt mit einem FremdschlĂŒssel auf die Ziel-Tabelle (die die konkrete CHBase:Item Klasse realisiert) abgebildet, d.h. kein Record in der Tabelle fĂŒr die Struktur mit dem âReferenceâ Attribut. | -|||
| --coalesceMultiSurface | -Strukturattribute deren maximale KardinalitĂ€t 1 ist, deren Basistyp CHBase:MultiSurface ist und die ausser âSurfacesâ keine weiteren Attribute haben, werden direkt als Spalte mit dem Typ MULTISURFACE (oder MULTIPOLYGON, falls --strokeArcs) abgebildet. | -|||
| --coalesceMultiLine | -Strukturattribute deren maximale KardinalitĂ€t 1 ist, deren Basistyp CHBase:MultiLine ist und die ausser âLinesâ keine weiteren Attribute haben, werden direkt als Spalte mit dem Typ MULTICURVE (oder MULTILINESTRING, falls --strokeArcs) abgebildet. | -|||
| --coalesceMultiPoint | -Strukturattribute deren maximale KardinalitÀt 1 ist, die nur ein Attribut haben, werden direkt als Spalte mit dem Typ MULTIPOINT abgebildet. | -|||
| --coalesceArray | -Strukturattribute mit dem Metaattribut ili2db.mapping=ARRAY, die nur ein Attribut haben, werden direkt als Spalte mit dem Typ ARRAY abgebildet. | -|||
| --coalesceJson | -Strukturattribute mit dem Metaattribut ili2db.mapping=JSON, werden direkt als Spalte mit dem Typ JSON abgebildet. | -|||
| --expandMultilingual | -Strukturattribute deren maximale KardinalitĂ€t 1 ist, deren Basistyp LocalisationCH_V1.MultilingualText oder LocalisationCH_V1.MultilingualMText ist (oder das Metaattribut ili2db.mapping=Multilingual haben) und die ausser âLocalisedTextâ keine weiteren Attribute haben, werden direkt als Spalten in der Tabelle des Strukturattributes abgebildet, d.h. keine Records in den Tabellen fĂŒr die Multilingual-Strukturen. | -|||
| --expandLocalised | -Strukturattribute deren maximale KardinalitĂ€t 1 ist, deren Basistyp LocalisationCH_V1.LocalisedText oder LocalisationCH_V1.LocalisedMText (oder das Metaattribut ili2db.mapping=Localised haben) ist und die ausser âLanguageâ und âTextâ keine weiteren Attribute haben, werden direkt als Spalten in der Tabelle des Strukturattributes abgebildet, d.h. keine Records in den Tabellen fĂŒr die Multilingual-Strukturen. | -|||
| --createGeomIdx | -Erstellt fĂŒr jede Geometriespalte in der Datenbank einen rĂ€umlichen Index. (siehe Kapitel Abbildungsregeln/Geometrieattribute) | -|||
| --createEnumColAsItfCode | -Bildet bei AufzÀhlungsattributen den AufzÀhlungswert als ITF-Code ab. Diese Option ist nur zulÀssig, wenn im Modell keine Erweiterungen von AufzÀhlungen vorkommen. Ohne diese Option wird der XTF-Code als AufzÀhlwert in der Datenbank verwendet. (siehe Kapitel Abbildungsregeln/AufzÀhlungen) | -|||
| --createEnumTxtCol | -Erstellt fĂŒr AufzĂ€hlungsattribute eine zusĂ€tzliche Spalte mit dem Namen des AufzĂ€hlwertes. (siehe Kapitel Abbildungsregeln/AufzĂ€hlungen) | -|||
| --createEnumTabs | -Erstellt pro AufzÀhlungsdefinition eine Tabelle mit den einzelnen AufzÀhlwerten. (siehe Kapitel Abbildungsregeln/AufzÀhlungen) | -|||
| --createSingleEnumTab | -Erstellt eine einzige Tabelle mit allen AufzÀhlwerten aller AufzÀhlungsdefinitionen. (siehe Kapitel Abbildungsregeln/AufzÀhlungen) | -|||
| --createEnumTabsWithId | -Erstellt pro Basis-AufzĂ€hlungsdefinition eine Tabelle mit den einzelnen AufzĂ€hlwerten, inkl. aller AufzĂ€hlungserweiterungen von dieser Basisdefinition. -So können auch FremdschlĂŒssel (--createFk) definiert werden. (siehe Kapitel Abbildungsregeln/AufzĂ€hlungen) | -|||
| --createMetaInfo | -Erstellt zusÀtzliche Meta-Tabellen T_ILI2DB_TABLE_PROP, T_ILI2DB_COLUMN_PROP, T_ILI2DB_META_ATTRS mit weiteren Angaben aus dem Interlis Modell. (siehe Kapitel Metadaten) | -|||
| --beautifyEnumDispName | -Verschönert den Anzeigetext fĂŒr das AufzĂ€hlelement. Beim Import wird die Spalte mit dem XTF-Code ohne Untersstriche befĂŒllt ("Strasse befestigt" statt "Strasse_befestigt") (siehe Kapitel Abbildungsregeln/AufzĂ€hlungen) | -|||
| --createStdCols | -Erstellt in jeder Tabelle zusÀtzliche Metadatenspalten T_User, T_CreateDate, T_LastChange. (siehe Kapitel Abbildungsregeln/Tabellen) | -|||
| --t_id_Name name | -Definiert den Namen fĂŒr die interne technische SchlĂŒsselspalte in jeder Tabelle (nicht zu verwechseln mit dem externen Transferidentifikator). Default ist T_Id. (siehe Kapitel Abbildungsregeln/Tabellen) | -|||
| --idSeqMin zahl | -PostGIS: Definiert den Minimalwert fĂŒr den Generator der internen technischen SchlĂŒssel | -|||
| --idSeqMax zahl | -PostGIS: Definiert den Maximalwert fĂŒr den Generator der internen technischen SchlĂŒssel | -|||
| --createTypeDiscriminator | -Erstellt fĂŒr jede Tabelle (auch wenn das Modell keine Vererbung benutzt) eine Spalte fĂŒr den Typdiskriminator. FĂŒr Klassen mit Vererbung wird die Spalte immer erstellt. (siehe Kapitel Abbildungsregeln/Tabellen) | -|||
| --structWithGenericRef | -Erstellt generische Spalten fĂŒr den FremdschlĂŒssel bei Tabellen die Interlis-Strukturen abbilden. Ohne diese Option wird pro Strukturattribut eine Spalte erstellt (in der Tabelle, die die Struktur abbildet). (siehe Kapitel Abbildungsregeln/Strukturen) | -|||
| --disableNameOptimization | -Schaltet die Nutzung von unqualifizierten Klassennamen aus. FĂŒr alle Tabellennamen werden qualifizierte Interlis-Klassennamen (Model.Topic.Class) verwendet (und in einen gĂŒltigen Tabellennamen abgebildet). (siehe Kapitel Abbildungsregeln/Namenskonventionen) | -|||
| --nameByTopic | -FĂŒr alle Tabellennamen werden teilweise qualifizierte Interlis-Klassennamen (Topic.Class) verwendet (und in einen gĂŒltigen Tabellennamen abgebildet). (siehe Kapitel Abbildungsregeln/Namenskonventionen) | -|||
| --nameLang lang | -FĂŒr alle Tabellen- und Spaltennamen werden Namen aus dem Interlis-Modell der gegebenen Sprache verwendet. Die möglichen Sprachnamen ergeben sich aus den Interlis-Modellen (MODEL Name (lang) ...). -Mehrere Sprachen können durch Semikolon getrennt werden, um die PrioritĂ€t zu regeln. Ist fĂŒr einen Namen kein Modell in einer der gegebenen Sprache vorhanden, wird der Namen aus dem Modell in der Ursprungssprache verwendet. | -|||
| --maxNameLength length | -Definiert die maximale LĂ€nge der Namen fĂŒr Datenbankelemente (Tabellennamen, Spaltennamen , usw.) Default ist 60. Ist der Interlis-Name lĂ€nger, wird er gekĂŒrzt. (siehe Kapitel Abbildungsregeln/Namenskonventionen) | -|||
| --sqlEnableNull | -Erstellt keine NOT NULL Anweisungen bei Spalten die Interlis-Attribute abbilden. (siehe Kapitel Abbildungsregeln/Attribute) | -|||
| --sqlExtRefCols | -Erstellt Spalten die Interlis-Rollen oder Interlis-Referenz-Attribute abbilden als Textspalten, so dass der Referenzwert aus der Transferdatei in der Spalte aufgenommen werden kann und die referenzierten Objekte nicht vorliegen mĂŒssen. (siehe Kapitel Abbildungsregeln/Beziehungen) | -|||
| --strokeArcs | -Segmentiert Kreisbogen beim Datenimport. Der Radius geht somit verloren. Die Kreisbogen werden so segmentiert, dass die Abweichung der erzeugten Geraden kleiner als die Koordinatengenauigkeit der StĂŒtzpunkte ist. | -|||
| --oneGeomPerTable | -PostGIS: Erzeugt Hilfstabellen, falls in einer Klasse/Tabelle mehr als ein Geometrie-Attribut ist, so dass pro Tabelle in der Datenbank nur eine Geometriespalte ist. | -|||
| --skipPolygonBuilding | -Bei ITF-Dateien werden die Linientabellen gelesen, so wie sie in der ITF-Datei sind, d.h. es werden keine Polygon gebildet. | -|||
| --skipGeometryErrors | -Geometry Fehler werden ignoriert (und nicht rapportiert). Spezifischere Fehlermeldungen mĂŒssen mittels --validConfig konfiguriert werden. | -|||
| --skipReferenceErrors | -Referenzfehler (z.B. Verweise auf nicht vorhandene Objekte) werden ignoriert (und nicht rapportiert). Die Option bedingt, dass der Schema Import mit --sqlEnableNull erfolgte, damit die fehlenden Referenzen beim Insert auf der DB nicht zu einem NULL Constraint Fehler fĂŒhren. | -|||
| --keepAreaRef | -Bei ITF-Dateien wird fĂŒr AREA Attribute der Gebietsreferenzpunkt als zusĂ€tzliche Spalte in der Tabelle eingefĂŒgt. | -|||
| --createTidCol | -Erstellt in jeder Tabelle eine zusÀtzlich Spalte T_Ili_Tid. (siehe Kapitel Abbildungsregeln/Tabellen) | -|||
| --importTid | -Liest die Transferidentifikation (TID aus der Transferdatei) in eine zusÀtzliche Spalte T_Ili_Tid. (siehe Kapitel Abbildungsregeln/Tabellen). Bedingt beim Schema Import die Option --createTidCol. | -|||
| --exportTid | -Verwendet den Wert der Spalte T_Ili_Tid als Transferidentifikation (TID in der Transferdatei). (siehe Kapitel Abbildungsregeln/Tabellen). Bedingt beim Schema Import die Option --createTidCol. | -|||
| --importBid | -Liest die BehÀlteridentifikation (BID aus der Transferdatei) in die Spalte T_Ili_Tid der Tabelle t_ili2db_basket. | -|||
| --importFetchSize | -Definiert den fetchsize fĂŒr die Statements beim import. | -|||
| --exportBatchSize | -Definiert den batchSize fĂŒr die Statements beim export. | -|||
| --createBasketCol | -Erstellt in jeder Tabelle eine zusÀtzlich Spalte T_basket um den BehÀlter identifizieren zu können. (siehe Kapitel Abbildungsregeln/Metadaten) | -|||
| --createDatasetCol | -Erstellt in jeder Tabelle eine zusÀtzlich Spalte T_datasetname mit dem Namen/Identifikator des Datensatzes. Die Option bedingt die Option --dataset. Die Spalte ist redundant zur Spalte datasetname der Tabelle t_ili2db_dataset (siehe Kapitel Abbildungsregeln/Metadaten). | -|||
| --createFk | -Erzeugt eine FremdschlĂŒsselbedingung bei Spalten die Records in anderen Tabellen referenzieren. | -|||
| --createFkIdx | -Erstellt fĂŒr jede FremdschlĂŒsselpalte in der Datenbank einen Index. Kann auch ohne die Option --createFk benutzt werden. | -|||
| --createUnique | -Erstellt fĂŒr INTERLIS-UNIQUE-Constraints in der Datenbank UNIQUE Bedingungen (sofern abbildbar). | -|||
| --createNumChecks | -Erstellt fĂŒr numerische Datentypen CHECK-Constraints in der Datenbank. | -|||
| --createTextChecks | -Erstellt fĂŒr Text Datentypen CHECK-Constraints in der Datenbank. (nicht nur Leerzeichen; bei TEXT keine ZeilenumbrĂŒche) | -|||
| --createDateTimeChecks | -Erstellt fĂŒr Datum und Zeit Datentypen CHECK-Constraints in der Datenbank. | -|||
| --createTypeConstraints | -Erstellt fĂŒr die t_type Spalte ein CHECK-Constraint in der Datenbank. | -|||
| --sqlColsAsText | -Bildet alle (einfachen/unstrukturierten) Interlis-Attribute als TEXT-Spalten ab, so dass fehlerhafte Daten importiert werden können. | -|||
| --createImportTabs | -Erstellt die t_ili2db_import Tabellen in der Datenbank. | -|||
| --doSchemaImport | -Beim Datenimport werden die Tabellen angelegt, d.h. es muss nicht zuerst ein --schemaimport gemacht werden. | -|||
| --ver4-noSchemaImport | -Nicht mehr verwenden, wird entfernt. Beim Datenimport wird keine Tabellen angelegt, d.h. es muss zuerst explizit ein --schemaimport gemacht werden. | -|||
| --ver3-translation | -Verwendet ili2db 3.x Abbildungsregeln fĂŒr ĂŒbersetzte Modelle (Inkompatibel mit ili2db 4.x Abbildungen). | -|||
| --ver4-translation | -Nicht mehr verwenden, wird entfernt. Verwendet ili2db 4.x Abbildungsregeln fĂŒr ĂŒbersetzte Modelle (Inkompatibel mit ili2db 3.x Abbildungen). | -|||
| --translation modelT=modelU | -Definiert bei ĂŒbersetzten INTERLIS 1 Modellen (modelT), das Modell der Ursprungssprache (ModelU). Mehrere Ăbersetzungen können durch Strichpunkt getrennt wrden, z.B.: --translation modelT1=modelU;modelT2=modelU | -|||
| --exportModels modelname | -Beim Export/PrĂŒfen werden die Daten gem. dem gegebenen Export-Modell exportiert/geprĂŒft. Ohne die Option --exportModels werden die Daten so wie sie erfasst sind (bzw. importiert wurden), exportiert/validiert. Mehrere Modellnamen können durch Semikolon â;â getrennt werden. Als Export-Modelle sind Basis-Modelle (also z.B. Bundes-Modell statt Kantons-Modell) oder ĂŒbersetzte Modelle (also z.B. DM_IT statt DM_DE) zulĂ€ssig. | -|||
| --exportCrsModels modelname | -Beim Export/PrĂŒfen werden die Daten gem. dem gegebenen Modell, das ein alternatives CRS zum Original Modell hat, exportiert/geprĂŒft. Ohne die Option --exportCrsModels werden die Daten so wie sie erfasst sind, exportiert/validiert. | -|||
| --ILIGML20 | -Verwendet beim Export eCH-0118-2.0 als Transferformat. | -|||
| --log filename | -Schreibt die log-Meldungen in eine Datei. | -|||
| --xtflog result.xtf | Schreibt die log-Meldungen in eine INTERLIS 2-Datei. Die Datei result.xtf entspricht dem Modell IliVErrors. | -||||
|
-||||
| --proxyPort port | -Port auf dem Proxy. | -|||
| --gui | -Startet ein einfaches GUI. | -|||
| --trace | -Erzeugt zusĂ€tzliche Log-Meldungen (wichtig fĂŒr Programm-Fehleranalysen) | -|||
| --help | -Zeigt einen kurzen Hilfetext an. | -|||
| --version | -Zeigt die Version des Programmes an. | -|||
Alle explizit genannten Modelle (mit --models) werden vollstÀndig importiert. -Direkt oder indirekt importierte Modelle (via IMPORTS) werden nicht importiert, -ausser denjenigen Klassen die direkt oder indirekt via Assoziationen oder -Referenzattribute referenziert werden.
-Wird via --models kein Modell explizit bezeichnet, wird das letzte Modell der -ili-Datei importiert.
-Wird das Schema als Teil des Daten-Imports (--doSchemaImport ) -angelegt (ohne --models), werden die Modelle gemÀss dem Element MODELS aus der Transferdatei angelegt.
-Je nach Programmoption, werden Klassen unterschiedlich abgebildet. Die -Abbildungsregeln fĂŒr den Tabellennamen sind im Abschnitt -Namenskonventionen beschrieben.
-| Nummer | -Beispiel INTERLIS | -Beispiel SQL | -Kommentare | -
|---|---|---|---|
| 1 | --CLASS A= -END A; -- |
--CREATE TABLE A ( - T_Id integer PRIMARY KEY -); -- |
-FĂŒr jede Klasse wird eine Tabelle erstellt. -Jede Tabelle hat mindestens eine Spalte T_Id. Diese Spalte ist der Datenbank interne PrimĂ€rschlĂŒssel (und nicht die TID aus der Transferdatei). - |
-
| 2 | --CLASS A = -END A; -- |
--CREATE TABLE A ( - T_Id integer PRIMARY KEY, - T_Type varchar(60) NOT NULL -); -- |
-Mit der Option --createTypeDiscriminator erhĂ€lt jede Tabelle (die eine Klasse oder Struktur reprĂ€sentiert, die keine Basisklasse hat) eine zusĂ€tzliche Spalte T_Type. Diese Spalte enthĂ€lt den konkreten Klassenname (der SQL-Name des qualifizierten INTERLIS-Klassennamens [2]) des Objektes jedes einzelnen Records. -Tabellen fĂŒr Klassen die eine Basisklasse haben, erhalten diese Spalte nicht. - |
-
| 3 | --CLASS A = -END A; -- |
--CREATE TABLE A ( - T_Id integer PRIMARY KEY, - T_LastChange timestamp NOT NULL, - T_CreateDate timestamp NOT NULL, - T_User varchar(40) NOT NULL -); -- |
-Mit der Option --createStdCols erhalten alle Tabellen drei zusĂ€tzliche Spalten fĂŒr den Zeitpunkt der letzten Ănderung, den Zeitpunkt der Erstellung und den Benutzer, der die letzte Ănderung durchgefĂŒhrt hat. Diese Spalten mĂŒssen durch die Applikation nachgefĂŒhrt werden, und werden typischerweise fĂŒr die Implementierung eines optimistischen Lockings benötigt/benutzt. | -
| 4 | --CLASS A = -END A; -- |
--CREATE TABLE A ( - T_Id integer PRIMARY KEY, - T_Ili_Tid varchar(200) NULL -); -- |
-Mit der Option --createTidCol erhĂ€lt jede Tabelle (die eine Klasse reprĂ€sentiert, die keine Basisklasse hat) eine zusĂ€tzliche Spalte T_Ili_Tid. Diese Spalte enthĂ€lt die TID aus der Transferdatei. -Diese Spalte ist NICHT der Datenbank interne PrimĂ€rschlĂŒssel. - |
-
| 5 | --!!@ili2db.oid=MyOID -CLASS A = -END A; -- |
--CREATE TABLE A ( - T_Id integer PRIMARY KEY, - T_Ili_Tid varchar(200) NULL -); -- |
-Mit dem Metaattribut ili2db.oid erhĂ€lt die Tabelle (die eine Klasse reprĂ€sentiert, die keine Basisklasse hat) eine zusĂ€tzliche Spalte T_Ili_Tid, wie wenn die Klasse eine OID hĂ€tte. Diese Spalte enthĂ€lt die TID aus der Transferdatei. -MyOID muss eine im Modell vorhandene OID-Domain Definition sein (z.b. INTERLIS.UUIDOID). Das Metaattribut steht typischerweise in einer externen Datei, die beim Schemaimport mit --iliMetaAttrs mitgegeben wird. -Diese Spalte ist NICHT der Datenbank interne PrimĂ€rschlĂŒssel. - |
-
| 6 | --CLASS A = -END A; -- |
--CREATE TABLE A ( - oidname integer PRIMARY KEY -); -- |
-Mit der Option --t_id_Name oidname wird der Namen der Spalte fĂŒr den Datenbank internen PrimĂ€rschlĂŒssel (nicht die Spalte fĂŒr die TID aus der Transferdatei) festgelegt. | -
| 7 | --STRUCTURE C = -END C; -- |
--CREATE TABLE C ( - T_Id integer PRIMARY KEY, - T_seq integer NOT NULL -); -- |
-Strukturen werden im Allgemeinen abgebildet wie Klassen. -Die Strukturtabelle enthÀlt zusÀtzlich eine Spalte T_seq, die die Reihenfolge der Strukturelement festlegt. -Da Strukturelemente keine TID haben, erhalten sie auch mit der Option --createTidCol kein Spalte T_Ili_Tid. - |
-
| 8 | --CLASS A = -END A; -- |
--CREATE TABLE A ( - T_Id integer PRIMARY KEY, - T_basket integer NOT NULL -); -- |
-Mit der Option --createBasketCol erhĂ€lt jede Tabelle eine zusĂ€tzliche Spalte T_basket. Diese Spalte enthĂ€lt den FremschlĂŒssel auf die Tabelle t_ili2db_basket. | -
| 9 | --CLASS A = -END A; -- |
--CREATE TABLE A ( - T_Id integer PRIMARY KEY, - T_datasetname varchar(200) - NOT NULL -); -- |
-Mit der Option --createDatasetCol erhÀlt jede Tabelle eine zusÀtzliche Spalte T_datasetname. -Die Spalte ist redunant zur Spalte datasetname der Tabelle t_ili2db_dataset (siehe Kapitel Abbildungsregeln/Metadaten) - |
-
Im allgemeinen lÀsst sich Vererbung nach drei unterschidlichen -Strategien abbilden:
-ili2db bildet die Vererbung nach einer je nach Klasse unterschiedlichen -Strategie (--smart1Inheritance oder --smart2Inheritance) oder fĂŒr alle -Klassen einheitlich nach der NewClass-Strategie (--noSmartMapping) ab.
-Bei --smart1Inheritance wird wie folgt abgebildet: Fuer Klassen, die -referenziert werden und deren Basisklassen nicht mit einer -NewClass-Strategie abgebildet werden, wird die NewClass-Strategie -verwendet. Abstrakte Klassen werden mit einer SubClass-Strategie -abgebildet. Konkrete Klassen, ohne Basisklasse oder deren direkte -Basisklassen mit einer SubClass-Strategie abgebildet werden, werden mit -einer NewClass-Strategie abgebildet. Alle anderen Klassen werden mit -einer SuperClass-Strategie abgebildet.
-Bei --smart2Inheritance wird wie folgt abgebildet: Abstrakte Klassen werden -mit einer SubClass-Strategie abgebildet. -Konkrete Klassen werden mit einer NewAndSubClass-Strategie abgebildet.
-| Nummer | -Beispiel INTERLIS | -Beispiel SQL | -Kommentare | -
|---|---|---|---|
| 1 | --CLASS A = - Attribut_1 : TEXT*20; -END A; - - - -CLASS B EXTENDS A = - Attribut_2 : TEST*20; -END B; -- |
--CREATE TABLE A ( - T_Id integer PRIMARY KEY, - T_Type varchar(60) NOT NULL, - Attribut_1 varchar(20) -); - -CREATE TABLE B ( - T_Id integer PRIMARY KEY, - Attribut_2 varchar(20) -); -- |
-Bei --noSmartMapping wird fĂŒr jede Klasse eine Tabelle erstellt. Ein Objekt A ergibt -ein Record in Tabellen A. -Ein Objekt B ergibt je ein Record in Tabellen A und B. Die T_Id ist bei beiden Records identisch. | -
| 2 | --CLASS A (ABSTRACT) = - Attribut_1 : TEXT*20; -END A; - - - -CLASS B EXTENDS A = - Attribut_2 : TEST*20; -END B; - - - - - -CLASS C EXTENDS B = - Attribut_3 : TEST*20; -END C; -- |
--CREATE TABLE B ( - T_Id integer PRIMARY KEY, - T_Type varchar(60) NOT NULL, - Attribut_1 varchar(20), - Attribut_2 varchar(20), - Attribut_3 varchar(20) -); -- |
-Bei --smart1Inheritance wird fĂŒr abstrakte Klassen (A) keine Tabelle erstellt (ausser sie wird -referenziert). FĂŒr die allgemeinste konkrete Klasse (B) wird eine Tabelle erstellt. -FĂŒr erweiterte konkrete Klassen (C), die eine konkrete Klasse erweitern, -wird keine eigene Tabelle erstellt. | -
| 3 | --CLASS A (ABSTRACT) = - Attribut_1 : TEXT*20; -END A; - - - -CLASS B EXTENDS A = - Attribut_2 : TEST*20; -END B; - - - - -CLASS C EXTENDS B = - Attribut_3 : TEST*20; -END B; -- |
--CREATE TABLE B ( - T_Id integer PRIMARY KEY, - T_Type varchar(60) NOT NULL, - Attribut_1 varchar(20), - Attribut_2 varchar(20) -); - -CREATE TABLE C ( - T_Id integer PRIMARY KEY, - T_Type varchar(60) NOT NULL, - Attribut_1 varchar(20), - Attribut_2 varchar(20), - Attribut_3 varchar(20) -); -- |
-Bei --smart2Inheritance wird fĂŒr abstrakte Klassen (A) keine Tabelle erstellt (auch nicht, wenn sie -referenziert wird). FĂŒr konkrete Klassen (B und C) wird je eine vollstĂ€ndige Tabelle erstellt -(inkl. geerbte Attribute). | -
EXTENDED Attribute ergeben keine Spalte, nur die Basis-Definition des -Attributs ergibt eine Spalte.
-| Nummer | -Beispiel INTERLIS | -Beispiel SQL | -Kommentare | -
|---|---|---|---|
| 1 | --textLimited : TEXT*10; -textUnlimited : TEXT; -mtextLimited : MTEXT*10; -mtextUnlimited : MTEXT; -- |
--textLimited varchar(10) NULL -textUnlimited text NULL -mtextLimited varchar(10) NULL -mtextUnlimited text NULL -- |
-- |
| 2 | --aufzaehlung : (null, eins, zwei, - drei, mehr ( - vier, fuenf, sechs, sieben, acht ,neun, zehn) - ); -- |
--aufzaehlung varchar(255) NULL -- |
-Je nach Option, sind andere Abbildungen möglich. Siehe Kapitel AufzÀhlungen. | -
| 3 | --horizAlignment : HALIGNMENT; -vertAlignment : VALIGNMENT; -- |
--horizAlignment varchar(255) NULL -vertAlignment varchar(255) NULL -- |
-- |
| 4 | --aBoolean : BOOLEAN; -- |
--aBoolean boolean NULL -- |
-- |
| 5 | --numericInt : 0 .. 10; -numericDec : 0.0 .. 10.0; -- |
--numericInt integer NULL -numericDec decimal(4,1) NULL -- |
-- |
| 6 | --aTime : INTERLIS.XMLTime; -aDate : INTERLIS.XMLDate; -aDateTime : INTERLIS.XMLDateTime; -- |
--aTime time NULL -aDate date NULL -aDateTime timestamp NULL -- |
-- |
| 7 | --aOid : OID TEXT*30; -aUuid : INTERLIS.UUIDOID; -- |
--aOid varchar(255) NULL -aUuid uuid NULL -- |
-- |
| 8 | --aClass : CLASS; -- |
--aClass varchar(255) NULL -- |
-- |
TODO
-Beziehungen werden abhÀngig von der maximalen KardinalitÀt auf zwei Arten abgebildet:
-Die StÀrke der Beziehung (Assoziation, Aggregation oder Komposition) beeinflusst die Art der Abbildung nicht.
-| Nummer | -Beispiel INTERLIS | -Beispiel SQL | -Kommentare | -
|---|---|---|---|
| 1 | -
-CLASS A =
-END A;
-
-
-CLASS B =
-END B;
-
-
-
-ASSOCIATION a2b =
- role_A -- {0..1} ClassA;
- role_B -- {0..*} ClassB;
-END a2b;
-
- |
--CREATE TABLE A ( - T_Id integer PRIMARY KEY, -); - -CREATE TABLE B ( - T_Id integer PRIMARY KEY, - role_a integer REFERENCES A(T_id) -); -- |
-Wenn die maximale KardinalitÀt bei einer der beiden Rollen nicht grösser als 1 ist, -wird keine Zwischentabelle erstellt. | -
| 2 | -
-CLASS A =
-END A;
-
-
-CLASS B =
-END B;
-
-
-
-ASSOCIATION a2b =
- role_A -- {0..*} ClassA;
- role_B -- {0..*} ClassB;
-END a2b;
-
- |
--CREATE TABLE A ( - T_Id integer PRIMARY KEY, -); - -CREATE TABLE B ( - T_Id integer PRIMARY KEY, -); - - -CREATE TABLE a2b ( - role_a integer REFERENCES A(T_id) - role_b integer REFERENCES B(T_id) -); -- |
-Wenn die maximale KardinalitÀt bei beiden Rollen grösser als 1 ist, -wird eine Zwischentabelle erstellt. | -
| 3 | -
-CLASS A =
-END A;
-
-
-CLASS B =
-END B;
-
-
-
-ASSOCIATION a2b =
- role_A (EXTERNAL)
- -- {0..1} ClassA;
- role_B -- {0..*} ClassB;
-END a2b;
-
- |
--CREATE TABLE A ( - T_Id integer PRIMARY KEY, -); - -CREATE TABLE B ( - T_Id integer PRIMARY KEY, - role_a varchar(255) -); -- |
-Wenn die Option --sqlExtRefCols benutzt wird, -wird bei EXTERNAL statt der FremdschlĂŒsselspalte ein Text-Spalte erstellt, die den REF Wert -aus der Transferdatei aufnimmt. So muss das refernzierte Objekt nicht importiert werden. | -
TODO
-TODO
-TODO
-Strukturen werden im Allgemeinen abgebildet wie Klassen (siehe Kapitel zu der Abbildung von Klassen). Strukturattribute (also wenn eine Struktur -als Attributstyp verwendet wird, z.B. bei BAG OF oder LIST OF) werden unabhĂ€ngig von der KardinalitĂ€t durch einen FremdschlĂŒssel bei -der Tabelle der Struktur abgebildet. Bei gewissen Strukturen wird bei Smart-Mapping eine alternative Abbildung verwendet.
-| Nummer | -Beispiel INTERLIS | -Beispiel SQL | -Kommentare | -
|---|---|---|---|
| 1 | --STRUCTURE C = -END C; - - - - - -CLASS D = - attr1 : LIST OF C; - attr2 : LIST OF C; -END D; -- |
--CREATE TABLE C ( - T_Id integer PRIMARY KEY, - T_seq integer NOT NULL, - D_attr1 integer, - D_attr2 integer -); - -CREATE TABLE D ( - T_Id integer PRIMARY KEY -); -- |
-FĂŒr jedes Strukturattribut wird in der Tabelle der Struktur eine Spalte fĂŒr den FremdschlĂŒssel erstellt. Der Name der Spalte ist der qualifizierte INTERLIS-Attributnamen [3]. -Die Strukturtabelle enthĂ€lt zusĂ€tzlich eine Spalte T_seq die die Reihenfolge der Strukturelement festlegt. - |
-
| 2 | --STRUCTURE C = -END C; - - - - - - -CLASS D = - attr1 : LIST OF C; -END D; -- |
--CREATE TABLE C ( - T_Id integer PRIMARY KEY, - T_seq integer NOT NULL, - T_ParentId integer NOT NULL - T_ParentType varchar(60) NOT NULL - T_ParentAttr varchar(60) NOT NULL -); - -CREATE TABLE D ( - T_Id integer PRIMARY KEY -); -- |
-Mit der Option --structWithGenericRef werden statt fĂŒr jedes Strukturattribut eine Spalte nur drei Standardspalten T_ParentId, T_ParentType, T_ParentAttr angelegt. Diese drei Spalten bilden zusammen einen generischen FremdschlĂŒssel. -T_ParentId ist die t_id des Objektes, das das Strukturelement enthĂ€lt. -T_ParentType ist die konkrete Klasse (der SQL-Name des qualifizierten INTERLIS-Klassennamens [4]) des Objektes, das das Strukturelement enthĂ€lt. -T_ParentAttr ist der Strukturattributname (der SQL-Name des unqualifizierten INTERLIS-Attributnamens) in der Klasse des Objektes, das das Strukturelement enthĂ€lt. - |
-
Beispiel XML:
--|<BspTable.TopicA.D TID="2"> -| <attr1> -| <BspTable.TopicA.C> -| </BspTable.TopicA.C> -| <BspTable.TopicA.C> -| </BspTable.TopicA.C> -| </attr1> -| <attr2> -| <BspTable.TopicA.C> -| </BspTable.TopicA.C> -| </attr2> -|</BspTable.TopicA.D> --
Beispiel fĂŒr Abbildungsvariante 1:
-| Tabelle C | -- | - | - |
|---|---|---|---|
| t_id | -t_seq | -D_attr1 | -D_attr2 | -
| 7 | -0 | -6 | -- |
| 8 | -1 | -6 | -- |
| 9 | -0 | -- | 6 | -
| Tabelle D | -- |
|---|---|
| t_id | -T_Ili_Tid | -
| 6 | -2 | -
Beispiel fĂŒr Abbildungsvariante 2:
-| Tabelle C | -- | - | - | - |
|---|---|---|---|---|
| t_id | -t_seq | -t_parentid | -t_parenttype | -t_parentattr | -
| 7 | -0 | -6 | -D | -attr1 | -
| 8 | -1 | -6 | -D | -attr1 | -
| 9 | -0 | -6 | -D | -attr2 | -
| Tabelle D | -- |
|---|---|
| t_id | -T_Ili_Tid | -
| 6 | -2 | -
Bei den folgenden Strukturen wird bei Smart-Mapping fĂŒr die Strukturattribute eine alternative Abbildung verwendet:
-FĂŒr die Abbildung von AufzĂ€hlungen gibt es zwei Varianten und verschiedene Optionen.
-| Nummer | -Beispiel INTERLIS | -Beispiel SQL | -Kommentare | -
|---|---|---|---|
| 1 | --farbe : (rot, blau, gruen); -- |
--farbe varchar(255) NULL -- |
-Default-Abbilung. Der XTF-Code (der Code wie er in der XTF-Transferdatei steht) -wird als AufzÀhlwert in der Datenbank verwendet. Im Beispiel also: -rot, blau oder gruen | -
| 2 | --farbe : (rot, blau, gruen); -- |
--farbe integer NULL -- |
-Abbilung mit der Option --createEnumColAsItfCode. Der ITF-Code (der Code -wie er in der ITF-Transferdatei steht) wird als AufzÀhlwert in der Datenbank -verwendet. Im Beispiel also: 0, 1 oder 2. Diese Option ist nur zulÀssig, wenn im -Modell keine Erweiterungen von AufzÀhlungen vorkommen. | -
| 3 | --farbe : (rot, blau, gruen); -- |
--farbe varchar(255) NULL, -farbe_txt varchar(255) NULL -- |
-Abbilung mit der Option --createEnumTxtCol. Es wird eine zusĂ€tzliche Spalte -mit dem Attributnamen+``_txt`` erstellt (Im Besipiel art_txt). -Die zusĂ€tzliche Spalte kann einen beliebigen Wert enthalten, der als Anzeigetext -gedacht ist. Beim Import wird die Spalte mit dem XTF-Code befĂŒllt. -Die Option kann bei Variante 1 oder 2 benutzt werden. | -
| 4 | --DOMAIN - Farbe : (rot, blau, - !!@ili2db.dispName=grĂŒn - gruen - ); -- |
--CREATE TABLE Farbe ( - itfCode integer PRIMARY KEY, - iliCode varchar(1024) NOT NULL, - seq integer NULL, - dispName varchar(250) NOT NULL, - description varchar(1024) NULL, - inactive boolean NOT NULL -); -- |
-Abbildung mit der Option --createEnumTabs. Es wird pro AufzĂ€hlungsdefinition -eine Tabelle mit den einzelnen AufzĂ€hlwerten erstellt. -itfCode ist der ITF-Code des AufzĂ€hlwertes. -iliCode ist der qualifizierte Elementnamen (=XTF-Code) des AufzĂ€hlwertes. -seq Definiert die Reihenfolge der AufzĂ€hlelemente. -dispName definiert den Anzeigetext fĂŒr das AufzĂ€hlelement. Beim Import wird die -Spalte mit dem XTF-Code befĂŒllt. Falls das AufzĂ€hlelement das Metaattribut -@ili2db.dispName hat, wird dessen Wert verwendet. -description enthĂ€lt die Beschreibung des AufzĂ€hlelements. Beim Import wird die -Spalte mit dem ilidoc Kommentar aus dem Modell befĂŒllt. -inactive TRUE um einen AufzĂ€hlwert fĂŒr die Erfassung auszublenden, ohne dass -er gelöscht werden muss. Wird beim Import mit FALSE befĂŒllt. - |
-
| 5 | --DOMAIN - Farbe : (rot, blau, - !!@ili2db.dispName=grĂŒn - gruen - ); -- |
--CREATE TABLE T_ILI2DB_ENUM ( - thisClass varchar(1024) NOT NULL, - baseClass varchar(1024) NOT NULL, - itfCode integer NOT NULL, - iliCode varchar(1024) NOT NULL, - seq integer NULL, - dispName varchar(250) NOT NULL, - description varchar(1024) NULL, - inactive boolean NOT NULL -); -- |
-Abbildung mit der Option --createSingleEnumTab. Es wird -eine einzige Tabelle fĂŒr die AufzĂ€hlwerte aller AufzĂ€hlungen erstellt. -thisClass ist der qualifizierte Namen der AufzĂ€hlungsdefinition. -baseClass ist der qualifizierte Namen der Basis-AufzĂ€hlungsdefinition -itfCode ist der ITF-Code des AufzĂ€hlwertes. -iliCode ist der qualifizierte Elementnamen (=XTF-Code) des AufzĂ€hlwertes. -seq Definiert die Reihenfolge der AufzĂ€hlelemente. -dispName definiert den Anzeigetext fĂŒr das AufzĂ€hlelement. Beim Import wird die -Spalte mit dem XTF-Code befĂŒllt. Falls das AufzĂ€hlelement das Metaattribut -@ili2db.dispName hat, wird dessen Wert verwendet. -description enthĂ€lt die Beschreibung des AufzĂ€hlelements. Beim Import wird die -Spalte mit dem ilidoc Kommentar aus dem Modell befĂŒllt. -inactive TRUE um einen AufzĂ€hlwert fĂŒr die Erfassung auszublenden, ohne dass -er gelöscht werden muss. Wird beim Import mit FALSE befĂŒllt. - |
-
| 6 | --DOMAIN - Farbe : (rot, blau, - !!@ili2db.dispName=grĂŒn - gruen - ); -- |
--CREATE TABLE Farbe ( - T_Id integer PRIMARY KEY, - thisClass varchar(1024) NOT NULL, - baseClass varchar(1024) NOT NULL, - itfCode integer NOT NULL, - iliCode varchar(1024) NOT NULL, - seq integer NULL, - dispName varchar(250) NOT NULL, - description varchar(1024) NULL, - inactive boolean NOT NULL -); -- |
-Abbildung mit der Option --createEnumTabsWithId. Es wird pro -Basis-AufzĂ€hlungsdefinition eine Tabelle mit den einzelnen AufzĂ€hlwerten, -inkl. aller AufzĂ€hlungserweiterungen von dieser Basisdefinition. -thisClass ist der qualifizierte Namen der AufzĂ€hlungsdefinition. -baseClass ist der qualifizierte Namen der Basis-AufzĂ€hlungsdefinition -itfCode ist der ITF-Code des AufzĂ€hlwertes. -iliCode ist der qualifizierte Elementnamen (=XTF-Code) des AufzĂ€hlwertes. -seq Definiert die Reihenfolge der AufzĂ€hlelemente. -dispName definiert den Anzeigetext fĂŒr das AufzĂ€hlelement. Beim Import wird die -Spalte mit dem XTF-Code befĂŒllt. Falls das AufzĂ€hlelement das Metaattribut -@ili2db.dispName hat, wird dessen Wert verwendet. -description enthĂ€lt die Beschreibung des AufzĂ€hlelements. Beim Import wird die -Spalte mit dem ilidoc Kommentar aus dem Modell befĂŒllt. -inactive TRUE um einen AufzĂ€hlwert fĂŒr die Erfassung auszublenden, ohne dass -er gelöscht werden muss. Wird beim Import mit FALSE befĂŒllt. - |
-
Einzelne Abbildungen können direkt im Modell ĂŒber Metaaatribute konfiguriert werden. -Metaattribute stehen unmittelbar vor dem Modellelement das sie betreffen und beginnen mit !!@. -Falls der Wert (rechts von `=`) aus mehreren durch Leerstellen getrennten Wörtern besteht, muss er mit GĂ€nsefĂŒsschen eingerahmt werden (`"..."`).
-| Modelelement | -Metaattribut | -Beschreibung | -
|---|---|---|
| AttributeDef | --ili2db.mapping -- |
-Strukturattribute mit diesem Meta-Attribut -werden als Spalte mit dem Datentyp Array oder JSON abgebildet. -D.h. es gibt keine weiteren Records in einer Hilfstabelle. -Siehe auch Programm-Optionen --coalesceArray und --coalesceJson. -Mögliche Werte: ARRAY, JSON | -
| ClassDef | --ili2db.mapping -- |
-Strukturen mit diesem Meta-Attribut -werden als Spalte mit dem enstprechenden Multi-Geometrie Datentyp abgebildet. -D.h. es gibt keine weiteren Records in einer Hilfstabelle. -Mögliche Werte: MultiSurface, MultiLine, MultiPoint | -
| ClassDef, -AttributeDef, -EnumElement | --ili2db.dispName -- |
-Definiert den Anzeigetext fĂŒr das entsprechende Modell-Element. -FĂŒr AufzĂ€hlelemente ist es der Wert der Saplte dispName in der jeweiligen Tabelle -mit den AufzĂ€hlwerten. -FĂŒr Klassen ist es in der Tabelle t_ili2db_table_prop der Wert mit -dem Tag ch.ehi.ili2db.dispName. -FĂŒr Attribute ist es in der Tabelle t_ili2db_column_prop der Wert mit -dem Tag ch.ehi.ili2db.dispName. | -
| ClassDef | --ili2db.oid -- |
-Mit dem Metaattribut ili2db.oid erhÀlt die Tabelle (die eine Klasse -reprÀsentiert, die keine Basisklasse hat) eine zusÀtzliche Spalte -T_Ili_Tid, wie wenn die Klasse eine OID hÀtte. -Siehe auch Klassen/Strukturen. | -
Ein Modell kann beliebige weitere Metaattribute enthalten; diese werden -durch ili2db beim Schemaimpot in t_ili2db_meta_attrs abgelegt. -Mit Hilfe der Option --iliMetaAttrs können beliebige weitere Metaattribute -definiert werden, ohne das Modell (die ili-Datei) zu Àndern.
-| Tabelle | -Beschreibung | -
|---|---|
| t_ili2db_attrname | -Abbildung von Attributnamen | -
| t_ili2db_basket | -In der Datenbank vorhandene Baskets. Wird benötigt, wenn die Option --createBasketCol verwendet wird. | -
| t_ili2db_classname | -Abbildung der qualifizierten Interlis Klassennamen auf Sql-Namen. Nicht aus jedem Eintrag gibt es eine Datenbank-Tabelle, je nach Abbildungsart der Interlis-Klasse wird der Sql-Name nur als Inhalt der Spalte t_type verwendet. | -
| t_ili2db_dataset | -In der Datenbank vorhandene DatensÀtze (Sammlung von Baskets). Wird benötigt, wenn die Option --createBasketCol verwendet wird. | -
| t_ili2db_import | -Nicht mehr verwenden, wird entfernt. Wird beim Export nicht benötigt. | -
| t_ili2db_import_basket | -Nicht mehr verwenden, wird entfernt. Wird beim Export nicht benötigt. | -
| t_ili2db_import_object | -Nicht mehr verwenden, wird entfernt. Wird beim Export nicht benötigt. | -
| t_ili2db_inheritance | -Abbildung der Interlis Klassen Vererbungshierarchie (in der Tabellen sind die qualifizierten Interlis Klassennamen). Wird beim Export nicht benötigt. | -
| t_ili2db_enum | -AufzÀhlwerte, falls die Option --createSingleEnumTab verwendet wird. Wird beim Export nicht benötigt. | -
| t_ili2db_model | -Modelle, die beim Import benötigt wurden (so dass der Export mit denselben Modellen erfolgen kann). | -
| t_ili2db_settings | -Programmeinstellungen fĂŒr ili2db | -
| t_ili2db_trafo | -Konfiguration der semantischen Abbildung (insb. der Vererbung) | -
| t_ili2db_table_prop | -Weitere Angaben zu den DB-Tabellen aus dem Interlis Modell (z.B. ob es eine Tabelle mit AufzÀhlwerten ist). Wird nur erstellt mit Option --createMetaInfo. | -
| t_ili2db_column_prop | -Weitere Angaben zu den DB-Spalten aus dem Interlis Modell (z.B. ob es MTEXT ist). Wird nur erstellt mit Option --createMetaInfo. | -
| t_ili2db_meta_attrs | -Interlis-Meta-Attribute (auch fĂŒr Modell-Elemente, denen kein DB-Element entspricht; z.B. die einem FK gegenĂŒberliegende Rolle). Wird nur erstellt mit der Option --createMetaInfo. | -
| t_key_object | -Hilfstabelle fĂŒr den ID-Generator. Wird beim Export nicht benötigt. | -
TODO alle Tabelle beschreiben
-Angaben zu den einzelnen BehÀltern (Ein BehÀlter ist eine Instanz eines TOPICs).
-Weitere Angaben zu den DB-Spalten aus dem Interlis Modell (z.B. ob es MTEXT ist). -Wird nur erstellt mit Option --createMetaInfo. Die Tabelle ist so aufgebaut, dass -sie beliebige (auch zukĂŒnftige) Werte/Zusatzangaben aufnehmen kann.
-| Tag | -Beschreibung | -
|---|---|
| ch.ehi.ili2db.c1Min | -Bei Geometriespalten der Minimalwert der 1. Dimension | -
| ch.ehi.ili2db.c1Max | -Bei Geometriespalten der Maximalwert der 1. Dimension | -
| ch.ehi.ili2db.c2Min | -Bei Geometriespalten der Minimalwert der 2. Dimension | -
| ch.ehi.ili2db.c2Max | -Bei Geometriespalten der Maximalwert der 2. Dimension | -
| ch.ehi.ili2db.c3Min | -Bei Geometriespalten der Minimalwert der 3. Dimension | -
| ch.ehi.ili2db.c3Max | -Bei Geometriespalten der Maximalwert der 3. Dimension | -
| ch.ehi.ili2db.geomType | -Bei Geometriespalten die Art der Geometrie. Mögliche Wert: -POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING -MULTIPOLYGON, GEOMETRYCOLLECTION, CIRCULARSTRING -COMPOUNDCURVE, CURVEPOLYGON, MULTICURVE, MULTISURFACE -POLYHEDRALSURFACE, TIN, TRIANGLE | -
| ch.ehi.ili2db.srid | -Bei Geometriespalten der EPSG Code | -
| ch.ehi.ili2db.coordDimension | -Bei Geometriespalten die Dimension der Geometrie | -
| ch.ehi.ili2db.dispName | -Benutzerfreundliche Bezeichnung der Spalte (z.B. im UI) | -
| ch.ehi.ili2db.textKind | -Falls mehrzeilige Textspalte, der Wert MTEXT | -
| ch.ehi.ili2db.unit | -Name der numerischen Einheit z.B. m | -
| ch.ehi.ili2db.foreignKey | -Bei FremdschlĂŒsseln der Name der Zieltabelle. Damit auch -ohne --createFk die Beziehungen ermittelt werden können | -
| ch.ehi.ili2db.enumDomain | -Bei AufzĂ€hlungsattributen der Name der konkreten AufzĂ€hlung. -Damit auch bei erweiterten Attributen/AufzĂ€hlungen die fĂŒr die -Subklasse relevante AufzĂ€hlung ermittelt werden kann | -
| ch.ehi.ili2db.oidDomain | -Bei Klassen mit OID der qualifizierte Name des -OID-Wertebereichs (z.B. INTERLIS.UUIDOID) | -
Weitere Angaben zu den DB-Tabellen aus dem Interlis Modell (z.B. ob es -eine Tabelle mit AufzÀhlwerten ist). Wird nur erstellt mit Option --createMetaInfo.
-| Tag | -Beschreibung | -
|---|---|
| ch.ehi.ili2db.dispName | -Benutzerfreundliche Bezeichnung der Tabelle (z.B. im UI) | -
| ch.ehi.ili2db.tableKind | -Art/Zweck der Tabelle -
|
-
Interlis-Meta-Attribute (auch fĂŒr Modell-Elemente, denen kein DB-Element -entspricht; z.B. die einem FK gegenĂŒberliegende Rolle). -Diese Tabelle wird nur erstellt -mit der Option --createMetaInfo. -Die Tabelle enthĂ€lt auch von ili2db aufgrund des Modells generierte -Meta-Attribute (z.B. KardinaliĂ€t einer Rolle). Die Namen dieser generierten -Meta-Attribute beginnen -mit ili2db.ili..
-Von ili2db werden automatisch aufgrund des Interlis-Modells folgende -Meta-Attribute generiert:
-| Tag | -Beschreibung | -
|---|---|
| ili2db.ili.attrCardinalityMin | -minimum Anzahl Werte eines Attributes | -
| ili2db.ili.attrCardinalityMax | -maximum Anzahl Werte eines Attributes | -
| ili2db.ili.assocCardinalityMin | -minimum Anzahl Objekte zu einer Bezeihungs-Rolle | -
| ili2db.ili.assocCardinalityMax | -maximum Anzahl Objekte zu einer Beziehungs-Rolle | -
| ili2db.ili.assocKind | -StÀrke der Rolle -
|
-
Die Abbildung der Klassennamen in Tabellennamen erfolgt nach drei -möglichen Strategien:
-Falls der Tabellenname zu lang ist, wird er gekĂŒrzt, in dem die Vokale -entfernt werden (ausser die ersten beiden und letzten beiden -Buchstaben). Falls er danach immer noch zu lang ist, werden in der der -Mitte des Namens Buchstaben entfernt.
-Falls der Tabellenname nun einem SQL-SchlĂŒsselwort entspricht, wird er -um ein fĂŒhreneds âaâ ergĂ€nzt.
-Falls der Tabellenname nun nicht eindeutig ist, wird er um eine Ziffer -ergĂ€nzt: â0â, â1â, usw. bis er eindeutig ist.
-Die automatische Namensabbildung kann ĂŒbersteuert werden, indem vor dem -ersten Import entsprechende EintrĂ€ge in der Tabelle t_ili2db_classname -gemacht werden.
-| [1] | GML 3.2; die verwendeten Kodierungsregeln entsprechen eCH-0118-1.0 |
| [2] | Der SQL-Name ergibt sich aus den Namenskonventionen. Die konkrete -Ăbersetzung ist in der Tabelle T_ILI2DB_CLASSNAME hinterlegt. |
| [3] | Der SQL-Name ergibt sich aus den Namenskonventionen. Die konkrete -Ăbersetzung ist in der Tabelle T_ILI2DB_ATTRNAME hinterlegt. |
| [4] | Der SQL-Name ergibt sich aus den Namenskonventionen. Die konkrete -Ăbersetzung ist in der Tabelle T_ILI2DB_CLASSNAME hinterlegt. |