====================================================================== - zdroje: - Jaroslav Pokorný, Ivan Halaška: Databázové systémy, Vybrané kapitoly a cvičení, skriptá, Karolinum, Praha 1998 - Jaroslav Pokorný: Databázová abeceda, Science, Veletiny 1998 - prednášky Romana Sotáka ====================================================================== Program prednášky: 1. Úvod - základné pojmy 2. Konceptuálny pohľad na dáta 2.1 Entitno-relačný (E-R) konceptuálny model 2.2 Integritné obmedzenia pre vzťahy 2.3 Ďalšie konštrukty konceptuálnych modelov 3. Relačný model dát ====================================================================== 1. Úvod - základné pojmy ====================================================================== - úrovne pohľadu na databázový systém - 1. reálny svet - stále vlastnosti objektov - 2. konceptuálna schéma - 3. databázová schéma - 4. fyzická schéma databázy - súbory - sú nezávislé a môžu na nich pracovať iné tímy - súvis s vytváraním programu (tzv. aplikácie) - životný cyklus - analýza (funkčná a dátová)-> návrh -> implementácia - databázová technológia - unifikovaný systém pojmov, nástrojov a techník na vytváranie informačných systémov a efektívne spracovávanie dát - riadenie veľkého množstva údajov - MB, GB i TB - perzistentnosť - pretrvávanie - nezávislosť na programoch (aplikáciách) i na tom, či s nimi niekto práve pracuje - zdieľateľnosť - používateľnosť viacerými požívateľmi - spoľahlivosť - integrita (integrity) - správnosť údajov a väzieb medzi nimi - integritné obmedzenia - bezpečnosť (sucurity) - ochrana pred neoprávnenými prístupmi (autorizácia) - ďalšie vlastnosti dobrej databázy - neredundantnosť - dáta sa _zbytočne_ neopakujú - dáta nezaberajú veľa miesta a pri zmene hodnoty netreba upravovať tie isté dáta na mnohých miestach; znižuje sa tak riziko výskytu chyby - nezávislosť - programy, ktoré dáta používajú, sú nezávislé na tom, kde sú dáta uložené - databázový systém - databáza - miesto uloženia údajov (a pomocných informácií) - systém riadenia databázy - programy pracujúce s týmito údajmi - potreba dvoch jazykov - jazyk na definíciu dát (data definition language - DDL) - jazyk na manipuláciu a vyhľadávanie dát - opytovacie jazyky (query language) - samostatné i vnorené do iného programovacieho jazyka - SQL (structured query language) zahŕňa oba jazyky - embedded SQL - súčasť programovacieho jazyka (napr. C) - umožňuje ďalšie črty (napr. cykly) - používateľské pohľady - poskytnutie len obmedzeného množstva dát - história - sieťové databázy - spájanie záznamov zo súborov pomocou ukazovateľov - zjednodušenie programovania väzieb medzi dátami - 1965 - konfenecia o jazykoch datových systémov (CODASYL), výbor DBTG (Database Task Group) - 1971 - DBTG vydal správu, kde sa objavili základné databázové pojmy - hierarchické databázy - 2. polovica 60. rokov - IMS (Information Management System) od IBM a iných pre program Apollo (organizovanie 2 miliónov súčiastok hierarchickým spôsobom) - najväčší databázový projekt v histórii - relačné databázy - nezávislé súbory s dátami - silné prostriedky na dopytovanie a aktualizáciu - 1970 - článok E. F. Codda - 1974 - jazyk SQL - 80. roky - rozvoj relačných databáz - objektové databázy - polovica 80. rokov - súčasnosť - relačné, objektové relačné, textové, ... - kompromisy, nič nie je všeliek - stále dominujú relačné - známe databázové systémy - DB2, Informix, Oracle, Sybase, ... ====================================================================== 2. Konceptuálny pohľad na dáta ====================================================================== ---------------------------------------------------------------------- 2.1 Entitno-relačný (E-R) konceptuálny model ---------------------------------------------------------------------- - entitno-relačný (E-R) konceptuálny model - systém pojmov, ktoré popisujú používateľskú aplikáciu (program) s cieľom vytvoriť špecifikáciu štruktúry databázy - pojmy entita a vzťah - entita (angl. entity) - objekt reálneho sveta, ktorý je schopný nezávislej existencie a je jednoznačne odlíšiteľný od ostatných objektov (napr. študent Jozef Púčik s rodným číslom 82...) - vzťah (často aj relácia) (angl. relationship) - väzba medzi dvoma (alebo viacerými) entitami (napr. študent Jozef Púčik s rodným číslom 82... má zapísaný predmet Databázové systémy) - vymedzenie entita vs. vzťah je dosť voľné, neexistuje jednoznačné pravidlo - entita zodpovedá podstatným menám (podmetom) a vzťah slovesám (prísudkom) - ďalšie pojmy - atribút (angl. attribute) - funkcia priraďujúca entitám alebo vzťahom hodnotu, určujúcu niektorú podstatnú vlastnosť entity alebo vzťahu - doména (angl. domain) - množina možných funkčných hodnôt (napr. celé čísla, reťazce znakov, dátumy, ...) - fázy vytvárania E-R modelu - 1. identifikovanie typy entít ako množiny objektov rovnakého typu (napr. študent, predmet) - 2. identifikovanie typov vzťahov, do ktorých entity môžu vstupovať (študent má_zapísaný predmet) - 3. priradenie relevantných atribútov ako entitám tak ich vzťahom (napr. u študenta meno, priezvisko, rodné číslo, ..., u predmetu jeho názov, počet kreditov, ..., u vzťahu má_zapísaný dátum zapísania, ...) - 4. formulácia integritných obmedzení vyjadrujúce s väčšou či menšou presnosťou súlad s modelovanou realitou (napr. doménou atribútu hmotnosť je množina reálnych čísel, dátum od nesmie presiahnuť dátum do) - typ (entity alebo vzťahu) - entity študent Jozef Púčik s rodným číslom 82... a študent Adam Barnau s rodným číslom 81...) sú dve rôzne entity, ale majú čosi spoločné - obe vystupujú v rovnakej roli - v roli študenta - sú to entity rovnakého typu, sú jeho výskytmi alebo inštanciami - obrázok študent-(má_zapísaný)-predmet - S1 Púčik: P1 Matematika, P2 Fyzika; S2 Barnau: P2 Fyzika, P3 Ekonómia, P4 Databázy - výskyty entity študent: S1, S2; výskyty entity predmet: P1, P2, P3, P4; výskyty vzťahu má_zapísaný: S1-P1, S1-P2, S2-P2, S2-P3, S2-P4 - často sa pojmy entita a typ entity zamieňajú, záleží od kontextu - identifikačný kľúč - každá entita musí byť jednoznačne identifikovateľná, a to niektorým atribútom (alebo skupinou atribútov) (napr. zamestnanec pomocou osobného čísla alebo rodného čísla alebo (menom, priezviskom a dátumom narodenia)) - pre jednoznačnosť sa často používa umelý kľúč (napr. S1 na predošlom obrázku) - názov entity je vzhľadom na celú databázovú schému jednoznačný - zápis konceptuálnej schémy: - obrázok: E: entitný_typ [; entitný_typ] R: vzťahový_typ [; vzťahový_typ] entitný_typ: meno_typu (__identifikátor__[, atribút]) vzťahový_typ: meno_typu (meno_entitného_typu [, meno_entitného_typu]) - napr. E: ŠTUDENT(__kód__, meno, priezvisko, ...); PREDMET(__kód__, názov, počet kreditov) R: MÁ_ZAPÍSANÝ (ŠTUDENT, PREDMET) - entity do obdľžnikov, vzťahy do kosoštvorcov - atribúty - entitné (i vzťahové) typy sú popísané až vtedy, keď sú každému pridelené (príslušne popísané) atribúty - atomické (jednoduché) atribúty priraďujú entite (najviac jednu) nedeliteľnú hodnotu - vlastnosti atribútov - meno - je jednoznačné v rámci jedného entitného typu, v rámci celej schémy sa však môžu mená opakovať - typ atribútu - množina hodnôt (doména) (napr. celé čísla, dátumy, reťazce znakov, ...) - kľúčovosť - príslušnosť k identifikačnému kľúču - či pripúšťa prázdnu (nedefinovanú, neznámu) hodnotu (NULL) - kľúčový atribút nesmie obsahovať prázdnu hodnotu - či má jednoznačnú hodnotu (UNIQUE) - čo nie sú atribúty entity - nepodstatné vlastnosti (o podstatnosti rozhoduje tvorca-návrhár-analytik) (napr. u študenta číslo topánok); - informácie, ktoré sú vlastnosťami nejakého iného objektu - napr. u pacienta počet lôžok izby, na ktorej leží - je to atribút tej izby, inak by sa opakovala u každého pacienta ležiaceho v tej izbe - vznikla by redundancia dát; návrh E: PACIENT (_rodné_číslo_, meno, adresa, ..., počet_lôžok) preto treba transformovať napr. na: E: PACIENT (_rodné_číslo_, meno, adresa, ...), IZBA (_číslo_, počet_lôžok, lokalita, ...) R: JE_UMIESTNENÝ_NA (PACIENT, IZBA); odpoveď na počet lôžok izby, v ktorej leží pacient, je potom dostupná cez nadviazaný vzťah JE_UMIESTNENÝ_NA - neatomické atribúty ((zatiaľ?) iba na konceptuálnej úrovni) - skupinové (zložené) atribúty (napr. adresa (štát, obec, ulica, PSČ)) - štruktúra nemusí byť jednoúrovňová, môže to byť celá hierarchia - používa sa vtedy, keď používame aj zložený atribút vcelku, aj jeho zložky jednotlivo - viachodnové atribúty (napr. ZAMESTNANEC (mená_detí: multivalued)) ---------------------------------------------------------------------- 2.2 Integritné obmedzenia pre vzťahy ---------------------------------------------------------------------- - kardinalita vzťahu - napr. (binárny) vzťah PREDNÁŠA medzi dvoma entitami - UČITEĽ a PREDMET - 1:1 - obrázok... - učiteľ prednáša najviac jeden predmet, predmet je prednášaný najviac jedným učiteľom - sú tu zahrnuté aj čiastočné vzťahy 1:0 resp. 0:1 (učiteľ neprednáša žiaden predmet, resp. predmet nie je prednášaný učiteľom (ale napr. odborníkom z praxe)) - v prísnejšom chápaní učiteľ prednáša práve jeden predmet, predmet je prednášaný práve jedným učiteľom - 1:N - obrázok... - učiteľ môže prednášať viac než jeden predmet, predmet je prednášaný najviac jedným učiteľom - vo všeobecnosti sú tu zahrnuté aj čiastočné vzťahy 1:1, 1:0, 0:1 - v prísnejšom chápaní učiteľ prednáša viac než jeden predmet a/alebo predmet je prednášaný práve jedným učiteľom - je tu významný smer - v prípade N:1 je vhodné vymeniť entity (názov vzťahu sa potom zmení na JE_PREDNÁŠANÝ) - M:N - obrázok... - učiteľ môže prednášať viac než jeden predmet, predmet môže byť prednášaný viac než jedným jedným učiteľom - vo všeobecnosti sú tu zahrnuté aj čiastočné vzťahy 1:1, N:1, 1:1, 1:0, 0:1 - determinácia alebo funkčná závislosť entít - entita jedného typu jednoznačne určuje resp. neurčuje entitu druhého typu (alebo je resp. nie je jej determinnantom) - 1:1 - učiteľ je determinantom predmetu, predmet je determinantom učiteľa - 1:N - učiteľ nie je determinantom predmetu, predmet je determinantom učiteľa - M:N - učiteľ nie je determinantom predmetu, predmet nie je determinantom učiteľa - obrázky - UČITEĽ a PREDMET sú v obdĺžnikoch, medzi nimi PREDNÁŠA v kosoštvorci - 1:1 - UČITEĽ 1 1 PREDMET - 1:N - UČITEĽ 1 N PREDMET - M:N - UČITEĽ M N PREDMET - kardinalita ternárneho vzťahu - 1:1:1, 1:1:N, 1:M:N, P:M:N - obrázky... - determinanty... - zložitejšie kardinality sa vyjadrujú obrázkami problematicky - členstvo vo vzťahu - povinné (obligatórne) resp. nepovinné, musí resp. môže, totálna resp. čiastočná účasť vo vzťahu - obligatórne členstvo vyjadruje, že inštancia jedného entitného typu nemôže existovať bez zapojenia do vzťahu s inštanciou druhého entitného typu; je to existenčná závislosť - napr. entitný typ kópia filmu je existenčne závislá od entitného typu film - slabé entitné typy - ak môžu existovať dve rôzne inštancie majúce rovnaké kombinácie hodnôt vlastných atribútov, a teda samy osebe nerozlíšiteľné; sú však identifikovateľné tým, že sú v povinnom (tzv. identifikačnom) vzťahu k inštancii entity iného typu (tzv. identifikačnému vlastníkovi) - napr. kópia filmu je slabý entitný typ (každý film môže mať kópiu s číslom 1), jeho identifikačný vlastník je entitný typ film - súčasťou identifikačného kľúča slabého entitného typu musí byť (popri prípadných vlastných atribútoch) aj identifikačný kľúč jeho identifikačného vlastníka - slabý entitný typ tak "zdedí" jeho príslušné kľúčové atribúty - ak by bolo číslo kópie jednoznačné (v rámci celej požičovne) nezávisle od filmu, nebol by to už slabý entitný typ, ale existenčná závislosť na entitnom type film by ostala - silné alebo regulárne typy entít - tie, ktoré nie sú slabé - jemnejšie vyjadrenie integritného obmedzenia vzťahov - min-max integritné obmedzenia - pre binárny typ vzťahu R(E_1, E_2) označme E_i:(min_i, max_i) minimálny a maximálny počet výskytov entity typu E_i vo vzťahovej množine R - min = 0 vyjadruje nepovinné členstvo vo vzťahu, t.j. možnosť existencie entity daného typu nezávisle na existencii vzťahu k entite druhého typu - min > 0 vyjadruje existenčnú závislosť na druhom členovi vzťahu - možnosti - 1:1 - E_1:(0,1), E_2:(0,1) - E_1 môže, E_2 môže - E_1:(0,1), E_2:(1,1) - E_1 môže, E_2 musí - E_1:(1,1), E_2:(0,1) - E_1 musí, E_2 môže - E_1:(1,1), E_2:(1,1) - E_1 musí, E_2 musí - 1:N - E_1:(0,n), E_2:(0,1) - E_1 môže, E_2 môže - E_1:(0,n), E_2:(1,1) - E_1 môže, E_2 musí - E_1:(1,n), E_2:(0,1) - E_1 musí, E_2 môže - E_1:(1,n), E_2:(1,1) - E_1 musí, E_2 musí - M:N - E_1:(0,n), E_2:(0,m) - E_1 môže, E_2 môže - E_1:(0,n), E_2:(1,m) - E_1 môže, E_2 musí - E_1:(1,n), E_2:(0,m) - E_1 musí, E_2 môže - E_1:(1,n), E_2:(1,m) - E_1 musí, E_2 musí - napr. PÔŽIČKA(ČITATEĽ:(0,4), EXEMPLÁR:(0,1)) - daný čitateľ nemusí mať vypožičanú žiadnu knihu a môže mať vypožičané najviac 4 knihy - daný exemplár môže byť vypožičaný najviac raz, v danom okamihu je buď požičaný nejakému čitateľovi, alebo je v regáli - napr. REZERVÁCIA(ČITATEĽ:(0,4), KNIHA:(0,m)) - daný čitateľ nemusí mať rezervovanú žiadnu knihu a môže mať rezervované najviac 4 knihy - daná kniha môže byť rezervovaná ľubovoľným počtom čitateľov (aj nulovým) - napr. MÁ_KÓPIU(KNIHA:(1,n), EXEMPLÁR:(1,1)) - v knižnici môže byť niekoľko exemplárov (kópií) danej knihy - kažedý exemplár musí mať (práve) jednu väzbu na konkrétny titul - napr. MÁ_KÓPIU(KNIHA:(0,n), EXEMPLÁR:(1,1)) - v knižnici môže byť aj nulový počet exemplárov danej knihy (kniha je zatiaľ len objednaná alebo sú už všetky exempláre vyradené) - dekompozícia vzťahu M:N - obrázok KINO - FILM s reláciou PROGRAM - medzi tieto dva entitné typy vložíme nový typ PROGRAM - tzv. prienikový entitný typ - vzťah sa zmenil na entitu - vzťah M:N sa tak rozloží na dva 1:N vzťahy - PREMIETA a JE_PREMIETANÝ - prienikový entitný typ je potom identifikačne závislý na oboch pôvodných entitách a jeho identifikačný kľúč je tvorený dvojicou identifikátorov oboch pôvodných entít (t.j. nemá žiadne vlastné kľúčové atribúty) - alternatívou je vyrobenie umelého identifikačného kľúča - niekedy na úrovni analýzy, niekedy až vo fáze transformácie ER-schémy do databázovej schémy ---------------------------------------------------------------------- 2.3 Ďalšie črty konceptuálneho modelu ---------------------------------------------------------------------- - IS-A hierarchia - študenti a učitelia majú niekoľko spoločných atribútov, ktoré možno zhrnúť do OSOBA (_osobné_číslo_, meno, priezvisko, dátum narodenia, adresa, ...) - niektoré vlastnosti však majú špecifické - atribúty - u študenta obor, ročník, počet_dosiahnutých_kreditov, ... - u učiteľa akademická_hodnosť, ... - vzťahy - u študenta ZAPÍSAL_SI, ... - u učiteľa UČÍ, JE_ČLENOM_KATEDRY, ... - jedným extrémnym riešením je OSOBA (_osobné_číslo_, meno, priezvisko, dátum narodenia, adresa, | typ_osoby, | obor, ročník, počet_dosiahnutých_kreditov, ..., | akademická_hodnosť, ...) (pričom typ osoby je študent/učiteľ), potom však musíme pripustiť prázdne hodnoty u tých atribútov, ktoré sú pre daný typ osoby irelevantné - druhým extrémnym riešením je zaviesť nezávislé typy ŠTUDENT (_osobné_číslo_, meno, priezvisko, dátum narodenia, adresa, obor, ročník, počet_dosiahnutých_kreditov, ...) a UČITEĽ (_osobné_číslo_, meno, priezvisko, dátum narodenia, adresa, akademická_hodnosť, ...), tým sa však stratí možnosť mať pokope spoločné atribúty - kompromisné riešenie zavádza IS-A hierarchiu: E: OSOBA (_osobné_číslo_, meno, priezvisko, dátum narodenia, adresa); ŠTUDENT (obor, ročník, počet_dosiahnutých_kreditov, ...) ISA OSOBA; UČITEĽ (akademická_hodnosť, ...) ISA OSOBA; - obrázok... (vidlička) - typ entity, ktorý je v IS-A hierarchii nižšie, dedí atribúty, ktorá je v IS-A hierarchii vyššie - IS-A je vzťah reflexívny a tranzitívny - IS-A hierarchia (z hľadiska teórie grafov) - nemusí to byť nutne strom, prípustné je aj viacnásobné dedenie - pre zjednodušenie sa však zavádza podmienka, že existuje iba jeden uzol, z ktorého nevedie žiadna IS-A hrana, tzv. zdroj IS-A hierarchie (táto podmienka je iba formálna - prinajhoršom sa urobí umelý uzol); v celej hierarchii sa potom môže ľahko dediť identifikačný kľúč zdroja; IS-A vzťahy preto nemôžu tvoriť orientovaný cyklus - typ entity v IS-A hierarchii, ktorý nie je zdrojom, nie je identifikačne závislý na žiadnom entitnom type, t.j. je identifikovateľný svojím zdrojom v IS-A hierarchii - zdroj IS-A hierarchie má identifikačný kľúč, ostatné entitné typy v IS-A hierarchii ho nemajú (vlastný) - mená atribútov sú jednoznačné aj vzhľadom na zdedené - prostriedky na vznik IS-A hierarchie - špecializácia - definícia podtypu - napr. PROFESOR je podtypom PRACOVNÍK_VŠ - generalizácia - definícia nadtypu - napr. PUBLIKÁCIA je generalizáciou typov ČLÁNOK, KNIHA, ... - hierarchia identifikačných vzťahov - analógia IS-A hierarchie - ani identifikačné vzťahy preto nemôžu tvoriť orientovaný cyklus, ale tu sa podmienka jedinosti idnetifikačného zdroja nevyžaduje - ak je identifikovaný slabý entitný typ E pre dva rôzne vzťahy ten istý, tak: - 1. buď pre E existujú dva rôzne identifikačné zdroje, - napr. ŽIADANKA by mohla byť identifikovaná pomocou identifikačných kľúčov entitných typov PRACOVNÍK a SKLAD - 2. alebo ten istý identifikačný zdroj vystupuje v dvoch rolách a tie je nutné odlíšiť označením rolí - napr. ŽIADOSŤ_O_MANŽELSKÚ_PÔŽIČKU je identifikovaná pomocou identifikátorov oboch manželov, ktorí žiadosť podávajú, t.j. identifikačné vzťahy sú dva, a to k tomu istému silnému entitnému typu - ďalšie črty - agregácia - umožňuje vzťah medzi objektmi nižšieho typu uvažovať ako objekt vyššieho typu - napr. dvojica typov [DÁTUM, FILM] môže tvoriť typ (množinu dvojíc) PROGRAM - zoskupovanie - slúži na vytváranie podmnožín objektov daného typu, t.j. triedy tried - napr. nad typom PREDNÁŠKA možno vytvoriť zoskupovaním PLÁN_PREDNÁŠOK - triedu prednášok, ktoré je možné študovať na škole v jednom odbore ====================================================================== 3. Relačný model dát ====================================================================== ---------------------------------------------------------------------- 3.1 Základné pojmy ---------------------------------------------------------------------- - relácia - relácia z matematického hľadiska je množina prvkov, ktoré majú tvar (a_1, a_2, ..., a_n), kde n je rád relácie - prvok nazývame n-tica, tica (angl. tuple), jeho zložka a_i je hodnota atribútu A_i - A_i je meno atribútu - reťazec znakov (jednoznačný medzi ostatnými A_i) - doména dom(A_i) je špecifikovaná množina hodnôt, ktoré môže atribút nadobúdať; z matematického hľadiska je teda _dom_ zobrazenie priraďujúce (menu) atribútu jeho doménu; domény môžu byť pre rôzne atribúty aj rovnaké (t.j. zobrazenie dom teda nemusí byť prosté) - reláciu pomenovanú R teda možno popísať ako R(A_1:D_1,...,A_n:D_n), kde D_i=dom(A_i) - je to schéma relácie; alternatívne (a častejšie) R(A_1,...,A_n), prípadne R(_A_), kde _A_={A_1,...,A_n} je množina atribútov - relácia je teda podmnožinou karteziánskeho súčinu D_1x...xD_n (môže byť aj prázdna) - aktuálna doména adom(A) je množina všetkých hodnôt atribútu A, ktoré sa v databáze vyskytujú (z matematického hľadiska ide o obor hodnôt) - napr. relácia FILM(MENO:CHAR(50), HEREC:CHAR(50), ROK:INTEGER) s hodnotami ... - tabuľková terminológia - relácia je tabuľka, schéma relácie je záhlavie tabuľky, tice sú riadky tabuľky, atribúty sú stĺpce tabuľky - rozdiely - relácie neobsahujú duplicitné riadky (sú to množiny), v tabuľkách sa však môžu vyskytovať - v relácii nezáleží na poradí riadkov, v tabuľke je však vždy dané nejaké poradie - 1. normálna forma (1NF) - hodnoty atribútov sú nedeliteľné (atomické); je to základný predpoklad - napr. ak pri filme treba sledovať viacero hercov, môžeme do tabuľky FILM vložiť riadok ("Černí baroni", "Vetchý, Landovský", 1994), stratí sa však atomickosť; dopyt na filmy, v ktorých hrá Landovský, by viedol k spracovávaniu reťazcov na časti a značne by sa skomplikoval - bol by za rámcom relačného modelu dát - projekcia - ak u=(a_1, ..., a_n) \in R a B \subset _A_, B=(A_i1, ..., A_ik), tak u[B]=(a_i1, ..., a_ik) je projekcia u na B - pod R[B] budeme rozumieť množinu projekcií všetkých jej prvkov na B - napr. ... - špecifikácia kľúča schémy - kľúč K schémy R(_A_) je minimálna (nezmenšiteľná) množina atribútov z _A_, ktorých hodnoty budú jednoznačne určovať tice relácie R; prvky u[K] sa nazývajú hodnoty kľúča K - platí teda, že ak sú u a v dve rôzne tice z R, tak existuje aspoň jeden atribút A_i \in K (t.j. kľúčový) taký, že u[A_i]\not = v[A_i] - z podstaty relačného modelu dát vyplýva, že nás zaujímajú iba také schémy relácií, pre ktoré možno definovať kľúč (v najhoršom prípade celá množina atribútov); zabezpečí sa tak neduplicita prvkov - pretože kľúčov môže byť viac, vyberá sa jeden, tzv. primárny kľúč (angl. primary key); ostatné sú sekundárne alebo alternatívne - kľúč, ktorý pozostáva len z jedného atribútu, sa nazýva jednoduchý, ostatné kľúče sú zložené - v schéme budeme kľúčové atribúty podčiarkovať - ak pridáme ku kľúču ľubovoľný nekľúčový atribút, vlastnosť jednoznačnej identifikácie zostáva zachovaná, ale stráca sa minimálnosť - výsledok je nadkľúč schémy R(_A_) - v praxi tabuľka môže obsahovať duplicitné riadky - ide o kolekciu tíc (odstrániť ju možno zavedením klauzuly DISTINCT v SQL) - integritné obmedzenia relačného modelu dát - zatiaľ sme sa zaoberali len štruktúrou dát, teraz nám pôjde o zabezpečenie ich správnosti - integritné obmedzenia sú ďalšie znalosti o dátach, ktoré musia dáta v databáze spĺňať; je potrebné mať mechanizmy umožňujúce kontrolovať dáta a ich zmeny v databáze - napr. v modeli (nie nutne správnom) s reláciami KINO(_názov_, adresa), FILM(_meno_, _herec_, rok), PROGRAM(_názov_kina_, _meno_filmu_, dátum) môžu byť takéto integritné obmedzenia: - v kinách sa nehrá viackrát než dvakrát za týždeň - jeden film sa nedáva viac než v troch kinách v meste - jeden film nemôžu dávať (vvrámci jedného sledovaného obdobia) v jednom kine viackrát - toto obmedzenie vyplýva z definície kľúča relácie PROGRAM - referenčná integrita - integritné obmedzenie popisujúce vzťah medzi dátami z v dvoch relácií - atribút, ktorého sa toto IO týka, sa volá cudzí kľúč (angl. foreign key); ide o atribút (alebo skupinu atribútov), ktorého hodnota v každej tici je hodnotou primárneho kľúča inej relácie (alebo prípadne prázdna) - napr. v predošlom príklade je v schéme PROGRAM atribút názov_kina cudzím kľúčom k relácii KINO a atribút meno_filmu FILM - kontrola referenčnej integrity sa uplatní ako pri vkladaní do závislej relácie, tak pri vymazávaní z hlavnej relácie - formálnejšie - ak je K kľúčom hlavnej relácie H a C cudzím kľúčom závislej relácie Z, tak Z[C] \subset H[K] - spôsoby vyjadrenia IO - procedurálne vyjadrenie IO - v minulosti bolo možné len málo integritných obmedzení špecifikovať v definícii databázy, museli sa implementovať na úrovni aplikácie, ktorá databázu používala - deklaratívna definícia IO - v súčasnosti je možné väčšinu integritných obmedzení formulovať na úrovni databázy, starostlivosť o IO je presunutá na databázový stroj - pri ich narušení by malo dôjsť k chybovému hláseniu a automatickému zotaveniu systému - kontrolné procedúry tvoria samostatné programové moduly, ktoré sú uložené v systémovej časti databázy a vykonáva ich databázový server; vytvárajú sa spravidla automaticky podľa definície IO - špeciálnymi kontrolnými procedúrami sú triggery, ktoré sa aktivujú niektorou (dopredu určenou) spúšťacou udalosťou, obvykle úpravou niektorej databázovej tabuľky - špecifikácia databázy - relačná schéma databázy je dvojica (_R_, _I_), kde _R_ je množina schém a _I_ množina integritných obmedzení - niekedy je vhodné odlišovať lokálne IO, týkajúce sa jednotlivých schém, a globálne IO, udávajúce väzby medzi schémami - ak schémy relácií vyhovujú predpísaným IO, množina relácií je konzistentná - relácie v databáze možno upravovať; databáza sa tak môže meniť z jedného stavu do druhého; v každom stave by však mala byť konzistentná - manipulácia s dátami - dopytovacie prostriedky (príkaz SELECT v SQL) nemenia stav databázy, len čítajú jej obsah - operácie na aktualizáciu - pridanie prvku do množiny - INSERT - odstránenie prvku z množiny - DELETE - úprava prvku v množine - UPDATE - pri manipulácii sa používa (na kontrolu resp. na vyhľadanie) kľúč - v praxi existujú aj iné operácie (napr. dávkové naplnenie) ---------------------------------------------------------------------- 3.2 Relačná algebra ---------------------------------------------------------------------- - relačná algebra - Coddov matematický pohľad na databázové štruktúry ako na relácie (v matematickom zmysle slova); od tej chvíle môžu databázy používať aparát predikátovej logiky prvého rádu - relačná algebra je množina operácií, ktorých aplikáciou na nejaké relácie (t.j. tabuľky) dostaneme ďalšie relácie (t.j. tabuľky) - základné operácie - keďže relácie sú množiny, ide o množinové operácie - súčin (x) - príklad... - zjednotenie (\cup) - príklad... - prienik (\cap) - príklad... - rozdiel (\setminus) - príklad... - na súčin sa nekladie žiadne obmedzenie, ostatné tri relácie musia mať kompatibilné operandy - rovnaký počet atribútov a rovnosť zodpovedajúcich domén (niekedy sa žiada aj zhodnosť mien prislúchajúcich atribútov) - príklad nekompatibility... - pri súčine môže nastať konflikt mien; v takom prípade použijeme bodkovú notáciu - ak sú dané schémy R(_A_) a S(_B_), kde _A_=(A_1,...,A_r) a _B_=(B_1,...,B_s), tak RxS môže mať atribúty pomenované R.A_1, ..., R.A_r, S.B_1, ..., S.B_s - príklad... - ak aj potom nastane konflikt (napr. v prípade R=S), použijeme ďalšiu operáciu - premenovanie atribútov: - ak má relácia schému R(A_1,...,A_r), možno operáciu premenovania zadať zoznamom substitúcií R (alebo alternatívne R) - napr. R (alebo alternatívne R) - konkrétny príklad - špecificky relačné operácie - projekcia (R[B] - hranaté zátvorky) - ak R(_A_) je relácia a B je množina atribútov, B \subset _A_, tak R[B] = {u[C]: u \in R} - pripomeňme, že ak u=(a_1, ..., a_n) \in R a B \subset _A_, B=(A_i1, ..., A_ik), tak u[B]=(a_i1, ..., a_ik) je projekcia u na B - operácia vytvorí reláciu so schémou B a ticami, ktoré vzniknú z pôvodnej relácie odstránením hodnôt atribútov z _A_-B; odstránené sú aj prípadné duplicitné tice - konkrétny príklad - selekcia (alebo aj reštrikcia) (R(\phi) - okrúhle zátvorky) - ak R(_A_) je relácia a \phi je logická podmienka, tak R(\phi) = {u: u \in R \and \phi(u)} - operácia vytvorí reláciu s tou istou schémou, ale ponechá len tie tice, ktoré spĺňajú podmienku \phi - podmienka \phi je zadaná booleovským výrazom - pomocou logických spojek (\and, \or, \not) z atomických formúl tvaru t_1@t_2 alebo t@a, kde a je konstanta, @\in{<, >, =. \ge, \le, \ne}, t_1, t_2, t sú mená atribútov; t_1@t_2(u) sa vyhodnotí ako u.t_1@u.t_2, (t@a)(u) sa vyhodnotí ako u.t@a a logické spojky podľa pravidiel booleovskej algebry - konkrétny príklad - spojenie (R*S) - ak R(_A_)a S(_B_) sú relácie, tak R*S = {u: u[_A_] \in R \and u[_B_] \in S} - operácia vytvorí reláciu so schémou _A_ \cup _B_ a s ticami, ktorých projekcia na atribúty _A_ je z relácie R a projekcia na atribúty _B_ je z relácie S - konkrétny príklad - prvky novej relácie teda vznikajú spojením tíc z oboch relácií cez rovnosť hodnôt na maximálnej množine atribútov (je to tzv. prirodzené spojenie podľa zásady "spoj vo všetkých kombináciách všetko, čo sa spojiť dá) - uvedená množina operácií nie je minimálna, t.j. existujú v nej operácie vyjadriteľné pomocou pomocou ostatných - R \cap S = R \ setminus (R \setminus S) - spojenie možno definovať pomocou kartézskeho súčinu a selekcie (prípadne aj projekcie) - dopytovací jazyk - ak B je množina operácií, tak _dopytovací_jazyk_relačná_algebra_ RA_B je množina výrazov, ktoré vzniknú skladaním relačných operácií nad reláciami danými schémami relačnej databázy - prvok tohto jazyka sa nazýva _dopyt_ (angl. query, čes. dotaz) - _odpoveď_ na dopyt vyjadrený výrazom relačnej algebry je relácia, ktorá vznikne vyhodnotením výrazu dopytu; - ak výrazy E_1, E_2 dávajú rovnakú odpoveď, sú _ekvivalentné_ - dopytovací jazyk, ktorý má prostriedky na realizáciu všetkých operácií relačnej algebry, je _relačne_úplný_ - napr. RA_B, kde B = {zjednotenie, kartézsky súčin, rozdiel, selekcia, projekcia, premenovanie}, je relačne úplný - všetky uvedené operácie možno skladať - schéma, akú bude mať výsledné zloženie týchto operácií je daná takouto funkciou sch (schéma relačného výrazu E): - 1. ak E = R, kde R má schému _A_, tak sch(E) = _A_ - 2.1. ak E = E_1 \cup E_2, E = E_1 \cap E_2 alebo E = E_1 \setminus E_2, tak sch(E) = sch(E_1) (= sch(E_2)) - 2.2. ak E = E_1 x E_2 alebo E = E_1 * E_2, sch(E) = sch(E_1) \cup sch(E_2) - 2.3. ak E = F[X], tak sch(E) = X - 2.4. ak E = F(\phi), tak sch(E) = sch(F) - 2.5. ak E = F<_A_ \to _B_>, kde _A_, _B_ sú množiny atribútov rovnakej mohutnosti, tak sch(E) = (sch(F) \setminus _A_) \cup _B_ - príklad - majme tabuľky: - ŠTUDENT: _meno_ adresa Ján Hraško Hrášková 2 Ružena Šípová Zámocká 4 Ali Baba Serail 1001 Ján Polienko Drevená dedina 16 - PREDMET: _názov_ _učiteľ_ kredit Databázové systémy Vinař 2 Databázové systémy Krajči 4 OOP Eliaš 4 OOP Marcinčák 2 Matematická logika Bukovský 2 Fraktály Bukovský 3 Teória informácie Bukovský 4 - MÁ_ZAPÍSANÉ: _študent_ _predmet_ hodnotenie Ján Hraško OOP A Ján Hraško Matematická logika B Ali Baba Fraktály D Ali Baba OOP C Ali Baba Matematická logika B - postupne robíme operácie: - R_1 = MÁ_ZAPÍSANÉ(študent = 'Ali Baba') študent predmet hodnotenie Ali Baba Fraktály D Ali Baba OOP C Ali Baba Matematická logika B - R_2 = R_1[predmet, hodnotenie] predmet hodnotenie Fraktály D OOP C Matematická logika B - R_3 = R_2 názov hodnotenie Fraktály D OOP C Matematická logika B - R_4 = R_3 * PREDMET názov hodnotenie učiteľ kredit Fraktály D Bukovský 2 OOP C Eliaš 4 OOP C Marcinčák 2 Matematická logika B Bukovský 2 - R_5 = R_4 [učiteľ] učiteľ Bukovský Eliaš Marcinčák - riešili sme vlastne dopyt "Nájdite učiteľov, ktorí učia Aliho Babu", a to pomocou výrazu (bez medzivýsledkov): ((MÁ_ZAPÍSANÉ(študent = 'Ali Baba')[predmet, hodnotenie]) * PREDMET)[učiteľ] - atribút "hodnotenie" nie je pre celkový výsledok podstatný, mohli sme ho teda pri konštrukcii výrazu vynechať; dostali by sme tak ekvivalentný výraz, ktorého vyhodnocovanie by bolo efektívnejšie - dopyty, ktoré využívajú len operácie selekcia, projekcia, spojenie a premenovanie atribútov (teda nie súčin, zjednotenie, prienik ani rozdiel), nazývame jednoduché dopyty; v praxi je ich drvivá väčšina - plán vyhodnotenia dopytu - v relačnom systéme riadenia databázy existuje tzv. jadro relačného stroja - skupina programov schopných vyhodnotiť relačné operácie, ktoré pracujú pomocou rôznych algoritmov - algoritmy využívajú zotriedenie relácií, indexy, štatistiky (napr. veľkosť relácie, početnosť rôznych hodnôt daného atribútu, ...), optimalizátor pomocou týchto metainformácií rozhodne, ktorý z algoritmov je pre vyhodnotenie daného dopytu optimálny, prípadne sám nahradí neefektívne napísaný výraz efektívnejším - príklady na vytváranie výrazov - máme tabuľky ako v minulom príklade - treba nájsť všetkých študentov, ktorí majú zapísané (okrem iných) všetky predmety Bukovského - R = MÁ_ZAPÍSANÉ[študent] x PREDMET(učiteľ='Bukovský')[názov] je zoznam všetkých kombinácií študentov, ktorí majú zapísanú aspoň jednu prednášku (od hocikoho) a predmetov, ktoré vyučuje Bukovský (bez ohľadu na to, či ho má študent zapísaný alebo nie) - S = R \setminus MÁ_ZAPÍSANÉ[študent, predmet] obsahuje dvojice študentov a predmetov, ktoré učí Bukovský, ale nemajú ich zapísané - T = S[študent] sú mená študentov, ktorí nemajú zapísaný aspoň jeden predmet Bukovského (t.j. takých, ktorým chýba čo i len jeden jeho predmet) - U = MÁ_ZAPÍSANÉ[študent] \setminus T je potom zoznam tých študentov, ktorí majú zapísané všetky predmety Bukovského - zhrnutím dostávame výraz: MÁ_ZAPÍSANÉ[študent] \setminus (MÁ_ZAPÍSANÉ[študent] x PREDMET(učiteľ='Bukovský')[názov] \setminus MÁ_ZAPÍSANÉ[študent, predmet])[študent] - treba nájsť všetkých študentov, ktorí nemajú zapísaný žiaden predmet Bukovského - od všetkých študentov odčítame takých, ktorí majú zapísaný aspoň jeden predmet Bukovského - ŠTUDENT[meno] \setminus (PREDMET(učiteľ='Bukovský')[názov] * MÁ_ZAPÍSANÉ[študent, predmet])[študent] - všimnime si, že výsledok obsahuje aj mená tých študentov, ktorí nemajú zapísané nič ('Ružena Šípová', 'Ján Polienko') - ďalšie operácie relačnej algebry - @-spojenie (R[t_1@t_2]S), kde @\in{<, >, =, \ge, \le, \ne} - ak R(_A_)a S(_B_) sú relácie, tak R[t_1@t_2]S = {u: u[_A_] \in R \and u[_B_] \in S \and u.t_1@u.t_2} - operácia vytvorí reláciu, ktorá je podmnožinou kartézskeho súčinu RxS a obsahuje tie tice u, ktoré spĺňajú podmienku u.t_1@u.t_2; je to vlastne zloženie kartézskeho súčinu a príslušnej selekcie - konkrétny príklad... - najčastejšou možnosťou pre @ je =, vtedy je to obyčajné spojenie (*) - @-polospojenie, kde @\in{<, >, =, \ge, \le, \ne} - ľavé @-polospojenie (RS) - analogicky - pri zrejmom smere sa hovorí iba o @-polospojení - najčastejšou možnosťou pre @ je =, vtedy ide o polospojenie cez rovnosť; v prípade, že ide o spojenie cez rovnosť všetkých zodpovedajúcich atribútov, hovorí sa o prirodzenom polospojení - ľavé polospojenie sa označuje R<*S, pravé R*>S - ľavé ani pravé @-polospojenie nie je komutatívne, t.j. R<*S a R*>S nie sú ekvivalentné - konkrétne príklady... - delenie (R\%S) - ak R(_A_)a S(_B_) sú relácie a _B_ \subset _A_, tak R\%S = {t: (\forall s \in S) t\oplus \in R} (\oplus označuje zreťazenie, napr. (a, b) \oplus (c, d) = (a, b, c, d)) - ak označíme T=R\%S, tak R=TxS, je to teda inverzná operácia ku karteziánskemu súčinu (pre disjunktné atribúty) - konkrétny príklad... - delenie sa dá odvodiť: R\%S = R[_A_ \setminus _B_] \setminus ((R[_A_ \setminus _B_] x S) \setminus R)[_A_ \setminus _B_] - príklad - nájdeme iný výraz vyjadrujúci všetkých študentov, ktorí nemajú zapísaný žiaden predmet Bukovského - MÁ_ZAPÍSANÉ[študent, predmet] \% PREDMET(učiteľ='Bukovský')[názov] - podľa definície obsahuje výsledok takých študentov š, že pre každý predmet p učený Bukovským existuje riadok r z relácie MÁ_ZAPÍSANÉ, že r[študent] = š a r[predmet] = p - operácie za relačným modelom dát - prázdna hodnota (NULL) - patrí do všetkých domén - označuje, že hodnota chýba, je neznáma, neaplikovateľná, ... - ak je použitá v logických operáciách, dostaneme logickú hodnotu UNKNOWN (prechod do trojhodnotovej logiky) - vonkajšie spojenie (R *_F S od angl. full outer join), ľavé vonkajšie spojenie (R *_L S od angl. left outer join), pravé vonkajšie spojenie (R *_R S od angl. right outer join) - R *_L S = (R * S) \cup (R_ne x (NULL, ..., NULL)), R *_R S = (R * S) \cup ((NULL, ..., NULL) x S_ne), R *_F S = (R *_L S) \cup (R *_R S), kde R_ne resp. S_ne obsahujú tice nespojiteľné s S resp. R - na rozdiel od vonkajšieho spojenia sa normálnemu spojeniu niekedy hovorí aj vnútorné spojenie (angl inner join) - konkrétny príklad... ---------------------------------------------------------------------- 3.2 Relačný kalkulus ---------------------------------------------------------------------- - relačný kalkulus - ticový relačný kalkulus - vyskytol sa v Coddovej definícii relačného modelu dát - poskytuje veľmi silný dopytovací prostriedok zrovnateľný s relačnou algebrou - používa prirodzený pohľad na reláciu ako na množinu tíc - doménový relačný kalkulus - objavil sa neskôr - pracuje s hodnotami jednotlivých tíc - je to vhodný teoretický základ pre dopytovací jazyk QBE (query by example) známy napríklad zo systému Paradox - oba jazyky úzko súvisia s predikátovým počtom prvého rádu - zameriame sa na doménový relačný kalkulus - základné prvky doménového relačného kalkulu - termy - (doménové) premenné - reťazce znakov - zodpovedajú atribútom, dosadzujú sa za ne hodnoty z prislúchajúcich domén - konštanty - nemusia sa vyskytovať v databáze - napr. plat < 10000 vyjadruje hodnoty premennej plat, ktoré sú menšie než 10000, pričom 10000 sa nemusí vyskytovať v databáze - na rozdiel od všeobecného predikátového počtu už nemá iné termy - na odlíšenie reťazcových konštánt od premenných ich budeme uzátvarať do apostrofov - predikátové symboly - mená relácií z databázy - binárne porovnávacie predikáty z množiny {<, >, =, \ge, \le, \ne} - formuly - atomické formuly - R(t_1, ..., t_n), kde R je predikátový symbol a t_i sú termy - napr. ŠTUDENT(priezvisko, adresa) - t_1@t_2, kde @\in{<, >, =, \ge, \le, \ne} - napr. priezvisko='Ali Baba' - skladanie formúl - pomocou logických spojok - \and (konjukcia), \or (disjunkcia), \impl (implikácia), \neg (negácia) - ak F_1, F_2 sú formuly, tak aj F_1\and F_2, F_1\or F_2, F_1\impl F_2 sú formuly - ak F je formula, tak aj \neg F je formula - pomocou kvantifikátorov - \exi (existenčný), \all (všeobecný) - ak F(x) je formula, tak aj (\exi x)F(x), (\all x)F(x) sú formuly - univerzum (univerzálna doména) - množina hodnôt, ktoré možno dosadzovať za premenné - je to napr. zjednotenie všetkých domén použitých v schéme databázy - prakticky je to však zjednotenie aktuálnych domén v schéme databázy a konštánt, ktoré sa vyskytli v tom-ktorom dopyte - interpretácia formúl - napr. keď vo formule ŠTUDENT(x,y) ohodnotíme premenné x a y, t.j. priradíme im konkrétne hodnoty a a b, táto formula má ohodnotenie TRUE, ak dvojica (a,b) patrí do relácie ŠTUDENT, a ohodnotenie FALSE, ak ak dvojica (a,b) do relácie ŠTUDENT nepatrí - tento mechanizmus možno využiť na formuláciu dopytov - napr. výraz {(x,y): ŠTUDENT(x, y)} znamená dopyt "Nájdi mená a adresy všetkých študentov" - napr. výraz {(učiteľ, kredit): PREDMET('OOP', učiteľ, kredit)} znamená dopyt, ktorí učitelia a za koľko kreditov vyučujú predmet 'OOP' - napr. výraz {učiteľ: (\exi kredit) PREDMET('OOP', učiteľ, kredit)} znamená dopyt, ktorí učitelia vyučujú predmet 'OOP' - vyhodnocovanie formuly (\exi x)F(x) resp. (\all x)F(x) si možno predstaviť ako mechanizmus dosadzujúci za x relevantné konštanty k a vyhodnocujúci platnosť formuly F(k) - napr. v prípade formuly (\exi učiteľ)PREDMET('OOP', učiteľ, 4) by vyhodnotil formuly: PREDMET('OOP', 'Vinař', 4) - FALSE, PREDMET('OOP', 'Krajči', 4) - FALSE, PREDMET('OOP', 'Eliaš', 4) - TRUE, PREDMET('OOP', 'Marcinčák', 4) - FALSE, PREDMET('OOP', 'Bukovský', 4) - FALSE, takže odpoveď by bola {'Eliaš'} - typy výskytov premennej - viazaný výskyt - ak je v dosahu príslušného kvantifikátora - napr. premenná x vo formule (\exi x)F(x) má viazaný výskyt - voľný výskyt - v inom prípade - budeme sa vyhýbať formulám typu G(x) \and (\exi x)F(x), v ktorých má premenná x aj voľný aj viazaný výskyt - časť (\exi x)F(x) jednoducho ekvivalentne nahradíme (\exi y)F(y) (na názve viazanej premennej nezáleží, označuje len väzbu medzi miestami jej výskytu); môžeme preto povedať, že každá premenná vo formule je buď voľná alebo viazaná - sprehľadnenia a zjednodušenia zápisov - aby bolo jasné, ktorá hodnota zodpovedá ktorému atribútu, budeme používať notáciu typu {(x,y): ŠTUDENT(meno:x, adresa:y)} - ak sa vo formule dopytu vyskytne (\exi x)R(..., A:x, ...) a x sa už viackrát vo formule nevyskytne, budeme (\exi x) a A:x vynechávať - napr. {u: (\exi k) PREDMET(názov:'OOP', učiteľ:u, kredit:k)} nahradíme zápisom {u: PREDMET(názov:'OOP', učiteľ:u)} - vzťah relačného kalkulu k relačnej algebre - príklady - formula {u: PREDMET(názov:'OOP', učiteľ:u)} v relačnej algebre znamená PREDMET(názov='OOP')[učiteľ] - pri vyhodnocovaní formuly robíme najprv selekciu a potom projekciu - formula {(š, a, p): (\exi š)(MÁ_ZAPÍSANÉ(študent:š, predmet:p) \and ŠTUDENT(meno:š, adresa:a)} v relačnej algebre znamená MÁ_ZAPÍSANÉ*(ŠTUDENT)[študent, adresa, predmet] - problémy s vyhodnocovaním formúl doménového relačného kalkulu - v doménovom relačnom kalkule možno formulovať výrazy, ktoré pri klasickom matemtickom spôsobe vyhodnocovania vedú pri (v princípe) nekonečnej doméne (napr. INTEGER) k nekonečným reláciám alebo k nekonečnému počtu vyhodnocovaní formúl - napr. aspoň jedna z relácií {x: R(x)} a {x: \neg R(x)} je nekonečná - napr. pri vyhodnocovaní formuly (\exi x)F(x) resp. (\all x)F(x) sa za x dosadzuje nekonečne množstvo konštánt - napr. ak je v {(x,y): R(x) \or S(y)} formula R(x) ohodnotená TRUE, za y možno dosadiť čokoľvek a dvojica (x,y) bude vyhovovať - riešením je obmedziť pojem relačného kalkulu - Ullman-ov syntaktický variant doménového relačného kalkulu) zavádza pojem tzv. bezpečných formúl, ktorej všetky voľné premenné sú ohraničené - vyhodnocovací algoritmus pre kvantifikátory obmedzíme na hodnoty z aktuálnych domén jednotlivých atribútov (t.j. hodnôt, ktoré sa vyskytujú v databáze) - hovoríme o obmedzenej interpretácii - takto upravený relačný dopytovací kalkulus je potom relačne úplný - je ekvivalentný relačnej algebre; znamená to, že relačná algebra je dostatočne silná, lebo zodpovedá prostriedkom logiky prvého rádu - rozšírenia relačných kalkulov - áno/nie dopyty - ak formula dopytu neobsahuje žiadnu voľnú premennú, testujeme vlastne, či nadobúda hodnotu FALSE (prázdna množina) alebo TRUE ("plná" množina) - agregačné funkcie - relačnou algebrou sa napr. nedá zistiť, koľko predmetov učí konkrétny učiteľ, potrebovali by sme funkciu, ktorá množine priradí jej mohutnosť - prax ukazuje potrebu takýchto agregačných funkcií, ktoré sa aplikujú na reláciu vzniknutú ako odpoveď na poddopyt - COUNT - počet prvkov - SUM_A - súčet hodnôt (číselného) atribútu A pre danú reláciu - MIN_A - mimimum z hodnôt atribútu A pre danú reláciu - MAX_A - maximum z hodnôt atribútu A pre danú reláciu - AVG_A - (aritmetický) priemer hodnôt (číselného) atribútu A pre danú reláciu - relačný kalkul môžeme rozšíriť tak, že medzi termy kalkulu zaradíme okrem jednoduchých premenných a konštánt výrazy tvaru agregačná_funkcia(výraz_relačného_kalkulu, atribút) a následne aj príslušné z nich zložené termy - napr. výraz {(š, počet): počet = COUNT(p: MÁ_ZAPÍSANÉ(študent:š, predmet:p)} vytvára tabuľku študentov spolu s počtom zapísaných predmetov - tranzitívny uzáver relácie - niektoré typy vzťahov sú tranzitívne, t.j. ak je A vo vzťahu k B a B vo vzťahu k C, tak aj A je vo vzťahu k C (napr. vzťah nadriadený-podriadený, dosiahnuteľnosť električkou z jedného miesta do druhého, predok-potomok) - reprezentovať takéto vzťahy v databáze možno jednoducho pomocou binárnej relácie R(A, B), kde dom(A)=dom(B), pričom stačí, aby v R boli iba bezprostredné vzťahy (napr. najbližší nadriadený, susedná zastávka električky, rodič) - výrazy definujúce úrovne: R_0(A, B) = R(A, B), R_1(A, B) = (R_0[B=A'](R_0)[A,B']), R_2(A, B) = (R_1[B=A'](R_1)[A,B']), ... - konkrétny príklad... - výraz pre tranzitívny uzáver relácie R je potom zjednotením týchto úrovní, nedá sa však vo všeobecnosti zostrojiť, lebo nie je známy počet úrovní (je implicitne obsiahnutý v databáze) ======================================================================