Objektové databázy

PDT

Genči

Obsah

• Motivácia

• Manifesty

• ODMG

• SQL3

Zdroje

[1] The Object-Oriented Database System Manifesto Kyoto, Japan, December 1989

[2] Third-Genreation Database System Manifesto ACM SIGMOD Record 19(3) (September 1990)

[3] The Third Manifesto ACM SIGMOD Record 24 (1), (March 1995)

[4] SQL3 Pozor!!!

[5] ODMG 3.0

Porovnanie relačnej a objektovo orientovanej databázy

Predstavme si, že máme databázu, v ktorej máme tabuľku zamestnancov (Employee Table) a tabuľku oddelení (Department Table). Na určenie obojsmernej príslušnosti zamestnancov a oddelení potrebujeme vytvoriť ďalšiu tabuľku (Dept_Empl Table), ktorá spája cudzí kľúč (foreign key) z tabuľky zamestnancov a tabuľky oddelení.

Porovnanie relačnej a objektovo orientovanej databázy

Porovnanie relačnej a objektovo orientovanej databázy

• V OO databáze sú vzťahy vyjadrené priamo, teda nie je potrebné ich modelovať pomocou ďalšej tabuľky.

Stav v 1. polovici 90-tych rokov

Generacie DBS1. network and hierarchical database systems -

CODASYL systems and IMS

2. Relational database systems.

3. New types of application – CAD, CASE, CIM, Office automation (integration of texts, images, animation, audio, video), medical information systems – all this application manipulate with complex data

Object-relational impedance mismatch

• set of conceptual and technical difficulties which are often encountered when a relational database management system is being used by a program written in an object-oriented programming language or style (Wikipedia)

Types of impedance mismatch

• Encapsulation• Data type differences (major mismatch)

• Structural and integrity differences

• Manipulative differences

• Transactional differences

The Object-Oriented Database System Manifesto(1989)

Malcolm Atkinson, University of GlasgowFrancois Bancilhon, Altair

David DeWitt, University of WisconsinKlaus Dittrich, University of Zurich

David Maier, Oregon Graduate CenterStanley Zdonik, Brown University

OODBS

• Manifest attempts to define an object-oriented database system

• It describes the main features and characteristics that a system must have to qualify as an object-oriented database system.

Characteristics

• Mandatory - the ones the system must satisfy in order to be termed an object-oriented database system

• Optional - the ones that can be added to make the system better, but not mandatory

• Open - the points where the designer can make a number of choices

Mandatory features

• Complex objects• Object identity• Encapsulation• Types and Classes• Class or Type Hierarchies• Overriding, overloading and late binding• Computational completeness• Extensibility

Mandatory features (cont.)

• Persistence

• Secondary storage management

• Concurrency

• Recovery

• Ad Hoc Query Facility

Optional

• Multiple inheritance

• Design transactions

• Versions

Open

• Programming paradigm• Representation system defined by the set of atomic

types and the set of constructors

• Type system• Uniformity (is a type an object? is a method an object? or

should these three notions be treated differently?)

Third generation DBS Manifesto (1990)

The Committee for Advanced DBMS Function(Michael Stonebraker of the University of California, Berkeley,

Lawrence A. Rowe of the University of California, Berkeley, Bruce Lindsay of IBM Research,

James Gray of Tandem Computers, Michael Carey of the University of Wisconsin,

Michael Brodie of GTE Laboratories, Philip Bernstein of Digital Equipment Corporation,

David Beech of OracleCorporation.)

THE TENETS OF THIRD-GENERATION DBMSs

• TENET 1: Besides traditional data management services, third generation DBMSs will provide support for richer object structures and rules.

• TENET 2: Third generation DBMSs must subsume second generation DBMSs.

• TENET 3: Third generation DBMSs must be open to other subsystems.

Tenet 1: support for richer object structures and rules

• capabilities required to store and manipulate non-traditional data elements such as text and spatial data.

• an application designer should be given the capability of specifying a set of rules about data elements, records and collections (Referential integrity in a relational context is one simple example of such a rule; however, there are many more complex ones)

Tenet 2: subsume second generation DBMSs

• second generation systems made a major contribution in two areas:

• non-procedural access• data independence

• these advances must not be compromised by third generation systems.

• Some argue that there are applications which never wish to run queries (CAD)

Tenet 3: open to other subsystems

• DBMS which expects broad applicability must have – a fourth generation language (4GL), – various decision support tools, – friendly access from many programming languages, – Friendly access to popular subsystems such as

LOTUS 1-2-3, – interfaces to business graphics packages, – the ability to run the application on a different machine

from the database,– distributed DBMS.

THE PROPOSITIONS

• Concerning Object and Rule Management

• Concerning Increasing DBMS Function

• that Result from the Necessity of an Open System

Propositions Concerning Object and Rule Management

• A third generation DBMS must have a rich type system.

• Inheritance is a good idea.• Functions, including database procedures and

methods, and encapsulation are a good idea.• Unique Identifiers (UIDs) for records should be

assigned by the DBMS only if a user-defined primary key is not available.

• Rules (triggers, constraints) will become a major feature in future systems. They should not be associated with a specific function or collection.

Rich type system

• All of the following are desirable:1. an abstract data type system to construct new base

types

2. an array type constructor

3. a sequence type constructor

4. a record type constructor

5. a set type constructor

6. functions as a type

7. a union type constructor

8. recursive composition of the above constructors

Propositions Concerning Increasing DBMS Function

• Essentially all programatic access to a database should be through a non-procedural, high-level access language.

• There should be at least two ways to specify collections, one using enumeration of members and one using the query language to specify membership.

• Updatable views are essential.• Performance indicators have almost nothing to

do with data models and must not appear in them.

Propositions that Result from the Necessity of an Open System

• Third generation DBMSs must be accessible from multiple HLLs.

• Persistent X for a variety of Xs is a good idea. They will all be supported on top of a single DBMS by compiler extensions and a (more or less) complex run time system.

• For better or worse, SQL is intergalactic dataspeak.

• Queries and their resulting answers should be the lowest level of communication between a client and a server.

The Third Manifesto(1995)

Hugh Darwen and C.J. Date

• Manifesto regarding the future of data and database management systems.

• It was intended to follow and supersede two previous manifestos

Main ideas

• Importance and significance of Relational Model of Data

• Reject SQL unequivocally

Mindset

• Acknowledge the desirability of supporting certain features of Object Orientation.

• They believe that OO features are orthogonal to the Relational Model, and therefore that the Relational Model needs no extension, no correction, no subsumption (zaradenie, včlenenie).

Content of Manifesto

• The manifesto consists of a series of:– Prescriptions

• Relational Model Prescriptions (RM Prescriptions)• Other Orthogonal Prescriptions (OO Prescriptions)

– Proscriptions (RM and OO) – “very strong suggestions.” (RM and OO)

RM Prescriptions1. Domains2. Typed scalars3. Scalar operators4. Actual representation5. Truth values6. Type constructor TUPLE7. Type constructor RELATION8. Equality operator9. Tuples10. Relations11. Scalar variables12. Tuple variables13. Relation variables (relvars)14. Base vs. derived relvars

15. Database variables (dbvars)

16. Transactions and dbvars

17. Create/destroy operations

18. Relational algebra

19. Relvar names and explicit relation values

20. Relational functions

21. Relation and tuple assignment

22. Comparisons

23. Integrity constraints

24. Relation and database predicates

25. Catalog

26. Language design

RM Proscriptions

1. No attribute ordering2. No tuple ordering3. No duplicate tuples4. No nulls5. No nullological mistakes6. No internal-level constructs7. No tuple-level operations8. No composite columns9. No domain check override10. Not SQL

OO Prescriptions

1. Compile-time type checking

2. Single inheritance (conditional)

3. Multiple inheritance (conditional)

4. Computational completeness

5. Explicit transaction boundaries

6. Nested transactions

7. Aggregates and empty sets

OO Proscriptions

1. Relvars are not domains

2. No object IDs

3. No “public instance variables”

4. No “protected instance variables” or “friends”

RM Very Strong Suggestions

1. Candidate keys for derived relvars2. System-generated keys3. Referential integrity4. Candidate key inference5. Quota queries6. Transitive closure7. Tuple and relation parameters8. Default values9. SQL migration

OO Very Strong Suggestions

1. Type inheritance

2. Collection type constructors

3. Conversion to/from relations

4. Single-level store

Štandard OODB – ODMG

História a vývoj ODMG

• Objektovo-orientovaný prístup (koniec 80-tych rokov) - vznik skupiny Object Database Management Group (podskupina OMG)

• Ciele:– vytvorenie priemyselného štandardu pre

OODBS– preklenutie tzv. „impedance mismatch“

Hlavné kroky štandardu ODMG

• 1994 – Zverejnenie prvého návrhu štandardu ODMG-93• Zaviazanie výrobcov pre implementáciu štandardu –

mnohí výrobcovia ponúkajú rozhranie ODMG-3.0• 1994 vychádza opravená verzia pod názvom ODMG-93

Release 1.1• 1996 - ODMG-93 Release 1.2• Zmeny zabraňujú plnej spätnej kompatibilite• Aktuálna verzia: ODMG 3.0 vydaná v roku 2000.

Odvtedy sa nevyvíja• Vylepšenia: Väzba Java, Objektový model a O-R

mapovanie

Architektúra ODMG

Štandard ODMG sa vzťahuje na tieto veci:• Objektový model (perzistentnosť)• Určuje jazyk špecifikácie objektov – ODL(Object

Definition Language) a OIF(Object Interlanguage Format)

• Určuje objektový dotazovací jazyk OQL (Object Query Language)

• Stanovuje väzby pre rôzne objektovo-orientované jazyky, akými sú Java, C++, Smalltalk

• väzba na OMG štandard CORBA a konkrétne na jeho komponentu ORB (Object Request Broker)

Prepojenie prvkov architektúry

Objektový model ODMG 3.0

• Vzťah objektov a hodnôt (literálov) v OO DB

• Zapúzdrenie• Identita objektov• Určovanie tried a vzťahov medzi nimi

(asociácie)• Použitie špecializácie tried (alias

dedičnosť)• Perzistentnosť

• objekt - inštancia abstraktného údajového typu (alias trieda)

• hodnota - inštancia jednoduchého údajového typu

• OID – Object Identification• Stav objektu - hodnota jeho atribútov,

vrátane referenčných• Kategorizácia objektov a literálov podľa

typov a schém

Dátové typy

• Atomické :• long, • long long, • short, • unsigned long, • float, • double, • boolean, • octet, • char, • string, • enum <>

Dátové typy

• Agregované: • set<>, • bag<>, • list<>, • array<>, • dictionary<>

• Štruktúrované literály : • date • time • timestamp • interval • structure<>

Dátové typy

• Agregované dátové typy ako triedy : set<>, bag<>, list<>, array<>, dictionary<> so všetkými iterátormi

• Štruktúrovaný dátový typ ako trieda : Date, Time, Timestamp, Interval

OID

• Prostriedok určovania identity objektov • Generuje sa pri vytváraní objektu • Je to sériové číslo• stabilná a jednoznačná hodnota• Štandard nehovorí o tom, či sú jednotlivé OID

opätovne použité pri zrušení objektu• Používateľ (alias aplikácia) OID nevidí, iba

databáza (názvy objektov)• Ddomény referenčných údajových typov (alias

smerníky) obsahujú práve tieto OID hodnoty

Jazyk ODL

• Opis objektových štruktúr a ER diagramov

• Vzťah tried a rozhraní:– class názov_triedy : názov_rohrania

• Perzistentné rozšírenie triedy – extent

• Nie je definovaná podpora pre migráciu objektov (presun z jedného OODBS do druhého) ani podmienené výrazy

• Podpora kľúčov – keys

Príkladtrieda Pracovnik( extent PracovnikRozsireniekey PracovnikCislo){ attribute Long PracovnikCislo;

attribute Struct PracovnikMeno {String meno,String priezvisko,String rodneMeno

} pracovnikMeno; attribute Date datumNarodenia;attribute Short plat;void zvys_plat (in short nariadenie);...

};

Vzťahy tried

• vzťahy sú výlučne binárne a nemajú žiadne atribúty

• charakter - 1:1, 1:N, M:N

• udržiavanie referenčnej integrity -> databázový systém

• asociácia – relationship

• Obojsmerná asociácia – inverse

trieda Pracovnik( extent PracovnikRozsirenie

key pracovnikCislo ){ attribute Long pracovnikCislo;

attribute Projekt vedie;relationship

List <Projekt> zucastnuje_sainverse Projekt::zucastneny;

...};

trieda Projekt ( extent ProjektRozsirenie

key projektID ){ attribute Long projektID;

relationshipSet <Pracovnik> zucastnenyinverse Pracovnik::zucastnuje_sa;

...};

Špecializácia alias dedenie

• hierarchia tried• subtypy - dcérske/synovské triedy - dynamická väzba

(overriding -známe z oblasti virtuálnych funkcií)• podpora preťaženia, prekrývania a polymorfie inklúzií• podpora dedenia od viacerých rodičovských tried:

interface rozhranie : rozhranie_rodič1, rozhranie_rodič2class názov_triedy : rozhranie_rodič1, rozhranie_rodič2class názov_triedy extends názov_rodiča

ClassClass Produkt : Produkt : ProduktInterfaceProduktInterface(( extent extent ProduktRozsirenieProduktRozsirenie

keykey produktCisloproduktCislo ) ){{ attribute Long attribute Long produktCisloproduktCislo; ;

attibute String attibute String popispopis; ; attribute Enum attribute Enum StatusStatus { {

planuje_saplanuje_sa, , vyraba_savyraba_sa, , hotovyhotovy

} } statusstatus; ; attribute Float attribute Float hmotnosthmotnost; ; ... ... void void

zmen_strukturu_produktu(...)zmen_strukturu_produktu(...); ; Float Float vypocet_hmotnosti ()vypocet_hmotnosti (); ;

};};class class Vyrobok Vyrobok extends extends ProduktProdukt(( extent extent VyrobokRozsirenieVyrobokRozsirenie)){{ attribute Long attribute Long nakladynaklady;;

... ... void void

zmen_strukturu_produktu(...)zmen_strukturu_produktu(...);;};};

Perzistentnosť

• z relačných databáz - zachovania platnosti vzťahov medzi jednotlivými tabuľkami

• zabezpečenie ->programové systémy (pomenovanie objektov)

Objekty:– transientné - udržiavané v rámci programovacieho

jazyka po dobu behu aplikácie – perzistentné - alokované v pamäti databázového

systému (nezávislé na behu aplikácie)- s oboma typmi sa zaobchádza rovnako (oproti

relačnému modelu)

interface Zamestnavatel

( extent Zamestnavatelia

keys ico): persistent

{ attribute String ico;

attribute String nazov;

void pridajZamestnanca (in Zamestnanec z);

...

};

Transakcie• len pre perzistentné objekty• protokol uzamykania• štandard nerieši deadlock• neexistujú vnorené transakcie

Typ transakcie:

interface Transaction {

void begin(); // začiatok transakcievoid commit(); // úspešné ukončenievoid abort(); // neúspešné ukončenievoid checkpoint(); // kontrolné body – možnosť vrátiť sa v prípade chybyvoid join(); void leave(); boolean isOpen(); // stav transakcie

};

Databázainterface Database {

void open (in string nazov_databazy); void close (); void bind (in Object objekt, in string nazov); Object unbind (in string nazov); Object lookup (in string nazov_objektu); ODLMetaObjects::Module schema ();

};

bind – priradenie mien k jednotlivým objektom (perzistentnosť)

Jazyk OIF• špecifikácia ukladania, načítania dát (objektov) do resp. zo súborov• Využitie: výmena objektov rôznymi databázami, duplikácia databáz,

vytváranie dokumentácie k databáze, spúšťanie testov na objektovej databáze (Java serializácia)

• formát podporuje všetky stavy objektov podľa ODMG objektového modelu a definície schémy v ODL

• pre definíciu stavov perzistentných objektov - kľúčové slová pre typy, atribúty a väzby, ktoré sú definované v databázovej schéme pomocou ODL

• absencia podpory štrukturovaných literálov – Date, Time, Timestamp, Interval a Enum

• neúplná špocifikácia niektorých vlastností (napríklad nejasne definuje, ako sa má postupovať pri formátovaní väzieb medzi objektmi)

• nahradzovaný XML formátom

Príklad súboru OIF s dvoma vyexportovanými perzistentnými objektmi:

333 Zamestnanec{cislo 333,jmeno "Karel",prijmeno "Novák",oddeleni "Úklid„

}

123456 Zamestnevatel{ico "123456",nazev "Firma XY",adresa {cislo 7, ulice "Točitá",

mesto "Praha 1",psc "11000"},

zamestnanci {333}}

OQL – Object Query Language

• na základe jazyka OOSQL (SQL-92)• funkcionálny jazyk (na rozdiel od SQL)• podporuje celý typový systém• nepodporuje rekurziu

Vlastnosti:• ortogonálnosť – možnosť kombinovať operácie podľa typového

systému• ohraničenosť, účinnosť, bezpečnosť a optimalizovateľnosť -

dotazy OQL môžu využívať volania metód• uzatvorenosť - objektový model podporuje výsledky relačných,

objekty obsahujúcich a objekty generujúcich dotazov

Blok SFW

• Select From Where – použitie v komplikovanejších dotazoch

Časti :– Select

– volanie metód (operácií) a subdotazov– výsledok dotazu môže byť komplexný typ– vracia multimnožinu hodnôt v DB podľa zadaných kritérií– pre obmedzenie výsledku na množinu – distinct

select distinct struct (m.nazov, projekty: (select p.projektID

from m.zucastnuje_sa as p))from Pracovnici as m;

Výsledok: Set < Struct < nazov: String, projekty: Bag < Long >>>

– From– zadáme kolekciu objektov, alebo hodnôt ako rozšírení tried,

referenčného atribútu, komplexného atribútu, výsledku volania metódy alebo subdotazu

– automatický prevod List (zoznam) a Array(pole) na Bag (multimnožina)

select m.nazovfrom ( select p vedie_projekt

from Projekt as pwhere p.status=“uzavrety“) as m

where m.zarobok>9000;

časť Where obsahuje boolovský výraz, ktorý môže obsahovať tieto prvky:

 Predikáty  Subdotazy  Trojhodnotová logika (nil=>undefined), predikáty

is_undefined, is_defined  Logické spojky: and, or, not  Podmienené spojky: andthen, orelse

Príklad:

select p.nazov

from Persons p

where p.address!=nil

andthen p.address.city=“Paris”

Spojenia (join)

• spojenie dát z dvoch tabuliek na základe rovnakých hodnôt v stĺpcoch

- napr. ktoré osoby majú meno totožné s názvom ulice jednej z adries:

select p from p in Osoby,

g in (select distinct b.v_dome from b in Byty)where p_meno = g_nazovUlice

• obídenie operácie spojenia použítím výrazov cesty

Výrazy cesty

• vznik z jazykov podporujúcich štruktúrované programovanie – operátor „.“

p.vedie.meno

• medzičlánky cesty musia byť referencie pozostávajúce z jediného elementu

nepovolený výraz: p.zucastnuje_sa.meno povolený výraz: select m.meno from p.zucastnuje_sa as mpoužitie referencií: select prod.popis from m.zucastnuje_sa as proj, proj.priradeny as prod

Pr: Odovzdaj adresu každej osoby aj mená a adresy svojich detí:select struct (

os: o.meno, os_Adresa: o.byva.v_dome.adresa, os_Deti:

( select struct ( de_Meno: d.Meno, de_Adresa: d.byva.v_dome.adresa)

from d in o.Deti)) from o in Osoby

Pr: Kto je šéfom zamestnanca Rudi Šuster a aké má služobné auto:select struct (

sef_Meno: o.meno,sef_Priezvisko: o.priezvisko,sef_SluzAuto: o.SluzAuto.SPZ)

from o in ( select z.zamestnany.firma.sef

from z in Zamestnanywhere z.Priezvisko = Rudi and z.Meno = Suster)

Zoskupovanie hodnôt• group by - je vždy viazané na blok SFW• podľa viacerých atribútov• výsledok je komplexný typ:

select p from Projekt as p group by status

Typ výsledku:

Set <Struct <status:enum (...), partition:Bag <Projekt>>>

• having - pre zadanie výberových podmienok • štandard nehovorí nič o zoskupujúcich dotazoch generujúcich

objekty

Agregačné funkcie

• agregácia výsledkov dotazu• min, max, sum, count a avg• funkcie pre kolekcie s príslušným návratovým typom Príklad:max(select zarobok from Pracovnici)

Alternatívny dotaz so syntaxou SQL: select max(zarobok) from Pracovnici

Ďalší príklad OQL: select max(select c.age from p.children c)

from Persons p where p.name = “Paul”

Operácie na agregovaných typoch

• listtoset : transformuje zoznam na množinu • flatten : zjednoduší delené množiny: {{1,2},{3,5}} sa zmení na {1,2,3,5} • union (zjednotenie), intersect (prienik), except (rozdiel)• first na zoznamy -vráti hlavu (prvý prvok) zoznamu• pomenované dotazy

• define as • zjednodušenie dotazov • prvotný koncept pohľadov

define DE_Monti_Projekty select p

from Pracovnici as m, m.vedie as p where priezvisko=”De Monti”

select p from De_Monti_Projekty as d, d.priradeny as p order by status

Zhrnutie OQL

• ortogonálnosť prostredníctvom funkcií v jazyku

• neexistuje priradenie výsledkov triedam a neexistuje priradenie výsledkov dotazu do hierarchie dedenia

• problémy pri explicitnej konverzii typov • bezpečnostné problémy pri správe metód • problém element: správnosť dotazu sa

môže kontrolovať len pri vykonaní

Zhrnutie

• Ciele štandardu:– podpora prenositeľnosti databázových aplikácií– preklenutie problému “impedance mismatch”

• priestor pre jednotlivé implementácie OODBS (model vnorených transakcií)

• chýbajú dôležité koncepty databází:– kontrola prístupu – pohľady – Role, migrácia objektov, podmienené rozšírenia, – Deklaratívne podmienky integrity

Produkty OO DBS

• Caché

• db4objects (open source)

• Generic Object Oriented Database System (GOODS)

• JADE

• Zope Object Database (ZODB)

Objektovo relačné databázy

• Objektovo relačný systém riadenia bázy dát (object-relational database management system ORDBMS) je relačný systém riadenia bázy dát, ktorý taktiež dovoľuje vývojárom integrovať do databázy ich vlastné dátové typy a metódy. Pojem objektovo relačná databáza sa niekedy používa tiež pre externý softvérový produkt bežiaci nad tradičným databázovým serverom, ktorý ponúka podobné možnosti. Tieto systémy sa nazývajú objektovo relačné mapovacie systémy.

Objektovo relačné databázy

• Výskum okolo objektovo relačných systémoch riadenia bázy dát začal vznikať začiatkom 90-tych rokov ako rozšírenie konceptu relačných databáz o koncept objektov. Najmarkantnejší projekt bol Postgres (UC Berkeley), z ktorého sú odvodené dva projekty: Illustra a PostgreSQL.

• Veľa myšlienok ohľadom objektovo relačných databáz bolo pridaných do SQL:1999. Napríklad IBM's DB2, Oracle database a Microsoft SQL Server vyhlasujú, že túto technológiu podporujú.

SQL3

Štandardy SQL

• ANSI (American National Standards Institute)• ISO (the International Standards Organization) • 1986-1987 – komerčná akceptácia• SQL89 (SQL1) • SQL92 (SQL2) • SQL99 (SQL3)

• podstatná časť jazyka nebola menená v týchto modifikáciách

• zdrojové texty písané v SQL1 sú stále použiteľné

SQL

• JTC1/SC32/WG3 Projects (SQL3 only):• Part 1: Framework• Part 2: Foundation• Part 3: Call-Level Interface• Part 4: Persistent Stored Modules• Part 5: Language Bindings• Part 6: XA Specialization• Part 7: Temporal• Part 9: Management of External Data• Part 10: Object Language Bindings

SQL

• JTC1/SC32/WG4 Projects:• Part 1: SQL/MM Framework• Part 2: SQL/MM Full-Text• Part 3: SQL/MM Spatial• Part 4: SQL/MM General Purpose Facilities• Part 5: SQL/MM Still Image

Štandardu SQL/89 vyhovuje 11 schválených produktov na 52 rôznych platformách.

Štandardu SQL/92 vyhovuje viac ako 10 schválených produktov na vyše 100 rôznych platformách

SQL 2003

• náhrada pôvodného štandardu SQL:1999• úprava FCD skončená v Januári 2003• opravenie chýb a rozšírenie všetkých

ôsmich častí SQL:1999• nová časť SQL-XML• nie sú nutné žiadne zmeny pri prispôsobení

sa požiadavkám SQL:2003

SQL 2003 - 2

• Časť 1: SQL/Framework• Časť 2: SQL/Foundation• Časť 3: SQL/CLI(Call-Level Interface)• Časť 4: SQL/PSM(Peristent Stored Modules)• Časť 9: SQL/MED(Management of Extrernal• Data)• Časť 10: SQL/OLB(Object Language Binidng)• Časť 11: SQL/Schemata• Časť 13: SQL/JRT(Java Routines and Types)• Časť 14: SQL/XML

Časť 1: SQL/Framework

• štruktúra štandardu a vzťahy medzi časťami• obvyklé definície a koncepty• prispôsobenie požiadavkám• zmeny v SQL:2003/Framework odrážajú zmeny vo

všetkých ostaných častiach

Časť 2: SQL/Foundation

• najrozsiahlejšia a najdôležitejšia časť• zahŕňa celu SQL:1999/Foundation (z množstvom

opráv) + niekoľko nových vlastností– preddefinované dátové typy– typové konštruktory– DDL pre vytváranie, zmeny, rušenie rôznych

perzistentných objektov (tabuľky, pohľady, udt, SQL- vyvolávaných procedúr)

– skalárne a tabuľkové výrazy– predikáty– DML pre získavanie a zmeny perzistentných dát– moderovaná jazyková väzba, dynamic SQL, direct SQL

Nové funkcie v SQL/Foundation

• nové dátové typy– BIGINT– MULTISET

• rozšírenie existujúcich dátových typov– Unbounded ARRAY

• zrušenie existujúcich typov– BIT– BIT VARYING

• nové schémové objekty– sekvenčné generátory

Nové funkcie v SQL/Foundation

• rozšírenie existujúcich schémových objektov– identita stĺpcov v tabuľkách– generované stĺpce tabuliek– dôležité zmeny v CREATE TABLE LIKE– materializované tabuľky(tabuľky vytvorené z query)– retrospektívne kontrolné obmedzenie– funkčnosť ALTER pre Transforms– SQL-volané procedúry z právami volajúceho– funkcie tabuliek– dynamické a schematické príkazy v procedúrach

Nové funkcie v SQL/Foundation

Nové zabudované skalárne funkcie• LN(epxr)• EXP(epxr)• POWER(epxr,expr)• SQRT(epxr)• FLOOR(epxr)• CEIL[ING](epxr)• WIDTH_BUCKET(expr,expr,expr,expr) Nové agregačné funkcie s jedným argumentom• STDDEV_POP(epxr)• STDDEV_SAMP(epxr)• VAR_POP(epxr)• VAR_SAMP(epxr)

Nové funkcie v SQL/Foundation

Nové agregačné funkcie s dvoma argumentmi• COVAR_POP(expr,expr)• COVAR_SAMP(expr,expr)• CORR(expr,expr)• REGR_SLOPE(expr,expr)• REGR_INTERCEPT(expr,expr)• REGR_COUNT(expr,expr)• REGR_R2(expr,expr)• REGR_AVGX(expr,expr)• REGR_AVGY(expr,expr)• REGR_SXX(expr,expr)• REGR_SYY(expr,expr)• SREGR_XY(expr,expr)

Nové funkcie v SQL/Foundation

Nové funkcie s tabuľkovými oknami• RANK () OVER ...• DENSE_RANK () OVER ...• PERCENT_RANK () OVER ...• CUME_DIST () OVER ...• ROW_NUMBER () OVER ...

Nové inverzne distributívne funkcie• PERCENTILE_DISC (expr) WITHIN GROUP (ORDER BY

<sort specification list>)• PERCENTILE_CONT (expr) WITHIN GROUP (ORDER BY• <sort specification list>)

Nové funkcie v SQL/Foundation

Nové hypotetické agregačné funkcie• RANK (expr, expr ...) WITHIN GROUP (ORDER BY <sort

specification list>)• DENSE_RANK (expr, expr ...) WITHIN GROUP (ORDER BY• <sort specification list>)• PERCENT_RANK (expr, expr ...) WITHIN GROUP (ORDER

BY <sort specification list>)• CUME_DIST (expr, expr ...) WITHIN GROUP (ORDER BY

<sort specification list>)

Nové funkcie v SQL/Foundation

Rozšírenia skalárných výrazov• rozšírenia CASE• rozšírenia TREATRozšírenia výrazov v query• rozšírenia GROUP BY• WINDOW• TABLESAMPLEMultiset výrazyRozšírenia volania procedúr• beztypový dynamický argument vo volaní• možnosť kvalifikovať parametre s názvom procedúry vo

vnútri procedúry

Nové funkcie v SQL/Foundation

Nové predikáty• predikáty pre multiset• NORMALIZENové DML príkazy• MERGE• SET COLLATION/ SET NO COLLATION• Viacstĺpcové priradenieVnorené savepointsZlepšený manažment diagnostikyRozšírenia PREPARE príkazu

Sekvenčné generátory

Mechanizmy pre automatické generovanie postupností• Dva druhy

– Externý: explicitný schémový objekt vytvorené pomocou CREATE

– Interný: implicitne vytvorené pri vytváraní identity stĺpca

• Prk. CREATE SEQUENCE part_num AS INTEGER

START WITH 1INCERMENT BY 1MAXVALUE 10000MINVALUE 1CYCLE

Sekvenčné generátory - 2 • Dátový typ musí byť numeric s presnosťou 0 ak

nie je špecifikovaná inkrementácia tak je daná 1

• Inkrementujúca hodnota môže byť záporná, sekvencia je klesajúca no nesmie byť 0

• Ak nie je definovaná počiatočná hodnota, nastaví pre rastúce (klesajúce) sekvencie minimum (maximum)

• Počiatočná hodnota musí byť medzi minimom a maximom

Sekvenčné generátory - 3

• základná hodnota je nastavená na počiatočnú value pri vytváraní sekvencie

• NO CYCLE je implicitné nastavenie• generovanie nasledujúcej hodnoty NEXT VALUE

FOR seqname = základná hodnota + N*increment

• Ak nasledujúca hodnota > maximum (alebo < minimum) potom:– ak NO CYCLE – vyvolá sa výnimka– inak – nastaví sa minimum (maximum) a vypočíta sa

nová hodnota

Sekvenčné generátory - 4 INSERT INTO orders (orderno, custno)

VALUES (NEXT VALUE FOR my_seq, 123456);

UPDATE ordersSET orderno = NEXT VALUE FOR my_seqWHERE orderno = 123456;

Alter – modifikovanie ikrementácie, základu, minima, maximaALTER SEQUENCE seqRESTART WITH 500INCREMENT BY 2

Drop – zrušenie generátoraDROP SEQUENCE seq

Identifikačné stĺpce

• Najviac jeden stĺpec tabuľky môže byť identifikačným stĺpcom• Automaticky sú mu priraďované hodnoty pri vkladaní do

tabuľky• Prepojenie so sekvenčným generátorom

– Prk. CREATE TABLE employees (

EMP_ID INTEGERGENERATED ALWAYS AS IDENTITYSTART WITH 100INCREMENT 1MINVALUE 100NO MAXVALUENO CYCLE,

SALARY DECIMAL(7,2), ... )

Generované stĺpce

• Môže byť generovaný ľubovoľný počet stĺpcov • Každý musí byť previazaný so skalárnym výrazom• Hodnoty pre generované stĺpce sa prepočítavajú pri každom

vkladaní do tabuľky– Prk.

CREATE TABLE EMPLOYEES (

EMP_ID INTEGER,SALARY DECIMAL(7,2),BONUS DECIMAL(7,2),TOTAL_COMP GENERATED ALWAYS AS (

SALARY + BONUS ),HR_CLERK GENERATED ALWAYS AS (

CURRENT_USER ))

Tabuľky vytvorené z query

• Definícia a/alebo obsah tabuľky môžu byť generované z query– Prk.

CREATE TABLE T1 AS (SELECT (C1+1) AS X,(C2+1) AS YFROM T WHERE C1 = 1)WITH DATA

• ak je špecifikované WITH NO DATA vytvorí sa prázdna tabuľka

Funkcie tabuliek

• SQL-volaná funkcia, ktorej návratová hodnota je MULTISET(ROW(...))

• Tieto funkcie môžu byť vo FORM klauzule a všade kde sa môže vyskytnúť odkaz na tabuľku

– Prk. externej funkcie

CREATE FUNCTION DOCMATCH(VARCHAR(30),VARCHAR(255))RETURNS TABLE(DOC_ID CHAR(16))LANGUAGE CNO SQLDETERMINISTICEXTERNALPARAMETER STYLE SQL

– Prk. SQL funkcieCREATE FUNCTION DEPTEMPLOYEES

(DEPTNO CHAR(3))RETURNS TABLE ( EMPNO CHAR(6),

NAME VARCHAR(40))READS SQL DATADETERMINISTICRETURN TABLE(SELECT EMPNO,

NAMEFROM EMPLOYEEWHERE

EMPLOYEE.WORKDEPT =DEPTEMPLOYEES.DEPTNO)

Typ BIGINT

• väčší rozsah ako INTEGER• presnosť definovaná implementáciou presnosť

BIGINT >=INTEGER >=SMALLINT• musí mať rovnaký základ ako SMALLINT a

INTEGER• všetky operácie definované pre hodnoty

INTEGER a SMALLINT sú aplikovateľné aj na hodnoty BIGINT

Multiset typový konštruktor

• variabilná dĺžka, neusporiadaný súbor elementov rovnakého typu

• žiadna syntax definujúca maximálnu mohutnosť– Prk.

CREATE TABLE (C1 INTEGER,C2 INTEGER MULTISET,C3 ROW ( F1 INT, F2 INT ) MULTISET)

Hodnotový konštruktor

• Konštrukcia prázdneho multiset– MULTISET()– typ elementov je zistený z kontextu

• Multiset vytvorený vymenovaním hodnôt– MULTISET(2,3,5,7)

• Multiset vytvorený výsledkom query– MULTISET(SELECT col1 FROM tbl1 WHERE col2 > 10 )

Multiset operácie

• CARDINALITY(value1)– typ value1 musí byť multiset– vráti počet elementov v value1

• SET(value1)– vráti value1 bez duplicitných hodnôt

• ELEMENT(value1)– mohutnosť value1 musí byť 1– vráti jednoduchý element vo value1

• UNNEST(value1) AS corr-name– vráti elementy multiset v riadkoch virtuálnej tabuľky

• Prk.SELECT SUM(t.c)FROM UNNEST(MULTISET(2,3,5,7)) AS t(c) vráti 17

Multiset operácie

• value1 MULTISET setop quantifier value2– setop - UNION | EXCEPT | INTERSECT– quantifier – ALL(default) alebo DISTINCT– Prk.

SELECT col1

MULTISET INTERSECT DISTINCT col2FROM tbl1WHERE CARDINALITY( col2) > 50

• Nová agregačná funkcia vracajúca hodnotu typu multiset– COLLECT – transformuje hodnoty v skupine na multiset

• Dve nové agregačné funkcie nad stĺpcami typu multiset stĺpcami

• FUSION• INTERSECTION

Multiset operácie

• operátory povolené pre multiset: =, <>• tri nové predikáty

– value1 [NOT] MEMEBER [OF] value2– value1 [NOT] SUBMULTISET [OF] value2– multiset [IS] [NOT] A SET

Windowed table funkcie

• 5 nových funkcií– RANK() OVER– DENSE_RANK() OVER– PERCENT_RANK() OVER– CUME_DIST() OVER– ROW_NUMBER() OVER

• poskytujú možnosti pre výpočet hodností, kĺzavých súm a priemerov.

Aggregačné funkcie akoWindowed Table funkcie

• Nové funkcie– SUM (...) OVER ...– AVG (...) OVER ...– MAX (...) OVER ...– MIN (...) OVER ...– COUNT (...) OVER ...– EVERY (...) OVER ...– ANY (...) OVER ...– SOME (...) OVER ...

• Umožňujú výpočet pohyblivých a súčtových agregačných hodnôt

Hypothetical Aggregate Functions

• 4 nové funkcie– RANK (expr, expr ...) WITHIN GROUP (ORDER BY <sort– specification list>)– DENSE_RANK (expr, expr ...) WITHIN GROUP (ORDER BY– <sort specification list>)– PERCENT_RANK (expr, expr ...) WITHIN GROUP (ORDER– BY <sort specification list>)– CUME_DIST (expr, expr ...) WITHIN GROUP (ORDER BY– <sort specification list>)

Inverse Distribution Functions

• 2 nové funkcie– PERCENTILE_DISC (expr) WITHIN GROUP

(ORDER BY <sort specification list>)– PERCENTILE_CONT (expr) WITHIN GROUP

(ORDER BY <sort specification list>)

• Argument musí byť ohodnotitelný medzi 0 a 1• Vracia hodnotu exp v <sort specification list>

ktorá korešponduje do špecifikovanej percentuálnej hodnoty

Query nad vzorkovými dátami

• Na zhodnotenie agregácie nad vzorkami z uložených dát

• Používa sa pre rozsiahle databázy a keď nie sú potrebné presné údaje

• Dve formy– BERNOULLI– SYSTEM

Prk. SELECT dept, SUM(salary) * 10• FROM employee TABLESAMPLE BERNOULLI(10)• REPEATABLE(5)• GROUP BY dept

príkaz MERGE

• Kombinácia insert a update operácií• Riadky vo vkladanej tabuľke sú na základe predikátu

rozdelené do dvoch skupín – insert source table (ak je predikát false alebo neznámy) a update source table (ak je predikát true)

• Insert source table sú vložené do cieľovej tabuľky• Každý riadok ktorý má zodpovedajúci riadok v update

source table je zmenený (chyba ak zodpovedá viacerým)• Klauzuly MATCHED a NOT MATCHED dovolené

v akomkoľvek poradí• Zavisí od nich poradie insert a updates

Záver

• ODBMS boli pôvodne myslené ako náhrada RDBMS, pretože lepšie „sedia“ objektovo orientovaným programovacím jazykom. Avšak vysoké náklady na prechod a zabudovanie objektovo orientovaných vlastností do RDBMS, vďaka ktorým sa stali ORDBMS a rýchly nástup objektovo – relačných mapperov (object-relational mappers ORM) pomohol RDBMS úspešne ubrániť svoju pozíciu.

• Objektové databázy sú dnes doplnkom a nie náhradou relačných databáz. S príchodom open source projektov prichádza nová vlna nadšenia pre ODBMS.