EP2054822A1 - Verfahren und vorrichtung zum aktualisieren einer datenbank und computerprogrammprodukt - Google Patents

Verfahren und vorrichtung zum aktualisieren einer datenbank und computerprogrammprodukt

Info

Publication number
EP2054822A1
EP2054822A1 EP07857247A EP07857247A EP2054822A1 EP 2054822 A1 EP2054822 A1 EP 2054822A1 EP 07857247 A EP07857247 A EP 07857247A EP 07857247 A EP07857247 A EP 07857247A EP 2054822 A1 EP2054822 A1 EP 2054822A1
Authority
EP
European Patent Office
Prior art keywords
file
updated
database
new
old
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP07857247A
Other languages
English (en)
French (fr)
Inventor
Martin Pfeifle
Volker Sasse
Jong-Hyun Suh
Uwe Tantz
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Aumovio Germany GmbH
Original Assignee
Continental Automotive Technologies GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Continental Automotive Technologies GmbH filed Critical Continental Automotive Technologies GmbH
Publication of EP2054822A1 publication Critical patent/EP2054822A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating

Definitions

  • the invention relates to a method and a device for updating a database.
  • a database system includes a database management system and the database.
  • the database comprises at least one file to be updated, which is stored on a storage device.
  • the invention relates to a computer program product comprising a computer readable storage medium having program instructions adapted to perform the method for updating the database.
  • a modern database system regularly includes a database and a database management system.
  • the database includes one or more files stored on one or more storage devices.
  • the files contain the data of the database.
  • the database management system is provided for managing the data of the database.
  • the management of the database may include, for example, searching, reading, and / or writing data to the corresponding files of the database.
  • an outdated file may be updated by an update command that includes a combination of search, read, and / or write commands.
  • the object of the invention is achieved by the features of the independent claims.
  • Advantageous embodiments of the invention are specified in the subclaims.
  • the invention is characterized according to a first aspect of the invention by a method and a device for updating a database of a database system.
  • the database system includes a database management system and the database.
  • the database comprises at least one file to be updated.
  • the file to be updated is stored on a storage device.
  • To update the database the file to be updated is overwritten with a new file of the database with current data by means of a transfer command.
  • the transfer command is written in a database language of the database system.
  • the database language is preferably SQL, but may also be an alternative database language.
  • the transfer command is preferably a copy command in which the source file does not necessarily have to be preserved.
  • the transfer command represents a transaction with multiple substeps. For example, the file to be updated may be overwritten step by step with the new file.
  • the file to be updated is checked how much the new file differs from the file to be updated.
  • the file to be updated will only be overwritten with the new file if the new file differs by at least a specified amount from the file to be updated.
  • the file to be updated is left on the storage device and updated depending on the new file, if the new file and the file to be updated differ at most or exactly by the predetermined amount. This can help to ensure that the file to be updated is completely replaced by the new file only if it is faster and / or more resource efficient than updating the file to be updated, depending on the new file.
  • the predetermined amount can be determined, for example, depending on the available hardware.
  • the file to be updated is overwritten with the new file when 20 percent or more of the new file is different from the file to be updated. This can help to replace the file to be updated with the new file only if it is faster and / or more resource efficient than updating the file to be updated, depending on the new file.
  • the database comprises at least a first and a second file to be updated. It is checked to what extent the first or the second file to be updated differ from a first or second new file. Depending on this check, at least one of the two files to be updated will be overwritten with the corresponding new file. The other of the two files to be updated is updated only on the storage device. This allows a simple, fast, and / or resource-efficient update of the database if multiple files are updated in one operation, and if the new files differ in severity from the corresponding files to be updated.
  • the file to be updated is backed up and / or deleted before being overwritten.
  • the advantageous embodiments of the method can be readily transferred to advantageous embodiments of the device.
  • the invention is characterized in a second aspect of the invention by a computer program product comprising a computer readable storage medium with program instructions.
  • the program instructions are designed to carry out the method explained above.
  • FIG. 1 shows a database system
  • Figure 3 is a flow chart of a program for updating the database.
  • a database system (FIG. 1) comprises a database management system 2 and a database 4.
  • the database 4 comprises at least one file.
  • the file is stored on a storage device of a computer.
  • the database 4 includes a plurality of files stored on the storage device or a plurality of other storage devices.
  • each file comprises at least one block, preferably comprising 1024 bytes.
  • the storage device preferably comprises a hard disk storage unit. Alternatively or additionally, the storage device may comprise a mobile data carrier.
  • the database system and / or in particular the database 4 can be a relational database System or a relational database 4 and / or a proprietary database system or a proprietary database 4 include.
  • the database management system 2 is designed to manage data stored in the database 4, in particular on the storage device.
  • the database management system 2 comprises a user interface IF, an SQL command processor SQL_CMD_PRO, a pager PAGER, a directory ID_LIB of index structures and an operating system interface OS IF.
  • the database management system 2 communicates with the database 4.
  • an alternative program module can be used.
  • the alternative program module can be selected depending on the programming language used.
  • a proprietary program module may be provided as an alternative to the SQL command processor SQL_CMD_PRO.
  • the user interface IF preferably comprises input and output units, by means of which command lines can be entered into the database management system 2.
  • the command lines are preferably written in a database language, preferably in SQL.
  • the user interface IF forwards the written command lines to the SQL command processor SQL_CMD_PRO.
  • the SQL command processor SQL_CMD_PRO determines a software execution plan depending on the command lines, and preferably, depending on at least one available index structure deposited in the ID_LIB directory of the index structures.
  • the software execution plan is a section of the program that serves to make access to the data as efficient as possible.
  • the software execution plan is passed to the pager PAGER by the SQL command processor SQL_CMD_PRO.
  • the pager PAGER is used to determine a hardware execution plan depending on the software execution plan.
  • the hardware execution plan is representative of how hardware, such as the hard disk storage device and / or the mobile media, which may include the database 4, must be driven to execute the software execution plan.
  • the hardware execution plan is transferred to the operating system interface OS_IF, which converts the hardware execution plan into corresponding control signals for the storage device on which the data is stored.
  • the database management system 2 is stored on a storage device of a navigation system.
  • the database management system 2 may be used independently of the navigation system.
  • the database management system 2 may be stored on a computer and used, for example, for managing music data.
  • the database 4, in particular a file of the database 4 is preferably stored on a storage device of the navigation system.
  • the database 4 preferably comprises a file POI of interesting places, a file 2D for two-dimensional map data, a file 3D for three-dimensional map data and / or a route file ROUTE for data for finding routes.
  • the database management system basically has two different options (FIG. 3).
  • a first possibility is to search for the elements of the file OLD_FILE to be updated by means of an update command SQL_UPD (FIG. 2) written in the database language and to replace them with current elements of a current file NEW FILE. This is especially useful if the new file NEW_FILE differs only slightly from the OLD FILE file to be updated. Minor means in this context that the file to be updated OLD FILE differs at most by a predetermined amount from the new file NEW_FILE.
  • a second possibility is that, depending on a transfer command SQL COPY written in the database language, the file OLD_FILE to be updated is overwritten with the new file NEW FILE with the current data.
  • the transfer command SQL_COPY is preferably a copy command.
  • the file OLD_FILE to be updated is backed up before being overwritten. After saving the file OLD_FILE to be updated, the file OLD FILE to be updated can be deleted from the storage device or overwritten directly.
  • the update command SQL_UPD and the transfer command SQL COPY are preferably representative of one transaction at a time.
  • the transactions preferably include substeps.
  • the OLD_FILE file to be updated can be updated or overwritten block by block, for example, always one block of the OLD FILE file to be updated with 1024 bytes at a time.
  • the OLD FILE file to be updated can be backed up before being overwritten; in particular, the OLD FILE file to be updated can be backed up and / or blocked in blocks.
  • the predetermined measure is preferably determined empirically.
  • the file to be updated, OLD FILE can be updated on the navigation device as a function of files changed to different degrees, and first durations required for this update can be determined.
  • first time durations it is preferable to determine second durations that are needed to overwrite the file OLD_FILE to be updated with the differently modified files.
  • the first and second time periods may then be used to find the appropriate predetermined amount.
  • the default measure may be between ten and thirty percent. In this context, this means that the OLD FILE file to be updated is only deleted and replaced by the new file NEW_FILE if the new file NEW FILE differs by ten to thirty percent from the OLD_FILE file to be updated.
  • the database 4 comprises a database 6 to be updated and the database 6 to be updated comprises a file POI of interesting locations which differs from the predefined measure from a new file POI of the points of interest, then it is preferably transmitted by means of the transfer command SQL COPY replaced by the new file POI interesting places.
  • the route file ROUTE to be updated of the database 6 to be updated differs from the new route file ROUTE by less than the predetermined amount, then the route file ROUTE to be updated is updated by means of the update command SQL UPD.
  • a program for updating the database 4 is stored on the storage device of the navigation system.
  • a computer in particular the navigation system on which the database management system is stored, can also be referred to as a device for updating the database.
  • the program for updating the database is preferably started in a step S1, in which variables are initialized if necessary.
  • a difference value DELTA is determined, which is representative of how much the file OLD FILE to be updated differs from the new file NEW_FILE.
  • a step S3 it is checked whether the difference value DELTA is greater than a predetermined threshold value THD.
  • the predetermined threshold THD represents the predetermined amount. If the condition of step S3 is satisfied, the processing is continued in step S5. If the condition of step S3 is not satisfied, the processing is continued in step S4.
  • step S4 the file OLD_FILE to be updated is updated by means of the update command SQL UPD and left on the storage device.
  • step S5 the file OLD_FILE to be updated is stored by means of a store instruction SAVE and thus saved and / or deleted by means of a deletion command DEL.
  • a block of the file OLD_FILE to be updated can be stored or saved or deleted.
  • a step S6 the new file NEW FILE is transferred to the storage device by means of the transfer command SQL_COPY and thus the file OLD FILE to be updated is transferred. if it has not yet been deleted in step S6.
  • the delete command DEL may be included in the transfer command SQL COPY.
  • the transfer command SQL_COPY is a copy command that automatically saves the new file NEW FILE instead of the file OLD_FILE to be updated.
  • a block of the file OLD FILE to be updated can be overwritten with a block of the new file NEW_FILE.
  • a step S7 the program can be terminated.
  • the program for all to be updated files OLD_FILE the database to be updated 6 is processed again from the step Sl.
  • the program can be executed individually for all blocks of the file OLD FILE to be updated.
  • the program for updating the database and / or the database management system can be stored on a mobile storage unit.
  • the mobile storage unit comprises program instructions which are adapted to update the database 6 to be updated.
  • the mobile storage unit is for example a CD, DVD and / or a memory stick or flash memory.
  • An advantage of updating database 4 using the SQL_UPD update command is that only the actual updated data is updated. However, after updating, logically related data, particularly old and updated data that is logically related, may no longer be spatially related to the storage device.
  • updating by means of the transfer command SQL_COPY offers the advantage that data which belong together logically can also be stored spatially and / or physically contiguous on the storage device.
  • map sections in particular the graphical data for illustration, are preferred. store the map sections spatially and / or physically coherently stored on the memory device, so that the corresponding map section can be read quickly. This is preferably also taken into account when creating the new file NEW FILE.
  • parts of the map excerpt can be stored at different locations of the storage device, in particular if only a part of the corresponding map excerpt is updated.
  • the read head of the storage device In order to display the map excerpt, the read head of the storage device then has to be brought to different locations of the storage medium of the storage device. This costs additional time.
  • the database system can be used independently of the navigation system.
  • the database may include fewer or more files.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Ein Datenbanksystem umfasst ein Datenbankverwaltungssystem (2) und eine Datenbank (4). Die Datenbank (4) umfasst zumindest eine zu aktualisierende Datei (OLD_FILE), die auf einer Speichervorrichtung abgespeichert ist. Zum Aktualisieren der Datenbank (4) wird die zu aktualisierende Datei (OLD_FILE) gelöscht. Eine neue Datei (NEW_FILE) der Datenbank (4) mit aktuellen Daten wird auf die Speichervorrichtung übertragen mittels eines Übertragungsbefehls (SQL_COPY), der in einer Datenbanksprache des Datenbanksystems verfasst ist.

Description

Beschreibung
Verfahren und Vorrichtung zum Aktualisieren einer Datenbank und Computerprogrammprodukt
Die Erfindung betrifft ein Verfahren und eine Vorrichtung zum Aktualisieren einer Datenbank. Ein Datenbanksystem umfasst ein Datenbankverwaltungssystem und die Datenbank. Die Datenbank umfasst zumindest eine zu aktualisierende Datei, die auf einer Speichervorrichtung abgespeichert ist. Ferner betrifft die Erfindung ein Computerprogrammprodukt, das ein computerlesbares Speichermedium mit Programmanweisungen umfasst, die zum Durchführen des Verfahrens zum Aktualisieren der Datenbank ausgebildet sind.
Ein modernes Datenbanksystem umfasst regelmäßig eine Datenbank und ein Datenbankverwaltungssystem. Die Datenbank umfasst eine oder mehrere Dateien, die auf einer oder mehrerer Speichervorrichtungen abgespeichert sind. Die Dateien enthalten die Daten der Datenbank. Das Datenbankverwaltungssystem ist vorgesehen zum Verwalten der Daten der Datenbank. Das Verwalten der Datenbank kann beispielsweise ein Suchen, ein Lesen und/oder ein Schreiben von Daten in die entsprechenden Dateien der Datenbank umfassen. Insbesondere kann eine nicht mehr aktuelle Datei aktualisiert werden durch einen Aktualisierungsbefehl, der eine Kombination aus Such-, Lese- und/oder Schreibbefehlen umfasst.
Es ist Aufgabe der Erfindung ein Verfahren und eine Vorrichtung zum Aktualisieren einer Datenbank zu schaffen, das beziehungsweise die einfach, schnell und Ressourcen sparend ein Aktualisieren der Datenbank, insbesondere von zu aktualisierenden Dateien der Datenbank ermöglicht.
Die Aufgabe der Erfindung wird gelöst durch die Merkmale der unabhängigen Ansprüche. Vorteilhafte Ausgestaltungen der Erfindung sind in den Unteransprüchen angegeben. Die Erfindung zeichnet sich aus gemäß eines ersten Aspekts der Erfindung durch ein Verfahren und eine Vorrichtung zum Aktualisieren einer Datenbank eines Datenbanksystems. Das Datenbanksystem umfasst ein Datenbankverwaltungssystem und die Datenbank. Die Datenbank umfasst zumindest eine zu aktualisierende Datei. Die zu aktualisierende Datei ist auf einer Speichervorrichtung abgespeichert. Zum Aktualisieren der Datenbank wird die zu aktualisierende Datei mit einer neuen Datei der Datenbank mit aktuellen Daten überschrieben mittels eines Übertragungsbefehls. Der Übertragungsbefehl ist in einer Datenbanksprache des Datenbanksystems verfasst.
Dies ermöglicht besonders einfach das Aktualisieren der Datenbank. Ferner kann dies dazu beitragen, dass die Datenbank schnell und/oder Ressourcen sparend aktualisiert wird, insbesondere wenn sich die neue Datei stark von der alten Datei unterscheidet. Stark heißt in diesem Zusammenhang, dass sich die Datei um mindestens ein vorgegebenes Maß von der zu aktualisierenden Datei unterscheidet. Die Datenbanksprache ist vorzugsweise SQL, kann jedoch auch eine alternative Datenbanksprache sein. Der Übertragungsbefehl ist vorzugsweise ein Kopierbefehl, bei dem die Quelldatei nicht zwingend erhalten bleiben muss. Vorzugsweise repräsentiert der Übertragungsbefehl eine Transaktion mit mehreren Unterschritten. Beispielsweise kann die zu aktualisierende Datei schrittweise mit der neuen Datei überschrieben werden.
In einer vorteilhaften Ausgestaltung des ersten Aspekts der Erfindung wird überprüft, wie stark sich die neue Datei von der zu aktualisierenden Datei unterscheidet. Die zu aktualisierende Datei wird nur dann mit der neuen Datei überschrieben, falls sich die neue Datei mindestens um ein vorgegebenes Maß von der zu aktualisierenden Datei unterscheidet. Die zu aktualisierende Datei wird auf der Speichervorrichtung belassen und aktualisiert abhängig von der neuen Datei, falls sich die neue Datei und die zu aktualisierende Datei höchstens oder genau um das vorgegebene Maß unterscheiden. Dies kann dazu beitragen, dass die zu aktualisierende Datei nur dann ganz durch die neue Datei ersetzt wird, wenn dies schneller und/oder Ressourcen sparender ist als die zu aktualisierende Datei abhängig von der neuen Datei zu aktualisieren. Das vorgegebene Maß kann beispielsweise abhängig von der zur Verfügung stehenden Hardware ermittelt werden.
In einer weiteren vorteilhaften Ausgestaltung des ersten Aspekts der Erfindung wird die zu aktualisierende Datei mit der neuen Datei überschrieben, wenn sich 20 Prozent oder mehr der neuen Datei von der zu aktualisierenden Datei unterscheiden. Dies kann dazu beitragen, dass die zu aktualisierende Datei nur dann ganz durch die neue Datei ersetzt wird, wenn dies schneller und/oder Ressourcen sparender ist als die zu aktualisierende Datei abhängig von der neuen Datei zu aktualisieren .
In einer weiteren vorteilhaften Ausgestaltung des ersten Aspekts der Erfindung umfasst die Datenbank zumindest eine erste und eine zweite zu aktualisierende Datei. Es wird überprüft, wie stark sich die erste beziehungsweise die zweite zu aktualisierende Datei von einer ersten beziehungsweise zweiten neuen Datei unterscheiden. Abhängig von dieser Überprüfung wird zumindest eine der beiden zu aktualisierenden Dateien mit der entsprechenden neuen Datei überschrieben. Die andere der beiden zu aktualisierenden Dateien wird lediglich auf der Speichervorrichtung aktualisiert. Dies ermöglicht die einfache, schnelle und/oder Ressourcen sparende Aktualisierung der Datenbank, wenn in einem Arbeitsgang mehrere Dateien aktualisiert werden und wenn sich die neuen Dateien unterschiedlich stark von den entsprechenden zu aktualisierenden Dateien unterscheiden.
In einer weiteren vorteilhaften Ausgestaltung des ersten Aspekts der Erfindung wird die zu aktualisierende Datei vor dem Überschreiben gesichert und/oder gelöscht. Die vorteilhaften Ausgestaltungen des Verfahrens können ohne weiteres auf vorteilhafte Ausgestaltungen der Vorrichtung übertragen werden.
Die Erfindung zeichnet sich aus gemäß eines zweiten Aspekts der Erfindung durch ein Computerprogrammprodukt, das ein computerlesbares Speichermedium mit Programmanweisungen umfasst. Die Programmanweisungen sind zum Durchführen des im Vorangehenden erläuterten Verfahrens ausgebildet.
Die Erfindung ist im Folgenden anhand von schematischen Zeichnungen näher erläutert.
Es zeigen:
Figur 1 ein Datenbanksystem,
Figur 2 eine zu aktualisierende und eine neue Datenbank und
Figur 3 ein Ablaufdiagramm eines Programms zum Aktualisieren der Datenbank.
Elemente gleicher Konstruktion oder Funktion sind figurenübergreifend mit den gleichen Bezugszeichen gekennzeichnet.
Ein Datenbanksystem (Figur 1) umfasst ein Datenbankverwaltungssystem 2 und eine Datenbank 4. Die Datenbank 4 umfasst zumindest eine Datei. Die Datei ist auf einer Speichervorrichtung eines Rechners gespeichert. Vorzugsweise umfasst die Datenbank 4 mehrere Dateien, die auf der Speichervorrichtung oder mehreren weiteren Speichervorrichtungen abgespeichert sind. Vorzugsweise umfasst jede Datei zumindest einen Block, der vorzugsweise 1024 Bytes umfasst. Die Speichervorrichtung umfasst vorzugsweise eine Festplattenspeichereinheit . Alternativ oder zusätzlich kann die Speichervorrichtung einen mobilen Datenträger umfassen. Das Datenbanksystem und/oder insbesondere die Datenbank 4 können ein relationales Datenbank- System bzw. eine relationale Datenbank 4 und/oder ein proprietäres Datenbanksystem bzw. eine proprietäre Datenbank 4 umfassen.
Das Datenbankverwaltungssystem 2 ist ausgebildet zum Verwalten von Daten, die in der Datenbank 4, insbesondere auf der Speichervorrichtung abgespeichert sind. Das Datenbankverwaltungssystem 2 umfasst eine Nutzerschnittstelle IF, einen SQL- Befehls-Prozessor SQL_CMD_PRO, einen Pager PAGER, ein Verzeichnis ID_LIB von Indexstrukturen und eine Betriebssystemschnittstelle OS IF. Das Datenbankverwaltungssystem 2 kommuniziert mit der Datenbank 4. Alternativ zu dem SQL-Befehls- Prozessor SQL CMD PRO kann ein alternatives Programmmodul verwendet werden. Beispielsweise kann das alternative Programmmodul abhängig von der verwendeten Programmiersprache ausgewählt werden. Ferner kann, falls das Datenbanksystem das proprietäre Datenbanksystem bzw. die proprietäre Datenbank 4 umfasst, alternativ zu dem SQL-Befehls-Prozessor SQL_CMD_PRO ein proprietäres Programmmodul vorgesehen sein.
Die Nutzerschnittstelle IF umfasst vorzugsweise Eingabe- und Ausgabeeinheiten, durch die Befehlszeilen in das Datenbankverwaltungssystem 2 eingegeben werden können. Die Befehlszeilen werden vorzugsweise in einer Datenbanksprache geschrieben, vorzugsweise in SQL. Die Nutzerschnittstelle IF leitet die geschriebenen Befehlszeilen an den SQL-Befehls-Prozessor SQL_CMD_PRO weiter.
Der SQL-Befehls-Prozessor SQL_CMD_PRO ermittelt abhängig von den Befehlszeilen und vorzugsweise abhängig von mindestens einer verfügbaren Indexstruktur, die in dem Verzeichnis ID_LIB der Indexstrukturen hinterlegt ist, einen Software- Ausführungsplan. Der Software-Ausführungsplan ist ein Programmabschnitt, der dazu dient, den Zugriff auf die Daten möglichst effizient zu gestalten. Der Software-Ausführungsplan wird von dem SQL-Befehls- Prozessor SQL_CMD_PRO an den Pager PAGER übergeben. Der Pager PAGER dient dazu, abhängig von dem Software-Ausführungsplan einen Hardware-Ausführungsplan zu ermitteln. Der Hardware- Ausführungsplan ist repräsentativ dafür, wie eine Hardware, beispielsweise die Festplattenspeichereinheit und/oder der mobile Datenträger, die die Datenbank 4 umfassen können, angesteuert werden müssen, um den Software-Ausführungsplan abzuarbeiten .
Der Hardware-Ausführungsplan wird an die Betriebssystem- Schnittstelle OS_IF übergeben, welche den Hardware- Ausführungsplan in entsprechende Stellsignale für die Speichervorrichtung umsetzt, auf der die Daten gespeichert sind.
Vorzugsweise ist das Datenbankverwaltungssystem 2 auf einer Speichervorrichtung eines Navigationssystems gespeichert. Alternativ dazu kann das Datenbankverwaltungssystem 2 auch unabhängig von dem Navigationssystem verwendet werden. Beispielsweise kann das Datenbankverwaltungssystem 2 auf einem Rechner gespeichert sein und beispielsweise zum Verwalten von Musikdaten verwendet werden. Ferner ist vorzugsweise die Datenbank 4, insbesondere eine Datei der Datenbank 4 auf einer Speichervorrichtung des Navigationssystems gespeichert. In diesem Zusammenhang umfasst die Datenbank 4 vorzugsweise eine Datei POI interessanter Orte, eine Datei 2D für zweidimensionale Landkartendaten, eine Datei 3D für dreidimensionale Landkartendaten und/oder eine Routendatei ROUTE für Daten zum Finden von Routen.
Die interessante Orte, die Landkartendaten und/oder die Routendaten können sich im Laufe der Zeit ändern. Daher ist es regelmäßig notwendig, veraltete Dateien zu aktualisieren. Zum Aktualisieren einer zu aktualisierenden Datei OLD_FILE hat das Datenbankverwaltungssystem grundsätzlich zwei unterschiedliche Möglichkeiten (Figur 3) . Eine erste Möglichkeit ist, mittels eines Aktualisierungsbefehls SQL_UPD (Figur 2), der in der Datenbanksprache verfasst ist, die zu aktualisierenden Elemente der zu aktualisierenden Datei OLD_FILE zu suchen und durch aktuelle Elemente einer aktuellen Datei NEW FILE zu ersetzen. Dies ist besonders dann vorteilhaft, wenn sich die neue Datei NEW_FILE nur geringfügig von der zu aktualisierenden Datei OLD FILE unterscheidet. Geringfügig bedeutet in diesem Zusammenhang, dass sich die zu aktualisierende Datei OLD FILE höchstens um ein vorgegebenes Maß von der neuen Datei NEW_FILE unterscheidet.
Eine zweite Möglichkeit besteht darin, dass abhängig von einem Übertragungsbefehl SQL COPY, der in der Datenbanksprache verfasst ist, die zu aktualisierende Datei OLD_FILE mit der neuen Datei NEW FILE mit den aktuellen Daten überschrieben wird. Der Übertragungsbefehl SQL_COPY ist vorzugsweise ein Kopierbefehl. Allerdings ist es in diesem Zusammenhang nicht nötig, dass die Quelldatei nach dem Kopiervorgang noch auf einer entsprechenden Quellspeichervorrichtung vorhanden ist. Vorzugsweise wird die zu aktualisierende Datei OLD_FILE vor dem Überschreiben gesichert. Nach dem Sichern der zu aktualisierenden Datei OLD_FILE kann die zu aktualisierende Datei OLD FILE von der Speichervorrichtung gelöscht oder direkt überschrieben werden.
Der Aktualisierungsbefehl SQL_UPD und der Übertragungsbefehl SQL COPY sind vorzugsweise repräsentativ für jeweils eine Transaktion. Die Transaktionen umfassen vorzugsweise Unterschritte. Beispielsweise kann die zu aktualisierende Datei OLD_FILE blockweise, beispielsweise immer ein Block der zu aktualisierenden Datei OLD FILE mit 1024 Bytes auf einmal, aktualisiert bzw. überschrieben werden. Ferner kann die zu aktualisierende Datei OLD FILE vor dem Überschreiben gesichert werden, insbesondere kann die zu aktualisierende Datei OLD FILE blockweise gesichert und/oder werden. Das vorgegebene Maß wird vorzugsweise empirisch ermittelt. Dazu kann beispielsweise auf dem Navigationsgerät die zu aktualisierende Datei OLD FILE abhängig von unterschiedlich stark veränderten Dateien aktualisiert werden und erste Zeitdauern ermittelt werden, die zu dieser Aktualisierung benötigt werden. Zusätzlich zu den ersten Zeitdauern werden vorzugsweise zweite Zeitdauern ermittelt, die benötigt werden, um die zu aktualisierende Datei OLD_FILE mit den unterschiedlich stark veränderten Dateien zu überschreiben. Je größer die Unterschiede zwischen der zu aktualisierenden Datei OLD FILE und den unterschiedlich stark veränderten Dateien sind, desto mehr rentiert sich in der Regel die zu aktualisierende Datei OLD FILE mit der entsprechenden unterschiedlich stark veränderten Datei, insbesondere der neuen Datei NEW FILE zu überschreiben. Die erste und die zweite Zeitdauer können dann herangezogen werden, um das geeignete vorgegebene Maß zu finden.
Das vorgegebene Maß kann beispielsweise zwischen zehn und dreißig Prozent sein. Das bedeutet in diesem Zusammenhang, dass die zu aktualisierende Datei OLD FILE lediglich dann gelöscht und durch die neue Datei NEW_FILE ersetzt wird, wenn sich die neue Datei NEW FILE um zehn bis dreißig Prozent von der zu aktualisierenden Datei OLD_FILE unterscheidet.
Falls die Datenbank 4 beispielsweise eine zu aktualisierende Datenbank 6 umfasst und die zu aktualisierende Datenbank 6 eine Datei POI interessanter Orte umfasst, die sich über das vorgegebene Maß hinaus von einer neuen Datei POI der interessanten Orte unterscheidet, so wird sie vorzugsweise mittels des Übertragungsbefehls SQL COPY durch die neue Datei POI interessanter Orte ersetzt. Falls sich bei derselben Aktualisierung die zu aktualisierende Routendatei ROUTE der zu aktualisierenden Datenbank 6 um weniger als das vorgegebene Maß von der neuen Routendatei ROUTE unterscheidet, so wird die zu aktualisierende Routendatei ROUTE mittels des Aktualisierungsbefehls SQL UPD aktualisiert. Vorzugsweise ist auf der Speichervorrichtung des Navigationssystems ein Programm zum Aktualisieren der Datenbank 4 abgespeichert. Ein Rechner, insbesondere das Navigationssystem, auf dem das Datenbankverwaltungssystem gespeichert ist, kann auch als Vorrichtung zum Aktualisieren der Datenbank bezeichnet werden. Das Programm zum Aktualisieren der Datenbank wird vorzugsweise in einem Schritt Sl gestartet, in dem gegebenenfalls Variablen initialisiert werden.
In einem Schritt S2 wird abhängig von der zu aktualisierenden Datei OLD_FILE und der neuen Datei NEW_FILE ein Unterschiedswert DELTA ermittelt, der repräsentativ dafür ist, wie stark sich die zu aktualisierende Datei OLD FILE von der neuen Datei NEW_FILE unterscheidet.
In einem Schritt S3 wird überprüft, ob der Unterschiedswert DELTA größer als ein vorgegebener Schwellenwert THD ist. Vorzugsweise repräsentiert der vorgegebene Schwellenwert THD das vorgegebene Maß. Ist die Bedingung des Schritts S3 erfüllt, so wird die Bearbeitung in einem Schritt S5 fortgesetzt. Ist die Bedingung des Schritts S3 nicht erfüllt, so wird die Bearbeitung in einem Schritt S4 fortgesetzt.
In dem Schritt S4 wird die zu aktualisierende Datei OLD_FILE mittels des Aktualisierungsbefehls SQL UPD aktualisiert und auf der Speichervorrichtung belassen.
In dem Schritt S5 wird die zu aktualisierende Datei OLD_FILE mittels eines Speicherbefehls SAVE gespeichert und so gesichert und/oder mittels eines Löschbefehls DEL gelöscht. Insbesondere kann in dem Schritt S5 ein Block der zu aktualisierenden Datei OLD_FILE gespeichert bzw. gesichert bzw. gelöscht werden.
In einem Schritt S6 wird die neue Datei NEW FILE mittels des Übertragungsbefehls SQL_COPY auf die Speichervorrichtung ü- bertragen und so die zu aktualisierende Datei OLD FILE über- schrieben, falls sie noch nicht in dem Schritt S6 gelöscht wurde. Alternativ dazu kann der Löschbefehl DEL von dem Übertragungsbefehl SQL COPY umfasst sein. Vorzugsweise ist der Übertragungsbefehl SQL_COPY ein Kopierbefehl, der automatisch die neue Datei NEW FILE anstelle der zu aktualisierenden Datei OLD_FILE abspeichert. Insbesondere kann in dem Schritt S6 ein Block der zu aktualisierenden Datei OLD FILE mit einem Block der neuen Datei NEW_FILE überschrieben werden.
In einem Schritt S7 kann das Programm beendet werden. Vorzugsweise wird das Programm für alle zu aktualisierende Dateien OLD_FILE der zu aktualisierenden Datenbank 6 erneut ausgehend von dem Schritt Sl abgearbeitet. Insbesondere kann das Programm für alle Blöcke der zu aktualisierenden Datei OLD FILE einzeln abgearbeitet werden.
Zusätzlich zu der Speichervorrichtung können das Programm zum Aktualisieren der Datenbank und/oder das Datenbankverwaltungssystem auf einer mobilen Speichereinheit abgespeichert sein. Die mobile Speichereinheit umfasst Programmanweisungen, die dazu ausgebildet sind, die zu aktualisierende Datenbank 6 zu aktualisieren. Die mobile Speichereinheit ist beispielsweise eine CD, DVD und/oder ein Speicherstick oder Flashspeicher .
Ein Vorteil des Aktualisierens der Datenbank 4 mittels des Aktualisierungsbefehls SQL_UPD ist, dass lediglich die tatsächlich aktualisierten Daten aktualisiert werden. Nach dem Aktualisieren können jedoch logisch zusammengehörende Daten, insbesondere alte und aktualisierte Daten, die logisch zusammenhängen, auf der Speichervorrichtung räumlich nicht mehr zusammenhängen. Im Gegensatz dazu bietet das Aktualisieren mittels des Übertragungsbefehls SQL_COPY den Vorteil, dass Daten, die logisch zusammengehören, auch räumlich und/oder physikalisch zusammenhängend auf der Speichervorrichtung abgespeichert werden können. Beispielsweise werden bevorzugt Kartenausschnitte, insbesondere die grafischen Daten zum Dar- stellen der Kartenausschnitte, räumlich und/oder physikalisch zusammenhängend auf der Speichervorrichtung abgespeichert, damit der entsprechende Kartenausschnitt schnell eingelesen werden kann. Dies wird vorzugsweise auch beim Erstellen der neuen Datei NEW FILE berücksichtigt. Im Gegensatz dazu können beim Aktualisieren des entsprechenden Kartenausschnitts mittels des Aktualisierungsbefehls SQL UPD Teile des Landkartenausschnitts an unterschiedlichen Stellen der Speichervorrichtung abgespeichert werden, insbesondere wenn nur ein Teil des entsprechenden Kartenausschnitts aktualisiert wird. Zum Darstellen des Landkartenausschnitts muss dann der Lesekopf der Speichervorrichtung an unterschiedlich weit auseinander liegende Stellen des Speichermediums der Speichervorrichtung gebracht werden. Dies kostet zusätzlich Zeit.
Die Erfindung ist nicht auf die angegebenen Ausführungsbeispiele beschränkt. Beispielsweise kann das Datenbanksystem unabhängig von dem Navigationssystem eingesetzt werden. Ferner kann die Datenbank weniger oder mehrere Dateien umfassen.

Claims

Patentansprüche
1. Verfahren zum Aktualisieren einer Datenbank (4) eines Datenbanksystems, das ein Datenbankverwaltungssystem (2) und die Datenbank (4) umfasst, wobei die Datenbank (4) zumindest eine zu aktualisierende Datei (OLD_FILE) umfasst, die auf einer Speichervorrichtung abgespeichert ist, bei dem die zu aktualisierende Datei (OLD_FILE) mit einer neuen Datei (NEW FILE) der Datenbank (4) mit aktuellen Daten überschrieben wird mittels eines Übertragungsbefehls (SQL COPY), der in einer Datenbanksprache des Datenbanksystems verfasst ist.
2. Verfahren nach Anspruch 1, bei dem a. überprüft wird, wie stark sich die neue Datei
(NEW_FILE) von der zu aktualisierenden Datei (OLD_FILE) unterscheidet, b. die zu aktualisierende Datei (OLD_FILE) nur dann mit der neuen Datei (NEW FILE) überschrieben wird, falls sich die neue Datei (NEW_FILE) mindestens um ein vorgegebenes Maß von der zu aktualisierenden Datei (OLD_FILE) unterscheidet, c. die zu aktualisierende Datei (OLD FILE) auf der Speichervorrichtung belassen und aktualisiert wird abhängig von der neuen Datei (NEW FILE) , falls sich die neue Datei (NEW_FILE) und die zu aktualisierende Datei (OLD FILE) höchstens oder genau um das vorgegebene Maß unterscheiden.
3. Verfahren nach einem der vorstehenden Ansprüche, bei dem die zu aktualisierende Datei (OLD FILE) gelöscht wird und bei dem die neue Datei (NEW_FILE) anstatt der zu aktualisierenden Datei (OLD FILE) auf die Speichervorrichtung übertragen wird, wenn sich zehn bis dreißig Prozent der neuen Datei (NEW FILE) von der zu aktualisierenden Datei
(OLD FILE) unterscheiden.
4. Verfahren nach einem der Ansprüche 2 oder 3, bei dem a. die Datenbank (4) zumindest eine erste und eine zweite zu aktualisierende Datei (OLD FILE) umfasst, b. überprüft wird, wie stark sich die erste bzw. die zweite zu aktualisierende Datei (OLD FILE) von einer ersten bzw. zweiten neuen Datei (NEW_FILE) unterscheiden, c. abhängig von dieser Überprüfung zumindest eine der beiden zu aktualisierenden Dateien (OLD FILE) durch die entsprechende neue Datei (NEW_FILE) überschrieben wird, wobei die andere der beiden zu aktualisierenden Dateien (OLD_FILE) lediglich auf der Speichervorrichtung aktualisiert wird.
5. Verfahren nach einem der vorstehenden Ansprüche, bei dem die zu aktualisierende Datei (OLD_FILE) vor dem Überschreiben gesichert und/oder gelöscht wird.
6. Vorrichtung zum Aktualisieren einer Datenbank (4) eines Datenbanksystems, das ein Datenbankverwaltungssystem (2) und die Datenbank (4) umfasst, wobei die Datenbank (4) zumindest eine zu aktualisierende Datei (OLD_FILE) umfasst, die auf einer Speichervorrichtung abgespeichert ist, wobei die Vorrichtung ausgebildet ist zum Überschreiben der zu aktualisierenden Datei (OLD FILE) mit einer neuen Datei (NEW_FILE) mittels eines Übertragungsbefehls (SQL COPY), der in einer Datenbanksprache des Datenbanksystems verfasst ist.
7. Computerprogrammprodukt, das ein computerlesbares Speichermedium mit Programmanweisungen umfasst, die zum Durchführen des Verfahrens gemäß einem der Ansprüche 1 bis 4 ausgebildet sind.
EP07857247A 2006-12-08 2007-12-04 Verfahren und vorrichtung zum aktualisieren einer datenbank und computerprogrammprodukt Withdrawn EP2054822A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102006057977A DE102006057977A1 (de) 2006-12-08 2006-12-08 Verfahren und Vorrichtung zum Aktualisieren einer Datenbank und Computerprogrammprodukt
PCT/EP2007/063262 WO2008068250A1 (de) 2006-12-08 2007-12-04 Verfahren und vorrichtung zum aktualisieren einer datenbank und computerprogrammprodukt

Publications (1)

Publication Number Publication Date
EP2054822A1 true EP2054822A1 (de) 2009-05-06

Family

ID=39059634

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07857247A Withdrawn EP2054822A1 (de) 2006-12-08 2007-12-04 Verfahren und vorrichtung zum aktualisieren einer datenbank und computerprogrammprodukt

Country Status (4)

Country Link
US (1) US20100094804A1 (de)
EP (1) EP2054822A1 (de)
DE (1) DE102006057977A1 (de)
WO (1) WO2008068250A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10289636B2 (en) * 2010-02-08 2019-05-14 Here Global B.V. Virtual table generator for analyzing geographic databases
US8756261B2 (en) 2010-07-09 2014-06-17 Navteq B.V. Method and system for handling binary large objects

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5729743A (en) * 1995-11-17 1998-03-17 Deltatech Research, Inc. Computer apparatus and method for merging system deltas
DE19628168A1 (de) * 1996-07-12 1998-01-22 Ibm Vernetztes multimediales Netz
KR19980024086A (ko) * 1996-09-03 1998-07-06 니시무로 타이조 컴퓨터 시스템 및 화일 관리 방법
US5999947A (en) * 1997-05-27 1999-12-07 Arkona, Llc Distributing database differences corresponding to database change events made to a database table located on a server computer
US7243136B2 (en) * 2000-01-18 2007-07-10 Inktomi Corporation Approach for managing and providing content to users
US20020112237A1 (en) * 2000-04-10 2002-08-15 Kelts Brett R. System and method for providing an interactive display interface for information objects
US7277901B2 (en) * 2003-07-10 2007-10-02 Tacit Networks, Inc. Collaborative file update system
EP1574952B1 (de) * 2004-03-10 2008-04-16 Sony Ericsson Mobile Communications AB Automatisierter Datensicherungsspeicher in Firmware-Aufwertungen
US7801882B2 (en) * 2004-10-01 2010-09-21 Microsoft Corporation Optimized constraint and index maintenance for non updating updates
US7401192B2 (en) * 2004-10-04 2008-07-15 International Business Machines Corporation Method of replicating a file using a base, delta, and reference file

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
BURNS R ET AL: "Version management and recoverability for large object data", MULTI-MEDIA DATABASE MANAGEMENT SYSTEMS, 1998. PROCEEDINGS. INTERNATIO NAL WORKSHOP ON DAYTON, OH, USA 5-7 AUG. 1998, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 5 August 1998 (1998-08-05), pages 12 - 19, XP010298806, ISBN: 978-0-8186-8676-4, DOI: DOI:10.1109/MMDBMS.1998.709474 *
CHAMBERLIN D D ED - CHAMBERLIN D D: "A Complete Guide to DB2 Universal Database, Chapter 10.7 , MOVING DATA IN BULK", 1 January 1998, A COMPLETE GUIDE TO DB2 UNIVERSAL DATABASE; [THE MORGAN KAUFMANN SERIES IN DATA MANAGEMENT SYSTEMS], SAN FRANCISCO, CALIF. : MORGAN KAUFMANN, USA, PAGE(S) 643 - 658, ISBN: 978-1-55860-482-7, XP002515084 *
See also references of WO2008068250A1 *

Also Published As

Publication number Publication date
DE102006057977A1 (de) 2008-06-12
WO2008068250A1 (de) 2008-06-12
US20100094804A1 (en) 2010-04-15

Similar Documents

Publication Publication Date Title
DE102013215535B4 (de) Sicherung oder wiederherstellung von daten mit hilfe eines hauptspeichers und nichtflüchtiger speichermedien
DE69622253T2 (de) System und verfahren für on-line- und echzeit-datenmigration
DE69821844T2 (de) Verfahren zur automatischen Installierung und übertragung von Daten auf ein Rechnerplattenlaufwerk
DE69516538T2 (de) Speicherung von rechnerdaten
DE102020112512A1 (de) Datenspeichergerät und Betriebsverfahren dafür
DE112020005787T5 (de) Verbesserte dateisystem-unterstützung für zonen-namespace-speicher
DE202010017613U1 (de) Datenspeichervorrichtung mit host-gesteuerter Speicherbereinigung
DE102011086098A1 (de) Parallele Speicherlese- und Speicherschreib-Operationen in einem Speicher mit serieller Schnittstelle
DE102008057219A1 (de) Verfahren zum Betreiben eines Solid-State-Speichersystems, Solid-State-Speichersystem und Computersystem
DE102012208141A1 (de) Ausgleich nachlassender Funktionsfähigkeit
DE202010017644U1 (de) Hybridspeichervorrichtung
DE102016010277A1 (de) Verfahren und systeme zum verbessern von speicher-journaling
DE102019102861B4 (de) Verfahren und Vorrichtung zur Abschätzung der Abnutzung eines nicht-flüchtigen Informationsspeichers
DE112021005198B4 (de) Hochauflösendes Bandverzeichnis für bandgestützte Speicherung
DE112004001255T5 (de) Speichervorrichtung und Speichersystem
DE102020126409A1 (de) Speichervorrichtung zum Speichern von Modellinformationen, die Speichervorrichtung enthaltendes Speichersystem und Betriebsverfahren des Speichersystems
DE112010004264B4 (de) Selektiver Schreibschutz für das Austesten der Wiederherstellung nach einem Absturz
EP1067460B1 (de) Datenträger mit wiederherstellbarem Basisdatengrundzustand und Verfahren zu dessen Herstellung
DE112012004297B4 (de) Verfahren zum Erkennen von Datenmanipulationen in einem Bandlaufwerk und Dateisystem
DE112018005768T5 (de) Copy-source-to-target-verwaltung in einem datenspeichersystem
DE102005037855A1 (de) System und Verfahren zum Speichern von Benutzerdaten in einer Partitionsdatei oder zum Verwenden einer Partitionsdatei, die Benutzerdaten enthält
WO2008068250A1 (de) Verfahren und vorrichtung zum aktualisieren einer datenbank und computerprogrammprodukt
EP2948894B1 (de) Verfahren zum sicheren löschen eines nichtflüchtigen halbleiter-massenspeichers, computersystem sowie computerprogrammprodukt
DE60210118T2 (de) Sicherheitseinrichtung für eine massenspeicherung
DE60226276T2 (de) Verfahren und anordnung zum modifizieren des inhalts eines korrekturidentifikationsregisters

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20090323

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK RS

17Q First examination report despatched

Effective date: 20090731

RIN1 Information on inventor provided before grant (corrected)

Inventor name: TANTZ, UWE

Inventor name: SUH, JONG-HYUN

Inventor name: SASSE, VOLKER

Inventor name: PFEIFLE, MARTIN

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FR GB

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20110823