[go: up one dir, main page]

WO2010031728A1 - Infotainmentsystem und computerprogrammprodukt - Google Patents

Infotainmentsystem und computerprogrammprodukt Download PDF

Info

Publication number
WO2010031728A1
WO2010031728A1 PCT/EP2009/061747 EP2009061747W WO2010031728A1 WO 2010031728 A1 WO2010031728 A1 WO 2010031728A1 EP 2009061747 W EP2009061747 W EP 2009061747W WO 2010031728 A1 WO2010031728 A1 WO 2010031728A1
Authority
WO
WIPO (PCT)
Prior art keywords
property
value
data
stored
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
PCT/EP2009/061747
Other languages
English (en)
French (fr)
Inventor
Martin Pfeifle
Kurt Stege
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.)
Continental Automotive GmbH
Original Assignee
Continental Automotive 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 GmbH filed Critical Continental Automotive GmbH
Priority to EP09782866A priority Critical patent/EP2329416A1/de
Priority to US13/119,874 priority patent/US20110231438A1/en
Publication of WO2010031728A1 publication Critical patent/WO2010031728A1/de
Anticipated expiration legal-status Critical
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/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases

Definitions

  • the invention relates to an infotainment system and a computer program product for operating the infotainment system.
  • Infotainment systems for example, are incorporated in modern motor vehicles and link the transmission of information, e.g. Navigation data, and entertainment data, e.g. TV or music data.
  • 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 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, in a first aspect, by an infotainment system comprising a relational database stored on a storage medium and a database management system.
  • the database management system is configured to access infotainment data stored in the relational database
  • Database are stored as data records.
  • a record has a unique identifier of the record and at least one table property. At least the unique identifier of each record is stored in a property value table in the relational database.
  • the property value table represents a corresponding value of the table property of the particular record. This enables a particularly efficient storage of the infotainment data in the relational database, in particular in that the at least one table property does not exist in the respective one
  • Property value table but is represented by the respective property value table itself.
  • the relational database and the database management system may function as a functional unit in the
  • the relational database and the database management system are assigned to the infotainment system as separate functional units.
  • the infotainment system is designed as a computer system.
  • the data of the respective property value table are preferably stored with respect to their spatial arrangement contiguous on the storage medium.
  • the respective data record has the unique identifier of the data record and the at least one table property and at least one further property.
  • the unique identifier and the at least one further property of the respective data record are stored in the property value table.
  • the at least one further property can be embodied, for example, as at least one data packet, for example a BLOB (Binary Large Object).
  • the at least one further property is designed as a record attribute.
  • table data records of at least one metadata table are stored in the relational database.
  • the corresponding property value table is referenced as a function of the corresponding value of the at least one table property of the respective data record.
  • the at least one metadata table is preferably stored separately in the relational database.
  • all property value tables stored in the relational database may be determined. Basically, it is also possible depending on the value of each
  • Dataset associated with the dataset to determine the associated property value table, where the value can be specified by means of a statement, for example.
  • the at least one further property and thus the infotainment data can be read and / or written. This allows particularly fast access to the infotainment data and At the same time, it enables particularly efficient storage of infotainment data.
  • the database management system is designed to access the corresponding property value table depending on at least one predefined instruction and to reconstruct the corresponding data record with the at least one table property represented by the property value table. That's it
  • Database management system further configured, depending on the at least one given instruction to access the at least one table property and / or the at least one further property of the reconstructed data set.
  • the property value table By means of the property value table, the corresponding data record can be reconstructed in a particularly simple manner, in particular by means of the use of SQL as a predefined statement. In principle, however, proprietary instructions for the reconstruction of the data sets are also usable.
  • the database management system is designed to determine the at least one property value table by means of the metadata table, depending on the at least one predetermined instruction. This enables particularly efficient storage of the infotainment data, since a property value table does not have to be provided for every possible value of the at least one table property.
  • the metadata table preferably only references the property value tables that actually used
  • the property value table represents at least one Boolean value and / or at least one value of a predetermined value set of the at least one table property.
  • the predetermined set of values includes only a predetermined number of different values that are usable for the at least one table property. Especially with a limited number of different possible values of the at least one table property, the use of the property value table ensures efficient storage of the records.
  • 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.
  • 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 a first table
  • FIG. 3 shows several property value tables for Boolean values
  • FIG. 4 shows a plurality of property value tables and one
  • FIG. 5 shows a plurality of property value tables for a plurality of Boolean values and a metadata table.
  • FIG. 6 shows another metadata table
  • An infotainment system ( Figure 1) comprises a
  • Infotainment device INFO a database management system RDBMS and a relational database RDB.
  • Infotainment system may include, for example, a navigation system and thus serves to find a predetermined route and / or to calculate a predetermined route and / or to find a predetermined location and / or to determine further information.
  • the infotainment system may additionally or alternatively but also include a music system and be designed to find, for example, predetermined pieces of music and play.
  • the infotainment device INFO, the relational database RDB and the database management system RDBMS can be integrated, for example, in a technical device which is arranged, for example, in a motor vehicle.
  • the infotainment device INFO, the relational database RDB, and the database management system RDBMS may also be software functional units that are provided by the technical device used.
  • the technical device can be for example an on-board computer of a motor vehicle and / or a computer, for example a portable computer, for example a laptop.
  • the technical device preferably has, in addition to at least one output unit, at least one input unit which serves to input information, for example a route and / or a piece of music, which is to be determined, and / or information on the basis of which infotainment data are changed, in particular updated.
  • the infotainment device INFO communicates with the database management system RDBMS.
  • the database management system RDBMS comprises an instruction interface SQL IF, a
  • Instruction command processor SQL_CMD_PRO a pager PAGER, an index 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 device INFO communicates with the
  • Database management system RDBMS preferably such that the infotainment device INFO sends an SQL CMD statement to the database management system RDBMS.
  • the SQL_CMD instruction may also be represented by appropriate signals, which are then stored in the
  • Database management system RDBMS be translated 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 is sent from the SQL IF statement interface to the
  • the instruction command processor SQL_CMD_PRO preferably determines a software execution plan depending on the SQL CMD instruction, and preferably on at least one available index structure stored 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 infotainment data as efficient as possible.
  • the software execution plan is provided by the
  • the pager PAGER serves to determine a hardware execution plan, depending on the software execution plan.
  • the hardware execution plan is representative of how to drive hardware, such as a CD-ROM drive and / or a hard disk, and / or other volumes that may include the relational database RDB, to run the software execution plan.
  • the hardware execution plan is sent to the
  • Pass operating system interface OS_IF which translates the hardware execution plan into corresponding control signals for the technical device on which the infotainment data are stored, and / or which includes 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 a first, second, third and fourth data record.
  • Record is a unique identifier PK and each have a first, a second and a third properties A, B, C assigned.
  • the respective unique identifier PK represents the respective data record.
  • the fourth record with the unique identifier PK 4 the first
  • Property a4 the second property b4, and the third property c4.
  • the properties of the respective data record are designed as data record attributes.
  • the values of the first property A of the respective data record are designed as Boolean values.
  • the first, second and third data sets are each assigned a Boolean value TRUE and the fourth data set a Boolean value FALSE as the first property A.
  • the first property A can also be referred to as a table property of the respective data record.
  • FIG. 3 shows a first and a second property value table R_A_TRUE, R_A_FALSE.
  • the first property value table RA TRUE represents the Boolean value TRUE of the first property A.
  • the second property value table RA FALSE represents the Boolean value FALSE of the first property A.
  • the unique identifier PK, the second and third properties are B, C of all records of the original table R, which have as the first property A the Boolean value TRUE associated with the first property value table RA TRUE and the unique identifier PK, the second and third property B, C all records of the original table R that have the first property A with the Boolean value FALSE are assigned to the second property value table RA FALSE.
  • the fourth record of the original table R is the only one to have the value FALSE as the first property A
  • only its unique identifier PK and properties B, C are assigned to the second property value table RA FALSE.
  • the unique identifier PK and the properties B, C of the remaining data records of the original table R are assigned to the first property value table R_A_TRUE.
  • the value of the respective first property A is represented by the associated property value table R_A_TRUE, R_A_FALSE.
  • additional metadata per property such as one or two bytes of metadata, are preferably reserved in the relational database RDB.
  • the respective Boolean value of the first property A has not just one bit, which would be sufficient for a value TRUE or FALSE, but additional bytes for the additional metadata.
  • indexes of properties of the data records in the index ID LIB of the index structures in the database management system RDBMS are frequently stored, which preferably allow a direct and thus particularly fast access to the respective properties.
  • this additional memory requirement for the additional metadata of the at least one table property on the storage medium DC and for the respective indices of the at least one Table property in the ID_LIB directory of the index structures can be saved, which in particular with a high number of data records, such as a million and more, a particularly reduced memory requirements in the relational database RDB and the
  • Database management system RDBMS Furthermore, the low memory requirement also reduces the access time of the database management system RDBMS to the relational database RDB, thus ensuring particularly fast access to the infotainment data.
  • the original table R (FIG. 2) can be reconstructed in a particularly simple manner. For example, using the statement SQL CMD
  • the respective first property A assumes a value of a predetermined value set, which comprises, for example, the different values e1, e2, e3, e4 or e5.
  • the first property A of the first and fourth data sets has the value e2.
  • the first property A of the third record has the value el and that of the second record the value e5.
  • the values e3 and e4 are unused.
  • the unique identifier PK and the second and third properties B, C of the four records of the original table R are stored in first, second and third property value tables RA el, RA e2, RA e5 in the relational database RDB.
  • the unique identifier PK and the characteristics B, C of the first and fourth records of the original table R are associated with the second property value table RA e2
  • the unique identifier PK and the properties B, C of the third record of the original table R of the first property value table R_A_el and the unique identifier PK and the properties B, C of the second data set are associated with the third property table R_A_e5.
  • a metadata table RA MD is shown, which is stored next to the property value tables R_A_el, R_A_e2, R_A_e5 in the relational database RDB.
  • the metadata table R_A_MD it is possible, depending on the predetermined value of the first property A, to refer directly to the respective property value table. If, for example, a value e2 is specified as table property A during read access by means of the SQL_CMD instruction, the property value table RA e2 can be referenced directly using the metadata table R_A_MD and then to the second and third respectively
  • Property B, C are accessed, for example by means of another statement SQL CMD.
  • SQL CMD This has the advantage that no respective property value table has to be stored for the unused values e3, e4 of the predetermined value set. This also leads to a reduced memory requirement, since every empty table stored in the relational database RDB also has metadata which can be saved by using the metadata table.
  • infotainment data which is designed as navigation data
  • these have to be updated or changed, such as e.g. due to changed roads.
  • the at least one table property of the respective data record is also changed.
  • the database management system RDBMS is designed, depending on the at least one given SQL CMD statement, to copy the further properties of the corresponding data set into another property value table or first to create a new assigned property value table and then to copy the further properties of the corresponding data set and then to adapt the corresponding metadata table ,
  • the first property A is used as the first table property A and the second property B is used as the second table property B.
  • the first as well as the second table property A, B each assume Boolean value. This results in four possible combinations of the first and second table properties A, B. If, for example, the second data set of the original table R has a value TRUE as the first property A and a value FALSE as the second property B, then only the unique identifier PK and the third property C of the second record of the property value table R_A_TRUE_B_FALSE is assigned, which is representative of the value of the first and second property A, B of the second data set.
  • another metadata table RAB MD is stored in the relational database RDB, which depending on the values of the first and second properties A, B the respective property value table is referenced. Due to the use of the further metadata table R_A_B_MD, another property value table representing the unused value FALSE of the first property A and the value FALSE of the second property B is not required. By means of the use of the further metadata table R_A_B_MD, all the stored property value tables can thus be initially used by, for example, a first instruction
  • Fig. 6 is a place metadata table
  • R_URBAN_SPEEPLIMIT_MD as used in connection with the navigation system of the infotainment system, for example.
  • a respective location property value table R_UR_TRUE_SL_NULL, R_UR_FALSE_SL_60, R_UR_TRUE_SL_30, R_UR_FALSE_SL_30 is referenced, which is not shown.
  • the first location table property URBAN Boolean value and thus represents whether a determined by means of the navigation system current position of the motor vehicle is located in a city or not.
  • the second location table property SPEEDLIMIT can preferably assume different integer values and the value NULL and thus represents a speed limit assigned to the determined current position of the motor vehicle.
  • the value NULL of the second location table property SPEEDLIMIT represents a non-speed limit at the determined position of the motor vehicle.
  • the second location table property SPEEDLIMIT assumes only predetermined integer values, such as 30, 50, 60, 70, 80, 90, 100, 120, such that only a limited number of combinations of the first and second location table properties URBAN, SPEEDLIMIT are used as possible combinations become.
  • location property value tables are created only for used integer values of the second location table property SPEEDLIMIT.
  • the determined current position of the motor vehicle is assigned to a current position in the urban area by means of a value TRUE of the first location table property URBAN.
  • This first location table property URBAN is assigned, for example by means of a value 60 of the second location table property SPEEDLIMIT, a maximum permissible speed of 60 km / h for the current position of the motor vehicle.
  • This first and second location table property URBAN, SPEEDLIMIT is assigned a location property value table R_UR_TRUE_SL_60 in which further properties are stored.
  • the data of the respective property value tables and those of the respective metadata tables are preferably stored contiguously with respect to their arrangement on the storage medium DC of the relational database RDB.
  • the data of the respective property value tables and that of the respective metadata tables can be stored coherently in different storage areas on the storage medium DC.
  • more than two properties of a table can also be used as table properties, whereby the values of each table property can be embodied as a Boolean value or as an integer value or as a value of the specified value set or as another value of a possible data type. Also, when using multiple table properties, any combination of different data types of the values of the respective table properties is possible. Also, multiple metadata tables may be stored in the relational database RDB and reference several different property value tables.

Landscapes

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

Abstract

Ein Infotainmentsystem umfasst eine relationale Datenbank (RDB), die auf einem Speichermedium (DC) gespeichert ist, und ein Datenbankverwaltungssystem (RDBMS). Das Datenbankverwaltungssystem (RDBMS) ist ausgebildet, auf Infotainmentdaten zu zugreifen, die in der relationalen Datenbank (RDB) als Datenstze abgespeichert sind. Ein Datensatz weist eine eindeutige Kennung (PK) des Datensatzes und zumindest eine Tabelleneigenschaft (A) auf. Zumindest die eindeutige Kennung (PK) des jeweiligen Datensatzes ist in einer Eigenschaftswerttabelle in der relationalen Datenbank (RDB) gespeichert. Die Eigenschaftswerttabelle reprsentiert einen entsprechenden Wert der Tabelleneigenschaft (A) des jeweiligen Datensatzes.

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 Informationen, 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 Infotainmentdaten 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 eines ersten Aspekts aus durch ein Infotainmentsystem, das eine relationale Datenbank, die auf einem Speichermedium gespeichert ist, und ein Datenbankverwaltungssystem umfasst. Das Datenbankverwaltungssystem ist ausgebildet, auf Infotainmentdaten zu zugreifen, die in der relationalen
Datenbank als Datensätze abgespeichert sind. Ein Datensatz weist eine eindeutige Kennung des Datensatzes und zumindest eine Tabelleneigenschaft auf. Zumindest die eindeutige Kennung des jeweiligen Datensatzes ist in einer Eigenschaftswerttabelle in der relationalen Datenbank gespeichert. Die Eigenschaftswerttabelle repräsentiert einen entsprechenden Wert der Tabelleneigenschaft des jeweiligen Datensatzes. Dies ermöglicht eine besonders effiziente Speicherung der Infotainmentdaten in der relationalen Datenbank, insbesondere dadurch, dass die zumindest eine Tabelleneigenschaft nicht in der jeweiligen
Eigenschaftswerttabelle gespeichert ist, sondern durch die jeweilige Eigenschaftswerttabelle selbst repräsentiert wird. Die relationale Datenbank und das Datenbankverwaltungssystem können beispielsweise als eine Funktionseinheit in dem
Infotainmentsystem integriert sein. Grundsätzlich ist es aber auch möglich, dass die relationale Datenbank und das Datenbankverwaltungssystem als separate Funktionseinheiten dem Infotainmentsystem zugeordnet sind. Vorzugsweise ist das Infotainmentsystem als Computersystem ausgebildet. Die Daten der jeweiligen Eigenschaftswerttabelle sind vorzugsweise bezüglich ihrer räumlichen Anordnung zusammenhängend auf dem Speichermedium gespeichert. In einer vorteilhaften Ausgestaltung des ersten Aspekts weist der jeweilige Datensatz die eindeutige Kennung des Datensatzes und die zumindest eine Tabelleneigenschaft und zumindest eine weitere Eigenschaft auf. Dabei sind die eindeutige Kennung und die zumindest eine weitere Eigenschaft des jeweiligen Datensatzes in der Eigenschaftswerttabelle gespeichert. Die zumindest eine weitere Eigenschaft kann beispielsweise als zumindest ein Datenpaket, so z.B. ein BLOB (Binary Large Object), ausgebildet sein. Vorzugsweise ist die zumindest eine weitere Eigenschaft als Datensatzattribut ausgebildet .
In einer weiteren vorteilhaften Ausgestaltung des ersten Aspekts sind in der relationalen Datenbank Tabellendatensätze zumindest einer Metadatentabelle gespeichert. Mittels der Metadatentabelle ist abhängig von dem entsprechenden Wert der zumindest einen Tabelleneigenschaft des jeweiligen Datensatzes die entsprechende Eigenschaftswerttabelle referenzierbar . Die zumindest eine Metadatentabelle ist vorzugsweise separat in der relationalen Datenbank abgespeichert. Abhängig von der Metadatentabelle können vorzugsweise alle in der relationalen Datenbank gespeicherten Eigenschaftswerttabellen ermittelt werden. Grundsätzlich ist es auch möglich abhängig von dem Wert der dem jeweiligen
Datensatz zugeordneten Tabelleneigenschaft, die zugeordnete Eigenschaftswerttabelle zu ermitteln, wobei der Wert beispielsweise mittels einer Anweisung vorgegeben werden kann. Abhängig von derselben oder beispielsweise einer weiteren Anweisung kann dann auf die zumindest eine weitere Eigenschaft und somit auf die Infotainmentdaten lesend und/oder schreibend zugegriffen werden. Dies ermöglicht einen besonders schnellen Zugriff auf die Infotainmentdaten und ermöglicht gleichzeitig eine besonders effiziente Speicherung der Infotainmentdaten .
In einer weiteren vorteilhaften Ausgestaltung des ersten Aspekts ist das Datenbankverwaltungssystem ausgebildet, abhängig von zumindest einer vorgegebenen Anweisung auf die entsprechende Eigenschaftswerttabelle zu zugreifen und den entsprechenden Datensatz mit der durch die Eigenschaftswerttabelle repräsentierten zumindest einen Tabelleneigenschaft zu rekonstruieren. Dabei ist das
Datenbankverwaltungssystem ferner ausgebildet, abhängig von der zumindest einen vorgegebenen Anweisung auf die zumindest eine Tabelleneigenschaft und/oder die zumindest eine weitere Eigenschaft des rekonstruierten Datensatzes zu zugreifen. Mittels der Eigenschaftswerttabelle kann besonders einfach der entsprechende Datensatz rekonstruiert werden, insbesondere mittels der Verwendung von SQL als vorgegebene Anweisung. Grundsätzlich sind aber auch proprietäre Anweisungen zur Rekonstruktion der Datensätze verwendbar.
In einer weiteren vorteilhaften Ausgestaltung des ersten Aspekts ist das Datenbankverwaltungssystem ausgebildet, abhängig von der zumindest einen vorgegebenen Anweisung die zumindest eine Eigenschaftswerttabelle mittels der Metadatentabelle zu ermitteln. Dies ermöglicht eine besonders effiziente Speicherung der Infotainmentdaten, da nicht für jeden möglichen Wert der zumindest einen Tabelleneigenschaft eine Eigenschaftswerttabelle vorgesehen werden muss. Somit referenziert die Metadatentabelle vorzugsweise nur die Eigenschaftswerttabellen, die die tatsächlich verwendeten
Werte der zumindest einen Tabelleneigenschaft repräsentieren. In einer weiteren vorteilhaften Ausgestaltung des ersten Aspekts repräsentiert die Eigenschaftswerttabelle zumindest einen booleschen Wert und/oder zumindest einen Wert einer vorgegebenen Wertemenge der zumindest einen Tabelleneigenschaft. Die vorgegebene Wertemenge umfasst nur eine vorgegebene Anzahl von unterschiedlichen Werten, die für die zumindest eine Tabelleneigenschaft verwendbar sind. Besonders bei einer begrenzten Anzahl unterschiedlicher möglicher Werte der zumindest einen Tabelleneigenschaft gewährleistet die Verwendung der Eigenschaftswerttabelle eine effiziente Speicherung der Datensätze.
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
Computerprogrammprodukt 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 Aspekts der Erfindung.
Die Erfindung ist im Folgenden anhand von schematischen Zeichnungen näher erläutert. Es zeigen:
Figur 1 ein Datenbanksystem,
Figur 2 eine erste Tabelle, Figur 3 mehrere Eigenschaftswerttabellen für boolesche Werte,
Figur 4 mehrere Eigenschaftswerttabellen und eine
Metadatentabelle,
Figur 5 mehrere Eigenschaftswerttabellen für mehrere boolesche Werte und eine Metadatentabelle,
Figur 6 eine weitere Metadatentabelle.
Elemente gleicher Konstruktion oder Funktion sind figurenübergreifend mit den gleichen Bezugszeichen gekennzeichnet .
Ein Infotainmentsystem (Figur 1) umfasst eine
Infotainmentvorrichtung INFO, ein Datenbankverwaltungssystem RDBMS und eine relationale Datenbank RDB. Das
Infotainmentsystem kann beispielsweise ein Navigationssystem 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 Infotainmentsystem kann zusätzlich oder alternativ aber auch ein Musiksystem umfassen und dazu ausgebildet sein, beispielsweise vorgegebene Musikstücke zu finden und abzuspielen.
Die Infotainmentvorrichtung INFO, die relationale Datenbank RDB und das Datenbankverwaltungssystem RDBMS können beispielsweise in einem technischen Gerät integriert sein, das beispielsweise in einem Kraftfahrzeug angeordnet ist. Alternativ können die Infotainmentvorrichtung INFO, die relationale Datenbank RDB und das Datenbankverwaltungssystem RDBMS auch Softwarefunktionseinheiten sein, die von dem technischen Gerät verwendet werden. Das technische Gerät kann beispielsweise ein Bordcomputer eines Kraftfahrzeugs und/oder ein Computer sein, beispielsweise ein tragbarer Computer, so z.B. ein Laptop sein. Das technische Gerät 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.
Die Infotainmentvorrichtung INFO kommuniziert mit dem Datenbankverwaltungssystem RDBMS. Das Datenbankverwaltungssystem RDBMS umfasst eine Anweisungsschnittstelle SQL IF, einen
Anweisungsbefehlsprozessor SQL_CMD_PRO, einen Pager PAGER, ein Verzeichnis ID LIB von Indexstrukturen und eine Betriebssystemschnittstelle OS_IF.
Das Datenbankverwaltungssystem RDBMS kommuniziert mit der relationalen Datenbank RDB. In der relationalen Datenbank RDB sind die Infotainmentdaten, so z.B. Navigationsdaten und/oder Musikdaten, gespeichert.
Die Infotainmentvorrichtung INFO kommuniziert mit dem
Datenbankverwaltungssystem RDBMS vorzugsweise derart, dass die Infotainmentvorrichtung 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 entsprechende 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 den
Anweisungsbefehlsprozessor SQL_CMD_PRO übergegeben.
Der Anweisungsbefehlsprozessor 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 dem
Anweisungsbefehlsprozessor 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
Betriebssystemschnittstelle 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 einen ersten, zweiten, dritten und vierten Datensatz aufweist. Jedem
Datensatz ist eine eindeutige Kennung PK und jeweils eine erste, eine zweite und eine dritte Eigenschaften A, B, C zugeordnet. Die jeweilige eindeutige Kennung PK repräsentiert den jeweiligen Datensatz. Beispielsweise weist der vierte Datensatz mit der eindeutigen Kennung PK 4 die erste
Eigenschaft a4, die zweite Eigenschaft b4 und die dritte Eigenschaft c4 auf. Vorzugsweise sind die Eigenschaften des jeweiligen Datensatzes als Datensatzattribute ausgebildet.
In Figur 3 sind die Werte der ersten Eigenschaft A des jeweiligen Datensatzes als boolesche Werte ausgebildet. So ist dem ersten, zweiten und dritten Datensatz jeweils ein boolescher Wert TRUE und dem vierten Datensatz ein boolescher Wert FALSE als erste Eigenschaft A zugeordnet. Die erste Eigenschaft A kann auch als Tabelleneigenschaft des jeweiligen Datensatzes bezeichnet werden.
In Figur 3 sind eine erste und eine zweite Eigenschaftswerttabelle R_A_TRUE, R_A_FALSE dargestellt. Die erste Eigenschaftswerttabelle R A TRUE repräsentiert den booleschen Wert TRUE der ersten Eigenschaft A. Die zweite Eigenschaftswerttabelle R A FALSE repräsentiert den booleschen Wert FALSE der ersten Eigenschaft A. Dabei sind die eindeutige Kennung PK, die zweite und dritte Eigenschaft B, C aller Datensätze der ursprünglichen Tabelle R, die als erste Eigenschaft A den booleschen Wert TRUE aufweisen der ersten Eigenschaftswerttabelle R A TRUE zugeordnet und die eindeutige Kennung PK, die zweite und dritte Eigenschaft B, C aller Datensätze der ursprünglichen Tabelle R, die als erste Eigenschaft A den booleschen Wert FALSE aufweisen der zweiten Eigenschaftswerttabelle R A FALSE zugeordnet. Da der vierte Datensatz der ursprünglichen Tabelle R als einziger den Wert FALSE als erste Eigenschaft A aufweist, sind nur dessen eindeutige Kennung PK und Eigenschaften B, C der zweiten Eigenschaftswerttabelle R A FALSE zugeordnet. Die eindeutige Kennung PK und die Eigenschaften B, C der übrigen Datensätze der ursprünglichen Tabelle R sind der ersten Eigenschaftswerttabelle R_A_TRUE zugeordnet. Der Wert der jeweiligen ersten Eigenschaft A wird durch die zugeordnete Eigenschaftswerttabelle R_A_TRUE, R_A_FALSE repräsentiert. Grundsätzlich ist es auch möglich, dass nur die jeweiligen eindeutigen Kennungen PK den jeweiligen Eigenschaftswerttabellen R_A_TRUE, R_A_FALSE zugeordnet sind.
Typischerweise werden neben der Speicherung der eigentlichen Werte der jeweiligen Eigenschaften vorzugsweise noch zusätzliche Metadaten je Eigenschaft, so z.B. ein oder zwei Byte Metadaten, in der relationalen Datenbank RDB reserviert. So weist beispielsweise der jeweils boolesche Wert der ersten Eigenschaft A nicht nur ein Bit auf, was für einen Wert TRUE oder FALSE ausreichend wäre, sondern noch zusätzliche Bytes für die zusätzlichen Metadaten. Ferner sind häufig Indizes von Eigenschaften der Datensätze in dem Verzeichnis ID LIB der Indexstrukturen in dem Datenbankverwaltungssystem RDBMS abgelegt, die vorzugsweise einen direkten und somit besonders schnellen Zugriff auf die jeweiligen Eigenschaften ermöglichen. Durch die Verwendung der Eigenschaftswerttabellen R_A_TRUE, R_A_FALSE kann dieser zusätzliche Speicherbedarf für die zusätzlichen Metadaten der zumindest einen Tabelleneigenschaft auf dem Speichermedium DC und für die jeweiligen Indizes der zumindest einen Tabelleneigenschaft in dem Verzeichnis ID_LIB der Indexstrukturen eingespart werden, was insbesondere bei einer hohen Anzahl von Datensätzen, so z.B. eine Million und mehr, einen besonders reduzierten Speicherbedarf in der relationalen Datenbank RDB und des
Datenbankverwaltungssystems RDBMS ermöglicht. Ferner wird durch den geringen Speicherbedarf auch die Zugriffszeit des Datenbankverwaltungssystems RDBMS auf die relationale Datenbank RDB reduziert und somit ein besonders schneller Zugriff auf die Infotainmentdaten gewährleistet.
Mit Hilfe der ersten und zweiten Eigenschaftswerttabelle R A TRUE, R A FALSE kann besonders einfach die ursprüngliche Tabelle R (Figur 2) rekonstruiert werden. So kann beispielsweise mittels der Anweisung SQL CMD
create view R as select PK, TRUE, B, C FROM R_A_TRUE union select PK, FALSE, B, C FROM R_A_FALSE
die ursprüngliche Tabelle R (Figur 2) rekonstruiert werden. Dabei stellen die Werte TRUE und FALSE in der ersten und zweiten select-Unteranweisung jeweils konstante Werte dar, die als Werte der jeweils ersten Eigenschaft A für die Rekonstruktion der ursprünglichen Tabelle R vorgegeben werden .
In Figur 4 nimmt die jeweils erste Eigenschaft A einen Wert einer vorgegebenen Wertemenge an, die beispielsweise die unterschiedlichen Werte el, e2, e3, e4 oder e5 umfasst.
Beispielsweise weist die erste Eigenschaften A des ersten und vierten Datensatzes den Wert e2 auf. Die erste Eigenschaft A des dritten Datensatzes weist den Wert el auf und die des zweiten Datensatzes den Wert e5. Die Werte e3 und e4 sind unbenutzt. Die eindeutige Kennung PK und die zweite und dritte Eigenschaft B, C der vier Datensätze der ursprünglichen Tabelle R sind in einer ersten, zweiten und dritten Eigenschaftswerttabelle R A el, R A e2, R A e5 in der relationalen Datenbank RDB gespeichert. So sind die eindeutige Kennung PK und die Eigenschaften B, C des ersten und vierten Datensatzes der ursprünglichen Tabelle R der zweiten Eigenschaftswerttabelle R A e2 zugeordnet, während die eindeutige Kennung PK und die Eigenschaften B, C des dritten Datensatzes der ursprünglichen Tabelle R der ersten Eigenschaftswerttabelle R_A_el und die eindeutige Kennung PK und die Eigenschaften B, C des zweiten Datensatzes der dritten Eigenschaftstabelle R_A_e5 zugeordnet sind. Zusätzlich ist eine Metadatentabelle R A MD dargestellt, die neben den Eigenschaftswerttabellen R_A_el, R_A_e2, R_A_e5 in der relationalen Datenbank RDB abgespeichert ist. Mittels der Metadatentabelle R_A_MD ist es möglich, abhängig von dem vorgegebenen Wert der ersten Eigenschaft A direkt die jeweilige Eigenschaftswerttabelle zu referenzieren . Wird beispielsweise während eines Lesezugriffs mittels der Anweisung SQL_CMD ein Wert e2 als Tabelleneigenschaft A vorgegeben, kann direkt die Eigenschaftswerttabelle R A e2 unter zur Hilfenahme der Metadatentabelle R_A_MD referenziert werden und danach auf die jeweils zweite und dritte
Eigenschaft B, C zugegriffen werden, beispielsweise mittels einer weiteren Anweisung SQL CMD. Dies hat den Vorteil, dass für die nicht verwendeten Werte e3, e4 der vorgegebenen Wertemenge keine jeweilige Eigenschaftswerttabelle abgespeichert werden muss. Auch das führt zu einem reduzierten Speicherbedarf, da auch jeder leeren, in der relationalen Datenbank RDB gespeicherten, Tabelle Metadaten zugeordnet sind, die durch die Verwendung der Metadatentabelle eingespart werden können.
Insbesondere bei Infotainmentdaten, die als Navigationsdaten ausgebildet sind, kommt es häufig vor, dass diese aktualisiert oder geändert werden müssen, so z.B. aufgrund geänderter Straßenführungen. Es kann durchaus vorkommen, dass auch die zumindest eine Tabelleneigenschaft des jeweiligen Datensatzes geändert wird. Dabei ist das Datenbankverwaltungssystem RDBMS ausgebildet, abhängig von der zumindest einen vorgegebenen Anweisung SQL CMD die weiteren Eigenschaften des entsprechenden Datensatzes in eine andere Eigenschaftswerttabelle umzukopieren oder zunächst eine neue zugeordnete Eigenschaftswerttabelle zu erstellen und danach die weiteren Eigenschaften des entsprechenden Datensatzes umzukopieren und danach die entsprechende Metadatentabelle anzupassen.
In Figur 5 wird die erste Eigenschaft A als erste Tabelleneigenschaft A und die zweite Eigenschaft B als zweite Tabelleneigenschaft B verwendet. Die erste wie auch die zweite Tabelleneigenschaft A, B nehmen jeweils boolesche Wert an. Daraus ergeben sich vier mögliche Kombinationen der ersten und zweiten Tabelleneigenschaft A, B. Ist beispielweise dem zweiten Datensatz der ursprünglichen Tabelle R als erste Eigenschaft A ein Wert TRUE und als zweite Eigenschaft B ein Wert FALSE zugeordnet, so ist nur noch die eindeutige Kennung PK und die dritte Eigenschaft C des zweiten Datensatzes der Eigenschaftswerttabelle R_A_TRUE_B_FALSE zugeordnet, die repräsentativ ist für den Wert der ersten und zweiten Eigenschaft A, B des zweiten Datensatzes. Ferner ist eine weitere Metadatentabelle R A B MD in der relationalen Datenbank RDB gespeichert, die abhängig von den Werten der ersten und zweiten Eigenschaft A, B die jeweilige Eigenschaftswerttabelle referenziert . Aufgrund der Verwendung der weiteren Metadatentabelle R_A_B_MD ist eine weitere Eigenschaftswerttabelle, die den nicht verwendeten Wert FALSE der ersten Eigenschaft A und den Wert FALSE der zweiten Eigenschaft B repräsentiert, nicht erforderlich. Mittels Verwendung der weiteren Metadatentabelle R_A_B_MD können somit zunächst alle gespeicherten Eigenschaftswerttabellen mittels beispielsweise einer ersten Anweisung
select VALUEA, VALUEB, RN from R_A_B_MD
ermittelt werden. Danach kann abhängig von dem Ergebnis der Ermittlung der ersten Anweisung mittels einer weiteren Anweisung
create view R as select PK, TRUE, TRUE, C from R_A_TRUE_B_TRUE union select PK, TRUE, FALSE, C from R_A_TRUE_B_FALSE union select PK, FALSE, TRUE, C from R_A_FALSE_B_TRUE
die ursprüngliche Tabelle R (Figur 2) rekonstruiert werden.
In Figur 6 ist eine Ortsmetadatentabelle
R_URBAN_SPEEPLIMIT_MD dargestellt, wie sie beispielsweise in Verbindung mit dem Navigationssystem des Infotainmentsystems verwendbar ist. Dabei wird abhängig von einer ersten Ortstabelleneigenschaft URBAN und einer zweiten Ortstabelleneigenschaft SPEEDLIMIT eine jeweilige Ortseigenschaftswerttabelle R_UR_TRUE_SL_NULL, R_UR_FALSE_SL_60, R_UR_TRUE_SL_30 , R_UR_FALSE_SL_30 referenziert, die nicht dargestellt ist. Dabei weist die erste Ortstabelleneigenschaft URBAN boolesche Wert auf und repräsentiert somit, ob eine mittels des Navigationssystems ermittelte aktuelle Position des Kraftfahrzeugs in einem Stadtgebiet liegt oder nicht. Die zweite Ortstabelleneigenschaft SPEEDLIMIT kann dabei vorzugsweise unterschiedliche ganzzahlige Werte und den Wert NULL annehmen und repräsentiert somit eine der ermittelten aktuellen Position des Kraftfahrzeugs zugeordnete Geschwindigkeitsbegrenzung. Der Wert NULL der zweiten Ortstabelleneigenschaft SPEEDLIMIT repräsentiert eine Nicht- Geschwindigkeitsbegrenzung an der ermittelten Position des Kraftfahrzeugs. Vorzugsweise nimmt die zweite Ortstabelleneigenschaft SPEEDLIMIT nur vorgegebene ganzzahlige Werte an, so z.B. 30, 50, 60, 70, 80, 90, 100, 120, so dass nur eine begrenzte Anzahl von Kombinationen der ersten und zweiten Ortstabelleneigenschaft URBAN, SPEEDLIMIT als mögliche Kombinationen verwendet werden. Somit werden nur für verwendete ganzzahlige Werte der zweiten Ortstabelleneigenschaft SPEEDLIMIT jeweils Ortseigenschaftswerttabellen angelegt. Ferner ist zu berücksichtigen, dass einige Eigenschaften vorzugsweise nicht kombinierbar sind, so z.B. eine Geschwindigkeitsbegrenzung von 120 km/h in dem Stadtgebiet. Beispielsweise wird der ermittelten aktuellen Position des Kraftfahrzeugs mittels eines Wertes TRUE der ersten Ortstabelleneigenschaft URBAN eine aktuelle Position in dem Stadtgebiet zugeordnet. Dieser ersten Ortstabelleneigenschaft URBAN ist beispielsweise mittels eines Wertes 60 der zweiten Ortstabelleneigenschaft SPEEDLIMIT eine zulässige Höchstgeschwindigkeit von 60 km/h für die aktuelle Position des Kraftfahrzeugs zuordnet. Dieser ersten und zweiten Ortstabelleneigenschaft URBAN, SPEEDLIMIT ist eine Ortseigenschaftswerttabelle R_UR_TRUE_SL_60 zugeordnet, in der weitere Eigenschaften gespeichert sind. Die Daten der jeweiligen Eigenschaftswerttabellen und die der jeweiligen Metadatentabellen sind vorzugsweise bezüglich ihrer Anordnung auf dem Speichermedium DC der relationalen Datenbank RDB zusammenhängend gespeichert. Dabei können die Daten der jeweiligen Eigenschaftswerttabellen und die der jeweiligen Metadatentabellen in unterschiedlichen Speicherbereichen auf dem Speichermedium DC zusammenhängend abgespeichert sein.
Grundsätzlich können auch mehr als zwei Eigenschaften einer Tabelle als Tabelleneigenschaften verwendet werden, wobei der Werte jeder Tabelleneigenschaft als boolescher Wert oder als ganzzahliger Wert oder als Wert der vorgegebenen Wertemenge oder als ein anderer Wert eines möglichen Datentyps ausgebildet sein kann. Auch ist bei der Verwendung mehrerer Tabelleneigenschaften eine beliebige Kombinationen unterschiedlicher Datentypen der Werte der jeweiligen Tabelleneigenschaften möglich. Auch können mehrere Metadatentabellen in der relationalen Datenbank RDB gespeichert sein und mehrere unterschiedliche Eigenschaftswerttabellen referenzieren .

Claims

Patentansprüche
1. Infotainmentsystem, das eine relationale Datenbank (RDB), die auf einem Speichermedium (DC) gespeichert ist, und ein Datenbankverwaltungssystem (RDBMS) umfasst und dazu ausgebildet ist, auf Infotainmentdaten zu zugreifen, die in der relationalen Datenbank (RDB) als Datensätze abgespeichert sind, wobei ein Datensatz eine eindeutige Kennung (PK) des Datensatzes und zumindest eine Tabelleneigenschaft (A) aufweist, wobei zumindest die eindeutige Kennung (PK) des jeweiligen Datensatzes in einer Eigenschaftswerttabelle in der relationalen Datenbank (RDB) gespeichert ist, die einen entsprechenden Wert der Tabelleneigenschaft (A) des jeweiligen Datensatzes repräsentiert.
2. Infotainmentsystem nach Anspruch 1, bei dem der jeweilige Datensatz die eindeutige Kennung (PK) des Datensatzes und die zumindest eine Tabelleneigenschaft (A) und zumindest eine weitere Eigenschaft (C) aufweist, wobei die eindeutige Kennung (PK) und die zumindest eine weitere Eigenschaft (C) des jeweiligen Datensatzes in der Eigenschaftswerttabelle gespeichert sind.
3. Infotainmentsystem nach Anspruch 1 oder 2, bei dem in der relationalen Datenbank (RDB) Tabellendatensätze zumindest einer Metadatentabelle (R_A_MD) gespeichert sind, mittels der abhängig von dem entsprechenden Wert der zumindest einen Tabelleneigenschaft (A) des jeweiligen Datensatzes die entsprechende Eigenschaftswerttabelle referenzierbar ist.
4. Infotainmentsystem nach einem der vorstehenden Ansprüche, bei dem das Datenbankverwaltungssystem (RDBMS) ausgebildet ist,
- abhängig von zumindest einer vorgegebenen Anweisung (SQL CMD) auf die entsprechende Eigenschaftswerttabelle zu zugreifen und den entsprechenden Datensatz mit der durch die Eigenschaftswerttabelle repräsentierten zumindest einen Tabelleneigenschaft (A) zu rekonstruieren, - abhängig von zumindest einer vorgegebenen Anweisung (SQL CMD) auf die zumindest eine Tabelleneigenschaft (A) und/oder die zumindest eine weitere Eigenschaft (C) des rekonstruierten Datensatzes zu zugreifen.
5. Infotainmentsystem nach Anspruch 3 oder 4, bei dem das Datenbankverwaltungssystem (RDBMS) ausgebildet ist, abhängig von der zumindest einen vorgegebenen Anweisung (SQL CMD) die zumindest eine Eigenschaftswerttabelle mittels der Metadatentabelle (R A MD) zu ermitteln.
6. Infotainmentsystem nach einem der vorstehenden Ansprüche, bei dem die Eigenschaftswerttabelle zumindest einen booleschen Wert und/oder zumindest einen Wert einer vorgegebenen Wertemenge der zumindest einen Tabelleneigenschaft (A) repräsentiert.
7. Infotainmentsystem nach einem der vorstehenden Ansprüche, bei dem die vorgegebene Anweisung (SQL_CMD) als SQL-Anweisung ausgebildet ist.
8. 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 7.
PCT/EP2009/061747 2008-09-19 2009-09-10 Infotainmentsystem und computerprogrammprodukt Ceased WO2010031728A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP09782866A EP2329416A1 (de) 2008-09-19 2009-09-10 Infotainmentsystem und computerprogrammprodukt
US13/119,874 US20110231438A1 (en) 2008-09-19 2009-09-10 Infotainment System And Computer Program Product

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102008047915.2 2008-09-19
DE102008047915A DE102008047915B4 (de) 2008-09-19 2008-09-19 Infotainmentsystem und Computerprogrammprodukt

Publications (1)

Publication Number Publication Date
WO2010031728A1 true WO2010031728A1 (de) 2010-03-25

Family

ID=41211688

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2009/061747 Ceased WO2010031728A1 (de) 2008-09-19 2009-09-10 Infotainmentsystem und computerprogrammprodukt

Country Status (4)

Country Link
US (1) US20110231438A1 (de)
EP (1) EP2329416A1 (de)
DE (1) DE102008047915B4 (de)
WO (1) WO2010031728A1 (de)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102011109917B3 (de) 2011-08-10 2012-10-25 Audi Ag Verfahren zum Bereitstellen einer Signalausgabe auf Grundlage einer Hauptdatei und zumindest einer Nebendatei, sowie Fahrzeug
EP2784699A1 (de) 2013-03-29 2014-10-01 Pilab S.A. Computerimplementiertes Verfahren zum Speichern unbegrenzter Datenmengen als Mind-Map in relationalen Datenbanksystemen
EP2819030A1 (de) 2013-06-30 2014-12-31 Pilab S.A. Datenbankhierarchieunabhängiges Data-Drilling
EP2843568A1 (de) 2013-08-30 2015-03-04 Pilab S.A. Computerimplementiertes Verfahren zur Erzeugung von Datenbankstrukturen ohne Kenntnisse der Funktionsfähigkeit eines relationalen Datenbanksystems
EP2843567B1 (de) 2013-08-30 2017-05-10 Pilab S.A. Computerimplementiertes Verfahren zur Verbesserung der Anfrageausführung in relationalen, Level 4 oder höher normalisierten Datenbanken
WO2017186774A1 (en) 2016-04-26 2017-11-02 Pilab S.A. Systems and methods for querying databases

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5799310A (en) * 1995-05-01 1998-08-25 International Business Machines Corporation Relational database extenders for handling complex data types
US6108664A (en) 1997-10-31 2000-08-22 Oracle Corporation Object views for relational data
US20020174124A1 (en) * 2001-04-16 2002-11-21 Haas Robert P. Spatially integrated relational database model with dynamic segmentation (SIR-DBMS)
US20080126389A1 (en) * 2006-11-27 2008-05-29 Eyal Mush Schema modeler for generating an efficient database schema

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ATE239257T1 (de) * 1994-09-01 2003-05-15 Computer Ass Think Inc System und verfahren für die x.500-datenbanknorm
US6035264A (en) * 1996-11-26 2000-03-07 Global Maintech, Inc. Electronic control system and method for externally controlling process in a computer system with a script language
US7020697B1 (en) * 1999-10-01 2006-03-28 Accenture Llp Architectures for netcentric computing systems
AU2001226401A1 (en) * 2000-01-14 2001-07-24 Saba Software, Inc. Method and apparatus for a business applications server
JP2002082815A (ja) * 2000-09-07 2002-03-22 Oki Electric Ind Co Ltd タスクプログラム制御システム
US20020069402A1 (en) * 2000-10-05 2002-06-06 Nevill Edward Colles Scheduling control within a system having mixed hardware and software based instruction execution
US20030208493A1 (en) * 2002-04-12 2003-11-06 Hall Bradley S. Object relational database management system
US6952692B1 (en) * 2002-05-17 2005-10-04 Ncr Corporation Execution of requests in a parallel database system
US20040036719A1 (en) * 2002-08-26 2004-02-26 Van Treeck George Michael Quicker development of database applications having a graphical user interface
US7779039B2 (en) * 2004-04-02 2010-08-17 Salesforce.Com, Inc. Custom entities and fields in a multi-tenant database system
US7317974B2 (en) * 2003-12-12 2008-01-08 Microsoft Corporation Remote vehicle system management
US7222133B1 (en) * 2004-02-05 2007-05-22 Unisys Corporation Method for reducing database recovery time
US20060015580A1 (en) * 2004-07-01 2006-01-19 Home Box Office, A Delaware Corporation Multimedia content distribution
US20060195460A1 (en) * 2005-02-28 2006-08-31 Microsoft Corporation Data model for object-relational data
US8010969B2 (en) * 2005-06-13 2011-08-30 Intel Corporation Mechanism for monitoring instruction set based thread execution on a plurality of instruction sequencers
DE102006004693A1 (de) * 2006-01-31 2007-08-09 Siemens Ag Navigationssystem, Verfahren und Computerprogrammprodukt zum Betreiben des Navigationssystems
DE102006017169B4 (de) * 2006-04-12 2018-09-20 Audi Ag Verfahren zum Bereitstellen von Informationen in einem Fahrzeug
US7917253B2 (en) * 2006-11-22 2011-03-29 General Motors Llc Method for making vehicle-related data available to an authorized third party
US9865240B2 (en) * 2006-12-29 2018-01-09 Harman International Industries, Incorporated Command interface for generating personalized audio content
WO2008137855A2 (en) * 2007-05-03 2008-11-13 Hti Ip, Llc Methods, systems, and apparatuses for telematics navigation
JP4975544B2 (ja) * 2007-07-20 2012-07-11 富士通セミコンダクター株式会社 シミュレーション装置及びプログラム
US8312104B2 (en) * 2008-07-01 2012-11-13 General Motors Llc Interactive information dissemination and retrieval system and method for generating action items

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5799310A (en) * 1995-05-01 1998-08-25 International Business Machines Corporation Relational database extenders for handling complex data types
US6108664A (en) 1997-10-31 2000-08-22 Oracle Corporation Object views for relational data
US20020174124A1 (en) * 2001-04-16 2002-11-21 Haas Robert P. Spatially integrated relational database model with dynamic segmentation (SIR-DBMS)
US20080126389A1 (en) * 2006-11-27 2008-05-29 Eyal Mush Schema modeler for generating an efficient database schema

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
"Ashish Gupta", 1999, THE MIT PRESS CAMBRIDGE, article "Materialized Views-Techniques, Implementations, and Applications"
BELLO R G ET AL: "Materialized views in Oracle", PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON VERY LARGEDATA BASES, XX, XX, 24 August 1998 (1998-08-24), pages 659 - 664, XP002233164 *
BLAKELEY J A ET AL: "Join index, materialized view, and hybrid-hash join: a performance analysis", PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON DATA ENGINEERING. LOS ANGELES, FEB. 5 - 9, 1990; [PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON DATA ENGINEERING], LOS ALAMITOS, IEEE. COMP. SOC. PRESS, US, vol. CONF. 6, 5 February 1990 (1990-02-05), pages 256 - 263, XP010018213, ISBN: 978-0-8186-2025-6 *
GUPTA ASHISH ET AL: "Materialized Views; Techniques, Implementations, and Applications, Applications of Materialized Views, Challenges in Supporting Materialized Views, Algorithms for Deferred View Maintenance", MATERIALIZED VIEWS : TECHNIQUES, IMPLEMENTATIONS, AND APPLICATIONS, THE MIT PRESS, CAMBRIDGE, MASSACHUSETTS, 1 January 1999 (1999-01-01), pages 13 - 48,209, XP002539151, ISBN: 978-0-262-57122-7 *
JOSE A. BLAKELEY ET AL.: "Computer Science Department", 1990, INDIANS UNIVERSITY, article "Join Index, Materialized Views, and Hybrid-Hash Join: A Performance Analysis"
RANDALL G. BELLO ET AL.: "Materialized Views in Oracle", PROCEEDINGS OF THE 24TH VLDB CONFERENCE NEW YORK, USA, 1998

Also Published As

Publication number Publication date
EP2329416A1 (de) 2011-06-08
US20110231438A1 (en) 2011-09-22
DE102008047915A1 (de) 2010-03-25
DE102008047915B4 (de) 2010-05-12

Similar Documents

Publication Publication Date Title
DE112010004677B4 (de) Anwendungsprogrammierschnittstelle (API) für Navigationsanwendungen, die inkrementierte Aktualisierungen mit einer bestehenden Datenbasis einer Karte verbindet
DE10211606B4 (de) Datenverarbeitungseinrichtung mit einem Metadatensicherungsmanagement
DE69229121T2 (de) Verfahren und vorrichtung zur herstellung einer cd-rom-disc zur verwendung mit merhfachbetriebsystemen
DE69031494T2 (de) Verfahren zum lesen und schreiben von dateien auf nichtlöschbaren speichermedien
DE102008047915B4 (de) Infotainmentsystem und Computerprogrammprodukt
DE69431499T2 (de) Meta-data-Struktur und Handhabung
DE112013000900B4 (de) Bewahren von Redundanz in Datendeduplizierungssystemen unter Verwendung eines Anzeigers
DE112012000280B4 (de) Organisation von Tabellen mit reduzierten Indizes
DE112018004222T5 (de) Datenbankaufteilung
DE60112257T2 (de) Virtuelles Dateisystem für dynamisch erzeugte Webseiten
DE69600754T2 (de) Aufteilung einer Teilung in einem Plattenspeichersystem
DE202010018481U1 (de) Asynchroner verteilter Objekt-Upload für replizierte Assoziativspeichercluster
DE102020115969A1 (de) Speichervorrichtungen, speichersysteme und verfahren zum betreiben von speichervorrichtungen
DE112010004264T5 (de) Selektiver Schreibschutz für das Austesten der Wiederherstellung nach einem Absturz
EP1067460A1 (de) Datenträger mit wiederherstellbarem Basisdatengrundzustand und Verfahren zu dessen Herstellung
DE112018000227B4 (de) Verfahren zum teilweisen Aktualisieren von Dateninhalten in einem verteilten Speichernetzwerk
DE60210118T2 (de) Sicherheitseinrichtung für eine massenspeicherung
WO2010060763A1 (de) Infotainmentsystem und computerprogrammprodukt
DE102015114721B4 (de) Verfahren, Gerät und System zur Datenverarbeitung
DE102023116322A1 (de) Fingerabdruck-verfolgungsstruktur für speichersystem
DE112009005021T5 (de) Datenaufzeichungseinrichtung und audiosystem
WO2010060764A1 (de) Infotainmentsystem und computerprogrammprodukt
EP4198760B1 (de) Verfahren zur verarbeitung von signaldaten
EP2037360A2 (de) Steuergerät für einen Massenspeicher und Verfahren zum Bereitstellen von Daten für einen Startvorgang eines Computers
DE102012006457A1 (de) Verfahren zum Verschlüsseln von Daten auf einem Speichermedium

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09782866

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2009782866

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 13119874

Country of ref document: US