RĪGAS TEHNISKĀ UNIVERSITĀTEDatorzinātnes un informācijas tehnoloģijas fakultāte

Informācijas tehnoloģiju institūts

VIENKĀRŠU UN SALIKTU VAICĀJUMU ATTĒLOŠANAS DIAGRAMMASVIENKĀRŠU UN SALIKTU VAICĀJUMU ATTĒLOŠANAS DIAGRAMMAS

Izstrādāja : Angelina Kleimenova Svetlana Kleimenova

Pārbaudīja : doc. Eiduks

2004./2005. m.g.

SATURSSATURS

Ievads...............................................................................................................................................3

1. Vienkāršu SQL vaicājumu attēlošanas diagrammas....................................................................5

Vaicājuma pilnas diagrammas.........................................................................................................5

Attēlota informācija vaicājumā diagrammās...................................................................................5

Mezgli...........................................................................................................................................5

Saites.............................................................................................................................................5

Pasvītroti skaitļi............................................................................................................................6

Nepasvītroti skaitļi........................................................................................................................6

Kas netiek iekļauts vaicājumā diagrammās.....................................................................................7

Izvelēs saraksti..............................................................................................................................7

Kārtošana un savienošana.............................................................................................................7

Tabulas nosaukumi.......................................................................................................................7

Sīkas savienojuma noteikumi.......................................................................................................7

Tabulas absolūtie izmēri (pretstats relatīviem).............................................................................7

Filtrācijas noteikumu sīkumi........................................................................................................8

Kad vaicājumu diagramma palīdz vislabāk.....................................................................................8

Abstrakta demonstrēšana vaicājumu diagrammas izmantošanas....................................................8

Vaicājumu diagrammas izveidošana...............................................................................................9

Sarežģītāks piemērs.......................................................................................................................11

Savienojuma attēlošana pie pirmās centrālas tabulas....................................................................12

Centrālas tabulas apmaiņa un atkārtošana.....................................................................................13

Filtrācijas un savienojumu koeficientu aprēķinājums...................................................................14

Saīsinājumi....................................................................................................................................16

Vaicājumu diagrammu interpretācija............................................................................................17

Vaicājumu diagrammas vienkāršošana..........................................................................................18

2 . saliktu vaicājumu attēlošanas diagrammas...............................................................................21

Neparastas savienojumu diagrammas............................................................................................21

Ciklisku savienošanas grafi...........................................................................................................21

1.gadijums. Divas galvenās tabulas ar attiecību ”viens-pret-vienu” kopīgi izmanto vienu un to

pašu daļēju tabulu..........................................................................................................................21

2

Gadījums 2. Galvena un detalizētai tabulai glabājas ārējas atslēga kopijas. Kuri norada uz

vienu un to pašu primāro atslēgu 3 tabulas....................................................................................23

Gadījums 4. Salikts savienojums no divām ārējam atslēgām pie saliktam primāram atslēgām

sadalītas uz divām tabulām............................................................................................................25

Nesaistītie vaicājuma diagrammas................................................................................................27

Vaicājuma diagrammas ar dažiem saknes mezgliem....................................................................28

Gadījums 1. Trūkušais savienojuma noteikums.........................................................................29

Gadījums 2. Dekarta reizinājuma sadalīšana uz dažādiem vaicājumiem...................................29

Gadījums 3. Attiecības ar saknes daļējam tabulām ne vairāk ka “viens-pret-veinu”.................30

Gadījums 4. Eksistēšanas pārbaudīšanas transformēšana uz skaidru apakšvaicajumu..............31

Savienojums bez primāram atslēgām............................................................................................31

Savienojums “viens-pret-vienu” ar apakškopas tabulu..............................................................32

Tieši savienojumi “viens-pret-vienu”.........................................................................................32

Savienojums “viens-pret-vienu” ar daudz mazāko datu kopu....................................................33

Savienojumi “viens-pret-vienu” ar noslēptiem savienojuma filtriem abos virzienos................34

Vienošana “viens-pret-vienu” savienojumu attēlošana..............................................................34

Ārēji savienojumi..........................................................................................................................36

Filtrētas ārēji savienojumi..........................................................................................................36

Ārējas savienojuma noteikumi vienai tabulai.............................................................................37

Ārēji savienojumi, kas ved pie iekšējiem savienojumiem..........................................................38

Ārēji savienojumi, kas norada uz daļēju tabulu..........................................................................38

Ārējas savienojumi ar daļēju tabulu ar filtru..............................................................................39

Vaicājumi ar apakšvaicājumiem.................................................................................................39

Vaicājumu ar apakšvaicājumiem attēlošana uz diagrammām....................................................40

Diagrammas attēlošana apakšvaicājumu EXIST........................................................................40

Diagrammas attēlošana NOT EXIST apakšvaicājumos.............................................................46

Vaicājumu ar apakšvaicājumiem iestatīšana.................................................................47

Vaicājumi ar skatiem.....................................................................................................48

Vaicājumu diagrammveida attēlošana, kas izmanto skatus...........................................49

Vaicājumu ar skatu iestatīšana.......................................................................................51

Ārēji savienojumi ar skatēm..........................................................................................52

Lieki nolasīšanas vaicājumos kuri izmanto skatus.....................................................................54

Kopas operācijas ar vaicājumiem...............................................................................................55

3

IEVADSIEVADS

Priekš kam ir vajadzīga jauna metode?

Vaicājuma diagramma tas ir kodola iestatīšana SQL pamat elementu sintēzē un datu

atslēgas sadalīšana, nepieciešamus optimāla izpildīšanas plāna meklēšanai. Pateicoties kodola

sintēzēm mēs atmetam nevajadzīgus detaļas un koncentrējamies uz problēmas iekšienes.

Rezultātā kompaktu valodu, kuru var izmantot reālam uzdevumam. Problēmas kas var aprakstīt

ar vairākām lapām izmantojot SQL valodu, mēs attēlosim ar vienkāršu diagrammu uz lapas

pusēs. Papild priekšrocība ir tas kā vaicājumu diagramma ir vērtīgs līdzeklis veselu klašu

nepamanītu loģisku kļūdu meklēšanai pielikumos kuras nav viegli ieraudzīt testēšanas laikā, tā

kā tas ierodas diezgan rētas un sarežģītas gadījumos.

4

1. VIENKĀRŠU SQL VAICĀJUMU ATTĒLOŠANAS DIAGRAMMAS1. VIENKĀRŠU SQL VAICĀJUMU ATTĒLOŠANAS DIAGRAMMAS

Vaicājuma pilnas diagrammas

Piemērā 1 ir paradīts vienkāršais vaicājums, kurš attēlo vaicājumā diagrammas visi nozīmīgi elementi.

Piemērs 1: Vienkāršais vaicājums ar vienu saite:SELECT D.Department_Name, E.Last_Name, E.First_NameFrom Employees E.Departments DWhere E.Department_Id = D.Department_Id And E.Exempt_Flag = ‘Y’And D.US_Based_Flag = ‘Y’;

Šis vaicājums tiek pārveidots uz diagrammas vaicājumu, attēlā 1.1.

Att.1.1. Vaicājuma pilnas diagrammas vienkāršam vaicājumam

Vispirms aprakstīsim diagrammas katra elementa vērtību, pēc tam apskatīsim, kā izveidot diagrammu, izmantojot SQL kodu.

Attēlota informācija vaicājumā diagrammās

Tas kas paradīts attēlā 1, ir nepareizs grafs. Tas ir mezglu un saites kopā, turklāt saites bieži tiek apzīmēti ar bultiņām, kas parada novirze. Mezgli diagrammā attēloti ar burtiem E un D. Blakus ar mezgliem un katras saites abām galam ir skaitli, kas parada mezglu un saites papildīpašības. Elementi var interpretēt sekojoši:Mezgli

Mezgli attēlo tabulas vai tabulas pseidonīmu FROM nodaļā- mūsu gadījuma tas ir pseidonīmi E un D. Var saīsināt tabulas nosaukumi vai pseidonīmi, ka jums būs ērtāk, ja tikai tas neizsauks divnozīmīgumu vai nesaprašanu.Saites

Saites attēlo savienojumi starp tabulām, bet virzīta saite nozīme, ka savienošana garantēti dabūs unikālo vērtību tajā tabulā kuru norada saitē.

Dotā gadījuma Department_ID – primāra atslēga tabulā Departments, tāpēc saitē ir bultiņa galā kura novirzīta uz D mezgli. Tā kā Department_ID nav unikāls tabulā Employees citas saites galā bultiņas nav.

5

Vienmēr jāattēlo saites kuri sastāv no vienas bultas, tā lai bultiņa tika novirzīta lejup. Jā tā būs novirzīta uz lēju būs vieglāk lasīt plānus, kur galvenās tabulas vienmēr atrodas zem daļējam tabulām.

Kaut gan jūs varat uzminēt ka Department_ID tas ir primārais atslēgs tabulai Department. SQL ne deklarē atklāti, kurās saites pusē ir primārais atslēgs un kurā ir ārējais atslēgs. Ir nepieciešams pārbaudīt indeksus vai deklarēti atslēgas, lai pārliecināties ka Department_ID ir garantēti unikāls tabulā Departments.Pasvītroti skaitļi

Pasvītroti skaitļi blakus ar mezgliem apzīmē katras tabulas rindu daļu, kuri apmierina filtrācijas noteikumiem dotai tabulai. Zem noteikumiem saprata noteikumi kas atteicas tikai konkrētai tabulai SQL diagrammā.

Uz zīmējuma 1, rindas 10 % Employees tabulā apmierina noteikumam Exempt_Flag = ‘Y’, un rindas 50% Departments tabulās apmierina noteikumam US_Based_Flag = ‘Y’. Dotas daļas nosaukums ir filtrācijas koeficienti.

Bieži vienai vai vairākām tabulām vispār netiek noradīti filtrācijas noteikumi. Dotā gadījumā filtrācijas koeficientam (R) jāizmanto vērtību 1.0, tā kā rindas 100% apmierina (neeksistējošiem) filtrācijas noteikumiem dotai tabulai.

Līdzīgas gadījumos parasti nav obligāti attēlot filtrācijas koeficientu diagrammā. Dota skaitļa neesamība nozīme R=1.0 dotai tabulai. Filtrācijas koeficients nevar būt lielāk par 1.0. Var aptuveni uzminēt filtrācijas koeficenta vērtību iepriekš zinot kas rada tabulas un ailes.

Jā ir pieejami reālu datu sadalījumi, var atrast filtrācijas koeficentu precīzas vērtības, vienkārši iegūšot un analizējot šos datus. Apskatiet katru filtrētu tabulu ar filtrācijas operatoru kas atteicas tikai uz šo tabulu, kā vientabulas vaicājums un meklējiet filtrus noteikumu selektivitāte.

Fāzes pielikuma izstrādāšanas laika mēs nevaram vienmēr precīzi zināt kādas filtrācijas koeficienti jāsagaida, pielikumus strādāšanas laikā uz reālu datu apjomam. Šajā gadījuma jāveic vērtējumu pamatojoties uz strādājoša pielikuma. Nepasvītroti skaitļi

Nepasvītroti skaitļi blakus ar saites abām galam attēlo atrastu vidējo rindu skaitu tabulā uz šo saites galā attiecīgai rindai citas saites galā. Tas nosaukums savienošanas koeficienti.

Savienošanas koeficients savienojumā sakumā, tas ir daļēju savienojumu koeficients, uz šo savienojumā galā(ar bultiņām) – galvenais savienošanas koeficients.

Galvenās savienošanas koeficienti ir vienmēr mazāk vai vienādi 1.0, tā kā unikālais atslēgs garantē dažādu galvenu rindu atrašanu vienai detaļai. Bieži ir tādi gadījumi kad deļejai tabulai ārējais atslēgs ir obligāts un atsauces datu integritāte ir ideāla, tad galvenais savienošanas koeficients ir precīzi vienāds ar 1,0.

Daļēji savienošanas koeficienti var būt vienādi ik vienām ne negatīvam skaitlim. Tas var būt mazāk par 1,0, tā kā dažādas tabulas attiecības atļauj nulles eksistēšanu vienai vai vairāku dļāju rindu, turklāt biežāk satika gadījums “viens-pret-nulles”.

Pievērsiet uzmanību ka dotā piemēra Employees vidējai rindai ir attiecīga rinda(ar kuru tā it saistīta) Departments tabulā uz 98% gadījumos, tad kad vidēja rinda Departments atteicas 20 Employees rindām.

6

Kas netiek iekļauts vaicājumā diagrammās

Izvelēs saraksti

Vaicājumu diagramma neiekļauj stabiņu sarakstus un izteiksmes, kurus izvēla vaicājums. Vaicājuma ražotspēja praktiski pilnīgi tiek definēta ar to, kādas rindas tiek izvelētas no datu bāzes, un kāda veida tas tiek iegūtas. Ko jūs darāt ar rindām, stabiņam un tabulām, tas praktiski nenozīmīgi ražotspējai.

Galvenais izņēmums, kad jūs izvēlāties tik mazs ailes no tabulas, kā datu bāze var izpildīt vaicājumu, izmantojot tikai dati no indeksa negriežoties pie pamat tabulai. Dažreiz pieeja tikai pie indeksiem var ietaupīt resursu, bet tas vāji ietekme uz lēmumu, kuru jūs pieņēmāt attiecīgi izpildes plāna paliktai daļai.

Pieņemot lēmumu vai ir nepieciešams mēģināt tikai indeksa pieeju, jātaisa tikai pēdējā iestatīšanas procesā brīdī un tikai tad kad labākais plāns bez šis stratēģijas pielietošanas izradas pārāk lēns.

Kārtošana un savienošana

Diagrammā trūkst jebkuras noradījumi uz kārtošanu (Order BY), grupēšanu (Group By) un filtrēšanu pēc grupēšanas (Having). Dotam operācijām praktiski nav nekādas lielas nozīmes vaicājuma ražotspējai. Kārtošanas solis, kurš parasti tiek iekļauts, var ietekmēt uz izpildīšanas ātrumu, bet lai izmanīt to vērtējumu, nedaudz ko var izdarīt. Tas vērtējums parasti nav tik liels ja salīdzināt ar ražotspēju slikti izpildāma vaicājuma.

Tabulas nosaukumi

Vaicājumā diagrammas tabulas nosaukumi parasti tiek aizvietoti ar pseidonīmiem. Ja jums ir nepieciešama tabulas statistika, lielāka daļa parejos sīkumos nav nozīmīgi iestatīšanas problēmai. Piemērām, nav nozīmes no kādas tabulas vaicājums nolasa datus vai kādas realitātes glabās tabulās. Galu galā jums jāmāk transformēt rezultātu atpakaļ uz darbībām izejošā SQL un datu bāzē. Tomēr kad jūs risināsiet abstrakto iestatīšanas problēmu, tad jo abstraktāk būs mezgli nosaukumi, jo labāk.

Analoģiski, kad jūsu mērķis ir pareizi pievienot skaitļu kartībā, tad nav starpības vai jūs strādājat ar inventāru sarakstu elementiem vai slimnīcas pacientiem. Jo abstraktāk jūs apskatāt problēmu, jo skaidrāk tā kļūst, un jo skaidrāk jūs redzat analoģijas ar līdzīgam problēmām, satīkamas agrāk, kuras iespējams strādāja ar citam realitātēm.

Sīkas savienojuma noteikumi

Daļējas savienošanas noteikumos tiek zaudēti, kad savienojumi tiek pārstāvēti kā parastas bultas ar skaitļu pāri, iegūtos aiz SQL robežām. Ja ir zināma savienojumu statistika, tad sīkumi nav svarīgi.

Tabulas absolūtie izmēri (pretstats relatīviem)

Diagramma neattēlo tabulas izmērus, bet jūs varat izdarīt pieņēmumu par tas izmēru, izejot no daļēji savienošanas koeficienta, kurš atrodas pie augšēja saites gala. Kad ir vaicājuma diagramma, jums nepieciešams zināt kopīgas tabulas izmēri, lai noskaidrot cik rindas būs atgrieztas un cik laiku aizņem vaicājuma izpildīšana. Bet dota informācija nav vajadzīga relatīva laika noskaidrošanai dažādu variantu izpildīšanai un sekojoši labāka varianta

7

meklēšanai. Tas ir lietderīgs rezultāts, jo nepieciešams sasniegt labu vaicājuma izpildīšanu, ne tikai uz vienā datu bāzes eksemplāra, bet pilna eksemplāru diapazonā pircēju kopai.

Dažādiem pircējiem var eksistēt dažādu absolūtu izmēru tabulas, bet relatīvi izmēri parasti izmaiņas nebūtiski, bet savienošanas un filtrācijas koeficienti vēl mazāk. Tas izmainās tik nebūtiski, jo starpības var ignorēt.

Filtrācijas noteikumu sīkumi

Filtrācijas noteikumus sīkumi tiek zaudēti, kad tas tiek apstraģētas līdz parastiem skaitļiem. Var izvelēt optimālo ceļu pie datiem. Ir nepieciešams zināt tikai cik efektīvs ir katrs filtrs skaitliskā attiecībā uzdotu mērķu sasniegšanai rindu izņēmumam. Kad tiks atrasts šis abstraktais optimālais plāns, būs nepieciešams atgriezties pie sīkam filtrācijas noteikumiem, lai saprast kas nepieciešams izmainīt. Var izmainīt indeksus optimālas ceļa sasniegšanai, vai izmainīt SQL kodu, lai piespiest datu bāzi izmantot jau esošus indeksus, jeb kura gadījumā šis fināla solis ir vienkāršs, ja jūs jau ziniet, kad ir optimālais abstraktais plāns.

Kad vaicājumu diagramma palīdz vislabāk

Ja visi vaicājumi būtu divpusīgie savienojumi, mēs varētu tikts bez vaicājuma diagrammām. Bet reālās pielikumos sešas vai vairākas tabulas savienojumi un pat 20 un vairāk var satikt ļoti bieži. Līdzīgi daudzskaitļu savienojumi tiekas starp vaicājumiem, kuras būs nepieciešams iestatīt, tā kā sarežģīti vaicājumi prasa rokas iestatīšanu.

Jo pilnāk normalizēta datu bāze un jo sarežģītāk lietotajā interfeiss, jo ticamāk būs nepieciešams strādāt ar daudzpusīgiem savienojumiem. Datu diagrammas bieži dod vēl vienu priekšroku. Ar diagrammām ērtāk ģenerēt praktiskie uzdevumi.

Abstrakta demonstrēšana vaicājumu diagrammas izmantošanas

Tagad apskatīsim, ka izmantot vaicājuma diagrammu zīmējumā 1. attiecīga vaicājuma sīkai iestatīšanai, īpaši labākas savienošanas kartības meklēšanai.

Labākais izpildes plāns, vairākām daudzskaitļu tabulas vaicājumiem iekļauj indeksētu pieeju pie pirmās tabulas, pēc kuras seko iekļautus ciklus griešana pie pārējam tabulām, un dotie cikli izmanto indeksus pēc attiecīgam savienošanas atslēgām, kāda optimāla savienojuma kartībā.

Viss nopietnākais rezultāts, kuru mums nepieciešams sasniegt tas ir ātrais veids labākas savienošanas kartības. Pirms sarežģītas optimizācijas procesa savienošanas kartības apskatīšanas ar vaicājumu diagrammas izmantošanu, apskatīsim ka attēlā 1.1. diagramma var pateikt par abas kartības salīdzināmu vērtību divpusīgām savienojumam. Ar lielu precizitāti vērtējums tikai indeksētas pieejas ar iekļautu cikli proporcionāla rindu skaitām, kuras saņem datu bāze, tāpēc vaicājuma vērtējums tiks aprēķināts pamatojoties uz salasīto rindu skatā.

Jā sākt no pakļauta E mezgla, būs neiespējams uzzināt absolūtu vērtību (jā ne izdarīt pieņēmumu par rindu skaitu dotai tabulai). Bet šis vērtības nav diagrammā, tādēļ paņemsim kādu vērtību C un apskatīsim sekas formāli.

1. Izmantojot indeksu uz E filtrā, datu bāzei jāsaka ar 0,1 x C rindas iegūšanas no vadošas E tabulas.

2. Sekojot iekļautam ciklam pēc D galvenās tabulās virzienā , galvenais savienošanas koeficients parada , kā datu bāze saņems 0,1 x C x 0,98 rindas no D.

3. Summējot 1 un 2 soļu rezultāti iegūsim kopējo rindu skaitu no abām tabulām : (0,1 x C) + (0,1 x C x 0,98).

4. Iznesīsim aiz iekavām C un 0,1 no abām izteiksmēm. Datu bāzei iegūtais kopējais rindu skaits ir vienāds C x (0,1 x(1+0,98)) vai 0,198 x C.

8

Sakot no pretējā savienojuma galā , tāpat attēlosim vērtējums caur C, bet uzdosim caur C izmērs D. Ziņojot D izmēru, izteikts caur C, vaicājumu vērtību C terminos aprēķināsim sekojoši:

1. Katrai rindai no D datu bāze atrod aptuveni 20 rindas uz E, kas attēlo daļēju savienošanas koeficientu. Tomēr tikai rindu 98% uz E principā ir piemēroti rindām no D, tādēļ C kopīgam rindu skaitam jābūt uz 20/0,98 vairāk, neka rindu skaitam iegūtam no D. Sekojot no tā iegūto rindu skaits no D vienāds ar C X 0,98/20.

2. Izmantojot indeksu tikai filtrētu rindu iegūšanai no D, mēs iegūsim rindas pusi no vadošas tabulas, vai C x 0,5 x 0,98/20.

3. Savienošanas izpildes laika ar E datu bāze saņem 20 reizes vairāk rindas no tabulas, t.i. 20 x C x 0,5 x 0,98/20 vai C x 0,5 x 0,98.

4. Summējot rindu skaitu no divām tabulām un iznest aiz iekavām kopējus reizinātājus , iegūsim kopīgu vērtējumu: C x (0,5 x 0,98 x((1/20)+1)) vai 0,5145 x C.

Absolūts vērtējums mūs neinterese. Mūs interese attiecīgais, tādēļ labākais plāns var izvelēt izejot no tā, kā kāds nebūtu C, 0,198 x C vienmēr būs mazāk 0,5145 x C. Vaicājumu diagrammā ir visa informācija, kas nepieciešams zināt: ka plāns kas sākas ar E un pievieno D būs apmēram 2,6 reizes ātrāk neka plāns kas sākas ar D un pievieno E. Visgalvenākais kas nepieciešams atcerēties, kā vaicājumu diagramma atbild uz pamatjautājumiem, kas attiecās vaicājumu optimizēšanai.

Vaicājumu diagrammas izveidošana

Tagad ir zināms kas ir vaicājumu diagramma. Apskatīsim diagrammas izveidošanas metodi pamatojoties uz SQL operatoram.

1. Jāsaka ar patvaļīgi izvelētu tabulas pseidonīmu no nodaļas FROM un ievietojiet to tukša lapa pa vidu. Dotu tabulu sauksim par centrālu tabulu, tā būs tekošais punkts, sakot no kuras mēs pievienosim parēji elementi vaicājumu diagrammā. Mūsu piemēra par sākuma punktu paņemsim E pseidonīmu.

2. Atradiet savienošanas noteikumi, attiecīgas vienīgai vērtībai centrālas tabulās primāra atslēga. Katram tādam savienojumam uzzīmējiet bultu virzītu uz leju, uz centrālo tabulu , ievietojot ar pseidonīmu bultas sākumu pretējā savienojuma pusē(parasti var atrast maksimums vienu savienojumu ar tabulu augšup). Ja saite pārstāv ārējo savienojumu ievietojiet saites vidē bultu, virzīto uz papildtabulu.Mūsu piemērā savienošanas ar tabulas Employees primāro atslēgu, iespējami nav Employee_ID. Ja jūs gribat pārliecināties , kā Department_ID ir Employees primāra atslēga pietiekami labs nosaukums, tad var pārbaudīt nosauktas primāras atslēgas un tabulas indeksus. Ja ir šaubas ka savienojums ir patiešam unikāls, bet datu bāzes izstrādātājs ne pasludināja un neiekļauj unikalitāte ar pasludināto atslēgu vai indeksa palīdzību, tad var pārbaudīt unikalitāte ar SELECT COUNT (*), COUNT (DISTINCT Department_ID) FROM Employees; palīdzību. Bet parasti var strādāt izmantojot savas pašas minējumus, un pārbaudīt tas tikai kad tas strādās sliktāk, jo nepieciešams.

3. Atradiet savienošanas noteikumu, kas meklē no centrālas tabulas ārēja atslēga pie citas tabulas primāra atslēga. Un uzzīmējiet tādam savienojumiem bultas, kas uzrada no centrālas tabulās uz lēju. Pie katras bultas zema gala uzrakstiet tabulas pseidonīmu, ar kuru tiek izveidota savienojumi. Ja saite pārstāv ārēju savienojumu, savienojumā centra iekļaujiet bultiņu, kas uzrada uz papildtabulu.

4. Apskatīsim citu mezgli diagrammā, pagaidām neapskatāmo un atkārtojiet soļi 2 un 3, kamēr nesavāksiet mezglus, kas pārstāv visi pseidonīmi nodaļā FROM, un bultas, kas pārstāv visi savienojumi. Parasti uz leju uzradis tikai viena bultiņa, tāpēc jūs meklēsiet

9

jaunus savienojumus no mezgliem, jau esošiem zemā savienojuma galā, kas uzrada uz leju.

5. Aizpildot visus mezglus, uzrakstiet skaitļi filtrācijas koeficientiem un savienošanas koeficientiem, pamatojoties, ja ir iespējams uz tabulas sintaksi industriālām pielikumam. Ja jums nav industriālus datus, tad pamēģiniet uzminēt pēc iespējas precīzāk. Nav nepieciešamības pievienot savienošanas koeficientus blakus ar saitēm, kas pārstāv arēji savienojumi. Praktiski vienmēr papildtabulas ārēja savienojuma( galā ar zīmi (+) savienojuma, veca Oracle ierakstā, vai jaunā stilā uzreiz pēc atslēgs vārda LEFT OUTER) filtrācijas noteikumi nav uzradīti, tāpēc filtrācijas koeficients it vienāds ar 1.0, kas nozīme skaitļa neesamību diagrammā.

6. Uzzīmējiet zvaigznīti blakus ar filtrācijas koeficientu visiem filtriem, kuri garantēti atgriež maksimums vienu rindu. Lai garantēt , ka atgriezts rindu skaits būs vienāds ar 1, ir neieciešams būt unikālām indeksam vai pielikuma saprotami ierobežojumi, kuri dod reālu garantiju.

Ja jums ir īstie dati, izmantojamas pielikuma darbībai, tad tas ir ideāls filtrācijas un savienošanas koeficientu avots.

Piemērā 1, lai precīzi noteikt šie koeficienti, ir nepieciešams izpildīt sekojoši vaicājumi (no Q1 līdz Q5):

Q1: SELECT COUNT (*) A1 FROM Employees WHERE Exempt_Flag =’Y’;A1: 1000

Q2: SELECT COUNT (*) A2 FROM Employees; A2: 10000

Q3: SELECT COUNT (*) A3 FROM Departments WHERE US_Based_Flag =’Y’;A3: 245

Q4: SELECT COUNT (*) A4 FROM Departments;A4: 490

Q5: SELECT COUNT (*) A5 FROM Employees E. Department D WHERE E.Department_ID =D.Department_ID;A5: 9800

Vērības no A1 līdz A5 tas ir vaicājuma atgriezti rezultāti, tāpēc nepieciešams izpildīt sekojošas matemātiskas darbības.

- Lai atrast filtrācijas koeficientu E mezglam, atradiet A1/A2 vērtību.- Lai atrast filtrācijas koeficientu D mezglam, atradiet A3/A4 vērtību .- Lai atrast daļēju savienošanas koeficientu, atradiet A5/A4 vērtību, ar citam

vārdiem nefiltrēta savienojuma atgrieztu rindu skaitu sadalīt ar atgriezto rindu skaitu no centrālas tabulas.

- Lai atrast galveno savienošanas koeficientu, atradiet A5/A2 vērtību, ar citiem vārdiem nefiltrēta savienojuma atgrieztu rindu skaitu sadalīt ar atgriezto rindu skaitu no daļēju tabulas.

Piemēram, vaicājuma Q1-Q5 izpildes rezultātā iegūtas vērtības 1000,10 000, 245, 490 un 9 800. Sanāca tieši filtrācijas un savienojuma koeficienti no attēlā 1.1., ja sareizināt visi rezultāti ar vienu konstanti, iegūsiet tādi paši koeficienti.

10

Sarežģītāks piemērs

Tagad apskatīsim diagrammas attēlošanu pietiekami lielam vaicājumam. Piemērā 2 , kur var redzēt ārējas savienošanas Oracle stilā.

Piemērs 2. Sarežģītāks piemērs ar 8 tabulas savienojumiem.

SELECT C.Phone_Number, C.Honorific, C.First_Name, C.Last_Name, C.Suffix, C.Address_ID, A.Address_ID, A.Street_Address_Line1, A.Street_Address_Line2, A.City_Name, A.State_Abbreviation, A.ZIP_Code, OD.Deferred_Shipment_Date, OD.Item_Count,

ODT. Text, OT. Text, P.Product_Description, S.Shipment)DateFROM Order O.Order_Details OD, Products P, Customers C, Shipment S,

Address A, Code_Translations ODT, Code_Translations OTWHERE UPPERS (C.Last_Name) LIKE : Last_Name ||’%’ AND UPPER (C.First_Name) LIKE : First_Name || ‘%’ AND OD.Order_ID = O.Order_ID AND O. Customer_ID = C. Customer_ID AND OD.Product_ID= P.Product_ID(+) AND OD.Shipment_ID= S.Shipment_ID(+) AND S.Address_ID= A.Address_ID(+) AND O. Status_Code = OT.Code AND OT.Code_Type =‘ORDER_STATUS’ AND OD.Status_Code = ODT.Code AND ODT. Code_Type = ‘ORDER_DETAILS_STATUS’ AND O.Order_Date> :Now –366ORDER BY C. Customer_ID, O.Order_ID DESC, S.Shipment_ID, OD.Order_Detail_ID;

Kā agrāk, nepieciešams ignorēt visas vaicājuma daļas, izņemot SELECT un WHERE sekcijas. Visam tabulām intuitīvi saprotami primāru atslēgu nosaukumi izņemot Code_Translations tabulu, kuras primārais atslēgs sastāv no divām daļam (Code_Type, Code) .

Kad jūs cenšas atrast vienkāršas tabulas vienādības noteikumu pēc primāra atslēga , tā kā vaicājumā pēc Code_Tranlations, šo noteikumu jāuzskata par savienošanas noteikuma daļu, nevis filtrācijas.

Ja jūs apstrādājiet vienkāršas tabulas noteikumu kā savienojumu daļu, tad parasti apskatāt fizisku tabulu ar divām vai vairākām loģiskam apakštabulām. Dotas fiziskas tabulas, kurās glabās savienotas realitātēs. Vaicājuma optimizēšanai uz dotas apakštabulas mūs interese statistika pēc atsevišķas apakštabulas pie kuras pavēršas vaicājums. Tādēļ izpildiet visus vaicājumus statistikai, pēc tabulām, pievienojot noteikumu ar interesējošo apakštabulu, un neaizmirstiet vaicājumu kopīga rindu skaitām (SELECT COUNT (*)FROM <Tabula>),kurš pārvēršas dota piemērā uz piemēroto rindu skaitu vaicājumu(SELECT COUNT (*)FROM Code_Translations WHERE Code_Type = ‘ORDER_STATUS’).

11

Savienojuma attēlošana pie pirmās centrālas tabulas

Solis 1. Ievietojiet O pseidonīmu diagrammas centrā. Solis 2. Atradiet visi savienojumi O tabulā ar primāro atslēgu O.Order_ID. Nepieciešams atrast savienojumu no OD, kas attēloti zīmējumā 1.2., kā virzīta lejup bulta no OD uz O. Lai neaizmirstu ka savienojums ir jau attēlots, jāizsvītro to no vaicājumā.

Att.1.2.Diagrammas sākums 2 piemērām

Savienojuma attēlošana Savienojuma attēlošana nono pirmās centrālas tabulas pirmās centrālas tabulas

Solis 3. Atradiet visi ārējie savienojumi (ne uz Order_ID, bet pie ārējam atslēgām) ar Orders un ievietojiet tas diagrammā ka bultas, virzītas lejup no O uz C un OT, tā kā doti savienojumi izmanto primāri atslēgas Customers un Code_Translations. Tagad diagramma izskatās ka attēlā 1.3.

Att.1.3. Solis 3 .

12

Centrālas tabulas apmaiņa un atkārtošana

Dota momentā apstrādāti visi savienojumi, izejošie no tabulas O. Lai neaizmirst, kāda daļā jau ir izveidotā, izsvītrojiet O FROM frāzē un jau attēlotus diagrammā savienojumus.

Solis 4. Nepieciešams atkārtot solis 2 un 3. ar jaunu centrāla tabulu. Ja pēc kārtas izvelēt par centrālo tabulu katru tabulu diagrammā, tad izveidosiet diagrammu pareizi neskatot uz secību.Bet var ietaupīt laiku izmantojot noteikumus:

- Vispirms cenšaties pabeigt diagrammas augšējas daļas, sāksiet ar OD.- Izmantojiet vel neuzzīmētus savienojumus, lai atrast jaunu centrālu tabulu. Vēl

neizsvītrotu savienojumu saraksta pārbaude dod mums sekojošu potenciālu kandidātu sarakstu: OD, P, S, A un ODT. Tomēr tikai OD atrodas diagrammā, tāpēc tikai šo mezgli var izvelēt par centrālu un paplašināt diagrammu. Ja jūs pamanījāt kā ar C un OT tabulām vairs nebūs savienojumus, tos jāizsvītro no FROM frāzēs, jo tālāk tas neprasa apstrādes.

Elementus jāattēlo tā lai jums būtu vieglāk, pēc jūsu uzskatīšanas.

Netika atrasti savienojumi ar primāro atslēgu Order_Details (pie OD.Order_Detail_ID), tāpēc visas saitēs no OD uzrāda lejup uz P, S un ODT, kuri ir saistītu ar OD ar savam primāram atslēgām. Tā kā S un P ir papildtabulas ārēja saitēs, šo saites vidū pievienojiet virzītas uz leju bultas. Izsvītrojiet no OD savienojumus, kuri attēloti ar dotām trim saitēm. Tagad palika tika viens savienojums ārējais savienojums no S uz A primāro atslēgu.

Tādēļ jāizvēlas pēdējo reizi centrālo tabulu , šoreiz S un pievienot vienu pēdēju bultu virzītu lejup uz A ar bultu pa vidu, apzīmējošo šo ārējo savienojumu. Izsvītrojiet pēdēju savienojumu. Visi pseidonīmi un savienojumi jau diagrammā.

Ja vaicājums izmanto Dekartu savienojumu, jāpārbauda vai nepalika pseidonīmi kuriem nav savienojumu noteikumus.

Ja viss izdarīts pareizi savienojumiem diagrammā jāizskatās kā attēlā 1.4. Pēc kodola izveidošanas jāieraksta skaitļi, kas pārstāv vajadzīgu skaitļu sadalīšana datu bāzē, kā aprakstīts 5. solī diagrammas attēlošana.

Att. 1.4. Vaicājuma kodols.

13

Filtrācijas un savienojumu koeficientu aprēķinājums

Ārēja savienojuma papildtabulām mums nav filtrācijas noteikumus, tāpēc nav vajadzīga statistika. Maldinoši filtrācijas noteikumi OT.Code_Type = ‘ORDER_STATUS’ un ODT.Code_Type = ‘ORDER_DETAIL_STATUS’ neveica filtrāciju tīra veida, bet attiecas pie savienojumiem ar attiecīgām tabulām. Jo ir savienojumu atslēga daļai šī tabulas pieejai. Tad paliks tikai filtrācijas noteikumi pēc pircēja vārda un pasūtījuma datuma.

Noteikumu selektivitāte pēc vārdiem un uzvārdiem ir atkarīga no attiecīgu šablonu garuma. Aprēķiniet selektivitāte, pieņemot, kā parametri :Last_Name un :First_Name parasti ir piesaistīta pie katra vārda pirmām 3 burtām, un kā lietotāji izveido meklēšanu pēc izplatītām trīs burtu rindām proporcionāli biežāk, nekā pēc bieži satīkamām. Tas piemērs paredzēts Oracleizmantojiet izteiksmi Oracle SUBSTR(Char_Col,1,3) pirmos trīs simbolu vērtības atgriešanai no katra simbolu ailes.

Ja vaicājums izmanto pasūtījuma stāvokļa kodu, kāda savienošanas nosacījuma, tad vajadzētu pieprasīt no Code_Translations rindu skaitu pasūtījuma stāvoklim. Tikai tabulas rindas tipiem, kas piedalās vaicājumā, būtiski ietekme uzvaicājumu vērtējumu. Var būt būs nepieciešams aptaujāt vienu tabulu divas reizes, bet dažādām apakškopām.

Piemērs 3 apjauta Code_Translations vienu reizi, lai saskaitīt pasūtījuma stāvokļa kodus, vēl reiz, lai saskaitīt pasūtījuma kodus detaļās stāvokli. Vaicājumi piemērā 3. iegūst visi dati, nepieciešamas savienošanas un filtrācijas koeficientu aprēķināšanai.

Piemērs 3. Statistikas vaicājumi vaicājuma iestatīšanai:

Q1 SELECT SUM(COUNT(8)*COUNT(*))/(SUM(COUNT(*))*SUM(COUNT (*)))A1FROM Customer

GROUP BY UPPER (SUBSTR(First_Name, 1,3)), UPPER ( SUBSTR (Last_Name, 1,3));A1 0,0002

Q2 SELECT COUNT(*) A2 FROM Customers;A2 5000000Q3 SELECT COUNT(*)A3 FROM Orders

WHERE Order_Date >SYSDATE –366;A3 120000

Q4 SELECT COUNT (*) A4 FROM Orders;A4 4000000

Q5 SELECT COUNT (*)A5 FROM Orders O, Customers CWHERE O.Customer_ID =C.Customer_ID;

A5 4000000

Q6 SELECT COUNT(*)A6 FROM Order_Details;A6 12000000

Q7 SELECT COUNT (*) A7 FROM Orders O, Order_Details ODWHERE OD.Order_ID=O.Order_ID;

A7 12000000

Q8 SELECT COUNT(*) A8 FROM Code_TranslationsWHERE Code_Type = ‘ORDR_STATUS’;

14

A8 4

Q9 SELECT COUNT (*) A9 FROM Orders O, Code_Translations OTWHERE O.Statud_Code = OT.CodeAND Code_Type=’ORDER_STATUS’;

A9 4000000

Q10 SELECT COUNT (*) A10 FROM Code_TranslationsWHERE Code_Type = ‘ORDER_DETAIL_STATUS’;

A10 3

Q11 SELECT COUNT(*) A11 FROM Order_Details OD, Code_Translations ODTWHERE OD.Status_Code=ODT.CodeAND Code_Type =’ORDER_DETAIL_STATUS’;

A11 12000000

Sākot ar filtrācijas koeficientiem, iegūsim vidēji suspendēts filtrācijas koeficientu noteikumam pircēja vārds un uzvārds(Customers tab.) taisni no A. Vaicājuma rezultāts ir 0,0002.

Atradīsim Orders filtrācijas koeficientu kā A3/A4, rezultātā iegūsim 0,3. Tā kā citiem pseidonīmiem filtru nav, tas filtrācijas koeficienti vienādi ar 1,0, kurus nav nepieciešamības attēlot diagrammā.

Atradiet daļēju savienošanas koeficientus un ievietojiet tas pie visas bultas augšēja galā iekšējām savienojumam. Lai to izdarīt jāsadala pēc divas tabulas apvienošanas iegūtas rindas skaitu uz rindu skaitu apakšā tabulā. Koeficienti savienošanai no OD uz O un ODT vienādi ar 3(A7/A4) un 4 000 000 (A11/A10).Diagrammā miljoni saīsināti kā m, tūkstoši kā k.

Koeficienti savienošanai no O uz C un OT vienādi 0,8 (A5/A2) un 1 000 000 (vai 1m, A9/A8).

Atradiet visām bultām apakšgaliem galvenās savienošanas koeficientus, sadalot rindu skaitu, iegūtos no savienojuma, uz rindu skaitu augšējā tabulā. Jā ir obligāti ārējie atslēgas un ārējie atslēgas vienmēr uzrada uz primāra atslēga vērtību, tad galvenie savienošanas koeficienti vienmēr vienādi ar 1,0, kas pareizi visam gadījumam dota piemērā: A7/A6, A11/A6, A5/A4 un A9/A4.

Pārbaudiet, vai ir filtrācijas unikālie noteikumi, kurus nepieciešamas apzīmēt ar zvaigznīti (Solis 6.). Dotā piemērā tādu noteikumu nav. Pēc tam uzrakstiet visi skaitli diagrammā, kā paradīts attēlā 1.5.

Att.1.5. Pilna vaicājuma diagramma otrām piemērām.

15

Saīsinājumi

Izmantojot šos noteikumus tas palīdzēs saīsināt vaicājumu diagrammas aizpildīšanas procesu.- Noteikt kādas ailes ir primāras atslēgas, var izejot no tā nosaukuma.- Parasti var ignorēt ārējas tabulas koeficientus un piedalītās tajās papildtabulas.

Bieži ārējas savienojumi var vispār neattēlot diagrammā uz iepriekšēja varianta kurš parada ar kādu potenciālu labošanai ir vaicājums.

- Galvenais savienošanas koeficients praktiski vienmēr vienāds ar 1,0, ja tikai ārējais atslēgs nav papilds. Ja nav iemesla domāt , kā ārēja atslēga vērtība bieži vienāda ar NULL vai tas bieži uzrada uz vairāk neeksistējošam primāra atslēga vērtībām, vienkārši jāignorē tas uzraksiet vērtību 1,0.

- Dažas datu bāzēs realizēti ierobežojumi, kas stingri garantē datu atsauces integritāti. Pat bez ierobežojumiem labi izveidoti pielikumi atbalsta atsauces integritāti vai kaut praktiski pilnu integritāti savās tabulās. Jā jūs garantē vai pieļaujiet atsauces integritāti, tad varat pieņemt, kā nevienādas NULL ārēji atslēgas vienmēr uzrada uz pieļaujamam primārām atslēgām. Tāda gadījumā meklēšanas faktora meklēšanai nevajag izpildīt rindu skaita vaicājumu pievienotā tabulā. Tad jums būs nepieciešams zināt rindu procentu ar ārēju atslēgu nevienādu ar NULL un rindu skaitu divās tabulās. Lai to saskaitīt , jāizpilda līdzīgu SQL kodu:

SELECT COUNT(*) D, COUNT (<Areja_Atslega_Tabula>) F FROM <DetaLu_Tabula>;SELECT COUNT (*) M FROM <Galvena_Tabula>;

Lai rindas pirmais skaits, iegūts ar pirmo vaicājumu ir vienāds D. Otrais rindu skaits, iegūts ar to pašu vaicājumu, vienāds F. Rindu skaits, iegūts ar otro vaicājumu, vienāds ar M. Tad galvenais savienošanas koeficients vienāds ar F/D, bet daļēju savienošanas koeficients – F M.Savienošanas koeficientiem reti var būt neparedzētas vai neparastas vērtības. Parasti tos var uzminēt. Daļējais savienošanas koeficientam liela jēga ir reti satīkamos gadījumos, kad tas ir daudz mazāk par 1,0. Parasti var uzminēt pietiekami precīzi.

- Dažu vaicājumu iestatīšanas laikā no viena pielikuma atkārtoti izmantojiet datus par savienošanas koeficientus, ja apstrādājiet tādas pašas savienojumus.

- Filtrācijas koeficientiem ir pat galvenāka nozīme, bet parasti variējas dažas kartības ierobežojumā. Un jā starpība starp filtrācijas koeficientiem ļoti liela, būs pietiekams, ja jūs uzminēsiet tas lieluma kartību. Jums ne būs vajadzīga praktiski nekad ļoti liela precizitāte, nekā līdz pirmā atšķirta no nulles skaitļa. Piemēram: 043 tiek apaļots līdz 0,04, bet 472 līdz 500.Tāpat ka savienošanas koeficientiem , informēts minējums filtrācijas koeficientam, strādā viss labāk.

16

Vaicājumu diagrammu interpretācija

Eksistē lietderīga un saprotama attiecības diagrammu attēlošana starp realitātēm un vaicājumu diagrammas kodoliem. Attēlā 1.6. paradīts piemēra 1. vaicājuma kodols un attiecīga attiecību diagrammu daļā starp realitātēm.

Att. 1.6. Vaicājuma kodols salīdzinoši ar attiecību diagrammu starp realitātēm.

Attiecību diagramma starp realitātēm attēlo datu bāzes dizainu, kurš nav atkarīgs no vaicājuma. Izejoši, vaicājuma kodols, attēlo attiecību “daudz-pret-vienu”, tāpat iziet no datu bāzes dizaina nevis no vaicājuma. Vaicājuma kodols uzrada, kāda apakškopa datu bāzes uzbūve nozīmīgs dota laika momentā, tad jākoncentrējas uz dota apakškopās. Ja viena un tāda paši tabula paradās ar dažādiem pseidonīmiem, vaicājumu diagramma paplašina attiecību diagrammu starp realitātēm, uzrada dažādi savienojumi ar vienu tabulu.

Ar savienošanas koeficientu palīdzību vaicājumā kodolā jūs kodējāt faktisku datu skaitliskas raksturojums, izmantojot tas kvalitātes raksturojumu “daudz”(many) vieta attiecības diagrammā starp realitātēm. Piemērām, “daudz-pret-viens” saitēm jānorada šo “daudz” skaitu ar daļēju savienošanas koeficientu; kad satiekas saite “daudz-pret-nule vai 1”, ar galvena savienošanas koeficientu palīdzību uzradiet cik bieži nulles vērtības. Tas ir datu raksturojums, neviss datu bāzes dizaina, tas nav atkarīgi no vaicājuma. Šie savienošanas koeficienti var izmainīties dažādās datu bāzes eksemplāros, kuras izmanto vienu pielikumu ar dažādiem datiem, bet viena eksemplāra iekšā savienošanas koeficienti fiksēti visiem vaicājumiem, kas izpilda vienādus savienojumus.

Optimālais plāns parasti nav atkarīgs no savienošanas koeficientiem. Tas gandrīz vienmēr atļauj veiksmīgi iestatīt vaicājumus.

Tikai pievienojot filtrācijas koeficientus, patiešam ievērosiet raksturotus datus kādam konkrētam vaicājumam, jo filtrācijas noteikums atkarīgs no vaicājuma, nevis no datiem. Dati parada visu apakškopu visas tabulās relatīvus izmērus, kas nepieciešamas vaicājumam.

Pareizi uzrakstītiem vaicājumiem diagrammās praktiski vienmēr uz koka virsotnē atrodas tikai viena daļēja tabula, no kuras bultas uzrada lejup uz galvenam tabulām, no kuram var iziet citas bultas, attēlojoši saites starp tabulām. Ja būs tāda vaicājumu diagrammas normāla forma, tad vaicājumu pietiekami vienkārši interpretēt.

Līdzīgs vaicājums ir realitātes jautājums, atbilstošs augšas daļējai tabulai, ar vienu vai vairākām savienojumiem ar galvenam tabulām lejā, kas paredzēti tālākai datu meklēšanai par šo realitātēm, kas glabājas citas tabulas pareizai normalizācijai.

Piemērām, vaicājums kurš savieno Employees un Departmente tas jautājums par darbiniekiem. Lai atbildēt uz šo jautājumu datu bāzei jā griežas Departments tabulai un iegūt informāciju par darbiniekiem. Piemērām, Department_Name kas glabjas tabulā Departments pareizai normalizācijai. Šeit runa iet par biznesa jautājumu.

17

Jautājumi par bizness - realitātēm, pietiekami svarīgi, lai būtu atsevišķas tabulas dabīgi bizness - pielikumos. Un prasa dažu līmeņu savienojumi daļēju datu meklēšanai, kas glabās galvenās tabulās. Runājot par dīvainām realitātes kombinācijām arī nedabīgas biznesam.

Apskatot vaicājuma diagrammas, kas neatbilst normāla formām, jūs pamanīsiet, kā tas atgriež tieši bezjēdzīgi rezultāti.

Tālāk aprakstīti noteikumi paredzētas vaicājumu diagrammām, attiecīgus datu glabāšanas normāla formai.

- Vaicājumam atbilst viens koks.- Kokā ir viena sakne - tieši viena tabula bez savienojumiem ar tas primāram

atslēgām. Visam pārējam mezgliem, izņemot sakni, ir vienīga virzīta lejup, uz viņiem, bulta, savienojot viņu ar daļējo mezglu augšā, bet jebkurš mezgls var atrasties augša gala jebkura bultu skaita radoša lejup.

- Visiem savienojumiem ir bulta virzīta lejup.- Ārēji savienojumi netiek filtrēti, paredzētas viņiem bultas virzīti lejup, ārēji

savienojumi var būt tikai zem ārējiem savienojumiem.- Jautājums uz kuru atbild vaicājums, tas ir parasti jautājums par realitāti, attēlota

koka saknes mezgli (vai par tas realitātes agregāciju).- Parejas tabulas vienkārši dot uzziņu un detalizēti dati, kas glabās tajos

normalizācijai.

Vaicājumu diagrammas vienkāršošana

Daudz sīkumos uz pilnām vaicājumu diagrammām nav obligāti. Koncentrējoties uz nepieciešamiem elementiem jums vajadzīgs diagrammas kodols un aptuvenas filtrācijas koeficienti. Reti ir nepieciešami savienošanas koeficienti, parasti tikai tad kad jebkurš no daļēju savienošanas koeficientiem mazāk par 1,5 vai galvenais savienojuma koeficients mazāk par 0,9. Ja jums nav iemeslu aizdomāt ka tas ir tas pats retais gadījums. Jums nav vajadzības uzzināt rindu skaitu tabulām bez filtriem. Prakse, daudzpusīgās savienojamās ir filtri tikai 3 –5 tabulām, tāpēc pat sarežģītākais vaicājums viegli var attēlot diagrammā, neizmantojot vairāk vaicājumos statistikas vākšanai.

Neizmantojot nevajadzīgas daļas , kas bija pārskaitīti agrāk, jānovienkāršo attēlu 1.5 līdz attēlam 1.7.

Att.1.7. Vienkāršota vaicājumu diagramma

Pievērsiet uzmanību, ka daļējais savienošanas koeficients no C pie O attēlā 1.5. mazāk par 1.5, tāpēc jāattēlo to pat uz vienkāršotā diagrammā attēlā 1.7.

Runājot par filtriem, pat aptuvenas vērtības nav vajadzīgi, ja ir zināms kāds filtrs ir labāk un ja citi filtri neattiecas pie to pašu senču daļēju mezgli. Mūsu gadījumā labākais filtrs

18

apzīmēsim ar burtu F un mazo filtru ar mazo f burtu. Zīmējums 1.7. vienkāršojas līdz 1.8.zimējumā.

Att.1.8.Pilnīgi vienkāršota vaicājumu diagramma 7. zīmējumam.

Pievērsiet uzmanību, ka daļējais savienojuma koeficients no C uz O, mazāk par 1,5, tāpēc jāattēlo to pilnīgi vienkāršotā diagrammā arī (att.1.8.).

Neskatoties uz to ka filtrācijas koeficients ir nodzēst no attēlā 1.8., jāturpina zīmēt zvaigznīte blakus ar jebkuru unikālo filtru. Arī jāuzrada faktiskas filtrācijas vērtības, kas attiecas pie viena un tāda paši senču daļēju mezgli. Piemēram, ja jums ir mazie filtri B un C mezglos attēlā 1.9., jāuzrada tiem reālie filtrācijas koeficienti, kā paradīts attēlā, tā kā tiem ir kopēji senču daļējais mezgls A.

Att. 1.9. Pilnīgi vienkāršota vaicājumu diagramma ar filtrācijas koeficientu kopējam sencim.

Praksē var sākt ar vaicājuma diagrammas vienkāršošanu, pēc tam ja nepieciešams pievienot daļas. Ja izpildes plāns izpildās tik ātri, kā tālāka labošana bezjēdzīga, tad darbu var uzskatīt par pabeigtu.

Jā pēc pirmās iestatīšanas, liekas kā to jāturpina, tad varat ātri pārbaudīt, vai iespējama tālāka iestatīšana. Lai to izdarīt apskatiet vai neesat palaidusi nopietnas savienojuma koeficienti.

Ātrākais veids izdarīt to, uzdod jautājumu vai tiešam vienīgais labākais filtrs ir atbildīgs par praktiski visus samazinājumus atgrieztu rindu skaitu, salīdzinoši ar pilnīgi neatfiltrētiem vaicājumiem pie viss detalizētai tabulai. Domājot, kā savienošanas diagramma izskatās ka apgriezts koks, var gaidīt ka viss vaicājums bez filtriem atgriež to pašu rindu skaitu, ka viss detalizētāka tabula savienojuma kokā saknē (augšā).

19

Gadījumā ar filtriem jūs gaidiet, ka katrs filtrs saīsina rindu skaitu, atgrieztus no viss detalizētas tabulas uz filtrācijas koeficientu. Ja labāka filtrācijas koeficienta un viss detalizētākas tabulas rindu skaitu reizinājums aptuveni vienāds ar rindu skaitu, kuru atgriež vaicājums, tad varat būt pārliecināti kā vienkāršotas diagrammas pietiks. No citas puses ja šis reizinājums pārsniedz rindu skaitu, kuru atgriež vaicājums, tad iespējam ka ir palaists garām nopietns iemesls rindu saīsināšanas skaita un nepieciešams savākt vairāk statistikas. Jā šis reizinājums ir ļoti mazs, jāpadomā par to ka ir nepieciešams vairāk informācijas. Tas var būt noslēptas savienojumu filtri, kuras savienojumos koeficienti mazāk par 1,0.

20

2 . SALIKTU VAICĀJUMU ATTĒLOŠANAS DIAGRAMMAS2 . SALIKTU VAICĀJUMU ATTĒLOŠANAS DIAGRAMMAS

Jūs jau ziniet kā izveidot diagrammu un iestatīt vaicājumu pie reāliem tabulām, kad diagramma atbild dažam prasībām parastam bizness - vaicājumam.

- Vaicājums tiek attēlots uz vienu koku.- Kokam ir viens saknes mezgls, tas ir viena tabula bez savienojumiem ar tas primāra

atslēga izmantošanu. Visam parejam mezgliem, izņemot saknes mezgli, ir pa vienam bultām, kas uzrada lejup, uz viņiem, savienojot viņus ar daļēju mezglu augša. Jeb kurš mezgls var atrasties jebkura virzīta lejup bultu skaita augša galā.

- Visam savienojumam ir virzīti lejup bultiņas (savienojumi ir unikāli vienā galā).- Ārēji savienojumi netika filtrēti, virzīti lejup, zem ārējam savienojumiem var būt tikai

ārēji savienojumi.- Jautājums uz kuru atbild vaicājums tas parasti ir jautājums par realitāti, attēlota koka

sakņu mezglā vai tas reālitātes agregācijas.- Parejos tabulas glabās izziņu dati, kas sakārtoti dotas tabulas normalizācijas mērķiem.

Neparastas savienojumu diagrammas

Jā jūsu vaicājumā iekļautas tikai parastās tabulas (ne skati), nav apakšvaicājumu un kopas operācijas, tādas kā UNION vienmēr var izveidot vaicājuma diagrammu izmantojot metodes no iepriekšējā daļā.

Dažreiz diagrammas var būt neparastas raksturojumi, kas nepiestāv ne viena kokveida savienojuma šablonā. Tālāk tiek aprakstīts un paskaidrots, kā rīkoties ar tāda veida novirzēm.

Ciklisku savienošanas grafi

1.gadijums. Divas galvenās tabulas ar attiecību ”viens-pret-vienu” kopīgi izmanto vienu un to pašu daļēju tabulu.

Attēla 2.1. paradīts pirmais gadījums, kad vienīga ārēja atslēga tiek savienota ar divu galvenu tabulu primāram atslēgām.

Att.2.1. Pirmais gadījums vaicājuma cikliska diagramma

21

SQL kods dota gadījuma var izskatīties sekojoša veida:SELECT ...FROM ...T1, ... T2, ... T3, ...WHERE ... T1.FKey1 = T2.PKey2And T1.FKey1 = T3.PKey3And T2.PKey2 = T3.PKey3

Šeit ir vienīgais ārējais atslēgs T1 tabulas, kurš uzrada uz abām tabulām, FKey1, bet primāras atslēgas T2 un T3 – PKey2 un PKey3, atbilstoši.

Ja visi 3 savienojumi skaidri pierakstīti SQL, tad cikliski saites skaidri, bet pievērsiet uzmanību, ka viena no dotam saitēm varētu būt palaistā garām vaicājumā un savienojuma noteikumu prombūtne tiek domāta pēc tranzitivitātes noteikumu (ja a=b un b=c, tad a=c).

Ja viens no noteikumiem ir palaists, tad tādam pašam vaicājumam jūs izveidojat diagrammu vienā no trim formām, attēlotas zīmējumā 2.2.

att.2.2. Tāds pats cikliskais vaicājums, kuram viens no savienojuma noteikumiem palaist garām

Pievērsiet uzmanību ka dota vaicājuma variantos A un B uzminēt par bultiņas prombūtne eksistēšanas var pamatojoties uz tāda fakta, ka starp saitēm T2 un T3 bultiņas ir no abām galam, bet bultiņas no abām galam nozīme ka tā ir saite “viens-pret-vienu”.

Variants C, no citas puses izskatās kā viss vieglākais savienojumu koks, bet tomēr šeit ir cikliskais savienojums, tā kā T1 izmanto vienu un to pašu ārēju atslēgu savienošanai ar T2 un ar T3.

Kad ir tabulas ar attiecībām “viens-pret-vienu” tad cikliskie savienojumi kā attēla 1 satikās bieži. Tas nav funkcionāla problēma. Savienojumi tāda veida var uzskaitīt par labo iespēju lai optimizēt vaicājumu. Ja T1 jau ir apstrādāts, tad lietderīgi ja ir izvēle pieviesties pie T2 un T3, tā ka vienam no viņiem varētu būt labākais filtrācijas koeficients, vai tas var dot pieeju pie labām filtriem lejup kokā.

Ja jūs apstrādājiet T2 vai T3 līdz T1 savienojuma kartība, tad iespēja izveidot savienojumu “viens-pret-vienu” ar pretēju tabulu (no T2 pie T3 vai no T3 pie T2) ir lietderīga. Tas pieļauj izmantot jebkuru filtru, kurš var būt pie otras tabulas, līdz savienojumu ar T1.Bez horizontālas saites varētu savienot T2 ar T3 un pretēji tikai caur T1, iespējams ar augstāko vērtējumu.

Ja jūs pamanījāt ka divi savienojumi pēc tranzitivitātes likuma prasa trešo, labāk izdarīt visi trīs savienojumi skaidri.

Eksistē īpašs gadījums kad tabulas ar attieksme “viens-pret-vienu” ir apzīmēti ka T2 un T3, bet tas ir viena un tāda paša tabula. Šajā gadījuma katra rinda no T1 tiek savienota ar vienu un to pašu rindu no T2 divreiz. Tas ir absolūti neefektīvi. Var gadīties kā viens tabulas vārds var atkārtoties divreiz. Lai izvairīties vaicājumā no liekas atsaucēs uz tabulu un pārvietot uz palikušu pseidonīmu visos atsauces uz ailēm un tālākiem savienojumiem lejup.

22

Gadījums 2. Galvena un detalizētai tabulai glabājas ārējas atslēga kopijas. Kuri norada uz vienu un to pašu primāro atslēgu 3 tabulas.

Attēla 2.3. ir paradīts otrais no cikliskiem savienojumiem pamat gadījumi. Šeit ir identiskas ārējas atslēgas T1 un T2, kas uzrada uz vienu un to pašu vērtību primāru atslēgu uz T3.Šajā gadījuma SQL kods izskatās šādi:Select ...From ...T1, ... T2, ... T3, ...Where ... T1.FKey1 = T2.PKey2AND T1.FKey2 = T3.Pkey3AND T2.FKey2 = T3.PKey3 ...

Att. 2.3. Cikliskais savienojums, domājošs denormalizāciju.

Šajā operatora SQL ārēji atslēgas no T1 uz T2 un T3, FKey1 un Fkey2. Pēc tranzitivitātes likuma ārēja atslēga T2.FKey2 ailes vērtība ir vienāda T1.FKey, tā ka abas atslēgas savienoti ar T3.Pkey3. Primāras atslēgas T2 un T3 tiek nosaukti PKey2 un Pkey3.

Paskaidrojums kā T1 un T2 ir savienoti ar vienu un to pašu tabulu T3, pēc tas pilna primāra atslēga ir tas, ka T1 un T2 iekļautas liekas ārējas atslēgas, kuri norada uz šo tabulu.

Šajā scenārija ailē FKey2 daļējas tabula T1 satur denormalizēti dati no tas galvenās tabulas T2. Šie dati vienmēr ir vienādi FKey2 vērtībai attiecīgi galvena rindā tabulā T2.

Iespējams kā denormālizacija tas ir kļūda. Noraidījums no denormalizācijas nozīme, ka tiks nodzēsti ārējas atslēgas FKey2 no T1, tāda veida novēršot saite no T1 pie T3 un pārveidojot vaicājuma diagramma kokā.

Gadījums 3. Divmezglu filtrs(nav unikālais abām galam) jau ir saistīts ar parastu savienojumu palīdzību.

Attēla 2.4. ir paradīts ciklisku savienojumu trešais pamat gadījums. Šajā gadījuma mums ir parasti bultiņas kuri virzītas lejup no T1 pie T2 un T3, bet tomēr ir 3 neparastais savienojuma noteikums starp T2 un T3, kurš nepiesaista primārais atslēgs ne vienam no divām tabulām. Tā kā neviens no primāriem atslēgām netik izmantots savienojuma starp T2 un T3 saite starp tiem nav bultas neviena galā.SQL kods izskatās sekojoši:SELECT ...From ... T1, ...T2, ... T3, ...Where ... T1.FKey1=T2.PKey2AND T1.FKey2=T3.PKey3AND T2.Col2<Kada veida tiek salidzinats>T3.Col3...

23

Att.2. 4. Cikliskais savienojums ar divmezglu filtru

Piemēram, ja T1 tas ir tabulas Orders pseidonīms, kura tiek savienota ar Customers, T2, un Salespersons T3, tad tas var nozīmēt, ka vaicājumam ir nepieciešami pasūtījumi, pircēji un atbildīgi pārdēvēji kuras saistīti ar dažiem reģionam:Select ...From Orders T1, Customer T2, Salesersons T3Where T1.Customer_ID= T2.Customer_IDAND T1.Salespersons_ID = T3.Salespersons_IDAND T2.Region_ID! = T3.Region_ID

Šeit noteikums T2.Region_ID! = T3.Region_ID – tas ir savienojums, bet labāk to apskatīt kā filtrācijas noteikums, kuram rindās no divām dažādam tabulām ir vajadzīgi vel pirms tas izmantošanas. Ja mēs ignorēsim šo neprastu saite starp T2 un T3 tad griešana pie T1 tiks izveidota pirms divmezgla filtra pēc Region_ID izmantošanas. Vienīgas savienojumi secības, kas izvairās no tiešas izpildīšanas neparasta savienojumus starp T2 un T3 tas ir:(T1, T2, T3)(T1, T3, T2)(T2, T1, T3)(T2, T1 T2)

Jebkura cita secība (piemēram (T2,T3,T1)), pēc 2 tabulas apstrādes, izveidos daudz rindas tipa “daudz-pret-daudziem”, praktiski dekartas rindas T2 un T3 reizinājums. Visas apskatītas agrāk savienojuma secības apstrādā T1 pirmkārt vai otrkārt, pirms abas tabulas T2 un T3 apstrādāšanai. Tāda veida, šis savienojuma secības izpilda tikai divas parastas savienojumus “daudz-pret-vienu” starp daļēju tabulu T1 un tas galvenam tabulām T2 un T3.

Neparastais divmezglu filtrs ne uzvedas ka parastais filtrs, kad jūs tikāt pie pirmās no divām filtrētām tabulām. Bet pēc tam kad jūs apstrādājiet otro tabulu, strādā ka parastais filtrs, atmeta rindas dalu. Filtrs neeksistē (vai nav pieejams tieši), kamēr netiks izveidots savienojums ar vienam no filtrētām tabulām.

Tomēr uzreiz kad ar jebkuru divmezglu galu filtra tiks izpildīts savienojums, pretējais mezgls iegūs labāko filtrācijas koeficientu un kļūs par labāko izvēle sekojošiem savienojumiem.

Attēla 2.5. ir paradīts specifiskais piemērs ar divmezglu filtru, kurā rindu daļa no parastam savienojumiem no T1 uz T2 un T3, apmierinošiem noteikumiem divmezglu papild filtra ir vienāda 0,2. Šajā gadījuma vispirms jāizvēlas savienojumu secību neatkarīgi no šīs filtra eksistēšanu, seko tikai pēc parastam saitēm. Tomēr uzreiz kad notiks savienojums ar T2 vai T3, pretējas tabulas filtrācijas koeficients (0,1 pēc T2 un 0,5 pēc T3) kļūs vienāds izejošam, reizinātām uz 0,2, kļūšot par labo izvēle nākošiem savienojumiem.

24

Att. 2.5. Divmezglu filtrs ar skaidru divmezglu filtrācijas koeficientu.

Sekojiet parastai procedūrai lai iestatīt diagrammu, ignorējot divmezglu filtru starp T2 un T3, kamēr filtrs nesasniegs vienu no tabulām. Vedoša tabula T1, pēc tam T4 - tabula zem T1 ar vislabāko parastu filtru. Pēc tam pie T3 kuram ir labākais filtrs ar filtrācijas koeficientu 0,5. Tāpēc tā tiek ievietota nākamā savienojuma secība. Tagad jāizvēlas starp T2 un T5, bet pēc T2 ir aktivizēts divmezglu filtrs, jo T3 jau ir apstrādāta, kas dod efektīvāko filtrācijas koeficientu 0,2, neka T5, tāpēc nākamo pievienojam T2.Visi savienojumi izskatās šajā secībā (T1, T4, T3, T2, T5).

Gadījums 4. Salikts savienojums no divām ārējam atslēgām pie saliktam primāram atslēgām sadalītas uz divām tabulām.

Attēla 2.6. ir paradīts ceturtais no cikliskiem savienojumiem pamat gadījumiem. Šeit ir divi neparasti savienojumi ar T3, un neviena no tiem netiek izmantots šis tabulas pilnais primārais atslēgs, kā ari netiek izmantoti tabulas primāras atslēgas pretēja gala savienojumiem.

Att.2.6. Cikliskais savienojums ar divām neparastam savienojumiem.

Situācija kura ir attēlota attēlā 2.6. SQL kods izskatās šādi:SELECTFrom ... T1, ... T2, ... T3, ...Where ... T1.Fket1 = T2.PKey2AND T1.FKey2 = T3.PkeyColumn1AND T2.FKey3 = T3.PkeyColumn2 ...

Tāds kods parasti radās kad primārais atslēgs T3 sastāv no divām daļām. Bet ārējais atslēgs kurs sastāv no divām daļām kaut kāda veida tiek sadalīts pa divām tabulām kas sastāv attieksme galvenās un daļējas tabulas.

25

Konkrētais piemērs paskaidros šo gadījumu. Apskatīsim tabulas datu vārdnīcas: Tables, Indexes, Table_Columns un Index_Columns. Tabulai Table_Columns var izvelēties primārais atslēgs kas sastāv no divām daļām kā (Table_ID, Column_Number), kur Column_Number apzīmē vietu, kurā tabulās ailē aizņem dabiskā tabulas ailes secība. Vieninieks pirmai ailei, divnieks otrai, un tā tālāk.

Ārējais atslēgs tabulā Indexes Tables tabulai sastāv no aile Table_ID. Tabulas Index_columns primārais atslēgs( Index_ID, Column_Number) arī sastāv no divām daļām.

Vērtības Column_Number un Index_Columns ir to pašu vērtību kas ir Column_Number uz Table_Columns- vietu kuru aile aizņem dabīga tabulas ailes secība (neviss vietu indeksā, kura tiek apzīmēta kā Index_Position).

Ja būtu zināms indeksa nosaukums, un būtu nepieciešams uzzināt ailes nosaukumu sarakstu, kuri sastāv indeksu, Index_Position uzradīta kartībā tad to jāuzraksta sekojoši:

SELECT TC.Column_NameFrom Indexes Ind, Index_columns IC, Table_Columns TCWhere Ind.Index_Name = ‘Employees_X1’AND Ind.Index_ID = IC.Index_IDAND Ind.Table_ID = TC.Table_IDAND IC.Column_Number = TC.Column_Number Order BY IC.Index_Position ASC

Ja filtrācijas koeficients pēc Index_Name noteikumiem vienāds 0.0002, tad vaicājuma diagramma bez savienojuma koeficientiem izskatās kā attēlā 2.7.

Šeit ir divas kļūdas(divi savienojumi, kuras galam nav pilnas primāras atslēgas) kas kompensē viena otru, ja apskatīt savienojumus ar TC kopīgi, tā ka kopā viņi izmanto šis tabulas pilnu primāru atslēgu.

Att. 2.7. Konkrētais piemērs ceturtam cikliskam savienojuma tipam

Šo diagrammas retu gadījumu var transformēt, tas ir attēlots attēla 2.8.

Att.2.8 Sastāv savienojumu kombinēšana no ārējam atslēgām sadalītam pa divām tabulām

26

Ja jūs izpildīsiet liela pirksta noteikumu, kurš piespiež izveidot savienojumi no pilnas primāras atslēgas(vai pie atslēgām), tad vislabākā savienojumu kartība kļūs skaidra attēlam 2.7.

Sākot no IND filtriem un pēc tam pa saitēm augšup uz IC. Tikai pēc tam, iegūšot abas primāras atslēgas daļas TC, var izpildīt savienojumu ar TC. Tas ir labākais plāns lai izpildīt šo uzdevumu. Liela pirksta noteikums tādas gadījumos –tas ir sekot pēc šim neparastam saitēm pie saliktu primāru atslēgu, pēc tam kad datu bāze apstrādās visi mezgli augšā, kas ir nepieciešami pilna primāra atslēga izmantošanai.

Nesaistītie vaicājuma diagrammas

Attēlā 2.9 ir paradīti nesaistītu vaicājuma diagrammas 2 gadījumi. Tas ir vaicājumi, kas neapvieno visi tabulas uz vienu saistītu struktūru. Katram no šiem gadījumiem jūs varat ieraudzīt divi neatkarīgi vaicājumi. Katram no vieniem eksistē atsevišķa diagramma, kuru var optimizēt neatkarīgi no cita vaicājuma. Gadījums A Gadījums B

Att. 2.9 Nesaistītie diagrammas vaicājumi

Gadījuma A tiek nodemonstrēts vaicājums no diviem vaicājumiem kas izskatās ka neatkarīgi vaicājumi, katram ir savienojumi. Gadījuma B tiek nodemonstrēts nedaudz cits parastais vaicājums, kur viena no tabulām (T2) nav saistīta ar savienojumu koku (citiem vārdiem nav saistīta ne ar vienu no tabulām). Abi gadījumi atteicas divām neatkarīgām vaicājuma, kuri izpildās viena vaicājuma iekša.

Ja jūs pieskārusies ar dekarto reizinājumu, piemēram ar attēlotu zīmējumā 2.9., tad jāizseko tas ieradīšanas iemesls. Kad izsekosim iemeslu, mēs varam risināt , kādas darbības jāizpilda atkarība no kāda no četriem gadījumiem nesaistītiem vaicājumiem mēs strādājam.

- Vaicājumā nav savienojuma starp nesaistītam daļām. Šajā gadījuma nepieciešams vienkārši pievienot neeksistējušo savienojumu. Vaicājums apvieno 2 neatkarīgi vaicājumi, katrs no kuriem atgriež dažas rindas. Šeit no dekarta reizinājuma var izvairīties, ja izpildīt neatkarīgi vaicājumi atsevišķi.

- Viens no neatkarīgiem vaicājumiem atgriež vienu rindu. Jāapskata dalīšanas vaicājuma variantu. Lai saglabāt datu bāzes ražotspēju, īpaši ja otrais neatkarīgs vaicājums atgriež daudz rindas. Vispirms jāizpilda vienu rindas vaicājumu. Abas neatkarīgas vaicājumi atgriež pa vienai rindai. Šajā gadījuma atstājiet vaicājumu par nesaistītu, ja tikai viņu nav grūti apstrādāt.

27

Vaicājuma diagrammas ar dažiem saknes mezgliem.

Attēlā 2.10 ir paradīts vaicājuma diagrammas piemērs, kas sabojā pieņēmumu viena saknes mezgla esamības pie vaicājuma koka.

Att. 2.10 . Vaicājuma diagramma ar dažam saknēm

Šeit katrai Master tabulas rindai, kas apmierina vaicājuma noteikumam, vaicājums atgriež visas kombinācijas atbilstošas daļējas rindas no Root1 un Root2. Ar daļējas koeficienta savienojuma datiem var sagaidīt ka visi 5 detalizētas rindas kombinācijas no Root1 un 30 rindas no tabulas Root2 iedos mums 150 kombinētas rindas katrai attiecīgai rindai no Master. 150 rindas satur ne vairāk izej datus, neka 5 rindas no Root1 un 30 rindas no Root2 kopā. Tāpēc būs ātrāk skaitīt 5 un 30 rindas atsevišķi, izvairīties no dekarta reizinājuma. Ir 4 iespējami gadījumi vaicājuma diagrammas paradīšanas ar dažiem saknēm.

1. Trūkušais noteikums. Šajā vaicājumā trūkst noteikums, kurš varētu pārveidot vienu no sakņu daļēju tabulu uz galvenu tabulu, izveidojot no savienojumu “viens-pret-daudziem” uz “viens-pret-vienu”.

Lēmums : Pievienot trūkušo savienojuma noteikumu2. Dekarta reizinājums “daudz-pret-daudziem”. Līdzīgais vaicājums attēlo dekarta

reizinājumu “daudz-pret-daudziem” katrai galvenai rindai, kurš rodas starp daļējam tabulām, atteicošiem vienai galvenai tabulai. Šis gadījums slēpjas zem filtrācijas daļējas koeficientiem kas pārsniedz 1.0 no vienas galvenās tabulas pie divām atšķirīgam sakņu daļējam tabulām

Lēmums : Jāsadala vaicājums uz neatkarīgiem vaicājumiem, kuri nolasa divas daļējas saknes tabulas atsevišķi, lai izvairīties no dekarta reizinājuma3. Daļējas savienojuma koeficients ir mazāk 1,0. Šajā gadījuma viena no saknes daļējas

tabulām tiek savienota ar kopējo galveno tabulu kurai detaļas savienošanas koeficients ir mazāk 1,0.

Lēmums : Kaut gan šis gadījums ne izveido ražotspējas problēmas, apskatiet vaicājuma daļas sadalīšanas variantu vai vienas no vaicājuma daļas uz apakšvaicājumu pārvešanas, pēc funkcionālam iemesliem.4. Tabula tiek izmantota tikai lai pārbaudīt jeb kādas realitātes eksistēšanas. Viena no

saknes daļējas tabulām nepiegādā nekādus datus, vajadzīgas saraksta SELECT, un ir iekļauta tikai lai pārbaudīt eksistēšanas.

Lēmums : Jāpārveido eksistēšanas pārbaudīšanu uz skaidru apakšvaicājumu.

28

Gadījums 1. Trūkušais savienojuma noteikums

Attēlā 2.11. ir paradīts pārvēršana, kad savienojums no Master pie Root1 pārvēršas uz “viens-pret-vienu” savienojumu, ja tiek pievienots papild noteikums Root1(samainīts uz R1), kas garantē ka datu bāze katrai rindai no Master atradis maksimums vienu rindu uz R1.Tas ir iespējams kad R1 glabās dažādi detalizētas dati, kuri ir atkarīgi no laika intervāliem.

Att.2.11. Vaicājuma kārtošana ar dažas saknēs mezgliem

Bieži noteikums, kas pārveido savienojumu uz “viens-pret-vienu”, jau ir un jūs atklātā ka savienojuma kombinācija “daudz-pret-vienu” un manīto filtru vienkārši atmaina filtrācijas daļējais koeficientu.

Citādi noteikums, kurš pārveido savienojumu uz “viens-pret-vienu” var vienkārši neeksistēt vaicājumā, īpaši ja izstrādāšana tika izveidotā tekstā sistēmā, kur attiecība “viens-pret-daudziem” var būt slēpta.

Gadījums 2. Dekarta reizinājuma sadalīšana uz dažādiem vaicājumiem

Attēlā 2.12. ir paradīts vēl viena vaicājuma diagrammas ar dažiem saknes mezgliem uzdevuma risinājums. Lai risināt šo uzdevumu, vajag sadalīt dekartu reizinājumu un aivietot īt to ar 2 atsevišķiem kopām. Šajā piemēra mēs aizvietosim vaicājumu, kurš atgrieza 150 rindas katrai rindai no Master, uz divām vaicājumam, kuri kopīgi atgriež pa 35 rindām katrai Master rindai. Ja jūs redzat galvenās tabulas attiecību “viens-pret-daudziem” ar divām dažādam saknes daļējam tabulām, tad varat iegūt tādas pašas datus, nolasot daudz vairāk rindas ar atsevišķiem vaicājumiem, kā ir attēlots zīmējumā 2.12.

29

Att.2.12.Dekarta reizinājuma izlabošana ar atsevišķiem vaicājumiem palīdzību.

Gadījums 3. Attiecības ar saknes daļējam tabulām ne vairāk ka “viens-pret-veinu”

Attēlā 2.13. ir paradīts diagrammas ar dažiem saknēm gadījums, kad izejoša vaicājuma ražotspēja nav problēma. Tā kā daļējais savienojuma koeficients Master ar Roote1 ir vienāds ar 0,5, dekartas reizinājums neved pie stipras rindu skaitās palielināšanai Dekartā reizinājumā, kad jūs kombinēsiet piemērotus ierakstus no Root1 uz Root2 vidējam piemērotām ierakstam no Master. Var uzskaitīt savienojumu ar Root1 par savienojumu lejup un pat atdot tam priekšroku, jā tas uzlabotu uz 0,5 reizes filtrācijas koeficientu priekš filtrējošiem savienojumam. Dotā gadījumā priekš daļējām filtrācijas koeficientiem, mazāk par 1,0.

Att.2.13. Dekarta reizinājums ar nelielu daļēju savienojumu koeficientu

30

Kaut gan šis vaicājums nav problēma iestatīšanai, tomēr var būt nepareizs. Savienojums “viens-pret-nulle” vai “viens-pret-daudziem” no Master uz Root1 ir skaidrs, parasti pārvēršas uz “viens-pret-nulle” vai “viens-pret-vienu”, nodrošināšot drošu Dekarta reizinājumu.

Bet tā ka retos gadījumos savienojums var pārveidots uz savienojumu “viens-pret-daudziem”, nepieciešams ieverot ka rezultāts var atgriezt Dekartu reizinājumu ar atkārtojumiem priekš dotai rindai no Root2.

Gadījums 4. Eksistēšanas pārbaudīšanas transformēšana uz skaidru apakšvaicajumu

Viens no funkcionālu uzdevuma 2.13. risinājuma jau ir paradīts attēlā 2.12. Viens vaicājums vienkārši tika sadalīts uz divām apakšvaicājumiem. Cits risinājums, kurš bieži ir labāk, atļauj izolēt zaru no Root1 apakšvaicājumā, parasti ar noteikumu EXISTS. Šis risinājums īpaši labi strādā ja izejošais vaicājums ne izvēlas ailes no Root1. Šajā gadījuma mums interese, vai eksistē piemērota rinda tabulā Root1 un vai tas apmierina dažiem filtrācijas noteikumiem.

Savienojums bez primāram atslēgām

Izmantosim saites bez bultiņām uz galam, lai apzīmēt savienojumi kuram nav primāras atslēgas uz abām galam. Kopumā tas attēlo neparastas savienojumi “daudz-pret-daudziem”, kaut gan dažādos gadījumos viņi pārvēršas uz “daudz-pret-nulle” vai “daudzi-pret-vienu”.

Ja dažreiz savienojumi var būt kā “daudzi-pret-daudziem”, tad jums radās tādas pašas problēmas kā priekš vaicājumu diagrammām ar dažām saknes mezgliem.

Attēlā 2.14 ir attēlots savienojums “daudz-pret-daudziem”, starp T1 un T2, kur daļējais savienojuma koeficients uz abām galam ir lielāks par 1,0.Galvenas savienojuma koeficienti ir tikai uz unikālas saites galā, kurš ir apzīmēts ar bultu, tāpēc dotā saitē ir divi daļējas savienojuma koeficienti.

Att.2.14. Savienojums “daudz-pret-daudziem”

Šis gadījums satikās biežāk neka jau apskatīti neparastas savienojumus diagrammas piemēri. Kaut gan šeit tomēr ir iespējami problēmas avoti(un risinājumi), ka gadījuma ar dažiem saknes mezgliem, lielāka savienošanas daļas “daudz-pret-daudziem” radās vienkārši tāpēc ka nav savienojuma noteikumus. Jāsāk ar pārbaudes, vai ir nepieciešams vaicājumā filtrācijas noteikums jāuzskata par savienošanas dalu, jo tas pabeidza pilnas atslēga specifikāciju vienai no savienošanas pusēm.

Tāds gadījums kad nav savienojamas noteikuma īpaši bieži paradās, kad datu bāzes dizains atļauj dažas realitātes tipa eksistēšanu, vai sadalīšanu tabulas ierobežojumos.

Pat ja reāliem datiem ir dažādas tipi vai sadalījumi, tad cita vairāk selektīvāka atslēgas daļa parasti var būt unikāla.

Neeksistējoša savienošanas noteikuma meklēšana un izlabošana var tikai nedaudz palielināt ražotspēju, ja taisāt šos savienojumus daudz selektīvas.

31

Savienojums “viens-pret-vienu” ar apakškopas tabulu

Attēlā 2.15. ir paradīts tipiskais “vien-pret-vienu” savienojums, kas ir iebūvēts lielā vaicājumā. Tajā paša laika kad “daudz-pret-daudziem” daļēji savienojumā koeficienti abām galam, savienojuma “viens-pret-vienu” tas ir galveni savienojuma koeficienti. Galveni savienojuma koeficienti šajā piemēra parada, ka savienojums starp T1 un T2 var būt tikai “viens-pret-nulle” vai “viens-pret-vienu”. Gadījums “viens-pret-nulle” var ierasties 30% rindām no T1.

Att.2.15. Tipiskais savienojums “viens-pret-vienu”

Tā kā tas ir iekšējais savienojums, savienojuma gadījumi “viens-pret-nulle” starp T1 un T2 ir paslēptais savienojuma filtrs. Ja virs T1 ir daļējā tabula, kas attēlo pelēkā krāsā saites augšup un ja dota daļējas tabula savienojas ar T1 pēc tāda paša unikāla atslēga, ka ar T2, tad pēc transitivitātes likuma jums ir domāts savienojums no daļējas tabulas pie T2. Attēlā 2.16. domāta saite tiek attēlota ar pelēku krasu.

Att.2.16. Domāta saite, kura izveido ciklisku savienojumu.

Ja jums ir cikliskais savienojums vai ne, jūs vienmēr varat uzlabot datu bāzes dizainu. Gadījums attēlots zīmējumā 2.16. attēlo realitātes kopu, kuri attēlo T1, un to pašos reālitātes apakškopu, kas attēloti uz T2, un tabula T2 izveidota no primāra atslēga un ailēm, kuras tiek izmantotas tikai dotai apakškopai. Tāpēc ja jums ir iespēja ietekmēt uz datu bāzes dizainu, padomājiet par divas tabulas izmantošanu.

Tieši savienojumi “viens-pret-vienu”

32

Attēlā 2.17. ir paradīts gadījums, kas prasa obligātu divas tabulas savienojumu uz vienu, kad tas ir iespējams. Šeit galveni filtrācijas koeficienti ir vienādi 1.0, un starp tabulām eksistē tieša attiecība “viens-pret-vienu”. Tāda veida, abas tabulas tiek attēloti uz vienu un to paši realitātes kopu un savienojums- tas ir nav vajadzīgi patēriņi, ja salīdzināt ar kombinētu tabulas izmantošanai.

Att.2.17. Tiešais savienojums “viens-pret-vienu”

Vienīga situācija, kad no ražotspējas viedokļa vajag sadalīt tabulas, tas ir kad vaicājumiem praktiski vienmēr ir vajadzīgi dati tikai no vienas tabulas, un reti nepieciešams izpildīt savienojumu.

No funkcionalitātes un izstrādāšanas puses, ir iespējams, ka izmaksas uz pievienošanu kodēšanu, un rindas dzēšanai vienlaicīgi abām tabulām, un dažreiz abas tabulas modificēšanas būs liela.

Iespējams, ka jūs izvelēties atbalstīt vienu kombinētu tabulu. Parasti, ja jūs redzat tiešo savienojumu “viens-pret-vienu”, tas paradās stingras funkcionalitātes rezultātā, kas pieprasa jaunus ailes jau eksistējošam realitātēm, un dažiem iedomātam vai reālam izstrādāšanas ierobežojumiem, kas ne pieļauj izmainīt izejošo tabulu. Šo problēmu labāk risināt doto problēmu ar šo ierobežojuma novēršanu.

Savienojums “viens-pret-vienu” ar daudz mazāko datu kopu

Attēlā 2.18 ir paradīts savienojums “viens-pret-nulle” vai “viens-pret-vienu”, kurš praktiski vienmēr strādā kā “viens-pret-nulle”. Šis gadījums ideāli attaisno tabulas sadalīšanu. Sīkai realitātes apakškopai, attēlotām ar T2, var eksistēt citas optimizācijas prasības, kuri ir atšķirīgas no prasībām paplašinātai kopai, kura ir attēlota ar tabulu T1. Iespējams, T1 parasti tiek aptaujāts bez T2 savienojuma, un dotas gadījumos nevajadzīgu T2 ailes izņēmums un atbalsta tikai tos indeksus, no kuram ir jēga kopīgam realitātēm, kuri ir lietderīgi.

Šeit noslēptais savienojuma filtrs, kas attēlots ar zemu galvenu savienojuma koeficientu T2 malā savienojums strādā lieliski. Viņš ir tik labs, ka jūs pat varat uzsākt vaicājuma izpildīšanu no nefiltrējoša tabulas T2 pilnas skanēšanas un tapāt labi atrast vislabākais ceļš pie parējām datiem. Ja jūs apvienosiet šīs tabulas uz vienu, tad iegūt tādu izpildīšanas plānu var būt nav viegli, ja tikai būs izveidoti indeksi, bezjēdzīgas parējās gadījumos.

Att.2.18. Savienojums “viens-pret-nulle” vai “viens-pret-daudziem” starp stipri atšķirīgam pēc izmēra tabulām

33

Šeit galvenais uzdevums neaizmirst ieverot noslēptu savienojuma filtru no T1 uz T2, vai jāsāk vaicājumu no T2, vai jāapstrādā to pēc iespējas ātrāk, lai pēc iespējas agrāk izmantot noslēptu filtru.

Savienojumi “viens-pret-vienu” ar noslēptiem savienojuma filtriem abos virzienos

Attēlā 2.19. ir paradīts rets savienojuma gadījums “nulle-pret-vienu” pie “nulle-pret-vienu”, kas tiek filtrēti abas virzienos. Ja tikai dati nav sabojāti(piemēram viena no tabulai trūkst jebkādas dati), šis rets gadījums, kad eksistē vai jāeksistē arī treša tabulai, kas attēlo paplašinātu kopu pārsegšanas. Ja jūs atradīsiet vai izveidosiet tādu tabulu, tad te paši argumenti kā agrāk jākombinē ar vienu vai abām apakškopas tabulām.

Att.2.19. Savienojums “nulle-pret-vienu” pie “nulle-pret-vienu”

Vienošana “viens-pret-vienu” savienojumu attēlošana

Attēlā 2.20. attēloti divi alternatīvi varianti, kuri ir labi piemēroti savienojumam “viens-pret-vienu”, kuri atrodas zem daļējas saknes tabulas. Pirmā varianta īpaši tiek pasvītrota divpusīga bultiņa, kuras galos vienāda līmeni attēloti mezgli. Otrā variantā tiek pasvītrotas parasta atsauces virziens - lejup no saknes daļējas tabulas. Abi varianti ir labi, ja jūs atcerēsieties ka “viens-pret-vienu” savienojums kaut kāda nozīme no abām pusēm virzītas lejup.

Att. 2.20. Savienojumu “viens-pret-vienam” diagrammas attēlošana kas atrodas zem saknes daļējas tabulas

34

Dotā gadījumā kad abas tabulas kas piedalās savienošana, atrodas zem saknes, jāatceras, ka ja līdztiesīgas tabulas izmanto kopējo primāru atslēgu, tad saite no augšas ar T1 pēc tranzitivitātes likuma tapat var atteikties pie T2, ja tikai tas ne ved pie unikālam alternatīvam atslēgām pēc T1, kurš ne tiks izmantots T2. Tas ne skaidrs cikliska savienojuma gadījums, kurš tika attēlots zīmējumā 2.2 variants B.

Attēlā 2.21. tiek attēloti alternatīvas “viens-pret-vienu” savienojuma diagrammas divas daļējas saknes tabulas(tādas tabulas atrodas augšup, un ar viņiem nav savienojumus), ja kaut gan no viens no savienojuma novirzēm tiek raksturots ar galveno savienojumu koeficientu, mazāk par 1,0. Un atkal mēs varam pasvītrot šo savienojuma raksturu vai horizontālu novietošanu, vai noradīt kāda no tabulām lielāk, ievietojot mezgls ar lielāku galvenu savienojuma koeficientu augstāk. Mezgls ar lielāku galvenu savienojuma koeficientu attēlo tabulu, kuras lielāka rindu daļa piedalās dotā savienojuma “nulle-pret-vienu” pie “nulle-pret-vienu”.

Att. 2.21.Diagrammas attēlošanas alternatīvie veidi daļējām saknes tabulām ar attiecību “(nulle vai viens) pret (nulle vai viens)”

Attēlā 2.22. tiek attēlots gadījums, līdzīgs ar attēlu 2.21.,bet ar mezgli ar tiešu attiecību “viens-pret-vienu”, kurš definē tabulas, kuri vienmēr tiek savienoti sekmīgi. Un atkal var pasvītrot ekvivalence savienojuma novirzes, ievietojot mezglus blakus pēc horizontāles. Vai arī izvelēt virzienu, kurš ļauj attēlot koku vairāk sabalansētam, lai tas vieglāk ievietojas lapas pusē, ievietojot mezglus ar garākiem zariem augstāk.

35

Att.2.22. Saknes daļējas tabulas ar tiešu attiecību “viens-pret-vienu” diagrammas attēlošana alternatīvie veidi

Ārēji savienojumi

Praktiski vienmēr jēga un ārēja savienojuma norīkojums- tas ir nepieļaut vajadzīgas informācijas zaudēšanas no tabulas, kura atrodas savienojumā sakumā, neatkarīgi no ārēji pievienotas tabulas satura.

Filtrētas ārēji savienojumi

Apskatīsim attēls 2.23., kur ārējais savienojums tiek izveidots ar tabulu ar filtrējošu noteikumu. Ārējā gadījumā, tas gadījumā kad T1 rindai nav piemērotas rindas no T2, datu bāze norīko rezultējošā rindā katrai T2 ailei vērtību null. Tāda veida, izņemot T2. Dažāda _aile IS NULL, praktiski jebkurš filtrējošais noteikums T2 dod rezultējošas rindas izņēmumam, kura tiek izveidota ārējā gadījumā ārējā savienojumā.

Att.2.23. Ārējais savienojums ar filtrētu mezglu

Tā kā vairāku filtru skaits ārējai tabulai atmeta ārēja savienojuma gadījumi, un ārējas savienojumi paredzēti lai saglābāt tādus gadījumus, jums nepieciešams pievērst uzmanību uz jebkuram ārējas tabulas filtriem. Eksistē dažādi scenāriji, un jums vajag patērēt daudz laika, lai noteikt, kāds no viņiem jāizmanto konkrēta gadījumā.

- Filtrs ir rets, piemēram Dažāda _aile IS NULL, un var atgriezt vērtību TRUE laukiem, kas ir vienādi ar NULL, kas ir ievietoti ārējā gadījumā, tāpēc filtrs funkcionāli pareizs.

- Izstrādātais ne plānoja atmet ārējo savienojumu, un filtrējušo noteikumu nepieciešams nodzēst.

- Filtrēts noteikums ir piemērots ārēja savienojuma atmēšanai, un savienojums var būt arī iekšējais. Šajā gadījuma nav nekādas funkcionālas atšķirības starp vaicājumiem ar savienojumiem, izteiktām kā ārējais vai iekšējais savienojums. Tomēr, izveidojot to formāli par iekšējo savienojumu, jūs dosiet datu bāzei vairāk brīvības izpildes plāna izveidošanai, kuras var izpildīt savienojumi jebkura novirzi. Kad vislabākais filtrs atrodas tāda paša puse kur atrodas savienojums, kur agrāk tika pievienota ārēja tabula, papilda brīvība var ļaut izvēlēt labāko izpildes plānu. No citas puses, savienojuma pavēršana uz iekšējo var piespiest optimizators izdarīt kļūdu. Kļūdas nebūtu ja tā būtu ārējais savienojums. Ārējais savienojums –tas ir viens no veidiem savienojuma kartības ierobežojums, kad jūs apzinīgi gribat izdarīt to, pat ja jums vispār nav nepieciešamības saglabāt ārējais gadījums.

- Filtrētais noteikums tiek pievienots speciāli, bet tam jābūt savienojuma daļai.

36

Ārējas savienojuma noteikumi vienai tabulai

Vecā Oracle stilā filtrējoša noteikuma pavēršana uz savienojuma daļu notiek ar (+) pievienošanu. Piemēram:Where ...And O.Order_Type_Code = OtypeTrans.Code(+)And OtypeTrans.Type(+) = ‘Order_Type’

Jaunā ANSI savienojuma stila, filtrētais noteikums pariet FROM nodaļā, lai kļūt par skaidu savienojuma noteikumu:From ... Orders O ...LEFT OUTER JOIN Code_Translations OtypeTrans ON O.Order_Type_Code = OtypeTrans.Code AND OtypeTrans.Type = ‘ORDER_TYPE’

Pirmā ierakstā ārējas savienojuma gadījumā SQL datu bāzē filtrētais noteikums ir savienojuma daļa:Where ...And O.Order_Type_Code *= OtypeTrans.CodeAnd OtypeTrans.Type = ‘Order_Type’

Pievērsiet uzmanību, ka tas dara apskatāmo problēmu par neiespējamu ārējam savienojumiem SQL Server vecā stilā; datu bāze automātiski veido filtrs kā savienojuma daļu. Retos gadījumos, kad filtrs patiešam ir filtrs, vēlamo rezultāta iegūšanai jums nepieciešams vai nu pārveidot ierakstu jaunā stila, vai pārvērst savienojumu uz ekvivalentu vaicājumu NOT EXIST.Apskatīsim pirmais scenārijs sīkāk. Paņemsim sekojošais vaicājums:SELECTFROM Employee ELEFT OUTER JOIN Departments DON E.Department_ID = D.Department_ID WHERE D.Dept_Manager_ID IS NULL

Kas patiešam grib vaicājums no datu bāzes? Semantiski tas pieprasa divas dažādas rindas kopas. Vienā kopā satur dati par visiem darbiniekiem, kuriem nav noradīta nodaļa, bet otra meklē visus darbiniekus kuram ir noradīta nodaļa, kurai nav priekšnieka. Eksistē varbūtība ka pielikums patiešam grib vienlaicīgi iegūt divas atšķirīgas kopas, bet iespējams, ka izstrādātais nepamanīja, ka tādam vieglam vaicājumam ir tāds rezultāts, un viņam nav vajadzīgs viens no šim rindas kopām.Apskatīsim atšķirīgu piemēru:SELECT ...FROM Employees EWHERE NOT EXIST (SELECT *FROM Departments_ID WHERE E.Department_ID = D.Department_ID)

Priekšrocības izteikumā NOT EXIST noteikuma ārējā savienojumā, pēc kuram seko primārais atslēgs IS NULL, ir tā, ka tāda veida forma ļauj precīzāk kontrolēt, kad tiek izpildīts savienojums un kad būs izmantota šis noteikuma selektivitāte.

37

Parasti NOT EXIST noteikumi tiek novērtēti pēc visam parastam savienojumiem. Tas ir viens no piemēriem, kad filtrs (kas nav daļa no ārēja savienojuma) pievienotai ārēji tabulai patiešam var būt iepriekš nodomāts un pareizs.

Ārēji savienojumi, kas ved pie iekšējiem savienojumiem

Apskatīsim attēls 2.24. kurā ir paradīts ārējais savienojums, kurš ved pie iekšējam savienojumam.

Att.2.24. Ārējais savienojums ved pie iekšējo savienojumu

Vecā Oracle SQL stilā tāda veida savienojums tiek uzrakstīts sekojoši:SELECT ...FROM Table1 T1, Table2 T2, Table3 T3Where T1.FKey2 = T2.PKey2(+)AND T2.FKey3 = T3.PKey3

Ārējā gadījuma pirmā savienojuma datu bāze noģenerēs pseidorindu no T2, visus ailes vērtība, tajā skaita T2.FKey2 būs vienāds ar null. Tomēr ārējais atslēgs kas ir vienāds ar null nekad nevar būt veiksmīgi pievienots citai tabulai, tāpēc rinda, kura pārstāv ārējais savienojuma gadījums, tika atmesta mēģinājumā izpildīt iekšējais savienojums ar T3. Tāda veida, ārējais savienojums, kas ved pie iekšēju savienojumu, dod tādu pašu rezultātu, kuru mēs iegūsim, ja abi savienojumi būs iekšēji.

Ārēji savienojumi, kas norada uz daļēju tabulu

Apskatīsim attēls 2.25. kur bultas radītājs saites vidē nozīme ārēju savienojumu, kas norada uz daļēju tabulu.

Att. 2.25. Ārējais savienojums daļējas tabulas virziena

38

Jaunā ANSI stilā šis vaicājums izskatās sekojoši:SELECTFROM Departments DLEFT OUTER JOIN Employess EON D.Department_ID = E.Department_ID

Vai vecā Oracle ierakstā:SELECTFROM Departments D, Employees EWHERE D.Department_ID = E.Department_ID(+)

Vai vecā SQL Server ierakstā:SELECTFROM Departments D, Employees EWHERE D.Department_ID *= E.Department_ID

Tāda veida vaicājumi, kurās ārēji savienojumi ved pie daļējam tabulas, reti var būt pareizi.

Ārējas savienojumi ar daļēju tabulu ar filtru

Attēlā 2.26 ir paradīts ārējais savienojums ar daļēju tabulu, kurai eksistē filtrējošais noteikums. Dažreiz divas kļūdas kompensē viena otru. Ārējais savienojums ar daļēju tabulu, kurai ir arī filtrs, var attēlot pati par sevī divkāršu kļūdu. Dažreiz filtrs kompensē ārējas savienojuma problemātisku efektu, funkcionāli pārveidojot to uz iekšējo. Tādas gadījumos labāk nepieļaut filtru dzēšanu, ja tikai jūs vienlaicīgi nepārveidojiet ārējo savienojumu uz iekšējo.

Att. 2.26. Ārējas savienojums ar filtrētu daļēju tabulu

Piemēram:T1.FKey_ID IS NULL,Šeit T1.FKey_ID tas ir ārējais atslēgs, kurš norada uz T2.PKey_ID paradīta uz diagrammas savienojuma. Noteikums IS NULL savienojuma atslēga vērtība, šis gadījums ekvivalents apakšvaicājumam NOT EXIST. Tā ka visi rindas, kas biji pievienoti ārēja gadījuma, tiek atmesti ar noteikuma IS NULL palīdzību, mēs nebūs parastas problēmas, tādas ka dažādu reālitātes sajaukšanu rindas, kuri tika iegūti ārēja un iekšējā savienojumā.

Vaicājumi ar apakšvaicājumiem.

Praktiski visi reāli vaicājumi ar apakšvaicājumiem iekļauj īpaša noteikuma veidu rindām ārējām, galvenam vaicājumam. Viņiem jāatbilst vai neatbilst piemērotam rindām saistītā

39

vaicājumā. Piemēram, ja jums ir nepieciešami dati par nodaļām, kuras ir darbinieki, jūs varat izmantot sekojošu vaicājumu:

SELECT ...FROM Departments DWHERE EXIST (SELECT NULLFROM Employees EWHERE E.Department_ID = D.Department_ID)

Kā arī jūs varat pieprasīt dati par nodaļām, kuras nav darbiniekus:SELECT ...FROM Departments DWHERE NOT EXIST (SELECT NULLFROM Employees EWHERE E.Department_ID = D.Department_ID)

Savienojums E.Department_ID= D.Department_ID katram no šim vaicājumiem tas ir korelācijas savienojums, kurš uzdot rindas attiecīgi viens otrām ārējā vaicājumā un apakšvaicājumā. NOT EXIST vaicājumam ir arī alternatīva forma:SELECT ...FROM Departments DWHERE D.Department_ID IN(SELECT E.Department_ID FROM Employees E)

Tā ka funkcionāli šis formas ir ekvivalenti, bet diagrammai jābūt objektīvai attiecība pret abām formām, tad diagrammas izskatās vienādi. Tikai pēc diagrammas apskatīšanas jāizvēlas, kurā no formām labāk risina iestatīšanas problēmu un izteica labāko ceļu pie datiem.

Vaicājumu ar apakšvaicājumiem attēlošana uz diagrammām

Jā ignorēt savienojumi, kuri savieno ārējas vaicājumi ar apakšvaicājumiem, vienmēr var izveidot atsevišķi, neatkarīgas vaicājuma diagrammas katram no divām vaicājumiem.Vaicājuma diagrammai jāatbild uz sekojošiem 4 jautājumiem par korelācijas savienojumiem. Doti jautājumi nav piemēroti parastam savienojumam.

- Vai tas ir parastais savienojums? (Ne, tas ir korelācijas savienojums ar apakšvaicājumu)

- Kāda no savienošanas pusēm ir apakšvaicājums, un kāda ārējais vaicājums?- Vai ir iespējams izteikt kā EXIST vaicājums, vai kā NOT EXIST vaicājums?- Kad izpildes plānā jāizpilda apakšvaicājumu?

Diagrammas attēlošana apakšvaicājumu EXIST

Attēlā 2.27. ir paradīti nosacīti apzīmējumi, kuri tiek izmantoti vaicājuma diagrammas attēlošanai ar apakšvaicājumu EXIST.

SELECT ...FROM Departments DWHERE EXIST (SELECT NULLFROM Employees EWHERE E.Department_ID = D.Departmnet_ID)

40

Att. 2.27. Vienkāršais vaicājums ar apkšvaicājumu

Pirmā vērtība blakus E, tas ir korelācijas priekšrokas koeficients Korelācijas priekšrokas koeficients ir vienāds I/E.

E- tas ir uzstādīts vai izmērīts laiks vislabākā plāna izpildīšanai, kad viņš izpildās no ārējas vaicājuma uz apakšvaicājumu (pēc EXIST loģikas).

I- tas ir uzstādīts vai izmērīts laiks vislabākā plāna izpildīšanai, kad viņš izpildās no ārējas vaicājuma uz iekšējo vaicājumu (pēc IN loģikas). Jūs vienmēr varat aprēķināt šo koeficientu, izmērot abas vaicājuma formas izpildīšanas laiku.

Kad priekšrokas korelācijas koeficients ir lielāks 1,0 jāizvēlas korelācijas apakšvaicājumu ar EXIST noteikumu un plāns, kurš sāc ar ārējo vaicājumu un iet pie apakšvaicājumu.

Cita jauna vērtība - tas ir precizēts apakšvaicājuma filtrācijas (0,8 ) koeficients, kurš tiek pieraksties blakus ar daļējo savienojuma koeficientu. Tas ir uzstādīta vērtība, kura palīdz izvēlēt labāko vietu savienojuma kartībā, apakšvaicājuma noteikumam pārbaudīšanai. Tas tiek izmantots vaicājumos, kuri sakas no ārēja vaicājuma, tāpēc izslēdziet to no pussavienojuma saites, kurš pārveidojās uz vadošo vaicājuma plānā.

Attēlā 2.28. ir paradīta daļēja vaicājuma diagramma EXIST apakšvaicājumām, kurā saknes daļēja apakšvaicājuma tabula atrodas pussavienojumā galā, kas virzīta uz primāro atslēgu.

Att. 2.28. Pussavienojums ar primāru atslēgu

Šeit pussavienojums funkcionāli nav atšķiras no parasta savienojuma, tā ka vaicājums nekad neatradis vairāk nekā vienu atbilstību tabulā M dotai rindai no ārēja vaicājumā. Sekojot no tā mēs varam iegūt izpildīšanas plāna brīvību, izslēdzot noteikumu EXIST un savienojot apakšvaicājumu ar ārējo vaicājumu. Piemēram:

41

SELECT <ailes tikai no ārēja vaicājuma>FROM Order_Details OD, Products P, Shipments S, Adresses S, Code_Translations ODTWHERE OD.Product_ID = P.Product_IDAND P.Unit_Cost > 100AND OD.Shipment_ID = S.Shipment_IDAND S.Adress_ID = A.Adress_ID(+)AND OD.Status_Code = ODT.CodeAND ODT.Code_Type = ‘Order_Detail_Status’AND S.Shipment_Date >:now –1AND EXIST (SELECT nullFROM Orders O, Customer C, Code_Translations OT, Customer_Type CTWHERE C.Customer_Type_ID = CT.Customer_Type_IDAND CT.Text = ‘Goverment’AND OD.Order_ID = O.Order_IDAND O.Customer_ID = C.Customer_IDAND O.Status_Code = OT.CodeAND O.Completed_Flad = ‘N’AND OT.Code_Type = ‘Order_Status’AND OT.Text ! = ‘Canceled’)ORDER BY <Ailes tika no ārēja vaicājuma>

Izmantojot tikai jauni apzīmējumi pussavienojumam, šis vaicājums var attēlot diagrammas veidā (att.2.29).

Att.2.29. Saliktais pussavienojuma piemērs ar korelācijas saite ar primāro atslēgu saknes daļēja apakšvaicājuma tabulas

Jā vienkārši pārrakstīt šo vaicājumu, pārvietojot savienojumi un noteikumi apakšvaicājumā tabulas uz ārējo vaicājumu, tad var iegūt funkcionāli identiskais vaicājums, tā ka pussavienojums notiek ar primāru atslēgu un apakšvaicājums viennozīmīgi tiek attēlots uz savu daļēju saknes tabulu:

SELECT <ailes tikai no izejas ārēja vaicājuma>

42

FROM Order_Details OD, Products P, Shipments S, Adresses S, Code_Translations ODT, Orders O, Customres C, Code_Translations OT, Customer_Types CTWHERE OD.Product_ID = P.Product_IDAND P.Unit_Cost > 100AND OD.Shipment_ID = S.Shipment_IDAND S.Adress_ID = A.Adress_ID(+)AND OD.Status_Code = ODT.CodeAND ODT.Code_Type = ‘Order_Detail_Status’AND S.Shipment_Date >:now –1AND C.Customer_Type_ID = CT.Customer_Type_IDAND CT.Text = ‘Goverment’AND OD.Order_ID = O.Order_IDAND O.Customer_ID = C.Customer_IDAND O.Status_Code = OT.CodeAND O.Completed_Flad = ‘N’AND OT.Code_Type = ‘Order_Status’AND OT.Text ! = ‘Canceled’)ORDER BY <Ailes tika no izejas ārēja vaicājuma>

Tagad varam apskatīt atšķirību no pagājušajās versijas att. 2.30.

Att.2.30 Tāds pats vaicājums, pārveidots, lai savienot apakšvaicājumu ar ārējo vaicājumu

Dotai jaunai formai ir būtiskas brīvības papildpakāpes, kas ļauj izveidot savienojumu ar filtrētu mezgli P pēc savienojuma ar labi filtrētu mezgli O, līdz savienojuma ar praktiski nefiltrētu mezgli OT. Izejoša datu bāzes forma pilnīgi jāapstrādā visu apakšvaicājuma zaru pirms pariet pie savienojumiem ar ārēja vaicājuma sekojošiem mezgliem. Tā kā apakšvaicājuma pievienošana šos gadījumos var tikai palīdzēt, un sanāca vaicājuma diagramma kuru mēs jau protam optimizēt. Tālāk mēs apskatīsim tikai diagrammas attēlošanu un citu vaicājumus optimizāciju.

Teorētiski var pielietot tādu pašu risinājumu ar apakšvaicājumu EXIST savienošanu, kad pussavienojuma bultiņa virzas uz daļēju savienojuma galu, bet tas ir sarežģīti un maz iespējams, ka tas palīdzes uzlabot vaicājuma ražotspēju. Apskatīsim iepriekšējo vaicājumu ar Exist noteikumu tabulai Employees:

43

SELECTFROM Departments DWHERE EXIST (SELECT NULLFROM Employees EWHERE E.Department_ID = D.Department_ID)

Sekojoši problēmas rodas pēc mēģinājuma izmantot tāds risinājums šajā gadījumā.- Izejošais vaicājums atgriež maksimums vienu rindu uz katru rindu galvenās tabulas

katrai nodaļai. Lai iegūt tādu pašu rezultātu no pārveidota vaicājuma ar vienkāršam savienojumam ar daļējo tabulas (Employees), nepieciešams iekļaut SELECT sarakstā unikālais atslēgs galvenai tabulai un izpildīt operāciju DISTINCT uz iegūtam vaicājumā rindām. Doti soļi atmeta dublikātus, kuri tiek iegūtas, kad vienam galvenam ierakstam ir dažas piemērotas daļējas.

- Kad galvenai rindai ir dažādas piemēroti daļējas rindas, tad visu atbilstības meklēšana ir dārgāka, nekā pussavienojuma apturēšana pēc tam, kad tiks atrasta pirmā atbilstība.

Tāda veida, reti ir nepieciešamība pārveidot pussavienojumi uz parastam savienojumiem, kad pussavienojuma bultiņa virzīta augšup, tikai tādas gadījumos, kad savienojuma daļējais pusavienojumām tuvs 1,0 vai mazāk.

Lai pabeigt apakšvaicājuma EXIST diagrammu, jums ir nepieciešami tikai izskaitļošanas noteikumi korelācijas priekšrocības koeficienta un precizēta filtrācijas koeficienta apakšvaicājuma. Lai atrast korelācijas priekšroka koeficientu, jāizpilda sekojoši darbības:

1. Lai D – tas ir daļējais savienojuma koeficients pussavienojuma, bet M galvenais savienojuma koeficients. Lai S –tas ir labākais vismazākais filtrācijas koeficients starp visiem mezgliem apakšvaicājumā, bet R –tas ir labākais vismazākais filtrācijas koeficients starp visiem mezgliem ārējā vaicājumā.

2. Ja DxS<MxR, tad korelācijas priekšrocības koeficients ir vienāds (DxS)/(MxR).3. Citādi, ja S>R, tad korelācijas priekšrocības koeficients ir vienāds S/R.4. Citādi, lai E – tas ir izmērīts vislabākā izpildīšanas plāna izpildīšanas laiks, kurš sakot no

ārēja vaicājuma un parejot pie apakšvaicājuma (pēc EXIST loģikas). Lai I – izmērīts vislabākā plāna izpildīšanas laiks, kurš sakot no iekšēja vaicājuma un parejot pie ārēju (pēc IN loģikas).Lai korelācijas priekšrocības koeficients ir vienāds I/E. Jā jūs varat novērtēt korelācijas priekšrocības koeficientu izmantojot 2 un 3 soļi palīdzību, pamatojoties uz tām var izvelēt apakšvaicājuma apstrādes virzienu, nemērojot izpildes reālu laiku.

Jā 2 un 3 soli jūs nevarat iegūt pareizu vērtību, tad drošāk un vieglāk izmantot vērtību, kura tika iegūta pēc reālas mērīšanas. Pēc korelācijas priekšrocības koeficienta atrašanas, jāpabauda, vai ir nepieciešams precizēts apakšvaicājuma filtrācijas koeficients, un ja ir nepieciešams, tad jāatrada to, izpildot sekojošas darbības:1. Ja korelācijas priekšrocības koeficients ir mazāk neka 1,0 un mazāk neka visi parēji

korelācijas priekšrocības koeficienti (gadījumā kad jums ir dažādi apakšvaicājumi) jāapstājas. Šajā gadījumā priekšrocības apakšvaicājuma koeficients jums ne būs vajadzīgs, tā ka viens būs vajadzīgs lai pieņemt lēmumu, tikai kad jūs sāksiet ar ārējo vaicājumu, bet tas nav tāds gadījums.

2. Ja apakšvaicājums –tas ir vientabulas vaicājums bez filtrējoša noteikuma, tikai ar korelācijas savienojuma noteikumu, jāizmēra q (rindas daudzums, kas tiek atgriezts ar ārēja vaicājuma palīdzību, ja novākt apakšvaicājuma noteikumu) un t(rindu daudzums, kas tiek atgriezts ar pilnu vaicājuma, ieskaitot apakšvaicājumu palīdzības).Precizēts apakšvaicājuma filtrācijas koeficients ir vienāds t/q. Šajā gadījuma EXIST noteikums ļoti viegli tiek pārbaudīts. Datu bāze vienkārši meklē pirmo sakrišanu savienojuma indeksā.

44

3. Citādi, pussavienojumam, lai D –tas ir daļējais savienojuma koeficients. Lai s – korelācijas mezgla filtrācijas koeficients (mezgls, kas ir pievienots pie pussavienojumam saitēm) uz apakšvaicājuma piederoša galā.

4. Ja D≤1, tad precizēts apakšvaicājuma filtrācijas koeficients ir vienāds sxD5. Citādi, ja sxD<1, tad precizēts apakšvaicājuma filtrācijas koeficients ir vienāds (D-1+ +

(sxD))/D.6. Citādi, lai precizēts apakšvaicājuma korelācijas koeficients ir vienāds ar 0.99. Pat ļoti

slikti filtrētais noteikums EXIST patiešam ļauj izvairīties no rindas daudzuma palielināšanas un nodrošināt labāku filtrācijas uz vienu vienības mēroga vērtējumu, nekā savienojums uz leju vispār bez filtriem.

Tagad apskatīsim piemēru, kurā jāaprēķina korelācijas priekšrocības koeficientu un precizēt filtrācijas koeficientu att. 2.31, kurā nepietiek divus skaitļus.

AT

Att. 2.31. Saliktais vaicājums, kurā trūkst vajadzīgas vērtības pussavienojumam

1. Lai D =2 un M=1(šī skaitļa nav diagrammā). Lai S=0,015 (vislabākais filtrācijas koeficients starp visiem apakšvaicājumā koeficientiem, kas pieder tabulai S3, kurā atrodas uz divām līmeņiem zemāk daļējas saknes apakšvaicājuma D tabulas).Lai tagad R= 0,01, tas ir vienāds ar labāko filtra vērtējumu starp visiem koka mezgliem, zem daļējas saknes tabulas M ārēja vaicājuma, iekļaujot šīs mezgls.

2. Atradīsim DxS = 0,03 un MxR = 0.01, no tam seko ka DxS >MxR. Pariesim uz soli 3.3. Tā kā S>R, tad korelācijas priekšrocības koeficients ir vienāds S/R, tas ir 1,5.Lai atrast precizētu apakšvaicājuma filtrācijas koeficientu, jāizdara sekojoši darbības:1. Pievērsiet uzmanību, ka korelācijas priekšrocības koeficients ir lielāk nekā 1, tāpēc

nepieciešams pariet uz soli 2.2. Pievērsiet uzmanību, ka apakšvaicājums iekļauj dažas tabulas un satur filtrus, tāpēc

nepieciešams pariet uz soli 3.3. Atradīsim D = 2, un atradīsim filtrācijas koeficientu mezglam D, s=0,14. Tā kā D>1, nepieciešams pariet pie soli 5.5. Izrēķināsim sxD = 0,2, kas ir mazāk nekā 1, tāpēc precīzs filtrācijas koeficients var

izrēķināt sekojoša veida (D-1+(sxD))/D=(2-1+(0,1x2))/2=0,6

45

Diagrammas attēlošana NOT EXIST apakšvaicājumos

Apakšvaicājuma noteikumi, kuri var izteikt ar NOT EXIST vai NOT IN palīdzību, vienkāršāk neka apakšvaicājumi tipa EXIST, vienā attiecībā – nav iespējami pariet no apakšvaicājuma ārā pie ārēja vaicājuma. Tas novērst korelācijas priekšrocības nepieciešamību. Burts E, kurš norada uz apakšvaicājuma noteikumu EXIST, tiek aizvietota ar burtu N, lai apzīmēt apakšvaicājuma noteikumu NOT EXIST, un korelācijas savienojums tagad tiek nosaukts par Antisavienojumu, bet ne pussavienojums, tā kā tas ir paredzēts gadījuma meklēšanai, kad savienojumam ar rindām no apakšvaicājumā nevar atrast atbilstības.

Praktiski vienmēr apakšvaicājuma noteikumi NOT EXIST labāk izteikt ar NOT EXIST palīdzību, neviss ar NOT IN palīdzību.Apskatīsim sekojošais piemērs ar NOT IN apakšvaicājumu:

SELECT ...FROM ...Outer_Anti_Joined_Table OuterWHERE ...AND Outer.Some_Key NOT IN(SELECT Inner.Some_KeyFROM ... Subquery_Anti_Joined_Table Inner WHERE<savienojuma noteikumi apakšvaicājumam tabulām> )

Var un nepieciešams pārveidot šo piemēru ekvivalentā formā NOT EXIST:

SELECT ...FROM ...Outer_Anti_Joined_Table OuterWHERE ...AND Outer.Some_Key IS NOT NULLAND NOT EXIST (SELECT null FROM ... Subquery_Anti_Joined_Table Inner WHERE<savienojuma noteikumi apakšvaicājumam tabulām> AND Outer.Some_Key = Inner.Some_Key)

Lai pārveidot NOT IN uz NOT EXIST bez funkcionalitātes izmaiņām, nepieciešams pievienot noteikumu NOT null korelācijas atslēgām savienojumam ārējā tabulā.Apakšvaicājuma noteikumi EXIST un NOT EXIST pabeidz atbilstību meklēšanu uzreiz kad tik atradīts pirmās atbilstības, ja tāda eksistē. Vienmēr jāatceras sekojoši noteikumi, lai salīdzināt EXIST un NOT EXIST noteikumi, kuri norada uz daļējam tabulām no galvenās tabulās ārājā vaicājumā:- Neselektīva noteikuma EXIST pārbaudē nav dārga, bet tas atmeta nedaudz rindas no

ārēja vaicājuma. Jo vairāk rindas atgriež apakšvaicājums, jo lētāk un mazāk selektīva pārbaudē EXIST noteikuma. Ja noteikums EXIST ir selektīvs, tad tas pārbaudē iespējami ir dārgāk, tā kā līdz ar to jāizslēdz atbilstības katrai daļējai rindai.

- Selektīva noteikuma NOT EXIST pārbaudē nav dārga, un atmeta daudz rindas no ārējā vaicājumā. Jo vairāk rindas atgriež apakšvaicājums, jo lētāk un selektīvāk noteikuma NOT EXIST pārbaudē. No citas puses, neselektīvu noteikumu NOT EXIST pārbaudē tapāt dārga, tā kā katrai daļējai rindai ir nepieciešams apstiprinājums, kā neeksistē atbilstības.

46

Tā kā noteikumu NOT EXIST pārveidošana uz ekvivalenti parasti vaicājumi bez apakšvaicājumiem ir dārgi, un ne pārak lietderīgi, labāk izmantot apakšvaicājumi NOT EXIST uz abām antisavienojuma galam: tur kur atrodas galvena tabula un tur, kur ir daļēja.

Ļoti reti ir nepieciešamība alternatīvu veidu meklēšanu noteikuma NOT EXIST izteiksmes.Tā kā selektīvas noteikumus NOT EXIST pārbaudē nav dārga, rodas ka aprēķināt apakšvaicājuma precizēts filtrācijas koeficients ir viegli:1. Jāizmēra q (rindas daudzums, kuri tiek atgriezti ar ārējo vaicājumu palīdzību, ja nodzēst

apakšvaicājuma noteikumu NOT EXIST) un t (rindu daudzums, kura tiek atgriezta ar pilnu vaicājumu, iekļaujot apakšvaicājumu). Lai C – tas ir tabulas daudzums apakšvaicājuma nodaļā FROM (parasti NOT EXIST noteikumiem šī vērtība ir vienāda 1 ).

2. Lai apakšvaicājuma precizēts filtrācijas koeficients ir vienāds (C-1 +(t/q))/C.

Vaicājumu ar apakšvaicājumiem iestatīšana

Tāpat kā vienkāršiem vaicājumiem, sarežģītu vaicājumu ar apakšvaicājumiem optimizācija izpildās vienkārši, ja ir pareiza vaicājumu diagramma. Sarežģītu vaicājumu optimizācijas soļi:

1. Transformējiet visi noteikumi NOT IN uz ekvivalentiem noteikumiem NOT EXIST, sekojot agrāk aprakstītam šablonam.

2. Jā korelācijas savienojums tas ir EXIST tipa savienojums, un apakšvaicājums atrodas šī savienojuma galvenā galā, transformējiet sarežģītu vaicājumu uz vienkāršo, kā aprakstīts agrāk, un izmantojot noteikumus vienkāršiem vaicājumiem iestādiet to.

3. Ja korelācijas savienojums tas ir EXIST tipa savienojums, atradiet mazāko korelācijas priekšrocības koeficientu starp visiem EXIST tipa vaicājumiem. Ja koeficienta vērtība mazāk par 1,0, transformējiet šo apakšvaicājuma noteikumu uz ekvivalentu noteikumu IN un izteiciet visi pārēji apakškopas noteikumi EXIST tipa, izmantojot noteikumu EXIST. Optimizējiet nekorelētu vaicājumu IN, it kā tā būtu atsevišķs vaicājums, tas ir visa vaicājuma izpildīšanas plāna sākums. Pēc nekorelēta apakšvaicājuma apstrādes datu bāze izpildes kārtošanas operāciju, lai izmest korelēta savienojuma atkārtotus atslēgas no izveidota ar apakšvaicājumu saraksta. Nākamais savienojums pēc pirmās apakšvaicājuma apstrādes izpildās ar korelētu atslēgu ārējā vaicājumā , sekojot pēc šī savienojuma atslēga indeksa, kuram jābūt indeksētām. Sākot no šī punkta apstrādājiet ārējo vaicājumu, it kā vadošais vaicājums neeksistē un pirmais mezgls ir ārēja vaicājuma vadoša tabula.

4. Ja visi korelācijas priekšrocības koeficienti lielāk vai vienādi ar 1,0 vai vaicājumā ir tikai tipa EXIST apakšvaicājuma noteikumi, izvelēt vadošu tabulu no ārējā vaicājumā, kā ja tur nav apakšvaicājuma noteikumus, sekojot vienkārša vaicājuma parastam noteikumiem.

5. Kad tiksiet līdz ārēja vaicājuma mezgliem, kas iekļauj pussavienojumi vai antisavienojumi ar vēl neizpildāma apakšvaicājumiem, apstrādājiet katru apakšvaicājumu, tā ja tas būtu viens zemāk esošs mezgls. Izveliet palikta apakšvaicājuma izpildīšanas punktus, tā kā ja tajos virtuālos mezglos būtu filtrācijas koeficients vienāds precizētām apakšvaicājuma filtrācijas koeficientam.

6. Pēc 5 soli izpildīšanas, jāievieto korelētu savienojumu uz savienojuma secību, uzreiz izpildiet dotu korelētu apakšvaicājumu, optimizējot šī apakšvaicājuma izpildīšanas plānu, uzskatot korelācijas mezgli par šī neatkarīga vaicājuma mezgli. Izpildot šī apakšvaicājuma apstrāde, atgriezties pie ārēja vaicājuma un turpiniet optimizēt tālāko savienojumu secību.

47

Kā piemērs attēls 2.32., rada attēlu 2.31. ar uzradītu priekšrocības korelācijas koeficientu un apakšvaicājuma precizētu filtrācijas koeficientu.

Att.2.32. Sarežģīta vaicājuma ar apakšvaicājumu optimizācijas uzdevums.

Tā kā korelēts savienojums attiecas pie EXIST tipam, solis 1. neizmantojas. Tā kā bultas radītājs pussavienojuma vidu virzīts augšup solis 2 netiek izmantots. Vismazākais priekšrokas korelācijas koeficients vienāds ar 1,5 (blakus ar E), tāpēc solis 3 netiek izmantots. Izpildot solis 4, atradām, kā labākais vadošs mezgls ārējā vaicājumā - tas ir M. Izpildot soli 5, izvēlam starp lejup savienojumiem no A1 un A2 ar filtrācijas koeficientiem 0,2 un 0,7 un lejup virtuāliem savienojumiem ar virtuālu mezgli, radošu pilnu apakšvaicājumu, ar virtuālo filtrācijas koeficientu 0,6. A1 labākais no trim kandidātiem, kam ir labākais filtrācijas koeficients, tāpēc savienosim to ar sekojošu. Tā kā no A1 nav lejup savienojumus, nākama labāka izvēle savienošanas kartība uzskatam apakšvaicājumu (izmantojot soli 5.), tāpēc izpildām pussavienojumu ar D.

Izpildot soli 6, jau sakot apakšvaicājuma apstrādāšanu, nepieciešams to pabeigt, sākot ar D kā vadoša mezgla. Sekojot noteikumam vienkāršiem vaicājumiem tālāk pievienosim S1, S3, S2, un S4 noradīta secībā. Atgriežamies pie ārēju vaicājumu un izmantojot parasti noteikumi vienkāršiem vaicājumiem, atradām paliktas savienojuma secību kā A2, B1, B2. Pilnīga optimāla savienošanas secība, iekļaujot pussavienojumi –(M, A1, D, S1, S3, S2, S4, A2, B1, B2).

Vaicājumi ar skatiem

Izmantojot skatus, var izdarīt tā, lai ļoti sarežģīts vaicājums izskatījās kā parasta tabula.. Kad vairāki vaicājumi kopīgi izmanto SQL koda lielu skaitu, tad kopējas skati daudzkārtīgas izmantošanas var kļūt par spēcīgu mehānismu pielikuma koda vienkāršošanai. Apskatīsim vaicājumu 2 tipus, nozīmīgus iestatīšanas problēmai.

1. Vaicājumi, kas definē skatu.Tas ir vaicājumi, kas ir skata pamatā (vaicājumi, kas tiek izmantoti lai izveidot skatu ar palīdzību CREATE VIEW <Skata_vārds> AS <Vaicājums_definējošs_skatu>).2. Vaicājumi, kas izmanto skatus.Tas ir vaicājumi, kuras jūs iestājat un kuras datu bāze faktiski izpilda. Dotas vaicājumos skati tiek minētas FROM frāzē (Piem.: SELECT … FROM View1 V1, View2 V2, … WHERE …).

Var rasties 3 veida grūtības:

48

- Nepieciešams transformēt vaicājumus, kuri izmanto skatus uz ekvivalenti vaicājumi pie reālam tabulām, lai izveidot un optimizēt savienojuma diagrammas.

- Vaicājumi pie skatiem parasti satur nevajadzīgus vai liekus mezglus vaicājuma kodolā. Skata izmantošana nozīme pilna apakškoka izmantošanu. Bet izstrādātajam kurš izmanto skatu bieži ir nepieciešamas tikai dažas ailes no skata. Viņš var palaist daži mezgli un savienojumi vaicājumā, kas definē skatus, ekvivalenta vaicājuma izveidošanas laikā pie parastam tabulām. Kad pielikumam ir nepieciešami visi skata mezgli, vaicājums var pietiekami bieži rasties pie dotiem mezgliem, pievienojot tādas pašas rindas tādas pašas pamat tabulas dažādas kontekstos.

- Dažreiz vaicājumi, kas izmanto skati neiespējams izteikt kā ekvivalento vaicājumu pie vienkāršam tabulām. Parasti gadījumi, kad vaicājums, kurš izmanto skatu atgriež dažādus rezultātus no vaicājuma pie vienkāršas tabulas ir noslēpti un reti paradās. Ja vaicājums kas izmanto skatu, nevar viegli sadalīt uz ekvivalentu vienkāršu vaicājumu pie tabulām, ražotspēja bieži cieš, bet slēpti gadījumi satur kļūdas. Ražotspējas labošana nevar pieļaut pat nelielas funkcionālas izmaiņas.

Vaicājumu diagrammveida attēlošana, kas izmanto skatus

1. Izveidojiet diagrammu visiem vaicājumiem kas definē skatus, tā it kā tas ir atsevišķi vaicājumi. Tāda vaicājumu diagrammā jābūt viena daļēji saknes tabula un tikai virzītas lejup savienojumi “daudz-pret-vienu” no šī augšēja mezgla, attiecīgus koka struktūrai. Jā definējošs skatu vaicājums ne attēlojas uz vaicājuma normālu kodolu, tad vaicājumi, kas izmanto šo skatu strādās slikti un atgriezis nepareizus rezultātus. Par visa skata primāru virtuālu atslēgu jāuzskata primāru atslēgu saknes detaļu tabulas vaicājuma.

2. Izveidojiet vaicājumu diagrammu, kas izmanto skatu, uzskatot ka visi skati tas ir parastas tabulas. Savienojumam ar skatu jābūt bulta attiecīga skatam galā , tikai ja savienojums tiek izveidots ar skata virtuālu primāru atslēgu. Simboliski uzradiet filtrācijas noteikumi skatam vaicājumā, kurš izmanto skatu burta F veidā. Apvediet katru mezgli ar punktētu līniju.

3. Pagrieziet izmantojošu skatu vaicājuma diagrammu, izveidotu Solī 2., aizvietojot visi mezgli , kuri atbilst skatam, ar pilnu vaicājumu diagrammu, kurā definē skatu no pirmās soli. Pēc tam apvadiet ar punktveida līniju vaicājuma apakškoka, kurš definēs skatu. Jebkurš savienojums augšā pievienos pie definējošam skatu apakškokām, kā viņu daļējo saknes mezgls. Savienojumi, kuri atiet no skata lejup, var sākties no jebkura mezgla skatā, bet atkarība no tā kurā vaicājuma tabula kurā definēs skatu, satur ārēja savienojuma atslēgu. Jebkurš filtrācijas noteikums skatām kļūst par filtrējušu noteikumu attiecīga vaicājuma mezglā, kurš definēs skatu atkarība no tā uz kurā mezgla aile ietekme dotais noteikums. Atrodiet faktisku filtrācijas koeficientu līdzīgam noteikumiem.

Apskatīsim piemēru pamatotu uz augšējiem noteikumiem. Paņemsim divu skatu definējumu:

CREATE VIEW Shipment_V ASSELECT A.Address_ID Shipment_Address_ID, A.Street_Addr_Line1

Shipment_Street_Address_Line1, A.Street_Addr_Line2Shipment_Street_Address_Line2, A.City_Name Shipment_City_Name,

A.State_Abbreviation Shipment_State, A.ZIP_Code Shipment_ZIP,S.Shipment_Date, S.Shipment_ID

FROM Shipment S, Addresses AWHERE S.Dddress_ID=A.Address_ID

CREATE VIEW Recent_Order_V AS

49

SELECT O.Order_ID, O.Order_Date, O.Customer_ID,C.Phone_Number Customer_Main_Phone, C.First_Name Customer_First_Name,C.Last_Name Customer_Last_Name,C.Address_ID Customer_Address_ID, OT.Text Order_Status

FROM Orders O, CustomersC, Code_Translations OTWHERE O.Customer_ID=C.Customer_IDAND O.Status_Code = OT.CodeAND OT.Code_Type = ‘ORDER_STATUS’ AND O.Order_Date>SYSDATE-366

Solis 1 Prasa diagrammas izveidošanu abām vaicājumiem, kas definē skatus (att.2.33). Diagrammu izveidošanai tika izmantota metode no 1 nodaļas un tika izmantota tāda paši filtrācijas un savienošanas koeficientu statistika (att.1.5.).

Att. 2.33. Vaicājumu diagramma vaicājumiem, kas definē skatus.

Tā izskatās vaicājums kas izmanto skatu:

SELECT OV.Customer_Main_Phone, C.Honorific, OV.Customer_First_Name,OV.Customer_Last_Name, C.Suffix, OV.Customer_Address_ID,SV.Shipment_Address_ID, SV.Shipment_Street_Address_Line1,SV.Shipment_Street_Address_Line2, SV.Shipment_City_Name,OD.Item_Count, ODT.Text, P.Product_Description, SV.Shipment_Date

FROM Recent_Order_V OV, Order_Details OD, Products P, Shipment_V SV,Code_Translations ODT, Customers C

WHERE UPPER (OV.Customer_Last_Name) LIKE :last_name||’%’ AND UPPER (OV.Customer_First_Name) LIKE :first_name||’%’AND OD.Order_ID=OV.Order_IDAND OV.Customer_ID=C.Customer_IDAND OD.Product_ID=P.Product_ID(+)AND OD.Shipment_ID=SV.Shipment_ID(+)AND OD.Status_Code=ODT.CodeAND ODT.Code_Type = ‘ORDER_DETAIL_STATUS’ORDER BY OV.Customer_ID, OV.Order_ID Desc,SV.Shipment_ID,OD.Order_Detail_ID

Solis 2. Izveidosim sakuma vaicājumu diagrammu tā kā tā būtu paradīta kā parastas tabulas , kā paradīts att.2.34.

Att.2.34. aizvietosim visus mezglus ar vaicājumu diagrammām, kas definē skatus ,no att. 2.33. Bet vaicājumu kodoli apvilksim ar punktētu līniju, lai apzīmēt skatus ierobežojumus.

Pievienosim kodolus pie paliktas pilnas vaicājumu diagrammas daļai pie piemērotām mezgliem, atkarība no tā kāda tabula no skata definējuma satur savienošanas atslēgu. Parasti jebkuri savienojumi ar skatiem augšā saistīti ar daļēju saknes tabulu, kas definē vaicājuma skatu.

Mezgli, kas pārstāv galvenās tabulas, kuras atrodas zem skatiem (piemēram C mezgls attēlā 2.34.), var būt pievienoti pie jebkura kodola mezgli skatu definējuma, atkarība no tā kāda tabula satur ārēju atslēgu, kurs uzrada uz galveno mezgli. Pievienosim skaitļi visiem mezgliem

Vaicājums kas definē Shipment_V skatu

Vaicājums kas definē Order_V skatu

50

vaicājuma kodolā, kuram ir filtri gan definējoša skatu vaicājuma, gan izmantojošo to vaicājumā. Attēlā 2.34. filtrācijas koeficients 0,3 blakus ar O mezgli paradās pateicoties filtram, bet filtrācijas koeficients 0,0002 ar C mezgli pateicoties noteikumiem uz vārdu un uzvārdu.

Att. 2.34.Nepaplašinata vaicājumu diagramma, kas izmanto skatu

Rezultāts attēlots zīmējumā 2.35. Zvaigzne pie kreisa C mezgla parada atšķirību starp mezgliem ar vienādiem nosaukumiem. Jāizmanto statistiku filtram pēc pircēja vārda , lai iegūt filtrācijas koeficientu 0,0002 blakus ar C.

Att. 2.35. Paplašināta vaicājumu diagramma, kas izmanto skatu.

Diagramma ir pabeigta.

Vaicājumu ar skatu iestatīšana

Četras problēmas kuras jārisina lai sastādīt optimālu vaicājuma izpildīšanas plānu.Dažādi savienojumi ar sarežģītiem skatiem grūti iedomāt kā parasti savienojumi ar vienkāršam tabulām. Ārēji savienojumi ar skatiem, kuras ir savienojumi vaicājumos, kas definē skatus, grūti izteikt izmantojot vienkāršus savienojumus.

Daži skati izmanto tādas pašas tabulas rindas ,ka cita tabula vaicājumā, kura tiek izmantoti skati, kas savukārt izveido lieku darbu datu bāzei, tas būs nepieciešams novērst. Tas notiek ar mezgliem C un C* attēlā 2.35 (Šo problēmu apskatīsim vēlāk)

51

Skatu priekšrocība ir tāda kā tas slēpj vaicājumu sarežģītību, tā priekšrocība atļauj arī nemanāmi izveidot liekas saites kodā, kura būtu skaidri un prasīja daudz darbības ar kodu, ja izstrādātāji izmantoja tikai vienkāršas tabulas.Mezgli definējošo vaicājumu skata iekšā un savienojumi ar tiem bieži var būt nevajadzīgi rezultātu iegūšanai, nepaciešamo vaicājumā kas izmanto skatu.Skata izmantošana ierobežo iespējas vadīt izpildes plānu. Jā izmainīsim definējošu skatu vaicājumu, lai uzlabot vaicājuma izpildes plānu, tad varat pasliktināt citu vaicājumu ražotspēju, kas izmanto to pašu skatu. Jūs vienmēr varat izveidot jaunu skatu tikai viena vaicājuma izmantošanas ērtībai, bet tas ir skata priekšrocības pretruna, kas iekļauts kopīga koda izmantošana. Dažreiz nepieciešama plāna iegūšanai nepieciešams izslēgt skatu izmantošanu.

Ārēji savienojumi ar skatēm

Atgriežoties pie iepriekš piemērā, apskatīsim, kas nozīme ārējas savienojuma esamība ar Shipment_V skatu, kurš ir iekšējais savienojums starp Shipments tabulu un Addresses tabulu. Tā kā datu bāze jāuzskata , kā eksistē reāla tabula ar tieši tādam rindām, kuras atradis skats, savienojums paradis iekšēju savienojumu Shipment_ID vērtībām, kuras ir Shipments un uzrada uz piegādēm, pēc Address_ID priekš kuram veiksmīgi savienojas ar tabulu Addresses. Ja datu bāze nevar veikt veiksmīgu savienojumu vienlaicīgi gan ar Shipments, gan ar Addresses, tad savienojums ar skatu kļūst pilnīgi ārējs, pat ja pirmais savienojums ar Shipments varēja būt veiksmīgs.

Plāna meklēšanas laikā ar iekļautam ciklam datu bāze nevar zināt, vai būs ārējai saitei atrasts iekšējais gadījums, kamēr netik izveidots veiksmīgs savienojums ar abām tabulām definējoša skatu vaicājumā. Diemžēl tas ir pārāk sarežģīti un datu bāze vienkārši var atteikties meklēt plānu ar iekļautiem cikliem. Datu bāzes serveris saprot, kā nav tik ļoti svarīgi cik sarežģīta ir loģika vaicājuma pamatā. Dota loģika nevar funkcionāli pieļaut kļūdas, ja vienkārši iegūs visas rindas no vaicājuma, kas definē skatu un apstrādā rezultātu kā reālu tabulu. Ārējām savienojumam ar datu bāzes skatu parasti izpilda savienojumu ar kārtošanas metodi saplūšanu vai jaukšanas savienojumu ar laicīgi izveidotu tabulu. Tas ir pietiekami droši funkcionalitātes jomā, bet parasti ne īpaši labi ražotspējai, izņemot tādus gadījumus, kad pats vaicājums ir pietiekami ātrs.Par pamat noteikumu ražotspējas labošanai izvairiet ārēji savienojumi ar jebkuram skatēm, sarežģītākiem nekā SELECT <Vienkaršu_stabiņu_saraksts> FROM <Viena_tabula>.

Līdzīgas problēmas rodas visiem savienojumam ar skatēm tipiem, kurās definējošā vaicājuma skata ir UNION vai GROUP BY. Tomēr, izejoši savienojumi no līdzīgam skatēm, kad tajos ir tabula kuru var izvelēt ar vaicājuma vadošu tabulu, parasti strādā labi.Apskatīsim vaicājumu kurš izmanto skatu, no iepriekšēja apakšskata. Jā ievietot definējošu skatu vaicājumu Shipment_V vaicājumā, kurš izmanto skatu, lai atrisināt ražotspējas problēmu ar ārēju savienojumu, tad droši vien iznāks sekojošais rezultāts:

SELECT OV.Customer_Main_Phone, C.Honorific,OV.Customer_First_Name,OV.Customer_Last_Name, C.Suffix, OV.Customer_Address_ID,A.Address_ID Shipment_Addres_ID,A.Street_Addr_Line1 Shipment_Street_Address_Line1,A.Street_Addr_Line2 Shipment_Street_Address_Line2,A.City_Name Shipment_City_Name, A.State_Abbreviation Shipment_State,A.ZIP_Code Shipment_Zip, OD.Deferred_Ship_Date, OD.Item_Count,ODT.Text, P.Prod_Description, S.Shipment_Date

FROM Recent_Order_V OV, Order_Details OD,Products P, Shipment S,Addresses A, Code_Translations ODT, Customers C

52

WHERE UPPER (OV.Customer_Last_Name)LIKE :last_name||’%’AND UPPER (OV.Customer_First_Name)LIKE :first_name||’%’AND OD.Order_ID=OV.Order_IDAND OV.Customer_ID=C.Customer_IDAND OD.Product_ID=P.Product_ID(+)AND OD.Shipment ID=S.ShipmentID(+)AND S.Address_ID=A.Address_ID(+)AND OD.Status_Code=ODT.CodeAND ODT.Code_Type=’ORDER_DETAIL_STATUS’ORDER BY OV.Customer_ID, OV.Order_ID Desc, S.Shipment_Id, OD.Order_Detail_ID

Diemžēl šis kods neatļauj iegūt tādu pašu rezultātu, kā izejas vaicājums, ārēja savienojuma ar skatu specifikas dēļ. Izejas vaicājums atgriež vērtību Shipment_Date vienādu ar NULL, ja pilnais skats iekļaujot savienojumu ar Addresses nevar veiksmīgi savienotie ar Order_Details. Tad, ja Shipmentām nav uzradīta pieļaujama nevienāda ar NULL vērtības Address_ID, izejas vaicājums atgriež NULL Shipment_Date, neskatoties uz to kā savienojums ar Shipment ir pieejams.

Droši viens tāda uzvedība nebija domāts izstrādātajam, un tajā nav funkcionālas nepieciešamības, tāpēc jauna forma droši vien strādās labi. Tomēr jebkura funkcionalitātes izmainīšana, ražotspējas labošanai ir bīstama. Pirms izveidot pārmaiņas jāpārliecinās ka viss strādās pareizi. Diez vai jums būs nepieciešams tieši izejoša vaicājuma uzvedība, bet ja gribat būt uzmanīgi varat emulēt izejas vaicājuma funkcionalitāte ar tādu kodu:

SELECT OV.Customer_Main_Phone, C.Honorific,OV.Customer_First_Name,OV.Customer_Last_Name, C.Suffix, OV.Customer_Address_ID,

A.Address_ID Shipment_Addres_ID,A.Street_Addr_Line1 Shipment_Street_Address_Line1,A.Street_Addr_Line2 Shipment_Street_Address_Line2,A.City_Name Shipment_City_Name, A.State_Abbreviation Shipment_State,A.ZIP_Code Shipment_Zip, OD.Deferred_Ship_Date, OD.Item_Count,ODT.Text, P.Prod_Description,DECODE (A.Address_ID, NULL, TO_DATE(NULL),

S.Shipment_Date) Shipment_Date

FROM Recent_Order_V OV, Order_Details OD,Products P, Shipment S,Addresses A, Code_Translations ODT, Customers C

WHERE UPPER (OV.Customer_Last_Name)LIKE :last_name||’%’AND UPPER (OV.Customer_First_Name)LIKE :first_name||’%’AND OD.Order_ID=OV.Order_IDAND OV.Customer_ID=C.Customer_IDAND OD.Product_ID=P.Product_ID(+)AND OD.Shipment ID=S.ShipmentID(+)AND S.Address_ID=A.Address_ID(+)AND OD.Status_Code=ODT.CodeAND ODT.Code_Type=’ORDER_DETAIL_STATUS’ORDER BY OV.Customer_ID, OV.Order_ID Desc,

DECODE (A.Address_ID,NULL, TO_NUMBER (NULL), S>Shipment_ID),OD.Order_Detail_ID

Dota vaicājumā ir divas izmaiņas, kuri piespiež vaicājumu atgriezt rezultātu. Izteiksme DECODE SELECT saraksta beigās un ORDER BY saraksta vidū piespiež pirma savienojuma

53

iekšēju gadījumu emulēt ārēju savienošanas gadījumu, neatkarīgi to tā vai būs savienošanas gadījumā ar Addresses atrasts ārējais gadījums.

Labāk izmantot skatus vienkāršu tabulu vietā gadījumos kad ir nepieciešamības apiet ierobežojumus automātiski ģenerētām SQL kodām. Izplatītāka apiešana ir noslēpt dotu sarežģītību definējošā skatu vaicājumā. Tāda gadījumā var neiznākt izbēgt no skatiem. Tad ir alternatīva pieeja - paplašināt skata izmantošanu noslēpot vairāk SQL skata definējumā.

CREATE VIEW Order_Detail_V ASSELECT A.Address_ID Shipment_Address_ID,A.Street_Addr_Line1 Shipment_Street_Address_Line1,A.Street_Addr_Line2 Shipment_Street_Address_Line2,A.City_Name Shipment_City_Name, A.State_Abbreviation Shipment_State,A.ZIP_Code Shipment_ZIP, S.Shipment_Date, S.Shipment_ID,OD.Deferred_Ship_Date, OD.Item_Count, OD.Order_ID,OD.Order_Detail_ID, OD.Product_ID, OD.Status_CodeFROM Shipments S, Address A, Order_Details ODWHERE OD.Shipment_ID = S.Shipment_ID(+)AND S.Address_ID = A.Address_ID(+)

Tad vaicājums, kas izmanto paplašinātu skatu, kļūs par tādu:

SELECT OV.Customer_Main_Phone, C.Honorific, OV.Customer_ID,OV.Customer_Last_Name, C.Cuffix, OV.Customer_Address_ID,ODV.Shipment_Address_ID, ODV.Shipment_Street_Address_Line1,ODV.Shipment_Street_Address_ID_Line2, ODV.Shipment_City_Name,ODV.Shipment_State, ODV.Shipment_Zip, ODV.Deferred_Ship_Date,ODV.Item_Count, ODT.Text, P.Prod_Description, ODV.Shipment_DateFROM Recent_Order_V OV, Oredr_Detail_V ODV, Products P,Code_Translations ODT, Customers CWHERE UPPER (OV.Customer_Last_Name) LIKE : last_name|| ‘%’ AND UPPER (OV.Customer_First_Name) LIKE : first_name|| ‘%’AND ODV.Order_ID = OV.Order_IDAND OV.Customer_ID = C.Customer_IDAND ODV.Product_ID = P.Product_ID(+)AND ODV.Status_Code = ODT.CodeAND ODT.Code_Type = ‘ORDER_DETAILS_STATUS’ORDER BY OV.Customer_ID, OV.Order_ID Desc, ODV.Shipment_ID, ODV.Order_Detail_ID

Lieki nolasīšanas vaicājumos kuri izmanto skatus

Tagad apskatīsim savienojumu gadījums kurs attēlots attēlā 2.35. apzīmētam ka C* un C, Šie mezgli pārstāv vienu un to pašu tabulu ar vienādiem savienojuma operatoriem, tāpēc jebkurš izpildes plāns, kurš iekļauj abi mezgli, ir lieks, viņš nolasa vienas un tādas pašas tabulas rindas, un iespējams, ka indeksus arī, divreiz. Otra nav vajadzīga nolasīšana jebkura gadījuma nevar prasīt fizisku ievade vai izvade, jo tas jau tika izpildīts, jāievieto tabulas bloku vai indeksu uz kopēju izmantotu kešā galvu.

Kāda veida mēs varam izvairīties no lieka savienojuma ar tabulas Customer? Ir trīs varianti:

1. Pievienot jaunas nepieciešamas ailes uz SELECT ierakstus vaicājuma, kas definē skatu, un izmantot tos atsauces vietā liekas tabulas ailē vaicājumā, kas izmanto skatus. Tas ir

54

droši citam vaicājumam, kuram ir vajadzīgs tāds pats skats, tā ka visi izmaiņas iekļauj tikai ailes pievienošanu, neviss diagrammas modificēšanu definējoša vaicājuma skatu.

2. Izslēgt liekus savienojumus no vaicājuma, kas definē skatu, un izmanto tikai ailes no parastas tabulas mezglā vaicājumā, kas izmanto skatus. Tomēr, tas nav droši, ja eksistē citi vaicājumi kas izmanto skatus, kuram var būt vajadzīgi izslēgtas skata ailes.

3. Novērst skatu no vaicājuma, kas izmanto skatus, aizvietojot to ar ekvivalentiem neliekiem savienojumiem ar parastam tabulām.

Kopas operācijas ar vaicājumiem

Dažreiz jums nākas iestatīt saliktie vaicājumi, kuras tiek izmantotas kopas operācijas, tādas ka UNION, UNION ALL, INTERSECT un IXPECT divas vai vairāku parastu vaicājumu rezultātu kombinēšanai. Izveidojiet diagrammu un iestatiet šos daļas kā atsevišķi vaicājumi. Ja atsevišķas daļas strādā ātri, tad kombinēti rezultāti ar grupas operācijas palīdzību strādā labi.

Tomēr dažādiem operācijām jāpievērš lielāku uzmanību. Operācija UNION, izņemot daļas kombinēšanas, jāmāk šķirt atmest dublikātus.

Pēdējais solis bieži nav vajadzīgs, īpaši ja visas daļas tiek izstrādāti tā, lai no paša sakuma izvairīties no atkārtojumiem. Oracle operāciju UNION var aizvietot ar UNION ALL operāciju, ja jūs atradīsiet ka dublikātu esamība neiespējama vai dublikātus nevajag dzēst.

Operāciju INTERSECT parasti sekmīgi var aizvietot ar apakšvaicājumu EXIST tipa, kurš meklē piemērotu rindu, kuru varētu paradīt otra daļa. Piemēram ja jums ir divas tabulas Employees, jūs varat izdarīt meklēšanu kopīgi izmantotus darbinieku sarakstu ar :

SELECT Employee_ID FROM Employees1INTERSECTSELECT Employee_ID FROM Employee2

Vaicājums INTERSECT vienmēr var aizvietot sekojoši:

SELECT DISTINCT Empoyee_IDFROM Employees1 E1WHERE EXIST (SELECT nullFROM Employees2 E2WHERE E.1Employee_ID = E2.Employee_ID)

Izmantojot metodes, kas tiek aprakstīti nodala “Vaicājumi ar apakšvaicājumiem”, jūs varat definēt, vai ir vajadzīgs apakšvaicājumu tipa EXIST izteikt EXIST formā vai IN vai transformēt to uz parastu savienojumu.

Pievērsiet uzmanību, ka korelācijas savienojuma noteikumi stipri paplašinājās, ja SELECT sarakstā ir daudz elementus.

Tapāt pievērsiet uzmanību, ka INTERSECT ievietos attiecīgi ailes sarakstām vērtības null, kas ne taisīs korelācijas savienojumu, ja tikai jūs neuzradīsiet savienojumu noteikumu speciāli dotām mērķim.

Piemēram, ja pozitīvam arējām atslēgām Manager_ID ir pieļauta vērtība null(bet vērtība Employee_ID nevar but null), tad Oracle vaicājumā vieta var izmantot ekvivalentu vaicājumu.

Vaicājums:

SELECT Employee_ID, Manager_ID FROM Employees1INTERSECTSELECT Employee_ID, Manger_ID FROM Employees2

Ekvivalentais vaicājums:

55

SELECT DISTINCT Employee_ID, Manager_IDFROM Employees1 E1WHERE EXIST (SELECT nullFROM Employees2 E2WHERE E1.Employee_ID = E2.Employee_IDAND NVL (E1.Manager_ID, -1) = NVL (E2.Manager_ID, -1))

Izteiksme NVL(... , -1) otrā korelācijas savienojuma noteikuma pārveido vērtību null ailes, kur tas ir pieļauts, lai, kad vērtību null salīdzina ar null, savienojums tika veiksmīgi izveidots.

Operāciju EXEPT (vai MINUS) parasti var veiksmīgi aizvietot ar NOT EXIST apakšvaicājumu. Ieraksta darbiniekus meklēšanai pirmā tabula, bet ne otrā, var izmantot šo vaicājumu:

SELECT Employee_ID FROM Employees1MINUSSELECT Employee_ID FROM Employees2

Bet šo vaicājums vienmēr var aizvietot ar citu vaicājumu:

SELECT DISTINCT Employee_IDFROM Employees1 E1WHERE NOT EXIST (SELECT nullFROM Employees2 E2WHERE E1.Employee_ID = E2.Employee_ID)

Un tad vaicājums var apstrādāt, izmantojot metodes, kuri tika aprakstīti nodala “Vaicājumi ar apakšvaicājumiem”.

56