Edit (nochmal zu einem anderen Beitrag):
Übernehme nur das Datumsfeld in DBT_TRAFFIC (lösche ID_ZEIT) und fülle es mit ROUND(<Datum>, 'HH').
Würde das nicht bedeuten, dass jedwede Art der Normalisierung nicht gemacht werden soll. Du löst ja meine untergeordneten Tabellen auf (auch ein Vorschlag bei dbt_Channel). Dann haben wir am Ende immer nur eine Tabelle mit allen Angaben.
Deswegen kann ich es nochmal auf den Punkt bringen: Alle PK-FK-Kombinationen müssen doch dieses Problem haben. Was macht man da?
Eine untergeordnete Tabelle einzuführen ist nicht zwangsläufig mit Normalisierung gleich zu setzen.
DBT_CHANNEL und DBT_ZEIT bestehen nur aus dem Primarschlüssel und haben damit eigentlich keine Daseinsberechtigung. Es gibt keine Spalten in diesen Tabellen die von diesen Daten abhängen. Dies verschleierst du ein wenig in dem du für den natürlichen zusammengesetzten Schlüssel, einen weiteren künstlichen vergibst.
Bei DBT_ZEIT ist das besonders deutlich zu sehen. Datum und Stunde sind der eigentliche Schlüssel der Tabelle. ID_ZEIT wird noch dazu erfunden. Datum und Stunde lassen sich mit Round(<DateTime>, 'HH') einfach in einem Date-Feld speichern. Du hast also eine Tabelle mit 2 Feldern die beide Unique sind und das eine Feld ID_Zeit wird nur gebraucht um auf den anderen Wert zu verweisen.
Speicherst du den gerundeten DateTime-Wert gleich in der Tabelle DBT_TRAFFIC wird alles einfacher.
statt
SQL-Code:
select * from
dbt_traffic t
inner join dbt_zeit z on
z.id_zeit = t.id_zeit and z.datum between date '2010-01-01' and date '2010-03-31'
schreibst du dann
SQL-Code:
select * from
dbt_traffic t
where
t.DatumStd between date '2010-01-01' and date '2010-03-31 23:23:59'
und bei einem insert in die DBT_TRAFFIC Tabelle musst du DatumStd auf Round(sysdate, 'HH') setzen.
Du würdest doch auch nicht
SQL-Code:
create table LEUTE
Nachname varchar(30),
Vorname varchar(30)
);
in die folgenden Tabellen aufteilen
SQL-Code:
create table LEUTE
Nachname varchar(30),
VornameID number(10)
);
create table VORNAMEN
VornameID number(10),
Vorname varchar(30)
);
Oder?
Für DBT_CHANNEL mag es praktische Gründe geben, z.B. ist es immer nervig wenn man, um zwei Tabellen zu joinen immer 7 Felder angeben musst, aber das kann ich gar nicht beurteilen, da ich nicht ersehen kann was mit der ChannelID angestellt wird.