Rekonstrukce OCL z SQL *

Rozměr: px
Začít zobrazení ze stránky:

Download "Rekonstrukce OCL z SQL *"

Transkript

1 Rekonstrukce OCL z SQL * Karel RICHTA 1 1 Katedra softwarového inženýrství, MFF UK Praha Malostranské nám. 25, Praha karel.richta@mff.cuni.cz Abstrakt. Jednou z často citovaných zkratek poslední doby je MDD (Model Driven Development), příp. MDA (Model Driven Architecture), nebo dokonce MDE (Model Driven Engineering). Princip těchto přístupů spočívá v tom, že se při tvorbě aplikace využívají různé modely. Sdružení OMG propaguje myšlenku, že práce s modelem může přinést mnoho nových možností. Model může být použit pro generování struktury dat a kostry řešení, reverzním inženýrstvím lze získat model existujícího systému pro jeho snazší pochopení, či úpravy. Nad modelem lze provádět různé transformace, refaktorizace apod. Pro modelování se v současnosti nejvíce využívá standard UML (Unified Modeling Language [9]). Aby však byl model dostatečně úplný, je třeba doplnit diagramy v UML přesnými popisy různých integritních omezení. Pro tento účel obsahuje notace UML speciální jazyk nazvaný OCL (Object Constraint Language [7]). Tento příspěvek se zabývá možnostmi rekonstrukce OCL z existujícího SQL, jako příspěvek k reverznímu inženýrství pro modelem řízený vývoj. Klíčová slova: MDD, MDA, UML, OCL, SQL 1 Úvod Základní princip modelem řízeného stylu [8] spočívá v tom, že se při tvorbě aplikace využívá nějaký model nebo modely. Model nám umožňuje lepší pochopení situace, neboť je abstraktnější a uchopitelnější, než modelovaná skutečnost. Zpravidla se nevyužívá model jediný, ale spíše sada různých modelů (doménový, konceptuální, logický, implementační, či fyzický, apod.). V čem může být vytváření modelu přínosem, co může přinést nového? Jak říká klasik model zůstává, lidé odcházejí, proto je existence dostatečně vypovídajícího modelu určitě přínosem pro stabilitu řešení. Zdánlivou výhodou zanedbání modelu je, že vývoj produktu nezahrnuje žádné aktivity, které by nevedly přímo k výsledku, nevytvářejí se žádné vedlejší produkty a artefakty, výsledkem je přímo kód zkonstruovaný podle katalogu požadavků (samozřejmě, pokud nepovažujeme za model samotný katalog požadavků zapsaný v přirozeném jazyce). Vývojář produktu odevzdává tyto artefakty a vzápětí odchází k jiné firmě. V témže okamžiku přichází od zákazníka nový požadavek, nebo požadavek na změnu. Zodpovědné osobě nezbývá, než svěřit řešení změny někomu, kdo zatím neměl s tímto produktem nic společného. Nová osoba se musí seznámit s kódem, vytvořit si jeho model v hlavě a poté jej přizpůsobit novým požadavkům. * Tento text vznikl za částečné podpory výzkumného záměru MŠMT č. MSM , grantových projektů GAČR: GA201/09/0990 a GA201/09/0983. Petr Šaloun (ed.), DATAKON 2010, Mikulov, , pp

2 Co jsme ušetřili na začátku, jsme teď ztratili. Pokud se model vytvořený při realizaci změny opět nezaznamená, bude se situace při další změně opakovat. Zdánlivá úspora na začátku se pak ukazuje jako ztráta. Představme si obrácenou situaci analytik rád modeluje a snaží se vytvořit dokonalý model podle požadavků zákazníka. Neustále jej vylepšuje, aby ho připravil na rozmanité změny, které mohou v budoucnosti nastat. Kód nevzniká, neboť se stále zabývá modelem, který ještě není dokonalý. Obě situace nejsou optimální, správný postup představuje rozumný kompromis - vytvořit jen takový model, který pomůže při analýze, návrhu, implementaci, testování a údržbě produktu, a který navíc zůstane firmě k dispozici pro další změny. Pokud je model udržován současně s produktem, může takto sloužit po celý jeho životní cyklus. Ovšem představa, že by vývojáři, analytici, nebo architekti udržovali modely produktu spolu s jeho vývojem a změnami je ovšem do značné míry iluzorní. Disciplinovaný analytik a vývojář mohou pořizovat dokumentaci modelů alespoň na papíře. Pravděpodobně nikdy však neudrží tuto disciplinu při všech změnách - výsledkem je situace bez aktuálního modelu. Jediným řešením by byl nástroj, který by takovou synchronizaci modelu a kódu dostatečně podporoval. Pokud model vytváříme a udržujeme pomocí nějakého sofistikovaného CASE nástroje, bylo by možné o takové synchronizaci uvažovat (CASE je zkratka pro Computer Aided Software Engineering). CASE nástroj by měl podporovat jak přímé inženýrství, kdy tvoříme model a generujeme z něj kostru kódu, tak i reverzní postup, kdy se snažíme z kódu rekonstruovat kostru modelu. Čím více umí CASE nástroj podporovat oba směry, tím užitečnější je jeho využití v procesu vývoje a údržby. V ideálním případě umožňuje cyklické opakování využití přímého a zpětného inženýrství - používá se zde termín roundtrip okružní jízda [2]. Aktuální problém všech modelovacích technik a nástrojů je míra preciznosti. Na jedné straně by měl být model abstraktní, lehce uchopitelný a srozumitelný. Na straně druhé stojí model, který obsahuje všechny podrobnosti, může být použit pro generování, ale už asi není tak přehledný a uchopitelný. Sdružení OMG řeší tento problém tak [8], že doporučuje vytváření modelů na různých úrovních doménový model (označen CIM Computation Independent Model), konceptuální model (PIM Platform Independent Model), logický model (PSM Platform Specific Model) a nakonec kód - fyzický model (ISM Implementation Specific Model). Na všech úrovních je třeba modely prezentovat pokud možno přesně, ale pouze v rozsahu potřebném pro tuto úroveň náhledu. Samotné diagramy to nikdy neumožňují úplně. Uvažme příklad problému evidence hypoték (viz [10]). Ukázka z katalogu požadavků říká, že: 1. Každá hypotéka bude vždy pro jednu osobu. 2. Osoba si může vzít několik hypoték. 3. Každou nemovitost vlastní právě jedna osoba. 4. Osoba může vlastnit libovolný počet nemovitostí. 5. Každá hypotéka musí být zajištěna nejméně jednou nemovitostí. 6. Nemovitost může být použita k zajištění více hypoték. Uvedené požadavky lze snadno na konceptuální úrovni reprezentovat diagramem tříd uvedeným na Obr. 1. Tento poměrně jednoduchý model může mít zajímavé interpretace, neboť je zde např. přípustné, aby osoba zajistila hypotéku nemovitostí, kterou nevlastní. Model je proto zapotřebí doplnit integritním omezením: Osoby mohou jako zajištění hypotéky použít pouze nemovitosti, které samy vlastní. Integritní omezení lze zapsat v přirozeném jazyce - výhodou takového řešení je, že mu navazující řešitelé rozumí - pokud

3 např. toto zadání předáme nějaké osobě k řešení. Nevýhodou je, pokud toto zadání chceme předat k řešení programu např. CASE nástroji. Ten takovému zápisu zatím nerozumí. Pokud bychom vyjádřili integritní omezení formálně, bylo by možné CASE nástroj tomuto jazyku naučit. Pro notaci UML [9] představuje takový formální nástroj jazyk OCL [7], který stručně popíšeme v následujícím odstavci. class Hypotéky - PIM skládá_se_z 0..* +je_částí 1 Nemovitost - označení: string - hodnota: penize +v lastní 0..* +je_majetkem 1 - jméno: string - příjmení: string - příjem: peníze Osoba +je_zajištěna 1..* + žádost(peníze, Set{Nemovitost}) : boolean +pro 1 +zajišťuje 0..* +má_půjčenu 0..* Hypotéka - od: datum - do: datum - celková_částka: peníze = ,- - měsíční_splátka: peníze Obr. 1: Jednoduchý konceptuální model hypoték (PIM) 2 Jazyk OCL Jazyk OCL [7] pochází původně z metodiky Syntropy (IBM, [10]). Je to čistě funkcionální jazyk - vyhodnocení výrazu je bez vedlejších efektů - neexistuje žádná globální paměť. Stejná funkce se stejnými argumenty dává vždy stejný výsledek. OCL není programovací jazyk - je určen pro vyjádření invariantů - je to specifikační jazyk. Zápisy v OCL je třeba chápat jako specifikaci pro programy, které budou odpovídající integritní omezení zajišťovat. OCL je silně typovaný jazyk, tj. každý výraz v jazyce OCL má definován typ. To umožňuje silnou statickou typovou kontrolu zapsaných omezení při jejich interpretaci. OCL má předdefinovánu sadu typů jsou to jednak primitivní typy: Integer, Boolean, String, Real, UnlimitedInteger, ze kterých lze vytvářet složené typy jako rozmanité kolekce: množina (Set), multi-množina (Bag), obecná kolekce (Collection), posloupnost (Sequence), atd. V jazyce OCL nezapisujeme programy tento pojem OCL nezná, není to programovací jazyk. Ve specifikačním jazyku OCL zapisujeme požadavky na to, aby v jistém kontextu byla splněna nějaká podmínka. Podmínku vyjádříme pomocí formule zapsané jako výraz v OCL. K ní pak připojíme specifikaci kontextu. Zápis v jazyce OCL má vždy jednotný tvar: context <jméno> [inv pre post]: <výraz> Klíčové slovo context zde slouží pro odkaz na kontext pro <výraz> v OCL, např. zápis: context Hypotéka inv : self.celková_částka >

4 označuje, že uvedený výraz se vztahuje ke kontextu třídy Hypotéka, tj. na všechny její instance (na konkrétní instanci se lze ve specifikaci odkazovat klíčovým slovem self). Výraz zde vyjadřuje podmínku, že pro každou instanci třídy Hypotéka, musí mít její vlastnost celková_částka hodnotu větší než V daném kontextu nelze evidovat hypotéky s nižší celkovou částkou. Klíčová slova inv, pre, post zastupují stereotypy <<invariant>> (obecně platné tvrzení), <<precondition>> (předpoklad např. vstupní podmínky operace) a <<postcondition>> (podmínka, která musí platit po provedení příslušné akce). OCL lze použít čistě jako navigační jazyk. Chceme-li označit jakýkoliv element některého diagramu, lze použít výraz v OCL. Např. příjem osoby x:osoba v kontextu modelu hypoték, zapíšeme to jako výraz x.příjem. Tento výraz má hodnotu, která je typu peníze. Chceme-li označit názvy nemovitostí, které osoba x:osoba v kontextu modelu hypoték právě vlastní, zapíšeme to jako výraz x.vlastní. V tomto případě je hodnotou množina nemovitostí výsledek je typu Set{Nemovitost}, neboť osoba může vlastnit více nemovitostí, příp. také žádnou. Nejčastěji se OCL používá pro vyjádření integritních omezení v datovém modelu, zejména v diagramech tříd. Také se používá pro vyjádření typových omezení při definici nových stereotypů. Lze jej ale rovněž použít pro vyjádření předpokládaného efektu operací, pro popis vstupních a výstupních podmínek operací. Jak již bylo řečeno, poskytuje jazyk OCL předefinované primitivní typy, ze kterých lze vytvářet složené typy. Při konstrukci hodnot složených typů lze využívat operátory: collect, select, reject, forall, exists, iterate, include, count, union, intersect, isempty, notempty, isunique a dalších. Volání operátorů se zapisuje ve tvaru inspirovaném jazykem Smalltalk, např. zápis: x.vlastní -> count() označuje počet nemovitostí, které osoba x:osoba vlastní. Podobně: x.vlastní.hodnota -> sum() označuje součet cen nemovitostí, které osoba x:osoba vlastní. Vzhledem k existenci kvantifikátorů (forall, exists), lze usuzovat, že OCL je notace pro zápis formulí predikátového kalkulu 1.řádu v programátorském stylu, smíchaná s množinovou notací. Konkrétní hodnoty kolekcí se konstruují stejně označenými konstruktory, např.: Set {2,4,1,5,7,13,11,17}, OrderedSet {1,2,3,5,7,11,13,17}, Sequence {1,2,3,5,7,11,13,17}, Bag {1,2,3,2,1}. 3 Příklad specifikace v OCL Jako ilustrační příklad použijeme dříve uvedenou jednoduchou evidenci hypoték. Model uvedený na obrázku Obr. 1 ale nevystihuje zdaleka všechny požadované vlastnosti hypoték. Původní požadavky doplnil systémový analytik o další, které by měla data o hypotékách splňovat:

5 7. Hypotéku lze zajistit pouze nemovitostmi, které osoba vlastní. 8. Cena nemovitostí zajišťujících hypotéku musí být větší, než celková zapůjčovaná částka. 9. Celková zapůjčovaná částka všech hypoték zajištěných danou nemovitostí nesmí přesahovat cenu nemovitosti. 10. Součet měsíčních splátek osoby by neměl přesáhnout 30% jejího měsíčního příjmu a zbytek příjmu po odečtení splátek musí splňovat zákonné požadavky nesmí klesnout pod zákonné minimum. 11. Půjčujeme nejméně 250 tis.kč. Tato integritní omezení již nevyjádříme pouze pomocí diagramů - musíme model doplnit o jejich specifikaci. Specifikaci zapíšeme pomocí výrazů v jazyce OCL. context Hypotéka inv IO7: self.je_zajištěna.je_majetkem = self.pro context Hypotéka inv IO8: self. celková_částka <= self.je_zajištěna.hodnota -> sum() context Nemovitost inv IO9: self.zajišťuje.celková_částka -> sum() <= self.cena context Hypotéka inv IO11: (self.celková_částka >= ). Podobným způsobem vyjadřujeme integritní omezení, popisující požadované vlastnosti operací. V našem modelu mohou osoby žádat o hypotéku na určitou částku, zajištěnou nějakou sadou nemovitostí. V modelu je na to určena metoda žádost, přesněji Osoba::žádost. Pro žádosti o hypotéky platí požadavek, který by měl omezit případy, kdy osoba nebude schopna hypotéky splácet, tj. kdy celkový součet měsíčních splátek přesáhne její možnosti: context Osoba::žádost(částka:peníze, zajištění:set{nemovitost}) pre IO10: (self.má_půjčenu.měsíční_splátka -> sum()) + částka <= self.příjem * 0.3 Ještě jedno důležité integritní omezení, které se týká rekurzivních vztahů: 12. Nemovitost se nemůže skládat sama ze sebe (dělíme jen na jedné úrovni). context Nemovitost inv IO12: not(self.skládá_se_z -> iselement(self)) Všechna uvedená integritní omezení zajišťují konzistenci evidovaných dat. Chytrý CASE nástroj může formální definici integritních omezení využít pro generování kódu zajišťující data proti porušení integrity. Např. na relační platformě může generovat relační integritní omezení nebo triggery, které porušení integrity hlídají a nepovolí uložení chybných dat. 4 Jazyk SQL Použijeme-li při vývoji jako platformu relační databázový systém, bude komunikačním jazykem této platformy jazyk SQL. Syntaxe SQL dělí příkazy do 5-ti kategorií: <SQL statement> ::= <QUERY> <DML> <DDL> <TCL> <DCL> Z hlediska našeho problému jsou zajímavé příkazy z kategorie DDL (Data Definition Language), neboť těmi se vytvářejí základní relační objekty tabulky atd. Tabulky a ostatní objekty uložené v databázi byly vytvořeny pomocí těchto příkazů. Ze všech možných druhů objektů se zde budeme zabývat pouze tabulkami, neboť ty jsou nejdůležitější.

6 CREATE TABLE "table_name" ("column 1" "data_type_for_column_1", "column 2" "data_type_for_column_2",... ) Uvažme např. tabulku osob (nazveme ji Osoby, neboť bude obsahovat záznamy typu Osoba o evidovaných osobách): CREATE TABLE Osoby (jméno VARCHAR2(24),... ) Při reverzním inženýrství můžeme všechny takové DDL příkazy rekonstruovat z katalogu databáze, kde musí být všechny informace o všech objektech uloženy. Konkrétní postup je samozřejmě závislý na struktuře katalogu daného poskytovatele. Tabulky v relační databázi jsou pro rekonstrukci OCL zajímavé pouze jako definice struktury. Pro jednoduchost budeme uvažovat pouze tabulky a ty později převedeme do UML/OCL jako třídy. Sloupce tabulek převedeme na vlastnosti tříd - atributy nebo vztahy. Pro rekonstrukci OCL jsou spíše zajímavá integritní omezení definovaná nad těmito tabulkami. SQL připouští pět typů deklarativních integritních omezení: <CONSTRAINT> ::= <NOT NULL> <UNIQUE> <PRIMARY KEY> <FOREIGN KEY> <CHECK> 5 Převod UML/OCL do SQL Převodem specifikace v UML/OCL do SQL se zabývají např. články [10], či [4]. Princip spočívá zhruba v tom, že třídy převedeme na tabulky, atributy na sloupce, vztahy 1:N realizujeme pomocí primárních a cizích klíčů. Vztahy M:N realizujeme pomocí vztahové tabulky a primárních a cizích klíčů. Příklad relačního logického modelu vytvořeného z konceptuálního modelu hypoték (viz Obr. 1) je zobrazen na obrázku Obr. 2. Byl pořízen automatickým převodem podle standardních pravidel pro transformaci PIM na PSM. Integritní omezení jsou na konceptuální úrovni reprezentována v OCL. Řadu z nich lze převést do SQL poměrně přímočaře. Zápis v OCL: context T inv IOT: <výraz> nahradíme v SQL příkazem: ALTER TABLE T ADD CONSTRAINT IOT CHECK (<výraz>) Uvažme např. integritní omezení č.11: context Hypotéka inv IO11: (self.celková_částka >= ) To nahradíme v SQL příkazem: ALTER TABLE Hypoteky ADD CONSTRAINT IO11 CHECK (celkova_castka >= ) Pokud výraz obsahuje operace pro práci s kolekcemi, bude převod o něco komplikovanější. Uvažme např. integritní omezení č.12: Nemovitost je majetkem právě jedné osoby, nebo se skládá z částí, které vlastní nějaká osoba (nemovitosti dělíme jen na jedné úrovni). context x:nemovitost inv IO14: (x.skládá_se_z -> isempty() and x.je_majetkem -> size() = 1) or (not (x.skládá_se_z -> isempty()) and (x.je_majetkem -> size() = 0)) and (x.skládá_se_z -> exists( y:osoba y.vlastní -> iselement(x))))

7 class DDL Nemovitost «column» *PK nemovitostid: NUMBER(8) označení: VARCHAR2(50) hodnota: NUMBER(9,2) FK je_majetkem: NUMBER(8) FK je_částí: NUMBER(8) «PK» + PK_Nemovitost(NUMBER) + FK_je_majetkem(NUMBER) 1 + FK_je_částí(NUMBER) +PK_Nemovitost (nemovitostid = nemovitostid) +FK_Nemovitost 0..* JoinHypotékaToNemovitost «column» *FK nemovitostid: NUMBER(8) * hypotékaid: NUMBER(8) 0..* +FK_je_majetkem 0..* +PK_Nemovitost +skládá_se_z (je_majetkem = osobaid) (je_částí = nemovitostid) +FK_Hypoteka +PK_Hypoteka (hypotékaid = hypotékaid) 1..* +PK_Osoba 1 Osoba «column» *PK osobaid: NUMBER(8) jméno: VARCHAR2(24) příjmení: VARCHAR2(35) příjem: NUMBER(8,2) «PK» + PK_Osoba(NUMBER) +PK_Osoba 1 +FK_pro (pro = osobaid) Hypotéka 0..* «column» *PK hypotékaid: NUMBER(8) od: DATE do: DATE celková_částka: NUMBER(9,2) = ,- měsíční_splátka: NUMBER(8,2) *FK pro: NUMBER(8) + FK_Nemovitost(NUMBER) + FK_Hypotéka() «PK» + PK_Hypotéka(NUMBER) + FK_pro(NUMBER) Obr. 2: Logický relační model hypoték (PSM) Můžeme opět vyzkoušet transformaci na klausuli CHECK, kde případně použijeme určitý trik např. při nahrazování univerzálního kvantifikátoru jej nahradíme pomocí dvojí negace a poté vyjádříme pomocí operátoru exists, který v SQL existuje. ALTER TABLE Nemovitosti ADD CONSTRAINT IO12 CHECK (IS NULL sklada_se_z AND ((SELECT count(*) FROM Osoby WHERE osobaid = je_majetkem) = 1) OR (IS NOT NULL sklada_se_z AND ((SELECT count(*) FROM Osoby WHERE osobaid = je_majetkem) = 0) AND (EXISTS (SELECT 'X' FROM Osoby WHERE nemovitostid in vlastni))) Ve skutečnosti bude převod o něco komplikovanější, neboť žádný poskytovatel systému řízení relační báze dat neumí implementovat klausuli CHECK, ve které se vyskytuje dotaz nad stejnou tabulkou. 6 Převod SQL do UML/OCL Poté, co jsme zkonstruovali PSM, můžeme se pokusit v rámci okružní jízdy o zpětný převod na PIM. Předmětem naší zpětné transformace je logický, relační databázový model (schema), který převádíme do UML/OCL. Výstupem by měl být konceptuální model vstupního schématu. Sloupec v tabulce T, nad kterým je definováno integritní omezení NOT

8 NULL budeme transformovat na povinný atribut v diagramu tříd UML, tj. atribut s četností [1..1], zkráceně [1] (nepovinný bude mít četnost [0..1]): SQL UML <sloupec> <typ> NOT NULL <sloupec> : <typ> [1] Sloupec v tabulce T, nad kterým je definováno integritní omezení UNIQUE budeme v OCL specifikovat pomocí zabudované metody isunique, kterou se v OCL vyjadřuje právě podmínka unikátnosti: SQL create table T ( <sloupec> <typ> UNIQUE ) OCL context T inv : self.<sloupec> -> isunique() Sloupec, nebo sloupce v tabulce T, nad kterými je definováno integritní omezení PRIMARY KEY budeme v OCL specifikovat jako kombinaci předešlých dvou vlastností: SQL create table T ( <sloupec> <typ> PRIMARY KEY ) OCL context T inv : self.<sloupec> -> isunique() and isdefined() Pro sloupec, nebo sloupce v tabulce T, nad kterými je definováno integritní omezení FOREIGN KEY se jménem <FK>, zavedeme v diagramu tříd vztah mezi tabulkou T a referencovaným objektem, který se bude jmenovat <FK>. Navíc budeme v OCL specifikovat omezení: SQL create table T ( <sloupec> <typ> CONSTRAINT <FK> REFERENCES <nazev>(<tabulka>) ) OCL context T inv : self.<sloupec> -> exists( x:<tabulka> x.<nazev> = self. <FK> ) Sloupec, nebo sloupce v tabulce T, nad kterými je definováno integritní omezení typu CHECK budeme v OCL specifikovat: SQL create table T ( <sloupec> <typ> CHECK(<výraz>) ) OCL context T inv : self.<sloupec> -> forall( x:t <výraz> ) Pokud aplikujeme tato pravidla na logický model PSM našich hypoték, získáme následující model zapsaný lineárně v jazyce USE [10]: model Hypotéky -- classes class Osoba attributes jméno : VARCHAR2(24)... end class Hypotéka attributes... end class Nemovitost attributes... end class JoinHypotékaToNemovitost attributes... end

9 -- associations association FK_pro between Osoba[1] Hypotéka[0..*] end association FK_je_majetkem between Nemovitost[0..*] Osoba[1] end association FK_Hypotéka between JoinHypotékaToNemovitost[1..*] Hypotéka[1] end association FK_Nemovitost between JoinHypotékaToNemovitost[0..*] Nemovitost[1] end -- OCL constraints constraints... context Hypotéka -- hypotéka musí být zajištěna vlastním majetkem inv IO7: self.je_zajištěna.je_majetkem = self.pro... context Hypotéka -- nejmenší částka je ,- inv IO11: self.celková_částka >= Z uvedených příkladů je zřejmé, že pro okružní jízdu je třeba si některé informace uchovávat spolu s modely. Např. je to mapování mezi identifikátory na úrovni PIM a identifikátory v relačním modelu na úrovni PSM. Jiný příklad jsou vztahy M:N, které jsme při převodu do PSM nahradili vztahovými tabulkami. Takových informací je celá řada a pokud ji neuchováme, bude problém okružní jízdu realizovat. Jak to zařídit bude předmětem dalšího výzkumu. 7 Závěr V článku je rozebírána tzv. okružní jízda (round-trip) pro případ relační platformy a datového modelu. Uvedené příklady formálních specifikací integritních omezení zapsaných v jazyce OCL a SQL představují ukázku kontextu, ve kterém se bude muset CASE nástroj podporující okružní jízdu pohybovat. Naznačili jsme postup převodu konceptuálního datového modelu (PIM) v notaci UML/OCL do SQL a zpětný převod logického modelu (PSM) z SQL do OCL. Je to samozřejmě jen malý krůček do modelem řízeného vývoje. Existuje několik škol, kde se specifikacemi v OCL intenzivně zabývají, viz. např. [5], či [6]. OCL není samozřejmě jediným způsobem formální specifikace integritních omezení. V současné době se ale zdá být nejperspektivnější. Uveďme si příklad využití formálních specifikací v praxi. V roce 1998 byla uvedena do provozu linka 14 pařížského metra, pro kterou byl požadavek, aby mohla být plně řízena

10 nejen lidskou obsluhou, ale také pouze softwarem. Protože se jednalo o citlivou věc, byl vývoj a testování tohoto softwaru prováděn za pomoci formálních specifikací. Požadavky byly zformulovány ve specifikačním jazyce B - jednalo se o asi 100 tis. řádků specifikace. Za pomoci různých nástrojů byla tato specifikace testována, bylo provedeno asi 27 tis. důkazů různých vlastností popsaného produktu. Posléze tato specifikace posloužila pro vygenerování kostry kódu v jazyce Ada, který po úpravách představoval asi 87 tis. řádků kódu, tj. méně než byla specifikace. Byť se tento příklad netýká přímo OCL, je z něj vidět, že používání formálních specifikací má v některých případech uplatnění. Vývoj formálních specifikací a nástrojů, které s nimi pracují, probíhá neustále. Např. poslední verze OCL je z února tohoto roku, nejedná se tedy o mrtvý standard. Spíše se hledají cesty, jak formální specifikace v OCL využít v CASE nástrojích. Např. známý Enterprise Architect již dovoluje vkládání omezení v OCL do modelů, umí dokonce kontrolovat správnost syntaxe, ale zatím neumí z těchto formálních zápisů generovat nějaký kód. Před několika lety ale neuměl ani syntaxi OCL. Uvidíme, co se změní za pár let. Literatura [1] Arlow, J., and Neustadt, I.: UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design (2nd Edition), Addison-Wesley Professional Press, [2] Beličák, M. Pokorný, J. Richta, K.: Open Design Architecture for Round Trip Engineering. In: Proceedings of ISD 2009, Nanchang, Springer-Verlag (v tisku). [3] Botting, R.: Simplex of OCL. URL: [4] Cook, S. - Daniels,J.: Designing Object Systems: Object-Oriented Modelling with Syntropy. Prentice Hall, 1994, ISBN URL: [5] Dresden OCL Toolkit. URL: [6] Octopus OCL Toolkit. URL: [7] OMG: Object Constraint Language, Version 2.2. February URL: [8] OMG: MDA Guide, URL: [9] OMG: UML 2.2, February URL: [10] Richta, K: Jazyk OCL a modelem řízený vývoj. In: Moderní database 2010, Nesuchyně, Komix Praha [11] Richters, M. Gogolla, M.: OCL: Syntax, Semantics, and Tools. In: Object Modeling with the OCL, LNCS 2263, Springer Berlin/Heidelberg, ISBN , pp , 2002 [12] Wikipedia: Annotation: Reconstruction of OCL from SQL This paper discusses the possibilities of reconstruction of UML classes and OCL constraints from an existing SQL, as a contribution to the reverse engineering process in the model-driven development.

Jazyk OCL a modelem řízený vývoj 1

Jazyk OCL a modelem řízený vývoj 1 Jazyk OCL a modelem řízený vývoj 1 Karel Richta Katedra softwarového inženýrství, MFF UK Malostranské nám.25, 118 00, Praha 1 Tel: 221917316 e-mail: richta@ksi.mff.cuni.cz www: http://www.ksi.mff.cuni.cz/~richta/

Více

OCL a integritní omezení

OCL a integritní omezení OCL a integritní omezení Karel Richta Katedra softwarového inženýrství Fakulta informačních technologií České vysoké učení technické v Praze richta@fel.cvut.cz, 2011 Softwarové inženýrství I., BI-SI1 04/2011,

Více

Databázové systémy. - SQL * definice dat * aktualizace * pohledy. Tomáš Skopal

Databázové systémy. - SQL * definice dat * aktualizace * pohledy. Tomáš Skopal Databázové systémy - SQL * definice dat * aktualizace * pohledy Tomáš Skopal Osnova přednášky definice dat definice (schémat) tabulek a integritních omezení CREATE TABLE změna definice schématu ALTER TABLE

Více

2. blok část B Základní syntaxe příkazů SELECT, INSERT, UPDATE, DELETE

2. blok část B Základní syntaxe příkazů SELECT, INSERT, UPDATE, DELETE 2. blok část B Základní syntaxe příkazů SELECT, INSERT, UPDATE, DELETE Studijní cíl Tento blok je věnován základní syntaxi příkazu SELECT, pojmům projekce a restrikce. Stručně zde budou představeny příkazy

Více

UML. Unified Modeling Language. Součásti UML

UML. Unified Modeling Language. Součásti UML UML Unified Modeling Language 1995 počátek 1997 verze 1.0 leden dnes verze 2.0 (vývoj stále nedokončen) Standardní notace OMG podpora velkých firem (Microsoft, IBM, Oracle, HP ) popisuje struktury popisuje

Více

Primární klíč (Primary Key - PK) Je právě jedna množina atributů patřící jednomu z kandidátů primárního klíče.

Primární klíč (Primary Key - PK) Je právě jedna množina atributů patřící jednomu z kandidátů primárního klíče. Primární a cizí klíč Kandidát primárního klíče (KPK) Je taková množina atributů, která splňuje podmínky: Unikátnosti Minimálnosti (neredukovatelnosti) Primární klíč (Primary Key - PK) Je právě jedna množina

Více

Databázové systémy Cvičení 5.2

Databázové systémy Cvičení 5.2 Databázové systémy Cvičení 5.2 SQL jako jazyk pro definici dat Detaily zápisu integritních omezení tabulek Integritní omezení tabulek kromě integritních omezení sloupců lze zadat integritní omezení jako

Více

Jiří Mašek BIVŠ V Pra r ha 20 2 08

Jiří Mašek BIVŠ V Pra r ha 20 2 08 Jiří Mašek BIVŠ Praha 2008 Procesvývoje IS Unifiedprocess(UP) Iterace vývoje Rysy CASE nástrojů Podpora metodických přístupů modelování Integrační mechanismy propojení modelů Podpora etap vývoje Generování

Více

Úvod do databázových systémů

Úvod do databázových systémů Vysoká škola báňská Technická univerzita Ostrava Fakulta elektrotechniky a informatiky Úvod do databázových systémů Cvičení 8 Ing. Petr Lukáš petr.lukas@vsb.cz Ostrava, 2014 Opakování Entita Entitní typ

Více

Úvod do databázových systémů

Úvod do databázových systémů Vysoká škola báňská Technická univerzita Ostrava Fakulta elektrotechniky a informatiky Úvod do databázových systémů Cvičení 3 Ing. Petr Lukáš petr.lukas@vsb.cz Ostrava, 2014 Opakování 4 fáze vytváření

Více

Kurz Databáze. Obsah. Dotazy. Zpracování dat. Doc. Ing. Radim Farana, CSc.

Kurz Databáze. Obsah. Dotazy. Zpracování dat. Doc. Ing. Radim Farana, CSc. 1 Kurz Databáze Zpracování dat Doc. Ing. Radim Farana, CSc. Obsah Druhy dotazů, tvorba dotazu, prostředí QBE (Query by Example). Realizace základních relačních operací selekce, projekce a spojení. Agregace

Více

7. Integrita a bezpečnost dat v DBS

7. Integrita a bezpečnost dat v DBS 7. Integrita a bezpečnost dat v DBS 7.1. Implementace integritních omezení... 2 7.1.1. Databázové triggery... 5 7.2. Zajištění bezpečnosti dat... 12 7.2.1. Bezpečnostní mechanismy poskytované SŘBD... 13

Více

7. Integrita a bezpečnost dat v DBS

7. Integrita a bezpečnost dat v DBS 7. Integrita a bezpečnost dat v DBS 7.1. Implementace integritních omezení... 2 7.1.1. Databázové triggery... 5 7.2. Zajištění bezpečnosti dat... 12 7.2.1. Bezpečnostní mechanismy poskytované SŘBD... 13

Více

Databáze I. Přednáška 4

Databáze I. Přednáška 4 Databáze I Přednáška 4 Definice dat v SQL Definice tabulek CREATE TABLE jméno_tab (jm_atributu typ [integr. omez.], jm_atributu typ [integr. omez.], ); integritní omezení lze dodefinovat později Definice

Více

Unifikovaný modelovací jazyk UML

Unifikovaný modelovací jazyk UML Unifikovaný modelovací jazyk UML Karel Richta katedra počíta tačů FEL ČVUT Praha richta@fel fel.cvut.czcz Motto: Komunikačním m prostředkem informační komunity se postupem času stala angličtina. Chcete-li

Více

DBS Transformace konceptuálního schématu na

DBS Transformace konceptuálního schématu na DBS Transformace konceptuálního schématu na relační Michal Valenta Katedra softwarového inženýrství FIT České vysoké učení technické v Praze c Michal Valenta, 2012 BI-DBS, ZS 2012/13 https://edux.fit.cvut.cz/courses/bi-dbs/

Více

Informační systémy 2008/2009. Radim Farana. Obsah. Jazyk SQL

Informační systémy 2008/2009. Radim Farana. Obsah. Jazyk SQL 4 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Jazyk SQL, datové typy, klauzule SELECT, WHERE, a ORDER BY. Doporučená

Více

Modelem řízený vývoj. SWI 1 Jan Kryštof

Modelem řízený vývoj. SWI 1 Jan Kryštof Modelem řízený vývoj SWI 1 Jan Kryštof Související zkratky MDA ~ Architecture formální vymezení MDD ~ Development aktivita SW vývojářů MDG, MDE,... UML ~ Unified modeling language OMG ~ Object Management

Více

Úvod do databázových systémů

Úvod do databázových systémů Vysoká škola báňská Technická univerzita Ostrava Fakulta elektrotechniky a informatiky Katedra informatiky Database Research Group Úvod do databázových systémů Cvičení 3 Ing. Petr Lukáš petr.lukas@vsb.cz

Více

UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W

UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Co je to UML Evoluce UML Diagram komponent Diagram odbavení Diagram tříd Aktivity diagram Stavový diagram Sekvenční diagram Diagram

Více

DUM 12 téma: Příkazy pro tvorbu databáze

DUM 12 téma: Příkazy pro tvorbu databáze DUM 12 téma: Příkazy pro tvorbu databáze ze sady: 3 tematický okruh sady: III. Databáze ze šablony: 7 Kancelářský software určeno pro: 4. ročník vzdělávací obor: 18-20-M/01 Informační technologie vzdělávací

Více

Obsah přednášky. Databázové systémy RDBMS. Fáze návrhu RDBMS. Coddových 12 pravidel. Coddových 12 pravidel

Obsah přednášky. Databázové systémy RDBMS. Fáze návrhu RDBMS. Coddových 12 pravidel. Coddových 12 pravidel Obsah přednášky Databázové systémy Konceptuální model databáze Codd a návrh relační databáze fáze návrhu pojem konceptuální model základní pojmy entity, relace, atributy, IO kardinalita, 2 historie: RDBMS

Více

Relace x vztah (relationship)

Relace x vztah (relationship) Relace x vztah (relationship) Peter Chen, Peter Pin-Shan (March 1976): "The Entity-Relationship Model Toward a Unified View of Data". ACM Transactions on Database Systems 1. E-R diagram v Chennově notaci

Více

A5M33IZS Informační a znalostní systémy. Relační databázová technologie

A5M33IZS Informační a znalostní systémy. Relační databázová technologie A5M33IZS Informační a znalostní systémy Relační databázová technologie Přechod z konceptuálního na logický model Entitní typ tabulka Atribut entitního typu sloupec tabulky Vztah: vazba 1:1 a 1:N: Vztah

Více

Transformace konceptuálního modelu na relační

Transformace konceptuálního modelu na relační Transformace konceptuálního modelu na relační Michal Valenta Katedra softwarového inženýrství Fakulta informačních technologií České vysoké učení technické v Praze c Michal Valenta, 2016 BI-DBS, LS 2015/16

Více

TÉMATICKÝ OKRUH Softwarové inženýrství

TÉMATICKÝ OKRUH Softwarové inženýrství TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 24. Otázka : Implementační fáze. Postupy při specifikaci organizace softwarových komponent pomocí UML. Mapování modelů na struktury programovacího

Více

Obsah. Zpracoval:

Obsah. Zpracoval: Zpracoval: houzvjir@fel.cvut.cz 03. Modelem řízený vývoj. Doménový (business), konceptuální (analytický) a logický (návrhový) model. Vize projektu. (A7B36SIN) Obsah Modelem řízený vývoj... 2 Cíl MDD, proč

Více

Principy UML. Clear View Training 2005 v2.2 1

Principy UML. Clear View Training 2005 v2.2 1 Principy UML Clear View Training 2005 v2.2 1 1.2 Co je touml? Unified Modelling Language (UML) je univerzálníjazyk pro vizuální modelování systémů Podporuje všechny životní cykly Mohou jej implementovat

Více

Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115

Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115 Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115 Číslo projektu: Číslo šablony: Název materiálu: Ročník: Identifikace materiálu: Jméno autora: Předmět: Tématický celek: Anotace: CZ.1.07/1.5.00/34.0410

Více

Tvorba informačních systémů

Tvorba informačních systémů Tvorba informačních systémů Michal Krátký 1 1 Katedra informatiky VŠB Technická univerzita Ostrava Tvorba informačních systémů, 2005/2006 c 2006 Michal Krátký Tvorba informačních systémů 1/35 Konceptuální

Více

Databázové systémy úvod

Databázové systémy úvod Databázové systémy úvod Michal Valenta Katedra softwarového inženýrství Fakulta informačních technologií České vysoké učení technické v Praze c Michal Valenta, 2016 BI-DBS, LS 2015/16 https://edux.fit.cvut.cz/courses/bi-dbs/

Více

Obchodní akademie a Jazyková škola s právem státní jazykové zkoušky Jihlava

Obchodní akademie a Jazyková škola s právem státní jazykové zkoušky Jihlava Obchodní akademie a Jazyková škola s právem státní jazykové zkoušky Jihlava Šablona 32 VY_32_INOVACE_038.ICT.34 Tvorba webových stránek SQL stručné minimum OA a JŠ Jihlava, VY_32_INOVACE_038.ICT.34 Číslo

Více

Databázové modelování. Analýza Návrh konceptuálního schématu

Databázové modelování. Analýza Návrh konceptuálního schématu Databázové modelování Analýza Návrh konceptuálního schématu 1 Vytváření IS Analýza Návrh Implementace Testování Předání SW Jednotlivé fáze mezi sebou iterují 2 Proč modelovat/analyzovat? Standardizované

Více

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů.

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů. Modely datové Existují různé úrovně pohledu na data. Nejvyšší úroveň je úroveň, která zachycuje pouze vztahy a struktury dat samotných. Konceptuální model - E-R model. Další úrovní je logická úroveň Databázové

Více

Databázové systémy trocha teorie

Databázové systémy trocha teorie Databázové systémy trocha teorie Základní pojmy Historie vývoje zpracování dat: 50. Léta vše v programu nevýhody poměrně jasné Aplikace1 alg.1 Aplikace2 alg.2 typy1 data1 typy2 data2 vytvoření systémů

Více

Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115

Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115 Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115 Číslo projektu: Číslo šablony: Název materiálu: Ročník: Identifikace materiálu: Jméno autora: Předmět: Tématický celek: Anotace: CZ.1.07/1.5.00/34.0410

Více

Vzorové příklady SQL. Tabulka: Kniha CREATE TABLE kniha (id INTEGER, název VARCHAR(50), PRIMARY KEY (id))

Vzorové příklady SQL. Tabulka: Kniha CREATE TABLE kniha (id INTEGER, název VARCHAR(50), PRIMARY KEY (id)) Vzorové příklady SQL Tabulka: Kniha CREATE TABLE kniha název VARCHAR(50, PRIMARY KEY (id Tabulka: Autoři CREATE TABLE autoři jméno VARCHAR(10, příjmení VARCHAR(20, titul VARCHAR(7, prostřední VARCHAR(10,

Více

Konceptuální modelování a SQL

Konceptuální modelování a SQL Konceptuální modelování a SQL přednáška č.? 1/90 Vytváření IS Analýza Návrh Implementace Testování Předání SW Jednotlivé fáze mezi sebou iterují 2/90 Proč modelovat/analyzovat? Standardizované pracovní

Více

Modelování webových služeb v UML

Modelování webových služeb v UML Modelování webových služeb v UML Jaromír Šveřepa LBMS, s.r.o. Abstrakt: Tento příspěvek se zaměřuje na praktický postup pro identifikaci potřeby webové služby, modelování způsobu jejího použití, popřípadě

Více

RELAČNÍ DATABÁZOVÉ SYSTÉMY

RELAČNÍ DATABÁZOVÉ SYSTÉMY RELAČNÍ DATABÁZOVÉ SYSTÉMY VÝPIS KONTROLNÍCH OTÁZEK S ODPOVĚDMI: Základní pojmy databázové technologie: 1. Uveďte základní aspekty pro vymezení jednotlivých přístupů ke zpracování hromadných dat: Pro vymezení

Více

2. Modelovací jazyk UML 2.1 Struktura UML 2.1.1 Diagram tříd 2.1.1.1 Asociace 2.1.2 OCL. 3. Smalltalk 3.1 Jazyk 3.1.1 Pojmenování

2. Modelovací jazyk UML 2.1 Struktura UML 2.1.1 Diagram tříd 2.1.1.1 Asociace 2.1.2 OCL. 3. Smalltalk 3.1 Jazyk 3.1.1 Pojmenování 1. Teoretické základy modelování na počítačích 1.1 Lambda-kalkul 1.1.1 Formální zápis, beta-redukce, alfa-konverze 1.1.2 Lambda-výraz jako data 1.1.3 Příklad alfa-konverze 1.1.4 Eta-redukce 1.2 Základy

Více

OBJECT DEFINITION LANGUAGE. Jonáš Klimeš NDBI001 Dotazovací Jazyky I 2013

OBJECT DEFINITION LANGUAGE. Jonáš Klimeš NDBI001 Dotazovací Jazyky I 2013 OBJECT DEFINITION LANGUAGE Jonáš Klimeš NDBI001 Dotazovací Jazyky I 2013 ODL a OQL ODL Objektové Object Definition Language popis objektového schéma SQL DDL Relační Data Definition Language příkazy CREATE,

Více

Kapitola 6: Omezení integrity. Omezení domény

Kapitola 6: Omezení integrity. Omezení domény - 6.1 - Omezení domény Referenční integrita Aserce Spouštěče (Triggers) Funkční závislosti Kapitola 6: Omezení integrity Omezení domény Omezení integrity zabraňují poškození databáze; zajišťují, že autorizované

Více

Databáze I. Přednáška 7

Databáze I. Přednáška 7 Databáze I Přednáška 7 Objektové rozšíření SQL Objektově relační databáze SQL:1999 objektové rozšíření SQL vztahuje se k objektově relačním databázovým systémům ukládají objekty do relační databáze umožňují

Více

Informační systémy 2008/2009. Radim Farana. Obsah. Dotazy přes více tabulek

Informační systémy 2008/2009. Radim Farana. Obsah. Dotazy přes více tabulek 5 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Jazyk SQL, Spojení tabulek, agregační dotazy, jednoduché a složené

Více

Databázové systémy. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz

Databázové systémy. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz Databázové systémy Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz Vývoj databázových systémů Ukládání dat Aktualizace dat Vyhledávání dat Třídění dat Výpočty a agregace 60.-70. léta Program Komunikace Výpočty

Více

Transformace ER SQL. Ing. Michal Valenta PhD. Databázové systémy BI-DBS ZS 2010/11, P edn. 9

Transformace ER SQL. Ing. Michal Valenta PhD. Databázové systémy BI-DBS ZS 2010/11, P edn. 9 Transformace ER SQL Ing. Michal Valenta PhD. Katedra softwarového inºenýrství Fakulta informa ních technologií ƒeské vysoké u ení technické v Praze c Michal Valenta, 2010 Databázové systémy BI-DBS ZS 2010/11,

Více

DBS Konceptuální modelování

DBS Konceptuální modelování DBS Konceptuální modelování Michal Valenta Katedra softwarového inženýrství FIT České vysoké učení technické v Praze Michal.Valenta@fit.cvut.cz c Michal Valenta, 2010 BIVŠ DBS I, ZS 2010/11 https://users.fit.cvut.cz/

Více

7.3 Diagramy tříd - základy

7.3 Diagramy tříd - základy 7.3 Diagramy tříd - základy - popisuje typy objektů a statické vztahy mezi nimi Objednávka -datumpřijetí -předplacena -číslo -cena +vyřiď() +uzavři() {if Objednávka.zákazník.charakteristika = 'nejistý'

Více

Databázové systémy. Cvičení 6: SQL

Databázové systémy. Cvičení 6: SQL Databázové systémy Cvičení 6: SQL Co je SQL? SQL = Structured Query Language SQL je standardním (ANSI, ISO) textovým počítačovým jazykem SQL umožňuje jednoduchým způsobem přistupovat k datům v databázi

Více

8.2 Používání a tvorba databází

8.2 Používání a tvorba databází 8.2 Používání a tvorba databází Slide 1 8.2.1 Základní pojmy z oblasti relačních databází Slide 2 Databáze ~ Evidence lidí peněz věcí... výběry, výpisy, početní úkony Slide 3 Pojmy tabulka, pole, záznam

Více

Jaký je rozdíl v definicicíh VARCHAR2(20 BYTE) a VARCHAR2(20 CHAR):

Jaký je rozdíl v definicicíh VARCHAR2(20 BYTE) a VARCHAR2(20 CHAR): Mezi příkazy pro manipulaci s daty (DML) patří : 1. SELECT 2. ALTER 3. DELETE 4. REVOKE Jaké vlastnosti má identifikující relace: 1. Je relace, která se využívá pouze v případě modelovaní odvozených entit

Více

6. SQL složitější dotazy, QBE

6. SQL složitější dotazy, QBE 6. SQL složitější dotazy, QBE Příklady : Veškeré příklady budou dotazy nad databází KONTAKTY nebo KNIHOVNA nebo FIRMA Databáze KONTAKTY OSOBA (Id_osoba, Příjmení, Jméno, Narození, Město, Ulice, PSČ) EMAIL

Více

Kritéria hodnocení praktické maturitní zkoušky z databázových systémů

Kritéria hodnocení praktické maturitní zkoušky z databázových systémů Kritéria hodnocení praktické maturitní zkoušky z databázových systémů Otázka č. 1 Datový model 1. Správně navržený ERD model dle zadání max. 40 bodů teoretické znalosti konceptuálního modelování správné

Více

CASE nástroje. Jaroslav Žáček

CASE nástroje. Jaroslav Žáček CASE nástroje Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Co znamená CASE? A CASE tool is a computer-based product aimed at supporting one or more software engineering activities within

Více

Databázové systémy úvod

Databázové systémy úvod Databázové systémy úvod Michal Valenta Katedra softwarového inženýrství FIT České vysoké učení technické v Praze c Michal Valenta, 2012 BI-DBS, ZS 2012/13 https://edux.fit.cvut.cz/courses/bi-dbs/ Michal

Více

CASE. Jaroslav Žáček

CASE. Jaroslav Žáček CASE Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Co znamená CASE? Definice dle SEI A CASE tool is a computer-based product aimed at supporting one or more software engineering activities

Více

Úvod do databází. Modelování v řízení. Ing. Petr Kalčev

Úvod do databází. Modelování v řízení. Ing. Petr Kalčev Úvod do databází Modelování v řízení Ing. Petr Kalčev Co je databáze? Množina záznamů a souborů, které jsou organizovány za určitým účelem. Jaké má mít přínosy? Rychlost Spolehlivost Přesnost Bezpečnost

Více

Databázové systémy úvod

Databázové systémy úvod Databázové systémy úvod Michal Valenta Katedra softwarového inženýrství FIT České vysoké učení technické v Praze c Michal Valenta, 2011 BI-DBS, ZS 2011/12 https://edux.fit.cvut.cz/courses/bi-dbs/ Michal

Více

Databáze 2011/2012 SQL DDL (CREATE/ALTER/DROP TABLE), DML (INSERT/UPDATE/DELETE) RNDr.David Hoksza, Ph.D. http://siret.cz/hoksza

Databáze 2011/2012 SQL DDL (CREATE/ALTER/DROP TABLE), DML (INSERT/UPDATE/DELETE) RNDr.David Hoksza, Ph.D. http://siret.cz/hoksza Databáze 2011/2012 SQL DDL (CREATE/ALTER/DROP TABLE), DML (INSERT/UPDATE/DELETE) RNDr.David Hksza, Ph.D. http://siret.cz/hksza Osnva Seznámení s SQL Server Management Studiem (SSMS) Základní architektura

Více

Relační databázová technologie

Relační databázová technologie Relační databázová technologie Klíč: množina (možná jednoprvková) atributů (sloupců), jež jednoznačně idetifikuje danou entitu. Poznámky: 1. Daný entitní typ (tabulka) může mít více klíčů. Například (i)

Více

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz UML a jeho použití v procesu vývoje Jaroslav Žáček jaroslav.zacek@osu.cz Různé pohledy na modelování Různé pohledy na modelování Unified Modeling Language UML není metodikou ani programovacím jazykem,

Více

X36SIN: Softwarové inženýrství. Životní cyklus a plánování

X36SIN: Softwarové inženýrství. Životní cyklus a plánování X36SIN: Softwarové inženýrství Životní cyklus a plánování 1 Kontext Minule jsme si řekli, co to je deklarace záměru, odborný článek, katalog požadavků, seznam aktérů a seznam událostí. Seznam aktérů a

Více

Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115

Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115 Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115 Číslo projektu: Číslo šablony: Název materiálu: Ročník: Identifikace materiálu: Jméno autora: Předmět: Tématický celek: Anotace: CZ.1.07/1.5.00/34.0410

Více

Diagram nebo text? Miroslav Benešovský, BenSoft s.r.o

Diagram nebo text? Miroslav Benešovský, BenSoft s.r.o Diagram nebo text? Miroslav Benešovský, Diagram nebo text? Jaká je role analytika při vývoji SW? Most mezi zákazníkem a vývojáři Jaké má analytik prostředky? Diagramy, vizuální modelování Jaká je zkušenost

Více

Jazyk SQL 1. Michal Valenta. Katedra softwarového inženýrství FIT České vysoké učení technické v Praze c Michal Valenta, 2012 BI-DBS, ZS 2011/12

Jazyk SQL 1. Michal Valenta. Katedra softwarového inženýrství FIT České vysoké učení technické v Praze c Michal Valenta, 2012 BI-DBS, ZS 2011/12 Jazyk SQL 1 Michal Valenta Katedra softwarového inženýrství FIT České vysoké učení technické v Praze c Michal Valenta, 2012 BI-DBS, ZS 2011/12 https://edux.fit.cvut.cz/courses/bi-dbs/ Michal Valenta (FIT

Více

Databáze SQL SELECT. David Hoksza http://siret.cz/hoksza

Databáze SQL SELECT. David Hoksza http://siret.cz/hoksza Databáze SQL SELECT David Hoksza http://siret.cz/hoksza Osnova Úvod do SQL Základní dotazování v SQL Cvičení základní dotazování v SQL Structured Query Language (SQL) SQL napodobuje jednoduché anglické

Více

6. blok část C Množinové operátory

6. blok část C Množinové operátory 6. blok část C Množinové operátory Studijní cíl Tento blok je věnován problematice množinových operátorů a práce s množinovými operátory v jazyce SQL. Čtenáři se seznámí s operátory, UNION, a INTERSECT.

Více

Tvorba informačních systémů

Tvorba informačních systémů Tvorba informačních systémů Michal Krátký Katedra informatiky VŠB Technická univerzita Ostrava Tvorba informačních systémů, 2007/2008 c 2005 2008 Michal Krátký Tvorba informačních systémů 1/39 Konceptuální

Více

Informační systémy 2008/2009. Radim Farana. Obsah. UML - charakteristika

Informační systémy 2008/2009. Radim Farana. Obsah. UML - charakteristika 2 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Jazyk UML, základní modely, diagramy aktivit, diagramy entit.

Více

Michal Krátký. Tvorba informačních systémů, 2008/2009. Katedra informatiky VŠB Technická univerzita Ostrava. Tvorba informačních systémů

Michal Krátký. Tvorba informačních systémů, 2008/2009. Katedra informatiky VŠB Technická univerzita Ostrava. Tvorba informačních systémů Tvorba informačních systémů 1/40 Tvorba informačních systémů Michal Krátký Katedra informatiky VŠB Technická univerzita Ostrava Tvorba informačních systémů, 2008/2009 Tvorba informačních systémů 2/40 Úvod

Více

Databázové systémy. Datová integrita + základy relační algebry. 4.přednáška

Databázové systémy. Datová integrita + základy relační algebry. 4.přednáška Databázové systémy Datová integrita + základy relační algebry 4.přednáška Datová integrita Datová integrita = popisuje pravidla, pomocí nichž hotový db. systém zajistí, že skutečná fyzická data v něm uložená

Více

Kapitola 1: Úvod. Systém pro správu databáze (Database Management Systém DBMS) Účel databázových systémů

Kapitola 1: Úvod. Systém pro správu databáze (Database Management Systém DBMS) Účel databázových systémů - 1.1 - Kapitola 1: Úvod Účel databázových systémů Pohled na data Modely dat Jazyk pro definici dat (Data Definition Language; DDL) Jazyk pro manipulaci s daty (Data Manipulation Language; DML) Správa

Více

Operátory ROLLUP a CUBE

Operátory ROLLUP a CUBE Operátory ROLLUP a CUBE Dotazovací jazyky, 2009 Marek Polák Martin Chytil Osnova přednášky o Analýza dat o Agregační funkce o GROUP BY a jeho problémy o Speciální hodnotový typ ALL o Operátor CUBE o Operátor

Více

KIV/ZIS cvičení 5. Tomáš Potužák

KIV/ZIS cvičení 5. Tomáš Potužák KIV/ZIS cvičení 5 Tomáš Potužák Úvod do SQL (1) SQL (Structured Query Language) je standardizovaný strukturovaný dotazovací jazyk pro práci s databází Veškeré operace v databázi se dají provádět pomocí

Více

6. blok část B Vnořené dotazy

6. blok část B Vnořené dotazy 6. blok část B Vnořené dotazy Studijní cíl Tento blok je věnován práci s vnořenými dotazy. Popisuje rozdíl mezi korelovanými a nekorelovanými vnořenými dotazy a zobrazuje jejich použití. Doba nutná k nastudování

Více

SQL. strukturovaný dotazovací jazyk. Structured Query Language (SQL)

SQL. strukturovaný dotazovací jazyk. Structured Query Language (SQL) SQL strukturovaný dotazovací jazyk Structured Query Language (SQL) SQL - historie 1974-75 - IBM - 1.prototyp - SEQUEL od 1979 - do praxe - ORACLE (1979) IBM - SQL/DS (1981), DB/2 (1983) postupně přijímán

Více

Úvod do databázových systémů

Úvod do databázových systémů Vysoká škola báňská Technická univerzita Ostrava Fakulta elektrotechniky a informatiky Úvod do databázových systémů Cvičení 4 Ing. Petr Lukáš petr.lukas@vsb.cz Ostrava, 2014 Opakování Klauzule příkazu

Více

Návrh a tvorba WWW stránek 1/14. PHP a databáze

Návrh a tvorba WWW stránek 1/14. PHP a databáze Návrh a tvorba WWW stránek 1/14 PHP a databáze nejčastěji MySQL součástí balíčků PHP navíc podporuje standard ODBC PHP nemá žádné šablony pro práci s databází princip práce s databází je stále stejný opakované

Více

Marketingová komunikace. 2. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK1aPH/N9KMK1bPH (um1a1ph/um1b1ph)

Marketingová komunikace. 2. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK1aPH/N9KMK1bPH (um1a1ph/um1b1ph) Marketingová komunikace Kombinované studium Skupina N9KMK1aPH/N9KMK1bPH (um1a1ph/um1b1ph) 2. soustředění Mgr. Pavel Vávra 9103@mail.vsfs.cz http://vavra.webzdarma.cz/home/index.htm Minulé soustředění úvod

Více

Marketingová komunikace. 2. a 3. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK3PH (vm3aph)

Marketingová komunikace. 2. a 3. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK3PH (vm3aph) Marketingová komunikace Kombinované studium Skupina N9KMK3PH (vm3aph) 2. a 3. soustředění Mgr. Pavel Vávra 9103@mail.vsfs.cz http://vavra.webzdarma.cz/home/index.htm Co nás čeká: 2. soustředění 16.1.2009

Více

Kolaborativní aplikace

Kolaborativní aplikace Kolaborativní aplikace Michal Máčel Vema, a. s. Okružní 3a, 638 00 Brno - Lesná, macel@vema.cz Tomáš Hruška Fakulta informačních technologií Vysokého učení technického v Brně, Ústav informačních systémů,

Více

Inovace a zkvalitnění výuky prostřednictvím ICT. Základní seznámení s MySQL Ing. Kotásek Jaroslav

Inovace a zkvalitnění výuky prostřednictvím ICT. Základní seznámení s MySQL Ing. Kotásek Jaroslav Střední průmyslová škola a Vyšší odborná škola technická Brno, Sokolská 1 Šablona: Název: Téma: Autor: Číslo: Anotace: Inovace a zkvalitnění výuky prostřednictvím ICT Databáze Základní seznámení s MySQL

Více

Jazyk SQL databáze SQLite. připravil ing. petr polách

Jazyk SQL databáze SQLite. připravil ing. petr polách Jazyk SQL databáze SQLite připravil ing. petr polách SQL - úvod Structured Query Language (strukturovaný dotazovací jazyk 70. léta min. století) Standardizovaný dotazovací jazyk používaný pro práci s daty

Více

Oracle XML DB. Tomáš Nykodým

Oracle XML DB. Tomáš Nykodým Oracle XML DB Tomáš Nykodým xnykodym@fi.muni.cz Osnova Oracle XML DB Architektura Oracle XML DB Hlavní rysy Oracle XML DB Hlavní rysy Oracle XML DB - pokračování XMLType XML Repository Využívání databázových

Více

Databázový systém označuje soubor programových prostředků, které umožňují přístup k datům uloženým v databázi.

Databázový systém označuje soubor programových prostředků, které umožňují přístup k datům uloženým v databázi. Databáze Základní pojmy Pojem databáze označuje obecně souhrn informací, údajů, dat o nějakých objektech. Úkolem databáze je hlídat dodržení všech omezení a dále poskytovat data při operacích. Objekty

Více

UML: Unified Modeling Language

UML: Unified Modeling Language UML 1 UML: Unified Modeling Language Systém kombinace softwaru, hardwaru, dat a uživatelů, která umožňuje řešení konkrétního problému Vývoj systémů vytváření systémů pro klienta Vývoj probíhá na základě

Více

ZÁZNAM PROCESU TVORBY INFORMAČNÍHO SYSTÉMU CAPTURING OF AN INFORMATION SYSTEM DEVELOPMENT

ZÁZNAM PROCESU TVORBY INFORMAČNÍHO SYSTÉMU CAPTURING OF AN INFORMATION SYSTEM DEVELOPMENT ZÁZNAM PROCESU TVORBY INFORMAČNÍHO SYSTÉMU CAPTURING OF AN INFORMATION SYSTEM DEVELOPMENT Marek Pícka Anotace: Tento článek pojednává o novém způsobu záznamu procesu tvorby informačního systému, který

Více

7.3 Diagramy tříd - základy

7.3 Diagramy tříd - základy 7.3 Diagramy tříd - základy - popisuje typy objektů a statické vztahy mezi nimi Objednávka -datumpřijetí -předplacena -číslo -cena +vyřiď() +uzavři() {if Objednávka.zákazník.charakteristika = 'nejistý'

Více

Unifikovaný modelovací jazyk UML 1

Unifikovaný modelovací jazyk UML 1 Unifikovaný modelovací jazyk UML 1 Karel Richta katedra počítačů, FEL ČVUT v Praze Karlovo nám. 13, 121 35 Praha 2 e-mail:richta@fel.cvut.cz Klíčová slova: UML, OCL. Abstrakt. Komunikačním prostředkem

Více

Analýza a Návrh. Analýza

Analýza a Návrh. Analýza Analysis & Design Návrh nebo Design? Design = návrh Není vytváření použitelného uživatelského prostředí (pouze malinká podmnožina celého návrhu) Často takto omezeně chápáno studenty nedokáží si představit,

Více

Analýza a modelování dat 3. přednáška. Helena Palovská

Analýza a modelování dat 3. přednáška. Helena Palovská Analýza a modelování dat 3. přednáška Helena Palovská Historie databázových modelů Relační model dat Codd, E.F. (1970). "A Relational Model of Data for Large Shared Data Banks". Communications of the ACM

Více

Informační systémy ve zdravotnictví. 6. cvičení

Informační systémy ve zdravotnictví. 6. cvičení Vysoká škola báňská Technická univerzita Ostrava Fakulta elektrotechniky a informatiky Informační systémy ve zdravotnictví 6. cvičení Ing. Petr Lukáš petr.lukas@nativa.cz Ostrava, 2014 Opakování Relace

Více

Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W

Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Osnova přednášky Co to je softwarové inženýrství Softwarový proces Metodika a metoda Evoluce softwarových

Více

2. přednáška. Databázový přístup k datům (SŘBD) Možnost počítání v dekadické aritmetice - potřeba přesných výpočtů, např.

2. přednáška. Databázový přístup k datům (SŘBD) Možnost počítání v dekadické aritmetice - potřeba přesných výpočtů, např. 2 přednáška 2 října 2012 10:32 Souborově orientované uchování dat Slabý HW Není možné uchovávat "velká data" - maximálně řádově jednotky MB Na každou úlohu samostatná aplikace, která má samostatná data

Více

4IT218 Databáze. 4IT218 Databáze

4IT218 Databáze. 4IT218 Databáze 4IT218 Databáze Pátá přednáška Dušan Chlapek (katedra informačních technologií, VŠE Praha) 4IT218 Databáze Pátá přednáška SQL - DDL - dokončení SQL - DCL Vlastnosti relačních databázových systémů. Princip

Více

Objektově relační databáze a ORACLE 8

Objektově relační databáze a ORACLE 8 Objektově relační databáze a ORACLE 8 Ludmila Kalužová VŠB - TU Ostrava, Ekonomická fakulta, Katedra informatiky v ekonomice, Sokolská 33, 701 21 Ostrava 1 Abstrakt V současné době existuje velký počet

Více

1. Relační databázový model

1. Relační databázový model 1. Relační databázový model Poprvé představen 1969 (Dr. Edgar F. Codd) IBM Založeno na Teorii množin Predikátové logice prvního řádu Umožňuje vysoký stupeň nezávislosti dat základ pro zvládnutí sémantiky

Více

Analýza a modelování dat. Přednáška 5

Analýza a modelování dat. Přednáška 5 Analýza a modelování dat Přednáška 5 Objektově orientované databáze Relační databáze data uložena v logicky provázaných tabulkách přes cizí klíče výhoda jednoduchost, intuitivnost, naplnění myšlenky oddělení

Více

Primární klíč, cizí klíč, referenční integrita, pravidla normalizace, relace

Primární klíč, cizí klíč, referenční integrita, pravidla normalizace, relace Téma 2.2 Primární klíč, cizí klíč, referenční integrita, pravidla normalizace, relace Obecný postup: Každá tabulka databáze by měla obsahovat pole (případně sadu polí), které jednoznačně identifikuje každý

Více