Zpracování informací

Ústav automatizace a informatiky Fakulta strojního inženýrství Vysoké učení technické v Brně

Přednáška č. 3 z předmětu

Zpracování informací © Ing. Radek Poliščuk, Ph.D.

Tato publikace vznikla jako součást projektu CZ.04.1.03/3.2.15.2/0285 „Inovace VŠ oborů strojního zaměření“, který je spolufinancován evropským sociálním fondem a státním rozpočtem České republiky

Zpracování informací, přednáška 3.

1/19

Ohlédnutí – přednášky 1 a 2 Abychom získali INFORMACE, potřebujeme DATA. Technická data získáváme měřením a sledováním. Logické a spojité veličiny (signály) měříme pomocí snímačů (senzorů). Pro elektronické zpracování je nutný převod do formy elektrického signálu (U,I...). Pro digitální zpracování se signály vzorkují (v čase) a kvantují (A/D). Data ze senzorů obvykle potřebujeme někam přenést, archivovat a analyzovat. Technickou úroveň a rychlost přenosu přizpůsobujeme rozpočtu dané úlohy.


2/19

Obsah přednášky Přednáška 3 – Záznam a organizace dat Metody ukládání dat Typické datové formáty „Flat File“ databáze Sekvenční procházení, filtrování a indexování dat Relační formy dat

Realita

DATA

Informační systém

Informace Příjemce


3/19

Metody ukládání dat Stojí-li za to data přenést, má smysl si je i zapamatovat pro opětovnou analýzu: nezálohovaná RAM (mikropočítače, mikrořadiče... ) při výpadku napájení dojde ke ztrátě dat) jen pro „postradatelná“ data, nebo data která se okamžitě předávají nadřízenému systému nutné cyklické obnovování dat (refresh) => nevýhodné pro bateriový provoz buňka = kondenzátor + MOSFET


4/19

Metody ukládání dat Stojí-li za to data přenést, má smysl si je i zapamatovat pro opětovnou analýzu: zálohovaná paměť (SRAM+ultrakondenzátor/lithiová baterie), konstrukčně složitější než DRAM (6 tranzistorů) minimální odběr proudu, nepotřebuje refresh

Flash paměti (bez nutnosti napájení) pro krátkodobé ukládání (~měsíce), s možností uploadu kritických dat do nadřízeného systému. obdobné schéma jako RAM (NAND nebo NOR zapojení) řídící brána (FG) MOSFET tranzistoru je oddělená dielektrikem => dlouhodobé uchování náboje zápis = nabití FG „zábleskem“ zvýšeného napětí čtení = rozlišování vodivých/nevodivých buněk mazání = vybití příslušného bloku FG (nevhodné jako RAM) SLC (single level cell): Až 1M zápisů, MLC 1000 - 100 000


5/19

Metody ukládání dat Stojí-li za to data přenést, má smysl si je i zapamatovat pro opětovnou analýzu: magnetická média (pásky, floppy disky, floptical disky, pevné disky,...) pro střednědobou archivaci (~roky), u nezapouzdřených médií (pásky, kazety, diskety) citlivost i na opakované čtení! (mechanické opotřebení) pevné disky – médium není v mechanickém kontaktu z hlavičkou (Bernoulliho efekt) => vysoká životnost, NIKDY NEOTEVÍRAT!


6/19

Metody ukládání dat Stojí-li za to data přenést, má smysl si je i zapamatovat pro opětovnou analýzu: magnetooptická média (magnetický zápis po zahřátí nad Curieho bod, optické čtení ∆n – Kerrův efekt) dlouhodobá archivace, kapacity až 2*4,6GB (130mm disky), velmi vysoká cena (=> DVD-RAM). optická média (distribuce, střednědobá archivace, střídavý 8-14 zápis ražením/propalováním substrátu) CD (CD-R, CD-RW): u médií se „zlatým“ substrátem „až desítky let“, organické substráty - roky. DVD (DVDR, DVDRW, DVD-RAM): obecně nižší spolehlivost než CD (distribuční formát!) HD-DVD, Blu-Ray Disc: Určeno především k distribuci, pro archivaci (i cenově) nevhodné. HVD (Holographic Versadile Disc): Kapacity až 300MB-1,6TB, místo logických „pitů“ (0/1) povrch reaguje na vzájemnou fázi 2 laserových svazků (R/G), extrémní ceny, životnost „až 50let“...


7/19

Přístup k datům IS musí být vždy schopen svá data rychle, spolehlivě a jednoznačně lokalizovat... Mít vždy 1 dokument na 1 médiu nebývá vždy nejlepší řešení . . . Jak jich tam ale dostat víc najednou a vyznat se v tom?

Prehistorie IT... (děrná páska)

jednotlivé sešity...

? …vs. kroužkový blok


Virtuální stopy a sektory 8/19 na disku

Přístup k datům Všechny OS a IS dnes pracují s daty v souborech, evidovaných v adresářích: každý soubor je v souborovém systému jednoznačně lokalizovatelný svou cestou: file:\\localhost:\C:\windows\explorer.exe:ADS přístupový protokol (nepovinné, předpokládá se „soubor“) hostitelský počítač (nepovinné, předpokládá se lokální stanice) cesta v příslušném souborovém systému (v OS Windows a/typicky začíná písmenem disku a dvojtečkou) jméno souboru (pojmenování musí respektovat specifika daného OS) přípona typu souboru (nepovinné, v případě nejasností pomáhá určit typ dat) více o příponách např. na http://www.computerhope.com/dosext.htm

Alternate Data Streams - alternativní verze (MacOS), pomocné informace,viry... (NTFS/Windows) lokalizace a interpretace dat uvnitř datového souboru pak záleží na zvoleném formátu: binární soubory: specifické řešení pro daný formát (Paketové streamy, RIFF data...) tabulkové soubory: data mají tvar 2D matice (~Array[y,x]: y~záznamy, x~položky) značkované soubory: interpretr vrací datový strom (větve, parametry, data) Zpracování informací, přednáška 3.

9/19

Souborové formáty Způsob budoucího použití předurčuje formát, ve kterém je vhodné data zapsat:


10/19

Souborové formáty Způsob budoucího použití předurčuje formát, ve kterém je vhodné data zapisovat: tabulkové dokumenty v souborovém systému a nebo v databázi: data mají charakter tabulky, s jednotlivými záznamy po řádcích a detaily ve sloupcích každý záznam obsahuje jednoznačně definované, uspořádané a formátované položky čitelná (textová) forma – TXT, CSV nebo binární – DBase, Paradox, spreadsheety... s proměnnou nebo pevnou délkou záznamu (typ RECORD – heterogenní data v rámci záznamu) podpora optimalizovaného procházení a řízení přístupu na úrovni většiny OS

jednotlivé binární dokumenty v souborovém systému (1 záznam ~ 1 soubor): u objemnějších dat s nestálou velikostí může být výhodná archivace ve formě vhodně umístěných a pojmenovaných binárních souborů – JPG, WAV/MP3, MPG.. nevhodné pro soubory dat menších nebo řádově ~ alokační jednotce použitého disku.

textové značkované dokumenty (UML, HTML, XML, dokumenty s datovými poli): technika původně určená k podpoře strojové extrakce dat z čistě textových dokumentů uvnitř textového/binárního dokumentu jsou smluvní značky, označující podstatná data každý dokument je tak „kontejnerem“, obsahujícím 1 a nebo více vnořených záznamů vícenásobné záznamy UML obecně nemají charakter tabulky, ale stromu (např. víceúrovňový obsah knihy: každý název je jinak dlouhý, každá kapitola má jiný počet podkapitol...) kořen (, <XML>...) větve (..., ...,...) výhodné pro přenos a práci s „neuspořádanými“ heterogenními daty v textové formě. fyzicky jde opět o jednotlivé, vhodně umístěné a pojmenované dokumenty v soub.sys. Zpracování informací, přednáška 3.

11/19

„Flat file“ databáze Většina inženýrských dat se kterými se setkáte bude mít charakter seznamů a tabulek...

...které jednou budete muset interpretovat:


12/19

„Flat file“ databáze

... AssignFile(Data ,Filename);//výběr //výběr souboru AssignFile(Data,Filename); Reset(Data ); //otevření typového soub. Reset(Data); While not EOF(Data ) do //Dokud nejsme na konci.. EOF(Data) begin read(Data ,Zaznam);//načti //načti další záznam read(Data,Zaznam); If Zaznam.Plat>10000 then //pokud splňuje.. writeln(Zaznam.Jmeno,' ',Zaznam.Prijmeni); End; Closefile(Data ); //Hotovo, zavřít soubor. Closefile(Data); ...

Historicky se data organizovaly v tabulkách po záznamech (řádcích) s pevnou délkou (odtud označení „Flat File“ - soubor se dal považovat za jasně danou 2D mapu dat s danými typy): typ čísel definoval přesnost (byte, word, integer, longint, short, real, double, currency, extended...) logické a výčtové typy se deklarovaly jako indexová ordinární čísla (boolean, wordbool...) datově/časové údaje se definují jako „počet dnů“ nebo „sekund“ od určitého data (1.1.1900..) textové řetězce (znakové posloupnosti, Ascii nebo Unicode) měly určenou maximální délku. Pro manipulaci s daty byl do všech OS přijat sekvenční způsob přístupu k datům soubory se nečtou/nezapisují „vcelku“ (jako úplná kopie paměti a pod.), ale po záznamech; vyhledávání se provádí postupným procházením záznamů „od BOF do EOF“ (viz ukázka) úpravy záznamů se díky jejich pevně danému rozměru mohou provádět „záměnou na místě“, "smazání" záznamu se provádí snulováním a nebo příznakem "zrušeno" (soubor se nezmenšuje) nové záznamy se přidávají buď na konec souboru (otevření souboru metodou „Append“) Omezení plynoucí z „flat-file“ přístupu k datům: u dlouhých záznamů s velkým počtem předimenzovaných polí rychle narůstá délka souboru; Řešení 1: Zavedení tabulek s proměnnou délkou záznamu a indexovými soubory při změně formátu/pořadí polí je nutné tabulku zreplikovat v novém tvaru a upravit i aplikace Řešení 2: Zavedení rozhraní, umožňujícího logické adresování fyzických dat nemožnost použití dynamických polí (typy "Memo", variant, BLOB, OLEcontainer, vícenásobná pole) Řešení 3: Separace obsahu dynamických polí do paralelních tabulek s proměnnou délkou záznamu, nebo do samostatných souborů v rámci soub. systému (vazba 1:1). Řešení 4: Logické oddělení vícenásobných dat do tabulek připojených relacemi 1:N (M:N) 13/19 Zpracování informací, přednáška 3.

Indexování dat Víme-li kde data jsou, můžeme je projít - jenže úplné sekvenční procházení zdržuje... Obsah

Vázaná kniha

Adresářová struktura

...vhodné řešení?

Svitek tóry, cca 1200 př.n.l.

14/19

Zpracování informací, přednáška 3. Jmenný rejstřík

Indexování dat Víme-li kde data jsou, můžeme je projít - jenže úplné sekvenční procházení zdržuje... Pro často prohledávané položky záznamů je proto vhodné vytvářet INDEX (klíč): index mívá tvar posloupnosti odkazů na data (čísel záznamů, ukazatelů, názvy souborů...); index bývá řádově menší než původní data (=> rychlejší procházení, možnost cachování); vždy bývá seřazený podle daného typu dat (např. podle abecedy, číselné hodnoty,...); díky řazení je možné data procházet optimalizovaně (půlení intervalů, zlaté řezy,...); je-li hledaný klíč unikátní (primární klíč/ID), pak shoda indexu = identifikace záznamu. pro různé druhy dotazů je možné udržovat více indexů, fyzické řazení dat v datovém souboru tak díky indexům nehraje roli. Aby nebylo nutné data reindexovat při každém prohledávání (..výpočetně náročné), bývají indexy uloženy v tzv. indexovém souboru, který se aktualizuje při každém přidání a nebo úpravě záznamu (jde tedy jen vřazení, připojení a nebo odstranění položky): Vložení záznamu = připojení záznamu na konec souboru + zařazení do indexů Odstranění záznamu = označení záznamu za neplatný + vyřazení z indexů v tabulkách se data NIKDY fyzicky nemažou, jen „zneplatňují“ (není nutná reindexace) prostor po zneplatněných datech může být „zrecyklován“ při dalším vřazování

Úprava záznamu = odstranění a vložení záznamu, viz výše.

je-li délka záznamu pevná, provádí se odstranění/vložení jen v ovlivněných indexech.


15/19

Relační uspořádání dat Prodej

FLAT FILE

Čistě 2-rozměrná topologie tabulek nemusí být příliš efektivní: Zázn. 1 2 3

Datum 10.1.2008 12.2.2008 14.2.2008

Zákazník Josef Novák Alois Skočdopole Josef Novák

Adresa IČ Zakoupil KS Zadní 2, 616 24 Kocourkov 58848421 šroubek M6 1500 Přední 4, 731 12 Kotěhůrky 72258463 matka M10 10 Zadní 2, 616 24 Kocourkov 58848421 matka M10 800

á Zaplaceno 0,80 Kč převodem 2,50 Kč hotově 2,50 Kč převodem

ID Datum Zákazník Adresa IČ Zakoupil KS á zaplaceno

položky datových záznamů by měly obsahovat jen pro ně specifická data pokud je možnost odkázat se na relevantní data jinam, lze opisování zbytečných dat nahradit vazbou (relací) na relevantní datový zdroj:

RELAČNÍ DATABÁZE

Fyzické uspořádání dat v tabulkách, propojených relacemi: Prodej 1 2 3

Datum 10.1.2008 12.2.2008 14.2.2008

Kontakt 1 2 3

Jméno Josef Novák Alois Skočdopole Ferona, a.s.

Katalog Název 1 šroubek M6 2 matka M10

Kontakt_ID 1 2 1

Katalog_ID 1 2 2

KS 1500 10 800

á Zaplaceno 0,80 Kč převodem 2,50 Kč hotově 0,80 Kč převodem

Adresa IČ Zadní 2, 616 24 Kocourkov 58848421 Přední 4, 731 12 Kotěhůrky 72258463 Havlíčkova 11, Praha 1 26440181

Dodavatel 3 3

á 0,80 Kč 2,50 Kč

Telefon 756 855855 255 847682 224 724111

kg 0,01 0,02

Výhody: úspora místa, konzistence dat, méně chyb při zadávání Omezení: relace nesmějí být aplikovány na časově proměnná pole Zpracování informací, přednáška 3.

Relační schéma: Prodej ID Datum Kontakt_ID Katalog_ID KS á Platba Kontakt ID Jméno Adresa IČ Telefon

Katalog ID Název Dodavatel á kg

16/19

Relační uspořádání dat Zjednodušené zásady správného návrhu relační databáze: Normalizace = Eliminace nadbytečných dat Atomizace polí (informace bychom neměli „dolovat“ dalšími funkcemi, např. jméno/příjmení) Unikátní/primární klíče (jednoznačná identifikace záznamu přes jedno nebo více jeho polí) Funkcionální závislost (záznam popisuje to co se týče daného objektu – přímo nebo relacemi) Nezávislost polí (změna jednoho pole by neměla ovlivňovat jiná – např. sazba a částka DPH) (nesystémové ale praktické) výjimky z normalizačních zásad: Zvýšení výkonnosti u časově kritických úloh Vyhodnocujeme-li často některou náročně počítanou hodnotu, pak může být výhodné pole s jejím výsledkem připojit k záznamu (ale při každé změně ji důsledně přepočítávat !!!). např.: pole typu „Celkem vč. DPH“ v tabulce faktur mohou urychlit tvorbu přehledů.

Zachycení časově proměnlivých dat Vyhýbáme se odkazům na pole v jiných tabulkách, jejichž změna by za čas mohla vadit. Např.: Fakturovanou částku za položky uvádíme vždy přímo (protože změna „katalogové“ ceny, na kterou by se dalo odkazovat, by mohla zpochybnit i již uzavřené obchody...=> finanční úřad =>). Nebo: Dále nevázaná zodpovědnostní pole typu „doklad vystavil“ neodkazovat někam do adresáře, ale při vystavování jej pouze naplnit kopií aktuální hodnoty (Dotyčný pracovník už ve firmě za měsíc pracovat nemusí a jeho záznam může být odstraněn/změněn...)Zpracování informací, přednáška 3.

17/19

Stromy a relace Stromové struktury lze převádět na relační:

FAKTURA-daňový doklad

číslo/var. symbol 200801

Vystavil: Šroubkař, s.r.o. Prostřední 2, 617 00 Brno IČ: 659035

Příjemce: Josef Novák Zadní 2, 616 24 Kocourkov IČ: 58848421

Způsob platby: Převodem Číslo účtu: 5956351/5100

Vystaveno: 1.2.2008 Splatnost: 1.3.2008

Položky: 1. Šroubek M6 1500ks á 0,80 Kč Celkem 1200,00 Kč +DPH 19% 2. Matka M10 800ks á 2,50 Kč Celkem 2000,00 Kč +DPH 19%

<XML> Celkem: 3200,00 Kč Vystavil: Šroubkař DPH 19%: 608,00 Kč Podpis: +++ K úhradě: 3808,00 Kč Razítko: :-) Šroubkař, s.r.o. Prostřední 3, 617 00 Brno 659035 Šroubkař Faktury ID 200801 Převodem Vystaveno 1:N 5956351/5100 Splatnost Kontakty 1.2.2008 Položky Platba <Splatnost>1.3.2008 ID ID Partner_ID <Partner> Jméno Faktura_ID Josef Novák Adresa Popis Zadní 2, 616 24 Kocourkov IČ KS 58848421 Telefon Cena_KS Šroubek M6 1500 0,80 K záznamu ID=200801 v tabulce „Faktury“ budou 2 záznamy v tabulce „Položky“ s hodnotou pole Faktura_ID=200801 (tím vzniká relace 1:N vůči Matka M10 nadřazenému objektu). Takto je dáno, že fa. 200801 bude mít 2 položky. 800 2,50 ...Všimněte si, že nikde nejsou uváděny spočitatelné údaje typu „Celkem“


18/19

Shrnutí Souborový formát a rozmístění dat volíme s ohledem na budoucí použití (datové tabulky, jednotlivé binární soubory, datové stromy ve značkovaných souborech). Sekvenčně zapisované tabulky s pevnou délkou záznamu mají řadu omezení Rychlost prohledávání datových záznamů je možné optimalizovat použitím indexů. Množství dat v tabulkách je možné zredukovat použitím relací Data nemusejí nutně mít jen tvar „pravoúhlých tabulek“, propojených relacemi. ...některé druhy informací může být efektivnější/přehlednější držet například ve formě stromu.


19/19

Zpracování informací

Recommend Documents