Analýza a modelování dat 6. přednáška Helena Palovská
Historie databázových modelů Jak je řešena temporalita?
Temporalita v databázích Možnosti pro platnost faktu (valid time): platí nyní, je to aktuální fakt, event. odkdy je to událost, která nastala, víme kdy nastala platil v období od..do = období platnosti od nebo do nemusí být známo od nebo do nemusí mít smysl
Temporalita v databázích, II. Doba zaznamenání event. smazání (transaction time) kdy zaznamenán do databáze kdy se má smazat (zrušit platnost záznamu) Tímto se zabývat nebudeme! čas zapsání, aktualizace... běžné postupy kdy se má event. smazat... ne tak běžné, ale řešitelné
Porovnání: Operace s valid time co bylo dříve, co potom najdi následující, předchozí Nastala uvažovaná událost v uvažovaném období? Jaký je vztah dvou období? Možnosti: první je částí druhého překrývají se jedno předchází druhému
Vztah k nyní : Operace s valid time historie, současnost, budoucnost The moving point NOW
Dotazy s obdobím Jsou sledovány odchody a příchody do zařízení. V zařízení také nastávají události. Během kterého pobytu které osoby v zařízení nastaly více než 2 události sledovaného typu? Potřeba GROUP BY podle osoby a období! období nejsou pravidelná, podle žádného rozvrhu...
Primární klíče Zaměstnanec pracoval době od..do na úkolu. Záznamy se nemají překrývat
Normalizace Host byl ubytován v hotelu v období od..do navazující období by se měly spojit
Integritní omezení Když zaměstnanec pracoval v období od..do na úkolu, pak tento zaměstnanec v tomto období musel být v zařízení.
Datový typ období od..do Specifické operace průnik sloučení Specifická porovnání překrývání dříve, potom jestli okamžik spadá do období
Implementace datového typu období Doposud v SQL DBMS není Nahrazováno dvojicí údajů typu datetime Předchozí požadované operace a porovnání je třeba programovat.
1. přístup Zapisuje se žurnál změn Např. se zapisují změny ceny, odkdy platí. Problém 1: Sleduje se jediná cena. Kdy nastalo zdražení o 10%? Řešení: Můžeme záznamy v žurnálu průběžně číslovat (nový záznam má číslo o 1 větší než poslední záznam). SELECT C2.datum FROM Ceny C1 JOIN Ceny C2 ON(C1.cis+1=C2.cis) AND C2.cena>=C1.cena*1.1
Problém 2: Sleduje se více cen. Kdy nastalo zdražení něčeho o 10%? (Průběžné číslování záznamů ceníku nepomůže.) SELECT C2.produkt, C2.datum FROM Ceny C1, Ceny C2 WHERE C1.produkt=C2.produkt AND C1.datum<C2.datum AND C2.cena>=C1.cena*1.1 AND NOT EXISTS (SELECT * FROM Ceny C3 WHERE C1.datum<C3.datum AND C3.datum<C2.datum) Efektivita?!?
Možné řešení: Pro každý produkt zapisujeme poslední číslo záznamu v ceníku. SELECT C2.datum FROM Ceny C1 JOIN Ceny C2 ON(C1.cis+1=C2.cis AND C1.produkt=C2.produkt) AND C2.cena>=C1.cena*1.1 Režie z udržování posledních čísel záznamů pro jednotlivé produkty... Toto je řešení jen pro tento specifický druh dotazu. Jiné možné dotazy: zdražení o 10% během 1 měsíce...?
Problém 3: Objednávka byla podána v nějaký den. Jaká tehdy platila cena? SELECT C1.cena FROM Ceny C1, Ceny C2 WHERE C1.produkt=C2.produkt AND C1.produkt=@p AND C1.datum<C2.datum AND C1.datum<=@d AND C2.datum>=@d AND NOT EXISTS (SELECT * FROM Ceny C3 WHERE C1.datum<C3.datum AND C3.datum<C2.datum) Efektivita?!?
Možné řešení: Přidáme údaj do. SELECT cena FROM Ceny WHERE produkt=@p AND od<=@datum AND do>=@datum Stále ještě ne ideální řešení, málo efektivní provádění dotazů. Praktické řešení: Do objednávky zapisujeme cenu platnou v době objednání. Je toto univerzální řešení?
Problém 4 (podobný jako dříve): Během kterého pobytu které osoby v zařízení nastala událost sledovaného typu? Vedou se žurnály: Záznamy o průchodu vstupem do zařízení. Záznamy o událostech. Řešení dotazu? obtížné... Špatná efektivita. Možné řešení: identifikátory pro každý pobyt, a tabulky provazující události a pobyty...
2.přístup Historie a současnost se vedou zvlášť. historické záznamy s platností od..do aktuální záznamy s aktuálním stavem, event. s údajem odkdy tento stav platí Podobně rozdělení IS na Transaction Processing systém (TPS) Data Warehouse (DWH) Procesní dotazy se řeší v TPS prosazování business rules Dolování dat se provádí v DWH
Řešení temporality v DWH (obecně v historických datech) Libovolná období od..do se nepovolují místo toho roky, čtvrtletí, měsíce,... Podobně deníky a žurnály dodržují rozvrhy týdny, dny, směny... Pouze určitá období, mající ID a event. skladbu celek-část
6. normální forma Pro historická data o stavech objektů a období, kdy tyto stavy platily. Objekt měl v období od..do stav a 1,...,a n Nový záznam vždy, když se změní některé z a 1 až a n..redundance informace o ostatních a i Normalizace: Modelujeme atomické fakty pro časové snímky, ukládáme záznamy o časové platnosti těchto atomických faktů:
OID období atribut1 atribut2 1 01-02 A B 1 03-04 A C 1 05-06 D C normalizace OID období atribut1 1 01-04 A 1 05-06 D OID období atribut2 1 01-02 B 1 03-06 C
3.přístup Zpracování proudů dat: Předdefinované dotazy, prováděné průběžně na vyrovnávací paměti zdražení o 10% opakovaný pokus o přístup ke zdroji v krátkém časovém rozmezí nutná paměť jen pro potřebou část fronty přicházejících dat, ke zpracování dotazů oznamování událostí Zprávy nebo události můžeme ukládat do skladu pro učení definice nových dotazů
Závěr Pro datový sklad s historickým fakty, s udáním období jejich platnosti od..do, tato období libovolná, obtížná proveditelnost dotazů týkajících se: předchozí, následující dvojice faktů s požadavkem na časový interval mezi nimi časová koincidence událostí, období event. agregace vzhledem k období