Das CERA-2 Daten- und Metadatenmodell
Werbung
Wissenschaftliches Datenmanagement: Das CERA-2 Daten- und Metadatenmodell Frank Toussaint, Potsdam-Institut für Klimafolgenforschung Zusammenfassung Um die in jeder Beziehung stark inhomogenen Daten verschiedener Forschungsinstitute zugänglich zu machen, wurde das Daten- und Metadatenmodell CERA entwickelt. Es ermöglicht für geografisch bezogene Metadaten institutsübergreifenden Zugang. Inhalt, Qualität, Formate und zahlreiche andere Parameter der beschriebenen Daten sind damit allgemein abrufbar. Die SQL der auf ORACLE-Basis erfolgten Umsetzung am PIK ist über das Internet einsehbar. Außerdem wurde eine flexible Java-Oberfläche (AFRI) entwickelt, mit der die Datenbank-Inhalte in Inter- und Intranet sichtbar gemacht werden. 1. Einführung Wie auf allen Gebieten der IT so sind auch im Bereich der raumbezogenen Daten die Datenmengen in den letzten Jahren exponentiell angestiegen. Sie liegen oftmals weit verteilt auf verschiedenen Medien und sind nach Struktur, Format, Qualität und Menge extrem inhomogen. In Forschungsinstituten kommen die unterschiedlichen Sicherheits- und Nutzungsanforderungen der einzelnen Arbeitsgruppen hinzu. Aus dieser Situation heraus wurde 1997/98 das CERA-2 Datenmodell entwickelt, mit dem Ziel, die ganz unterschiedlichen raumbezogenen Daten verschiedener Institute gleichermaßen zu beschreiben und die Beschreibungen transparent zu koppeln. Außerdem sollte das Konzept von CERA (Climate and Environmental Data Retrieval and Archiving System) offen genug für die Möglichkeit sein, lokale Daten direkt in das Datenmodell der beschreibenden Daten zu integrieren. Hierdurch können die beschreibenden Informationen der Meta-Datenbank (MDB) mit den eigentlichen Daten verschmolzen werden. In den folgenden Kapiteln sollen die Anforderungen an das Datenmodell skizziert (Kap. 2) und seine Entstehung beschrieben (Kap. 3) werden. Es folgen eine Beschreibung der Struktur des Modells (Kap. 4) sowie der aktuellen Implementation (Kap. 5) am Potsdam-Institut für Klimafolgenforschung (PIK). Zusätzlich wurde eine flexible, webfähige grafische Nutzerschnittstelle (AFRI) entwickelt, die in Kapitel 6 beschrieben wird. Den Abschluss bildet ein kurzer Ausblick auf die geplante Weiterentwicklung (Kap. 7) von CERA-2 und seiner Implementation im PIK. 2. Motivation und Anforderungen an das Metadatenmodell Zunächst sind die verschiedenen Anforderungen an das Datenmodell zu formulieren. Dabei sei vorgegeben, dass es sich um geografisch-raumbezogene Daten (Geospatial Data) handeln soll. Die Zuordnung zu Raumbereichen erfolgte über bounding boxes (minimale und maximale geografische Länge und Breite) sowie (optional) über örtliche Bezeichnungen. Bei der Festlegung der Metadatenstrukturen von CERA-2 standen vor allem folgende, sich teilweise überschneidende Punkte im Vordergrund: • Flexibilität der Datenstrukturen hinsichtlich der sehr inhomogenen Daten der verschiedenen Anwender und ihrer ebenso inhomogenen Bedürfnisse, • leichte Erweiterbarkeit zur Anpassung an neue Anforderungen, die im Hause aber auch durch Erweiterung des Kreises der Nutzerinstitute immer wieder auftreten, • Übersichtlichkeit der Strukturen, da etliche Dutzend Tabellen miteinander in Verbindung stehen und über Institutsgrenzen hinweg koppelbar sein sollen, • hinreichende Beschreibung der Speicherstrukturen, um automatischen Datenzugriff zu ermöglichen, • Kompatibilität zu inhaltlichen Standards wie sie durch den Content Standard of Digital Geospatial Metadata (CSDGM) des Federal Geographic Data Committee (FGDC 1999) oder das Directory Interchange Format (DIF) der National Aeronautics and Space Administration (NASA 1999) festgelegt werden, • Kompatibilität zu funktionalen Standards. Zum Beispiel fordert die US-amerikanische IEEE (siehe Bretherton 1994) neben »Browse/Search/Retrieval« Funktionen und der Unterstützung von »Storage and Archive« auch die Möglichkeit, mittels der Metadaten »Application to Application Transfer« durchzuführen sowie »Ingest, Quality Assurance and Reprocessing«. • transparente Vernetzung verteilter Datenbestände soll möglich sein, • akzeptabler Aufwand für Pflege und Nutzung, damit die DB die Projektlaufzeit ihrer Erstellung überlebt. Außerdem spielte bei der Umsetzung eine besondere Rolle, dass die entstehende Datenbank von NichtInformatikern in weitgehend fachlich disjunkten Institutionen verwendet werden sollte. 3. Werdegang von CERA-2 Zunächst entstand am Deutschen Klimarechenzentrum (DKRZ) in Hamburg das CERA-1 Datenmodell in Zusammenarbeit mit dem Potsdam-Institut für Klimafolgenforschung (PIK) und dem Alfred-WegenerInstitut für Polar- und Meeresforschung (AWI) in Bremerhaven. Auf Basis des Oracle DatenbankManagementsystems (DBMS) wurde ein relationaler Ansatz gewählt. Einer relationalen Struktur wurde aus verschiedenen Gründen der Vorzug gegeben. Neben der besseren Übersichtlichkeit spielten dabei Institute 1 Institute 2 CERA Module A l.e. 1 l.e. 2 CERA Core Mod. B Mod. C local extension 3 Institute 3 Abb. 1: Die CERA-2 Tabellen teilen sich in einen Kernbereich (CERA Core), die Module (CERA Modules) und lokal installierte Erweiterungen (local extensions). vor allem die weite Verbreitung und der hohe Entwicklungsstand entsprechender Systeme eine Rolle, mit denen für Oracle und Sybase auch bereits positive Erfahrungen vorlagen. Gleichzeitig war mit SQL eine einheitliche Definitions- und Abfragesprache verfügbar, die eine Zusammenarbeit verschiedener Entwicklungszentren begünstigte. Dieser zunächst sehr an der Massendatenhaltung des DKRZ ausgerichtete erste Entwurf war Grundlage für das CERA-2 Datenmodell, das von den beteiligten Instituten unter Potsdamer Federführung erstellt wurde. Die gemeinsame Entwicklung wurde über das Internet (Diskussionsbeiträge, gemeinsame »CERA Central Page«) koordiniert. Dabei wurde die Entstehung besonders davon beeinflusst, dass die beteiligten Institute sehr unterschiedliche Interessen haben, bedingt durch ihre unterschiedlichen Datenstrukturen (AWI: große Mengen mäßig homogener Messdaten; DKRZ: große Mengen relativ homogener Modelldaten; PIK: relativ geringe Mengen extrem inhomogener Daten). 4. Grundlagen von CERA-2 4.1 Die Struktur: CERA Core und CERA Modules Flexibilität und Erweiterbarkeit werden vor allem durch die Aufteilung der Tabellen in Gruppen gewährleistet. Dabei sollte die zentrale Gruppe von gut 40 Tabellen (CERA Core) von allen Partnerinstituten installiert und in der Regel auch genutzt (i.e. befüllt) werden. Hingegen werden Tabellengruppen, die nur für einige Teilnehmer von Bedeutung sind, dort als sogenannte CERA Modules installiert. Schließlich kann jedes Institut natürlich eigene Tabellenstrukturen (»Local Extensions«) in CERA integrieren (s. Abb. 1). REFERENCE Any publication related to the data can be stored in this block, together with the form of presentation of the data. Publication types include, e.g., the publication of the data itself or papers that make use of the data. STATUS Here some status information is given as, e.g., on data quality and processing that has been applied to the data. COVERAGE This block contains information on the volume of spacetime, covered by the data. METADATA ENTRY This is the main CERA Block, providing information on - the entry’s title - its type and relation to other entries, if implemented - the project the data belong to - a summary of the entry - a list of keywords related to the data - creation and review dates of the metadata additionally : DISTRIBUTION Information on how data is distributed is provided in this block, including access restrictions, data format, and fees. MODULES AND LOCAL EXTENSIONS Module DATA_ORGANIZATION Module DATA_ACCESS Local extensions for specific information on (e.g.): - data usage - data access and data administration PARAMETER The content of this block describes the topic, the data gives information about, its unit, and its aggregation in space (e.g., data given per country, per square degree) and time (weekly, daily data). SPATIAL REFERENCE Information on the coordinate systems used. CONTACT Information on contact persons and contact institutes related to the data, as e.g., distributor, investigator, and owner of the copyright. Abb. 2: Der CERA-Kernbereich (CERA Core) ist thematisch in Tabellengruppen (CERA Blocks) untergliedert. Abb. 3: METADATA ENTRY STATUS SPATIAL REFERENCE CERA Core Hauptblock (“Metadata Entry”) mit Blöcken “Status” und “Spatial Information”. ENTRY entry_id entry_name entry_acronym entry_type_id summary_id quality_id progress_id creation_date review_date future_review_date QUALITY SPATIAL_REFERENCE quality_id accuracy_report consistency_report completeness_report horizontal_acc_report vertical_acc_report entry_id hor_coord_sys_id ver_coord_sys_id KEY_CONNECT entry_id general_key_id VER_COORD_SYS PROGRESS SUMMARY summary_id summary GENERAL_KEY ver_coord_sys_id sys_descr general_key_id general_key PROCESS_STEP ENTRY_TYPE entry_type_id entry_type entry_type_descr progress_id progress_descr HOR_COORD_SYS CAMPAIGN entry_id project_id entry_id process_descr process_date person_id hor_coord_sys_id sys_descr ENTRY_CONNECT PERSON gen_entry_id spec_entry_id connect_type_id PROJECT CONNECT_TYPE project_id project_name project_acronym project_descr connect_type_id connect_type connect_type_descr PARAMETER LOCATION_CONNECT COVERAGE CONTACT DISTRIBUTION REFERENCE ENTITY: List of values ENTITY: other RELATION Abb. 4: CERA Core Blocks “Parameter”, “Coverage“, “Contact”, “Distribution” und “Reference”. ENTRY currentness_ref_id currentness_ref_descr CURRENTNESS_REF topic_id topic_name topic_acronym topic_descr topic_pointer topic_level TOPIC unit_id unit_name unit_acronym unit_descr UNIT spatial_data_org_id reference_method SPATIAL_DATA_ORG AGGREGATION aggregation_id aggregation_descr PARAMETER entry_id topic_id unit_id spatial_data_org_id aggregation_id (data_org_id) (data_access_id) PARAMETER ENTRY temporal_coverage_id start_year start_month start_day stop_year stop_month stop_day currentness_ref_id TEMPORAL_COVERAGE spatial_coverage_id min_lat max_lat min_lon max_lon min_altitude max_altitude min_alt_unit_id max_alt_unit_id SPATIAL_COVERAGE entry_id temporal_coverage_id spatial_coverage_id COVERAGE location_id location_name location_pointer location_level ref_date min_lat max_lat min_lon max_lon LOCATION entry_id location_id LOCATION_CONNECT COVERAGE PROCESS_STEP institute_id institute_name institute_acronym department_name department_acronym country state_or_province place street street_postal_code pobox pobox_postal_code url additional_info INSTITUTE person_id first_name second_name last_name title institute_id telephone fax email url PERSON contact_type_id contact_type CONTACT_TYPE entry_id institute_id person_id contact_type_id CONTACT CONTACT ENTRY ENTRY PIK, DKRZ, AWI 07/99 CERA Version 2.4 access_type_id access_acronym access_descr ACCESS_TYPE format_id format_acronym format_descr FORMAT fees_id fees_acronym fees_descr FEES access_constraint_id constraint_descr ACCESS_CONSTRAINT use_constraint_id constraint_descr USE_CONSTRAINT entry_id data_size access_type_id format_id fees_id access_constraint_id use_constraint_id DISTRIBUTION DISTRIBUTION PRESENTATION presentation_id presentation_descr CITATION_TYPE citation_type_id citation_type citation_type_descr CITATION citation_id title authors publication publisher editor publication_date country state place edition access_spec presentation_id citation_type_id REF_TYPE ref_type_id ref_type_descr REFERENCE entry_id citation_id ref_type_id REFERENCE ENTRY Abb. 5: CERA Module “Data Access” CERA Module DATA_ACCESS, Version 1.0 PARAMETER data_access_id These are examples of using the strings of the storage table. They can be defined in "ACCESS_STRUCTURE": DATA_ACCESS data_access_id access_structure_id storage1_id storage2_id storage3_id storage4_id rec_structure_id modification_date ACCESS_STRUCTURE access_structure_id access_structure_name*80 accesss_structure_descr*2000 acc_structure disk ext.&int.: DB internal: storage1 host name DB type storage2 directory DB name storage3 file table name storage4 comment owner STORAGE storage_id storage_name*250 TABLE_NAME REC_STRUCTURE rec_structure_id structure_name*250 dim1_type*10 dim1_id dim2_type*10 dim2_id dim3_type*10 dim3_id dim4_type*10 dim4_id dim5_type*10 dim5_id SCALE TIME POINT_SET (PARA_ORDER: local extension) start_moment_id blob_id blob_size blob_table_name blob_min blob_max missing_value MOMENT blob_table_name blob_id blob These tables are an example of storing blobs at DKRZ (local extension). 3 ENTITIES 1 LIST OF VALUES Version 1.0, 6. February 1998 Institut 1 Institut 2 GUI GUI CERA Core ist inhaltlich in acht CERA Blocks unterteilt, die verschiedene Themenbereiche abdecken: Titel und Datum des Eintrags, die raumzeitliche Überdeckung der Daten, ihr Qualitäts- und Bearbeitungsstatus, die gemessenen physikalischen Größen, die verwendeten Koordinatensysteme, Kontaktinformation zu Datennehmern, eignern und Distributoren, die nötigen Informationen um an die Daten zu gelangen und schließlich Verbindungen zu eventuellen Publikationen (s. Abb. 2). In der CERA Core-Tabellenstruktur (s. Abb. 3 und 4) sind zahlreiche Wertetabellen integriert, um die Eingaben zu systematisieren. Sie sind auf der zur Eingabe bestimmten Benutzeroberfläche als Pull-Down-Menues zugänglich. Server JDBC Server JDBC A DB MS DB MS B DB DB Abb. 6: Eine Kopplung verschiedener DB an eine grafische Nutzerschnittstelle (GUI) kann über JDBC erfolgen, da entsprechende Treiber praktisch für alle DBMS erhältlich sind (Fall A, Sun 1998b). Bei gleichen DBMS ist oft eine Kopplung auf DB-Ebene (Fall B) sehr viel einfacher durchzuführen (z.B. bei ORACLE). Die CERA Module beschreiben als fakultative Erweiterungen des Modells beispielsweise die Speicher- (CERA Module Data Organization) und Zugriffsstrukturen (CERA Module Data Access, beispielhaft in Abb. 5) oder auch die Inputparameter, mit denen bestimmte Modelldaten erzeugt wurden (CERA Module Model Input). 4.2 Von Metadaten zu Daten: CERA Local Extensions Das CERA Datenmodell lässt Raum für die Bedürfnisse der einzelnen Anwender. Beispielsweise kann es lokal um zusätzliche Tabellen mit Metainformationen erweitert werden. Hierdurch wird der Tatsache Rechnung getragen, dass die erforderliche Detailgenauigkeit der Metadaten von Anwender zu Anwender stark unterschiedlich ist. Mittels der CERA Local Extensions können andererseits aber auch die Daten selbst in das Model integriert werden. Beschreibungen der Integration finden sich dann ggf. in den übrigen CERA Tabellen. In dieser Form erfolgte die Umsetzung am Deutschen Klimarechenzentrum. 4.3 Vernetzung von DB unter CERA Die transparente Kopplung der MetaDatenbanken verschiedener Institute ist grundsätzlich auf verschiedene Weisen möglich (s. Abb. 6). Bei der Verwendung gleicher DBMS kann vielfach direkt auf Datenbankebene gekoppelt werden. In diesem Fall sorgt die an den verschiedenen Orten gleiche Tabellenstruktur dafür, dass die lokalen Oberflächen unmittelbar auf die Partnerstrukturen aufsetzen können. So wird zum Beispiel gegenwärtig zwischen DKRZ und PIK verfahren, die beide Oracle als DBMS verwenden. Auch die datenbankspezifischen Nutzeroberflächen können dann gemeinsam verwendet werden. Etwas aufwendiger ist die Vernetzung, wenn verschiedene DBMS vorliegen. Die lokalen Nutzeroberflächen müssen in der Regel getrennt entwickelt werden, eine Kopplung ist via JDBC oder CORBA möglich. 4.4 Praktische Umsetzung Bei der Entwicklung von DB sind gegenüber theoretischen Entity-Relationship-(ER)-Modellen und ihren Forderungen nach Normalform verschiedentlich Kompromisse nötig, um die Nutzbarkeit nicht unnötig einzuschränken. In solchen Fällen muss der praktische Nutzwert den Ausschlag geben gegenüber modelltheoretisch oder ästhetisch ansprechenderen Lösungen. Unter Normalisierungsgesichtspunkten (Erste Normalform) hätte es sich in CERA zum Beispiel angeboten, die im Bereich der Beschreibung von Publikationen auftretenden »Autoren« in der sowieso vorhandenen Tabelle »Personen« abzulegen. Die genauere Betrachtung praktischer Fälle verbietet solches Vorgehen. Bei der Eingabe von Literaturzitaten sind oftmals von einem Autor nur der Nachname und der Initial des Vornamens bekannt. In der Personentabelle qualifiziert dies keinen Schlüssel, folglich ist eine Eintragung dort nicht sinnvoll. Das »Authors«-Feld muss daher als freier Text in der Beschreibung von Referenzen bleiben. Auch die Beschreibung der jeweiligen Speicherstruktur ist für die verschiedenen Daten der unterschiedlichen Institute so spezifisch, dass sie sich nicht ohne Weiteres in eine Datenstruktur abbilden lässt. In CERA wurde der wohl flexibelst denkbare Weg gewählt. Die Zugriffsbeschreibung erfolgt in vier freien Textfeldern. Deren Bedeutung wiederum kann abhängig von der konkreten Situation in einer beschreibenden Tabelle definiert werden. Eine häufige Bezeichnung für die vier Felder ist hier zum Beispiel Host/Pfad/Datei/Kommentar. Auf diese Weise können auch Zugriffsregeln für in DB gehaltene große Binärdatenmengen (Binary Large Objects, blobs) in der MDB abgelegt und zur automatisierten Weiterverarbeitung ausgelesen werden. Hierarchien werden in CERA nicht als Tabellengruppen mit einer Tabelle pro Ebene abgespeichert, da dies eine A-priori-Festlegung auf die Zahl der Hierarchieebenen erfordert. Statt dessen ist jeweils eine einzelne rekursive Tabelle eingerichtet worden. In ihr enthält jede Zeile einen Zeiger auf die Zeile des übergeordneten Eintrags sowie aus Performanzgründen die (redundante) Information über das Hierarchieniveau, auf dem sich die Zeile befindet. Zusammen gefasst mag man die praktische Umsetzung an dem Satz orientieren: Soviel Normalform wie möglich, aber durchaus Abweichungen wo nötig. In einigen, begründeten Fällen kann also durchaus von den Normalformen abgewichen werden, generell aber ist eine weitgehende Normalisierung durchaus wünschenswert. Der eingesparte Speicherplatz spielt beim heutigen Preisniveau von Festplatten zwar kaum noch eine Rolle, die Datenintegrität ist jedoch sehr viel leichter zu gewährleisten, wenn Doppelspeicherungen unterbleiben. Eine andere Maxime für den Strukturentwurf mag sein: So allgemein wie möglich, aber speziell wo nötig. Bei neuen Anforderungen sind Erweiterungen und Umstrukturierungen in generischen Modellentwürfen sehr viel leichter durchzuführen. Schließlich hat sich bewährt, über die reine Tabellenstruktur hinaus auch die Semantik in die Entwurfsdiskussion mit einzubeziehen. Allein unter dem Begriff “Modell” wird von verschiedenen Anwendern mal der ein Problem beschreibende Algorithmus verstanden, mal dessen Implementation als Programm und mal die resultierenden Ergebnisse. Eine sorgfältig gewählte Semantik ist umso wichtiger, wenn mehrere Personen unterschiedlicher fachlicher Herkunft am DB-Entwurf arbeiten, was für eine möglichst allgemein nutzbare Struktur gerade wünschenswert ist. 5. Die aktuelle CERA-Implementierung am PIK Gegenwärtig sind am PIK das CERA Core sowie zwei der CERA Module installiert und in Verwendung; außerdem eine Gruppe von rund 30 Tabellen (Ladetabellen) in denen Neueingaben aufgefangen werden. Erst nach einer halbautomatischen Prüfung werden sie dann mittels SQL Skripten in die CERA Tabellen übertragen. Die Füllung der Ladetabellen erfolgt über Masken (ORACLE Forms). Update der Datenbankeinträge ist ebenfalls über Masken möglich (s. Abb. 7). Die Abfrage der Datenbank erfolgt im Wesentlichen auf zwei Wegen: Über die CERA Central Page des Internets (http://www.pik-Potsdam.de/cera/) ist ein direkter Zugang zu einem Teil der Einträge über ein Java-Applet (AFRI, s. nächster Abschnitt) möglich, im Intranet zu allen Einträgen. Gleichzeitig kann hausintern (oft performanter) über das analoge Java-Programm zugegriffen werden. Zusätzlich kann die CERA MDB über ORACLE Masken abgefragt werden, die noch einige besondere Funktionalitäten bieten. INPUT Graphical user interface: " update MDB " (ORACLE Form) FOREIGN RETRIEVAL Graphical user interface: " read MDB " (ORACLE Form) Internet Web GUI : query for non protected data (WWW, Java) View layer : 9 views View layer : 5 views control layer CERA Load (input control layer) : 9 main loading tables INHOUSE RETRIEVAL user interface GUI: automatted: "load MDB" (ASCII (ORACLE input) Form) UPDATE PL/SQL script Abb. 7: CERA structure of approx. 75 tables Organized as CERA Core and several CERA Modules storage layer CERA Base (permanent storage) : Die CERA-2-Implementierung am PIK. Für Eingabe, Bearbeitung und Abfragen wurden ORACLE Forms Oberflächen verwendet. Um Konsistenz und Sinnhaftigkeit der Eingabedaten zu sichern, wurde eine Zwischenschicht von neun Haupt- und rund 20 kleineren Ladetabellen erzeugt, die eine Kontrolle der eingegebenen Daten ermöglicht, bevor diese mittels eines SQLSkriptes in die CERA-Tabellen eingetragen werden. Parallel entstand die Abfrage-Oberfläche “AFRI” (s. Kap. 6), die die CERA-Eintragungen in Intranet und Internet sichtbar macht. 6. AFRI und IDA: Flexible Grafische Nutzer Schnittstellen (GUI) auf Java Basis Zur komfortablen Abfrage von DB- und MetaDB-Inhalten wurde am PIK ein flexibles Java-Userinterface mit dem dazugehörigen Server entwickelt (AFRI, s. Abb. 8). Zusammen mit einem interaktiven digitalen Atlas (IDA) erlaubt es, intuitiv Anfragen auf die räumliche und zeitliche Überdeckung der gesuchten Daten zu formulieren. Außerdem ist eine Auswahl in Stichwort-Hierarchien und in Einzelfeldern möglich. Die auszugebenden Spalten können gewählt werden und die gefundenen Daten direkt auf den Client übertragen. Dabei wird der Kontakt zur Datenbank über JDBC (Sun 1998a) hergestellt. Abb. 8: Das Java-Programm AFRI ermöglicht DB-Abfragen über Internet, Intranet und als Standalone-Version. Es passt sich selbstkonfigurierend an die in Steuertabellen beschriebenen DBTabellen an. Die Datenstruktur, an die sich das GUI anpassen muss, wird in Tabellenform beschrieben und ebenfalls in der DB abgelegt, so dass bei Änderungen keine Neuprogrammierung erfolgen muss (s. Abb. AFRI/IDA). Dadurch eignet es sich nicht nur für CERA sondern für jede Art von Tabellengruppen geografischer Daten, die in einem relationalen DBMS über JDBC zugänglich sind. Abb. 9: Die Ausgabe erfolgt bei AFRI in Tabellenform oder mittels IDA als Ortsinformation. Bei der Ausgabe erlaubt IDA die Darstellung von verorteten Daten als Figuren auf den Karten des hierarchischen Atlas. Die aktuelle Version von AFRI hat unkomprimiert eine Größe von ca. 560 KB. Für den Zugriff auf die PIK MDB CERA ist sie über die CERA Central Page im Netz offen zugänglich. 7. Ausblick Am PIK ist die Installation von CERA-2 abgeschlossen. Die SQL-Skripte zur Tabellendefinition (DDL) sowie zahlreiche Tools (DML) können über die CERA Central Page eingesehen und abgerufen werden. Ebenso stehen dort die Beschreibungen des CERA-Konzepts zur Verfügung. Gegenwärtig ist CERA an vier Instituten installiert. Eine Kopplung der MDB steht bisher zwischen Potsdam und Hamburg zur Verfügung, weitere Kopplungen sind geplant. Noch unvollständig sind die Automatisierungsmöglichkeiten genutzt. Lediglich in der Ladeschicht laufen Konsistenzprüfungen bereits teilweise automatisch ab. Wenigstens soweit Speicherorte der Daten beschrieben werden, wäre von Zeit zu Zeit eine automatische Kontrolle auf Aktualität wünschenswert, da damit zu rechnen ist, dass in den verschiedenen Arbeitsgruppen Daten migrieren, ohne dass die entsprechenden Korrekturen der Metainformationen vorgenommen werden. Schließlich ist eine engere Anbindung der Daten an die Metadaten geplant. Nach Selektion der Metainformationen aus CERA (zum Beispiel mittels AFRI), soll sich der Nutzer schnell einen Überblick über die Daten selbst verschaffen können, um sie dann gegebenenfalls lokal weiter zu bearbeiten. Literatur Bretherton, F., 1994: Reference Model for Metadata: A Strawman. Whitepaper, University Wisconsin. URL: http://www.llnl.gov/liv_comp/metadata/papers/whitepaper-bretherton.html and whitepaperbretherton.ps Federal Geographic Data Committee (FGDC), 1999: Content Standard for Digital Geospatial Metadata (CSDGM), Version 1.0, URL: http://www.fgdc.gov/metadata/contstan.html Kramer, R. und F. Hosenfeld (Hrsg.) 1999: Heterogene, aktive Umweltdatenbanken, Workshop Vilm 1998, Metropolis-Verlag, Marburg 1999 Lautenschlager, M., F. Toussaint, H. Thiemann, M. Reinke, 1998: The CERA-2 Metadata Model, Technical Report No.15, Deutsches Klimarechenzentrum Hamburg 1998, URL: http:// www.pikpotsdam.de/cera/Descriptions/Publications/Papers/9807_DKRZ_TechRep15/ National Aeronautics and Space Administration (NASA), 1999: Global Change Master Directory, URL: http://gcmd.gsfc.nasa.gov/ Potsdam-Institut für Klimafolgenforschung (PIK), 1999: The CERA Central Page, URL: http://www.pikpotsdam.de/cera/ Sun Microsystems, 1998a: The JDBC Database Access API, URL: http://java.sun.com/products/ jdbc/jdbc.html Sun Microsystems, 1998b: JDBC Drivers, URL: http://java.sun.com/products/jdbc/jdbc.drivers.html Toussaint, F., M. Lautenschlager und M. Reinke, 1999: CERA-2 - Ein raumbezogenes Daten- und Metadatenmodell, in: Kramer und Hosenfeld 1999 Wrobel, M., 1999: AFRI/IDA - Ein flexibles Retrieval-Interface für heterogene raumbezogene Daten, in: Kramer und Hosenfeld 1999
