EP2370915A1 - Infotainmentsystem und computerprogrammprodukt - Google Patents

Infotainmentsystem und computerprogrammprodukt

Info

Publication number
EP2370915A1
EP2370915A1 EP09764209A EP09764209A EP2370915A1 EP 2370915 A1 EP2370915 A1 EP 2370915A1 EP 09764209 A EP09764209 A EP 09764209A EP 09764209 A EP09764209 A EP 09764209A EP 2370915 A1 EP2370915 A1 EP 2370915A1
Authority
EP
European Patent Office
Prior art keywords
sub
identifier
properties
property
infotainment
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.)
Ceased
Application number
EP09764209A
Other languages
English (en)
French (fr)
Inventor
Martin Pfeifle
Kurt Stege
Steffen Zehner
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 EP2370915A1 publication Critical patent/EP2370915A1/de
Ceased 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/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2237—Vectors, bitmaps or matrices

Definitions

  • the invention relates to an infotainment system and a computer program product for operating the infotainment system.
  • Infotainment systems are installed, for example, in modern motor vehicles and combine the transmission of information, such.
  • the storage and management of this so-called infotainment data is preferably carried out by means of a database system.
  • a modern database system regularly includes a database and a database management system.
  • the data is stored in the database.
  • the database management system is provided for managing the data in the database.
  • the management of the database may include, for example, searching, reading and / or writing data in the database.
  • outdated data may be updated by an update command that includes a combination of search, read, and / or write commands.
  • the object of the invention is to provide an infotainment system and a computer program product for operating the infotainment system, which enables efficient storage of infotainment data.
  • the invention is characterized, in a first aspect, by an infotainment system comprising a relational database stored on a storage medium and a data storage system. bank management system.
  • the database management system is configured to access infotainment data stored in the relational database as data records.
  • a data record has a respective identification value of a unique identifier, property values of several properties and at least one sub-identifier value of at least one subrecognition. All or at least one of the plurality of properties and one of the at least one sub-identifier are associated with at least one sub-table.
  • the unique identifier, the remaining of the multiple properties, and the at least one associated sub-identifier are associated with at least one main table.
  • Tuples of the property values of the properties assigned to the respective sub-table are only stored once in the respective subtable.
  • the multiple properties are functionally independent. This contributes to the fact that tuples of the property values of the properties of the respective sub-table are stored only once in each sub-table. That is, a respective combination of property values associated with each tuple is stored only once in each sub-table. This helps to reduce redundancy of property values in the respective sub-table.
  • a table normalized according to the third normal form there is no functional dependency between the properties assigned to the table, ie it is not possible to unambiguously conclude a property value of a property for a property value of another property. The unique identifier and subrecognition are not considered as a property. Tables that are already normalized to the third normal form of database theory may have redundancies of tuples of property values.
  • the at least one main table preferably has at least one unique identifier and at least one sub-identifier.
  • the at least one subtable has at least one of the at least one subkey on.
  • the at least one main table and the at least one subtable each have columns and rows. Each column is assigned to a property or the unique identifier or the at least one subrecognition.
  • Main table and an associated row of at least one subtable form a record.
  • the respective sub-recognition value of the at least one sub-identifier represents in each case a reference of the respective line of the at least one main table to the assigned respective line of the respective sub-table.
  • a tuple denotes a combination of property values that are assigned to a row of the respective subtable. Tuples of the property values may include one or more property values associated with a row of the respective subtable.
  • a combination of property values, each associated with a row occurs only once in the at least one subtable.
  • the data records can be stored on the storage medium of the relational database in a particularly efficient manner and with a small storage space requirement.
  • a redundancy of property values associated with a property may still exist.
  • the number of sub-tables is as small as possible in order to minimize the additional memory requirement, which is present due to the at least one sub-identifier.
  • the relational database and the database management system can be integrated, for example, as a functional unit in the infotainment system of a motor vehicle, the infotainment system in the motor vehicle preferably being referred to as an embedded system is formed. In principle, however, it is also possible that the relational database and the database management system are designed as separate functional units in the infotainment system.
  • the database management system is designed to access the at least one sub-table and to reconstruct at least one of the data records depending on the at least one sub-identifier and the property values stored in the at least one sub-table.
  • the database management system is designed to first access the respective sub-table when specifying a property value of one of the properties associated with the at least one sub-table.
  • the database management system is designed to compare the predetermined property value with the stored property values of the respective properties and, depending on the comparison, to determine at least one sub-identifier value of at least one assigned sub-identifier. Depending on this, at least one of the data records is determined.
  • an instruction calculation unit of the database management system is preferably designed to interpret the predefined statement in such a way that the at least one sub-table is first accessed to determine the at least one sub-identifier value of the at least one sub-identifier.
  • the at least one sub-identification value is determined by means of the comparison of the predetermined property value with the stored property values of the respective properties if the sub-table has a few lines.
  • the infotainment system has at least one index structure that includes references to storage locations of the property values of the respective property that is assigned to the respective sub-table.
  • the database administration system is designed to first access the respective index structure and to compare the predetermined property value with the property values of the respective properties stored in the index structure.
  • the database management system is also designed to determine at least one sub-identifier value of at least one assigned sub-identifier, depending on the comparison. Depending on this, at least one of the data records is determined.
  • the index structure allows particularly fast access to the respective property values of the sub-table on the storage medium, in particular if the subtable has particularly many lines.
  • the predetermined instruction is designed as an SQL statement. This allows a particularly fast read and / or write access to the infotainment data in the relational database.
  • the invention is characterized in terms of a second aspect by a computer program product.
  • the computer program Product includes a computer readable medium with program instructions.
  • the program instructions are executable by a computer.
  • the program instructions are designed to operate the infotainment system according to the first aspect of the invention.
  • FIG. 1 shows a database system
  • FIG. 2 an original table
  • FIG. 3 shows a main table and a sub-table
  • FIG. 4 shows a further main and further sub-tables.
  • An infotainment system (FIG. 1) comprises an infotainment unit INFO, a database management system RDBMS and a relational database RDB.
  • the infotainment system can for example comprise a navigation unit and thus serves to find a predefined route and / or to calculate a predefined route and / or to find a predefined location and / or to determine further information.
  • the infotainment system may additionally or alternatively also include a music system and be designed to find and play predetermined music pieces, for example.
  • the infotainment unit INFO, the relational database RDB and the database management system RDBMS can also be embodied as software function units in the infotainment system.
  • the infotainment system for example, a
  • the infotainment system preferably has at least one input unit which serves to input information, for example a route and / or a piece of music, which are to be determined, and / or information on the basis of which infotainment data are changed, in particular updated.
  • the infotainment unit INFO, the relational database RDB and the database management system RDBMS can be integrated as a functional unit in the infotainment system or as distributed functional units.
  • the infotainment unit INFO communicates with the database management system RDBMS.
  • the database management system RDBMS comprises an instruction interface SQL_IF, a statement processing unit SQL_CMD_PRO, a pager PAGER, a directory ID_LIB of index structures, and an operating system interface OS_IF.
  • the database management system RDBMS communicates with the relational database RDB.
  • the infotainment data e.g. Navigation data and / or music data stored.
  • the infotainment unit INFO preferably communicates with the database management system RDBMS in such a way that the infotainment unit INFO sends an instruction SQL_CMD to the database management system RDBMS.
  • the statement SQL_CMD can also be represented by suitable signals, which are then translated in the database management system RDBMS into the corresponding statement SQL_CMD.
  • the statement SQL CMD is designed as an SQL statement.
  • the SQL IF statement interface is used to verify that the SQL_CMD statement is syntactically correct. If the SQL CMD statement is syntactically correct, it will be parsed by the
  • Statement interface SQL_IF passed to the statement calculation unit SQL CMD PRO.
  • the instruction calculation unit SQL CMD PRO preferably determines a software execution plan depending on the statement SQL_CMD and preferably on the basis of at least one available index structure, which is stored in the index structure directory ID_LIB.
  • the software execution plan is a section of the program that serves to make access to the infotainment data as efficient as possible.
  • the software execution plan is passed from the statement calculation unit SQL_CMD_PRO to the pager PAGER.
  • the pager PAGER serves to determine a hardware execution plan, depending on the software execution plan.
  • the hardware execution plan is representative of how a hardware, such as a CD-ROM drive and / or a hard disk and / or other data carriers, which may include the relational database RDB, must be driven to execute the software execution plan.
  • the hardware execution plan is transferred to the operating system interface OS_IF, which translates the hardware execution plan into corresponding setting signals for the technical device on which the infotainment data are stored, and / or which comprises the storage medium on which the infotainment data are stored.
  • the infotainment data are stored in the relational database RDB as data records in tables.
  • FIG. 2 shows an original table R which has ten data sets.
  • Each data record is represented by an identification value of a unique identifier PK and additionally comprises five property values a-e of different properties A-E.
  • the properties AE of the respective data records are indicated in capital letters, while property values ae of the properties AE are indicated in lower case letters.
  • Egg- Each property is assigned a column.
  • a row of the at least one main table and an associated row of the at least one subtable constitute a data record.
  • the properties A-E of the original table R are functionally independent of each other and are normalized according to the third normal form.
  • FIG. 2 indicates that the same property values a-e are stored in the different data sets for the plurality of properties A-E.
  • the property value el of the property E of the first data set is identical to the property value el of the property E of the second through the fourth data set.
  • further redundancies of property values in the original table R are indicated in FIG. 2, wherein not all redundancies are identified.
  • a data record of the original table R is divided into a main data record in a main table MR and to a sub-data record in a first sub-table PR1.
  • the main table MR includes the unique identifier PK and the properties A and C, as well as a first subcode PID1.
  • the first sub-table PR1 comprises the first sub-identifier PID1 and the properties B, D, E associated with this identifier of the original table R, wherein a respective tuple of the property values b, d, e, which are each associated with one row of the first sub-table PR1, only in each case once stored in the first sub-table PRl.
  • the tuple of the property values b5, d5, e5 of the properties B, D, E is stored only once in the first sub-table PR1
  • this tuple of the property values b5, d5, e5 is stored five times, although the original table R is normalized according to the third normal form.
  • a redundancy of property values of one property is still present in the first th sub-table PRl available, such.
  • the property value el is stored three times in the first sub-table PR1.
  • the respective sub-table can have such a small memory requirement that, for example, the respective sub-table can be temporarily stored in a cache memory of the database management system RDBMS or the relational database RDB and thus can be accessed particularly quickly. This allows a particularly efficient access to the property values of the respective sub-table.
  • the respective sub-identifier value of the first sub-identifier PID1 represents the respective sub-data record in the first sub-table PR1 and makes it possible to refer the respective sub-data record from the main data record associated therewith in the main table MR.
  • SQL CMD SQL CMD
  • the database management system RDBMS in particular the instruction calculation unit SQL_CMD_PRO of the database management system RDBMS, is preferably configured first to the first sub-table PR1 access.
  • the predetermined property value is compared with the eigenvalue stored in the first sub-table PR1.
  • values b, d, e and dependent thereon determines one or more associated sub-identification values of the first sub-identifiers PID1.
  • the at least one determined sub-recognition value of the first sub-identifier PID1 is representative of at least one data record which has the predetermined property value of the property B, D, E.
  • the main data records in the main table MR can then be accessed particularly efficiently.
  • the index structure for the first subtable PR1 may be created in the ID_LIB directory of index structures.
  • the index structure then preferably references the storage locations of the sub-identification values of the first sub-IDs PID1 of the first sub-table PR1. If, for example, all the property values a of the property A are searched for, to which the predetermined property value bl of the property B is assigned, then, for example, by means of the statement SQL_CMD
  • a data record of the original table R is divided into the main data record of the main table MR and to the sub-data record of the first sub-table PR1 and to another sub-data record of a second sub-table PR2.
  • the main table MR additionally comprises a second sub-identifier PID2 in addition to the first sub-identifier PID1.
  • the property values b of the property B of the first sub-table PR1 can be referenced by means of the respective sub-recognition value of the first sub-identifier PID1.
  • the property values d, e of the properties D, E of the second sub-table PR2 can be referenced by means of the respective sub-identifier value of the second sub-identifier PID2.
  • the first algorithm explains the determination of a subtable as used in Figs. 3a and 3b.
  • n 'of property values of the given combination of the properties Al, A3, A5 in the original table RX lie.
  • r represents the memory requirement of the respective subrecognition, e.g. 8 bytes.
  • the first term o * s * (n-n ') represents the amount of bytes saved for the particular combination of properties being considered.
  • the second term r * (n + n ') then represents the additionally required memory requirement, which is required due to the additional sub-IDs and which is to be deducted from the memory space saved.
  • the calculation shown is calculated for each of the 2 ° possible combinations of properties.
  • the combination of properties with the highest memory space savings is then preferably assigned to the subtable.
  • this sub-table then also has an optimum number of rows and columns.
  • the second algorithm explains the detection of several sub-tables as used in FIG.
  • the following algorithm does not determine the combinations of properties with the least amount of memory, but rather combinations of properties that allow a reasonable reduction in memory requirements.
  • the saved memory space can be calculated in bytes of each property, where s, n, n ', and r have the same meaning as in the first algorithm.
  • an attempt is made to merge two property pairs to form a property triplet. If, for example, the two property pairs Ai, Aj and Ak, Aj are present, then it can be checked whether the property triplet Ai, Aj, Ak saves more storage space than the associated property pairs Ai, Aj and Ak, Aj.
  • two property striplets are combined into a property tuple of length 4 and evaluated. If, for example, the two property strips Ai, Aj, Ak and Ai, Aj, Al are present, then it can be checked whether the property tuple of length 4 Ai, Aj, Ak, Al saves more memory space than the associated property strips Ai, Aj, Ak and Ai, Aj, Al.
  • the further merger can be operated to property stubs of predetermined length until a further saving of storage space can no longer be determined.
  • the first way of combining properties on the list, while preserving the highest memory space can be assigned directly to a first subtable.
  • the second possibility following the first possibility of the combination of properties on the list is determined, which has not been canceled.
  • the second possibility of the combination is assigned to a second subtable and again all list entries are deleted, which have at least one property, which is also contained in the second possibility of the combination of properties.
  • the second algorithm can be used to determine several sub-tables with different numbers of different properties, which enable a particularly efficient storage of property values in the relational database RDB.
  • the property 'speed_limit' (speed limitation), according to experience, allows only relatively few property values, for example 50, 60, 70, 80, 100, 120 km / h, or the property 'urban' preferably as eigenvalue. values only yes or no, or the property 'functional_road_class', for example motorway, main road, etc., allows as possible property values, these properties are particularly suitable for being assigned to one or more sub-tables. This allows a particularly efficient storage of these property values in the relational database RDB.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (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

Infotainmentsystem, das umfasst eine relationale Datenbank (RDB) und ein Datenbankverwaltungssystem (RDBMS) und ausgebildet ist, auf Infotainmentdaten zu zugreifen, die in der relationalen Datenbank (RDB) als Datensätze gespeichert sind. Ein Datensatz weist jeweils einen Kennungswert einer eindeutigen Kennung (PK), Eigenschaftswerte (a-e) mehrerer Eigenschaften (A-E) und zumindest einen Unterkennungswert zumindest einer Unterkennung (PID1, PID2) auf. Alle oder zumindest einer der mehreren Eigenschaften (A-E) und eine der zumindest einen Unterkennung (PID1, PID2) sind zumindest einer Untertabelle (PR1, PR2) zugeordnet. Die eindeutige Kennung (PK), die verbleibenden der mehreren Eigenschaften (A-E) und die zumindest eine zugeordnete Unterkennung (PID1, PID2) sind zumindest einer Haupttabelle (MR) zugeordnet. Tupel der Eigenschaftswerte (a-e) der Eigenschaften (A-E), die jeweils einem Datensatz und die der jeweiligen Untertabelle (PR1, PR2) zugeordnet sind, sind nur jeweils einmal in der jeweiligen Untertabelle (PR1, PR2) gespeichert. Die mehreren Eigenschaften (A-E) sind funktional unabhängig voneinander.

Description

Beschreibung
Infotainmentsystem und Computerprogrammprodukt
Die Erfindung betrifft ein Infotainmentsystem und ein Computerprogrammprodukt zum Betreiben des Infotainmentsystems .
Infotainmentsysteme sind beispielsweise in modernen Kraftfahrzeugen eingebaut und verknüpfen die Vermittlung von In- formationen, so z. B. Navigationsdaten, und von Unterhaltungsdaten, so z. B. TV- oder Musikdaten. Die Speicherung und Verwaltung dieser sogenannten Infotainmentdaten erfolgt vorzugsweise mittels eines Datenbanksystems.
Ein modernes Datenbanksystem umfasst regelmäßig eine Datenbank und ein Datenbankverwaltungssystem. In der Datenbank sind die Daten gespeichert. Das Datenbankverwaltungssystem ist vorgesehen zum Verwalten der Daten in der Datenbank. Das Verwalten der Datenbank kann beispielsweise ein Suchen, ein Lesen und/oder ein Schreiben von Daten in der Datenbank umfassen. Insbesondere können nicht mehr aktuelle Daten aktualisiert werden durch einen Aktualisierungsbefehl, der eine Kombination aus Such-, Lese- und/oder Schreibbefehlen umfasst .
Aufgabe der Erfindung ist es, ein Infotainmentsystem und ein Computerprogrammprodukt zum Betreiben des Infotainmentsystems zu schaffen, das eine effiziente Speicherung von Infotain- mentdaten 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 bezüglich einem ersten Aspekt aus durch ein Infotainmentsystem, das eine relationale Datenbank, die auf einem Speichermedium gespeichert ist, und ein Daten- bankverwaltungssystem umfasst. Das Datenbankverwaltungssystem ist ausgebildet, auf Infotainmentdaten zu zugreifen, die in der relationalen Datenbank als Datensätze abgespeichert sind. Ein Datensatz weist einen jeweiligen Kennungswert einer ein- deutigen Kennung, Eigenschaftswerte mehrerer Eigenschaften und zumindest einen Unterkennungswert zumindest einer Unter- kennung auf. Alle oder zumindest einer der mehreren Eigenschaften und eine der zumindest einen Unterkennung sind zumindest einer Untertabelle zugeordnet. Die eindeutige Ken- nung, die verbleibenden der mehreren Eigenschaften und die zumindest eine zugeordnete Unterkennung sind zumindest einer Haupttabelle zugeordnet. Tupel der Eigenschaftswerte der Eigenschaften, die der jeweiligen Untertabelle zugeordnet sind, sind jeweils nur einmal in der jeweiligen Untertabelle ge- speichert. Die mehreren Eigenschaften sind funktional unabhängig voneinander. Dies trägt dazu bei, dass Tupel der Eigenschaftswerte der Eigenschaften der jeweiligen Untertabelle nur jeweils einmal in der jeweiligen Untertabelle gespeichert sind. D.h. eine jeweilige Kombination von Eigenschaftswerten, die dem jeweiligen Tupel zugeordnet sind, ist nur jeweils einmal in der jeweiligen Untertabelle gespeichert. Dies trägt dazu bei, Redundanzen von Eigenschaftswerten in der jeweiligen Untertabelle zu reduzieren. In einer Tabelle, die gemäß der dritten Normalform normalisiert ist, besteht keine funk- tionale Abhängigkeit zwischen den Eigenschaften, die der Tabelle zugeordnet sind, d.h. es kann von einem Eigenschaftswert einer Eigenschaft nicht eindeutig auf einen Eigenschaftswert einer anderen Eigenschaft geschlossen werden. Dabei werden die eindeutige Kennung und die Unterkennung nicht als Eigenschaft betrachtet. Tabellen, die bereits nach der dritten Normalform der Datenbanktheorie normalisiert sind, können Redundanzen von Tupeln von Eigenschaftswerten aufweisen .
Die zumindest eine Haupttabelle weist vorzugsweise zumindest eine eindeutige Kennung und zumindest eine Unterkennung auf. Die zumindest eine Untertabelle weist zumindest eine der zu- mindest einen Unterkennung auf. Die zumindest eine Haupttabelle und die zumindest eine Untertabelle weisen jeweils Spalten und Zeilen auf. Eine Spalte ist jeweils einer Eigenschaft oder der eindeutigen Kennung oder der zumindest einen Unterkennung zugeordnet. Eine Zeile der zumindest einen
Haupttabelle und eine zugeordnete Zeile der zumindest einen Untertabelle bilden einen Datensatz. Der jeweilige Unterken- nungswert der zumindest einen Unterkennung stellt jeweils eine Referenz der jeweiligen Zeile der zumindest einen Hauptta- belle zu der zugeordneten jeweiligen Zeile der jeweiligen Untertabelle dar.
Dabei bezeichnet ein Tupel eine Kombination von Eigenschaftswerten, die einer Zeile der jeweiligen Untertabelle zugeord- net sind. Tupel der Eigenschaftswerte können einen oder mehrere Eigenschaftswerte umfassen, die einer Zeile der jeweiligen Untertabelle zugeordnet sind.
Vorzugsweise kommt eine Kombination von Eigenschaftswerten, die jeweils einer Zeile zugeordnet sind, nur einmal in der zumindest einen Untertabelle vor. Dadurch können die Datensätze besonders effizient und mit geringem Speicherplatzbedarf auf dem Speichermedium der relationalen Datenbank abgespeichert werden. Eine Speicherplatzeinsparung ist umso grö- ßer, je größer die Anzahl der Spalten ist, die der zumindest einen Untertabelle zugeordnet ist und je kleiner die Anzahl der Zeilen dieser zumindest einen Untertabelle ist. Dabei kann aber eine Redundanz von Eigenschaftswerten, die einer Eigenschaft zugeordnet sind, weiterhin vorliegen. Vorzugswei- se ist die Anzahl der Untertabellen möglichst gering, um den zusätzlichen Speicherbedarf, der aufgrund der zumindest einen Unterkennung vorliegt, gering zu halten.
Die relationale Datenbank und das Datenbankverwaltungssystem können beispielsweise als eine Funktionseinheit in dem Info- tainmentsystem eines Kraftfahrzeugs integriert sein, wobei das Infotainmentsystem in dem Kraftfahrzeug vorzugsweise als ein eingebettetes System (embedded System) ausgebildet ist. Grundsätzlich ist es aber auch möglich, dass die relationale Datenbank und das Datenbankverwaltungssystem als separate Funktionseinheiten in dem Infotainmentsystem ausgebildet sind.
In einer vorteilhaften Ausgestaltung des ersten Aspekts ist das Datenbankverwaltungssystem ausgebildet, abhängig von zumindest einer vorgegebenen Anweisung auf die zumindest eine Untertabelle zu zugreifen und zumindest einen der Datensätze abhängig von der zumindest einen Unterkennung und den in der zumindest einen Untertabelle gespeicherten Eigenschaftswerten zu rekonstruieren. Dies hat den Vorteil, dass die Datensätze relativ schnell rekonstruiert werden können, bei gleichzeiti- ger effizienter Speicherung der Eigenschaftswerte auf dem Speichermedium der relationalen Datenbank.
In einer weiteren vorteilhaften Ausgestaltung des ersten Aspekts ist das Datenbankverwaltungssystem ausgebildet, bei Vorgabe eines Eigenschaftswertes einer der Eigenschaften, die der zumindest einen Untertabelle zugeordnet ist, zunächst auf die jeweilige Untertabelle zu zugreifen. Dabei ist das Datenbankverwaltungssystem ausgebildet, den vorgegebenen Eigenschaftswert mit den gespeicherten Eigenschaftswerten der je- weiligen Eigenschaften zu vergleichen und abhängig von dem Vergleich zumindest einen Unterkennungswert zumindest einer zugeordneten Unterkennung zu ermitteln. Davon abhängig wird zumindest einer der Datensätze ermittelt. Soll beispielsweise abhängig von einer vorgegebenen Anweisung, die den Eigen- schaftswert der Untertabelle vorgibt, ein oder mehrere Datensätze ermittelt werden, ist vorzugsweise eine Anweisungsrecheneinheit des Datenbankverwaltungssystems ausgebildet, die vorgegebene Anweisung derart zu interpretieren, dass zunächst auf die zumindest eine Untertabelle zugegriffen wird, um den zumindest einen Unterkennungswert der zumindest einen Unterkennung zu ermitteln. Dies ermöglicht eine besonders schnelle Rekonstruktion der Datensätze. Vorzugsweise wird der zumin- dest eine Unterkennungswert mittels des Vergleichs des vorgegebenen Eigenschaftswertes mit den gespeicherten Eigenschaftswerten der jeweiligen Eigenschaften ermittelt, wenn die Untertabelle wenige Zeilen aufweist. Dadurch ist eine je- weilige Indexstruktur, die Referenzen auf Speicherorte der Eigenschaftswerte der jeweiligen Eigenschaft speichert, für die jeweilige Untertabelle nicht erforderlich und somit der Speicherbedarf besonders gering.
In einer weiteren vorteilhaften Ausgestaltung des ersten Aspekts weist das Infotainmentsystem zumindest eine Indexstruktur auf, die Referenzen auf Speicherorte der Eigenschaftswerte der jeweiligen Eigenschaft umfasst, die der jeweiligen Untertabelle zugeordnet ist. Dabei ist das Datenbankverwal- tungssystem ausgebildet, bei Vorgabe eines Eigenschaftswertes einer der Eigenschaften, die der zumindest einen Untertabelle zugeordnet ist, zunächst auf die jeweilige Indexstruktur zu zugreifen und den vorgegebenen Eigenschaftswert mit den in der Indexstruktur gespeicherten Eigenschaftswerten der jewei- ligen Eigenschaften zu vergleichen. Das Datenbankverwaltungssystem ist ferner ausgebildet, abhängig von dem Vergleich zumindest einen Unterkennungswert zumindest einer zugeordneten Unterkennung zu ermitteln. Davon abhängig wird zumindest einer der Datensätze ermittelt. Die Indexstruktur ermöglicht einen besonders schnellen Zugriff auf die jeweiligen Eigenschaftswerte der Untertabelle auf dem Speichermedium, insbesondere wenn die Untertabelle besonders viele Zeilen aufweist .
In einer weiteren vorteilhaften Ausgestaltung des ersten Aspekts ist die vorgegebene Anweisung als SQL-Anweisung ausgebildet. Dies ermöglicht einen besonders schnellen Lese- und/oder Schreibzugriff auf die Infotainmentdaten in der relationalen Datenbank.
Die Erfindung zeichnet sich bezüglich eines zweiten Aspekts aus durch ein Computerprogrammprodukt. Das Computerprogramm- produkt umfasst ein computerlesbares Medium mit Programmanweisungen. Die Programmanweisungen sind durch einen Computer ausführbar. Ferner sind die Programmanweisungen ausgebildet zum Betreiben des Infotainmentsystems gemäß des ersten As- pekts der Erfindung.
Die Erfindung ist im Folgenden anhand von schematischen Zeichnungen näher erläutert. Es zeigen:
Figur 1 ein Datenbanksystem,
Figur 2 eine ursprüngliche Tabelle,
Figur 3 eine Haupt- und eine Untertabelle,
Figur 4 eine weitere Haupt- und weitere Untertabellen.
Elemente gleicher Konstruktion oder Funktion sind figurenübergreifend mit den gleichen Bezugszeichen gekennzeichnet.
Ein Infotainmentsystem (Figur 1) umfasst eine Infotainment- einheit INFO, ein Datenbankverwaltungssystem RDBMS und eine relationale Datenbank RDB. Das Infotainmentsystem kann beispielsweise eine Navigationseinheit umfassen und dient somit dazu, eine vorgegebene Route zu finden und/oder eine vorgegebene Strecke zu berechnen und/oder einen vorgegebenen Ort zu finden und/oder weitere Informationen zu ermitteln. Das Info- tainmentsystem kann zusätzlich oder alternativ aber auch ein Musiksystem umfassen und dazu ausgebildet sein, beispielswei- se vorgegebene Musikstücke zu finden und abzuspielen.
Die Infotainmenteinheit INFO, die relationale Datenbank RDB und das Datenbankverwaltungssystem RDBMS können auch als Softwarefunktionseinheiten in dem Infotainmentsystem ausge- bildet sein. Das Infotainmentsystem kann beispielsweise ein
Bordcomputer eines Kraftfahrzeugs und/oder ein Computer sein, beispielsweise ein tragbarer Computer, so z. B. ein Laptop sein. Das Infotainmentsystem weist vorzugsweise neben zumindest einer Ausgabeeinheit zumindest eine Eingabeeinheit auf, die dazu dient, Informationen, beispielsweise einer Route und/oder einem Musikstück, die ermittelt werden sollen, und/oder Informationen, aufgrund derer Infotainmentdaten geändert, insbesondere aktualisiert werden, einzugeben. Dabei können die Infotainmenteinheit INFO, die relationale Datenbank RDB und das Datenbankverwaltungssystem RDBMS als eine Funktionseinheit in dem Infotainmentsystem integriert sein oder als verteilte Funktionseinheiten.
Die Infotainmenteinheit INFO kommuniziert mit dem Datenbankverwaltungssystem RDBMS. Das Datenbankverwaltungssystem RDBMS umfasst eine Anweisungsschnittstelle SQL_IF, eine Anweisungs- recheneinheit SQL_CMD_PRO, einen Pager PAGER, ein Verzeichnis ID_LIB von Indexstrukturen und eine Betriebssystemschnittstelle OS_IF.
Das Datenbankverwaltungssystem RDBMS kommuniziert mit der re- lationalen Datenbank RDB. In der relationalen Datenbank RDB sind die Infotainmentdaten, so z.B. Navigationsdaten und/oder Musikdaten, gespeichert.
Die Infotainmenteinheit INFO kommuniziert mit dem Datenbank- Verwaltungssystem RDBMS vorzugsweise derart, dass die Info- tainmenteinheit INFO eine Anweisung SQL_CMD an das Datenbankverwaltungssystem RDBMS sendet. Alternativ kann die Anweisung SQL_CMD auch durch geeignete Signale repräsentiert werden, die dann in dem Datenbankverwaltungssystem RDBMS in die ent- sprechende Anweisung SQL_CMD übersetzt werden. Vorzugsweise ist die Anweisung SQL CMD als SQL-Anweisung ausgebildet.
Die Anweisungsschnittstelle SQL IF dient dazu, zu überprüfen, ob die Anweisung SQL_CMD syntaktisch richtig ist. Falls die Anweisung SQL CMD syntaktisch richtig ist, wird sie von der
Anweisungsschnittstelle SQL_IF an die Anweisungsrecheneinheit SQL CMD PRO übergegeben. Die Anweisungsrecheneinheit SQL CMD PRO ermittelt abhängig von der Anweisung SQL_CMD und vorzugsweise abhängig von mindestens einer verfügbaren Indexstruktur, die in dem Verzeichnis ID_LIB der Indexstrukturen hinterlegt ist, vorzugsweise einen Software-Ausführungsplan. Der Software-Ausführungsplan ist ein Programmabschnitt, der dazu dient, den Zugriff auf die Infotainmentdaten möglichst effizient zu gestalten.
Der Software-Ausführungsplan wird von der Anweisungsrechen- einheit SQL_CMD_PRO an den Pager PAGER übergeben. Der Pager PAGER dient dazu, abhängig von dem Software-Ausführungsplan vorzugsweise einen Hardware-Ausführungsplan zu ermitteln. Der Hardware-Ausführungsplan ist repräsentativ dafür, wie eine Hardware, beispielsweise ein CD-ROM-Laufwerk und/oder eine Festplatte und/oder weitere Datenträger, die die relationale Datenbank RDB 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 das technische Gerät übersetzt, auf dem die Infotainmentdaten gespeichert sind, und/oder das das Speichermedium umfasst, auf dem die Infotainmentdaten gespeichert sind.
Die Infotainmentdaten sind in der relationalen Datenbank RDB als Datensätze in Tabellen abgespeichert.
In Figur 2 ist eine ursprüngliche Tabelle R dargestellt, die zehn Datensätze aufweist. Jeder Datensatz wird durch einen Kennungswert einer eindeutigen Kennung PK repräsentiert und umfasst zusätzlich fünf Eigenschaftswerte a-e unterschiedlicher Eigenschaften A-E.
Die Eigenschaften A-E der jeweiligen Datensätze sind in Großbuchstaben gekennzeichnet, während Eigenschaftswerte a-e der Eigenschaften A-E in Kleinbuchstaben gekennzeichnet sind. Ei- ner Eigenschaft ist jeweils eine Spalte zugeordnet. Eine Zeile der zumindest einen Haupttabelle und eine zugeordnete Zeile der zumindest einen Untertabelle bilden einen Datensatz.
Die Eigenschaften A-E der ursprünglichen Tabelle R sind funktional unabhängig voneinander und sind entsprechend der dritten Normalform normalisiert.
In Figur 2 ist angedeutet, dass für die mehreren Eigenschaf- ten A-E in den unterschiedlichen Datensätzen gleiche Eigenschaftswerte a-e abgespeichert sind. So ist beispielsweise der Eigenschaftswert el der Eigenschaft E des ersten Datensatzes identisch mit dem Eigenschaftswert el der Eigenschaft E des zweiten bis vierten Datensatzes. Darüber hinaus sind in Figur 2 weitere Redundanzen von Eigenschaftswerten in der ursprünglichen Tabelle R gekennzeichnet, wobei nicht alle Redundanzen gekennzeichnet sind.
Gemäß einer ersten Ausführungsform (Figur 3) ist ein Daten- satz der ursprünglichen Tabelle R auf einen Hauptdatensatz in einer Haupttabelle MR und auf einen Unterdatensatz in einer ersten Untertabelle PRl aufgeteilt. Die Haupttabelle MR um- fasst die eindeutige Kennung PK und die Eigenschaften A und C, sowie zusätzlich eine erste Unterkennung PIDl. Die erste Untertabelle PRl umfasst die erste Unterkennung PIDl und die dieser Kennung zugeordnete Eigenschaften B, D, E der ursprünglichen Tabelle R, wobei ein jeweiliges Tupel der Eigenschaftswerte b, d, e, die jeweils einer Zeile der ersten Untertabelle PRl zugeordnet sind, nur jeweils einmal in der ersten Untertabelle PRl gespeichert ist. So ist beispielsweise das Tupel der Eigenschaftswerte b5, d5, e5 der Eigenschaften B, D, E nur einmal in der ersten Untertabelle PRl gespeichert, während in der ursprünglichen Tabelle R dieses Tupel der Eigenschaftswerte b5, d5, e5 fünfmal gespeichert ist, ob- wohl die ursprüngliche Tabelle R gemäß der dritten Normalform normalisiert ist. Eine Redundanz von Eigenschaftswerten jeweils einer Eigenschaft ist allerdings weiterhin in der ers- ten Untertabelle PRl vorhanden, so z. B. ist der Eigenschaftswert el dreimal in der ersten Untertabelle PRl gespeichert .
Dabei besteht das Bestreben, so viele Spalten und gleichzeitig so wenig Zeilen wie möglich der jeweiligen Untertabelle zu zuordnen. Dies erlaubt eine besonders hohe Speicherplatzeinsparung auf dem Speichermedium DC der relationalen Datenbank RDB. Dadurch kann die jeweilige Untertabelle einen der- art geringen Speicherbedarf aufweisen, dass beispielsweise die jeweilige Untertabelle in einem Cache-Speicher des Datenbankverwaltungssystems RDBMS oder der relationalen Datenbank RDB zwischengespeichert werden kann und somit besonders schnell zugreifbar ist. Dies ermöglicht einen besonders effi- zienten Zugriff auf die Eigenschaftswerte der jeweiligen Untertabelle .
Der jeweilige Unterkennungswert der ersten Unterkennung PIDl repräsentiert den jeweiligen Unterdatensatz in der ersten Un- tertabelle PRl und ermöglicht eine Referenzierung des jeweiligen Unterdatensatzes aus dem diesem zugeordneten Hauptdatensatz in der Haupttabelle MR. Somit kann beispielsweise mittels der Anweisung SQL CMD
create view R as select * from MR natural join PRl
die ursprüngliche Tabelle R (Figur 1) rekonstruiert werden.
Sind beispielsweise Datensätze zu ermitteln, die einen vorgegebenen Eigenschaftswert der Eigenschaft B, D, E in der ersten Untertabelle PRl aufweisen, so ist das Datenbankverwaltungssystem RDBMS, insbesondere die Anweisungsrecheneinheit SQL_CMD_PRO des Datenbankverwaltungssystems RDBMS, vorzugs- weise ausgebildet, zunächst auf die erste Untertabelle PRl zu zugreifen. Dabei wird der vorgegebene Eigenschaftswert mit den in der ersten Untertabelle PRl gespeicherten Eigen- schaftswerten b, d, e verglichen und davon abhängig ein oder mehrere zugeordnete Unterkennungswerte der ersten Unterken- nungen PIDl ermittelt. Der zumindest eine ermittelte Unter- kennungswert der ersten Unterkennung PIDl ist repräsentativ für zumindest einen Datensatz, der den vorgegebenen Eigenschaftswert der Eigenschaft B, D, E aufweist. Abhängig von dem zumindest einen ermittelten Unterkennungswert kann dann besonders effizient auf die Hauptdatensätze in der Haupttabelle MR zugegriffen werden. Vorzugsweise ist dadurch die In- dexstruktur, die Referenzen auf Speicherorte der Eigenschaftswerte der jeweiligen Eigenschaft A-E umfasst, die der jeweiligen Untertabelle zugeordnet ist, nicht erforderlich, insbesondere wenn die erste Untertabelle PRl eine geringe Anzahl an Zeilen aufweist, so z. B. <= 5.
Weist die erste Untertabelle PRl jedoch viele Zeilen auf, so z. B. > 5, so kann alternativ die Indexstruktur für die erste Untertabelle PRl in dem Verzeichnis ID_LIB von Indexstrukturen angelegt werden. Die Indexstruktur referenziert dann vor- zugsweise die Speicherorte der Unterkennungswerte der ersten Unterkennungen PIDl der ersten Untertabelle PRl. Werden beispielsweise alle Eigenschaftswerte a der Eigenschaft A gesucht, denen der vorgegebene Eigenschaftswert bl der Eigenschaft B zugeordnet ist, so kann beispielsweise mittels der Anweisung SQL_CMD
select A from MR where PIDl in (select PIDl from PRl where B='bl')
diese Suche besonders schnell ausgeführt werden.
Gemäß einer zweiten Ausführungsform in Figur 4 ist ein Datensatz der ursprünglichen Tabelle R auf den Hauptdatensatz der Haupttabelle MR und auf den Unterdatensatz der ersten Unter- tabelle PRl und auf einen weiteren Unterdatensatz einer zweiten Untertabelle PR2 aufgeteilt. Dies hat den Vorteil, dass die vorhandene Redundanz von Eigenschaftswerten der jeweili- gen Eigenschaften B, D, E in der ersten Untertabelle PRl gemäß der Figur 3 weiter reduziert werden kann. Die Haupttabelle MR umfasst neben der ersten Unterkennung PIDl zusätzlich eine zweite Unterkennung PID2. Mittels des jeweiligen Unter- kennungswertes der ersten Unterkennung PIDl sind die Eigenschaftswerte b der Eigenschaft B der ersten Untertabelle PRl referenzierbar . Mittels des jeweiligen Unterkennungswertes der zweiten Unterkennung PID2 sind die Eigenschaftswerte d, e der Eigenschaften D, E der zweiten Untertabelle PR2 referen- zierbar.
Im Folgenden werden zwei Algorithmen erläutert, die das Ermitteln geeigneter Untertabellen ermöglicht, so dass eine Redundanz von Eigenschaftswerten in der jeweiligen Untertabelle so weit wie möglich reduziert wird.
Der erste Algorithmus erläutert die Ermittlung einer Untertabelle wie sie in der Figur 3a und 3b verwendet wird.
Dazu wird zunächst angenommen, dass eine ursprüngliche Tabelle RX vorliegt mit n Zeilen und o Eigenschaften Al bis Ao pro Zeile. Für o Eigenschaften bestehen 2° Möglichkeiten von Kombinationen von Eigenschaften, die der Untertabelle zugeordnet werden können. Liegen beispielsweise 5 Eigenschaften vor, so ergeben sich 25 = 32 mögliche Kombinationen von Eigenschaften. Es gilt nun herauszufinden, welche Kombination von Eigenschaften die höchste Speicherplatzeinsparung ermöglicht.
Beginnend von einer der 2° Möglichkeiten, so z. B. die Kombi- nation der Eigenschaften Al, A3, A5, kann beispielsweise mit der folgenden Anweisung SQL CMD
select count(l) from RX group by A1,A3,A5
ermittelt werden, wieviele unterschiedliche Kombinationen n' von Eigenschaftswerten der vorgegebenen Kombination der Eigenschaften Al, A3, A5 in der ursprünglichen Tabelle RX vor- liegen. Die unterschiedlichen Kombinationen n' repräsentieren dabei die Anzahl der Zeilen der Untertabelle, die resultieren würde, wenn die gerade verwendete Kombination der Eigenschaften Al, A3, A5 der Untertabelle zugeordnet würde.
Danach wird ein durchschnittlicher Speicherbedarf s eines Eigenschaftswertes in Bytes ermittelt. Dies kann beispielsweise mittels folgender Anweisung SQL_CMD
select average (length (Al) +length (A3) +length (A5) ) \3 from RX group by A1,A3,A5
erfolgen. Mit der ermittelten Anzahl an unterschiedlichen Kombination n' von Eigenschaftswerten und dem durchschnittli- chen Speicherbedarf s eines Eigenschaftswertes kann die jeweilige Einsparung des Speicherplatzes in Bytes mit folgender mathematischen Gleichung ermittelt werden
o * s * (n - n' ) - r * (n + n' ) .
Dabei stellt r den Speicherbedarf der jeweiligen Unterkennung dar, so z.B. 8 Bytes. Der erste Term o * s * (n - n' ) repräsentiert die Einsparung in Bytes für die jeweilige Kombination von Eigenschaften, die gerade betrachtet wird. Der zweite Term r * (n + n' ) stellt dann den zusätzlich benötigten Speicherbedarf dar, der aufgrund der zusätzlichen Unterkennungen benötigt wird und der von dem eingesparten Speicherplatz abzuziehen ist.
Die dargestellte Berechnung wird für jede der 2° möglichen Kombinationen von Eigenschaften berechnet. Die Kombination von Eigenschaften mit der höchsten Speicherplatzeinsparung wird dann vorzugsweise der Untertabelle zugeordnet. Vorzugsweise weist diese Untertabelle dann auch eine optimale Anzahl von Zeilen und Spalten auf. Der zweite Algorithmus erläutert die Ermittlung mehrerer Untertabellen wie sie in der Figur 4 verwendet werden.
Dabei ermittelt der folgende Algorithmus nicht die Kombinati- onen von Eigenschaften mit dem geringsten Speicherbedarf, sondern vielmehr Kombinationen von Eigenschaften, die eine annehmbare Reduktion des Speicherbedarfes ermöglichen.
Auch hier wird angenommen, dass die ursprüngliche Tabelle RX vorliegt mit n Zeilen und o Eigenschaften Al bis Ao pro Zeile.
In einem ersten Schritt wird für jede Eigenschaft Ai (mit i = 1 bis o) der ursprünglichen Tabelle RX die folgende Anweisung SQL_CMD
select count(l) as n' , average (length (Ai) ) as s from RX group by Ai
ausgeführt. Mit der folgenden schon bekannten mathematischen Gleichung
s * (n - n' ) - r * (n + n' )
kann der eingesparte Speicherplatz in Bytes jeder Eigenschaft berechnet werden, wobei s, n, n' und r die gleiche Bedeutung wie im ersten Algorithmus haben.
In einem nächsten Schritt werden Eigenschaftspaare Ai, Aj (mit i, j = 1...O, wobei i I= J) betrachtet. Dabei wird für jedes mögliche Eigenschaftspaar Ai, Aj die folgende Anweisung SQL_CMD ausgeführt
select count(l) as n' , average (length (Ai) +length (Aj )) \2 as s from RX group by Ai, Aj . Auch hier kann anhand der schon bekannten mathematischen Gleichung der eingesparte Speicherplatz in Bytes berechnet werden. Abhängig von dem ermittelten eingesparten Speicherplatz pro Eigenschaftspaar Ai, Aj kann nun entschieden wer- den, ob ein jeweiliges Eigenschaftspaar Ai, Aj einer eigenen Untertabelle zugeordnet werden kann.
In einem nächsten Schritt wird versucht, zwei Eigenschaftspaar zu jeweils einem Eigenschaftstripel zusammenzuführen. Liegen beispielsweise die beiden Eigenschaftspaare Ai, Aj und Ak, Aj vor, so kann überprüft werden, ob das Eigenschaftstripel Ai, Aj, Ak mehr Speicherplatz einspart als die dazugehörigen Eigenschaftspaare Ai, Aj und Ak, Aj.
In einem nächsten Schritt werden zwei Eigenschaftstripel zu einem Eigenschaftstupel einer Länge 4 zusammengefasst und bewertet. Liegen beispielsweise die beiden Eigenschaftstripel Ai, Aj, Ak und Ai, Aj, Al vor, so kann überprüft werden, ob das Eigenschaftstupel der Länge 4 Ai, Aj, Ak, Al mehr Spei- cherplatz einspart als die dazugehörigen Eigenschaftstripel Ai, Aj, Ak und Ai, Aj, Al.
Vorzugsweise kann die weitere Zusammenführung zu Eigenschaftstupeln vorgegebener Länge solange betrieben werden, bis sich eine weitere Einsparung von Speicherplatz nicht mehr ermitteln lässt.
In einem weiteren Schritt werden alle ermittelten Möglichkeiten der Kombinationen von Eigenschaften und deren dazugehöri- ge Speicherplatzeinsparung in Bytes in eine Liste eingetragen, wobei die Liste nach der Größe der Speicherplatzeinsparung sortiert wird. Möglichkeiten der Kombination von Eigenschaften, die keine Speicherplatzeinsparung ermöglichen, werden nicht berücksichtigt.
Die erste Möglichkeit der Kombination von Eigenschaften auf der Liste, der gleichzeitig die höchste Speicherplatzeinspa- rung zugeordnet ist, kann direkt einer ersten Untertabelle zugeordnet werden.
Danach werden alle Listeneinträge gestrichen, die zumindest eine Eigenschaft aufweisen, die auch in der ersten Möglichkeit der Kombination von Eigenschaften enthalten ist.
In einem nächsten Schritt wird die der ersten Möglichkeit folgende zweite Möglichkeit der Kombination von Eigenschaften auf der Liste ermittelt, die nicht gestrichen wurde. Die zweite Möglichkeit der Kombination wird einer zweiten Untertabelle zugeordnet und erneut werden alle Listeneinträge gestrichen, die zumindest eine Eigenschaft aufweisen, die auch in der zweiten Möglichkeit der Kombination von Eigenschaften enthalten ist. Diese letzten Schritte werden solange wiederholt, bis keine Möglichkeiten der Kombination von Eigenschaften mehr auf der Liste verfügbar ist.
Durch den zweiten Algorithmus können mehrere Untertabellen mit unterschiedlicher Anzahl von unterschiedlichen Eigenschaften ermittelt werden, die eine besonders effiziente Speicherung von Eigenschaftswerten in der relationalen Datenbank RDB ermöglichen.
Es gibt viele Beispiele im Bereich der Infotainmentsysteme auf die die Verwendung von Untertabellen angewendet werden kann. So kann beispielsweise eine folgende ursprüngliche Tabelle (mit Eigenschaften in der Klammer)
Links (LINK_ID, speed_limit, urban, functional_road_class, ...)
aus dem Bereich der Navigationssysteme vorgesehen sein. Da insbesondere die Eigenschaft , speed_limit' (Geschwindigkeits- begrenzung) erfahrungsgemäß nur relativ wenige Eigenschaftswerte zulässt, so z.B. 50, 60, 70, 80, 100, 120 km/h, oder die Eigenschaft , urban' (Stadtgebiet) vorzugsweise als Eigen- schaftswerte nur ja oder nein zulässt oder die Eigenschaft , functional_road_class' beispielsweise Autobahn, Bundesstrasse, etc. als mögliche Eigenschaftswerte zulässt, sind diese Eigenschaften besonders geeignet, einer oder mehreren Untertabellen zugeordnet zu werden. Dadurch wird eine besonders erffiziente Speicherung dieser Eigenschaftswerte in der relationalen Datenbank RDB ermöglicht.

Claims

Patentansprüche
1. Infotainmentsystem, das umfasst eine relationale Datenbank (RDB) , die auf einem Speichermedium (DC) gespeichert ist, und ein Datenbankverwaltungssystem (RDBMS) und dazu ausgebildet ist, auf Infotainmentdaten zu zugreifen, die in der relationalen Datenbank (RDB) als Datensätze gespeichert sind, wobei ein Datensatz jeweils ein Kennungswert einer eindeutigen Kennung (PK), Eigenschaftswerte mehrerer Ei- genschaften (A-E) und zumindest einen Unterkennungswert zumindest einer Unterkennung (PIDl, PID2) aufweist, wobei
- zumindest einer Untertabelle (PRl, PR2) zugeordnet sind, alle oder zumindest eine der mehreren Eigenschaften (A- E) und eine der zumindest einen Unterkennung (PIDl, PID2),
- zumindest einer Haupttabelle (MR) zugeordnet sind, die eindeutige Kennung (PK), die verbleibenden der mehreren Eigenschaften (A-E) und die zumindest eine zugeordnete Unterkennung (PIDl, PID2) - Tupel der Eigenschaftswerte (a-e) der Eigenschaften (A- E), die der jeweiligen Untertabelle (PRl, PR2) zugeordnet sind, nur jeweils einmal in der jeweiligen Untertabelle (PRl, PR2 ) gespeichert sind,
- die mehreren Eigenschaften (A-E) funktional unabhängig voneinander sind.
2. Infotainmentsystem nach Anspruch 1, bei dem das Datenbankverwaltungssystem (RDBMS) ausgebildet ist, abhängig von zumindest einer vorgegebenen Anweisung (SQL CMD) auf die zumindest eine Untertabelle (PRl, PR2) zu zugreifen und zumindest einen der Datensätze abhängig von der zumindest einen Unterkennung (PIDl, PID2) und den in der zumindest einen Untertabelle (PRl, PR2) gespeicherten Eigenschaftswerten (a-e) zu rekonstruieren.
3. Infotainmentsystem nach Anspruch 1 oder 2, bei dem das Datenbankverwaltungssystem (RDBMS) ausgebildet ist, bei Vor- gäbe eines Eigenschaftswertes einer der Eigenschaften (A- E), die der zumindest einen Untertabelle (PRl, PR2) zugeordnet ist, zunächst auf die jeweilige Untertabelle (PRl, PR2) zu zugreifen und den vorgegebenen Eigenschaftswert mit den gespeicherten Eigenschaftswerten (a-e) der jeweiligen Eigenschaften (A-E) zu vergleichen und abhängig von dem Vergleich zumindest einen Unterkennungswert zumindest einer zugeordneten Unterkennung (PIDl, PID2) zu ermitteln und davon abhängig zumindest einen der Datensätze zu er- mittein.
4. Infotainmentsystem nach einem der vorstehenden Ansprüche, das zumindest eine Indexstruktur aufweist, die Referenzen auf Speicherorte der Eigenschaftswerte (a-e) der jeweili- gen Eigenschaft (A-E) umfasst, die der jeweiligen Untertabelle (PRl, PR2) zugeordnet ist, bei dem das Datenbankverwaltungssystem (RDBMS) ausgebildet ist, bei Vorgabe eines Eigenschaftswertes einer der Eigenschaften (A-E) , die der zumindest einen Untertabelle (PRl, PR2) zugeordnet ist, zunächst auf die jeweilige Indexstruktur zu zugreifen und den vorgegebenen Eigenschaftswert mit den in der Indexstruktur gespeicherten Eigenschaftswerten (a-e) der jeweiligen Eigenschaften (A-E) zu vergleichen und abhängig von dem Vergleich zumindest einen Unterkennungswert zumindest einer zugeordneten Unterkennung (PIDl, PID2) zu ermitteln und davon abhängig zumindest einen der Datensätze zu ermitteln .
5. Infotainmentsystem nach einem der vorstehenden Ansprüche, bei dem die vorgegebene Anweisung (SQL_CMD) als SQL- Anweisung ausgebildet ist.
6. Computerprogrammprodukt, das ein computerlesbares Medium mit Programmanweisungen umfasst, die durch einen Computer ausführbar sind und die ausgebildet sind zum Betreiben eines Infotainmentsystems nach einem der Ansprüche 1 bis 5.
EP09764209A 2008-11-26 2009-11-04 Infotainmentsystem und computerprogrammprodukt Ceased EP2370915A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102008059096 2008-11-26
PCT/EP2009/064620 WO2010060764A1 (de) 2008-11-26 2009-11-04 Infotainmentsystem und computerprogrammprodukt

Publications (1)

Publication Number Publication Date
EP2370915A1 true EP2370915A1 (de) 2011-10-05

Family

ID=41571577

Family Applications (1)

Application Number Title Priority Date Filing Date
EP09764209A Ceased EP2370915A1 (de) 2008-11-26 2009-11-04 Infotainmentsystem und computerprogrammprodukt

Country Status (2)

Country Link
EP (1) EP2370915A1 (de)
WO (1) WO2010060764A1 (de)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050131585A1 (en) * 2003-12-12 2005-06-16 Microsoft Corporation Remote vehicle system management
US20060036356A1 (en) * 2004-08-12 2006-02-16 Vladimir Rasin System and method of vehicle policy control
US20080156173A1 (en) * 2006-12-29 2008-07-03 Harman International Industries, Inc. Vehicle infotainment system with personalized content

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6016497A (en) * 1997-12-24 2000-01-18 Microsoft Corporation Methods and system for storing and accessing embedded information in object-relational databases

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050131585A1 (en) * 2003-12-12 2005-06-16 Microsoft Corporation Remote vehicle system management
US20060036356A1 (en) * 2004-08-12 2006-02-16 Vladimir Rasin System and method of vehicle policy control
US20080156173A1 (en) * 2006-12-29 2008-07-03 Harman International Industries, Inc. Vehicle infotainment system with personalized content

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"Database systems : the complete book", 1 January 2002, PEARSON EDUCATION INTERNATIONAL, Upper Saddle River, NJ [u.a.], ISBN: 978-0-13-098043-4, article HECTOR GARCIA-MOLINA ET AL: "Database Systems the complete book", pages: 102 - 300, XP055472777 *
"SQL-Datenbanken unter Unix. System und Netzwerk Management von Hochverfügbarkeitssystemen", 1 January 2003, BOOKS ON DEMAND, ISBN: 978-3-8330-0121-5, article RALF STEFFLER: "SQL-Datenbanken unter Unix. System und Netzwerk Management von Hochverfügbarkeitssystemen", XP055472726 *
See also references of WO2010060764A1 *

Also Published As

Publication number Publication date
WO2010060764A1 (de) 2010-06-03

Similar Documents

Publication Publication Date Title
DE60118973T2 (de) Verfahren zum abfragen einer struktur komprimierter daten
DE69704085T2 (de) Optimierung des zugriffes auf multiplexierte datenströme
DE102014201682A1 (de) Verfahren zur Koexistenz von Software mit verschiedenen Sicherheitsstufen in einem Multicore-Prozessorsystem
DE112005003265T5 (de) Registerdateibereiche für ein Verarbeitungssystem
DE102008047915B4 (de) Infotainmentsystem und Computerprogrammprodukt
DE102007037646A1 (de) System und Verfahren zum Indizieren, Durchsuchen und zur Datenwiedergewinnung von Datenbanken
EP3831035A1 (de) Verfahren und zwischenspeichereinrichtung für messdaten von fahrzeugen (&#34;datentankstelle&#34;)
DE102018107860A1 (de) System und Verfahren zum Zugriff auf Daten in einem Mehrkern-Verarbeitungssystem, um Zugriffe auf externe Speicher zu verringern
DE102021125858A1 (de) Verfolgen eines protokollverlaufs einer änderungsdatenerfassung
DE60314844T2 (de) Verfahren und Vorrichtung zur Sprachausgabe, Datenträger mit Sprachdaten
WO2010060764A1 (de) Infotainmentsystem und computerprogrammprodukt
WO2010060763A1 (de) Infotainmentsystem und computerprogrammprodukt
EP3129891B1 (de) Verfahren zum verbesserten zugriff auf einen hauptspeicher eines computersystems, entsprechendes computersystem sowie computerprogramm-produkt
DE112021000801T5 (de) Informationsverarbeitungsvorrichtung und Informationsverarbeitungsverfahren
WO2008071733A1 (de) Verfahren zum auslesen von daten aus einem speichermedium
DE3885202T2 (de) Zugriffsverriegelungsmittel für Speicherzugriffsverwaltungseinheit und Zugriffskonfliktenverwaltung mit solchen Verriegelungsmitteln.
DE102022202335A1 (de) Computerimplementiertes verfahren zur speicheroptimierung eines partitionierten systems
WO2007048148A1 (de) Verfahren zur steuerung eines relationalen datenbanksystems
DE19810784A1 (de) Hardwareunterstützung für Datenumsetzung
DE102008044808A1 (de) Verfahren zur Generierung von Programmcode in einem Betriebssystemspeicher und einem Applikationsspeicher eines Datenträgers
WO2021064037A1 (de) Verfahren, computerprogramm, speichermedium, speichermittel und system zur nutzung eines gemeinsam genutzten speichermittels
EP4198760B1 (de) Verfahren zur verarbeitung von signaldaten
EP1979837B1 (de) Verfahren zur ausgabe von datensätzen und vorrichtung hierfür
WO2020094175A1 (de) Verfahren und vorrichtung zum speichern von daten und deren beziehungen
DE102024104529A1 (de) Verfahren zum Ermitteln einer besten Fahrzeugausstattung

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: 20110627

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 HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

RIN1 Information on inventor provided before grant (corrected)

Inventor name: STEGE, KURT

Inventor name: ZEHNER, STEFFEN

Inventor name: PFEIFLE, MARTIN

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20161202

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

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

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20190121