Infotainmentsystem und Computerprogrammprodukt

Die Erfindung betrifft ein Infotainmentsystem und ein Computerprogrammprodukt zum Betreiben des Infotainmentsystems .

Infotainmentsysteme sind beispielsweise in modernen Kraftfahrzeugen eingebaut und verknüpfen die Vermittlung von In- formationen, so z. B. Navigationsdaten, und von Unterhaltungsdaten, so z. B. TV- oder Musikdaten. Die Speicherung und Verwaltung dieser sogenannten Infotainmentdaten erfolgt vorzugsweise mittels eines Datenbanksystems.

Ein modernes Datenbanksystem umfasst regelmäßig eine Datenbank und ein Datenbankverwaltungssystem. In der Datenbank sind die Daten gespeichert. Das Datenbankverwaltungssystem ist vorgesehen zum Verwalten der Daten in der Datenbank. Das Verwalten der Datenbank kann beispielsweise ein Suchen, ein Lesen und/oder ein Schreiben von Daten in der Datenbank umfassen. Insbesondere können nicht mehr aktuelle Daten aktualisiert werden durch einen Aktualisierungsbefehl, der eine Kombination aus Such-, Lese- und/oder Schreibbefehlen umfasst .

Aufgabe der Erfindung ist es, ein Infotainmentsystem und ein Computerprogrammprodukt zum Betreiben des Infotainmentsystems zu schaffen, das eine effiziente Speicherung von Infotain- mentdaten ermöglicht.

Die Aufgabe der Erfindung wird gelöst durch die Merkmale der unabhängigen Ansprüche. Vorteilhafte Ausgestaltungen der Erfindung sind in den Unteransprüchen angegeben.

Die Erfindung zeichnet sich bezüglich einem ersten Aspekt aus durch ein Infotainmentsystem, das eine relationale Datenbank, die auf einem Speichermedium gespeichert ist, und ein Daten- bankverwaltungssystem umfasst. Das Datenbankverwaltungssystem ist ausgebildet, auf Infotainmentdaten zu zugreifen, die in der relationalen Datenbank als Datensätze abgespeichert sind. Ein Datensatz weist einen jeweiligen Kennungswert einer ein- deutigen Kennung, Eigenschaftswerte mehrerer Eigenschaften und zumindest einen Unterkennungswert zumindest einer Unter- kennung auf. Alle oder zumindest einer der mehreren Eigenschaften und eine der zumindest einen Unterkennung sind zumindest einer Untertabelle zugeordnet. Die eindeutige Ken- nung, die verbleibenden der mehreren Eigenschaften und die zumindest eine zugeordnete Unterkennung sind zumindest einer Haupttabelle zugeordnet. Tupel der Eigenschaftswerte der Eigenschaften, die der jeweiligen Untertabelle zugeordnet sind, sind jeweils nur einmal in der jeweiligen Untertabelle ge- speichert. Die mehreren Eigenschaften sind funktional unabhängig voneinander. Dies trägt dazu bei, dass Tupel der Eigenschaftswerte der Eigenschaften der jeweiligen Untertabelle nur jeweils einmal in der jeweiligen Untertabelle gespeichert sind. D.h. eine jeweilige Kombination von Eigenschaftswerten, die dem jeweiligen Tupel zugeordnet sind, ist nur jeweils einmal in der jeweiligen Untertabelle gespeichert. Dies trägt dazu bei, Redundanzen von Eigenschaftswerten in der jeweiligen Untertabelle zu reduzieren. In einer Tabelle, die gemäß der dritten Normalform normalisiert ist, besteht keine funk- tionale Abhängigkeit zwischen den Eigenschaften, die der Tabelle zugeordnet sind, d.h. es kann von einem Eigenschaftswert einer Eigenschaft nicht eindeutig auf einen Eigenschaftswert einer anderen Eigenschaft geschlossen werden. Dabei werden die eindeutige Kennung und die Unterkennung nicht als Eigenschaft betrachtet. Tabellen, die bereits nach der dritten Normalform der Datenbanktheorie normalisiert sind, können Redundanzen von Tupeln von Eigenschaftswerten aufweisen .

Die zumindest eine Haupttabelle weist vorzugsweise zumindest eine eindeutige Kennung und zumindest eine Unterkennung auf. Die zumindest eine Untertabelle weist zumindest eine der zu- mindest einen Unterkennung auf. Die zumindest eine Haupttabelle und die zumindest eine Untertabelle weisen jeweils Spalten und Zeilen auf. Eine Spalte ist jeweils einer Eigenschaft oder der eindeutigen Kennung oder der zumindest einen Unterkennung zugeordnet. Eine Zeile der zumindest einen

Haupttabelle und eine zugeordnete Zeile der zumindest einen Untertabelle bilden einen Datensatz. Der jeweilige Unterken- nungswert der zumindest einen Unterkennung stellt jeweils eine Referenz der jeweiligen Zeile der zumindest einen Hauptta- belle zu der zugeordneten jeweiligen Zeile der jeweiligen Untertabelle dar.

Dabei bezeichnet ein Tupel eine Kombination von Eigenschaftswerten, die einer Zeile der jeweiligen Untertabelle zugeord- net sind. Tupel der Eigenschaftswerte können einen oder mehrere Eigenschaftswerte umfassen, die einer Zeile der jeweiligen Untertabelle zugeordnet sind.

Vorzugsweise kommt eine Kombination von Eigenschaftswerten, die jeweils einer Zeile zugeordnet sind, nur einmal in der zumindest einen Untertabelle vor. Dadurch können die Datensätze besonders effizient und mit geringem Speicherplatzbedarf auf dem Speichermedium der relationalen Datenbank abgespeichert werden. Eine Speicherplatzeinsparung ist umso grö- ßer, je größer die Anzahl der Spalten ist, die der zumindest einen Untertabelle zugeordnet ist und je kleiner die Anzahl der Zeilen dieser zumindest einen Untertabelle ist. Dabei kann aber eine Redundanz von Eigenschaftswerten, die einer Eigenschaft zugeordnet sind, weiterhin vorliegen. Vorzugswei- se ist die Anzahl der Untertabellen möglichst gering, um den zusätzlichen Speicherbedarf, der aufgrund der zumindest einen Unterkennung vorliegt, gering zu halten.

Die relationale Datenbank und das Datenbankverwaltungssystem können beispielsweise als eine Funktionseinheit in dem Info- tainmentsystem eines Kraftfahrzeugs integriert sein, wobei das Infotainmentsystem in dem Kraftfahrzeug vorzugsweise als ein eingebettetes System (embedded System) ausgebildet ist. Grundsätzlich ist es aber auch möglich, dass die relationale Datenbank und das Datenbankverwaltungssystem als separate Funktionseinheiten in dem Infotainmentsystem ausgebildet sind.

In einer vorteilhaften Ausgestaltung des ersten Aspekts ist das Datenbankverwaltungssystem ausgebildet, abhängig von zumindest einer vorgegebenen Anweisung auf die zumindest eine Untertabelle zu zugreifen und zumindest einen der Datensätze abhängig von der zumindest einen Unterkennung und den in der zumindest einen Untertabelle gespeicherten Eigenschaftswerten zu rekonstruieren. Dies hat den Vorteil, dass die Datensätze relativ schnell rekonstruiert werden können, bei gleichzeiti- ger effizienter Speicherung der Eigenschaftswerte auf dem Speichermedium der relationalen Datenbank.

In einer weiteren vorteilhaften Ausgestaltung des ersten Aspekts ist das Datenbankverwaltungssystem ausgebildet, bei Vorgabe eines Eigenschaftswertes einer der Eigenschaften, die der zumindest einen Untertabelle zugeordnet ist, zunächst auf die jeweilige Untertabelle zu zugreifen. Dabei ist das Datenbankverwaltungssystem ausgebildet, den vorgegebenen Eigenschaftswert mit den gespeicherten Eigenschaftswerten der je- weiligen Eigenschaften zu vergleichen und abhängig von dem Vergleich zumindest einen Unterkennungswert zumindest einer zugeordneten Unterkennung zu ermitteln. Davon abhängig wird zumindest einer der Datensätze ermittelt. Soll beispielsweise abhängig von einer vorgegebenen Anweisung, die den Eigen- schaftswert der Untertabelle vorgibt, ein oder mehrere Datensätze ermittelt werden, ist vorzugsweise eine Anweisungsrecheneinheit des Datenbankverwaltungssystems ausgebildet, die vorgegebene Anweisung derart zu interpretieren, dass zunächst auf die zumindest eine Untertabelle zugegriffen wird, um den zumindest einen Unterkennungswert der zumindest einen Unterkennung zu ermitteln. Dies ermöglicht eine besonders schnelle Rekonstruktion der Datensätze. Vorzugsweise wird der zumin- dest eine Unterkennungswert mittels des Vergleichs des vorgegebenen Eigenschaftswertes mit den gespeicherten Eigenschaftswerten der jeweiligen Eigenschaften ermittelt, wenn die Untertabelle wenige Zeilen aufweist. Dadurch ist eine je- weilige Indexstruktur, die Referenzen auf Speicherorte der Eigenschaftswerte der jeweiligen Eigenschaft speichert, für die jeweilige Untertabelle nicht erforderlich und somit der Speicherbedarf besonders gering.

In einer weiteren vorteilhaften Ausgestaltung des ersten Aspekts weist das Infotainmentsystem zumindest eine Indexstruktur auf, die Referenzen auf Speicherorte der Eigenschaftswerte der jeweiligen Eigenschaft umfasst, die der jeweiligen Untertabelle zugeordnet ist. Dabei ist das Datenbankverwal- tungssystem ausgebildet, bei Vorgabe eines Eigenschaftswertes einer der Eigenschaften, die der zumindest einen Untertabelle zugeordnet ist, zunächst auf die jeweilige Indexstruktur zu zugreifen und den vorgegebenen Eigenschaftswert mit den in der Indexstruktur gespeicherten Eigenschaftswerten der jewei- ligen Eigenschaften zu vergleichen. Das Datenbankverwaltungssystem ist ferner ausgebildet, abhängig von dem Vergleich zumindest einen Unterkennungswert zumindest einer zugeordneten Unterkennung zu ermitteln. Davon abhängig wird zumindest einer der Datensätze ermittelt. Die Indexstruktur ermöglicht einen besonders schnellen Zugriff auf die jeweiligen Eigenschaftswerte der Untertabelle auf dem Speichermedium, insbesondere wenn die Untertabelle besonders viele Zeilen aufweist .

In einer weiteren vorteilhaften Ausgestaltung des ersten Aspekts ist die vorgegebene Anweisung als SQL-Anweisung ausgebildet. Dies ermöglicht einen besonders schnellen Lese- und/oder Schreibzugriff auf die Infotainmentdaten in der relationalen Datenbank.

Die Erfindung zeichnet sich bezüglich eines zweiten Aspekts aus durch ein Computerprogrammprodukt. Das Computerprogramm- produkt umfasst ein computerlesbares Medium mit Programmanweisungen. Die Programmanweisungen sind durch einen Computer ausführbar. Ferner sind die Programmanweisungen ausgebildet zum Betreiben des Infotainmentsystems gemäß des ersten As- pekts der Erfindung.

Die Erfindung ist im Folgenden anhand von schematischen Zeichnungen näher erläutert. Es zeigen:

Figur 1 ein Datenbanksystem,

Figur 2 eine ursprüngliche Tabelle,

Figur 3 eine Haupt- und eine Untertabelle,

Figur 4 eine weitere Haupt- und weitere Untertabellen.

Elemente gleicher Konstruktion oder Funktion sind figurenübergreifend mit den gleichen Bezugszeichen gekennzeichnet.

Ein Infotainmentsystem (Figur 1) umfasst eine Infotainment- einheit INFO, ein Datenbankverwaltungssystem RDBMS und eine relationale Datenbank RDB. Das Infotainmentsystem kann beispielsweise eine Navigationseinheit umfassen und dient somit dazu, eine vorgegebene Route zu finden und/oder eine vorgegebene Strecke zu berechnen und/oder einen vorgegebenen Ort zu finden und/oder weitere Informationen zu ermitteln. Das Info- tainmentsystem kann zusätzlich oder alternativ aber auch ein Musiksystem umfassen und dazu ausgebildet sein, beispielswei- se vorgegebene Musikstücke zu finden und abzuspielen.

Die Infotainmenteinheit INFO, die relationale Datenbank RDB und das Datenbankverwaltungssystem RDBMS können auch als Softwarefunktionseinheiten in dem Infotainmentsystem ausge- bildet sein. Das Infotainmentsystem kann beispielsweise ein

Bordcomputer eines Kraftfahrzeugs und/oder ein Computer sein, beispielsweise ein tragbarer Computer, so z. B. ein Laptop sein. Das Infotainmentsystem weist vorzugsweise neben zumindest einer Ausgabeeinheit zumindest eine Eingabeeinheit auf, die dazu dient, Informationen, beispielsweise einer Route und/oder einem Musikstück, die ermittelt werden sollen, und/oder Informationen, aufgrund derer Infotainmentdaten geändert, insbesondere aktualisiert werden, einzugeben. Dabei können die Infotainmenteinheit INFO, die relationale Datenbank RDB und das Datenbankverwaltungssystem RDBMS als eine Funktionseinheit in dem Infotainmentsystem integriert sein oder als verteilte Funktionseinheiten.

Die Infotainmenteinheit INFO kommuniziert mit dem Datenbankverwaltungssystem RDBMS. Das Datenbankverwaltungssystem RDBMS umfasst eine Anweisungsschnittstelle SQL_IF, eine Anweisungs- recheneinheit SQL_CMD_PRO, einen Pager PAGER, ein Verzeichnis ID_LIB von Indexstrukturen und eine Betriebssystemschnittstelle OS_IF.

Das Datenbankverwaltungssystem RDBMS kommuniziert mit der re- lationalen Datenbank RDB. In der relationalen Datenbank RDB sind die Infotainmentdaten, so z.B. Navigationsdaten und/oder Musikdaten, gespeichert.

Die Infotainmenteinheit INFO kommuniziert mit dem Datenbank- Verwaltungssystem RDBMS vorzugsweise derart, dass die Info- tainmenteinheit INFO eine Anweisung SQL_CMD an das Datenbankverwaltungssystem RDBMS sendet. Alternativ kann die Anweisung SQL_CMD auch durch geeignete Signale repräsentiert werden, die dann in dem Datenbankverwaltungssystem RDBMS in die ent- sprechende Anweisung SQL_CMD übersetzt werden. Vorzugsweise ist die Anweisung SQL CMD als SQL-Anweisung ausgebildet.

Die Anweisungsschnittstelle SQL IF dient dazu, zu überprüfen, ob die Anweisung SQL_CMD syntaktisch richtig ist. Falls die Anweisung SQL CMD syntaktisch richtig ist, wird sie von der

Anweisungsschnittstelle SQL_IF an die Anweisungsrecheneinheit SQL CMD PRO übergegeben. Die Anweisungsrecheneinheit SQL CMD PRO ermittelt abhängig von der Anweisung SQL_CMD und vorzugsweise abhängig von mindestens einer verfügbaren Indexstruktur, die in dem Verzeichnis ID_LIB der Indexstrukturen hinterlegt ist, vorzugsweise einen Software-Ausführungsplan. Der Software-Ausführungsplan ist ein Programmabschnitt, der dazu dient, den Zugriff auf die Infotainmentdaten möglichst effizient zu gestalten.

Der Software-Ausführungsplan wird von der Anweisungsrechen- einheit SQL_CMD_PRO an den Pager PAGER übergeben. Der Pager PAGER dient dazu, abhängig von dem Software-Ausführungsplan vorzugsweise einen Hardware-Ausführungsplan zu ermitteln. Der Hardware-Ausführungsplan ist repräsentativ dafür, wie eine Hardware, beispielsweise ein CD-ROM-Laufwerk und/oder eine Festplatte und/oder weitere Datenträger, die die relationale Datenbank RDB umfassen können, angesteuert werden müssen, um den Software-Ausführungsplan abzuarbeiten.

Der Hardware-Ausführungsplan wird an die Betriebssystem- Schnittstelle OS_IF übergeben, welche den Hardware-Ausführungsplan in entsprechende Stellsignale für das technische Gerät übersetzt, auf dem die Infotainmentdaten gespeichert sind, und/oder das das Speichermedium umfasst, auf dem die Infotainmentdaten gespeichert sind.

Die Infotainmentdaten sind in der relationalen Datenbank RDB als Datensätze in Tabellen abgespeichert.

In Figur 2 ist eine ursprüngliche Tabelle R dargestellt, die zehn Datensätze aufweist. Jeder Datensatz wird durch einen Kennungswert einer eindeutigen Kennung PK repräsentiert und umfasst zusätzlich fünf Eigenschaftswerte a-e unterschiedlicher Eigenschaften A-E.

Die Eigenschaften A-E der jeweiligen Datensätze sind in Großbuchstaben gekennzeichnet, während Eigenschaftswerte a-e der Eigenschaften A-E in Kleinbuchstaben gekennzeichnet sind. Ei- ner Eigenschaft ist jeweils eine Spalte zugeordnet. Eine Zeile der zumindest einen Haupttabelle und eine zugeordnete Zeile der zumindest einen Untertabelle bilden einen Datensatz.

Die Eigenschaften A-E der ursprünglichen Tabelle R sind funktional unabhängig voneinander und sind entsprechend der dritten Normalform normalisiert.

In Figur 2 ist angedeutet, dass für die mehreren Eigenschaf- ten A-E in den unterschiedlichen Datensätzen gleiche Eigenschaftswerte a-e abgespeichert sind. So ist beispielsweise der Eigenschaftswert el der Eigenschaft E des ersten Datensatzes identisch mit dem Eigenschaftswert el der Eigenschaft E des zweiten bis vierten Datensatzes. Darüber hinaus sind in Figur 2 weitere Redundanzen von Eigenschaftswerten in der ursprünglichen Tabelle R gekennzeichnet, wobei nicht alle Redundanzen gekennzeichnet sind.

Gemäß einer ersten Ausführungsform (Figur 3) ist ein Daten- satz der ursprünglichen Tabelle R auf einen Hauptdatensatz in einer Haupttabelle MR und auf einen Unterdatensatz in einer ersten Untertabelle PRl aufgeteilt. Die Haupttabelle MR um- fasst die eindeutige Kennung PK und die Eigenschaften A und C, sowie zusätzlich eine erste Unterkennung PIDl. Die erste Untertabelle PRl umfasst die erste Unterkennung PIDl und die dieser Kennung zugeordnete Eigenschaften B, D, E der ursprünglichen Tabelle R, wobei ein jeweiliges Tupel der Eigenschaftswerte b, d, e, die jeweils einer Zeile der ersten Untertabelle PRl zugeordnet sind, nur jeweils einmal in der ersten Untertabelle PRl gespeichert ist. So ist beispielsweise das Tupel der Eigenschaftswerte b5, d5, e5 der Eigenschaften B, D, E nur einmal in der ersten Untertabelle PRl gespeichert, während in der ursprünglichen Tabelle R dieses Tupel der Eigenschaftswerte b5, d5, e5 fünfmal gespeichert ist, ob- wohl die ursprüngliche Tabelle R gemäß der dritten Normalform normalisiert ist. Eine Redundanz von Eigenschaftswerten jeweils einer Eigenschaft ist allerdings weiterhin in der ers- ten Untertabelle PRl vorhanden, so z. B. ist der Eigenschaftswert el dreimal in der ersten Untertabelle PRl gespeichert .

Dabei besteht das Bestreben, so viele Spalten und gleichzeitig so wenig Zeilen wie möglich der jeweiligen Untertabelle zu zuordnen. Dies erlaubt eine besonders hohe Speicherplatzeinsparung auf dem Speichermedium DC der relationalen Datenbank RDB. Dadurch kann die jeweilige Untertabelle einen der- art geringen Speicherbedarf aufweisen, dass beispielsweise die jeweilige Untertabelle in einem Cache-Speicher des Datenbankverwaltungssystems RDBMS oder der relationalen Datenbank RDB zwischengespeichert werden kann und somit besonders schnell zugreifbar ist. Dies ermöglicht einen besonders effi- zienten Zugriff auf die Eigenschaftswerte der jeweiligen Untertabelle .

Der jeweilige Unterkennungswert der ersten Unterkennung PIDl repräsentiert den jeweiligen Unterdatensatz in der ersten Un- tertabelle PRl und ermöglicht eine Referenzierung des jeweiligen Unterdatensatzes aus dem diesem zugeordneten Hauptdatensatz in der Haupttabelle MR. Somit kann beispielsweise mittels der Anweisung SQL CMD

create view R as select * from MR natural join PRl

die ursprüngliche Tabelle R (Figur 1) rekonstruiert werden.

Sind beispielsweise Datensätze zu ermitteln, die einen vorgegebenen Eigenschaftswert der Eigenschaft B, D, E in der ersten Untertabelle PRl aufweisen, so ist das Datenbankverwaltungssystem RDBMS, insbesondere die Anweisungsrecheneinheit SQL_CMD_PRO des Datenbankverwaltungssystems RDBMS, vorzugs- weise ausgebildet, zunächst auf die erste Untertabelle PRl zu zugreifen. Dabei wird der vorgegebene Eigenschaftswert mit den in der ersten Untertabelle PRl gespeicherten Eigen- schaftswerten b, d, e verglichen und davon abhängig ein oder mehrere zugeordnete Unterkennungswerte der ersten Unterken- nungen PIDl ermittelt. Der zumindest eine ermittelte Unter- kennungswert der ersten Unterkennung PIDl ist repräsentativ für zumindest einen Datensatz, der den vorgegebenen Eigenschaftswert der Eigenschaft B, D, E aufweist. Abhängig von dem zumindest einen ermittelten Unterkennungswert kann dann besonders effizient auf die Hauptdatensätze in der Haupttabelle MR zugegriffen werden. Vorzugsweise ist dadurch die In- dexstruktur, die Referenzen auf Speicherorte der Eigenschaftswerte der jeweiligen Eigenschaft A-E umfasst, die der jeweiligen Untertabelle zugeordnet ist, nicht erforderlich, insbesondere wenn die erste Untertabelle PRl eine geringe Anzahl an Zeilen aufweist, so z. B. <= 5.

Weist die erste Untertabelle PRl jedoch viele Zeilen auf, so z. B. > 5, so kann alternativ die Indexstruktur für die erste Untertabelle PRl in dem Verzeichnis ID_LIB von Indexstrukturen angelegt werden. Die Indexstruktur referenziert dann vor- zugsweise die Speicherorte der Unterkennungswerte der ersten Unterkennungen PIDl der ersten Untertabelle PRl. Werden beispielsweise alle Eigenschaftswerte a der Eigenschaft A gesucht, denen der vorgegebene Eigenschaftswert bl der Eigenschaft B zugeordnet ist, so kann beispielsweise mittels der Anweisung SQL_CMD

select A from MR where PIDl in (select PIDl from PRl where B='bl')

diese Suche besonders schnell ausgeführt werden.

Gemäß einer zweiten Ausführungsform in Figur 4 ist ein Datensatz der ursprünglichen Tabelle R auf den Hauptdatensatz der Haupttabelle MR und auf den Unterdatensatz der ersten Unter- tabelle PRl und auf einen weiteren Unterdatensatz einer zweiten Untertabelle PR2 aufgeteilt. Dies hat den Vorteil, dass die vorhandene Redundanz von Eigenschaftswerten der jeweili- gen Eigenschaften B, D, E in der ersten Untertabelle PRl gemäß der Figur 3 weiter reduziert werden kann. Die Haupttabelle MR umfasst neben der ersten Unterkennung PIDl zusätzlich eine zweite Unterkennung PID2. Mittels des jeweiligen Unter- kennungswertes der ersten Unterkennung PIDl sind die Eigenschaftswerte b der Eigenschaft B der ersten Untertabelle PRl referenzierbar . Mittels des jeweiligen Unterkennungswertes der zweiten Unterkennung PID2 sind die Eigenschaftswerte d, e der Eigenschaften D, E der zweiten Untertabelle PR2 referen- zierbar.

Im Folgenden werden zwei Algorithmen erläutert, die das Ermitteln geeigneter Untertabellen ermöglicht, so dass eine Redundanz von Eigenschaftswerten in der jeweiligen Untertabelle so weit wie möglich reduziert wird.

Der erste Algorithmus erläutert die Ermittlung einer Untertabelle wie sie in der Figur 3a und 3b verwendet wird.

Dazu wird zunächst angenommen, dass eine ursprüngliche Tabelle RX vorliegt mit n Zeilen und o Eigenschaften Al bis Ao pro Zeile. Für o Eigenschaften bestehen 2° Möglichkeiten von Kombinationen von Eigenschaften, die der Untertabelle zugeordnet werden können. Liegen beispielsweise 5 Eigenschaften vor, so ergeben sich 2 ⁵ = 32 mögliche Kombinationen von Eigenschaften. Es gilt nun herauszufinden, welche Kombination von Eigenschaften die höchste Speicherplatzeinsparung ermöglicht.

Beginnend von einer der 2° Möglichkeiten, so z. B. die Kombi- nation der Eigenschaften Al, A3, A5, kann beispielsweise mit der folgenden Anweisung SQL CMD

select count(l) from RX group by A1,A3,A5

ermittelt werden, wieviele unterschiedliche Kombinationen n' von Eigenschaftswerten der vorgegebenen Kombination der Eigenschaften Al, A3, A5 in der ursprünglichen Tabelle RX vor- liegen. Die unterschiedlichen Kombinationen n' repräsentieren dabei die Anzahl der Zeilen der Untertabelle, die resultieren würde, wenn die gerade verwendete Kombination der Eigenschaften Al, A3, A5 der Untertabelle zugeordnet würde.

Danach wird ein durchschnittlicher Speicherbedarf s eines Eigenschaftswertes in Bytes ermittelt. Dies kann beispielsweise mittels folgender Anweisung SQL_CMD

select average (length (Al) +length (A3) +length (A5) ) \3 from RX group by A1,A3,A5

erfolgen. Mit der ermittelten Anzahl an unterschiedlichen Kombination n' von Eigenschaftswerten und dem durchschnittli- chen Speicherbedarf s eines Eigenschaftswertes kann die jeweilige Einsparung des Speicherplatzes in Bytes mit folgender mathematischen Gleichung ermittelt werden

o * s * (n - n' ) - r * (n + n' ) .

Dabei stellt r den Speicherbedarf der jeweiligen Unterkennung dar, so z.B. 8 Bytes. Der erste Term o * s * (n - n' ) repräsentiert die Einsparung in Bytes für die jeweilige Kombination von Eigenschaften, die gerade betrachtet wird. Der zweite Term r * (n + n' ) stellt dann den zusätzlich benötigten Speicherbedarf dar, der aufgrund der zusätzlichen Unterkennungen benötigt wird und der von dem eingesparten Speicherplatz abzuziehen ist.

Die dargestellte Berechnung wird für jede der 2° möglichen Kombinationen von Eigenschaften berechnet. Die Kombination von Eigenschaften mit der höchsten Speicherplatzeinsparung wird dann vorzugsweise der Untertabelle zugeordnet. Vorzugsweise weist diese Untertabelle dann auch eine optimale Anzahl von Zeilen und Spalten auf. Der zweite Algorithmus erläutert die Ermittlung mehrerer Untertabellen wie sie in der Figur 4 verwendet werden.

Dabei ermittelt der folgende Algorithmus nicht die Kombinati- onen von Eigenschaften mit dem geringsten Speicherbedarf, sondern vielmehr Kombinationen von Eigenschaften, die eine annehmbare Reduktion des Speicherbedarfes ermöglichen.

Auch hier wird angenommen, dass die ursprüngliche Tabelle RX vorliegt mit n Zeilen und o Eigenschaften Al bis Ao pro Zeile.

In einem ersten Schritt wird für jede Eigenschaft Ai (mit i = 1 bis o) der ursprünglichen Tabelle RX die folgende Anweisung SQL_CMD

select count(l) as n' , average (length (Ai) ) as s from RX group by Ai

ausgeführt. Mit der folgenden schon bekannten mathematischen Gleichung

s * (n - n' ) - r * (n + n' )

kann der eingesparte Speicherplatz in Bytes jeder Eigenschaft berechnet werden, wobei s, n, n' und r die gleiche Bedeutung wie im ersten Algorithmus haben.

In einem nächsten Schritt werden Eigenschaftspaare Ai, Aj (mit i, j = 1...O, wobei i I= J) betrachtet. Dabei wird für jedes mögliche Eigenschaftspaar Ai, Aj die folgende Anweisung SQL_CMD ausgeführt

select count(l) as n' , average (length (Ai) +length (Aj )) \2 as s from RX group by Ai, Aj . Auch hier kann anhand der schon bekannten mathematischen Gleichung der eingesparte Speicherplatz in Bytes berechnet werden. Abhängig von dem ermittelten eingesparten Speicherplatz pro Eigenschaftspaar Ai, Aj kann nun entschieden wer- den, ob ein jeweiliges Eigenschaftspaar Ai, Aj einer eigenen Untertabelle zugeordnet werden kann.

In einem nächsten Schritt wird versucht, zwei Eigenschaftspaar zu jeweils einem Eigenschaftstripel zusammenzuführen. Liegen beispielsweise die beiden Eigenschaftspaare Ai, Aj und Ak, Aj vor, so kann überprüft werden, ob das Eigenschaftstripel Ai, Aj, Ak mehr Speicherplatz einspart als die dazugehörigen Eigenschaftspaare Ai, Aj und Ak, Aj.

In einem nächsten Schritt werden zwei Eigenschaftstripel zu einem Eigenschaftstupel einer Länge 4 zusammengefasst und bewertet. Liegen beispielsweise die beiden Eigenschaftstripel Ai, Aj, Ak und Ai, Aj, Al vor, so kann überprüft werden, ob das Eigenschaftstupel der Länge 4 Ai, Aj, Ak, Al mehr Spei- cherplatz einspart als die dazugehörigen Eigenschaftstripel Ai, Aj, Ak und Ai, Aj, Al.

Vorzugsweise kann die weitere Zusammenführung zu Eigenschaftstupeln vorgegebener Länge solange betrieben werden, bis sich eine weitere Einsparung von Speicherplatz nicht mehr ermitteln lässt.

In einem weiteren Schritt werden alle ermittelten Möglichkeiten der Kombinationen von Eigenschaften und deren dazugehöri- ge Speicherplatzeinsparung in Bytes in eine Liste eingetragen, wobei die Liste nach der Größe der Speicherplatzeinsparung sortiert wird. Möglichkeiten der Kombination von Eigenschaften, die keine Speicherplatzeinsparung ermöglichen, werden nicht berücksichtigt.

Die erste Möglichkeit der Kombination von Eigenschaften auf der Liste, der gleichzeitig die höchste Speicherplatzeinspa- rung zugeordnet ist, kann direkt einer ersten Untertabelle zugeordnet werden.

Danach werden alle Listeneinträge gestrichen, die zumindest eine Eigenschaft aufweisen, die auch in der ersten Möglichkeit der Kombination von Eigenschaften enthalten ist.

In einem nächsten Schritt wird die der ersten Möglichkeit folgende zweite Möglichkeit der Kombination von Eigenschaften auf der Liste ermittelt, die nicht gestrichen wurde. Die zweite Möglichkeit der Kombination wird einer zweiten Untertabelle zugeordnet und erneut werden alle Listeneinträge gestrichen, die zumindest eine Eigenschaft aufweisen, die auch in der zweiten Möglichkeit der Kombination von Eigenschaften enthalten ist. Diese letzten Schritte werden solange wiederholt, bis keine Möglichkeiten der Kombination von Eigenschaften mehr auf der Liste verfügbar ist.

Durch den zweiten Algorithmus können mehrere Untertabellen mit unterschiedlicher Anzahl von unterschiedlichen Eigenschaften ermittelt werden, die eine besonders effiziente Speicherung von Eigenschaftswerten in der relationalen Datenbank RDB ermöglichen.

Es gibt viele Beispiele im Bereich der Infotainmentsysteme auf die die Verwendung von Untertabellen angewendet werden kann. So kann beispielsweise eine folgende ursprüngliche Tabelle (mit Eigenschaften in der Klammer)

Links (LINK_ID, speed_limit, urban, functional_road_class, ...)

aus dem Bereich der Navigationssysteme vorgesehen sein. Da insbesondere die Eigenschaft , speed_limit' (Geschwindigkeits- begrenzung) erfahrungsgemäß nur relativ wenige Eigenschaftswerte zulässt, so z.B. 50, 60, 70, 80, 100, 120 km/h, oder die Eigenschaft , urban' (Stadtgebiet) vorzugsweise als Eigen- schaftswerte nur ja oder nein zulässt oder die Eigenschaft , functional_road_class' beispielsweise Autobahn, Bundesstrasse, etc. als mögliche Eigenschaftswerte zulässt, sind diese Eigenschaften besonders geeignet, einer oder mehreren Untertabellen zugeordnet zu werden. Dadurch wird eine besonders erffiziente Speicherung dieser Eigenschaftswerte in der relationalen Datenbank RDB ermöglicht.