Databases I Tupelcalculus Martin Caminada / Wiebren de Jonge Vrije Universiteit, Amsterdam definitieve versie 2002.

Slides:



Advertisements
Verwante presentaties
SQL deel 2: datamodel ontwerp
Advertisements

Module 7 – Hoofdstuk 5 (1) SQL – een begin.
Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese - -
Databases via internet
Meerdere tabellen: Relaties en Joins
PHP & MYSQL LES 03 PHP & DATABASES. PHP & MYSQL 01 PHP BASICS 02 PHP & FORMULIEREN 03 PHP & DATABASES 04 CMS: BEST PRACTICE.
Databases Informatica Ga verder met een muisklik. SQL FCO DBMS NE FA
HALLO OPLETTEN : Waarom sql DOEN : Introductie opdracht
Databases I (H.15) Normaliseren Wiebren de Jonge Vrije Universiteit, Amsterdam voorlopige versie 2003 sheets 1-54 stabiel !?
Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese - -
Sets in een RDBS Een database
Relationele Databases
Relationele Databases Hoofdstuk 10
Databases.
Databases I Van EER naar relationeel
Thema 3 Genetica Paragraaf 1
Inleiding Databanken: oefeningen 4 Sven Casteleyn 4 Lokaal: 6G HomePage: te bereiken via
Compositionaliteit, bereik en lambda’s
Databanken by Steven Stinis.
Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese - -
Normalisatie Relationeel databaseontwerp:
Opleiding Kunstmatige Intelligentie cursus Databases voor AI
SQL (structured Query Language) DDL (Data Definition Language) DML (Data Manipulation Language) Ontwerp databaseBevraag database.
Databases I Relationeel Model Martin Caminada / Wiebren de Jonge Vrije Universiteit, Amsterdam definitieve versie 2002.
Martin Caminada / Wiebren de Jonge Vrije Universiteit, Amsterdam
Databases I EER and Object Modeling Martin Caminada / Wiebren de Jonge Vrije Universiteit, Amsterdam definitieve versie 2002.
Databases I (H. 9.3) Tupelcalculus Wiebren de Jonge Vrije Universiteit, Amsterdam versie 2003.
Databases I (H. 1) Wiebren de Jonge Vrije Universiteit, Amsterdam Voorlopige versie 2003.
Databases I Normaliseren Martin Caminada / Wiebren de Jonge Vrije Universiteit, Amsterdam definitieve versie 2002.
Spatial subgroup mining
Databases.
Relationele Databases Hoofdstuk 10 Deel 2 Blz.: 90 t/m 95.
Relationele Databases
Laat software voor je werken
LauwersCollege Buitenpost Informatica
Databases I Domeincalculus Martin Caminada / Wiebren de Jonge Vrije Universiteit, Amsterdam definitieve versie 2002.
7 Databases. STRUCTURED QUERY LANGUAGE Bij het relationele model hoort een programmeertaal waarmee de database benaderd kan worden. In de praktijk wordt.
Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese - -
Vakgroep Telecommunicatie en Informatieverwerking 1 Relationele databases: Het relationeel databasemodel Hoofdstuk 4 Database, Document and Content Management.
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 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 (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
ANALYSE 3 INFANL01-3 WEEK CMI Informatica.
Analyse 3 INFANL01-3 week 3 CMI Informatica.
ANALYSE 3 INFANL01-3 WEEK CMI Informatica.
Analyse 3 INFANL01-3 week 2 CMI Informatica.
ANALYSE 3 INFANL01-3 WEEK CMI Informatica.
ANALYSE 3 INFANL01-3 WEEK 8 CMI Informatica. ANALYSE 3- INFANL01-3 ▸ Vorige les ▸ Herhaling ▸ Normaliseerregels ▸ Omzetten ERD ▸ Group by en SET ▸ Proeftentamen.
ANALYSE 3 INFANL01-3 WEEK CMI Informatica.
ANALYSE 3 INFANL01-3 WEEK 6 CMI Informatica. ANALYSE 3- INFANL01-3 ▸ Vorige les ▸ Subqueries met correlaties ▸ Subqueries zonder correlaties ▸ Views ▸
Wat is SQL (1)? SQL (Structured Query Language):  is een zeer krachtige taal met een beperkt vocabulaire (aantal ‘woorden’)  is declaratief (‘WAT’ niet.
– Software development fundamentals
Informatica-Actief Thema: Databases en informatiemodellering
LauwersCollege Buitenpost Informatica
Databases.
SQL Les February 2019.
SQL Les 3 17 February 2019.
SQL Les 3 23 February 2019.
SQL Les 9 12 May 2019.
SQL Les 4 12 May 2019.
– Software development fundamentals
Transcript van de presentatie:

Databases I Tupelcalculus Martin Caminada / Wiebren de Jonge Vrije Universiteit, Amsterdam definitieve versie 2002

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

Voorbeeld Database DEPARTMENT D#NAMEBUDGET D1engineering500,000 D2sales200,000 DEPENDENT EMPLOYEEE#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 voorbeeld query: “Geef de naam en geboortedatum van de employees die in D2 werken” Domeincalculus: variabelen bevatten waarden attributen { (n, b) | EMPLOYEE(name: n, bdate: b, D#: “D2”) } Tupelcalculus: variabelen bevatten waarden tupels { (e.name, e.bdate) | EMPLOYEE(e)  e.D# = “D2” }

Tupelcalculus Algemene vorm: { (t 1.A 1, t 2.A 2, …, t n.A n ) | CONDITIE(t 1, t 2, …, t n ) } CONDITIE is een formule in predicaatlogica (met t 1, t 2, …, t n als vrije variabelen), opgebouwd uit de volgende atomen: –REL(t i ) met t i tupelvariabele –t i.A op t j.B met t i tupelvariabele met attribuut A, t j tupelvariabele met attribuut B en op  { , , , , ,  } –t i.A op c (of: c op t i.A) met t i tupelvariabele met attribuut A, c constante en op  { , , , , ,  }

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

Voorbeeld query (alternatief) “Geef alle informatie uit de EMPLOYEE tabel van employees die voor 1970 zijn geboren” { e | EMPLOYEE(e)  e.bdate < “ ” ) } e.E#e.name e.bdate e.D# E1John D1 E2Joe D1 E3Jack D1 { (e.E#, e.name, e.bdate, e.D#) | EMPLOYEE(e)  e.bdate < “ ” ) }

Voorbeeld query (  ) “Geef de namen van de dependents van Will” { (d.name) | DEPENDENT(d)   e (EMPLOYEE(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 (  ) “Geef voor iedere employee (= 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 (  ) “Geef de namen en E#’s van de ongehuwde engineering- employees” { (e.name, e.E#) | EMPLOYEE(e)   dpm (DEPARTMENT(dpm)  dpm.D# = e.D#  dpm.name = “engineering”)   dpd(DEPENDENT(dpd)  dpd.E# = e.E#  (dpd.rel = “husband”  dpd.rel = “wife”)) } e.namee.E# E1John E2Joe

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

Voorbeeld Database PROJECT { (e.E#) |  p (PROJECT(p)  J#NAME  ep (EMP_PROJ(ep)  J1build-intranet ep.J# = p.J#  ep.E# = e.E#)) } J2market-research EMP_PROJ EMPLOYEEE#J# E#NAME BDATE D# E2J1 E1John D1 E3J1 E2Joe D1 E3J2 E3Jack D1 E4J2 E4Will D2 E5J2 E5Bridget D2

Voorbeeld query (  ) “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) }

Voorbeeld Database M_ZOEKENDE M_NAAM M_ADRESM_GJAAR M_MINJ M_MAXJ TeunNes WimSingel SjonDamstr V_ZOEKENDE V_NAAM V_ADRES V_GJAARV_MINJ V_MAXJ Truus Amstel Bep Rokin Anita NZVBW

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) { (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 (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 (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) “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) “Geef de personen die tenminste naar ieder radiostation luisteren waar Piet ook naar luistert (eventueel ook nog naar andere stations)” { (l1.persoon) | LUISTERT_NAAR(l1)   lpiet (LUISTERT_NAAR(lpiet)  lpiet.persoon = “Piet”   l2 (LUISTERT_NAAR(l2)  l2.persoon = l1.persoon  l2.station = lpiet.station)) } l1.persoon Piet Joost

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

Safe expressions (1/3) { t |  EMPLOYEE(t) } wat komt hier zoal uit? –(“E6”, “Nick”, “ ”, “D2”) –(“D1”, “engineering”, ) , 96398, “y&$q!%”) alles, zolang het maar geen EMPLOYEE tupel is

Safe expressions (2/3) Het domein van een tupelcalculus-query { (t 1.A 1, t 2.A 2, …, t n.A n ) | CONDITIE(t 1, t 2, …, t n ) } is de verzameling van: –alle waarden van constanten die voorkomen in CONDITIE –alle attribuutwaarden van tupels die voorkomen in een relatie die voorkomt in CONDITIE

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

Thuis u nalezen: 9.3 u voorbereiden: hoofdstuk 8 (+ aanvullingen)