WO2010060763A1 - Infotainmentsystem und computerprogrammprodukt - Google Patents

Infotainmentsystem und computerprogrammprodukt Download PDF

Info

Publication number
WO2010060763A1
WO2010060763A1 PCT/EP2009/064616 EP2009064616W WO2010060763A1 WO 2010060763 A1 WO2010060763 A1 WO 2010060763A1 EP 2009064616 W EP2009064616 W EP 2009064616W WO 2010060763 A1 WO2010060763 A1 WO 2010060763A1
Authority
WO
WIPO (PCT)
Prior art keywords
identifier
sub
data
record
unique
Prior art date
Application number
PCT/EP2009/064616
Other languages
English (en)
French (fr)
Inventor
Martin Pfeifle
Kurt Stege
Steffen Zehner
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 EP09745063A priority Critical patent/EP2370913A1/de
Publication of WO2010060763A1 publication Critical patent/WO2010060763A1/de

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2228Indexing structures
    • G06F16/2237Vectors, bitmaps or matrices

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.
PCT/EP2009/064616 2008-11-26 2009-11-04 Infotainmentsystem und computerprogrammprodukt WO2010060763A1 (de)

Priority Applications (1)

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

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102008059098.3 2008-11-26
DE102008059098A DE102008059098A1 (de) 2008-11-26 2008-11-26 Infotainmentsystem und Computerprogrammprodukt

Publications (1)

Publication Number Publication Date
WO2010060763A1 true WO2010060763A1 (de) 2010-06-03

Family

ID=41416231

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2009/064616 WO2010060763A1 (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)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070300024A1 (en) * 2004-11-11 2007-12-27 Toyota Jidosha Kabushiki Kaisha Data Recording Device and Data Recording Method
CN106080446A (zh) * 2016-06-07 2016-11-09 东风汽车公司 Bcm控制器的数据记录方法与系统及故障诊断方法

Families Citing this family (1)

* 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

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0818743A2 (de) * 1996-07-09 1998-01-14 Informix Software, Inc. Verallgemeinerte Schlüsselindizes
US20050131585A1 (en) * 2003-12-12 2005-06-16 Microsoft Corporation Remote vehicle system management

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0818743A2 (de) * 1996-07-09 1998-01-14 Informix Software, Inc. Verallgemeinerte Schlüsselindizes
US20050131585A1 (en) * 2003-12-12 2005-06-16 Microsoft Corporation Remote vehicle system management

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
CELKO,J.: "SQL for Smarties: Advanced SQL Programming", SQL FOR SMARTIES: ADVANCED SQL PROGRAMMING, 2005, San Francisco, CA, USA, pages 1 - 99, XP040425700 *
ELMASRI R ET AL: "Fundamentals of Database Systems, PASSAGE", FUNDAMENTALS OF DATABASE SYSTEMS, XX, XX, 1 January 2004 (2004-01-01), pages 455 - 491, XP002354081 *
SANDERS G L ET AL: "Denormalization effects on performance of RDBMS", SYSTEM SCIENCES, 2001. PROCEEDINGS OF THE 34TH ANNUAL HAWAII INTERNATI ONAL CONFERENCE ON JANUARY 3-6, 2001, PISCATAWAY, NJ, USA,IEEE, 3 January 2001 (2001-01-03), pages 930 - 938, XP010549684, ISBN: 978-0-7695-0981-5 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070300024A1 (en) * 2004-11-11 2007-12-27 Toyota Jidosha Kabushiki Kaisha Data Recording Device and Data Recording Method
US8275952B2 (en) * 2004-11-11 2012-09-25 Toyota Jidosha Kabushiki Kaisha Data recording device and data recording method configured to sort data by frame ID prior to recording
CN106080446A (zh) * 2016-06-07 2016-11-09 东风汽车公司 Bcm控制器的数据记录方法与系统及故障诊断方法

Also Published As

Publication number Publication date
DE102008059098A1 (de) 2010-06-10
EP2370913A1 (de) 2011-10-05

Similar Documents

Publication Publication Date Title
WO2007088088A1 (de) Navigationssystem, verfahren und computerprogrammprodukt zum betreiben des navigationssystems
EP0910829A1 (de) Datenbanksystem
DE102008047915B4 (de) Infotainmentsystem und Computerprogrammprodukt
DE19750692A1 (de) Schnelles Dateisystem
WO2010060763A1 (de) Infotainmentsystem und computerprogrammprodukt
US8073823B2 (en) Database management program
WO2007048148A1 (de) Verfahren zur steuerung eines relationalen datenbanksystems
WO2005024703A1 (de) Datenübertragungssystem und verfahren zum betreiben eines datenübertragungssystems
EP1979837B1 (de) Verfahren zur ausgabe von datensätzen und vorrichtung hierfür
EP1929243B1 (de) Verfahren zur aktualisierung von digitalen karten
DE102006013389A1 (de) Verfahren zum Betrieb eines Navigationssystems
EP2370915A1 (de) Infotainmentsystem und computerprogrammprodukt
DE112010005494T5 (de) Navigationssystem
DE102008047914B4 (de) Navigationssystem, Verfahren und Computerprogrammprodukt zum Betreiben des Navigationssystems
DE102015200075B4 (de) Verfahren zur Zuordnung von streckenbezogenen Daten eines Online-Dienstes und Navigationssystem
DE102013000369A1 (de) Verfahren zum Betreiben eines Infotainmentsystem
WO2010094596A1 (de) Verfahren zum betreiben eines informationssystems, informationssystem und speichermedium
DE10201161A1 (de) Verfahren zur Darstellung von Ortsnamen, Informationsträger und Navigationsvorrichtung hierzu
WO2021064037A1 (de) Verfahren, computerprogramm, speichermedium, speichermittel und system zur nutzung eines gemeinsam genutzten speichermittels
EP2194466A1 (de) Verfahren und Vorrichtung zum Indexieren von Daten in einer Suchmaschine oder einer Datenbank für eine geschwindigkeitsoptimierte radiusabhängige Umkreissuche
DE102006014348A1 (de) Verfahren zur Suche nach Datensätzen in einem Datenbestand
EP1898301A2 (de) Datenbanksystem, Verfahren zum Betreiben des Datenbanksystems und Computerprogrammprodukt
DE102010027764A1 (de) Verfahren und Informationssystem zur Darstellung von Zusatzinformationen zu Objekten
DE102020214362A1 (de) Verfahren zum Verwalten von Daten von einer Vielzahl von Entitäten und Vorrichtung zur Datenverarbeitung
WO2012107427A1 (de) Verfahren zur rechnergestützten navigation in einem datenbestand

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

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2009745063

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE