EP2370913A1 - Infotainmentsystem und computerprogrammprodukt - Google Patents

Infotainmentsystem und computerprogrammprodukt

Info

Publication number
EP2370913A1
EP2370913A1 EP09745063A EP09745063A EP2370913A1 EP 2370913 A1 EP2370913 A1 EP 2370913A1 EP 09745063 A EP09745063 A EP 09745063A EP 09745063 A EP09745063 A EP 09745063A EP 2370913 A1 EP2370913 A1 EP 2370913A1
Authority
EP
European Patent Office
Prior art keywords
identifier
sub
data
record
unique
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP09745063A
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 EP2370913A1 publication Critical patent/EP2370913A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/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 can 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, which is stored on a storage medium and comprises a database management system.
  • the database management system is configured to access infotainment data stored in the relational database as records of a first record type and as records of a second record type.
  • Each record of the first record type has an identifier value of a unique first identifier, a respective property value of at least one first property and a respective sub-identifier value of at least one sub-identifier.
  • Each record of the second record type has an identifier value of a unique second identifier and a respective attribute value of at least one second attribute.
  • the unique first identifier, the at least one first property and the at least one associated subrecognition are assigned to a first main table.
  • the unique second identifier and the at least one second property are assigned to a second main table. Tuples of property values of the second property associated with the second main table are only stored once each in the second main table.
  • the sub-identifier values of the at least one sub-identifier and the associated identifier values of the unique second identifier are stored in at least one sub-table. This helps to reduce redundancy of property values in the second main table associated with a respective record of the second record type.
  • the first and second main tables preferably have at least one unique identifier and at least one property.
  • the at least one sub-table has the at least one sub-identifier and the unique second identifier.
  • the first and second main tables and the at least one subtable each have columns and rows. Each column is associated with a property or a unique identifier or subrecognition, and the respective row represents a respective record of the respective table.
  • the sub-identification values of the at least one sub-identifier represents, with the aid of the at least one subtable, a reference of the respective row of the first main table to the associated respective row of the second main table.
  • a tuple denotes a combination of property values associated with a row of the second main table. Tuples of the property values may include one or more property values associated with a row of the second main table. If only one property is assigned to the second main table, the respective property value of the property is stored only once in the second main table. If, on the other hand, a plurality of properties are assigned to the second main table, a combination of the assigned property values assigned to a row of the second data record type is stored only once in the second main table.
  • the first and second main tables are assigned several first and second properties, respectively.
  • the first properties are functionally independent of each other and the second properties are functionally independent of each other. That the first and second main tables are normalized according to the third normal form, respectively.
  • the data sets can be stored on the storage medium of the relational database in a particularly efficient and low-memory manner.
  • the relational database and the database management system can be integrated as a functional unit in the infotainment system of a motor vehicle, for example the infotainment system in the motor vehicle is preferably designed as an embedded system. 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 determine a data record of the first or second data record type associated with a data record of the second or first data record type, to assist the at least one sub-table. This contributes to the fact that the corresponding data records can be quickly referenced by means of the at least one sub-table and at the same time the property values can be efficiently stored on the storage medium of the relational database.
  • 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 comprises 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 shows several original tables
  • FIG. 3a shows two main tables and one sub-table
  • FIG. 3b shows an alternative subtable
  • Figure 4 two main and two 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 is 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 relational database RDB are the infotainment data, such. As 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
  • 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 that 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 a first, a second and a third original table R1, R2, R3.
  • the first original table R1 has ten data records, each data record being represented by a respective identifier value of a unique first identifier PK1.
  • the second original table R2 has four data records which are each represented by an identifier value of a unique second identifier PK2.
  • the first record of the first original table R1 is associated with the first and second records of the second original table R2.
  • the assignment takes place by means of the third original table R3 in which the identifier values of the unique first identifier PK1 and the associated identifier values of the unique second identifier PK2 are stored.
  • the first original table R1 has the first properties Al, Bl, Cl, which are functionally independent of each other.
  • the second original table R2 has the second properties D2, E2, which are also functionally independent of one another.
  • the first and second original tables R1, R2 are preferably normalized according to the third normal form of the database theory.
  • MR1 data records of a first data record type are stored in a first main table.
  • Each record of the first record type has the unique first identifier PK1, the first properties Al, Bl, Cl and additionally a subrecognition PID.
  • Each data record of the first data type is represented by the respective identifier value of the unique first identifier PK1.
  • records of a second record type are stored.
  • Each record of the second record type has the unique second identifier PK2 and the second properties D2, E2.
  • Each data record of the second data type is represented by the respective identifier value of the unique second identifier PK2.
  • each record The properties of each record are uppercase, while property values of the properties are lowercase.
  • a property is assigned a column and a row is assigned to each record.
  • the first properties Al, Bl, Cl of the first main table MR1 are functionally independent of one another, and the second properties D2, E2 of the second main table MR2 are functionally independent of one another. Tuples of the property values, which are each assigned to a data record of the second data record type and thus to the second main table MR2, are stored only once in the second main table MR2.
  • a sub-table PR is shown in FIG. 3a.
  • the sub-table PR is assigned the sub-identifier PID and the unique second identifier PK2 assigned to this sub-identifier PID to the second main table MR2.
  • the unique second identifier PK2 is designed as a complex data type because of multiple assignments of identifier values of the second identifier PK2.
  • the subtable PR according to FIG. 3b can also be used.
  • the latter assigns exactly one identification value of the unique second identifier PK2 to each sub-identifier value of the sub-identifier PID in one line and is therefore accessible with each configuration of a database management system RDBMS.
  • the sub-tag values of the additional sub-tag PID in the first main table MR1 and the sub-tag values and the tag values stored in the sub-table PR according to Figure 3a or Figure 3b replace the tag values of the third original table R3 in Figure 2. This results in following memory space savings.
  • the additional subcode PID with 10 subrecognizable values requires a memory requirement of 10
  • the first main table MR1 is assigned the unique first identifier PK1, the first properties A1, C1, the sub-identifier PID and an additional identifier SID.
  • the second main table MR2 is assigned the unique second identifier PK2 and the second properties D2, E2.
  • a respective combination of the property values, which are each assigned to a data record of the second data record type, is stored only once in the second main table MR2.
  • the subtable PR and another table SR are shown.
  • the subtable PR is designed analogously to the subtable from FIG. 3b.
  • the further table SR comprises the property values b of the first property Bl and is thus assigned to the first main table MR1.
  • a property value b of the first property B is only stored once in the further table SR.
  • the property values which are assigned to the further table SR and which are assigned to the second main table MR2 can be stored particularly efficiently in the relational database RDB.
  • POI POI
  • CAT_ID Category
  • POI2Category POI ID, CAT ID
  • the records of the original tables may be the following main tables POI, Category and the sub-table PR
  • POI POI_ID, name, address, longitude, latitude, ..., PID
  • Category CAT_ID, icon, parent_category, (7) PR (PID, CAT_ID)
  • the sub-identifier PID the two main tables referenced to each other.

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 Infotainmentdaten umfasst, die in einer relationalen Datenbank (RDB) als Datensätze eines ersten und zweiten Datensatztyps gespeichert sind. Jeder Datensatz des ersten Datensatztyps umfasst eine eindeutige erste Kennung (PK1), Eigenschaftswerte (a1-c1) einer ersten Eigenschaft (A1-C1) und eine Unterkennung (PID). Jeder Datensatz des zweiten Datensatztyps umfasst eine eindeutige zweite Kennung (PK2) und Eigenschaftswerte (d2, e2) einer zweiten Eigenschaft (D2, E2). Die erste Kennung (PK1), die erste Eigenschaft (A1-C1) und die zugeordnete Unterkennung (PID) sind einer ersten Haupttabelle (MR1) zugeordnet. Die zweite Kennung (PK2) und die zweite Eigenschaft (D2, E2) sind einer zweiten Haupttabelle (MR2) zugeordnet. Dabei ist ein Eigenschaftswert bei nur einer zweiten Eigenschaft oder eine Kombination der Eigenschaftswerte (d2, e2) bei mehreren zweiten Eigenschaften nur jeweils einmal in der zweiten Haupttabelle (MR2) gespeichert. Die Unterkennungen (PID) und die zweite Kennungen (PK2) sind in zumindest einer Untertabelle (PR) gespeichert.

Description

Beschreibung
Infotainmentsystem und Computerprogrammprodukt
Die Erfindung betrifft ein Infotainmentsystem und ein Computerprogrammprodukt zum Betreiben des Infotainmentsystems .
Infotainmentsysteme sind beispielsweise in modernen Kraft- fahrzeugen 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 um- fasst.
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 Datenbankverwaltungssystem umfasst. Das Datenbankverwaltungssystem ist ausgebildet, auf Infotainmentdaten zu zugreifen, die in der relationalen Datenbank als Datensätze eines ersten Daten- satztyps und als Datensätze eines zweiten Datensatztyps gespeichert sind. Jeder Datensatz des ersten Datensatztyps weist einen Kennungswert einer eindeutigen ersten Kennung, einen jeweiligen Eigenschaftswert zumindest einer ersten Eigenschaft und jeweils einen Unterkennungswert zumindest einer Unterkennung auf. Jeder Datensatz des zweiten Datensatztyps weist einen Kennungswert einer eindeutigen zweiten Kennung und einen jeweiligen Eigenschaftswert zumindest einer zweiten Eigenschaft auf. Die eindeutige erste Kennung, die zumindest eine erste Eigenschaft und die zumindest eine zugeordnete Un- terkennung sind einer ersten Haupttabelle zugeordnet. Die eindeutige zweite Kennung und die zumindest eine zweite Eigenschaft sind einer zweiten Haupttabelle zugeordnet. Tupel von Eigenschaftswerten der zweiten Eigenschaft, die der zweiten Haupttabelle zugeordnet sind, sind nur jeweils einmal in der zweiten Haupttabelle gespeichert. Die Unterkennungswerte der zumindest einen Unterkennung und die zugeordneten Ken- nungswerte der eindeutigen zweiten Kennung sind in zumindest einer Untertabelle gespeichert. Dies trägt dazu bei, dass Redundanzen von Eigenschaftswerten in der zweiten Haupttabelle, die einem jeweiligen Datensatz des zweiten Datensatztyps zugeordnet sind, reduziert werden.
Die erste und zweite Haupttabelle weisen vorzugsweise zumindest eine eindeutige Kennung und zumindest eine Eigenschaft auf. Die zumindest eine Untertabelle weist die zumindest eine Unterkennung und die eindeutige zweite Kennung auf. Die erste und zweite Haupttabelle und die zumindest eine Untertabelle weisen jeweils Spalten und Zeilen auf. Eine Spalte ist jeweils einer Eigenschaft oder einer eindeutigen Kennung oder einer Unterkennung zugeordnet und die jeweilige Zeile repräsentiert einen jeweiligen Datensatz der jeweiligen Tabelle. Die Unterkennungswerte der zumindest einen Unterkennung stellt unter zur Hilfenahme der zumindest einen Untertabelle eine Referenz der jeweiligen Zeile der ersten Haupttabelle zu der zugeordneten jeweiligen Zeile der zweiten Haupttabelle dar .
Dabei bezeichnet ein Tupel eine Kombination von Eigenschaftswerten, die einer Zeile der zweiten Haupttabelle zugeordnet sind. Tupel der Eigenschaftswerte können einen oder mehrere Eigenschaftswerte umfasst, die einer Zeile der zweiten Haupt- tabelle zugeordnet sind. Ist der zweiten Haupttabelle nur eine Eigenschaft zugeordnet, so ist der jeweilige Eigenschaftswert der Eigenschaft nur einmal in der zweiten Haupttabelle gespeichert. Sind dagegen der zweiten Haupttabelle mehrere Eigenschaften zugeordnet, so ist eine Kombination der zuge- ordneten Eigenschaftswerte, die einer Zeile des zweiten Datensatztyps zugeordnet ist, nur jeweils einmal in der zweiten Haupttabelle gespeichert.
Vorzugsweise sind der ersten bzw. zweiten Haupttabelle mehre- re erste bzw. zweite Eigenschaften zugeordnet. Dabei sind die ersten Eigenschaften funktional unabhängig voneinander und die zweiten Eigenschaften funktional unabhängig voneinander. D.h. die erste und zweite Haupttabelle sind jeweils gemäß der dritten Normalform normalisiert.
Dadurch können die Datensätze besonders effizient und mit geringem Speicherbedarf auf dem Speichermedium der relationalen Datenbank abgespeichert werden. Eine Speicherplatzeinsparung ist umso größer, je größer die Anzahl der Spalten ist, die der zweiten Haupttabelle zugeordnet ist und je kleiner die
Anzahl der Zeilen dieser zweiten Haupttabelle ist. Dabei kann aber eine Redundanz von Eigenschaftswerten, die einer Eigenschaft zugeordnet sind, weiterhin vorliegen.
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, unter zur Hilfe- nähme der zumindest einen Untertabelle einen Datensatz des ersten bzw. zweiten Datensatztyps zu ermitteln, der einem Datensatz des zweiten bzw. ersten Datensatztyps zugeordnet ist. Dies trägt dazu bei, dass die entsprechenden Datensätze mittels der zumindest einen Untertabelle schnell referenzierbar sind und gleichzeitig die Eigenschaftswerte effizient auf dem Speichermedium der relationalen Datenbank gespeichert werden können .
In einer weiteren vorteilhaften Ausgestaltung des ersten As- pekts 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 mehrere ursprüngliche Tabellen, Figur 3a zwei Haupt- und eine Untertabelle,
Figur 3b eine alternative Untertabelle,
Figur 4 zwei Haupt- und zwei 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 Daten- bank 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 Anweisungsrecheneinheit 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 erste, eine zweite und eine dritte ursprüngliche Tabelle Rl, R2, R3 dargestellt. Mittels dieser drei Tabellen Rl, R2, R3 werden n zu m Beziehung zwischen Datensätzen ermöglicht. Die erste ursprüngliche Tabelle Rl weist zehn Datensätze auf, wobei jeder Datensatz durch jeweils einen Kennungswert einer eindeutigen ersten Kennung PKl repräsentiert wird. Die zweite ursprüngliche Tabelle R2 weist vier Datensätze auf, die jeweils durch einen Kennungswert einer eindeutigen zweiten Kennung PK2 repräsentiert werden. Beispielsweise ist der erste Datensatz der ersten ursprünglichen Tabelle Rl dem ersten und zweiten Datensatz der zweiten ursprünglichen Tabelle R2 zugeordnet. Die Zuordnung erfolgt mittels der dritten ursprünglichen Tabelle R3, in der die Kennungswerte der eindeutigen ersten Kennung PKl und die zu- geordneten Kennungswerte der eindeutigen zweiten Kennung PK2 gespeichert sind. Die erste ursprüngliche Tabelle Rl weist die ersten Eigenschaften Al, Bl, Cl auf, die funktional unabhängig voneinander sind. Die zweite ursprüngliche Tabelle R2 weist die zweiten Eigenschaften D2, E2 auf, die ebenfalls funktional unab- hängig voneinander sind. Die erste und zweite ursprüngliche Tabelle Rl, R2 sind vorzugsweise gemäß der dritten Normalform der Datenbanktheorie normalisiert.
Gemäß einer ersten Ausführungsform (Figur 3a und 3b) sind in einer ersten Haupttabelle MRl Datensätze eines ersten Datensatztyps gespeichert. Jeder Datensatz des ersten Datensatztyps weist die eindeutige erste Kennung PKl, die ersten Eigenschaften Al, Bl, Cl und zusätzlich eine Unterkennung PID auf. Jeder Datensatz des ersten Datentyps wird durch den je- weiligen Kennungswert der eindeutigen ersten Kennung PKl repräsentiert. In einer zweiten Haupttabelle MR2 sind Datensätze eines zweiten Datensatztyps gespeichert. Jeder Datensatz des zweiten Datensatztyps weist die eindeutige zweite Kennung PK2 und die zweiten Eigenschaften D2, E2 auf. Jeder Datensatz des zweiten Datentyps wird durch den jeweiligen Kennungswert der eindeutigen zweiten Kennung PK2 repräsentiert.
Die Eigenschaften der jeweiligen Datensätze sind in Großbuchstaben gekennzeichnet, während Eigenschaftswerte der Eigen- Schäften in Kleinbuchstaben gekennzeichnet sind. Einer Eigenschaft ist jeweils eine Spalte zugeordnet und einem jeweiligen Datensatz ist eine Zeile der jeweiligen Tabelle zugeordnet .
Die ersten Eigenschaften Al, Bl, Cl der ersten Haupttabelle MRl sind funktional unabhängig voneinander und die zweiten Eigenschaften D2, E2 der zweiten Haupttabelle MR2 sind funktional unabhängig voneinander. Tupel der Eigenschaftswerte, die jeweils einem Datensatz des zweiten Datensatztyps und so- mit der zweiten Haupttabelle MR2 zugeordnet sind, sind jeweils nur einmal in der zweiten Haupttabelle MR2 gespeichert. Ferner ist in Figur 3a eine Untertabelle PR dargestellt. Der Untertabelle PR sind die Unterkennung PID und die dieser Un- terkennung PID zugeordnete eindeutige zweite Kennung PK2 der zweiten Haupttabelle MR2 zugeordnet. Mittels der Untertabelle PR erfolgt die Zuordnung des jeweiligen Datensatzes des ersten Datensatztyps zu dem jeweiligen Datensatz des zweiten Datensatztyps und umgekehrt. Dabei ist in der Untertabelle PR die eindeutige zweite Kennung PK2, aufgrund von Mehrfachzuordnungen von Kennungswerten der zweiten Kennung PK2, als komplexer Datentypen ausgebildet. Komplexe Datentypen mit
Mehrfachzuordnungen sind allerdings nicht von jeder Ausbildung eines Datenbankverwaltungssystems RDBMS zugreifbar.
Alternativ zu der Untertabelle PR in Figur 3a ist auch die Untertabelle PR gemäß Figur 3b verwendbar. Diese weist in einer Zeile jedem Unterkennungswert der Unterkennung PID genau einen Kennungswert der eindeutigen zweiten Kennung PK2 zu und ist somit mit jeder Ausbildung eines Datenbankverwaltungssystems RDBMS zugreifbar.
Die Unterkennungswerte der zusätzlichen Unterkennung PID in der ersten Haupttabelle MRl und die Unterkennungswerte und die Kennungswerte, die in der Untertabelle PR gemäß der Figur 3a oder gemäß der Figur 3b gespeichert sind, ersetzen die Kennungswerte der dritten ursprünglichen Tabelle R3 in Figur 2. Dadurch ergibt sich folgende Speicherplatzeinsparung. Die ursprüngliche Tabelle R3 in Figur 2 benötigt bei 17 Einträgen zu je zwei Kennungswerten einen Speicherbedarf von 2 x 17 = 34 Speichereinheiten. Die zusätzliche Unterkennung PID mit 10 Unterkennungswerten benötigt einen Speicherbedarf von 10
Speichereinheiten. Die Untertabelle PR gemäß der Figur 3b benötigt bei 6 Einträgen zu je einem Unterkennungswert und einem Kennungswert einen Speicherbedarf von 2 x 6 = 12 Speichereinheiten. Daraus resultiert ein summierter Speicherbe- darf von 10 + 12 = 22 Speichereinheiten. Dabei ist vorausgesetzt, dass die Unterkennung PID und die eindeutige erste und zweite Kennung PKl, PK2 als gleiche Datentypen, so z.B. INTEGER, definiert sind. Somit ergibt sich gemäß der Daten- strukturierung in Figur 3a und 3b zumindest eine Speicherplatzeinsparung von 10 Speichereinheiten im Vergleich zu dem Speicherbedarf, die eine Datenstrukturierung gemäß der Figur 2 erfordern würde.
Gemäß einer zweiten Ausführungsform (Figur 4) sind der ersten Haupttabelle MRl die eindeutige erste Kennung PKl, die ersten Eigenschaften Al, Cl, die Unterkennung PID und eine Zusatz- kennung SID zugeordnet. Der zweiten Haupttabelle MR2 sind die eindeutige zweite Kennung PK2 und die zweiten Eigenschaften D2, E2 zugeordnet. Eine jeweilige Kombination der Eigenschaftswerte, die jeweils einem Datensatz des zweiten Datensatztyps zugeordnet sind, ist jeweils nur einmal in der zwei- ten Haupttabelle MR2 gespeichert.
Ferner sind die Untertabelle PR und eine weitere Tabelle SR dargestellt. Die Untertabelle PR ist analog zu der Untertabelle aus Figur 3b ausgebildet. Die weitere Tabelle SR um- fasst die Eigenschaftswerte b der ersten Eigenschaft Bl und ist somit der ersten Haupttabelle MRl zugeordnet. Dabei ist ein Eigenschaftswert b der ersten Eigenschaft B in der weiteren Tabelle SR nur jeweils einmal gespeichert. Dadurch können die Eigenschaftswerte, die der weiteren Tabelle SR zugeordnet sind und die der zweiten Haupttabelle MR2 zugeordnet sind, besonders effizient in der relationalen Datenbank RDB gespeichert werden.
Es gibt viele Beispiele im Bereich der Infotainmentsysteme auf die die Verwendung von Untertabellen angewendet werden kann. So können beispielsweise die folgenden ursprünglichen Tabellen (mit jeweiligen Eigenschaften in der Klammer)
POI (POI_ID, name, address, longitude, latitude, ...) Category (CAT_ID, icon, parent_category, ...) POI2Category (POI ID, CAT ID) aus dem Bereich von Navigationssystemen vorgesehen sein. Die ursprüngliche Tabelle POI umfasst Daten zu „Orten von Interesse", so z. B. Restaurants, Hotels, Touristen-Attraktionen, etc .
Die Datensätze der ursprünglichen Tabellen können beispielsweise den folgenden Haupttabellen POI, Category und der Untertabelle PR
POI(POI_ID, name, address, longitude, latitude, ..., PID) Category (CAT_ID, icon, parent_category, ...) PR(PID, CAT_ID)
zugeordnet sein, wobei die Unterkennung PID die beiden Haupt- tabellen zueinander referenziert .

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 zuzugreifen, die in der relationalen Datenbank (RDB) als Datensätze eines ersten Datensatztyps und als Datensätze eines zweiten Datensatztyps gespeichert sind, wobei jeder Datensatz des ersten Datensatztyps einen Kennungswert einer eindeutigen ersten Kennung (PKl), einen jeweiligen Eigenschaftswert (al-cl) zumindest einer ersten Eigenschaft (Al-Cl) und jeweils einen Unterkennungswert zumindest einer Unterkennung (PID) aufweist, wobei jeder Datensatz des zweiten Datensatztyps einen Unterkennungswert einer eindeutigen zweiten Kennung (PK2) und jeweils einen Eigenschaftswert (d2, e2) zumindest einer zweiten Eigenschaft (D2, E2) aufweist, wobei
- einer ersten Haupttabelle (MRl) zugeordnet sind, die eindeutige erste Kennung (PKl), die zumindest eine erste Eigenschaft (Al-Cl) und die zumindest eine zugeordnete Unterkennung (PID),
- einer zweiten Haupttabelle (MR2) zugeordnet sind, die eindeutige zweite Kennung (PK2) und die zumindest eine zweite Eigenschaft (D2, E2), wobei Tupel von Eigen- schaftswerten der zweiten Eigenschaft, die der zweiten Haupttabelle zugeordnet sind, nur jeweils einmal in der zweiten Haupttabelle (MR2) gespeichert sind,
- in zumindest einer Untertabelle (PR) gespeichert sind, die Unterkennungswerte der zumindest einen Unterkennung (PID) und die zugeordneten Kennungswert der eindeutigen zweiten Kennung (PK2) .
2. Infotainmentsystem nach Anspruch 1, bei dem das Datenbankverwaltungssystem (RDBMS) ausgebildet ist, unter zur Hilfe- nähme der zumindest einen Untertabelle (PR) einen Datensatz des ersten bzw. zweiten Datensatztyps zu ermitteln, der einem Datensatz des zweiten bzw. ersten Datensatztyps zugeordnet ist .
3. Infotainmentsystem nach Anspruch 1 oder 2, bei dem die vorgegebene Anweisung (SQL CMD) als SQL-Anweisung ausgebildet ist .
4. 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 3.
EP09745063A 2008-11-26 2009-11-04 Infotainmentsystem und computerprogrammprodukt Withdrawn EP2370913A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102008059098A DE102008059098A1 (de) 2008-11-26 2008-11-26 Infotainmentsystem und Computerprogrammprodukt
PCT/EP2009/064616 WO2010060763A1 (de) 2008-11-26 2009-11-04 Infotainmentsystem und computerprogrammprodukt

Publications (1)

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

Family

ID=41416231

Family Applications (1)

Application Number Title Priority Date Filing Date
EP09745063A Withdrawn EP2370913A1 (de) 2008-11-26 2009-11-04 Infotainmentsystem und computerprogrammprodukt

Country Status (3)

Country Link
EP (1) EP2370913A1 (de)
DE (1) DE102008059098A1 (de)
WO (1) WO2010060763A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4259456B2 (ja) * 2004-11-11 2009-04-30 トヨタ自動車株式会社 データ記録装置及びデータ記録方法
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
CN106080446B (zh) * 2016-06-07 2018-10-16 东风汽车公司 Bcm控制器的数据记录方法与系统及故障诊断方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5870747A (en) * 1996-07-09 1999-02-09 Informix Software, Inc. Generalized key indexes
US7317974B2 (en) * 2003-12-12 2008-01-08 Microsoft Corporation Remote vehicle system management

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2010060763A1 *

Also Published As

Publication number Publication date
DE102008059098A1 (de) 2010-06-10
WO2010060763A1 (de) 2010-06-03

Similar Documents

Publication Publication Date Title
DE112012000280B4 (de) Organisation von Tabellen mit reduzierten Indizes
WO1998001808A1 (de) Datenbanksystem
DE102008047915B4 (de) Infotainmentsystem und Computerprogrammprodukt
EP2370913A1 (de) Infotainmentsystem und computerprogrammprodukt
EP1982146B1 (de) Navigationssystem, verfahren und computerprogrammprodukt zum betreiben des navigationssystems
WO2024012737A1 (de) Verfahren zum speichern und bereitstellen georeferenzierter fahrzeugdaten, computerlesbares medium, und verteiltes system
EP1979837B1 (de) Verfahren zur ausgabe von datensätzen und vorrichtung hierfür
US8073823B2 (en) Database management program
DE102013000369A1 (de) Verfahren zum Betreiben eines Infotainmentsystem
WO2021064037A1 (de) Verfahren, computerprogramm, speichermedium, speichermittel und system zur nutzung eines gemeinsam genutzten speichermittels
EP2370915A1 (de) Infotainmentsystem und computerprogrammprodukt
EP2143096A1 (de) VERFAHREN ZUM ERSTELLEN EINES VERZEICHNISSES VON STRAßENABSCHNITTEN, VERFAHREN ZUM ERMITTELN ALLER STRAßENABSCHNITTE INNERHALB EINES SUCHGEBIETS UND COMPUTERPROGRAMM
WO2010094596A1 (de) Verfahren zum betreiben eines informationssystems, informationssystem und speichermedium
DE102019008662A1 (de) Verfahren zur parallelen und/oder inkrementellen Geolokalisierung von Grundursachen von durch ein Fahrzeug erfassten Ereignissen
DE102008047914B4 (de) Navigationssystem, Verfahren und Computerprogrammprodukt zum Betreiben des Navigationssystems
DE102015200075B4 (de) Verfahren zur Zuordnung von streckenbezogenen Daten eines Online-Dienstes und Navigationssystem
DE10201161A1 (de) Verfahren zur Darstellung von Ortsnamen, Informationsträger und Navigationsvorrichtung hierzu
WO2007033873A1 (de) Verfahren zur aktualisierung von digitalen karten
EP1883024A1 (de) Verfahren zum Betrieb eines Navigationssystems
WO2021064241A1 (de) Datenstruktur, speichermittel und vorrichtung
WO2012107427A1 (de) Verfahren zur rechnergestützten navigation in einem datenbestand
Touir A Theoretical and Empirical Evaluation of a Novel Spatial Data Indexing Structure
WO2003030019A2 (de) Verfahren und anordnung zur speicherung hierarchisch abhängiger daten
DE102004033079A1 (de) Verfahren zur Steuerung des Zugriffs auf in einer Datenbank gespeicherte Daten

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: ZEHNER, STEFFEN

Inventor name: PFEIFLE, MARTIN

Inventor name: STEGE, KURT

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

Effective date: 20180226

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

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

18D Application deemed to be withdrawn

Effective date: 20190601