1. Objektové databázy
PDT
Genči

2. Obsah Motivácia Manifesty ODMG SQL3 a vývoj štandardizácie
Podpora v súčasných DBMS

3. Anketa Čo je objektová databáza? Čo je to objekt?
Ako by sa mali ukladať objekty do databázy?

4. 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] ODMG 3.0
[5] SQL3 (SQL:1999, SQL99)
[6] Groff, J. R., Weinberg, P. N.:SQL: The Complete Reference, Second Edition, ISBN
[7] príručky a weby serverov – Informix a DB2 (IBM), ORACLE

5. Stav v 1. polovici 90-tych rokov
Generácie DBS
network and hierarchical database systems -CODASYL systems and IMS
Relational database systems.
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

6. 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)

7. 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í (väzba M:N) potrebujeme vytvoriť ďalšiu tabuľku (Dept_Empl Table), ktorá spája kľúče z tabuľky zamestnancov a tabuľky oddelení.

8. Porovnanie relačnej a objektovo orientovanej databázy

9. 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.

10. Types of impedance mismatch
Encapsulation
Data type differences (major mismatch)
Structural and integrity differences
OO structures are heavily nested – difficult to map to relational schemas
Relations - sets of tuples conforming to the same header -do not have an ideal counterpart in OO languages
Manipulative differences
Declarative (REL) versus imperative operations (OO)
Transactional differences
Short transactions (REL) versus long and nested transactions (OO)

11. Pohľad do histórie

12. The Object-Oriented Database System Manifesto(1989)
Malcolm Atkinson, University of Glasgow
Francois Bancilhon, Altair
David DeWitt, University of Wisconsin
Klaus Dittrich, University of Zurich
David Maier, Oregon Graduate Center
Stanley Zdonik, Brown University

13. 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.

14. 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

15. Mandatory features (OO)
Complex objects
Object identity
Encapsulation
Types and Classes
Class or Type Hierarchies
Overriding, overloading and late binding
Computational completeness
Extensibility

16. Mandatory features (R)
Persistence
Secondary storage management
Concurrency
Recovery
Ad Hoc Query Facility

17. Optional
Multiple inheritance
Design transactions
Versions

18. 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 notions be treated differently?)

19. 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 Oracle Corporation.

20. 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=princíp

21. 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)

22. 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 people argue, that there are applications which never wish to run queries (CAD)

23. 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 (spreadsheet),
interfaces to business graphics packages,
the ability to run the application on a different machine from the database,
distributed DBMS.

24. THE PROPOSITIONS Concerning Object and Rule Management
Concerning Increasing DBMS Function
that Result from the Necessity of an Open System

25. 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.

26. Rich type system All of the following are desirable:
an abstract data type (ADT) system to construct new base types
an array type constructor
a sequence type constructor
a record type constructor
a set type constructor
functions as a type
a union type constructor
recursive composition of the above constructors

27. 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.

28. Propositions that Result from the Necessity of an Open System
Third generation DBMSs must be accessible from multiple high level languages.
Persistent X for a variety of Xs is a good idea (cashing). 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.

29. The Third Manifesto (1995)
Hugh Darwen and C.J. Date

30. Manifesto regarding the future of data and database management systems.
It was intended to follow and supersede two previous manifestos

31. Main ideas Importance and significance of Relational Model of Data
Reject SQL unequivocally (jednoznačne)

32. 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).
Mindset=prístup, postoj

33. 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)

34. RM Prescriptions 1. Domains 16. Transactions and dbvars
2. Typed scalars
3. Scalar operators
4. Actual representation
5. Truth values
6. Type constructor TUPLE
7. Type constructor RELATION
8. Equality operator
9. Tuples
10. Relations
11. Scalar variables
12. Tuple variables
13. 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

35. RM Proscriptions (zákaz)
1. No attribute ordering
2. No tuple ordering
3. No duplicate tuples
4. No nulls
5. No nullological mistakes
6. No internal-level constructs
7. No tuple-level operations
8. No composite columns
9. No domain check override
10. No SQL

36. 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

37. OO Proscriptions 1. Relvars are not domains 2. No object IDs
3. No “public instance variables”
4. No “protected instance variables” or “friends”

38. RM Very Strong Suggestions
1. Candidate keys for derived relvars
2. System-generated keys
3. Referential integrity
4. Candidate key inference
5. Quota queries
6. Transitive closure
7. Tuple and relation parameters
8. Default values
9. SQL migration

39. OO Very Strong Suggestions
1. Type inheritance
2. Collection type constructors
3. Conversion to/from relations
4. Single-level store

40. Štandard OODB – ODMG

41. 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“

42. 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
ODMG-93 Release 1.2
Zmeny zabraňujú plnej spätnej kompatibilite
Aktuálna verzia: ODMG 3.0 vydaná v roku Odvtedy sa nevyvíja
Vylepšenia: Väzba Java, Objektový model a O-R mapovanie

43. Architecture of ODMG ODMG 3.0 is a portability specification.
It is designed to allow for portable applications that could run on more than one product.
ODMG 3.0 uses the Java, C++, and Smalltalk languages as much as possible, to allow for the transparent integration of object programming languages. (

44. The major components of ODMG 3.0
Object Model
Object Specification Languages
Object Query Language
C++ Language Binding
Smalltalk Language Binding
Java Language Binding

45. Object model Common data model based on the OMG Object Model.
The OMG core model was designed to be a common denominator for:
object request brokers,
object database systems,
object programming languages,
other applications.
Denominator=menovateľ

46. Object Specification Languages
The two specification languages:
Object Definition Language (ODL) - ODL is a specification language used to define the object types that conform to the ODMG Object Model and is based on the OMG IDL.
Object Interchange Format (OIF) -specification language used to dump and load from a file or set of files.

47. Object Query Language
A declarative (nonprocedural) language for querying and updating objects.
SQL-92 was used as the basis for OQL.

48. Language Binding Supported languages
C++, Smalltalk, Java
It is possible to read and write the same database from C++, Smalltalk, and Java
The ODMG data manipulation languages are tailored to specific application programming languages
The binding includes a version of the ODL that uses syntax of particular language and mechanism to invoke OQL and procedures for operations and transactions

49. Prepojenie prvkov architektúry

50. 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ť

51. 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

52. Dátové typy Atomické : long, long long, short, unsigned long, float,
double,
boolean,
octet,
char,
string,
enum <>

53. Dátové typy Agregované: Štruktúrované literály : set<>,
bag<>,
list<>,
array<>,
dictionary<>
Štruktúrované literály :
date
time
timestamp
interval
structure<>

54. 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ľ (aplikácia) OID nevidí, iba databáza (názvy objektov)
Domény referenčných údajových typov (odkazy) obsahujú práve tieto OID hodnoty

55. 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)
Podpora kľúčov – keys

56. Príklad trieda Pracovnik ( extent PracovnikRozsirenie
key 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);
... };

57. 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

58. trieda Pracovnik
( extent PracovnikRozsirenie
key pracovnikCislo )
{ attribute Long pracovnikCislo;
attribute Projekt vedie;
relationship
List <Projekt> zucastnuje_sa
inverse Projekt::zucastneny;
... };
trieda Projekt
( extent ProjektRozsirenie
key projektID )
{ attribute Long projektID;
Set <Pracovnik> zucastneny
inverse Pracovnik::zucastnuje_sa;

59. Š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č2
class názov_triedy : rozhranie_rodič1, rozhranie_rodič2
class názov_triedy extends názov_rodiča

60. Class Produkt : ProduktInterface
( extent ProduktRozsirenie
key produktCislo )
{ attribute Long produktCislo;
attibute String popis;
attribute Enum Status {
planuje_sa,
vyraba_sa,
hotovy
} status;
attribute Float hmotnost;
...
void zmen_strukturu_produktu(...);
Float vypocet_hmotnosti (); };
class Vyrobok extends Produkt
( extent VyrobokRozsirenie)
{ attribute Long naklady;

61. Perzistentnosť
z relačných databáz - zachovanie 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)

62. interface Zamestnavatel
( extent Zamestnavatelia
keys ico): persistent
{ attribute String ico;
attribute String nazov;
void pridajZamestnanca (in Zamestnanec z);
... };

63. Transakcie len pre perzistentné objekty protokol uzamykania
štandard nerieši deadlock
neexistujú vnorené transakcie
Typ transakcie:
interface Transaction {
void begin(); // začiatok transakcie
void commit(); // úspešné ukončenie
void abort(); // neúspešné ukončenie
void checkpoint(); // kontrolné body – možnosť vrátiť sa v prípade chyby
void join();
void leave();
boolean isOpen(); // stav transakcie };

64. Databáza interface 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ť)

65. 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á špecifikácia niektorých vlastností (napríklad nejasne definuje, ako sa má postupovať pri formátovaní väzieb medzi objektmi)
nahradzovaný XML formátom

66. Príklad súboru OIF s dvoma vyexportovanými perzistentnými objektmi:
333 Zamestnanec{
cislo 333,
jmeno "Karel",
prijmeno "Novák",
oddeleni "Úklid„ }
Zamestnevatel{
ico "123456",
nazev "Firma XY",
adresa {cislo 7,
ulice "Točitá",
mesto "Praha 1",
psc "11000"},
zamestnanci {333}

67. 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 dotazov (objekty obsahujúcich a objekty generujúcich)

68. 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 >>>

69. From
zadáme kolekciu objektov, alebo hodnôt ako rozšírenie 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.nazov
from ( select p vedie_projekt
from Projekt as p
where 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

70. Príklad: select p.nazov from Persons p where p.address!=nil
andthen p.address.city=“Paris”

71. 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

72. Výraz 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 m
použitie referencií:
select prod.popis from m.zucastnuje_sa as proj, proj.priradeny as prod

73. Pr: Zisti adresu každej osoby aj mená a adresy jej 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 PETER Matej a aké má služobné auto:
sef_Meno: o.meno,
sef_Priezvisko: o.priezvisko,
sef_SluzAuto: o.SluzAuto.SPZ)
from o in
( select z.zamestnany.firma.sef
from z in Zamestnany
where z.Priezvisko = “PETER” and z.Meno = “Matej”)

74. 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

75. 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”

76. 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

77. 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: správnosť dotazu sa môže kontrolovať len pri vykonaní

78. 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

79. Produkty OO DBS Caché db4objects (open source)
Generic Object Oriented Database System (GOODS)
JADE
Zope Object Database (ZODB)
Ďalšie viď napr.:

80. 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ý 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.

81. 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 boli odvodené dva projekty: Illustra (Informix) 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ú.

82. SQL

83. SQL - Structured Query Language
Otvorený (neproprietárny) jazyk, ktorého pravidlá boli vytvorené štandardizačnou komisiou
Čo robí SQL?
čítanie existujúcich dát,
vytváranie nových záznamov udržiavajúcich dáta,
zmena existujúcich dát,
mazanie dát
Čo nerobí SQL?
SQL nie je program alebo vývojové prostredie
nemá nástroje na ukladanie dát
SQL je neprocedurálny (deklaratívny) jazyk
SQL nemá vlastné špecifické vývojové prostredie
SQL nie je sieťový jazyk

84. SQL (pokr.)
je čiastočne alebo (takmer) úplne implementovaný a prístupný vo väčšine relačných SRBD
založený na relačnej algebre
dotaz je sekvencia operácií relačnej algebry
Dr. Edgar Frank Codd – tvorca relačných databáz a SQL
1970 – relačný model
1978 – implementácia v IBM ako System/R
198x/199x – komerčné implementácie (ORACLE, DB2, Ingres, Informix, Sybase, ...)

85. Štandardizácia SQL
Medzinárodný štandard ISO/IEC bol pripravený Joint Technical Committee ISO/IEC JTC 1 – Information Technology, Subcommittee SC 32, Data management and interchange
Štandard ISO/IEC 9075 pozostáva z nasledujúcich častí, ktoré sú uvádzané pod spoločným titulom Information technology — Database languages SQL:
JTC1/SC32: Data Management and Interchange
WG1: Open EDI (Finland)
WG2: Metadata (USA)
WG3: Database Languages (Netherlands)
WG4: SQL Multimedia and Application Packages (Japan)
WG5: Remote Database Access (RDA) (United Kingdom)
RG1: Reference Model for Data Management (Maintenance) (UK)
RG2: Export /Import (Maintenance) (Canada)

86. 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

87. 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
Jim Melton, Andrew Eisenberg: SQL Multimedia and Application Packages (SQL/MM)

88. Štandardizácia SQL Year Name Alias Commnet 1986 SQL-86 SQL-87 1989
First formalized by ANSI.
1989
SQL-89
FIPS 127-1
Minor revision, adopted as FIPS
1992
SQL-92
SQL2,
FIPS 127-2
Major revision (ISO 9075), Entry Level SQL-92 adopted as FIPS
1999
SQL:1999
SQL3
Added regular expression matching, recursive queries, triggers, support for procedural and control-of-flow statements, non-scalar types, and some object-oriented features.
2003
SQL:2003
Introduced XML-related features, window functions, standardized sequences, and columns with auto-generated values.
2006
SQL:2006
ISO/IEC :2006 defines ways in which SQL can be used in conjunction with XML. (storing XML data in an SQL database, manipulating it within the database and publishing both XML and conventional SQL-data in XML form. In addition, it enables applications to integrate into their SQL code the use of XQuery, to concurrently access ordinary SQL-data and XML documents)
2008
SQL:2008
Legalizes ORDER BY outside cursor definitions. Adds INSTEAD OF triggers. Adds the TRUNCATE statement
Zdroj:

89. Štandardizácia SQL (pokr.)
podstatná časť jazyka nebola menená v uvedených modifikáciách
zdrojové texty písané v SQL1 sú stále použiteľné

90. SQL 2003 náhrada pôvodného štandardu SQL:1999
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

91. 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

92. Č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

93. Č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

94. 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

95. 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

96. 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)

97. 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)

98. 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>)

99. 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>)

100. Nové funkcie v SQL/Foundation
Rozšírenia skalárných výrazov
rozšírenia CASE
rozšírenia TREAT
Rozšírenia výrazov v query
rozšírenia GROUP BY
WINDOW
TABLESAMPLE
Multiset výrazy
Rozšírenia volania procedúr
beztypový dynamický argument vo volaní
možnosť kvalifikovať parametre s názvom procedúry vo vnútri procedúry

101. Nové funkcie v SQL/Foundation
Nové predikáty
predikáty pre multiset
NORMALIZE
Nové DML príkazy
MERGE
SET COLLATION/ SET NO COLLATION
Viacstĺpcové priradenie
Vnorené savepoints
Zlepšený manažment diagnostiky
Rozšírenia PREPARE príkazu

102. 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 1
INCERMENT BY 1
MAXVALUE 10000
MINVALUE 1
CYCLE

103. 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

104. 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

105. Sekvenčné generátory – 4
INSERT INTO orders (orderno, custno)
VALUES (NEXT VALUE FOR my_seq, );
UPDATE orders
SET orderno = NEXT VALUE FOR my_seq
WHERE orderno = ;
Alter – modifikovanie ikrementácie, základu, minima, maxima
ALTER SEQUENCE seq
RESTART WITH 500
INCREMENT BY 2
Drop – zrušenie generátora
DROP SEQUENCE seq

106. 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 INTEGER
GENERATED ALWAYS AS IDENTITY
START WITH 100
INCREMENT 1
MINVALUE 100
NO MAXVALUE
NO CYCLE,
SALARY DECIMAL(7,2),
... )

107. 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 ) )

108. 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 Y
FROM T WHERE C1 = 1)
WITH DATA
ak je špecifikované WITH NO DATA vytvorí sa prázdna tabuľka

109. 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
Príklad externej funkcie
CREATE FUNCTION DOCMATCH
(VARCHAR(30),VARCHAR(255))
RETURNS TABLE(DOC_ID CHAR(16))
LANGUAGE C
NO SQL
DETERMINISTIC
EXTERNAL
PARAMETER STYLE SQL
Príklad SQL funkcie
CREATE FUNCTION DEPTEMPLOYEES
(DEPTNO CHAR(3))
RETURNS TABLE ( EMPNO CHAR(6),
NAME VARCHAR(40))
READS SQL DATA
DETERMINISTIC
RETURN TABLE(SELECT EMPNO, NAME
FROM EMPLOYEE
WHERE
EMPLOYEE.WORKDEPT =
DEPTEMPLOYEES.DEPTNO)

110. Typ BIGINT väčší rozsah ako INTEGER presnosť definovaná implementáciou
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

111. 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)

112. 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 )

113. Multiset operácie CARDINALITY(value1) SET(value1) ELEMENT(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

114. Multiset operácie value1 MULTISET setop quantifier value2 SELECT col1
setop - UNION | EXCEPT | INTERSECT
quantifier – ALL(default) alebo DISTINCT
Prk.
SELECT col1
MULTISET INTERSECT DISTINCT col2
FROM tbl1
WHERE 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

115. 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

116. 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 hodnôt, kĺzavých súm a priemerov.

117. Aggregačné funkcie ako Windowed 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

118. 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

119. 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

120. 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

121. 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

122. SQL3 Datatypes Built-in types DISTINCT type Array type Row type
Abstract Data Type (ADT)

123. DISTINCT type Specialization of basic data type
CREATE DISTINCT TYPE US_dollar as DECIMAL (7,2)
CREATE TABLE US_sales {
order_id INTEGER,
cust_id INTEGER,
emp_id INTEGER,
sale_amt US_dollar }

124. Array type
provides means to specify a varying cardinality list of elements for a field
Array type allows the specification of array of built-in types
CREATE TABLE Employee {
emp_id INTEGER, …
phone_num CHARACTER(15) ARRAY (5), }

125. Row Types [SQL3] Row-type Definition: Examples:
create row type
T (<component-declaration-list>)
Examples:
create row type AddressType(
street char(50),
city char(20));
create row type StarType(
name char(30),
address AddressType );
create table MovieStar of type StarType;
select MovieStar.name, MovieStar.address..street
from MovieStar
WhereMovieStar.address..city = ‘Columbus’;

126. Abstract Data Types (ADT)
One of the most important changes
ADT allows to define and support the storage and manipulation of complex structures
Definition (example)
CREATE TYPE address
<ADT address body>
Body contains specification of stored information, routines that provide desired behavior, operators, …

127. Informix – Datablades
ftp://ftp.software.ibm.com/software/data/informix/pubs/specsheets/SWSEC E.pdf

129. Informix – Datablades 2
IBM Informix® DataBlade™ modules are server extensions that are integrated into the very core of the engine, delivering unparalleled application functionality and outstanding performance.
DBMS allows to use a single DataBlade module, or integrate several simultaneously to create a unique information management solution customized for customer needs.

131. Datablade
Datablade sú serverové rozšírenia, integrované priamo do funkčného jadra, ktoré prinášajú jedinečnú funkcionalitu aplikácií a vynikajúci výkon.
Pomocou modulov IBM Informix DataBlade sa obrázky, formátované dokumenty, zložité video sekvencie a informačné html stránky dajú ukladať, indexovať a sprístupňovať priamo v prostredí relačnej databázy, čo zabezpečuje väčšiu bezpečnosť, výkon a jednoduchosť použitia

132. Príklady modulov
Modul Spatial Datablade umožňuje riadiť zložité geopriestorové informácie.
Modul Geodetic Datablade podporuje globálne priestorové a časové dotazy.
Modul TimeSeries Datablade poskytuje sofistikovanú podporu pre riadenie časových radov a dočasných dát.
Modul TimeSeries Real-Time Loader je nástroj na zvýšenie výkonu databázového servera pre analýzy v reálnom čase.
Modul Web DataBlade je kolekcia nástrojov, funkcií a príkladov, ktoré uľahčujú vývoj inteligentných interaktívnych databázových aplikácií pre web.
Image Foundation DataBlade™ poskytuje podporu pre spracovanie obrazov zavedením tzv. image typu.

133. Informix datatypes Built-in datatypes User-define datatypes
Complex datatypes

134. Informix – built-in datatypes
Zdroj: InformixIBM Informix Dynamic Server Guide to SQL: Syntax

135. User-Defined Data Type
DISTINCT type
OPAQUE type
Zdroj: InformixIBM Informix Dynamic Server Guide to SQL: Syntax

136. Distinct Data Type
A DISTINCT data type is a user-defined data type that is based on one of the following data types:
a built-in type (including built-in opaque types)
a user-defined opaque type
a named ROW type
an existing DISTINCT type.
Zdroj: InformixIBM Informix Dynamic Server Guide to SQL: Syntax

137. Opaque Data Type
An opaque data type is a user-defined data type that can be used in the same way as a built-in data type.
To create an opaque type, you must use the CREATE OPAQUE TYPE statement.
Because an opaque type is encapsulated, to access the individual components of an opaque type is necessary to create support functions.
The internal storage details of the type are hidden or opaque.
Zdroj: InformixIBM Informix Dynamic Server Guide to SQL: Syntax
opaque=nepriehľadný, nepriesvitný

138. Complex Data Type Complex data types are
ROW types
COLLECTION types
They are created from built-in types, opaque types, distinct types, or other complex types
Zdroj: InformixIBM Informix Dynamic Server Guide to SQL: Syntax

139. Complex Data Type
A single complex data type can include multiple components.
A complex type is not encapsulated (unlike an opaque type).
You can use SQL to access the individual components of a complex data type.
The individual components of a complex data type are called elements.

140. Complex Data Type
Dynamic Server supports the following categories of complex data types:
ROW data types:
Named ROW types
Unnamed ROW types
COLLECTION data types:
SET
MULTISET
LIST

141. Row type
ROW data types consist of one or more fields, defined using the Field Definition syntax.
ROW data types are not the same as table rows.
It is similar to C language “struct” construct

142. COLLECTION data types
SET - unordered collection of elements, each of which has a unique value
MULTISET - unordered collection of elements that can have duplicate values
LIST - ordered collection of elements that can include duplicate elements

143. UDR, UDT

144. ORACLE http://wiki.oracle.com/page/Data+Cartridge

145. Overview of Data Cartridges
Data cartridges extend the capabilities of the Oracle server by taking advantage of Oracle Extensibility Architecture framework.
Data cartridges determine how the server interprets, stores, retrieves, and indexes the application data.
Data cartridges create software components that plug into a server and extend its capabilities into a new domain, making the database itself extensible.

146. Server extension

147. Server extension Extensibility is provided through (see next slides):
Extensible services
Extensible Type System
Extensible Server Execution Environment
Extensible Indexing
Extensible Optimizer
Extensible interfaces

148. Extensible Type System
Oracle adds support for new types, including:
User-defined object types
Collections, such as VARRAY (varying length array) and nested tables
Relationships (REFs)
Large object types (LOBs), such as binary large objects (BLOBs), character large objects (CLOBs), and external binary files (BFILEs)

149. Extensible Server Execution Environment
The Oracle type system decouples the implementation of a member method for a user-defined type from the specification of that method.
Oracle data cartridge components can be implemented using a large number of popular programming languages, such as PL/SQL, C, C++, or Java, extending the database server runtime environment by user-defined methods, functions, and procedures.
Decouple=oddeliť

150. Extensible Server Execution Environment

151. Extensible Indexing
Complex data like text, spatial, image, video, and audio information requires complex data types and specialized indexing techniques.
User-defined indexes are called domain indexes because they index data in an application-specific domain.
The cartridge is responsible for defining the index structure, maintaining the index content during load and update operations, and searching the index during query processing.
The physical index can be stored either in the Oracle database as tables, or externally as a file.

152. Extensible Optimizer
The extensible optimizer lets user-defined functions and indexes collect statistical information (selectivity and cost) and generates an execution plan for a SQL statement.
This information is used by the optimizer in choosing a query plan, thus extending the optimizer to use the user-supplied information.

153. Extensibility Interfaces
DBMS Interfaces - The DBMS interfaces offer the simplest kind of extensibility services.
Cartridge Basic Service Interfaces - provide generic services like memory management, context management, internationalization, and cartridge-specific management.
Data Cartridge Interfaces - to compute the cost of user-defined operators or functions.

154. Object-Relational Features of Oracle

155. Defining Types The syntax is Príklad:
CREATE TYPE t AS OBJECT (
list of attributes and methods );
Príklad:
definition of a point type consisting of two numbers:
CREATE TYPE PointType AS OBJECT (
x NUMBER,
y NUMBER );

156. After that, we might define a line type by
CREATE TYPE LineType AS OBJECT (
end1 PointType,
end2 PointType );
Then, we could create a relation that is a set of lines with ``line ID's'' as:
CREATE TABLE Lines (
lineID INT,
line LineType

157. Constructing Object Values
INSERT INTO Lines
VALUES(27, LineType(
PointType(0.0, 0.0),
PointType(3.0, 4.0) ) );

158. Declaring and Defining Methods
A type declaration can also include methods that are defined on values of that type. The method is declared in the CREATE TYPE statement by constructs:
MEMBER FUNCTION
MEMBER PROCEDURE
Code for the function itself (the definition of the method) is in a separate CREATE TYPE BODY statement.

159. Example Revised declaration of LineType
CREATE TYPE LineType AS OBJECT (
end1 PointType,
end2 PointType,
MEMBER FUNCTION length(scale IN NUMBER) RETURN NUMBER,
PRAGMA RESTRICT_REFERENCES(length, WNDS) );
All methods for a type are then defined in a single CREATE BODY statement:
CREATE TYPE BODY LineType AS
MEMBER FUNCTION length(scale NUMBER) RETURN NUMBER IS
BEGIN
RETURN scale *
SQRT((SELF.end1.x-SELF.end2.x)*(SELF.end1.x-SELF.end2.x) +
(SELF.end1.y-SELF.end2.y)*(SELF.end1.y-SELF.end2.y)
END;

160. Queries to Relations That Involve User-Defined Types
Some queries about the relation lines.
SELECT ll.line.end1.x, ll.line.end1.y
FROM Lines ll;
prints the x and y coordinates of the first end of each line.
SELECT ll.line.end2
Query finds the lengths of all the lines in relation Lines, using scale factor 2
SELECT lineID, ll.line.length(2.0)

161. Types Can Also Be Relation Schemas
To create a relation each of whose tuples is a pair of points
CREATE TABLE Lines1 OF LineType;
Is equivalent to:
CREATE TABLE Lines1 (
end1 PointType,
end2 PointType );
Defined method length is also available whenever we refer to a tuple of Lines1. For instance, we could compute the average length of a line by:
SELECT AVG(ll.length(1.0))
FROM Lines1 ll;

162. References as a Type
For every type t, REF t is the type of references (object ID's if you will) to values of type t.
CREATE TABLE Lines2 (
end1 REF PointType,
end2 REF PointType );
CREATE TABLE Points OF PointType;
Set of all lines between pairs of these points that go from left to right:
INSERT INTO Lines2
SELECT REF(pp), REF(qq)
FROM Points pp, Points qq
WHERE pp.x < qq.x;

163. Nested Tables
A more powerful use of object types in Oracle is the fact that the type of a column can be a table-type.
That is, the value of an attribute in one tuple can be an entire relation
Osoba
Deti …
Jano
Anna 10
Peter 7
Jozef
Jožo 3 5
Kamil 9
Laco 15

164. Peter …
Milan
Eduard
Peter 12
Anna 7
Jožo 15
Kamil 12
Peter 7
Laco 3

165. Nested Tables – example
Table of polygons
Create polygon type
CREATE TYPE PolygonType AS TABLE OF PointType;
Create polygon table
CREATE TABLE Polygons (name VARCHAR2(20), points PolygonType) NESTED TABLE points STORE AS PointsTable;
Insert values into polygon table
INSERT INTO Polygons VALUES(
'square', PolygonType(PointType(0.0, 0.0), PointType(0.0, 1.0),
PointType(1.0, 0.0), PointType(1.0, 1.0) ) );

166. Nested Tables – example (cont.)
Select points that are parts of square
SELECT points
FROM Polygons
WHERE name = 'square';
Select squares with point on the main diagonal
SELECT ss.x
FROM THE(SELECT points
WHERE name = 'square'
) ss
WHERE ss.x = ss.y;

167. DB2 Extenders

168. Examples of DB2 Extenders
Integrate databases with optical storage systems
GIS and geospatial data
Conversion functions, financial functions, math functions, string functions
Time series analysis, financial and macroeconomic time series
Multimedia (audio, video, image data), text, XML, geo-spatial data analysis
Natural language business intelligence language
Integrate heterogeneous data types (CAD, GIS, RDBMS)

169. User defined types (briefly)
Distinct type
Structured type
Reference (REF) type

170. User-Defined Functions
External function - defined to the database with a reference to an object code library; function within that library will be executed when the function is invoked.
SQL function - defined to the database using only the SQL RETURN statement.
Sourced function - defined to the database with a reference to another built-in or user-defined function that is already known to the database.

171. Postgress
PostgreSQL is a robust, next-generation, Object-Relational DBMS (ORDBMS), derived from the Berkeley Postgres database management system. While PostgreSQL retains the powerful object-relational data model, rich data types and easy extensibility of Postgres, it replaces the PostQuel query language with an extended subset of SQL.

172. Záver

173. 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.