Source: http://itpravo.cz/index.shtml?x=63674
Timestamp: 2018-01-17 09:06:35+00:00

Document:
Princip moderního informačního systému založeného na podnikové relační databázi v porovnání s historickými způsoby evidence dat
1. Doba kamenná
V dobách, kdy ještě neexistovaly počítače, všechny evidence se vedly v sešitech nebo knihách. Každý sešit sloužil pro evidenci jiných druhů událostí, subjektů či objektů. (Evidence stížností, evidence majitelů loděk, evidence nabízeného zboží). Jakýkoliv zápis v sešitu měl řádky a sloupce.
Jeden řádek zápisu byl buď evidencí nové události, subjektu či objektu nebo změn či oprav vážících se k řádkům již evidovaným.
Sloupce sešitu označovaly atributy evidovaných událostí nebo atributy evidovaných subjektů či objektů. (datum stížnosti, předmět stížnosti, příjmení referenta vyřizujícího stížnost / jméno majitele loďky, příjmení majitele loďky, bydliště majitele loďky / název druhu zboží, cena zboží, druh použitého obalu).
Z výše uvedeného vyplývá, že řádky zápisů v sešitech se z principu nedají nijak přeskupovat - třídit (jsou na papíře), informace zjišťujeme tak, že různými sešity listujeme a děláme si výpisky.
Od vzniku počítačů (a často bohužel až dodnes) se výše popsaný princip sešitů - metodika sešitů - používá naprosto stejně, s tím rozdílem, že sešity jsou elektronické, uložené na discích počítačů, a sešitům se říká "soubory" či "databáze" (využíváme-li relační databázový systém takto, je to jako kdybychom k dopravě kufrů na letišti využívali místo multikáry jumbo jet).
Systémy elektronických sešitů mají ovšem oproti papírovým sešitům tu výhodu, že v nich můžeme vyhledávat podle hodnot nejrůznějších atributů. Vyhledávání je rychlé a jednoduché. Tím ale výhody tohoto systému končí.
Elektronické sešity mají ovšem do svého genomu zabudovány především následující systémové chyby: Veškerá data v těchto elektronických sešitech jsou nekonsolidovaná (v různých řádcích různých sešitů při porovnání mezi sebou nalézáme sobě si odporující informace a nevíme, jak a co a za jakých podmínek vlastně kdy platilo - a co vlastně bylo správně? - a jak a co platí dnes) a duplicitní (řada údajů - hodnot atributů - je v evidencích zbytečně mnohokrát na nejrůznějších místech a aktualizace těchto zápisů je prakticky neproveditelná). Příklad: Máme databázi majitelů psů a obyvatel. Máme tedy v tomto systému dva nezávislé "elektronické sešity". V jednom sešitě máme totéž v co v tom druhém - adresu majitele psa pana A a adresu obyvatele pana A. To je duplicita. Může se stát, že se pan A přestěhuje a svou změnu nahlásí, ta ale bude zanesena jen do databáze ("elektronického sešitu") evidence obyvatelstva. Stará a neplatná adresa zůstává v databázi evidující majitele psů. To je nekonsolidovanost. V případě více databází ("elektronických sešitů") jsou tyto problémy mnohem markantnější. Přitom obě databáze vede ten samý subjekt - například obecní úřad.
Princip "sešitů" je v podstatě agendový přístup, kdy jedna agenda (vedená v jednom sešitě) neví nic o agendě jiné (vedené v jiném sešitě), i když vědomě či nevědomě (v každém případě nekontrolovaně) pracuje se stejnými subjekty, objekty či událostmi. Dvě nezávislé agendy evidují paralelně nevědomky hodnoty nějakých atributů. Jsou evidovány různé hodnoty. Která z nich je správně, má-li být tato hodnota použita v agendě třetí? Spolupráce a návaznost agend je velmi obtížná. Příklad: Na stejném obecním úřadě se vytváří se databáze evidující majitele motorových vozidel. Porovnáním již existujících databází se zjistí, že pan A má dvě adresy - jednu v databázi obyvatel a jinou v databázi majitelů psů. Jaká je správná ? To úřad nezjistí a musí obtěžovat pana A a vyžádat si od něj tuto informaci. Tu zjistí a vytvoří nový elektronický sešit - evidence majitelů motorových vozidel. Tam je uvedena (stejně jako v evidenci obyvatelstva) jeho správná adresa. Je ale více než pravděpodobné, že si adresu pana A v registru majitelů psů neopraví. Pak jeden a týž subjekt (obecní úřad) vede v třech různých databázích tři stejné údaje - adresu pana A. Z toho je jeden tento údaj zcela špatný (v evidenci majitelů psů). Takový systém databází je prakticky nepoužitelný.
Amatérská představa využívání relační databáze pouze jako "elektronického sešitu" je jednou z největších fundamentálních omylů nejen laiků ale i řady současných informatiků, kteří do geniálního a již několik desetiletí starého principu relačních databázových systémů ještě nepronikli a tedy jej neumí správně využít resp. pochopit, proč byl vlastně vymyšlen.
Zákon o ochraně osobních údajů podle mého názoru bohužel předpokládá, že informační systém je postaven pouze na principu "doba kamenná" nebo "doba bronzová".
Analytik společně s managementem podniku vytipuje tak zvanou "předmětnou oblast", kterou se bude podnikový integrovaný informační systém (PIIS) podniku zabývat. Pod pojmem předmětná oblast si můžeme představit řadu vzájemně provázaných procesů představující náplň činnosti podniku včetně veškerých druhů subjektů, objektů a jejich atributů používaných ve všech procesech předmětné oblasti.
Záměrem je prioritně jednoznačně a neduplicitně v čase evidovat nejen veškeré procesy a jejich návaznost (workflow) tak, aby si mohl klient podniku své záležitosti vyřizovat interaktivně sám z domova přes internetový prohlížeč - pracuje nad konsolidovanou podnikovou relační databází.
Nedefinují se žádné "elektronické sešity", ale jednotné konceptuální datové schéma konsolidované integrované relační databáze.
Padají veškeré bariéry mezi "agendami", protože snahou je evidovat veškerá data jednotně, správně a v čase je aktualizovat dochází-li ke změnám (ať už zdrojem změny je jakákoliv agenda), přičemž staré hodnoty údajů nemažeme, ale stále evidujeme včetně intervalu platnosti, v nichž platily.
Většina informací je v dobře navržené relační struktuře uložena ve vazbách.
Neevidujeme tedy jméno osoby, příjmení osoby, adresu osoby, název objednávaného výrobku a číslo objednávky v nezávislém elektronickém sešitě "objednávky", nýbrž jméno a příjmení osoby evidujeme v číselníku osob, adresu evidujeme v číselníku adres, název výrobku evidujeme v číselníku výrobků, číslo objednávky evidujeme v číselníku obchodních případů jako číslo obchodního případu.
Jak to vše propojíme?
Vytvoříme vazební tabulku "bydliště osoby" mezi číselníkem osob a číselníkem adres s atributy "platí od" a "platí do", čímž evidujeme v celém systému jednoznačně, kdo kde bydlí od kdy do kdy bez ohledu na agendu, jíž se to týká. Platí to totiž všeobecně! Každá agenda, která aktualizuje vazbu osoby na bydliště, aktualizuje tuto vazbu pro jakékoliv ostatní agendy!
Vytvoříme vazební tabulku "objednávka" mezi číselníkem osob, číselníkem výrobků a číselníkem obchodních případů s atributy "platnost objednávky od" = aktuální datum, "platnost objednávky do" = nekonečno = otevřená objednávka, čímž evidujeme v celém systému jednoznačně, kdo, co, kdy objednal a od kdy objednávka platí, přičemž víme, že na objednávku ještě nezareagovala výroba.
Příklad: Jméno našeho pana A je uvedeno v číselníku ("škatulce") osob. Jeho adresa je dána číselníkem nemovitostí, jeho vozidlo číselníkem motorových vozidel a jeho pes číselníkem psů. Propojením těchto číselníků a přidáním dalších atributů velmi lehce zjistíme, že pan A se dnes jmenuje XY, bydlí Na Zelené louce 16, že vlastní mazdu 323 a jeho pes je kokršpaněl Rek. Pokud se pan A přestěhuje, stačí propojit jeho jméno v číselníku osob s jinou nemovitostí (adresou) v číselníku nemovitostí a hned víme, že pan A se jmenuje XY, bydlí Na Červené louce 24 (přitom stále ale víme, že v období od 1996-2001 bydlel na Zelené louce 16) a stále má psa Reka a mazdu 323.
To je shromažďování poměrně velkého množství osobních údajů. Může být namítáno, že když potřebuji zjistit majitele psa Reka, nemusím vůbec vědět, že je jeho pán majitelem mazdy 323. To je úplná pravda. Je třeba si ale uvědomit, že přístup k dalším údajům (např. vlastnictví mazdy 323) lze podle účelu dotazu (např. hledám, kdo je majitelem psa Reka) zakázat. Navíc jsem uvedl příklad obecního úřadu, který tak jako tak shromažďuje údaje z více oblastí (pro různé účely), zatímco například krejčí by i v rámci svého PIIS vedl pouze údaje o jméně, adrese a mírách svého zákazníka.
Uvedené údaje v různých databázích jednoho subjektu (různé elektronické sešity obecního úřadu) existují. Všechny tyto údaje zcela legálně shromažďuje. Z dikce zákona na ochranu osobních údajů (ZOOÚ) výše uvedené slučování dat není povoleno. Subjekt, který tak jako tak vede údaje z více oblastí (majitelé psů, evidence obyvatelstva, majitelé motorových vozidel) musí vést ony "elektronické sešity" z doby bronzové, se všemi jejich nedostatky.
Zákon o ochraně osobních údajů, relační databáze, SQL a Internet
Zákon 101/2000 Sb. se snaží v dobré víře ochránit osobní údaje o fyzických osobách. Tvůrci zákona ovšem neberou na vědomí principy ukládání dat v dobře navržené relační databázi, datovou integritu, Internet a ustrnuli v představě, že data se evidují buď v sešitě nebo v jednoduchých datových souborech.
Důsledné dodržování litery tohoto zákona vytváří z odpovědných tvůrců a správců databází potencionální zločince, kteří se musí neustále třást před sankcemi za to, že svou práci dělají odpovědně a správně.
Naopak, tvůrci mnoha neintegrovaných jednoúčelových databází (elektronických sešitů) jsou tímto zákonem vlastně chváleni, protože nevytvářejí integrovanou kvalitní podnikovou databázi (PIIS), ale množinu různých chaotických nesouvisejících souborů či databázových tabulek s neintegrovanými údaji bez historie (viz uváděné příklady o panu A, jeho psu a změně adresy).
V době rozvinuté informační společnosti, která nechce občanům jen škodit, jak zákonodárce pravděpodobně předpokládá, ale velmi často jim i sloužit a pomáhat (viz např. veřejná správa a nejrůznější služby, kde se vytvářejí pro tyto účely relační databáze s dotazovacím jazykem SQL přístupné přes webovský server a internetový prohlížeč), působí tento zákon v mnoha ustanoveních nedomyšleně a kontraproduktivně. V budoucnu jistě dozná řady novelizací, resp. se budou vytvářet nové speciální zákony, např.[1], které svým zněním zákon 101/2000 eliminují.
Jak vyplývá z německéha zákona na ochranu osobních údajů,[2] v Německu mají veřejnoprávní instituce v oblasti ochrany osobních údajů větší práva než běžné komerční subjekty, což v našem zákoně neplatí.
Připomeňme si některá ustanovení zákona 101/2000, která jsou zajímavá z hlediska relačních databází a jazyka SQL. Kurzívou komentáře autorů příspěvku:
· § 4 a) Pro účely tohoto zákona se rozumí osobním údajem jakýkoliv údaj týkající se určeného nebo určitelného subjektu údajů. Subjekt údajů se považuje za určený nebo určitelný, jestliže lze na základě jednoho či více osobních údajů přímo či nepřímo zjistit jeho identitu. O osobní údaj se nejedná, pokud je třeba ke zjištění identity subjektu údajů nepřiměřené množství času, úsilí či materiálních prostředků.
· § 4 c) anonymním údajem takový údaj, který buď v původním tvaru nebo po provedeném zpracování nelze vztáhnout k určenému nebo určitelnému subjektu údajů.
Anonymizace je operace snadno proveditelná v dimenzionálním datovém skladu. Popis technických řešení přesahuje rozsah tohoto článku a zájemci jej naleznou v článku "OLTP Dimenzionální Model a ochrana osobních údajů" pod odkazem PUBLIKACE na adrese WWW.SOFTMODEL.CZ
· § 5 (1) c) Správce je povinen zpracovávat pouze pravdivé a přesné osobní údaje, které získal v souladu s tímto zákonem. Je povinen ověřovat, zda jsou osobní údaje pravdivé a přesné. Zjistí-li správce, že jím zpracovávané údaje nejsou s ohledem na stanovený účel pravdivé a přesné, zejména k námitce subjektu údajů, je povinen je blokovat a bez zbytečného odkladu opravit nebo doplnit. Nelze-li je opravit nebo doplnit, musí je bez zbytečného odkladu zlikvidovat. Nepravdivé, nepřesné nebo neověřené osobní údaje lze zpracovávat pouze v případě, stanoví-li tak zvláštní zákon. Tyto údaje se musí náležitě označit a vést odděleně od ostatních osobních údajů.
· § 5 (1) d) Správce je povinen shromažďovat osobní údaje odpovídající pouze stanovenému účelu a v rozsahu nezbytném pro naplnění stanoveného účelu.
· § 5 (1) e) Správce je povinen uchovávat osobní údaje pouze po dobu, která je nezbytná k účelu jejich zpracování. Po uplynutí této doby mohou být osobní údaje uchovávány pouze pro účely statistické, vědecké a pro účely archivnictví. Při použití pro tyto účely je třeba dbát práva na ochranu před neoprávněným zasahováním do soukromého a osobního života subjektu údajů
Zpracovávat pravdivé a přesné osobní údaje je jedině správné. Této činnosti ovšem podstatně brání § 5 (1) e) a § 5 (1) h) ZOOÚ.
Pravdivé a přesné údaje můžeme evidovat pouze tak, že se snažíme dozvědět se o jejich změně co možná nejdříve, údaje při změně co nejdříve aktualizovat a historii těchto hodnot evidovat a ne mazat.
Existují totiž přirozené dlouhodobé až kontinuální obchodní a správní procesy vzájemně se překrývající, při nichž se musí pracovat jak s daty aktuálními, tak s daty historickými používanými v těchto procesech paralelně s hodnotami aktuálními.
Abychom to mohli realizovat, musíme využít jakékoliv možné příležitosti, jak získat informace o tom, že se sledovaný údaj změnil. Tuto příležitost poskytuje (mimo jiné věrohodné zdroje) především fyzická osoba samotná, která v rámci jednoho podniku řeší své různé nesouvisející záležitosti, např.:
Vyřizování různých nesouvisejících správních řízení na jednom úřadě - především přes Internet - ne ale neustálým novým a novým vyplňováním různých prázdných elektronických formulářů, ale inteligentní web-databázovou technologií, kdy již jednou evidované osobní údaje klienta získané v různých dobách z různých důvodů budou klientovi pouze nabídnuty k verifikaci v prohlížeči.
Postupné objednávky různých dodávek u stejného podniku, např. u jednoho internetového knihkupectví
Údaj se nejlépe a přirozeně aktualizuje při přímém styku podniku s osobou (Internet, email, telefon, osobně, písemně), i když kontakt může být z jakéhokoliv důvodu. Příkladem je aktualizace emailových adres, telefonních čísel, adresy bydliště, kontaktní adresy, příjmení u vdávajících se žen atd.
Změní-li se z rozhodnutím Obecního Zastupitelstva jméno nějaké ulice, promítne se to v integrovaném systému do všech osobních dat všech tím "postižených" občanů, aniž tito musí běhat po různých odborech Úřadu a zbytečně ztrácet čas.
Přijde-li si občan na Městský Úřad vyřídit změnu bydliště, nechce běhat po všech zákonně izolovaných odborech Úřadu jenom proto, abych si tuto záležitost všude zákonně izolovaně vyřídil: "registr nájemních obecních bytů", "volební registr", "živnostenský registr", "registr majitelů psů", "registr parkovacích karet",.....
Izolovaných "elektronických sešitů" (= izolovaných pytlů dat bez historie) dnes všeobecně velmi přibývá. Čím více jich je, tím méně pravdivé a aktuální údaje obsahují.
Správce může ověřit zda jsou osobní údaje pravdivé a přesné nejlépe tak, že bude stejné údaje ukládat na jednom místě a tam aktualizovat, ať již je důvod aktualizace jakýkoliv. Tomu ale brání §5 (1) (h) ZOOÚ.
· § 5 (1) f) Správce je povinen zpracovávat osobní údaje pouze v souladu s účelem, k němuž byly shromážděny, pokud zvláštní zákon nestanoví jinak. Zpracovávat k jinému účelu lze osobní údaj, jen pokud k tomu dal subjekt údajů souhlas
Dispozitivní možnost souhlasu subjektu údajů ke zpracování osobních údajů v rámci podnikového integrovaného informačního systému je jediná záchrana legálního rozvoje moderní informatiky. Subjekt údajů podepíše, že chce mít údaje uložené v příslušné podnikové databázi jako integrované údaje, že se v rámci podniku budou jeho osobní údaje poskytnuté k rozdílným účelům sdružovat, že se bude na jejich zpracování používat jazyk SQL a že podnik ručí za to, že se tyto údaje nedostanou mimo podnik.
Ten, kdo toto prohlášení nepodepíše, bude chodit všude s jednotlivými papíry, lhůty vyřízení se prodlouží a ceny za takováto vyřízení budou řádově vyšší. Ceny musí být podstatně vyšší i proto, že kvůli individuálním "papírovým" řízením musí podnik zaměstnávat zcela zbytečně řadu zaměstnanců.
· § 5 (1) g) Správce je povinen shromažďovat osobní údaje pouze otevřeně; je vyloučeno shromažďovat údaje pod záminkou jiného účelu nebo jiné činnosti, pokud zvláštní zákon nestanoví jinak
Dříve než subjekt údajů podepíše, že souhlasí s tím, aby jím poskytnuté údaje byly uloženy v příslušné podnikové integrované relační databázi pro jakékoliv další potřeby klienta a pro zkvalitnění jemu poskytovaných služeb, informuje jej podnik otevřeně o veškerých svých činnostech a vysvětlí mu srozumitelně důvod provozování podnikového integrovaného informačního systému. (PIIS) .
· § 5 (1) h) Správce je povinen nesdružovat osobní údaje, které byly získány k rozdílným účelům, pokud zvláštní zákon nestanoví jinak.
Největší překážka vzniku kvalitních a moderních databázových systémů. Tyto systémy totiž z čistě technického hlediska kvůli dosažení správnosti dat vycházejí právě ze sdružování veškerých dat (včetně osobních údajů) relačními vztahy tak jak bylo popsáno výše. Správnost dat sice požaduje § 5 (1) c), ale toho se nedá dosáhnout, platí-li současně § 5 (1) h)
Principiální návrhy na novelizaci zákona tak, aby vyhovoval provozu moderních informačních systémů
Principem této úvahy je zavést databázi, která by nesdružovala osobní údaje pouze a výhradně pro jeden jediný účel (omezení jediným účelem), ale která by byla omezena na jednu konkrétní osobu (subjekt) pro všechny účely, kterých se týká oprávněná činnost tohoto subjektu (omezení subjektem a více účely). Říkejme této databázi "podnikový integrovaný informační systém - PIIS". Rozsah shromažďovaných údajů by byl různý podle povahy subjektů a jeho aktivit- větší rozsah by měl PIIS obecního úřadu, který shromažďuje (byť v současné době ve více jednotlivých databázích - "elektronických sešitech") poměrně mnoho údajů (evidence obyvatelstva, evidence majitelů psů ...) než obchodní společnosti, která se zabývá pouze čištěním oděvů (evidence výhradně svých zákazníků). navíc je třeba vytvořit zvláštní právní rámec pro tzv. citlivé údaje, tak jak je definuje zákon.
· Zavést pojem "podnikový integrovaný informační systém" provozovaný konkrétním ekonomickým subjektem na jeho odpovědnost a existenci tohoto systému podmínit velmi přísnými podmínkami pro ochranu osobních údajů v něm obsažených před přístupem neoprávněných osob (tj. únikem informací - osobních údajů - z tohoto systému). Pro přístup k tomuto systému přes Internet vyžadovat důsledně certifikaci uživatele u certifikační autority. Na základě certifikátu se uživatel dostane pouze ke svým osobním datům a ne k datům kohokoliv jiného. Na základě certifikátu si uživatel bude moci kdykoliv zjistit, jaké osobní údaje jsou o něm v tomto systému aktuálně evidovány a může vyžadovat jejich opravu či smazání.
· Zrušit zákaz sdružování údajů v "podnikovém integrovaném informačním systému".
· Obecně zakázat replikace osobních údajů mezi jednotlivými "podnikovými integrovanými informačními systémy"
· Taxativně v zákoně vyjmenovat ty konkrétní "podnikové integrované informační systémy", které musí (gestor celostátního systému, optimálně MV ČR) a které smějí replikovat některé osobní údaje do jiných "podnikových integrovaných informačních systémů". Jinými slovy přesně vymezit výjimky z obecného zákazu replikace osobních údajů mezi jednotlivými podnikovými integrovanými systémy, uvedeného v předchozím bodě.
Příklady "podnikových integrovaných informačních systémů" (PIIS): Ministerstva vnitra ČR, Pardubického kraje, Ministerstva práce a sociálních věcí, Všeobecné zdravotní pojišťovny, Obce Louny, ABCD a.s., QWER s.r.o., Josef Vomáčka - INTERNETBOOK,....
1. Aby se dal integrovaný informační systém podniku vystavět, nesmí se zakázat relační propojování údajů, protože právě na něm je celý tento systém založen! To však zakazuje v § 5 (1) h) ZOOÚ. Toto ustanovení je asi největší překážkou pro rozvoj moderních databázových systémů.
2. V integrovaném informačním systému podniku lze ovšem kterémukoliv evidovanému klientovi velmi jednoduše umožnit, aby viděl, co se o něm eviduje za údaje. To je v systému "elektronických sešitů" téměř nemožné.
3. Lze požadovat, aby se po ukončení obchodního případu anonymizovaly veškeré údaje, které s tímto obchodním případem souvisí. Je však nutno definovat v zákoně veškeré typy obchodních případů a lhůty pro jejich anonymizaci. Je si třeba uvědomit, že obchodní případy jsou někdy velmi složité logické konstrukce, někdy až s nekonečným trváním.
4. Je nesmysl jakkoliv zamezovat evidenci identity subjektů napojených na alespoň jeden aktuálně zpracovávaný (živý) obchodní případ. Viz rozkrádání knih ve veřejných knihovnách jako důsledek zjevně špatné nebo přehnané aplikace zákona - zákaz evidence rodných čísel čtenářů.
5. Je žádoucí využívat údaje získané v jednom aktuálním (živém) obchodním případě pro jiný aktuální (živý) obchodní případ pro jejich zkvalitňování a menší obtěžování klientů.
6. Současná situace nahrává korupci: Špatné a zastaralé informační systémy používající "sešity" či "elektronické sešity" zákonu formálně vyhovují. Dobře a moderně navržené informační systémy musí z logiky věci sdružovat údaje (= používat je jednotně v celém systému bez ohledu na agendu - účel), a proto porušují literu současného zákona. Aby se směly kvalitní systémy vůbec používat, je třeba "přimhouřit oko".
[1] ÚSIS, odbor koncepcí: "Věcný záměr zákona o registrech veřejné správy (návrh)", draft, verze 2.00 ze dne 1.11.2000
[2] "Bundesdatenschutzgesetz" (BDSG) ze dne 20.12.1990
Poznámky k německému zákonu (BDSG):
Zweiter Abschnitt: Datenverarbeitung der öffentlichen Stellen, § 12 - §26
Dritter Abschnitt: Datenverarbeitung nicht-öffentlichen Stellen und öffentlich-rechtlicher Wettbewerbsunternehmen, §27 - §38
Zásadní definice výše uvedených kategorií jsou uvedeny v § 2
Zajímavý je §28, který popisuje, co si může evidovat soukromý subjekt bez omezení. Na veřejnoprávní subjekty se ani toto omezení samozřejmě nevztahuje.
V německém zákoně na ochranu osobních údajů se tedy zásadně odlišují subjekty soukromé od veřejnoprávních. Ne jako u nás, kde dělící čára probíhá mezi subjekty, které nesmí evidovat téměř nic (soukromé i veřejnoprávní) a mezi taxativně vyjmenovanou množinou všemožných tajných služeb a institucí, které mohou evidovat úplně všechno, včetně citlivých osobních údajů.
Rubrika: Ochrana osobních údajů a dat Čtenost: 12823 Počet reakcí: 13
12 Feb 2002 11:41 Milan Kvasnica
13 Feb 2002 19:18 Josef Prokeš
NESOUHLAS. Jde o nepochopení zákona?
14 Feb 2002 10:20 Petr Vršek
14 Feb 2002 13:47 Josef Prokeš
Nepochopení podstatných institutů nejen zákona, ale i práva.
14 Feb 2002 15:04 Petr Vršek
schůzka nutná, další korespondence zbytečná
14 Feb 2002 17:01 Josef Prokeš
schůzka s potěšením vítána
14 Feb 2002 16:55 Tomáš Vršek
22 Feb 2002 16:51 Miloš Kafka
22 Feb 2002 19:16 Petr Vršek
25 Feb 2002 08:54 Petr Vršek
Dodatek k rodnému číslu
07 May 2002 18:06 Martin Molhanec
25 Nov 2003 09:21 Sigmundova
02 Sep 2012 10:17 Jana

References: § 4
 § 4
 § 5
 § 5
 § 5
 § 5
 § 5
 §5
 § 5
 § 5
 § 5
 § 5
 § 5
 § 5
 § 12
 §26
 §27
 §38
 § 2
 §28