Chapter 23: Advanced Application Development

صفحه 1:
+ Ohopter CO: Odvawed Opplowva Devebbpwedt يدف !» م۳۲) ‎Cerhorne Bractworks‏ للم ‎€-Cowwerce‏ سرت مسا |۱۳ Gyetre Oocowytr, Oe. ‏موه‎ 

صفحه 2:
@erPorcowwe Pusey © Odyetey vorivus pocneeters ued desiqa choives to koprove systew perPorwaure Por ‏تاو و‎ application. © Dunia is best dour by dee acy bottoms, ered ۲ Ooo tee o database systew ut 9 levels! © ‏روت - یلم‎ odd dishes to speed up VO, odd wewory to eorewse ‏اه‎ hits, wove too Poster processor. © Oonber systew poraweters — ey, set bPPer size to avoid porcine oP ‏موی ابو ,الط‎ iotervals to het log stze. Gystew way have ۱ سس له وله ماه اعد تسه رو هل امه لب ۶ ‎(svore hater)‏ سا0 لح 0 لا سواه 1 هوه ‎@eedrwr Gyetre Oocowytr, Oe.‏ 

صفحه 3:
@vtlewvhs Bl PerPorenee of covet systews (ot feast bePore ey ore heed) usu beoted by ‏مور‎ oP par ‏الط سوه وا نت و‎ © Cy. OO% of the oode way the wy CO% oF teve ond CO% oF core tohes ‏صم خام 0096© جنب‎ » Oot speadiay wet thee va CO% oF code tho tke OD% oF tere © @otleuechs wy be ia hardware (ey. disks ore very busy, CPO is ide), or it Pare © Rewoutey ove botleueck Pec exposes coher © Oe-butlecechioy cousisis oP ‏رم لو اساسا بل رل‎ thew © Dhis eo heuristic سا0 لح 0 لا سواه 1 ووه ‎Od.‏ ,تن 6 تیه 

صفحه 4:
امسطاه() بهز سل و ‎ey. CPO, Ork VO, lochs‏ © Bt coocurred trocsuniives, trocronives way have to uvat Por requested service while viher treocsaniogs are bet served ۲ Con cordel dacbase wo quewekny pyeiew wih a quer Por pack service ‏بو‎ epcd oe te benny ۱ ‏مور‎ a genice, wal kr queue Por the service, oad cpt serviced Bl Ootleurvke na thisbose systiew typed shaw up os very ksh ‏اجم) تلف‎ ‏امه‎ very bri sueves) oP 3 pariadar service © Cy. deb ve OPO ihren © 100% uikzatcn leads to very booy waiter the! * Rue oP thu: design systew Por ubout PO% vizatics ot peak brad ۱ ‏ره شحف‎ OO % should be avoided ‎Od. coe ©Sbervehnts, Cork ced Cnakershe‏ ,تن 6 تیه 

صفحه 5:
CPU manager ۵ disk manager 5 6 ©Sbervehnts, Cork ced Cnakershe page page reply page request page reply concurrency control 6 ... 6 lock lock request grant transaction manager manager request J buffer manager| 9 transaction monitor 2 fransa source ‎Od.‏ ,تن 6 تیه ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ 

صفحه 6:
لس ‎oF‏ یی ‎of sckewa‏ یی ‎“Dariery oF torches‏ ‎views:‏ ای ۴ یی شمسا (ه یی ‎|۱۳ Gyetre Oocowytr, Oe. ‏هوه‎ 

صفحه 7:
+ ‘ang oP Dardare ۲ ‏میا مامت‎ ypicdly resuiire o Pew VO opercticces © Dyed disk supports obo (DO radon VO vpercicas per sevicnd © ‏و مس ام موی‎ het © rondo VO operstiows. Phen t SATO ‏ور ماو‎ second, we ceed ‏مه مد سوه و‎ 0 choker (roi shew) ۲ ‏ات(‎ of VO vperciogs per trowsuniion coc be reduced by keepin wore dota fe ewer 09 dichta ts to wewery, VO ceeded poly Por wrties © Qeepioy Prequedy used dota ewe wory reduces disk usvesses, neduricny sanvber of disks required, but has a wewory ost ‎Od. 007 ©Sbervehnts, Cork ced Cnakershe‏ ,تن 6 تیه 

صفحه 8:
+ ‏یی مورا‎ Pve-Dinie Rue Question! whick dota to heep to wewory: 0 Rape tp wcessed aes per seri, keeping i kr ewory ‏جمد‎ ‎۱ ‏و‎ preeperdeh-dive ‏سوم لوهجم سوه‎ © Cost ‏ی و و مسا‎ ۱ ‏سس هه‎ 4 ۱ ١ ۱۳ ‏یه‎ ore wore thea savin is qreuier tras ost © ‏مرول بو‎ equaice wits cuneot disk oad wewory prices leads to: © ‏عانواج-‎ rule! Pa page thot ts roadowly averse ts used wore Prequel thao pur tt S coitus t shoul be kept to ewory ۱ (by buen PPced wer!) سا0 لح 0 لا سواه 1 هوه ‎@eedrwr Gyetre Oocowytr, Oe.‏ 

صفحه 9:
+ Dorkuvae Taxing ‏ات(‎ Cle © Por seqedtdly averse dota, wore pages co be read per ‏امه‎ ‏رممجو)‎ sequedtd reads oF (D® of dota of ‏صم و‎ Chote rue! sequeuidly woepeed dota thot te weed Due or wore fo wine should be kept ‏وی و‎ B® Crives of disk ood wewory hove choayed qrediy ver the years, but the ‏وص‎ ‎eve ‏اس اهب‎ © so nites ‏له عم 9 وه و‎ cima nies, oot ۱ ‏او )مج سح‎ nies! سا0 لح 0 لا سواه 1 هوه ‎@eedrwr Gyetre Oocowytr, Oe.‏ 

صفحه 10:
+ Aartuae Ture: Oboe oP ROW Level 18 Powe ROW dow ROW S? © Depecds vo rotio oP reads oad wrtes * RO1W S rexnires © block reads ood O block writes to wart pul oe data blocs 4P oo opphouive requires rreads ond w writes per ‏امه‎ ‎© ROW Creqires r+ Gw VO operciows per seven © ROW S requires: r+ Pw WO vperctioas per sevoed ۲ ۵ ‏را‎ berger ond w, this requires lots oP disks to hoard workicad © ROW 8 ww require wore debe thas ROW (1 te bode bred! © Opporedt saviey of cunvber oP disks by ROW S (by vet poriy, oo vpposed to he wirrortay door by ROD ٩( way be thisory! ۲ ‏تب ایا‎ ROW S ts Poe whe writes ore rore ood dota is very karye, but RO10 Cis prePerdble verwise ©1P pow ceed wore disks ty hood VO load, just ‏و‎ thew ste dst ‏موی‎ these days ore rors! سا0 لح 0 لا سواه 1 مدمه ‎@eedrwr Gyetre Oocowytr, Oe.‏ 

صفحه 11:
+ Tray be 60 Deviqa ۲ ‏سای‎ ‎© Oertcdly partion rektiows ty teokte the dota thot fr accessed covet ‏تا - ماه‎ hare Berk echt ١ ‏و2‎ spi ‏صد محدم‎ hun, (azevabnnrber, brmetecnnce) ord (orem ‏لا طلسم‎ © Orowk-orwe ued ant be Petched uddess required © epee perPorwoue by storia o dewwrwdzed rekon ۰ Cox, store pre oP ‏مومس‎ deposi; brouh-unee od bok ‏جز‎ repedted Por euck holder oP oc acount, but pit ceed ont be ‏.نبل رو امه‎ © rice ‏او وب و لو وه و لو‎ keep ‏لو من موه مه‎ © beter to wee ‏لحطت‎ views (swore ‏مج‎ thts kiter..) © ‏سای مان‎ oo the socve disk page revords that woud swatch too Prequecly required jit, 0 poopie pis very ePPictedly wheo required. سا0 لح 0 لا سواه 1 موه ‎Od.‏ ,تن 6 تیه 

صفحه 12:
+ Arte te Orie Devtea (Onc) 8 ‏ی یا‎ © Create upproprie ‏حلاص ناد و لو و ول‎ © Opeed up sl updies by rewoviey excess tides (iedeoPP between queries coed updates) © Choose type oP ‏(جاصدا| عست ()) »صلم‎ oppropricie Por covet Prequedt ives oP ‏سب‎ ‎© Choose ‏لاه سل وا ی ات‎ ‏هر ها سور ما‎ queries cred arches (hee wrorhbror) crt ‎be best Por the uorbived‏ لت اه ات جوم مور ‏سا0 لح 0 لا سواه 1 مدمه ‎@eedrwr Gyetre Oocowytr, Oe.‏ ‎ 

صفحه 13:
+ Arte te Orie Devtea (Onc) 00 ‏لصحام ده‎ Otrws 19 ‏ونيصب لوطا صه17)‎ cos kelp speed up certs queries © Conickody ‏وی‎ queries 198 ‏مرن‎ ‎© Cpe © Dee Por ‏من ری‎ ۱ ‏لو‎ view wotdteatare door as port oP upc peor ‏مس ول برط لور اوه و‎ * OePered ‏اج ات رن و موی رن‎ ‎tkoe is spect oct view‏ مود لا ماه و ها متس لیس مس ‎> vot updated, the view way be ‏صمل ايج‎ ‎© rePerble ‏اد‎ schews siwe view wonton ‏و و راهم ومجويه جا‎ © ‏و‎ ‏سا0 لح 0 لا سواه 1 ووه ‎Gyetre Oocowytr, Oe.‏ ۱۳| 

صفحه 14:
+ Arte te Orie Devtea (Onc) © Wow to chose ot oF wotertaized views © ‏راصنا‎ poe irresunion type by tairoductoy ot wotertiized views ay burt others © Choice oP wotertdized views depends va costs + ‏ماه جوو()‎ have oo ideo oP ‏اوه اجه‎ oP operatic © Overt, wodudl seleviog of wotertazed views ib ted © Gowe dotobuse sysiews provide tools to hely DBO choose views to wutertaize © “Qatertazed view seleviva wizards” سا0 لح 0 لا سواه 1 جومه ‎@eedrwr Gyetre Oocowytr, Oe.‏ 

صفحه 15:
Try oP Traswirw Bose approaches te tuctay oF trocsuntions: ۶ ‏مس همم‎ © Reduce ‏ما سا‎ ۱ 3 ta he post, bul sort ppruiaers hove wore is keve Reporter § Coun ‏بل رهم لو تون‎ overheuds siqaPicad pad oP cost of ‏أ اس‎ ۶ ‏مین‎ wuliple ewhedded GALIODBONOBO qurter tie a stage sot prievied query ‏او و سل رح من بر‎ ١ ‏برق‎ hee progr ‏منت سد جرصصت اكلا‎ scary Por puck depurkoea! usta a separ (QL query by ‏د موی تمس‎ singe query ‏رم‎ total pokes Por dl deparkoedt of mare (usin pup by) © Ope viored procedures: words re-porsieg ued repped oP query سا0 لح 0 لا سواه 1 دوه ‎Od.‏ ,تن 6 تیه 

صفحه 16:
+ Tarik ob Trex (Clock) © Reductay lock ‏ی‎ BE Loo ixxeuntons (ypidy rented) fro exaoie kee pore of a rekiioa rem ‏تفت ساب‎ wil wpa manele © Coy, eve query te cowpute back ‏اه‎ ced ‏سس وا لو‎ © Po reker ‏ی‎ ‎۶ ‏امه ترجه هل عو()‎ ۱ ‏موی" عامو() ب)‎ whick ‏محص ی سوه‎ 06۳ © Doe deuree-wwy rawisewy (oursuretdbity) ‏امس نما بو‎ * Orawback: result way be apprentice @eedrwr Gyetre Oocowytr, Oe. e010 ©Sbervehnts, Cork ced Cnakershe 

صفحه 17:
+ Tarik ob Trex (Clock) Lowy update ‏وه‎ couse severd probews © ‏و بسا سمل‎ ۶ ‏سوب ملق‎ ۱ ‏اه سا زرم بو رای وه لو‎ a crack, ood way ever exhaust oy space durtay recovery ۶ ‏لول رل ع مه توص‎ © Ose whotbuck trensurious ty kei ‏ان ماو‎ updates thot o stage iraosaricg cot ‏مج ها موه و( رود اه روم‎ updates every record of avery kee vetaiog, lox ‏سا ما سح بو‎ اه و روط ای رام ‎Gplt lorge trocsuntiva fete butch oP‏ * ول دا بقاطمص جد عسجب صا عاج ايه ‎old locks oacoss trocsunives foo‏ * OP lock table size ‏اه نها راما سا موی ارام و وا‎ oost of 4 ۱ رارف عسصی ۱ ررو و مه مور رو ‎Od. eon? ©Sbervehnts, Cork ced Cnakershe‏ ,تن 6 تیه 

صفحه 18:
و۵ یبط + © Perforwouwe ‏اصلصصم صا تخاصوص أصلججد عمتجي عدص وصامان همات‎ botlecerks os wel wus the ef Pens oF tucioy charges, evra wihoul access to red ‏موه‎ © Qeevicy wodel oe we saw porter ۶ ‏نا منت له(‎ yp vata parcel © Gieukaica worded is quite ‏نوا وه ی را نا ,اجان‎ bevel deta © Oodel service tre, but dereqard details oP service © ‏ام ال موه مه رو توا ول موه و‎ tke © xpertweds cas be roa vo woe, ood provide oo estate of weusures suck se wenn ‏ووم جودسوجب نومه‎ ۲ Cannes con be tuced to wodel oad thea repliccied it red syste © ‏ام بر‎ of debs, wewory, ckpritews, eto سا0 لح 0 لا سواه 1 دوه ‎Od.‏ ,تن 6 تیه 

صفحه 19:
@erPorwawe Orwkwarks ۲ Gates oP tasks used to quodiPy the perPorwouce of svPwore systews §eopertad tt cowportay dotdbose systews, especidly us systews berowe wore ‏ای مود‎ اسح سرخ لت لول ۲ ۱ ‎oP rend)‏ مس و مس ‎of‏ موه و ‎thor (dehy‏ سوج © ‎ere tr Poker‏ یلا6 ۶ سا0 لح 0 لا سواه 1 دوه ‎@eedrwr Gyetre Oocowytr, Oe.‏ 

صفحه 20:
+ 005252525250222 22 ام ا ا ا و اه لعجت ام حاص ‎kc‏ © ‎Veer‏ سمج ‎of dfPered‏ ممط مرجومه تجف وت منت تنم ۴ ف ۵ سا تلم ‎Bot OO ips‏ مر مس سود موه وه رو ۶ ‎(ips.‏ ‎trots wt (OHS = SO‏ ,© لم © ‎Creacr ead whee of yer‏ © ‎ps.‏ ‎cher toe (4.00 sepoads, unr front‏ سا ات اه مس ‎Rogaine par‏ © عم 06ج ‎De wate wenne krack, we karwoulr ween!‏ © خا سس واه با هط ۶ لامج جمجدمه صم ‎PPercot trosuniva ppes‏ سا0 لح 0 لا سواه 1 مومه ‎@eedrwr Gyetre Oocowytr, Oe.‏ 

صفحه 21:
+ Oxide @ppitira Okwoee Bl Ocke texewten proveseien (OLPP) © requires high oan rreumy ond clever tevhorques i speed up orci provessiny, i support a high roe oP update trocerariivas. ۲ ‏ارو موه میا‎ ‏وت 60۱ و سم لاه ای ی و‎ ‏موی‎ word query evoktatos cherie cod query ‏ون‎ ‎Bl Orchtertre of sowe chtcbase systews treed to vue oP the tue chess © oy. ‏اوه مد وال سا لصو‎ 19 Obers ‏صمي نو سا لا نت‎ © @.y. Ora, wil scapshot support Por boxy ‏جوم رال‎ سا0 لح 0 لا سواه 1 مومه ‎Od.‏ ,تن 6 تیه 

صفحه 22:
+ @rwhwate Cues © Phe ‏مه‎ Provessiay Ovucl (PPO) beackwork suites are widely sed, © 04۵ urd PPO-O: stop OL TP upptiration wodetay a brats tele -pphcaica uth: ced without poe * Oot eed capwore © POO-O: cowpex OL TP uoppicaica wodeley oa uediory Syste * Correct standard Por OLTP beuckorartteg سا0 لح 0 لا سواه 1 مومه ‎@eedrwr Gyetre Oocowytr, Oe.‏ 

صفحه 23:
+ Crwkuats Ques (Ova) مس ۱۵ ۲ © (6۵۵۵: ‏ماوت سوه مس روم‎ > Guperceded by PPO“ cant PPOAR © PEO: (UL Por wad how) bowed oa DPO-D with sow extra nero > Dede ad hoe queries whick ‏مها سس امه سوه‎ - Dord of CC queries ‏موی من سارت نت‎ صتمي لسطصی سای ‎trees oly oo primary ord Poet heer‏ ۱3 © PRO-R: (RB Por reporicn) seeoe oe MPO-1L, but wikout way resiricioas ‏یج اس رو ای موی مر‎ © PPO-D: ( Por Deb) Coxte-eud Deb server bewkwark wodekey 3 ‏مامت خی مرا بیط‎ of ota ‏رون تحص تام ای‎ سا0 لح 0 لا سواه 1 مومه ‎Gyetre Oocowytr, Oe.‏ ۱۳| 

صفحه 24:
+ TEC Catone Dares سحب بم صم ‎BDC‏ ‏صم لسمسموس ص وی او را ‎per-secoatperddbar amr Por cost oP mucin syste‏ جا © ۲ TPO beukwork requires dotdbose sizes ty be srded up ‏ره خلت‎ ‏لممجج مسا‎ و و موه وه سا ماوت ‎red work‏ ال © بسس۲۳ موی ای موم ۳۵ جه له ام ۲ ‎trusted‏ سا ی واه وم ۳۵ ۶ سا0 لح 0 لا سواه 1 مومه ‎Od.‏ ,تن 6 تیه 

صفحه 25:
+ TEC Catone Dares © Pe pes oP tests Por DPO-W ord TRO-R © Power test nes querer vod upddies sequeuidly, thea tohes weun ty Pod speries ‏چم‎ © Wevuckpul test! nee queries ond updates coourreciy ( ‏رل‎ sirens rosin it pordel cack ‏ی‎ queries, with oe pred ee i © Composte query per hour wet! square root oP produnt of power ood throuihpul wetrios: ۱ Compost pricelperPorwaue wets سا0 لح 0 لا سواه 1 مومه ‎Od.‏ ,تن 6 تیه 

صفحه 26:
+ Oter Orahwrte اما ان وه ‎require 0 dPPered‏ مه 000009 © © O00? bewkwork kos severd dPPered opercives, oad provides o sepande beackwerk cucber Por ‏ان اما اس‎ operation © Revsod! hod ty dePice what is a typed 00010089 ‏ماو‎ ‎© ‏امس‎ Por XO) betry derssed سا0 لح 0 لا سواه 1 مومه ‎Od.‏ ,تن 6 تیه 

صفحه 27:
لس هن Bl ‏سل روموت اه هت بط‎ syeteun oad he aed Por ete ‏تلاوت تا رامین تقوم موم‎ ۶ ‏و رم اه و لو رد‎ ‏اس موس ات با تم‎ ‏تراسا توا ود تال ول‎ rekivod chime) Bord stank wy skanartk: devebped by w otankards ‏شام‎ ‎(©0641, 16), or by teksty wows, frank o publ proves. © Oe Pas ‏ولو‎ we ‏را‎ oovepied us stradards wihout coy Por process of ‏امس‎ © Gromdards dePiced by downret vemdors (BO, Dierverh) vPiea bevowe de Ponto standards © Oe Poy stradards oPieo yo teough o Bored provess of revocation ‏لمم‎ ‏موه مس( مسا‎ سا0 لح 0 لا سواه 1 جومه ‎Od.‏ ,تن 6 تیه 

صفحه 28:
+ Oraadardiva (Ova.) ۴ ‏لعسا موه تمه‎ he worker phe, ‏مها بالط‎ ut vendors he gopher © Crewe copy of Ruture produrts © Qube ieee brows very ane ond vicky shire stndards bodes way ‏و انوم مات اه سس وا مق ات رو اس‎ (66:,ا6و) رام سا مومس ند وم للم جا هواپ 11 oplewecied, possibly in dPPerect ways. ۶ ‏لسوت راما مه و ولو وه و لوا اون‎ Pectures. E.y. OOO systews 0000 ‎Od.‏ ,تن 6 تیه 

صفحه 29:
+ OQ) Grades Very GQ) developed by WO ta hte ‏ملد‎ COs GQL-89 Prat ‏امه تسس‎ ٩180 60006 stererdad Por GAL a ۶ وا لاه تفه ‎to GQL-O9 thot were‏ مه لحلل سای وود و الم زره و © ۲ ۵06 ‏له‎ wo ‏ربسمسم) ۵61-69 و هنن‎ skankad) ‏و۱9‎ ‎© vec aw Paw ‏مس ۵66 خ ما سول اد‎ سا0 لح 0 لا سواه 1 مومه ‎Od.‏ ,تن 6 تیه 

صفحه 30:
+ OQ) Granade Very (Ov) ۲ ۵۵0 © Odds vrarey of ce Petures — extruded dota types, obiect oriectaion, ‏وا سم‎ ete. © @rcken hy severd porte > GALIPrxrework (Pot (): cervew » GALMPockics (Pot ©): ‏ات ,ور‎ bles, quervhartie phic, seo, et > GALICM (Cad Level terPare) (Pot 9): BP ‏تخب‎ ‎> GALIPECO (Persea Grred Dohler) (Pat @): procedurd ‏سور‎ ای مسطل ۳ راق) ای :(9 عد<)) بطلم9انا6 ۱ مها سا0 لح 0 لا سواه 1 مومه ‎Od.‏ ,تن 6 تیه 

صفحه 31:
+ OQ) Granade Very (Ov) Bl Dore parts uenderopien stenkercrion process ۶ Pat P: CQL ‏سوت تسه‎ ces © P19: CALIOEO Ocxanewert of Cxtered Dara) ( ‏مه مد لو وا سید خر وی‎ ~ ‏مرو ,ال چاه نما‎ Ales, con be viewed os port oF the database © Pat dD GQLIOL® (Obert Laogucce Bieri): eecbeddicry GGL ict ava © De stay pot anvbers O ond © cover ‏بو و نما هه‎ oeur stocdardzatica pet سا0 لح 0 لا سواه 1 هوه ‎@eedrwr Gyetre Oocowytr, Oe.‏ 

صفحه 32:
طاحسلجه !9 رش و ‎Dridicew‏ + بشةعصصم م جنا جمدل عونا ولج (000080) بنش ع0 ج095 دصرن 11 موی و بو عمط (ابان) ساسا سرا له( من مرا ۶ ‎procrcnecniny ierPare, od OGL Peutures that wurst be‏ ۱ مرن ناسا وال ‎supported‏ ‎weed Por dave‏ ا ا ‏مه و وله روموت وت ال ولو 2۵ مینز ۲ ‏اه م9 لطاب ‎svurces oP dak‏ ولو موه بط تمه نا 00000 ۶ 1 :0 وان 18 ‎suck us Plot Ales‏ ‎OLE-00 preyrag coo ceyptie wih data svurce te Pied wbot Peutures are‏ © ‎supported‏ ‎a subset oP GGL‏ ها بو ما خی و رایخ 2-000 ران) وا سهخا اه عرص ‎OOO (Gove Outs Obpow):‏ ۲ ‏سا0 لح 0 لا سواه 1 مومه ‎Gyetre Oocowytr, Oe.‏ ۱۳| 

صفحه 33:
‎Orteted Outdbases Otaadards‏ بان ‎۲ Obert ‏مومت له‎ Brow (OOO) stnard Por sbevtorecied hitches ۰ ‏مس ,165 ۰ 9 موس له 1995 ۰ ) میس‎ 9 ۰ 0 © provddes keeping tedepeudeot Object DePkatiza Lop nage (OV) ce wel oe ‏لد مها تسود‎ bra ۲ Obert Daxpwrd Brow (OO) skankad Por dotted soPiwore bused ot objects © Obprt Request Brober (ORO) provides ‏و موس مومت‎ ‏تیان هس‎ © ‏جیت‎ DePratioa Lacey (DL) Por ‏مدل جوا تم‎ vers © Opaxmon Obert Request Broker Orcktectre (CORPO) deh xew specPiraioas oP OR® wd TL ‎ ‎4 ‏سا0 لح 0 لا سواه 1 مومه ‎@eedrwr Gyetre Oocowytr, Oe.‏ 

صفحه 34:
XOL-Owed Oranderds Bl Geverd XOL bused Grantards Por B-coaerce ۶ x1. Rowers (vp ‏حك < هر(‎ © Ortke ride, serie descriptions, uvices, purchase orders, Pir. © XL wreppers ore wed ty export ‏ال لا مد مهوت‎ to XOL © Grote Obert Brees Procol (SOPP): XOL based rewote provedure voll ‏تمس‎ © ‏رل طلست و ۱۱ و(‎ WIP os traveport ‏امس‎ ‎© Groans bused oa ۵006 ۲ ‏سوت تسه‎ * Ey. OLOP ced Data Diciay starctards Pow Dierosvht 4 سا0 لح 0 لا سواه 1 مومه ‎Od.‏ ,تن 6 تیه 

صفحه 35:
C-Ovwwerve و لاس روص له مرو ‎he process of‏ وس 019 لا سس سوه اما ون Bowater tackle: © Crevue waite! votdbwp, wberioeweut, ey © Gabe prowess! vexpiaions oa priceleniiy of service © ‏امه اه بت مساو‎ Wolo, reverse Wek © Paywedt Por se © Oelwery rekied wiviies: ‏ماس واه و واه ماه‎ oP order ‏دوعسم‎ ۱ ond posted service 4 سا0 لح 0 لا سواه 1 مومه ‎Od.‏ ,تن 6 تیه 

صفحه 36:
4 es © rok ‏اجه ای لس اس ی‎ browstay Parties: © Organize ‏ملسم‎ tne totuitive hierarchy: © Qepword search ۱ ‏جاص لصم خأت جمصاعجروجت كلابب‎ ۲ ‏پا و مین‎ ۶ ‏جم موس تسه رس لب(‎ ۱۳ dscounis Por nstwers based va post history ( ‏امس وم بر‎ © Leva resiricicas ‏مم‎ sdes ۱ ‏موی وا لو اب تا ول‎ Astor ۲ ‏همه مه و تون‎ iPorwato مومه ‎Od.‏ ,تن 6 تیه 

صفحه 37:
Oetephwes ۱ Oorketphices help to ceupiatoy the price of a produ wheo there ore ‏جات الم‎ cad buyers © Geverd ies oP workeiphices © Reverse antic ۶ ‏مه‎ ‎#۰ ‏عم‎ ‎B Red world worteiph be quite ‏ماه سلجم وا سل یی‎ ۲ ‏لت(‎ pours! © ‏لا میسن‎ © Record bu/sel bids sere) © Communizate bids quickly to portiipercts * Oetays coe lead to Piecroctal boss ‏مومس وت و‎ © Deed ty horde very hare uokeves of trade of ‏صصص‎ ‎۱ ‏ب.)‎ othe ead oP ‏سم مه‎ سا0 لح 0 لا سواه 1 جووه ‎Od.‏ ,تن 6 تیه 

صفحه 38:
+ Deer oP Oartephor © Reverse ‏موه‎ systew! sine bwer, walipls selers. © Bwer skies reqirewrds, selers bid Por supp tows. Lowest bicker wre. (boo kana ‏تچ‎ eyotec) © Open bidder ve. closed bickbay هط ‎Croton: Dulipe bwers,‏ نا ‎Groplest rose! ody oar testoare oP eark tear ts beter sok‏ © حصان مجلا جه ‎Por‏ لا لا و © Ovre cowphodted wit wuliple copies, ued buyers bid Por ‏ای سوه‎ oP copes Bl @xckene! waliple buyers, wnt ‏اه‎ ‎© ‏ربق‎ sch exchenge © Owers spevky waxkrun price, sellers spevihy wicker price © exchenge wuirhes buy ued sell bids, devickry oa prize Por the trode © ey werene of buyloel bide سا0 لح 0 لا سواه 1 مومه ‎Od.‏ ,تن 6 تیه 

صفحه 39:
تدسج و6۵ ‎Order‏ ی اس اس سوه امه مرو مه و مت 1 امه اوه تن تاهج بو تم بو مس © صجة موی زان را و لت بات با )۶ © ‏یی‎ bos to be trusted ut tp poss oo ‏لج جنيب صا ای لس لس ع‎ peopl © Qeed seme paxved ‏رو‎ ‎© Quod chove-wecivaed problews ۶ Crovide yreuter degree oF privacy: ١ ‏بر‎ oot reved buyers idectiy ‏ط‎ sete ‎racer UTES‏ تمس تسه سا روط وروت ما سوه و موه اه ‎ ‎4 ‏سا0 لح 0 لا سواه 1 مومه ‎Od.‏ ,تن 6 تیه 

صفحه 40:
Geowe Pwwed Gysews © Ol iPonnutod wat be soared ty preved eaverdroppiry © Cubtclprivde hey eoorypiivg widely used ۱ utoche © C.y. sowevue twpersoudies seher or bocbloredt card copay aed Pooks buyer ini revedtary Portion ١ ‏بو‎ wessuges viva desu sve this probiew * Dore va this ‏لاه مه ها‎ 8 Phew ‏وه ولو له هه ای ها موی‎ ‏موم‎ ‏ات وا نمی و نمی لسن و‎ © Cred ‏اوه رو لس‎ of payeedis Prow a buyer aed oolevts thew ‏اس‎ ١ 08 ‏صن .ب‎ buyer's book tough physicd/elevirvair ‏موم سم‎ سا0 لح 0 لا سواه 1 مومه ‎Od.‏ ,تن 6 تیه 

صفحه 41:
+ ‏و و‎ (O04) ۲ 0 ‏وولو مج وا له تاه‎ widde attack ۱ ‏با مخ مسبج جل وج رو ال‎ » Oeries seters theatty by extercd samc Pret! © Geller seuds veriPicde to buyer اجه اجه مس و ره متسه و با تالم ‎uses‏ مین ۶ ‎Pred selers public hey‏ > Donekrhe-cidde cone seud Poke pubhr heyy © Gelers publ hey weed Por setter up serine coer RircoT Bl Geverd seme pacwed protools © Cx. Crowe Choro Trawaton (OT) ‎Od. e000 ©Sbervehnts, Cork ced Cnakershe‏ ,تن 6 تیه 

صفحه 42:
4 Ord Ow © Credited paxvedt dees wot provide cavoyeriyy © Dke GET protocol hides buyers idestiy Pro seter © @uteved uth GED, buyer can be traved with help of oredt card rowpoay BO igi cack sysiews provide cazayeniy stor te thot provided by physicd cask © Gy. OnOwk © ‏من له‎ eurrypiive tevhoiques that woke ۱ ‏ات نی له موه‎ purchased dhytal cask Proc the back © Ont cask coc be speut by purchoser fa ports ١ ‏واه و رس سا اس‎ oo os ooozunl whose ower te سا0 لح 0 لا سواه 1 مومه ‎Od.‏ ,تن 6 تیه 

صفحه 43:
bequy Oystews 18. ‏ام و ما موه لان جد جبمصاصبر5 تصصيصنا‎ wi: aunt ‏موه مش‎ ond systews but sill it production use © Coy. oppiotices writes ta Cobol trot run po wate » Doday'’s hot vew systew is towers leyany spstew! © Corey eqacy sysiew upphcuives to a wore woderd paired is probewctie ‎systew way wove wilivas oP hoes oP code,‏ روا مت موه ول و ‎er‏ ره رن ‎۱ or brager avahable © Guaichiey over Prow oh systew to caw sysiew isu probe * ore oc this biter ‎BO ce approach: bud o wrapper kyer oa top of keen ‏مه سوه و موه‎ ‏رنه ما‎ spots ond ker prc ‎© Cy. we ODBC vr OLE-O® ws wrepper ‎ ‏سا0 لح 0 لا سواه 1 مومه ‎Od.‏ ,تن 6 تیه 

صفحه 44:
۲ ‏ماو تا ی‎ requires 0 Pirst phase ‏كلب يجلمو و صلم خاه‎ ١ es © OP ec leary ode kos 7 dorxmeottion or cused dom cmectit © reverse ‏اه مر سوه‎ gory over leyory pode » Coe up wil sohewa devine tt BR vr OO wodel * ted gut what procedures ced processes ore koplew ected, t7 yet high fevel view oF spstew 11 Reeakerriog! reverse exerts ‏لصاون‎ by desk of caw sysiew ۶ eprom ore wade oo exten suet devin ia his process 4 سا0 لح 0 لا سواه 1 مومو ‎Od.‏ ,تن 6 تیه 

صفحه 45:
+ Leqay Ovetrwe (Ora) ۲۱ Guaichiag over ‏ون و مهو سوه وا لاه و‎ probed © ‏مل جد رش رو مهو و و رو ملس‎ © Gtoppreg he systew way bricg dl oP ‏كماصحت راجا ه وا عرش رو و‎ وه مور ۲ ‏مب م۵‎ 1١ Seeplesmect copes vew syste: (Popukte tuvits dota Pro ‏مرو لاه‎ (0 Op tersuniows hie thir step exerted ‎are crested to do this quickly‏ وود ‎(Ghat dows oh systess ond stort ‏مصاصيه نيص يحاص‎ ‏مو۳)‎ ils thie opprzock: udkot iP aeus ade hos bugs or ‏و(‎ ‏ها مه ‎problews,‏ ‏لاه و مج سا بو بووین ۱ ‏مومه ‎Od.‏ ,تن 6 تیه 

صفحه 46:
© Obthectile opprowh: ۶ ‏و توا سل‎ ove pieve oto the © Ose wreppers ‏ره سح له را مرها عمجم وا‎ * Coq. replace ‏بو‎ eed Pirst, with ‏ماو روا مه وت‎ — OW Proot eed coo oootcue worktoy to this phose to case oP ‏اراس‎ ‏ری ات‎ Proot eed * Replace back eed, vor ‏و ای امش‎ a tee ~ Oll pars thot shore a dotobese way have ty be replaced together, or ‏جا عو رومن‎ weeded va ‏مجاه رال‎ ‎siqaPiccd extra developed ePPont to bubd wrappers ond easure‏ طونم و ‎avon tateroper atic‏ ‎۱ ‏وروی ۱ ان‎ WPe depos oo syste ‎ ‏سا0 لح 0 لا سواه 1 مومه ‎Od.‏ ,تن 6 تیه 

صفحه 47:
Gad oP Okaper 

Chapter 23: Advanced Application Development  Performance Tuning  Performance Benchmarks  Standardization  E-Commerce  Legacy Systems 1 Database System Concepts, 5th Ed. 23.1 ©Silberschatz, Korth and Sudarshan Performance Tuning  Adjusting various parameters and design choices to improve system performance for a specific application.  Tuning is best done by  1. identifying bottlenecks, and 2. eliminating them. Can tune a database system at 3 levels:  Hardware -- e.g., add disks to speed up I/O, add memory to increase buffer hits, move to a faster processor.  Database system parameters -- e.g., set buffer size to avoid paging of buffer, set checkpointing intervals to limit log size. System may have automatic tuning.  Higher level database design, such as the schema, indices and transactions (more later) 2 Database System Concepts, 5th Ed. 23.2 ©Silberschatz, Korth and Sudarshan Bottlenecks  Performance of most systems (at least before they are tuned) usually limited by performance of one or a few components: these are called bottlenecks  E.g. 80% of the code may take up 20% of time and 20% of code takes up 80% of time  Worth spending most time on 20% of code that take 80% of time  Bottlenecks may be in hardware (e.g. disks are very busy, CPU is idle), or in software  Removing one bottleneck often exposes another  De-bottlenecking consists of repeatedly finding bottlenecks, and removing them  This is a heuristic 3 Database System Concepts, 5th Ed. 23.3 ©Silberschatz, Korth and Sudarshan Identifying Bottlenecks  Transactions request a sequence of services  e.g. CPU, Disk I/O, locks  With concurrent transactions, transactions may have to wait for a requested service while other transactions are being served  Can model database as a queueing system with a queue for each service  transactions repeatedly do the following   request a service, wait in queue for the service, and get serviced Bottlenecks in a database system typically show up as very high utilizations (and correspondingly, very long queues) of a particular service  E.g. disk vs CPU utilization  100% utilization leads to very long waiting time:  Rule of thumb: design system for about 70% utilization at peak load  utilization over 90% should be avoided 4 Database System Concepts, 5th Ed. 23.4 ©Silberschatz, Korth and Sudarshan Queues In A Database System 5 Database System Concepts, 5th Ed. 23.5 ©Silberschatz, Korth and Sudarshan Tunable Parameters  Tuning of hardware  Tuning of schema  Tuning of indices  Tuning of materialized views  Tuning of transactions 6 Database System Concepts, 5th Ed. 23.6 ©Silberschatz, Korth and Sudarshan Tuning of Hardware   Even well-tuned transactions typically require a few I/O operations  Typical disk supports about 100 random I/O operations per second  Suppose each transaction requires just 2 random I/O operations. Then to support n transactions per second, we need to stripe data across n/50 disks (ignoring skew) Number of I/O operations per transaction can be reduced by keeping more data in memory  If all data is in memory, I/O needed only for writes  Keeping frequently used data in memory reduces disk accesses, reducing number of disks required, but has a memory cost 7 Database System Concepts, 5th Ed. 23.7 ©Silberschatz, Korth and Sudarshan Hardware Tuning: Five-Minute Rule  Question: which data to keep in memory:  If a page is accessed n times per second, keeping it in memory saves  n* price-per-disk-drive accesses-per-second-per-disk  Cost of keeping page in memory  price-per-MB-of-memory ages-per-MB-of-memory  Break-even point: value of n for which above costs are equal   If accesses are more then saving is greater than cost Solving above equation with current disk and memory prices leads to: 5-minute rule: if a page that is randomly accessed is used more frequently than once in 5 minutes it should be kept in memory  (by buying sufficient memory!) 8 Database System Concepts, 5th Ed. 23.8 ©Silberschatz, Korth and Sudarshan Hardware Tuning: One-Minute Rule  For sequentially accessed data, more pages can be read per second. Assuming sequential reads of 1MB of data at a time: 1-minute rule: sequentially accessed data that is accessed once or more in a minute should be kept in memory  Prices of disk and memory have changed greatly over the years, but the ratios have not changed much  so rules remain as 5 minute and 1 minute rules, not 1 hour or 1 second rules! 9 Database System Concepts, 5th Ed. 23.9 ©Silberschatz, Korth and Sudarshan Hardware Tuning: Choice of RAID Level  To use RAID 1 or RAID 5?  Depends on ratio of reads and writes     RAID 5 requires 2 block reads and 2 block writes to write out one data block If an application requires r reads and w writes per second  RAID 1 requires r + 2w  RAID 5 requires: r + 4w I/O operations per second I/O operations per second For reasonably large r and w, this requires lots of disks to handle workload  RAID 5 may require more disks than RAID 1 to handle load!  Apparent saving of number of disks by RAID 5 (by using parity, as opposed to the mirroring done by RAID 1) may be illusory! Thumb rule: RAID 5 is fine when writes are rare and data is very large, but RAID 1 is preferable otherwise  If you need more disks to handle I/O load, just mirror them since disk capacities these days are enormous! 10 Database System Concepts, 5th Ed. 23.10 ©Silberschatz, Korth and Sudarshan Tuning the Database Design  Schema tuning  Vertically partition relations to isolate the data that is accessed most often -- only fetch needed information. •   E.g., split account into two, (account-number, branch-name) and (accountnumber, balance). • Branch-name need not be fetched unless required Improve performance by storing a denormalized relation • E.g., store join of account and depositor; branch-name and balance information is repeated for each holder of an account, but join need not be computed repeatedly. • Price paid: more space and more work for programmer to keep relation consistent on updates • better to use materialized views (more on this later..) Cluster together on the same disk page records that would match in a frequently required join,  compute join very efficiently when required. 11 Database System Concepts, 5th Ed. 23.11 ©Silberschatz, Korth and Sudarshan Tuning the Database Design (Cont.)   Index tuning  Create appropriate indices to speed up slow queries/updates  Speed up slow updates by removing excess indices (tradeoff between queries and updates)  Choose type of index (B-tree/hash) appropriate for most frequent types of queries.  Choose which index to make clustered Index tuning wizards look at past history of queries and updates (the workload) and recommend which indices would be best for the workload 12 Database System Concepts, 5th Ed. 23.12 ©Silberschatz, Korth and Sudarshan Tuning the Database Design (Cont.) Materialized Views  Materialized views can help speed up certain queries   Particularly aggregate queries Overheads  Space  Time for view maintenance  Immediate view maintenance:done as part of update txn – time overhead paid by update transaction  Deferred view maintenance: done only when required – update transaction is not affected, but system time is spent on view maintenance »  until updated, the view may be out-of-date Preferable to denormalized schema since view maintenance is systems responsibility, not programmers  Avoids inconsistencies caused by errors in update programs 13 Database System Concepts, 5th Ed. 23.13 ©Silberschatz, Korth and Sudarshan Tuning the Database Design (Cont.)  How to choose set of materialized views  Helping one transaction type by introducing a materialized view may hurt others  Choice of materialized views depends on costs    Users often have no idea of actual cost of operations Overall, manual selection of materialized views is tedious Some database systems provide tools to help DBA choose views to materialize  “Materialized view selection wizards” 14 Database System Concepts, 5th Ed. 23.14 ©Silberschatz, Korth and Sudarshan Tuning of Transactions  Basic approaches to tuning of transactions  Improve set orientation  Reduce lock contention  Rewriting of queries to improve performance was important in the past, but smart optimizers have made this less important  Communication overhead and query handling overheads significant part of cost of each call   Combine multiple embedded SQL/ODBC/JDBC queries into a single setoriented query  Set orientation -> fewer calls to database  E.g. tune program that computes total salary for each department using a separate SQL query by instead using a single query that computes total salaries for all department at once (using group by) Use stored procedures: avoids re-parsing and re-optimization of query 15 Database System Concepts, 5th Ed. 23.15 ©Silberschatz, Korth and Sudarshan Tuning of Transactions (Cont.)  Reducing lock contention  Long transactions (typically read-only) that examine large parts of a relation result in lock contention with update transactions   E.g. large query to compute bank statistics and regular bank transactions To reduce contention  Use multi-version concurrency control   E.g. Oracle “snapshots” which support multi-version 2PL Use degree-two consistency (cursor-stability) for long transactions  Drawback: result may be approximate 16 Database System Concepts, 5th Ed. 23.16 ©Silberschatz, Korth and Sudarshan Tuning of Transactions (Cont.)  Long update transactions cause several problems  Exhaust lock space  Exhaust log space   and also greatly increase recovery time after a crash, and may even exhaust log space during recovery if recovery algorithm is badly designed! Use mini-batch transactions to limit number of updates that a single transaction can carry out. E.g., if a single large transaction updates every record of a very large relation, log may grow too big. * Split large transaction into batch of ``mini-transactions,'' each performing part of the updates • Hold locks across transactions in a mini-batch to ensure serializability • If lock table size is a problem can release locks, but at the cost of serializability * In case of failure during a mini-batch, must complete its remaining portion on recovery, to ensure atomicity. 17 Database System Concepts, 5th Ed. 23.17 ©Silberschatz, Korth and Sudarshan Performance Simulation  Performance simulation using queuing model useful to predict bottlenecks as well as the effects of tuning changes, even without access to real system  Queuing model as we saw earlier   Models activities that go on in parallel Simulation model is quite detailed, but usually omits some low level details  Model service time, but disregard details of service  E.g. approximate disk read time by using an average disk read time  Experiments can be run on model, and provide an estimate of measures such as average throughput/response time  Parameters can be tuned in model and then replicated in real system  E.g. number of disks, memory, algorithms, etc 18 Database System Concepts, 5th Ed. 23.18 ©Silberschatz, Korth and Sudarshan Performance Benchmarks  Suites of tasks used to quantify the performance of software systems  Important in comparing database systems, especially as systems become more standards compliant.  Commonly used performance measures:  Throughput (transactions per second, or tps)  Response time (delay from submission of transaction to return of result)  Availability or mean time to failure 19 Database System Concepts, 5th Ed. 23.19 ©Silberschatz, Korth and Sudarshan Performance Benchmarks (Cont.)  Suites of tasks used to characterize performance   single task not enough for complex systems Beware when computing average throughput of different transaction types  E.g., suppose a system runs transaction type A at 99 tps and transaction type B at 1 tps.  Given an equal mixture of types A and B, throughput is not (99+1)/2 = 50 tps.  Running one transaction of each type takes time 1+.01 seconds, giving a throughput of 1.98 tps.  To compute average throughput, use harmonic mean: n  Interference (e.g. lock1/t contention) makes even this incorrect if 1 + 1/t2 + … + 1/tn different transaction types run concurrently 20 Database System Concepts, 5th Ed. 23.20 ©Silberschatz, Korth and Sudarshan Database Application Classes  Online transaction processing (OLTP)    Decision support applications  including online analytical processing, or OLAP applications  require good query evaluation algorithms and query optimization. Architecture of some database systems tuned to one of the two classes   requires high concurrency and clever techniques to speed up commit processing, to support a high rate of update transactions. E.g. Teradata is tuned to decision support Others try to balance the two requirements  E.g. Oracle, with snapshot support for long read-only transaction 21 Database System Concepts, 5th Ed. 23.21 ©Silberschatz, Korth and Sudarshan Benchmarks Suites  The Transaction Processing Council (TPC) benchmark suites are widely used.  TPC-A and TPC-B: simple OLTP application modeling a bank teller application with and without communication   Not used anymore TPC-C: complex OLTP application modeling an inventory system  Current standard for OLTP benchmarking 22 Database System Concepts, 5th Ed. 23.22 ©Silberschatz, Korth and Sudarshan Benchmarks Suites (Cont.)  TPC benchmarks (cont.)  TPC-D: complex decision support application   Superceded by TPC-H and TPC-R TPC-H: (H for ad hoc) based on TPC-D with some extra queries  Models ad hoc queries which are not known beforehand – Total of 22 queries with emphasis on aggregation  prohibits materialized views  permits indices only on primary and foreign keys  TPC-R: (R for reporting) same as TPC-H, but without any restrictions on materialized views and indices  TPC-W: (W for Web) End-to-end Web service benchmark modeling a Web bookstore, with combination of static and dynamically generated pages 23 Database System Concepts, 5th Ed. 23.23 ©Silberschatz, Korth and Sudarshan TPC Performance Measures   TPC performance measures  transactions-per-second with specified constraints on response time  transactions-per-second-per-dollar accounts for cost of owning system TPC benchmark requires database sizes to be scaled up with increasing transactions-per-second   reflects real world applications where more customers means more database size and more transactions-per-second External audit of TPC performance numbers mandatory  TPC performance claims can be trusted 24 Database System Concepts, 5th Ed. 23.24 ©Silberschatz, Korth and Sudarshan TPC Performance Measures  Two types of tests for TPC-H and TPC-R  Power test: runs queries and updates sequentially, then takes mean to find queries per hour  Throughput test: runs queries and updates concurrently  multiple streams running in parallel each generates queries, with one parallel update stream  Composite query per hour metric: square root of product of power and throughput metrics  Composite price/performance metric 25 Database System Concepts, 5th Ed. 23.25 ©Silberschatz, Korth and Sudarshan Other Benchmarks   OODB transactions require a different set of benchmarks.  OO7 benchmark has several different operations, and provides a separate benchmark number for each kind of operation  Reason: hard to define what is a typical OODB application Benchmarks for XML being discussed 26 Database System Concepts, 5th Ed. 23.26 ©Silberschatz, Korth and Sudarshan Standardization  The complexity of contemporary database systems and the need for their interoperation require a variety of standards.  syntax and semantics of programming languages  functions in application program interfaces  data models (e.g. object oriented/object relational databases)  Formal standards are standards developed by a standards organization (ANSI, ISO), or by industry groups, through a public process.  De facto standards are generally accepted as standards without any formal process of recognition  Standards defined by dominant vendors (IBM, Microsoft) often become de facto standards  De facto standards often go through a formal process of recognition and become formal standards 27 Database System Concepts, 5th Ed. 23.27 ©Silberschatz, Korth and Sudarshan Standardization (Cont.)  Anticipatory standards lead the market place, defining features that vendors then implement    Ensure compatibility of future products But at times become very large and unwieldy since standards bodies may not pay enough attention to ease of implementation (e.g.,SQL-92 or SQL:1999) Reactionary standards attempt to standardize features that vendors have already implemented, possibly in different ways.  Can be hard to convince vendors to change already implemented features. E.g. OODB systems 28 Database System Concepts, 5th Ed. 23.28 ©Silberschatz, Korth and Sudarshan SQL Standards History  SQL developed by IBM in late 70s/early 80s  SQL-86 first formal standard  IBM SAA standard for SQL in 1987  SQL-89 added features to SQL-86 that were already implemented in many systems   Was a reactionary standard SQL-92 added many new features to SQL-89 (anticipatory standard)  Defines levels of compliance (entry, intermediate and full)  Even now few database vendors have full SQL-92 implementation 29 Database System Concepts, 5th Ed. 23.29 ©Silberschatz, Korth and Sudarshan SQL Standards History (Cont.)  SQL:1999  Adds variety of new features --- extended data types, object orientation, procedures, triggers, etc.  Broken into several parts  SQL/Framework (Part 1): overview  SQL/Foundation (Part 2): types, schemas, tables, query/update statements, security, etc  SQL/CLI (Call Level Interface) (Part 3): API interface  SQL/PSM (Persistent Stored Modules) (Part 4): procedural extensions  SQL/Bindings (Part 5): embedded SQL for different embedding languages 30 Database System Concepts, 5th Ed. 23.30 ©Silberschatz, Korth and Sudarshan SQL Standards History (Cont.)  More parts undergoing standardization process  Part 7: SQL/Temporal: temporal data  Part 9: SQL/MED (Management of External Data)  Interfacing of database to external data sources – Allows other databases, even files, can be viewed as part of the database  Part 10 SQL/OLB (Object Language Bindings): embedding SQL in Java  Missing part numbers 6 and 8 cover features that are not near standardization yet 31 Database System Concepts, 5th Ed. 23.31 ©Silberschatz, Korth and Sudarshan Database Connectivity Standards  Open DataBase Connectivity (ODBC) standard for database interconnectivity   based on Call Level Interface (CLI) developed by X/Open consortium defines application programming interface, and SQL features that must be supported at different levels of compliance  JDBC standard used for Java  X/Open XA standards define transaction management standards for supporting distributed 2-phase commit  OLE-DB: API like ODBC, but intended to support non-database sources of data such as flat files   OLE-DB program can negotiate with data source to find what features are supported  Interface language may be a subset of SQL ADO (Active Data Objects): easy-to-use interface to OLE-DB functionality 32 Database System Concepts, 5th Ed. 23.32 ©Silberschatz, Korth and Sudarshan Object Oriented Databases Standards   Object Database Management Group (ODMG) standard for object-oriented databases  version 1 in 1993 and version 2 in 1997, version 3 in 2000  provides language independent Object Definition Language (ODL) as well as several language specific bindings Object Management Group (OMG) standard for distributed software based on objects  Object Request Broker (ORB) provides transparent message dispatch to distributed objects  Interface Definition Language (IDL) for defining language-independent data types  Common Object Request Broker Architecture (CORBA) defines specifications of ORB and IDL 33 Database System Concepts, 5th Ed. 23.33 ©Silberschatz, Korth and Sudarshan XML-Based Standards   Several XML based Standards for E-commerce  E.g. RosettaNet (supply chain), BizTalk  Define catalogs, service descriptions, invoices, purchase orders, etc.  XML wrappers are used to export information from relational databases to XML Simple Object Access Protocol (SOAP): XML based remote procedure call standard  Uses XML to encode data, HTTP as transport protocol  Standards based on SOAP for specific applications  E.g. OLAP and Data Mining standards from Microsoft 34 Database System Concepts, 5th Ed. 23.34 ©Silberschatz, Korth and Sudarshan E-Commerce  E-commerce is the process of carrying out various activities related to commerce through electronic means  Activities include:  Presale activities: catalogs, advertisements, etc  Sale process: negotiations on price/quality of service  Marketplace: e.g. stock exchange, auctions, reverse auctions  Payment for sale  Delivery related activities: electronic shipping, or electronic tracking of order processing/shipping  Customer support and post-sale service 35 Database System Concepts, 5th Ed. 23.35 ©Silberschatz, Korth and Sudarshan E-Catalogs   Product catalogs must provide searching and browsing facilities  Organize products into intuitive hierarchy  Keyword search  Help customer with comparison of products Customization of catalog  Negotiated pricing for specific organizations  Special discounts for customers based on past history   Legal restrictions on sales   E.g. loyalty discount Certain items not exposed to under-age customers Customization requires extensive customer-specific information 36 Database System Concepts, 5th Ed. 23.36 ©Silberschatz, Korth and Sudarshan Marketplaces  Marketplaces help in negotiating the price of a product when there are multiple sellers and buyers  Several types of marketplaces  Reverse auction  Auction  Exchange  Real world marketplaces can be quite complicated due to product differentiation  Database issues:  Authenticate bidders  Record buy/sell bids securely  Communicate bids quickly to participants   Delays can lead to financial loss to some participants Need to handle very large volumes of trade at times  E.g. at the end of an auction 37 Database System Concepts, 5th Ed. 23.37 ©Silberschatz, Korth and Sudarshan Types of Marketplace    Reverse auction system: single buyer, multiple sellers.  Buyer states requirements, sellers bid for supplying items. Lowest bidder wins. (also known as tender system)  Open bidding vs. closed bidding Auction: Multiple buyers, single seller  Simplest case: only one instance of each item is being sold  Highest bidder for an item wins  More complicated with multiple copies, and buyers bid for specific number of copies Exchange: multiple buyers, multiple sellers  E.g., stock exchange  Buyers specify maximum price, sellers specify minimum price  exchange matches buy and sell bids, deciding on price for the trade  e.g. average of buy/sell bids 38 Database System Concepts, 5th Ed. 23.38 ©Silberschatz, Korth and Sudarshan Order Settlement  Order settlement: payment for goods and delivery  Insecure means for electronic payment: send credit card number   Buyers may present some one else’s credit card numbers  Seller has to be trusted to bill only for agreed-on item  Seller has to be trusted not to pass on the credit card number to unauthorized people Need secure payment systems  Avoid above-mentioned problems  Provide greater degree of privacy   E.g. not reveal buyers identity to seller Ensure that anyone monitoring the electronic transmissions cannot access critical information 39 Database System Concepts, 5th Ed. 23.39 ©Silberschatz, Korth and Sudarshan Secure Payment Systems  All information must be encrypted to prevent eavesdropping   Must prevent person-in-the-middle attacks   Public/private key encryption widely used E.g. someone impersonates seller or bank/credit card company and fools buyer into revealing information  Encrypting messages alone doesn’t solve this problem  More on this in next slide Three-way communication between seller, buyer and credit-card company to make payment  Credit card company credits amount to seller  Credit card company consolidates all payments from a buyer and collects them together  E.g. via buyer’s bank through physical/electronic check payment 40 Database System Concepts, 5th Ed. 23.40 ©Silberschatz, Korth and Sudarshan Secure Payment Systems (Cont.)  Digital certificates are used to prevent impersonation/man-in-the middle attack  Certification agency creates digital certificate by encrypting, e.g., seller’s public key using its own private key   Seller sends certificate to buyer  Customer uses public key of certification agency to decrypt certificate and find sellers public key    Verifies sellers identity by external means first! Man-in-the-middle cannot send fake public key Sellers public key used for setting up secure communication Several secure payment protocols  E.g. Secure Electronic Transaction (SET) 41 Database System Concepts, 5th Ed. 23.41 ©Silberschatz, Korth and Sudarshan Digital Cash   Credit-card payment does not provide anonymity  The SET protocol hides buyers identity from seller  But even with SET, buyer can be traced with help of credit card company Digital cash systems provide anonymity similar to that provided by physical cash  E.g. DigiCash  Based on encryption techniques that make it impossible to find out who purchased digital cash from the bank  Digital cash can be spent by purchaser in parts  much like writing a check on an account whose owner is anonymous 42 Database System Concepts, 5th Ed. 23.42 ©Silberschatz, Korth and Sudarshan Legacy Systems  Legacy systems are older-generation systems that are incompatible with current generation standards and systems but still in production use  E.g. applications written in Cobol that run on mainframes   Porting legacy system applications to a more modern environment is problematic  Very expensive, since legacy system may involve millions of lines of code, written over decades   Original programmers usually no longer available Switching over from old system to new system is a problem   Today’s hot new system is tomorrows legacy system! more on this later One approach: build a wrapper layer on top of legacy application to allow interoperation between newer systems and legacy application  E.g. use ODBC or OLE-DB as wrapper 43 Database System Concepts, 5th Ed. 23.43 ©Silberschatz, Korth and Sudarshan Legacy Systems (Cont.)   Rewriting legacy application requires a first phase of understanding what it does  Often legacy code has no documentation or outdated documentation  reverse engineering: process of going over legacy code to  Come up with schema designs in ER or OO model  Find out what procedures and processes are implemented, to get a high level view of system Re-engineering: reverse engineering followed by design of new system  Improvements are made on existing system design in this process 44 Database System Concepts, 5th Ed. 23.44 ©Silberschatz, Korth and Sudarshan Legacy Systems (Cont.)   Switching over from old to new system is a major problem  Production systems are in every day, generating new data  Stopping the system may bring all of a company’s activities to a halt, causing enormous losses Big-bang approach: 1. Implement complete new system 2. Populate it with data from old system 1. No transactions while this step is executed 2. scripts are created to do this quickly 3. Shut down old system and start using new system  Danger with this approach: what if new code has bugs or performance problems, or missing features  Company may be brought to a halt 45 Database System Concepts, 5th Ed. 23.45 ©Silberschatz, Korth and Sudarshan Legacy Systems (Cont.)  Chicken-little approach:  Replace legacy system one piece at a time  Use wrappers to interoperate between legacy and new code  E.g. replace front end first, with wrappers on legacy backend – Old front end can continue working in this phase in case of problems with new front end  Replace back end, one functional unit at a time – All parts that share a database may have to be replaced together, or wrapper is needed on database also  Drawback: significant extra development effort to build wrappers and ensure smooth interoperation  Still worth it if company’s life depends on system 46 Database System Concepts, 5th Ed. 23.46 ©Silberschatz, Korth and Sudarshan End of Chapter Database System Concepts ©Silberschatz, Korth and Sudarshan See www.db-book.com for conditions on re-use Database System Concepts 47 ©Silberschatz, Korth and Sudarshan