Databases I (H. 9.3) Tupelcalculus Wiebren de Jonge Vrije Universiteit, Amsterdam versie 2003.

Slides:



Advertisements
Verwante presentaties
OP DE VIERKANTE METER.
Advertisements

Familie de Koning Dien en Theo Hein, Ine en Gitte
SQL deel 2: datamodel ontwerp
Noord-Brabant 18 plaatsen 6 wateren 3 gebieden
Hoe werkt een rekenmachine?
1 Trip Amsterdam Trip Amsterdam D e A r a b i e r D e A r a b i e r.
November 2013 Opinieonderzoek Vlaanderen – oktober 2013 Opiniepeiling Vlaanderen uitgevoerd op het iVOXpanel.
H 14: Enkelvoudige interest
Module 7 – Hoofdstuk 5 (1) SQL – een begin.
Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese - -
Meerdere tabellen: Relaties en Joins
Sint Jorisschool Examenvoorlichting Studie & Voorbereiding Examen Uitslag Diploma.
PHP & MYSQL LES 03 PHP & DATABASES. PHP & MYSQL 01 PHP BASICS 02 PHP & FORMULIEREN 03 PHP & DATABASES 04 CMS: BEST PRACTICE.
Ronde (Sport & Spel) Quiz Night !
SPREEKBEURT 3de LEERJAAR
wivo's football calendar
Databases I (H.15) Normaliseren Wiebren de Jonge Vrije Universiteit, Amsterdam voorlopige versie 2003 sheets 1-54 stabiel !?
De Kalender en De Seizoenen Ellen Adriansens Gegradueerde in de ergotherapie BuSo – OV 2 – 2 e graad Algemene en Sociale Vorming Raamplan BuSo.
3 mavo Betekenis van dit percentage bespreken..
1 Trip Amsterdam Trip Amsterdam D e A r a b i e r D e A r a b i e r.
Sets in een RDBS Een database
Databases I Van EER naar relationeel
Als de som en het verschil gegeven zijn.
Inleiding Databanken: oefeningen 4 Sven Casteleyn 4 Lokaal: 6G HomePage: te bereiken via
Opbouw ISS Vanaf tot ‘Klein maar fijn’,
Regelmaat in getallen … … …
Opleiding Kunstmatige Intelligentie cursus Databases voor AI
1Ben Bruidegom Hoe werkt een rekenmachine? Ben Bruidegom AMSTEL Instituut Universiteit van Amsterdam.
Wat levert de tweede pensioenpijler op voor het personeelslid? 1 Enkele simulaties op basis van de weddeschaal B1-B3.
Les 12b : MODULE 1 Snedekrachten (4)
Les 12b : MODULE 1 Snedekrachten (4)
Databases I Relationeel Model Martin Caminada / Wiebren de Jonge Vrije Universiteit, Amsterdam definitieve versie 2002.
Databases I (H.14) Functionele Afhankelijkheden en Normaalvormen
Databases I EER and Object Modeling Martin Caminada / Wiebren de Jonge Vrije Universiteit, Amsterdam definitieve versie 2002.
Databases I Normaliseren Martin Caminada / Wiebren de Jonge Vrije Universiteit, Amsterdam definitieve versie 2002.
Spatial subgroup mining
Hogeschool van Utrecht1 LEERPLAN V2GDSY3 Februari 2010 – August 2010
2.6 Het gebruik van formules en diagrammen
ribwis1 Toegepaste wiskunde Lesweek 01 – Deel B
ribwis1 Toegepaste wiskunde, ribPWI Lesweek 01
Omvang van VS-troepen in Vietnam
Databases.
Het statuut van de zelfstandige versus werknemer
Herbalife Outer Nutrition
ontdek wat jij kunt bereiken
1 Zie ook identiteit.pdf willen denkenvoelen 5 Zie ook identiteit.pdf.
Dienstregelingen en Wiskunde
Databases I Domeincalculus Martin Caminada / Wiebren de Jonge Vrije Universiteit, Amsterdam definitieve versie 2002.
Regels voor verenigingen en commerciële horeca
Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese - -
Databases I (H. 7: 1-3) Het Relationele Model Wiebren de Jonge Vrije Universiteit, Amsterdam versie 2003.
Databases I Praktische aspecten Database Design en Database System Architectuur Martin Caminada / Wiebren de Jonge Vrije Universiteit, Amsterdam definitieve.
Databases I (Info) Wiebren de Jonge Vrije Universiteit, Amsterdam versie 2003.
Databases I Relationele Algebra Martin Caminada / Wiebren de Jonge Vrije Universiteit, Amsterdam definitieve versie 2002.
Databases I (H. 17) DB System Architectures & DB System Catalog Wiebren de Jonge Vrije Universiteit, Amsterdam versie 2003.
Databases I Het Entity-Relationship Model
Databases I SQL Martin Caminada / Wiebren de Jonge Vrije Universiteit, Amsterdam definitieve versie 2002.
Databases I (H.8) SQL Wiebren de Jonge Vrije Universiteit, Amsterdam versie 2003.
Databases I (H.9.4) Domeincalculus Wiebren de Jonge Vrije Universiteit, Amsterdam versie 2003.
Databases I Tupelcalculus Martin Caminada / Wiebren de Jonge Vrije Universiteit, Amsterdam definitieve versie 2002.
Databases I (H.7.4 e.v.) Relationele Algebra Wiebren de Jonge Vrije Universiteit, Amsterdam versie 2003.
College 3 Hoofdstuk 3: Basis concepten van een relationele database
Les 0 Structured Query Language SQL. Programma Les 0 – Introductieopdracht Les 1 Les 2 Les 3 Schriftelijke toets.
Java Objectgeoriënteerd Programmeren in Java met BlueJ
Wat is SQL (1)? SQL (Structured Query Language):  is een zeer krachtige taal met een beperkt vocabulaire (aantal ‘woorden’)  is declaratief (‘WAT’ niet.
Een computersysteem organiseert gegevens in een hiërarchie die begint bij een bit die de waarde 0 of een 1 vertegenwoordigt. Bits kunnen worden gegroepeerd.
SQL Les February 2019.
SQL Les 3 23 February 2019.
SQL Les 4 12 May 2019.
Transcript van de presentatie:

Databases I (H. 9.3) Tupelcalculus Wiebren de Jonge Vrije Universiteit, Amsterdam versie 2003

Te behandelen querytalen u relationele algebra u domeincalculus u tupelcalculus u SQL

Voorbeeld Database DEPT D#NAMEBUDGET D1engineering500,000 D2sales200,000 DPD EMPE#NAME REL E#NAME BDATE D# E3Mary daughter E1John D1 E3Sue wife E2Joe D1 E4Suzie daughter E3Jack D1 E4Tom son E4Will D2 E4Mary wife E5Bridget D2

Domeincalculus versus Tupelcalculus Vb. query:“Geef de naam en geboortedatum van de werknemers die in D2 werken” Domeincalculus: variabelen bevatten attribuutwaarden (‘domeinelementen’) b.v.: { (n, b) | EMP(name: n, bdate: b, D#: “D2”) } Tupelcalculus: variabelen bevatten tupels uit relaties { (e.name, e.bdate) | EMP(e)  e.D# = “D2” } Dus eig.: tupelvariabelen vs. domeinelementvariabelen

Tupelcalculus Algemene vorm: { (t 1.A 1, t 2.A 2, …, t n.A n ) | CONDITIE(t 1, t 2, …, t n, t n+1, …, t n+m ) } waarbij CONDITIE een formule in predicaatlogica is met: –t 1, t 2, …, t n als vrije tupelvariabelen, en –t n+1, t n+2, …, t n+m als gebonden tupelvariabelen (door quantor  of  ) –en A 1, A 2, …, A n attributen van de betreffende tupels en die opgebouwd is uit de volgende atomen: –R(t i ) waarbij R een relatie in de DB is (“membership condition”; en t i een tupelvariabele elke t i komt voor in een m.c.) –t i.A op t j.B met t i een tupelvariabele met attribuut A, t j een tupelvariabele met attribuut B en op  { , , , , ,  } –t i.A op c (of: c op t i.A) met t i een tupelvariabele met attribuut A, c een constante en op  { , , , , ,  }

Voorbeeld query (“met  en  ”) “Geef de namen en E#’s van werknemers geboren voor 1970” { (e.name, e.E#) | EMP(e)  (e.bdate < “ ” ) } e.namee.E# JohnE1 JoeE2 JackE3

Voorbeeld query (“met alle attributen”) “Geef alle informatie uit de EMP tabel over werknemers geboren voor 1970” { (e.E#, e.name, e.bdate, e.D#) | EMP(e)  ( e.bdate < “ ”) } òf: { e | EMP(e)  ( e.bdate < “ ”) } e.E#e.name e.bdate e.D# E1John D1 E2Joe D1 E3Jack D1

Voorbeeld query (“met  ”) “Geef de namen van de ‘dependents’ van Will” { (d.name) | DPD(d)   e (EMP(e)  e.E# = d.E#  e.name = “Will”) } d.name Suzie Tom Mary

Voorbeeld Database SECRETARY NAME E# BDATE ADDRESS TSPEED Sue E Singel Mary E Damrak SALESMAN NAME E# BDATE ADDRESS LIMIT John E Rokin Joe E Nes ENGINEER NAME E# BDATE ADDRESS SPECIAL Jack E NZVBW 13 electronics Jill E NZABW 15 software

Voorbeeld query (“met  ”) “Geef voor iedere werknemer (= secretary, salesman of engineer) z’n E# en naam” { (e.E#, e.name) | SECRETARY(e)  SALESMAN(e)  ENGINEER(e) } e.E#e.name E1Sue E2Mary E3John E4Joe E5Jack E6Jill

Voorbeeld query (“met  ”) “Geef de namen en E#’s van de ongehuwde engineering- werknemers” { (e.name, e.E#) | EMP(e)   dpm (DEPT(dpm)  dpm.D# = e.D#  dpm.name = “engineering”)   dpd (DPD(dpd)  dpd.E# = e.E#  (dpd.rel = “husband”  dpd.rel = “wife”) )} e.namee.E# JohnE1 JoeE2

Voorbeeld query (“met  ”) “Geef de E#’s van de werknemers die werken aan alle projecten” { (e.E#) | EMP(e)   p ( PROJ(p)   ep (EMP_PROJ(ep)  ep.J# = p.J#  ep.E# = e.E#) ) } e.E# E3

Toelichting bij laatste query { (e.E#) | EMP(e)  PROJ  p (PROJ(p)  J#NAME  ep (EMP_PROJ(ep)  J1build-intranet ep.J# = p.J#  ep.E# = e.E#) )} J2market-research EMP_PROJ EMPE#J# E#NAME BDATE D# E2J1 E1John D1 E3J1 E2Joe D1 E3J2 E3Jack D1 E4J2 E4Will D2 E5J2 E5Bridget D2

Voorbeeld Database M_ZOEKENDE NAAMADRES GJAAR MINJMAXJ TeunNes WimSingel SjonDamstr V_ZOEKENDE NAAMADRES GJAAR MINJMAXJ Truus Amstel BepRokin AnitaNZVBW

Voorbeeld query (“met  ”) “Geef alle paren (naam + adres) van mannen en vrouwen, ongeacht of ze in elkaars gewenste leeftijdscategorie vallen” { (m.naam, m.adres, v.naam, v.adres) | M_ZOEKENDE(m)  V_ZOEKENDE(v) }

Resultaat query m.naam m.adresv.naamv.adres Teun Nes 30Truus Amstel 80 Teun Nes 30Bep Rokin 42 Teun Nes 30Anita NZVBW 18 Wim Singel 23Truus Amstel 80 Wim Singel 23Bep Rokin 42 Wim Singel 23Anita NZVBW 18 Sjon Damstr 9Truus Amstel 80 Sjon Damstr 9Bep Rokin 42 Sjon Damstr 9Anita NZVBW 18

Relationeel compleet u tupelcalculus is relationeel compleet; je kunt er dezelfde queries mee opstellen als met de operaties { , , , ,  } in relationele algebra u queries met de operaties outer join, outer union of aggregate functions kunnen niet noodzakelijkerwijs in tupelcalculus worden uitgedrukt “kale” tupelcalculus en “kale” domeincalculus hebben dus dezelfde functionaliteit als “kale” relationele algebra

Voorbeeld complexe queries (I) ZOEKENDE NAAM ADRES GESL GJAARMINJ MAXJ Teun Nes 30 M Wim Singel 23 M Sjon Damstr 9 M Truus Amstel 80 V Bep Rokin 42 V Anita NZVBW 18 V “Geef de namen en adressen van alle eventuele paren (d.w.z. personen van tegenovergesteld geslacht die binnen elkaars gewenste leeftijdscategorie vallen)”

Voorbeeld query (I) “Geef de namen en adressen van alle eventuele paren (d.w.z. personen van tegenovergesteld geslacht die binnen elkaars gewenste leeftijdscategorie vallen)” { (m.naam, m.adres, v.naam, v.adres) | ZOEKENDE(m)  ZOEKENDE(v)  m.gesl = ‘M’  v.gesl = ‘V’  v.minj  m.gjaar  m.gjaar  v.maxj  m.minj  v.gjaar  v.gjaar  m.maxj }

Voorbeeld complexe queries (I) m.naam m.adresv.naamv.adres TeunNes 30Truus Amstel 80 TeunNes 30Bep Rokin 42 WimSingel 23Truus Amstel 80 WimSingel 23Bep Rokin 42 SjonDamstr 9Anita NZVBW 18

Voorbeeld complexe queries (II) CAN_SUPPLY SUPPLIERPART PRICE s1 p1 3 s1 p2 3NEEDED s2 p1 2PART s2 p2 3 p1 s2 p3 4 p2 s3 p1 4 p3 s3 p2 3 s3 p3 3 “Geef de supplier(s) die alles s3 p4 8 kunnen leveren wat we nodig hebben”

Voorbeeld complexe queries (II) “Geef de suppliers die alles kunnen leveren wat we nodig hebben” { (cs1.supplier) | CAN_SUPPLY(cs1)   p (NEEDED(p)   cs2 (CAN_SUPPLY(cs2)  cs2.supplier = cs1.supplier  cs2.part = p.part) ) } cs1.supplier s2 s3

Voorbeeld complexe queries (II) { (cs1.supplier) | CAN_SUPPLY(cs1)  CAN_SUPPLY  p (NEEDED(p)  SUPPLIERPART PRICE  cs2 (CAN_SUPPLY(cs2)  s1 p1 3 cs2.supplier = cs1.supplier  s1 p2 3 cs2.part = p.part) ) } s2 p1 2 s2 p2 3 s2 p3 4NEEDED s3 p1 4PART s3 p2 3 p1 s3 p3 3p2 s3 p4 8p3

Voorbeeld complexe queries (III) DRAAITFAN_VAN STATIONARTIESTPERSOONARTIEST CountryCarpenters JanOP CountryParton PietMeeuwis NoordzeeHazes JoostBorsato NoordzeeBorsato JoostCarpenters NoordzeeMeeuwis Radio10MeeuwisLUISTERT_NAAR Radio10ElvisPERSOONSTATION Radio10Abba JanRadio10 PietNoordzee JoostRadio10 JoostNoordzee

Voorbeeld complexe queries (III.a) “Geef de artiesten die gedraaid worden op de stations waar Joost naar luistert” { (d.artiest) | DRAAIT(d)   l (LUISTERT_NAAR(l)  l.station = d.station  l.persoon = “Joost”) } d.artiest Hazes Borsato Meeuwis Elvis Abba

Voorbeeld complexe queries (III.b) “Geef de fans van artiesten die nergens gedraaid worden” { (f.persoon) | FAN_VAN(f)   d (DRAAIT(d)  d.artiest = f.artiest) } f.persoon Jan

Voorbeeld complexe queries (III.c) “Geef de personen die tenminste naar ieder radiostation luisteren waar Piet ook naar luistert” (N.B. tenminste, dus eventueel ook nog naar andere stations) { (ln1.persoon) | LUISTERT_NAAR(ln1)   ln2 ( (LUISTERT_NAAR(ln2)  ln2.persoon = “Piet”)   ln3 (LUISTERT_NAAR(ln3)  ln3.persoon = ln1.persoon  ln3.station = ln2.station) ) } ln1.persoon Piet Joost

Safe expressions (1/4) { t |  EMP(t) } wat komt hier zoal uit? o.a.: –(“E6”, “Nick”, “ ”, “D2”) –(“D1”, “engineering”, ) , 96398, “y&$q!%”, ) “alles”, zolang het maar geen in de DB aanwezig EMP tupel is

Safe expressions (2/4) BOEK: Het (safe-)domein van een tupelcalculus-query { (t 1.A 1, t 2.A 2, …, t n.A n ) | CONDITIE(t 1, t 2, …, t n, t n+1, …, t n+m ) } is de verzameling van alle waarden: –die als constante voorkomen in CONDITIE –die voorkomen in een tupel van een relatie die genoemd wordt in CONDITIE

Safe expressions (3/4) voorbeeld: { (e.name, e.E#) | EMP(e)  e.bdate < “ ” ) } (safe-)domein:vb. is safe, want output: { , e.namee.E# E1, John, , D1, JohnE1 E2, Joe, , D1, JoeE2 E3, Jack, , D1, JackE3 E4, Will, , D2, E5, Bridget, , D2 } Boek:Een (domein/tupel) calculus-query is safe indien iedere attribuut-waarde van de output een element is van het bij die query behorende (safe-)domein

Safe expressions (4/4) OPMERKINGEN: Deze aanpak van het boek is (nog) niet helemaal OK, want o.a.: u onnodig restrictief, want verhindert o.a.: –b.v. zoiets als: “t 1.A 1  t 2.A 2 ” en “t 1.A 1  t 2.A 2 ” –aggregaat-functies u onnodig ruim, want lijkt onvoldoende af te dwingen dat resultaat-tupels van juiste graad en type moeten zijn –b.v. character-string als waarde van een ‘integer-attribuut’ u onhandig, want: –(safe-)domein is steeds wat anders, want elke query heeft z’n eigen (safe)-domein Kortom: voegt onvoldoende toe aan onze aanpak met ‘vereiste membership-condities’