Mi predesztinál sikerre egy adatbányászprojektet?

.
Szakmai társblogon olvastam az imént a tárgybeli témában egy friss posztot.

A 7.sikerkritérium

"Egy népszerű ökölszabály alapján egy jó adatbányászati projektnek hat sikerkritériuma van: legyen
(1) sok sorból álló
(2) attribútumokban gazdag adathalmazunk, melyben legyenek az adatok egyrészt
(3) tiszták, másrészt
(4) jól reprezentálják a prediktív modellekben körüljárt eseményt. Ezen túlmenően fontos, hogy a projektre
(5) jól mérhető legyen a ROI, illetve a vállalati környezet olyan legyen, hogy a kapott eredmények alapján a menedzsment ténylegesen változtathasson a korábbi folyamatokon, azaz
(6) akcióképes legyen a vizsgált tématerület.
(7) rövid válaszidő"

A téma nagyon jó (a hét mesterlövészre utalás különösen szellemes telitalálat), a poszt helyből és azonnal hozzászólásra inspirált, plusz van akkora fontossága/jelentősége a kiinduló felvetésnek, hogy "replikáljam" ide is. Pláne, hogy egy blogposztban nem lehet mindent és teljeskörűen leírni, biztos lehet kiegészítéseket tenni egyéni megfontolásokból... ;)

* Én például jobban szoktam vágyni kevesebb, de nagyobb magyarázó erővel bíró attribútum(kombináci)okra. Az KDD-s Orange-verseny is rámutatott, hogy nagyon gyorsan el tudnak szabadulni a potenciális magyarázó-változók.

* Bár jóféle technikák vannak kezelésükre, mégis alapból hálás tud lenni, ha (1) kitöltöttek ("missing value"-mentesség) valamint (2) minél inkább mentesek a kiugró értékektől (outlier)az attribútumok. A nagyobb/jobb kitöltöttségért olykor nagyon meg kellhet küzdeni, az én tapasztalatom szerint

* Nagy öröm volt olvasni a "jól mérhető ROI"-ról. Részint mert nincs triviálisan a köztudatban (szerintem) a dolog nehézsége, másrészt az adatbányász komfortérzetét is nagyban javítja a korrekt mérés/visszamérés lehetősége.

* Az akcióképesség ilyetén hangsúlyozása engem elsőre megdöbbentett. Értem persze a felvetés jogosságát (amúgy se jó sose az öncélú l'art pour l'art játszadozás, nemcsak az adatbányászatban), de azért felveti a kérdést (pláne az eggyel korábbi "börtönfenyegetettséges" blogposztommal összhangban), hogy meddig terjed az adatbányász hatóköre. Számomra sokkal fontosabb idevágóan az adatbányász(-projekt) hitelessége, meg ennek hangsúlyozása, aminek alapján a menedzsment megbízik az eléje tálalt infókban majd dönt a további lépések mikéntjéről, másfelöl, hogy ne vállalati klikkharcok martaléka legyen egy értékes adatbányászati elemzés, azaz legyen motiváció a menedzsmentben az objektív mérlegelésre .

* Nagyon hasznos felvetés volt az eredeti blogposztban a "feketedoboz-effektus" mérlegelése. Én azt a példát hoznám, hogy a potenciális - kézzel leellenőrízendő - csalók listájára pénzügyi szektorban is el tudok képzelni feketedoboz-os adatbányász algoritmust, a minél teljesebbkörű azonosítás érdekében és valóban ügyfél-szegmentációra vagy guide-technológia esetén sokkal kevésbé "adható el" a feketedoboz.

* A legérdekesebb viszont kétségtelenül a poszt-címadó 7.sikerkritérium. ;)

- Így első belegondolásra és nagy százalékban a válaszidő és a pontosság többnyire egymás kárára tuningolható leginkább. Magyarán létezhet "optimum" a két szempontra.

- Van egy harmadik aspektusa a rövid válaszidőnek méghozzá a skálázhatóság. Ugyanis a gyakorlat az az, hogy úgy nőnek az adatok (az "égig"), hogy a már egyszer implementált megszokott válaszidőket implicite el is várjuk. Azaz durva példával élve kétszer akkora adattömegre elég legyen még egy gépet beállítani, hogy minden funkcionalitás tudjon a régi válaszidőkkel menni.
Tipikus példa lehet egy Netflix (rohamosan növekvő ügyfél- és filmbázissal).

- Én ha választhatok jobban szeretem a pontosságot választani, mint a rövidebb válaszidőt, de el kell fogadni, hogy az "idő pénz". De ekkor is felhasználóként / ügyfélként szeretném látni, hogy a rövidebb válaszidő tényleg nagyobb profitot hoz (nem öncélú a rövidebb válaszidő a "látványért" magáért)

Update

Az eredeti blogposztot író Gáspár-Papanek Csaba kommentje:
Lehet, hogy nem írtam le teljesen egyértelműen, a válaszidő alatt nem a modellezés futási idejét értem, hanem azt, hogy egy modell való életben történő használatáról milyen hamar kap visszajelzést maga a megrendelő. Szóval ez nem az adatbányászati folyamat belsejében megjelenő technikák, hanem magának a feladatnak a tulajdonsága.

Tényleg nem akartam végtelen hosszú blogbejegyzést írni, ezért talán nem is emeltem ki eléggé, hogy itt a sikerkritériumoka valójában a környezetről szólnak: mikor lesz sikeres egy adatbányászati projekt, milyen feladatok alkalmasak arra, hogy sikeres projektet csináljunk belőlük.

Nyilván nagyobb az esély a sikerre, ha hamarabb jelentkezik a(z) (esélyes) pozitív visszajelzés.
Talán idevág a fociból vett analógia, hogy az edzők 2-3 évre szeretnek tervezni úgymond csapatot építeni, de elég lehet 1-2 vereeég a bajnokságban, hogy aztán mégis iziben repüljön az edző.
Valóban nehéz egyeztetni a folyamatos azonali sikeréhséget a hosszabbtávú stratégiai tervszerűséggel. 

Prediktálás börtönfenyegetettség árnyékában?

.
Új minőség az adatbányászat horizontján?

Nem jósolták meg a földrengést, perlik őket

"Hét olasz tudós és szakértő ellen gondatlanságból elkövetett emberölés miatt emeltek vádat szerdán, mert nem figyelmeztettek a háromszáz halálos áldozatot követelő 2009-es földrengésre. A védelem visszautasítja a vádat, mondván, lehetetlenség megjósolni a földrengéseket."

Azért ez felvethet pár érdekes kérdést még laikusokban is.

(1) Ilyen megbízhatóak mára az adatbányász/prediktálási protokollok, hogy börtönnel is számonkérhetők?

(2) Attól még hogy
(a) egy ember
(b) magas százalékos valószínűséggel
lát egy bekövetkező földrengést onnan még nem hosszú az út egy "kicsit"?
(Hogy szakmai konszenzus legyen, továbbá a döntéshozók is megfelelő lépések útjára lépjenek)

Nekem analógiaként a 2008-as pénzügyi válság jut eszembe. Egészen biztosan voltak kockázatelemzők, akik látták akkor is a bajt elemzéseik konklúziójaként, a válság mégis nagyon durván ráomlott az USÁ-ra, meg aztán a világra.

Adatbányászat és etika témához meg egy újabb érdekes adalék lehet a sztori: az én érzékelésemben nagyon hosszúnak látszik még az út, amikor az adatbányászaton kívüli közvéleményben kialakul a helyes arányérzék: mit lehet várni az adatbányászattól, milyen követelmények/elvárások a reálisak. Pro és kontra.


UPDATE-1

Befutott egy érdekes és inspiráló komment, köszönet érte. :o)

* Nem tudom, ezek az előrejelzések mennyiben adatbányász feladatok?
* A konkrét eset sem teljesen egyértelmű. Ugyanis azt írja, hogy voltak akkoriban kisebb rengések, és abból talán tudtak volna következtetni... Persze itt felmerül, hogy minden ilyen esetben ezentúl kilakoltatják a települést, és nem jön be az előrejelzés, akkor egy idő után hiteltelenné válhat, és már maga a lakosság lenne, akik nem hinnének...
* meg aztán ahogy olvasom, őket ezért fizették :))) "nagy veszélyek bizottsága" :)))
* Ami ennek kapcsán még az eszembe jutott, nálunk az árvízveszély. Épp nemrégiben olvastam, hogy itthon is akarnak valami katasztrófavédelmi tanfolyamot, amin kötelező lenne a részvétel az állampolgároknak, és azt tanítanák, hogyan kell szervezkedni árvíz esetén....

Én úgy gondolom, hogy ami nagy tömegű és/vagy historikus adatokon alapuló, matematikai algoritmusokkal kiszámolt előrejelzés az minden esetben adatbányászfeladat: nevében is benne van, nagy adattömegből kell kibányászni értékes kevés ("lesz-e földrengés: igen/nem") információt.

Az adatbányászatnak van tárgy-(domain-), jelenesetben geológusi/szeizmológusi-, függése. Amihez én nem értek. Rögtön nem tudnék például arra a kérdésre válaszolni, hogy a földrengés-előrejelzés analóg-e az időjárás előrejelzéssel a tekintetben, hogy minél közelebbi időpontra történik az előrejelzés, annál pontosabb. Időjárásnál így van tudtommal, földrengésnél egyáltalán nem biztos. A hírek szerint a minapi japán földrengés-előrejelzés is vetett fel komoly szakmai kérdéseket.

Így van ahogy mondod, a nagy kérdés az az, hogy egy előrejelzés, milyen alapon / implikációk révén, milyen tevékenységláncolatot indítson be. Az előrejelzés információtömege elért-e kellő kritikus tömeget, mekkora hordereje van a tevékenységláncolatnak stb. (adott esetben lehet "farkast kiáltani" sokszor, ahogy esernyő is sokszor van nálunk, miközben süt a nap, mert nincs nagy rezsije. Míg a pénzügyi válság elkerüléséhez olyan döntés- és tevékenységsorozatra lett volna szükség, amire esélytelen volt az emberiség)

Az idevágó paradoxont én úgy szoktam megfogalmazni, hogy nem elég előrejelezni, az előrejelzést alá kell tudni támasztani, hitelt kell tudni neki adni, akkor ér valamit. Az hogy az éterbe millióan beleböfögnek valamit és aztán mindig valakinek/másnak igaza van (kitalálhatatlanul); egy adott (teszemazt közgazdasági) előrejelzési kérdésben, ez így ebben a formában használhatatlan zaj.

A dolgot megfordítva: ha egy előrejelzőt "fizetnek", akkor börtönnel kell jótállnia az előrejelzéseiért?

Deja vu, nagyon fontos, ráadásul hazai analógia a tárgyban, amit ennek a fenti kommentnek köszönhetek.  amikor volt a pár évvel ezelötti (szél)viharos, fakidöntéses tüzijáték, emberhalállal (Budapesten).

Kit akartak felelősségre vonni? A meteorológiai előrejelzőt, avagy a politikust, aki engedte a tüzijátékot?Meddig terjed az előrejelző felelőssége? Előrejelzés pontosságáig? Döntéshozó meggyőzéséig? Egy érdekes idevágó gondolatmenet a témában, jogi szemszögből:

A budapesti tűzijáték tragédia és a vezetői felelősség kérdése


Az árvízvédelem, védekező mechanizmusainak lépései fontosak valóban a tárgyunk szempontjából is. "Milyen előrejelzés alapján, mi történjen?"

Beszéd, mint a sikeres párkapcsolat prediktora?

.
Sikerült egy "igazgyöngyöt" találnom a hatalmas indexes napi forgatagban, mondhatni "zajban". :o)

Mire nem jó (még) a (szöveg)bányászat. :o) Ha már itt a blogon oly hangsúlyos volt többször is a szerelem meg társkeresés jövőjének fürkészése, nemcsak és főleg nem teoretice, hanem konkrét egyedi párkapcsolatok vonatkozásában, matematikai/numerátori alapokon, akkor röviden szót ejtek erről is.

A beszédstílus a jó párkapcsolat alapja

Az érintettek beszédmódja alapján nagy biztonsággal megjósolható egy párkapcsolat jövője, állítják az új módszert kidolgozó pszichológusok.

Azok a párok, akiknek beszédje szinkronban van, négyszer nagyobb valószínűséggel szeretnének máskor is találkozni, mint azok, akik nem egy nyelvet beszéltek, derült ki a Texasi Egyetemen diákok bevonásával végzett vizsgálatból. A kutatók a szavak mondatokká fűzéséhez nélkülözhetetlen funkcionális szavakra koncentráltak.

A kutatás első fázisában 40 pár gyors, mindössze négyperces randevút bonyolított le, és beszélgetésüket rögzítették. A második fázisban már rendszeresen találkozgató párok hétköznapi beszélgetéseit és üzenetváltásait vizsgálták 10 napon át, és a kutatók arra a következtetésre jutottak, hogy a beszédmodor és az írás stílusa jó indikátor lehet arra nézve, hogy sikeres lesz-e vagy sem egy kapcsolat.

A dolgot ugye nem tudom leellenőrizni, maximum csak fejben végiggondolni.  És részben pozitív gondolkodásomból fakadóan, részben tapasztalatom alapján azt kell mondjam: erősen el tudom képzelni, mint reális lehetőséget.

* A kutatásnak értelme is van, lásd csökkenő házasodási és gyerekvállalási kedv (fejlett nyugaton).

* Nem "brittudósi" hülyeség, már első olvasatban sem. Például mert egybevág a józan paraszti ész tapasztalatával.

* Ha én állítanék fel csapatot társkeresési honlap alapításához, én is nagyon támaszkodnék pszichológusokra. Már az óriási segítség lehet, hogy mik lehetnek a releváns felteendő kérdések.

* Négyszeres szorzó az már nagyon komolyan hangzik (ha valós). Ez előrevetíti minden adatbányász örök álmát, a talált prediktor erős magyarázóerejét.

* A említett indikátor tipikusan nem az a prediktor, amit az emberek oly könnyen befolyásolni tudnak. De még ha igen, akkor sem látszik, hogy milyen irány lenne jó stratégiailag/taktikailag. Azaz a prediktor eléggé ígéretes módon őszintének tűnik, mint a hormonok is, dr. Helen Fishernél, nehéz vele hazudni. ;) Ez az én olvasatomban talán a legkritikusabb pont, bármiféle algoritmusokkal támogatott társkeresésnél.

* Egy dolog látszik csak problémásnak számomra: hogy lehet számokkal mérhetővé tenni a beszédmodort.

Társkeresés és adatbányászat témát érintő blogpostjaim:
Társkeresés adatbányász alapokon
Társkeresés - Numerátorok
Dr. Helen Fisher mint a szerelem "brittudósa"?
Dr. Helen Fisher kérdőíve társkereséshez
Dr. Helen Fisher - Zárszó
Társkeresés adatbányászati támogatással
Beszéd, mint a sikeres párkapcsolat prediktora?
COMMENT:COM: "Házasság első látásra"

Egy SQL-verseny elvi és gyakorlati problémái

.
Ha valaki rákeres SQL kulcsszóval milyen állásokat hirdetnek ilyen tárgyú site-okon (Profession, Jobmonitor, stb.), akkor bármely, akár "punnyadásos", időpillanatban is egyfelöl jó eséllyel fog találni több nyitott poziciót, másfelöl könnyen valószínűsítheti, hogy "trendi" és ígéretes szakma általános követelménye, aminek következtében, megint csak könnyen valószínűsíthetően, jó sok jelölt pályázhat meg egy-egy állást, ahol SQL-lel kell dolgozni.

Ilyen esetekben munkáltató oldalról felmerül az (1) alkalmasság(előszűrés) illetve a (2) legjobb jelölt (versenyszerű) kiválasztásának triviális igénye. Kérdés van-e - és ha igen, akkor mennyire jó - módszertan ilyen jellegű kérdések megválaszolására? Könnyű-e annyira az SQL-tudás mérése, mint a nyelvtudásé (ahol pár perc diskurzus után megbízhatóan érzékelhető, ki mennyire jó nyelvből -> feltéve persze, hogy a munkaadó bír releváns nyelvtudással, ugye).

Nyelvtudás témájából is blogposzt-hegyeket lehetne írni (itt egy friss aktuális példa: Miért kérnek idegen nyelveket?), de most fókuszáljunk csak az SQL-tudásra és mérésére.

Első nehézség, mik a legfontosabb ismérvei egy jó SQL-esnek. Biztosan vitatható lesz amit mondok, én úgy vélem, hogy az alábbi öt dolog:

(1) Megbízhatóság, hogy egy megírt SQL-parancs tényleg azt csinálja, amit a fejlesztője akart. Komoly, aggregált, nagy futási idejű SQL-lekérdezést nem nagyon lehet sokszor futtatni (adott esetben még egy rossz futást lelőni is probléma lehet), és debugolni sem olyan könnyű, mint egy 3GL kódot.A dolog hatványozottan fontos tud lenni meglévő kódok módosítása esetén. Egy-egy rontáson nagyon sok múlhat, miközben a tesztelési költségek behatároltak, pláne nagyon nagy adatbázisoknál.

(2) Gyorsaság: ki kell tudni használni a deklaratív programozás fejlesztési előnyeit.Pláne figyelembevéve az RDBMS-ek magas alap és támogatási bekerülési költségeit, amik az SQL fejlesztési és végrehajtási előnyeit biztosítják.

(3) Komplex - például inline view-s - sql-ek olvasási, írási és módosítási készsége

(4) Logikai műveletek minél hibamentesebb értelmezése. Magam részéről nem pártolom az összetett logikai kifejezések eröltetését, a hibázási valószínűség robbanásszerű növekedésének lehetősége miatt, de ettől még mások preferálhatják és olvasni kell tudni az ő SQL-jeiket.

(5) Képes legyen kölcsönös kétirányú leképezésre/változtatásra (agyban) a fejlesztő, az SQL és a resultset között. Elismerem ez így nagyon homályos és képlékeny, ha analógiát akarnék keresni, akkor valami olyasmire gondolok, hogy a programozó sem soronként "nulláról" ír programkódot illetve képesnek kell lennie a gép "fejével" gondolkodnia. SQL-nél "kevesebb" karakter kell ugyan a kódoláshoz, viszont a resultset "elképzelése" szerintem nélkülözhetetlen követelmény, a hatékony SQL-parancs megfogalmazásához (sőt mindezt végrehajtási aspektusokkal vegyítve)

Magam részéről - egészen a mai napig - úgy gondoltam, hogy, ha nekem kéne valaki jó SQL-est kiválasztanom több emberből, akkor én például a magyar nyelvű szakmai SQL-levlistáról választanék egy-egy problémát és arról beszélgetnék a jelöltekkel. (Ezt előzetesen jelezném is feléjük.) A kiválasztott probléma lehet elméleti is, gyakorlat is (hibakeresés, sql-módosítás, resultsetes sql elemzés, stb.)


Ily módon, 

(1) legalább valamennyire "zárt" a tudásbázis (még ha zajos is).

(2) de kellően "nyitott" is (hiszen régóta van sokezer hozzászólás, feladat, és így nehéz - végeredményt befolyásolóan - célraorientáltan készülni)

(3) aki a levlistán van (erőforrást fektet olvasásába/írásába), annak legyen ennyi "természetes" előnye

(4) a jelölteket felmérő is "(meg)dolgozik", hiszen közreműködik a kiválasztásban: persze nézőpont kérdése, hogy ez mennyire előny -> az én szememben az.

(5) végeredmény konvergálhat a kiválasztás jóságához, például azzal is, hogy a való életből választódik probléma.


Na, de mi a helyzet, ha

(1) több tíz potenciális jelentkezőre kéne minél megbízhatóbban sorrendet alkotni

(2) papír-ceruza alapon kéne dolgozni

(3) nem klasszikus alkalmassági-/vizsgamegfelelés, hanem versenyszerű alapokon való kiválasztás a cél?

Amióta egyre intenzívebben mozgok adatbányász világban, azóta ternmészetes módon izgatnak a verseny-aspektusok. Na ez most ezennel begyűrűzött az SQL-világba is. :o) Annyira azért nem tartom triviálisnak az SQL-versenyzést,  de jó játék lehet belegondolni, hogyan lenne érdemes ilyesmit lebonyolítani.

Lehetséges felvetések/problémák egy egyáltalán nem futurisztikus SQL-verseny kapcsán:

* Kezdem egy elméleti (definiciós) kérdéskörrel: létezik SQL-re "rátermettség"? Aki jó 3GL-es, abból feltétlen "implikálódik" jó SQL-ezés képessége? Stb.

* Legyen OCA/OCP típusú (angol) feleletválasztós teszt a versenyzés alapja? Ez jó lehet disztingválásra, kiválasztásra? Mennyire él egy angol nyelvvizsga feleletválasztós tesztjével való analógia (állítólag az a mondás és ezért preferálják, hogy a jobb angolos jobban tölti ki őket, az én saját tapasztalatom, hogy az ilyen teszteket jobban töltöm ki, mint amennyire jó angolosnak tartom magamat. Avagy a ceruza-papír alapú és/vagy felelet-választós módi leginkább csak alkalmassági előszűrésre alkalmas, versenyzésre nem igazán?

* A győztes jósága mennyiben korrelál az kiválasztás jóságával (elsőfajú hibázás lehetőségei)?

* Létezik-e (és mennyire) olyan SQL-teszt, amit ha valaki nem kellően jól tölt ki (és bukik), attól még érdemes lenne alkalmazni (másodfajú hibázás lehetőségei)?

* Mennyire legyen "nyitott" az anyag? Lehessen rá készülni valahogy előzetesen? Erről célszerű-e bármit egyeztetni a jelöltekkel?

* Mennyire fontos a (help/internet nélküli)  precíz szintaxis szempontja versenyzésnél? Ha az a feladat, hogy írjon be valaki például natív dinamikus ciklusos select feldolgozást pár sorban, abban "lehet-e" hibát ejteni? Lehet-e, jó sql-es, aki helpből másolgat átírásra kódot?

* Az Oracle pszeudó-, sor- és analitikus függvényei, hierarchikus lekérdezései mennyire erős/ütős szempontok képességmérésben? Egyáltalán mi a helyzet az ANSI szabvány vs. Oracle-specifikumokat illetően?

* Sql-performancia? Hintek?

* Sql vs PlSql? Ha PlSql (3GL) is, akkor ott azért már komoly versenyfeladatok képzelhetők el, kérdés persze, hogy az RDBMS-világtól mennyire elszakadóan.

* Meg lehetne-e tölteni egy könyvet jó versenyfeladatokkal?

Na most itt abbahagyom a további kérdés-kigenerálást. :o)


UPDATE-1.

Némileg revideálnom szükséges álláspontomat, azután, hogy tegnap este, nulla rákészülés után, éles körülmények között kitöltöttem otthon, egy gyári, hivatalos, angol nyelvű 1Z0-047 kódú Oracle SQL Expert tesztet. Egy ilyen teszt során 70 kérdésre kell válaszolni, két óra leforgása alatt. 60%-nyi jó válasz után sikeres a vizsga. Nem síma feleletválasztós volt a teszt (mint nyelvvizsga teszteknél), mert van, hogy több jó megoldás is lehetséges volt egy-egy kérdésnél (viszont meglepő módon előre jelzik a tényt is, sőt, hogy hány jó választ várnak el az adott kérdésnél).A két óra is bőven elegendő volt (sőt szerintem túlméretezett), mégha eléggé meg is terhelő a teszt-kitöltés maga.

Parádés módon nagyszerű (plusz élvezetes) volt az a teszt, amit kitöltöttem. 100%-ban olyan dolgokra kérdezett rá, amit szerintem is tudnia kell egy jó SQL-esnek, egyetlen "aljasság" és/vagy vitatható dolog nem volt a tesztkérdések között (nem úgy, mint nyelvvizsga teszteknél). Rendkívüli módon kiváló "vérfrissítésre" is alkalmas, jó tréningnek tartom ezt a fajta tesztet.

Nagyon tetszett a tesztben az is, hogy rengeteg kérdés volt SQL-olvasásra. Vagyis adtak adatmodellt és/vagy SQL create&insert scripteket, és az ezekre megírt közel nem triviális SQL-eket kellett elemezni a kérdés megválaszolásához (alapvetően ANSI SQL-eseket). Én az ilyen típusú feladatokat tartom a legegészségesebbnek.

A teszt alkalmas lehet a szakmai angol tesztelésére is (esetleg szükség esetén némileg tuningolva, mert a teszt angolja tényleg nagyon egyszerű volt). Továbbá szerintem megoldja azt a problémát is, hogy feltétlen kelljen papír-ceruza alapon kódokat írni (help nélkül).A teszt-kiértékelés is tudhat menni könnyedén.

Szóval nem biztos, hogy fel kell találni a meleg vizet még egy versenyszerű kiválasztáshoz sem. Ilyen tesztekből bárki össze tud állítani magának egy jó tesztet saját használatra,sőt bővítheti feladatbankját saját SQL-olvasási/-módosítási példákkal. Esetleg PlSql-tesztekből is át lehet emelni példákat szükség esetére. Kiváncsi lennék hányan élnek ilyen módival.

Nekem mindig is voltak kifogásaim egy OCP-vizsgával, leginkább olyan téren, hogy szükséges volt hozzájuk valami nem éppen jó, olcsó és/vagy hasznos Oracle eszköz(ök) precíz tudása. Márpedig abból, hogy az Oracle jó és sikeres RDBMS-t tudott fejleszteni, nem következik, hogy jó és sikeres front-end eszközöket is tud(ott). Sőt. Ezt a fajta Oracle-specifikumot (és eröltetését) én perdöntő módon inkorrektnek tartom, ami alkalmas lehet súlyos aránytévesztésre/megtévesztésére is a vizsgára befizetők, valamint a jóhiszemű potenciális munkadók körében. Na ez a mostani Oracle SQL-Expert teszt hálistennek visszaadott némi jó szájízt.


UPDATE-2.

Hali,

Itt egy kilenc feladatos, Papír-ceruzás SQL-teszt. Kidolgozási idő szigorúan egy óra. Emlékezetből írom, nem kizárt, hogy hibázok. Ezért előre is elnézést kérek.

Ügyfél(ügyfél_id,ügyfél_név)
Számla(ügyfél_id,számla_id,egyenleg_dátum,számla_egyenleg)
Tranzakció(tranzakció_id,ügyfél_id,számla_id,tranzakció_ideje,tranzakció_összeg)
Ügyfélkapcsolat(id,ügyfél_id1,ügyfél_id2)

1. Listázandók az inaktív ügyfelek, akik az elmúlt 30 napban nem tranzaktáltak.

2. Az ügyfeleknek hány számlájuk van?

3. Az aktuális számlaegyenlegekből meghatározandó a 30 nappal ezelötti számlaegyenlegek, a tranzakciós adatok révén.

4. Itt volt egy 30 napi forgalmi adat alapján valami kiválasztás. Egyszerű volt, de már nem emlékszem rá vissza pontosan. :o(

5. Akkor nem tekinthető sikeresnek egy napi zárás, ha a tranzakció táblán a napi összesítés nem fut ki nullára. Mely napokon nem volt sikeres zárás?

6. Listázandók azon ügyfelek, akiknél van legalább egy 45 napos intervallum, amikor több mint 100.000 fórint jóváírás érkezett.

7. Egy ügyfél közvetlenül és közvetetten is kapcsolódhat egy másik ügyfélhez (egy másik ügyfélen keresztül). A tranzitivitási lánc tetszőleges hosszú lehet. Egy-egy ügyfélnek hány (közvetlen és közvetett) kapcsolata van?

8. Készítendő egy output, ahol ügyfél_id-nként az első, második, harmadik számlához tartozó pozitív előjelű tranzakció összegek végösszege jelenik meg, 2010.11.01 utáni tranzakciókra.

9. Listázandók azon ügyfelek, akiknek legalább 7 negatív összegű tranzakciója van 2010.11.01-től kezdve, ezen tranzakciók átlaga kell ügyfelenként, úgy, hogy a három legkisebb és legnagyobb összegű tranzakció nem számolódik bele az átlagba.

Azt gondolom ez egy igazi emberkínzós "teszt"(?), mind megírni, mind kijavítani (pláne nagyüzemben). Főleg annak ismeretében, hogy az én kézírásom csúnyább, mint a világ legcsúnyább nője, a néhai Zámbó Jimmy....
;)

Az egy óra is elég kevés érzésem szerint, én legalábbis kihasználtam a rendelkezésre álló időt.

A feladatok viszont zseniálisak, szvsz. Ezért is osztom meg őket, tanulságképpen.


UPDATE-3.

Szerintem a legfontosabb azonosítani, hogy szakmailag mitől jó egy SQL-es, ahogy ezt fentebb is megkíséreltem. A további kérdésekre az én válaszkezdeményeim:

* Szvsz, aki (ösztönösen) jó 3GL-ben, nem feltétlen jó SQL-ben is. De van komoly esélye jónak lennie benne, leginkább avval, ha sikerül érdemben ráéreznie az ízére. Sokkal nehezebbnek érzem az átmenetet 3GL és SQL között, mint két 3GL nyelv között. Valamint én megkülönböztetek OLTP-s és adattárházas (analitikus) SQL-est is. Az elöbbi lényegesebben könnyebb műfaj, szvsz.

* Immáron azt vélem, hogy a feleletválasztós teszt csomó előnyén túl, a versenyszerű kiválasztásra is alkalmas (legalkalmasabb?). Főleg, hogy a kiválasztásnál egyéb szempontok is vannak, más véleményekkel összhangban. Azt nehezen tudom elképzelni, hogy aki jól tud olvasni/módosítani kemény komplex SQL-eket, az ne tudna írni is jól SQL-eket. (Nyelvnél ez például távolról sincs így, szvsz). De befolyásolható vagyok a kérdésben. ;)

* Az elsőfajú hibázást sokkal valószínűbbnek tartom mint a másodfajú hibázást. Analógia: szerelembe könnyebb esni, mint komoly, tartós, boldog házasságba lépni. Illetve, ha valaki első körben ellenszenves, nehéz lesz lesz másodjára szerelemre kiválasztani, még ha jó sok hálivúdi film is szól ilyesmiről. ;)

* Én pártolom, hogy minél zártabb legyen az anyag, amiről szólna a verseny (előzetes informálással), de nyilván nem publikus tesztsor alapján versenyeztetnék.

* Én nem vagyok híve a precíz szintaxis számonkérésének (tőlem még a hierarchikus query vázát is lehet helpből másolni, az analitikus függvényekről nem is beszélve). Például mert hasznosabb agyi tevékenységek elöl veheti el az erőforrást. De el tudom fogadni az ellenvéleményt is.

* Tetszik nem tetszik, az ANSI-szabvány "tudása" nehezen megkerülhető. Olvasni mindenképpen kell tudni ilyen SQL-eket, szvsz.

* Oracle-specifikumok nálam opcionális kategória. Szerintem fontosabbak az eddigi szempontok, illetve ezek a specifikumok menetközben felszedhetők, külön tanfolyam nélkül is. De el tudom képzelni, hogy valaki munkaadó igényelje ezt kiválasztásnál valamilyen (rákérdezési) szinten.

* Nem OLTP-s, hanem analitikus SQL-ezésnél, szerintem érdemes firtatni performancia-kérdéseket, ahogy PlSql-es kérdéseket is, de ez az esetemben lehet, hogy már az agykárosodás kategóriája. :o)

* Hogy mennyire vendorspecifikus kell legyen a kiválasztás? Én inkább úgy teszem fel a kérdést, hogy drágább RDBMS-hez, talán drágább alkalmazottak tartoznak jellemzőbben (hogy mennyire indokoltan az lehet vita tárgya). MySQl 3.2-höz nem feltétlen alkalmaznék Oracle 11g profit (most így extrapolálva). Viszont, ha MySql-s OLTP-s tudás kell, engem nem zavarna, hogy valaki PostgreSQL-ben szerezte a tapasztalatát (vagy fordítva).

* Azt én is jónak tartanám, ha lennének jó, strukturált és karbantartott feladatbankok SQL/PlSql-re. Bennem a kérdés immáron az, hogy mennyire inkább az önképzéshez tartozóan, és mennyire a versenyszerű kiválasztást támogatva.

* Az emberi és egyéb képességek szerintem is nagyon fontosak (szakmain túl és persze perspektivikusan is). És akkor tényleg ott van még a fizetésigény kérdése is. ;)