Bazat e të dhënave 1. Skedarët sistemor dhe bazat e të dhënave • Skedarët sistemor • Bazat e të dhënave • Modelet 2. Modeli relacional 3.Modeli E – R. 4. Normalizimi 5. SQL 6. Disajnimi i përparuar dhe implementimi 7. 8. Distribuimi Klient Serverët 9. Bazat e orientuara në objekte
1
Leksioni 1 Të marësh vendime të saktë kërkohet informacion i mirë, që merret nga fluksi i fakteve që njihen si të dhëna. Bazat e të dhënave e kanë origjinën në sistemet e skedarëve, të cilat aktualisht janë komplet jasht mode, megjithatë t’i kuptosh ata është e rëndësishme, sepse karakteristikat bazë të sistemeve të skedarëve janë burimi i disa kufizimeve serioze të administrimit të të dhënave. Nga ana tjetër duke kuptuar sistemet e skedarëve, ju jeni më të prirur për ta kuptuar përse dhe si vetitë specifike të bazave të të dhënave janë mjaft të dobishme dhe do t’i shfrytëzoni këto veti në mënyrë të përshtatëshme. Për të kuptuar arsyen e konceptimit të bazave të të dhënave duhet vënë në dukje diferencat ndërmjet informacioneve dhe të dhënave. Të dhënat janë flukse faktesh. Supozojmë se kompania KOMROB (KOMpania ROBotike) kur dy devizione dhe secili prej tyre ka gjeneruar 1.380.456 dhe 1.453.507 dergësa respektivisht nga tremujori i parë 1999 deri në tremujorin e parë 2003. Kompania përmban 2.834.363 dergësa dhe po kaq fatura shpenzimi. Është e kuptueshme se për të nxjerrë konkluzione të ndryshme në rang devizionesh dhe për çdo tremujor kërkohet një punë mjaft sistematike në trajtimin e të dhënave. Koha jonë quhet “mosha e infirmacionit”. Ky term nënkupton prodhimin e një informacioni të mirë, relevant dhe në kohën e duhur. Le të përmbledhim disa elemente bazë: Të dhënat formojnë blloqet e ndërtimit të informacionit. Informacioni prodhohet nga përpunimi i të dhënave. Informacioni përdoret për të zbuluar kuptimin e të dhënave. Informacioni i mirë, relevent dhe në kohë është çelësi i marrjes së vendimeve të mira. Marrja e vendimeve të mirë është çelësi për të organizuar mjedisin global. Baza e të dhënave është bashkësia e strukturuar e të dhënave e regjistruar në su informatikës për të kënaqur në mënyrë të njëkohëshme shumë përdorues në mënyrë selektive dhe në kohë të ndarë. Duke ia referuar praktikës vemë në dukje konceptet që lidhen me bazar e të dhënave. Administrimi i të dhënave (Data Management) është disiplina që merret me gjenerimin, ruajtjen dhe marrjen e të dhënave. Administrimi i të dhënave kërkon përdorimin e databazës të kompjuterit. Databaza përbëhet nga: • Të dhënat e përdoruesit fundor, që jane fakte me interes për të. • Metadata ose të dhëna mbi të dhënat, nëpërmjet të cilave të dhënet janë integruar. Metadata prodhojnë përshkrimin e karakteristikave të të dhënave dhe bashkësinë që ekzistojnë ndërmjet tyre.
2
Në këtë kuptim databaza i ngjan përmbajtejes së një kabineti elektronik të organizuar mjaft mirë, në të cilin një program mjaft i fuqishëm i njohur si sistemi i administrimit të të dhënave (DBMS) krijon administrimin e përmbajtejs së kabinetit.DBMS është një koleksion programesh që administron strukturën e të dhënave dhe kontrollon aksesin në të dhënat e ruajtura. DBMS janë mjaft të rëndësishëm në shoqërinë tonë të informacionit. Në këtë kuptim vemë në dukje: • DBMS ndihmon në menaxhimin e të dhënave në mënyrë mjaft efektive, në raport me periudhën kur kjo mënyrë nuk ekzistonte. • DBMS përmban gjuhën e pyetjeve (query language) që bënë të mundur të marrësh përgjigje për pyetje të ndryshme. • DBMS bëni të mundur krijimin e mjedisit në të cilin përdoruesit fundor kanë akses dhe administrim gjithnjë e më të mirë. • Kjo sjellë një pamje të integruar të veprimeve të organizmit. • DBMS redukton paqëndrueshmërinë e të dhënave. Në menyrë skematike lidhja e përdoruesit fundor me databasin jepet më poshtë. Aplikimi (info) Përdoruesi fundor
Të dhënat DBMS
Struktura e Db Metadata Klientët Produktet
Të dhënat
Shërbimet
Të dhënat e përdoruesit fundor
Aplikimi (Info) Aplikimet e përdoruesve mund të shkruhen në gjuhë programimi p.sh. COBOL ose në programet e përdorshëm në DBMS (DML). • Përse është i rëndësishëm desinjimi i një Db. Desinimi i një databaze është një punë vendimtare gjatë ndërtimit të Db, prandaj edhe i kushtohet një rëndësi e veçantë në zhvillimin e kushtit. Një bazë të dhënash e dezinjuar mirë sjell pakësimin e llafollogjisë. Llafollogjia arrihet kur të njëjtat të dhëna ruhen në dy vende, dhe sjell gabime me trajtimin e të dhënave.
3
Përafrimi tradicional i bazave të të dhënave: Megjithëse sistemi i skedarëve është mjaft i vjetruar në ditët tona, ka një seri arsyesh për t’i studjuar ata: • Sistemi i skedarëve na jep prespektivë historike mbi mënyrën se si janë trajtuar të dhënat. • Filozofi George Santagana ka theksuar “ata që nuk kujtojnë të shkuarën janë të dënuar ta përsërisin atë”. • Një kuptim i karakteristikave të thjeshta të sistemit të skedarëve bën që kompleksiteti i konceptimit të bazave të të dhënave të kuptohet lehtë. • N.q.s. kërkoni të konvertoni një sistem skedarësh të vjetruar në sistemin e bazave të të dhënave, jokonvente mbi sistemin e skedarëve janë të dobishme. Në të shkuarën manaxherët e organizmave të vogla ishin të afta të ruanin të dhëna duke përdorur sistemin manual të skedarëve. Ky sistem skedarësh përbëhej nga koleksion dosjesh të cilat identifikoheshin saktë dhe ruheshin me radhë në kabinetin përkatës. Një dosje në klinikën e mjekut përmban të dhënat e pacientit, duke patur një dosje për çdo klient. Në mënyrë të ngjashme manaxheri i personelit mund të organizojë të dhënat të dhënat e personelit me kategori të punëve që kryhen (hierarhike, teknike, pages etj.). Në dosjet klinike mbahen punonjësit detyrat e të cilëve janë teknike. Gjatë periudhës kur të dhënat janë të pakta sistemi manual e kryen funksionin e tij. Megjithate me rritjen e organizmit dhe me rritjen e kompleksitetit të raportimeve, ruajta e të dhënave me sistemin manual bëhet gjithnjë e më i vështirë. Kalimi nga sistemi manual i skedarëve në sistemin kompjuterik të skedarëve nga pikpamja teknike është kompleks. Si rrjedhim ç’faqet një tip i ri profesioni i njohur si specialist i përpunimit të të dhënave (Data ProcessingSpecialist =DP specialist). Specialisti i DP krijon strukturën e nevojshme të skedarëve, shpesh shkruan programe që administrojnë të dhënat dhe prodhojnë raportet përkatëse. Fillimisht skedarët e kompjuterëve me sistemin e skedarëve ishin të ngjashëm me skedarët manual. Le të marrim një shembull të skedarit të të dhënave të klientëve në një kompani të vogël sigurimesh siç tregohet në figurën në vazhdim.
K_Emri
K_Phone
K_Adrese K_Zip A_Emër
A_Phone
TP AMT REN
4
Alban Mali Besnik Skembi Agron Deti Skender Kodra Vera Fusha Petrit Degoi Luan Curi Alma Ferra Genti Ullari Monda Dardha
55 52 55 56 89 52 65 89 78 67
4 273394 2 456920 4 719412 7 920032 5 420012 2 125983 4 654322 5 652421 6 189124 7 254125
36123 25246 36123 36123 36155 25246 37118 37119 25432 37118
Legjenda: K_EMËR : Emri i klientit K_PHONE : Numri i telefonit agjentit të klientit K_ADRESE: Adresa e klientit K_ZIP : Kodi ZIP i klientit sigurimit
Arjan Tirana Elton Durësi Arjan Tirana Arjan Tirana Elton Durësi Xhim Kovça Arjan Tirana Xhim Kovça Elton Durësi Xhim Kovça
52 2 321456 56 3 412123 65 7 721892 52 2 622321 52 3 451154 55 4 721182 65 5 921128 66 3 425126 55 4 645133 52 3 654331
T1 T1 T2 S1 T1 T2 S1 S1 T2 S2
$100 $250 $150 $300 $100 $850 $120 $250 $100 $100
A_EMËR : Emri i Agjentit A_PHONE: Numri i telefonit të TP : Tipi i sigurimit AMT : Mandati i sigurimit REN : Data e renovimit të
Skedari i treguar më sipër përmban 10 rekorde. Çdo rekord është i përbërë nga 9 fusha. Regjistrimet janë ruajtur në skedarin me emrin KLIENT. Duke përdorur skedarin KLIENT specialist i DP shkroi programet që prodhojnë raporte të dobishme për departamentin e shitjes (sales). • Përmbledhjet mujore që tregojnë tipet dhe mandatet e sigurimit të realizuara nga çdo agjent (analizohet produktiviteti i çdo agjenti). • Pagesat mujore për të përcaktuar cilët klient duhen kontaktuar për rinovimin e sigurimit. • Raporti i cili përcakton raportet e typeve të sigurimeve për çdo agjent. Me kalimin e kohës shkruhen programe shtesë për të krijuar raporte të reja. Në vazhdim Departamenti i shitjes krijon skedarin SHITJE, i cili mban veprimet ditore të Departamentit. Për të raportet mbi pagesën e personelit, specialisti i DP kërkon krijimin e skedarit AGJENT. Duke u rritur numri i skedarëve krijohet një sistem i vogël skedarësh që tregohen në figurën e më poshtë.
Departamenti i shitjes
Departamenti i personelit 5
Programet e administrimit të skedarëve
Raportet
Skedari KLIENT Programet e administrimit të skedarëve
Programet e administrimit të skedarëve
Raportet
Skedari Agjent
Raportet
Skedari SHITJE Sistem Skedarësh i thjeshtë Administrimi i sistemit të skedarëve Çdo problem i zgjidhur në sistemin e skedarëve të të dhënave kërkon programim në brezin e tretë të gjuhëve të programimit (therd-generation language – 3GL). 3GL kërkojnë nga programisti të specifikojë se çfarë duhet bërë dhe si duhet bërë. Shembuj të 3GL janë COBOL, BASIC, FORTRAN etj. Në këtë model për çdo skedar krijon Programet e administrimit të skedarit. Në këtë sistem elementet e sigurisë siç janë mbrojtja me fjalë kalimi, ruajtja nga vëzhgimet e skedarëv ose të sistemit të skedarëve janë të vështirë për t’u programuar.
6
Disavantazhet e sistemit të përpunimit të skedarëve 1. Teprimet e pa kontrolluara Së pari: hapsira e kujtesës shpenzohet shpejt Së dyti: të njëjtat të dhëna regjistrohen disa herë Së treti: paqëndrueshmëria (njëri ekorigjon tjetri jo) 2. Mungesa e elasticitetit Nuk i përgjigjet kërkesave komplekse menjëherë.
3. Standardizimi i dobët Sinonima: dy emra të ndryshme për të njejtën gjë. Homonimia : kur një emër përdoret për dy gjëra të ndryshme. 4. Produktiviteti i ulët i programimit Duhet konceptuar çdo skedar dhe regjistrimi i përdorur nga një aplikim i ri.
5. Kostoja e lartë e mirëmbajtjes: Aplikimet e ndryshme kanë programe individuale. Kështu që mirëmbajtja nxjeri problemet e standardizimit.
7
Funksioni i DBMS DBMS kryen funksione mjaft të rëndësishme që garantojnë integritetin dhe qëndrushmërinë e të dhënave në Databazë. Shumica e këtyre funksioneve janë transparente për përdoruesin fundor dhe mund të arrihen nëpërmjet DBMS. Këtë përfshinë funksionet e mëposhtme: 1. Administrimi i fjalorit të të dhënave(Data Dictionary Management) DBMS kërkon përcaktimin e elementeve të të dhënave dhe relacionet (metedata) që ruhen në fjalorin e të dhënave. Të gjithë programet që hapen të dhëna në D.base punojnë nëpërmjet DBMS. DBMS përdor fjalorin e të dhënave për të gjetur komponentët e kërkuar të të dhënave si nga struktura dhe nga të dhënat. Vëmë në dukje se çdo ndryshim që bëhet në strukturën e të dhënave automatikisht duhet paraqitur në fjalorin e të dhënave, duke na çliruar nga modifikimi i gjitha programeve që kanë cilësi në bazën e të dhënave. 2. Administrimi i ruajtjes së të dhënave (Data storage management). DBMS Krijon struktura komplekse që kërkohen poër ruajtjen e të dhënave, që na çliron ne nga puna e vështirë e përcaktimit dhe programimit të karakteristikave fizike të të dhënave. DBMS modern administron kujtesë jo vetëm për të dhënat, por edhe për format e ikonave që shërbejn për regjistrimin e të dhënave, përcaktimin e raporteve, rregullat e vlefshmërisë etj. 3. Transormimi dhe prezentimi i të dhënave: (Data transformation and presentation) DBMS i transformon të dhënat e regjistruara në përputhje mestrukturën e të dhënave që është kërkuar. DBMS na çliron nga puna për të bërë diferencën ndërmjet formatit logjik të të dhënave dhe formatit fizik të tyre. Paqëndrueshmëria e të dhënave. Kur të njejtat të dhëna janë ruajtur në vende të ndryshme, paqëndrueshmëria e të dhënave është e paaritshme. P.sh. disa skedarë përmbajnë të dhënat e klientit. Supozojmë se do të ndryshojnë adresën e një klienti. Që skedarët të jenë të qëndrueshëm duhet të bëhet njëherësh (dhe në mënyrë korekte) në çdo skedar janë kontrolluar nga përdorues të ndryshëm është e mundshme që ndonjë skedar të paraqesë adresën e vjetër ndërsa të tjerët kanë adresën e re.
8
Paqëndrueshmëria e të dhënave është burimi më i madh i gabimeve në aplikimet e kompjuterizuara Mungesa e elasticitetit: Sistemi i përpunimit të skedarëve bashkon disa lehtësira të prodhimit. Ky sistem prodhon shumë dokumente dhe raporte të punës së përditshme. Por sistemi nuk mund t’i përgjigjet në mënyrë të menjëhershme kërkesës për një “produkt” të konceptuar rishtaz. Kjo krijon shpesh probleme tek përdoruesit, të cilët nuk kuptojnë përse sistemi nuk plotëson kërkesën e tyre. Kufizuashmëria e Ndarjes së të dhënave: Me përafrimin tradicional, çdo aplikim ka skedarët e tij privat dhe është një shansë i vogël për përdoruesit për të ndarë të dhënat jashtë aplikimeve të tyre. Pasoja e parë e ndarjes së kufizuar është se të njejtat të dhëna të futen disa herë me qëllim që të bëhen modifikimet e skedarëve. Pasoja e dytë është në zhvillimin e aplikimeve të reja, konceptuesi e ka të vështirë të përdorë skedarët ekzistues. Standardizimi i dobët: çdo organizëm kërkon procedura dhe metoda standarde që të operojë në mënyrë efektive. Në sistemet e informacionit standardet arrihen nëpërmjet emrit të të dhënave, formateve dhe kufizimeve të hapjes. Standardet është vështirë të arrihen në sistemin tradicional të përpunimit të të dhënave, kryesisht se përgjegjësia e konceptimit të sistemit është decentralizuar. Dy tipe paqëndrueshmërie mund të rezultojnë nga standardizimi i dobët. Rezultatet Sinonim kur dy emra të ndryshëm janë përdorur për të njejtën rubrikë të dhënash p.sh. numri i studentit dhe numri i meshkujve. Homonimi është një emër i vetëm që është përdorur për dy rubrika të ndryshme. Produktiviteti i ulët i programuesit : Në sistemin tradicional të përpunimit të skedarëve programuesi duhet të konceptoj çdo regjistrim dhe skedar të përdorur nga një aplikim i ri dhe pastaj kodin e përcaktimit të të dhënave në program. Programuesi duhet veç të tjerash të seleksionij metodën e haëjes së skedarit që do të përdoret dhe pastaj të shkruajë shprehjet e lexim/shkrimit në një program procedural. Kjo ngarkesë në konceptimin e skedarëve dhe regjistrimeve, përshkrimi i të dhënave dhe shkrimi procedurave të lexim/shkrimit është përsëritur për çdo aplikim dhe përbën një pjesë të madhe të zhvillimit të sistemit. Kostoja e lartë e mirëmbajtjes: Në sistemin e përpunimit të skedarëve, përshkrimi i skedarëve, regjistrimeve dhe rubrikave të të dhënave janë të ndërthurura me programet individuale të aplikimit. Megjithatë ndryshimi në skedarët e të dhënave (p.sh. ndryshimi i emrit të të dhënës, formati ose metodës të hapjes) kërkon që programi ose programet të modifikohen. Disantazhet e diskutuara këtu i pëtkasin brezit të parë dhe të dytë të gjenerimit të aplikimeve. Megjithatë veprimi i disa disavantazheve mund të ulët duke e bërë 9
kështu më të ulët koston e ndërhyrjes së njeriut në aplikimet. Zgjidhja më e mirë është për të ndërtuar standarde në përpunimin e të dhënave duke krijuar filozofonë dhe mjedisin automatik në të cilin këto disavantazhe mund të kontrollohen ose të eliminohen që në fillim. Kjo është ideja e përafrimit me baza të dhënash.
Përafrimi me baza të dhënash Përafrimi ma baza të dhënash përfaqëson një koncept të ndryshëm me qeverisjen e burimeve të informacionit. Të dhënat shihen si një burim i rëndësishëm, i ndashëm që mund të administrohet si çdo bashkësi tjetër, si njerëzit, materialet, paisjet dhe lekët. Në përputhje me Weverest (1976) koncepti i bazave të të dhënave është përqëndruar në ndarjen e përbashkët të burimeve të të dhënave, kontrolli i plotë i burimeve të të dhënave nga një përgjegjës i përbashkët dhe kooperimi në përmbajtjen e këtyre burimeve të të dhënave të ndarë. Baza e të dhënave është një bashkim i ndarë i të dhënave bashkëvepruese, të konceptuara për të plotësuar nevojat me informacion të përdoruesve të shumëfishtë. Sejcili përdorues mund të kryejë një pamje unike të bazës së të dhënave në përuthje me nevojet e tij për informacion. Të dhënat janë ruajtur kështuqë ato janë të pavarura nga programet që ata përdorin. Përafrimi i përbashkët dhe i kontrolluar përdoret në kapjen dhe mbrojtjen e të dhënave, në shtimin, modifikimin dhe heqjen e të dhënave. Baza e të dhënave është ilustruar në fig. 1-5. Baza e të dhënave përbëhet prej 10 skedarësh, vijat që lidhin skedarët paraqesin bashkëveprim ndërmjet tyre. Ndryshe nga fig. 1-2 dhe fig. 1-3 skedarët në fig. 1-5 nuk janë të lidhur direkt me aplikimin. Në filim në B.D.ishin aplikimet e administrimit. Sot B.D. janë kudo. Ka një treg të madh të programeve dhe informacioneve. Historiku: 1960: skedarët COBOL (gjuha COBOL u përdor si gjuhë e SEBD) 1920: B.D. hierarhike dhe rrjetore. 1980: B.D. relacionale 1990: B.D. objekt 2000: B.D. të orientuar objekt.
10
Përafrimi me B.D. • I kanë si dënim të dhënat të pavarura nga trajtimi. • Përshkruan informacionet në kuadrin e një aplikimi konkret: - B.D. të shërbimit spitalor: të sëmurët, shërbimet etj. - B.D. universitare: studentët, pedagogët, kurset, diplomat etj. - B.D. të filmave : titujt, vitet e prodhimit, aktorët, buxheti etj. Interesohuni për të dhëna me vakum të madh. 1 mega = 166 , 1Giga = 109. Tera = 1012bytes
11
Përfitimi nga përafrimi me Baza të Dhënash Përafrimi me baza të dhënash ofron një numër potencial avantazhesh. Ky përfitim përfshin teprime minimale tek të dhënat, qëndrueshmërinë e tyre, integrimin, ndarjen, forcimin e standardit, lehtësi në zhvillimin e aplikimeve, siguri uniforme, intimitetin (privacy), kontrollin e integruar, aksesin në të dhënat dhe përgjigjen pavarësinë e të dhënave dhe mirëmbajtjen e reduktuar të programeve. Teprimet minimale të të dhënave: Në përafrimin me baza të dhënash skedarët e të dhënave janë integruar në një strukturë të vetme logjike. Në vazhdim çdo ndodhje e një njësie të dhënash është kontrolluar në mënyrë ideale vetëm në një vend të bazës së të dhënave. P.sh. fakti SHIT NË ADRESËN për një klient specifik, mund të jetë e regjistruar në dy skedarë të ndarë në sistemin e përpunimit të skedarëve. Në sistemin e bazave të të dhënave, ky fakt do të regjistrohet vetëm një herë. Me këtë nuk duhet thënë se të gjitha teprimet do të zhduken. Shpesh herë ka arsye të qëndrueshme për të ruajtur kopje të shumëfishta të së njëjtës të dhënë (P.sh. të dhënat e efektivitetit të kopjes, të dhënat e kontrollit të vlefshmërisë). Megjithatë në sistemin e bazave të të dhënave, teprimet janë të kontrolluara. Qëndrueshmëria e të dhënave duke eliminuar (ose kontrolluar) teprimet në të dhënat ne reduktjmë shum shanse për paqëndrueshmëri p.sh. çdo SHIT NE ADRESEN është ruajtur vetëm një herë, pra nuk mund të kemi mospërputhje në vlerat e ruajtura. Kurë në bazë të të dhënave janë lejuar teprimet, sistemi i bazave të të dhënave vetë e forcon qëndrueshmërinë duke modifikuar çdo ndodhje të njësisë së të dhënës. Në qoftë e njësia SHIT NE ADRESEN është ruajtur në dy regjistrime të ndryshme në bazat e të dhënave, atëherë sistemi i bazave të të dhënave do të bëjë korigjimin në të gjithë regjistrimet ku ndodh ndryshimi. Fetkeqësisht, shum sisteme sot nuk veprojnë për qëndrueshmërinë në këtë mënyrë. Pamja 1
Pamja 2
Pamja 3
Shitja
Llogaria
Porositë
Klientat
Klientat
Porositë
Porositë
Klientat
Dërgesat
Klientat
Klientat
Tre pamje përdoruesish të ndryshme.
12
Integrimi i të dhënave Në bazat e të dhënave, të dhënat janë organizuar në një strukturë të vetme llogjike së bashku me relacionet llogjike të përcaktuara ndërmjet njësive të caktuara të të dhënave. Në këtë mënyrë përdoruesi mundet të lidhë lehtësisht një njësi të dhënash me një tjetër. P.sh. po të lidhni një shikim në dhe të merni në konsideratë një Prodhim, kjo njësi është e lidhur me Materialet dhe përdoruesi mund të përcaktojë se çfarë materialesh janë të nevojshme për një prodhim të caktuar. Ndarja e të dhënave Baza e të dhënave është krijuar që të ndahet nga të gjitha përdoruesit e autorizuar në organizëm. P.sh. në një kompani të implementosh bazën e të dhënave do të thotë të plotësosh nevojat për informacion të llogarisë, shitjes, prodhimit, dërgimit dhe departamenteve të tjera. Shumica e bazave të të dhënave sot lejojnë përdoruesit e shumëfishtë për të ndarë bazën e të dhënave në mënyrë konkurente, megjithatë disa kufizime janë të nevojshme siç do të shihet në kapitujt e mëposhtëm. Në sistemin e bazave të të dhënave, çdo departament funksional është paisur me pamjen (ose pamjet) e tij të bazës së të dhënave. P.sh. 1-7 tregon 3 pamje të ndryshme për K.P.D. Pamja e parë është për Departamentin e shitjes dhe tregon relacionet ndërmjet Klientit dhe njësive të Porosive. Pamja e dytë është për departamentin e Llogarisë dhe tregon relacionet ndërmjet Klientit, Porosive dhe njësive të Dërgimit. Pamja e tretë është për Departamentin e Porosive dhe tregon relacionet ndërmjet Produktit, Shitësit dhe Materialeve. Forcimi i Standardizimit. Krijimi i funksionit të administrimit të bazave të të dhënave është një pjesë mjaft e rëndësishme e përafrimit me baza të dhënash. Ky funksion organizativ ka autiritetin të përcaktojë dhe të përforcojë standardin e të dhënave. Nëqoftëse në K.P.D. përcaktohet funksioni i administrimit të bazave të të dhënave, kjo zyrë do të përcaktojë të gjitha emrate të dhënave dhe formatin si dhe akordon të drejtat e hyrjes për të gjithë kompaninë. Mbi të gjitha ndryshimet në standardin e të dhënave do të miratohet nga administrimi i bazave të të dhënave. Lehtësia në zhvillimin e aplikimeve: Avantazhi kryesor i përafrimit me baza të dhënash është se kostoja e kohës për zhvillimin e aplikimeve të reja është më e ulët. Studimet tregojnë se kur baza e
13
të dhënave është konceptuar dhe krijuar, programuesi e përcakton dhe e zhvillon aplikimin e ri 2-4 herë më shpejt se me baza të dhënash konvencionale.
Siguria uniforme, Intimiteti dhe Kontrolli i Integritetit: Funksioni i administrimit të të dhënave ka juridiksionin e plotë mbi bazën e të dhënave dhe është përgjegjës për ndërtimin e kontrolleve të aksesit, modifikimit dhe mbrojtjes së të dhënave. Procedurat standarde të kontrollit dhe të standardizimit përmirësojnë mbrojtjen e të dhënave në krahasim me ato të sistemit të skedarëve të të dhënave. Megjithatë, nëqoftëse nuk janë aplikuar kontrolle të mirëfillta baza e të dhënave është më e paraqitshme se skedarët konvensional, meqenëse një bashkësi përdoruesish kanë ndarë burimet e përbashkëta. Hyrja dhe përgjigja e të dhënave: Sistemi i bazave të të dhënave krijon disa rrugë marrje për çdo njësi të dhënash, duke i dhënë përdoruesit më shumë fleksibilitet në vendosjen dhe marrjen e të dhënave se sa me skedar të dhënash. Pavarësia e të dhënave Ndarja e përshkrimit të të dhënave nga programet e aplikimit që përdorin të dhënat është quajtur pavarësi e të dhënave. Si rezultat i pavarësisë së të dhënave organizmi mund të zhvillojë aplikime të reja pa pasur nevojë të ndryshojë aplikimet ekzistuese. Reduktimi i mirëmbajtjes së programeve: Të dhënat e ruajtura mund të ndryshohen shpesh për arsye të ndryshme. Shtohen njësi të reja, ndryshohen formatet të dhënash, paisje të reja kujtesë ose metoda të kapjes futen e kështu me rradhë. Në mjedisin e skedarëve të të dhënave këto ndryshime kërkojnë midifikimin e programeve të aplikimit që përdorin të dhënat. Termi i mirëmbajtjes i referohet modifikimi ose rishikimit të programeve të vjetra për t’i bërë ata konform me formatet e reja të të dhënave, metodat e kapjes etj. Në sistemin e bazave të tëdhënave, të dhënat janë të pavarura nga programet e aplikimit që i përdorin ato me kufizimet e mundshme ose të dhënat ose programet e aplikimit kërkojnë ndryshimin në faktorët e rinj që shtohen.
14
Komponentët e mjedisit të bazave të të dhënave Komponentët kryesorë të mjedisit tipik të bazave të të dhënave janë treguar në fig. 1-8. Duke studjuar këta komponentë dhe lidhjet ndërmjet tyre ju do të keni një kuptim më të mirë të përafrimit me baza të dhënash dha avantazhet që ata kanë. Të gjashtë komponentët e treguar në fig. 1-8 janë përshkruar shkurtimisht në listën që jepet më poshtë. 1. Grupi i përdorësve: Grupi i përdorësve përbëhet nga kërkuesit e të dhënave. Kemi 3 kategori kryesore të kërkesave të përdoruesve: vetëm lexim, shtim/fshirje dhe modifikim. Të gjitha kërkesat për të dhëna janë realizuar nëpërmjet SQBDH. Ky sistem duhet të iterpretojë instruksionet e shprehura në termat e skemës së jashtme për t’i kthyer ato në urdhëra në bazën e të dhënave fizike. Arkitektura e një SQBDH ka realizime të ndryshme sipas natyrës së saj, por kryesorja rrjedh identike dhe lejon të sktësohen në mënyrë të përafërt principet bazë.
Ndërfaqësi Përdoruesi/Sistem
Niveli konceptial Udhëzuesi Fjalorit të të dhënave
SQBDH
Baza e të dhënave
Niveli i brendshëm Skema e brendshme
Administrimi Bazave të të Dhënave
Fig. 1-8 Komponentet e mjedisit të bazave të të dhënave 2. Sistemi i Qeverisjes së Bazave të të Dhënave (SQBDH) është një sistem programesh që merr dhe plotëson të gjitha kërkesat për të dhëna. Normalisht, SQBDH lejon hyrjen e njëhershme të përdoruesve të shumfisht. Funksioni kryesor i këtij sistemi është të organizojë të dhënat në bartësat periferik dhe të vejë në dispozicion procedurat e kërkimit dhe të seleksionimit të këtyre të dhënave. Për të arritur në këto rezultate, përdoruesi përshkruan në termat abstrakte se çfarë dëshiron që ai të bëjë me këto të dhëna, duke i lënë në dorë sistemit të kryejë punën e kërkimit në funksion të paraqitjes dhe organizmit të të dhënave në suportet fizike.
15
3. Baza e të Dhënave. Baza e të dhënave është depozitimi fizik të të gjithë të dhënave të përdoruesve. Një bazë të dhënash është një bashkësi e strukturuar të dhënash të regjistruara në bartësa të kapshëm nga kompjuteri për të kënaqur njëkohësisht shumë përdoruese në mënyrë selektive dhe në kohë të favorshme. Një bazë të dhënash realizohet për të regjistruar fakte, ngjarje që takohen në jetën e një organizmi dhe për t’i kërkuar ata sipas nevojës ose për të nxjerrë konkluzione duke bashkuar fakte elementare.
16
Operacionet e bazave të të dhënave relacionale Algjebra relacionale përcakton rrugën teorike të manipulimit të përmbajtjeve të tabelave duke përdorur tetë operatorët relacional: SELECT, PROJECT, JOIN, INTERSECT, UNION, DIFFERENCE, PRODUCT dhe DEVIDE. Ilustrimi i këtyre operatorëve bëhet mjaft lehtë: Union (mbledhja) Ky operacion vepron mbi dy relacione të së njëjtës skemë. R1 dhe R2. Rezultati jep një relacion R3 që ka për n-është ata që bëjnë pjesë në R1 ose ata që bëjnë pjesë në R2 ose në të dy relacionet. Për të ilistruar operatorin UNION dhe të tjerët në vazhdim do të përdorimrelacionet: Furnizuesi Num_Furnizuesit F1 F2 F3 F4 F5
Emri Arben Luan Besnik Dritan Ermir
Pjesa Num_Pjesë Emri Pjesës P5 Vide P1 Dado P18 Bulon Me të dy relacionet. Shënimet e këtij operatori çfaqen në disa forma:
Qyteti Durrës Tiranë Tiranë Durrës Elbasan Furnizimi Num_Furnizuesi t F1 F2 F3 F4 F5
Num_Pjesës P1 P18 P5 P18 P18
R3 = R1UR2 R3 = UNION (R1, R2) R3 = APPEND (R1, R2) Me këtë rast përbërësit e R1 dhe R2 janë identike dhe rezultati R3 ka po ata atribute. 17
P.sh.: R1 Furnizimi Num_Furnizuesit Num_Pjesës F1 P1 F2 P18 F5 P18
R2 Furnizimi 2 Num_Furnizuesit Num_Pjesës F3 P5 F1 P1 F2 P18
R3 = Furnizues1 U Furnizues 2 Furnizimi Num_Furnizuesit Num_Pjesës F1 P1 F2 P18 F8 P18 F3 P5 F2 P18 Diferenca: Operacioni i diferencës vepron mbi dy relacione të së njëjtës skemë R1 dhe R2 që jep një relacion të tretë R3 që ka për n-është ata që janë me R1 dhe nuk janë në R2. P.sh.: Furnizues Num_F Emri F1 Arben F2 Luan F3 Besnik F1 Arben F2 Luan F3 Besnik
Seleksioni (Furnizues, Num_pjesës=P5) Num_Pjese P5 P5 P5 P1 P1 P1
Num_F F1 F2 F3
Emri Arben Luan Besnik
Num_Pjese P5 P5 P5
18
Bashkimi (Jointure) ose 0-Produkte Operacioni që duke u nisur nga dy relacionet R1 dhe R2 formon një relacion të tretë R3 që përmban bashkësinë e të gjith n-ëshave që merren duke bashkuar n-ësha nga R1 dhe n-ësha nga R2 që verifikojnë kandidatin. Shënime:
R3 = JOIN (R1, R2 kandita).
p.sh.: F1 Num_ F F1 F2 F3
F2 Emer Num_F Arben F1 Luan F1 Besnik F2
Num_Pjese P1 P18 P5
JOIN (F1, F2, F1. NUM-F =. NUM –F) Num-F F1 F1 F2
Emri Erban Arben Luan
Num-Pjese P1 P18 P5
Bashkimi pa kondit korespondon me prodhimin kortezian Prerja Operacioni që vepron mbi dy relacione të së njëjtës skemë (kanë të njëjtat atribute) dhe që formon një relacion R3 që ka si n-ëshe ata që janë së në R1 ashtu dhe në R2. Paraqitja: R3 = R1 R2 R3 = AND (R2, R2) R3 = INTERSECT (R1, R2)
p.sh. 19
Furni. 1 Num_F F1 F3 F4 Num_F F1 F2 F3
Emri Arben Besnik Fatmir Emri Arben Luan Besnik
Qyteti Durrës Tiranë Durrës
Furni.2
Qyteti Durrës Tiranë Tiranë
Num_F Emri
Qyteti
F1 F3
Durrës Tiranë
Arben Besnik
Antiprojeksioni: Jep ata n-ëshe që kanë vlera në të gjitha fushën e përcaktimit të atributëve që nuk marrin pjesë në anti projeksion. Paraqitja: R1 = R ]s[ s- atributi i antiprojeksionit R1 = Antiprojeksion (R, s).
p.sh. FURNIZIM Num_Furnizuesi Num_ Pjese F1 P1 F2 P18 F1 P5 F3 P5 F1 P18 F5 P18
R1 = FURNIZIM ] NUM_FURNIZUESI[ Fusha e përcaktimit NUM_PJES = (P1, P5, P18) R1 NUM_FURNIZUESI F1.
20
Pjestimi – jep njëshet që realizojnë rezultatet në vlerat e dhëna për n-ëshet e zgjedhura. Paraqitja: R1 = R ÷ S R1 = DIVIDE (R, S) p.sh. FURNIZIM Num_Furnizuesi Num_Pjese F1 P1 F2 P18 F1 P18 F5 P5
R1 = FURNIZIM
÷S
S Num_Pjese P1 P18
Num_Furnizuesi F1
Funksionet e llogaritjes Mundësia e përdorimit të lloharitjeve është futur duke përgjithësuar projeksionin, seleksionin dhe bashkimin duka përdorur funksione. Në këtë mënyrë atributi që gjendet me argumentin e një operacioni është zëvendësuar nga një shprehje e atributit. Kjo lejon t’i përgjigjeni pyetjeve të reja: p.sh.: Supozojmë se relacioni PJESE ( Num_pjese, Em_ Pjesë, Çmimi_Pa_TVSH), që precizon cili është çmimi pa TVSH i një pjesë. Për t’ju përgjigjur pyetjes “jepni listën e emrave të pjesëve për të cilat çmimi me TVSH është <1000” jepet me R1 = seleksion (PJESË, Emri_pa_TVSH 1.17<1000); jep n-ëshat Rezultati = Projeksion (R1, Em_Pjese). Jep listën e emrave Agregatet
21
Funsionet e llogaritjes lejojnë të bëhen llogaritje në rreshte, por shpesh lind nevoja e llogaritjeve në kolonë. p.sh. mund të llogaritet shuma e shpenzimeve. Kjo realozohet nëpërmjet konceptit të agrgatit . Një agregat është ndarja horizontale e një relacioni në funksion të vlerave të një grupi atributësh, e ndjekur nga një rigrupim nëpërmjet përdorimit të një funksioni të llogaritjes. Funksionet më të përdorshëm mbi funksionet janë: -
Shuma: shuma e elementeve të një bashkësie Mesatarja Minimumi Maksimumi Numërimi (count)
Forma: R = AGREGAT(Relacion, atribut1, Funksion, Atribut2) Ku: -
Atribut1: paraqet një ose disa atribute të përdorurpër ndarje. Funksion: është funksioni i llogaritjes mbi bashkësi i përdorur mbi Atribut2.
p.sh. : Duke u nisur nga relacioni FURNIZIM (Em_Furnizuesi; Num_P; Sasia) Mund të llogarisëm sasinë që siguron çdo furnizues si më poshtë: Rezultat = AGREGAT(FURNIZIM; Em_Furnizuesi, Sum (Sasia)) ose sasinë mesatare të lëvrimit Përcakton kufirin Rezultat = AGREGAT (FURNIZIM; ;AVERAGE (sasia)); Mesatarja totale
22
3. Jepen relacionet FLUTURIMET Numri. Flut. BA533 BA528 KG2544 KG2540 KG946 BR382 BA019 AEROPORTET Emër_Aeroporti Napoli Londër/ GK Londër/ GK Pisa Verona Venecia/ MP Mançester Kai - Tak 3. 4. 5. 6.
Origjina Napoli Londër A Verona Venecia/MP Venecia/MP Londër/GK Londër/HW
Destinacioni Lohndë GK Pisa Londër GK Londër GK Mançester Kai – Tak Kai – Tak NDALIMET
Emër vendi Itali Angli Angli Itali Itali Itali Angli Hong - Kong
Numri_ fluturimeve BR 382 BA 019 BA 019
Emër_ Aeroporti Dubai Dubai Shangai
Numri Ndalimit 1 1 2
Përgjigjuni pyetjeve në SQL: 1. Cilat aeroporte janë në Angli? 2. Cilat aeroporte mund të kapen nga Pisa? Cilat udhëtime kanë më shum se 2 ndalime? Në cilat vende ndalon BA 768? Cilat fluturime fillojnë nga një aeroport Anglez? Cilat fluturime fillojnë nga një aeroport Anglez dhe mbarojnë në një Italian?
4. Të jepet shija e verërave të gradës mbi 13 ose të prodhuara në vitin 1997. SELECT SHIJA FROM VERË WHERE GRADA >13 UNION SELECT SHIJA FROM VERË WHERE VITI_PRODH = 1997. 5. Të llogaritet grada mesatare e “Chablis”. SELECT AVG (GRADA) FROM VERE 23
WHERE SHIJA = “CHABLIS” 6. Të gjenden të gjitha kodet e verërave që janë pirë nga më shum se 100 vetë. SELECT NV FROM ABUZIV GROUP BY NV HAVINE COUNT (*)>100.
VERE (NV, Shija, Viti_Prodh, GRADA). PIJETAR (NP, EMRI ADRESA, SASIA). 1. Jepni listën e verërave që janë prodhuar më 1997 me Gradë më të madhe se 13. 2. Të jepet kodi i verës dhe shija për verërat e prodhuar më 1997 me shkallë mbi 13 në rendin alfabetik rritës të emrave të shijeve dhe zbritës të kodit. SELECT SHITE, NV FROM VERË WHERE VITI_PRODH: 1997 AND GRADA > 13 OP.DERED BY SHIJA, ASC, NV DESC. 3. Emrat e pijetarëve që kanë pirë Chablos. (3 mënyrë) I.
SELECT UNIQUE EMRI FROM PIJETAR, VERË, ABUZIV WHERE PIJETAR, NP = ABUZIV, NP AND ABUZIV, NV = VERË, NV. AND VERE, SHIJA. = “ Chablis”
II.
SELECT UNIQUE EMRI FROM PIJETAR WHERE NP IN (SELECT NB 24
FROM ABUZIV. NV = VERË. NV AND VERË. SHIJE = “CHABLIS”). III.
SELECT UNIQUE EMRI FROM PIJETAR WHERE. NP. IN (SELECT NP FROM ABUZIV WHERE NV. IN (SELECT NV FROM VERË WHERE SHIJA = “Chablis”).
4. Të jepet shija e verërave të gradës mbi 13 ose të prodhuara në vitin 1997. SELECT SHIJA FROM VERË WHERE GRADA > 13 UNION SELECT SHIJA FROM VERË WHERE VITI_PRODH = 1997. 5. Të llogaritetgrada mesatare e “Chablis”. SELECT AVG (GRADA). FROM VERË WHERE SHIJA = “Chablis”. 6. Të gjenden të gjithë kodet e verërave që janë pirë nga më shumë se 100 vetë. SELECT NV FROM ABUZIV GROUP BY NV HAVINE COUNT (*) > 100.
25
Modeli Relacional i Bazave të të Dhënave Njësitë dhe atributet: Konceptimi relacional fillon duke përcaktuar njësitë e kërkuara. Një njësi është një person, vend ose send rreth të cilit nemendojmë të grumbullojmë të dhëna. P.sh. në mjedisin universitar njësitë me interes mund të jenë stdentët, kurset, fakultetet etj. N.q.s. ju punoni në një shoqëri ajrore njësitë mund të jenë pilotët, avionët, linjat etj. Njësitë grupohen në përputhje me karakteristikat e përbashkëta. P.sh. Studentët janë vendosur së bashku për të formuar bashkësi njësish. Çdo bashkësi njësish ka një emër. Zakonisht emri reflekton përmbajtjen e saj. P.sh. studentët e U.T. mund të ruhen në bashkësinë e njësive me emrin STUDENT. Në shoqërinë ajrore mund të përdoret emri i bashkësisë së njësisë AVION. Çdo njësi ka disa karakteristika të njohura si atribute. P.sh. njësia STUDENT mund të përmbajë: kodin e studentit, emrin, notën mesatare, datën e regjistrimit, datën e lindjes, adresën e shtëpisë, numrin e telefonit. Në mënyrë të ngjashme shoqëria ajrore mund të përcaktojë atributet për njësinë AVION: kodi avionit, data e kontrollt të fundit, orët e fluturimit, orët e fluturimit nga mirëmbajtja e fundit. Çdo atribut emërtohet për të treguar përdorimin përmbajtjes së tij. P.sh. në njësinë STUDENT, datëlindja mund të shënohet STU_DL, ose numri i telefonit të shtëpisë STU_SHPI_PHONE.
Tabelat dhe karakteristikat e tyre Pamja logjike e bazave të të dhënave relacionale është lehtësuar nëpërmjet krijimit të lidhjes së të dhënave bazuar me strukturën e njohur si tabelë. Tabela është strukturë dy dimensionale e kompozuar nga rreshta dhe shtylla. Ndryshe kjo tabelë quhet relacion, emër i vendosur nga E.F.Codd. Një relacion është paraqitur nga një tabelë duke pasur: • Në emër të vetëm që identifikon atë • Një numrë fiks kolonash, • Një numër të çfarëdoshëm rreshtash.
26
p.sh. relacionet Furnizues, Pjesë, Furnizim. Atributet Furnizuesi Kod_furnizuesi F1 F2 F3 F4 F5
Emri Arben Luan Besnik Dritan Ermir
Qyteti Durrës Tiranë Tiranë Durrës Elbasan
n-ëshet Pjesa
Furnizimi Kod_Furnizuesi Kod_Pjesë Kodi_Pjesës Emri_Pjesës Sasia F1 P1 P5 Vidë 100 F2 P18 P1 Dado 50 F3 P5 P18 Bulon 150 F4 P18 Kolonat janë quajtur atribute. F5 P18 Çdo atribut: - Është përcaktuar nga një emrë. Ky emër duhet të jetë i vetëm brenda një relacioni, për të evituar konfuzionin, dy atributet të relacioneve të ndryshme mund të kenë të njejtin emër. - Rreshtat janë quajtur n-ëshe dhe janë të ndryshme në modelet relacionale. Radha e vendosjes së tyre nuk ka rëndësi. Sasia e n-ëshave në një relacion quhet kordinalitet. - Çdo prerje rresht/kolonë përmban një vlerë të vetme. Të dhënat mund të klasifikohen në përputhje me formatin dhe funksionin e tyre. a. Numerike: Numerike janë të dhënat mbi të cilat ju kryeni veprime arithmetike. P.sh. sasia është dhënë numerike. b. Character: Të dhënat karakter të njohur ndryshe si string mund të përmbajnë karaktere ose simbole që nuk pranojnë veprime arithmetike. P.sh. Emri, Qyteti. c. Date: atributet do të përmbajnë datat kalendarike. d. Logjike: mund të marrin vetëm vlerat true ose false. Çdo tabelë duhet të ketë një çelës primar. Në përgjithësi çelësi primar është një atribut (ose kombinim atributesh), që përcakton në mënyrë të vetme një njësi të dhënë (rresht). Në rastin e tabëlës Furnizuesi Kod_Furnizuesi është çelës primar i saj. Atributi Emri nuk është çelës primar sepse përcakton disa njësi. Çelësat 27
Çelësi përbëhet nga një ose disa atribute që përcaktojnë atributet e tjera. P.sh. Kodi i një fature përcakton të gjitha atributet e tjera. Kemi folur për çelësin primar në paragrafin e mëposhtëm. Për të vazhduar më tej konceptet do të marrim në konsideratë tabelën STUDENT të përcaktuar më poshtë: Student Stud_Kod
Stud_Emër
Stud_Mbiemër
Stud_Dl
DEPT_Kod
Stud_Phone
Prof_LOG
Roli i çelësit bazohet në konceptim e përcaktimit. Në konceptin e Bazave të të dhënave shprehja “A përcakton B” tregon se duke njohur vlerën e atributit B. Në tabelën STUDENT duke njohur Kod_Stud ju mund ta gjeni Emrin e studentit etj. Shprehja e dhënë më lart “A përcakton B” mund të përkthehet AB. N.q.s. A përcakton B, C dhe D, ju do të shkruani A B, C, D. Duke u nisur nga tabela STUDENT ne mund të shkruajmë: STUD_KODSTUD_EMËR Në fakt STU_KOD i përcakton të gjitha përbërësit e tjerë STUD_KODSTUD_EMËR, STUD_MBIEMËR, STUD_DL, DEPT_KOD, STUD_PHONE, PRFO_LOG. Në të kundërtën STUD_KOD nuk përcaktohet nga STUD_EMËR. Principi i përcaktimit është shumë i rëndësishëm, sepse ai është përdorur në përcaktimin e konceptit kryesor të Databazës, që është ai i varësive funksionale. Termi varësi funksionale mund të përcaktohet mjaft thjeshtë në këtë mënyrë: Në tabelën Student mund të themi se STUD_PHONE varet funksionalisht nga STUD_KOD. P.sh. studenti me kod 321452 përcakton STUD_PHONE 2134. Nga ana tjetër STUD_PHONE, sepse numri i telefonit 2267 i përket dy studentëve 324274 dhe 324291. Nga ana tjetër STUD_KOD me vlerën 324247 jepe numri e SMITH. Në rastin kur varësia nuk përcaktohet një me një, atëherë zgjerohet koncepti i çelsit duke arritur në çelsin e kompozuar. Një atribut që është pjesë e çelësit njihet si atribut i çelësit. Në relacionin STUDENT mund të shohim varësinë STUD_EMËR, STUD_MBIEMËR STUD_PHONE, STUD_DL (duke supozuar identike EMËR, MBIEMËR). Duke marë në konsideratë çelësin e kompozuar ne mund të flasim për varësi funksionale të plotë (varësi elementare).
28
Përkufizimi: N.q.s. atributi B është funksionalisht i varrur nga çelësi i kompozuar A, por jo nga një nënbashkësi A’ ⊂ A, atëherë themi se atributi B ka varësi të plotë funksionale nga A. Me zgjerimin e klasifikimit të çelësave mund të përcaktohen disa tipe çelësash. P. sh. Çelësi primar është ai që identifikon çdo njësi. Në relacionin student çelësi primar është STUD_KOD. Çelësi kandidat është çelësi primar pa llotollogji. P.sh. STUD_KOD, është vet çelës kandidat. Çelësi primar pasqyron atë që quhet integritet i njësisë. Për të mbajtur integritetin e njësisë vëmë në dukje se vlera “asgjë “ (që do të thotë nuk lejohen të mos regjistrohen vlera). Nuk është e lejuar në çelësin primar. Shënim: “Asgjë” nuk do të thotë zero ose space. “Asgjë” do të thotë të bësh Enter pa shtypur ndonjë tast paraprakisht “Asgjë” N.q.s. përdoret jo saktësisht mund të kryojë probleme meqenëse mund të kenë kuptime të ndryshme. P.sh. “Asgjë” mund të paraqesë: • • •
Një vlerë të panjohur, Vlerë që njihet, pa e humbur, Kanditë të “pa aplikueshme”.
Në varësi të sofistikimit të zhvillimit të aplikimit “asgjë” mund të kryojë problem kur përdorim funksione si COUNT, AVERAGE dhe SUM. Në përdorimin e kanditave “asgjë” mund të kryojë probleme logjike kur tabelat relacionale janë të lidhura. Tabelat në vazhdim PRODUKT dhe SHITËS ndajnë bashkë atributin KOD_SHITËS. PRODUKT KOD_PROD 001278-AB 12321UUV QER.34256 SRE. 657UG ZZX. 324Q SHITËS
PËRSHK_PROD ÇMIM_PROD SHEQER 65 VERË 250 VAJ VEJETALL 170 TAPETË 6500 800
KOD_SHITËSI
EMËR SHITËSI KODI_ZONËS_SHITËSIT PHON_SHITËS
230 231 232 233 234 235
Arben Mali Vera Shkëmbi Gent Deti Arjan Kodra Mira Pasha Gëzim Pylli
608 615 608 904 615 615
COD_SHITËSI 232 235 231 232 235 555_234 123_536 224_194 342_656 123_324 899_425 29
Çelësi primar në tabelën PRODUKT është KOD_PROD, ndërsa në tabelën SHITËSështë KOD_SHITËSI. Lidhja ndërmjet dy tabelave bphet me KOD_SHITËSI. Theksojmë se lidhja bëhet kur tabelat ndajnë një atribut. Më specifikisht çelësi primar i një relacioni paraqet ni çelës i jashtëm në relacionin tjetër. Çelësi i jashtëm është atribut, i cili bashkëshoqëron vlerat e çelësit primar në tabelën . Në shembullin që kemi marrë në konsideratë KOD_SHITËSI është çelësi i jashtëm në tabelën PRODUKT dhe çelësi primar në tabelën SHITËS. Së fundi është koncepti i çelësit sekondar, i cili është përcaktuar si element mjaft i rëndësishëm në marrjen e reultateve të pyetjeve. Çelësi sekondar përdoret për ndërtimin e Querive. Sistemet e bazave të të dhënave Problemet që çfaqen në sistemet e skedarëve i bëjnë bazat e të dhënave shumë tërheqëse. Ndryshe nga sistemet e skedarëve, databaza konsiston në të dhënat e lidhura logjikisht të ruajtura në të njëjtën hapsirë. Databaza paraqet ndryshim dhe nga fakti se si të dhënat janë ruajtur, hapur dhe administruar. Nga pikpamja skematike është e qartë diferenca ndërmjet sistemit të skedarëve dhe data_bazës. Sistemi i bazave të të dhënave Database Dept.Personelit Dept. Shitjes Dept. i financave
Punënjësit Klientët Shitjet Inventari Llogaria
DBMS
Sistemi i skedarëve Dept. Personelit
Punonjësit
Dept. Shitjes
Klientët
Shitjet
Dept. Financës
Inventari
Llogaria
30
Komplementet e mjedisit të bazave të të dhënave
Ndërfaqësi përdorues (sistem) Fjalori i të dhënave
SQBh
BDh
Administrimi i BDh
Dezinjimi dhe modelimi i bazës së të dhënave Dezinjimi i bazës së të dhënave përbën problemin bazë për të aritur fuqinë e dëshiruar në përdorimin e saj. Dezinjimi është më i thjeshtë kur përdorim modelet. Modelet janë abstraksion i ngjrjeve dhe kandidatave të botës reale. Ky abstraksion na jep mundësinë të zbulojmë karakteristikat e njësive dhe lidhjeve midis tyre. N.q.s. modeli nuk është i ndërtuar mirë logjikisht atëherë databaza e derivuar prej tyre nuk do të sjellë efektivitetin e premtuar. Si përfundim mund të themi se modeli i mirë sjell dezinjim të mirë, që janë bazat për një aplikim të mirë. Modelet e bazave të të dhënave mund të grupihen në dy kategori: modeli konceptual dhe modeli i implementimit. • Modeli konceprual fokusohet në natyrën logjike të paraqitjes së të dhënave. Modeli konceptual lidh me faktin se çfarë do të paraqesin në databazë. Modelet konceptuale përfshijnë modelin njësi shoqërinë (E-R) dhe modelin objekt oriental. • Modeli i implementimit merret me faktin se si janë paraqitur të dhënat në databazë ose se si është paraqitur struktura e të dhënave. Modeli i implementimit përfshin modelin hierarhik, modelin rrjetor, modelin relacional dhe modelin object-oriented.
31
Tipet e sistemeve të administrimit të të dhënave DBMS në të cilën është bazuar sistemi i bazave të të dhënave mund të klasifikohet në përputhje me numrin e përdoruesve, me vendin (vendet) e vendosjes dhe zgjerueshmëria e përdorimit + tipi i përdorimit. • Numri i përdoruesëve përcakton me se DBMS është klasifikuar. Single – user multi – user. DBMS single – oser sporton vetëm një përdorues në një çast të dhënë, • Në përputhje me site e vendosjes DBMS klasifikohen: - DBMS e çentralizuar - kur të dhënat vendosen në një site të vetëm. - DBMS e shpërndarë – kur të dhënat vendosen në disa site. • Lidhur me tipin e përdorimit dhe zgjerueshmërinë jepen klasifikimet si më poshtë. Dbase transaksionale, kur merren informacione të . Dbase: decision support database, që lidhen me prodhimin e informacioneve që përdoren për të marrë vendime taktike dhe strategjike. Në këtë rast përdoren të dhënat . Termi data warehous (negacione të dhënash) përdoret për të dhënat që përdoren në këtë stil pune. Aplication Model. Një Model Aplikacioni përbëhet nga shërbimet e mëposhtme: • Shërbimet e përdoruesit (User Services). Këto përbëjnë ndërfaqen e sistemit si p.sh. një GUI, një ndërfaqesh menush, apo një ndërfaqe command-line. • Shërbimet e biznesit (Bussines Services). Këto përbpjnë logjikën e aplikacionit ose siç thuhet ndryshe business rules që lidh shërbimet e përdoruesit me shërbimet e të dhënave. • Shërbimet e të dhënave (Data Service). Këto shërbime që zakonisht kryhen nga DBMS manipulojnë të dhënat dhe sigurojnë integritetin e tyre. Lejojnë përdoruesit të bëjnë insert, update, delete dhe të kërkojnë të dhëna pa u merakosur se ku ndodhen këto të dhëna, se si janë implementuar ato dhe se si aksesohen ato. Po ku është e mira e ndarjes së një aplikacioni sipas këtij modeli? Më poshtë po listoj një serë arsyesh:
32
•
Paralelizëm në ndërtimin software duke lejuar që antarët e grupit të ndërtimit të punojnë sëbashku në secilin nga grupet e shërbimeve. Kjo gjithashtu lejon antarët e grupit që të ndajnë punën në pjesë më të vogla dhe më të menexhueshme që bën rë mundur minimizimin e riskut. • Ripërdorim i softwer-it, pasi shërbimet e biznesit mund tp implementohen si komponente p.sh. COM dhe mund të përdoren përsëri në software të ndryshëm. Fleksibilitet të lartë në mbështetjen e shumë shërbimeve të përdoruesve siç janë aplikacionet tradicionale dhe aplikacionet e reja web based. • Qenja konsistent në grupe ndërtimi softwaresh pasi të gjithë grupet përdorin të njëjtin model zhvillimi aplikacioni. • Mundësi për tu përshtatur me teknologji të reja pasi të tre grupet e shërbimeve izolojnë njëra tjetrën e nga efektet e ndryshmimit të teknologjisë për një grup shërbimiapo një tjetër. Por cilat janë tipet e aplikacioneve që mbështesin këtë model? Single – tier, tow – tier, three – tier dhe n – tier janë tipet e aplikacioneve që mbështesin këtë model dhe paraqitin menyra për të implementuar fizikisht të tre grupet e shërbimeve. Single – tier. Aplikacionet Single – tier janë aplikacionet që përcaktojnë shërbimet e përdoruesit, biznesit dhe të të dhënave në një makinë të vetme. Shembuj aplikacionesh single – tier janë MS Word, Ms Excel, më poshtë është dhënë një paraqitje grafike e këtij tipi aplikacionesh.
33
Single Tier GUI Client, Peer ose server
Presentation Logic Busines Logic Data Acces Logic
Use srvice Business Services Data services
DBMS
Vihet re dhe që atje kemi vendosur disa terma të rinj si Presentation Logic, Business Logic, Data Access Logic të cilat përbëjnë thelbin e grupeve të shërbimit. Pra në këto tipe aplikacionesh kemi një centralizim të gjithë shërbimeve por le të kalojmë drejt decentralizimit. Client/Server, tow–tiers, three–tiers dhe n–tiers. Klient/Server është një nga teknikat dominante në ndërtimin e software-ve në IT dhe është zhvilluar ndërsa industria e kompjuterave kaloi nga sistemet më logjike të centralizuara drejt njëri rrjeti workstations dhe servers. Klient/Server konsitston në dhënjen e një arkitekture aplikacioni që bën të mundur që një proces i kompjuterizuar të ndahet në nënprocese më pak komplekse dhe një mekanizëm komunikimi për këto nënprocesse në mënyrë që ata të bashkëpunojnë me njëritjetrin. Qëllimi i ndarjes është që të arihet në një formë nivelesh e cila pastaj është më e lehtë për tu implementuar në disa makina në mënyra optimale. Këto nivele janë ashtu si e kam paraqitur dhe në figurën e mësipërme: • Presentation Logic (Logjika e prezantimit) që hynë në user services. • Business Logic (Logjika e biznesit) që hyn në Bussiness servicess. • Data access Logic (Logjika e aksesimit të të dhënave) që hyn në data Services. Ndërtimi i këtyre niveleve kërkon një modelim të kujdesshëm dhe përcaktim të saktë të kufijve midis tyre në mënyrë që të sigurohet që logjika e niveleve mos ndërfutet në njëra tjetra. Organizmi i logjikës në një mënyrë të tillë siguron që ndryshimet e mëvonshme në një nivel të kenë sa më pak ndikim në nivelet e tjera.
34
Pra mund të themi: Klient/Server është një teknologji që implementon një sistem në një organizatë në një mënyrë modulare dhe fleksibil, duke lejuar shpërndarjen e aplikimit ndërmjet shumë makinave që ndodhen në një enterprise. Ka disa arkitektura Klient/Server të cilat implementohen sot le të shohim me rradhë ato: Two – Tier klient/server N.q.s. në single tier ne kishim një aplikim të vetëm këtu kemin darjen e tij në komponentet që marrin emrin klient dhe server. Gjeneracioni i parë i Klient/Server është evulimi i një sistemi file-sharing i cili u zëvendësua nga një Relational Database Management System (RDBMS). Sisteme të tilla ofrojnë përqindje të larta transaksionesh dhe kur klienti kërkon të veprojë mbi këto të dhëna ai dërgon një kërkesë përmes një rrjeti në DBMS e cila më pas i kthen një përgjigje duke i ofruar të dhënat që kërkoi. Po ti krahasosh file sharing dhe klient/server, këto të fundit zvogëlojnë shum trafikun në rrjetpasi tashmë kthen vetëm të dhënat që do dhe jo gjithë skedari si në rastin file-sharing, gjithashtu DBMS të ofron mundësinë për krijimin e aplikimeve me shumë përdorues duke lejuar që të aksesohen dhe të ndryshohen të dhënat në mënyrë të sigurtë. Këtu aplikacioni ndahet në dy nivele që përfaqësohen nga workstation dhe server për këtë arsye këto lloj aplikacionesh quhen dhe two-tier klient/server. Two-tier klient/server ndahen në dy tipe. • Fat client/thin server • Thin client/fat server Fat client/thin server. Ky është tipi më i zakonshëm i implementimi të sistemeve tow-tier ku logjika e prezantimit dhe e biznesit vendosen np klient duke e bërë atë marë emrin fat client, ndërse data accee logic vendoset në server që merr emrin thin server. Kërkesat për të dhëna implementohen nga klienti nëpërmjet gjuhës SQL dhe kalojnë në DBMS nëpërmjet një protokolli transporti të dhënash ose duke përdorur mekanizmin e ODBC. Më poshtë po jap një paraqitje grafike të arkitekturës.
35
Tow-tier fat client/thin Server Client
Server
GUI Presentation Logic Business Logic
Data Access Logic DBMS
User Services Business Services
Data Services
Sisteme të tilla mund të implementohen lehtë duke përdorur RAD (rapi application development) tools siç janë MS Visual Studio, Sybase Power Builder dhe Borland Delphi. Këto sisteme janë të përshtatshme për mjedise workgroup. Por këto lloj sistemesh kanë disa probleme: • Vetë arkitektura imponon që klientët duhet të jenë makina shumë të mira për të përballuar ngarkesën që do të thotë që të kesh workstations me fuqi procesim të lartë, sasi të madhe memorje dhe hapësirë në disk. • Kërkesat në database mund të gjenerojnë rezultate të mëdha të cilat per tu transportuar më klient mund të shkaktojnë një trafik të tillë që të degradojnë rrjetit. • Çdo workstation që komunikon me server-in kërkon një lidhje të veçant që kërkon burimet e mëdha. P.sh. MS SQL Server kërkon 37K memorje për çdo përdorues që lidhet me të. • Ndodhja e logjikës së biznesit në klient çon në një kosto të lartë të shpërndarjes dhe mirëmbajtjes pasi për çdo ndryshim që mund të bëhet në logjikën e biznesit duhet që të merret dhe të çohet në çdo klient ndryshimi dhe kjo rrit koston. • Gjithashtu nga praktika dihet se performanca e sistemeve të tilla bihe në mënyrë eksponenciale kur rrjeti degradon pasi është arritur një numër përdoruesish që punojnë në të. Si përfundim mund të themi që kjo arkitekturë nuk na jep fleksibilitetin dhe performancë që nevojitet në një sistem të madh në enterprise ose Internet sic është Mercury.
36
Thin client/fat server. Kjo është një alternativë e arkitekturës së më sipërme në të cilën logjika e biznesit është zhvendosur në anën e server-it pra në database duke përdorur teknikat e DBMS si stored procedure, triggers dhe constraints. Më poshtë po jap paraqitjen grafike të kësaj arkitekture. Two-tier thin client/fat Server Client
Server
GUI Presentation Logic
User Services
Busines Logic Data Access Logic DBMS
Busines Services Data Services
Por dhe kjo arkitekturë nuk është adekuate për sisteme të mëdha pasi gjuha që përdoret për ndërtimin e stord procedure dhe triggers është shumë private p.sh. gjuha që përdoret MS SQL Server për implementimin e tyre T-SQL që ka ndryshime nga PL/SQL e ORACLE. Kështu që kemi më pak fleksibilitet dhe më pak mundësi për kalim nga një RDBMS në tjetrin. Gjithashtu si dhe në rastin e parë mundësi për të mbajtur një lidhje database-i për çdo workstation ka ndikim në server dhe e bën jo të pëlqyeshme këtë arkitekturë për implementime në enterprise apo Internet. Multi-tier klient/server Duke patur parasysh të metat e mësipërme në mund të risim performancën e aplikimit dhe të zvogëlojnë trafikun në rrjet duke kaluar në një arkitekturë me tre Threetier Client/Server tier ose siç quhet three-tier client/server. User Services Client Three-tier Kjo arkitekturë konsiston në shtimin e një shtrese midis një thin klient dhe një thin serveri duke krijuar një arkitekturë me tre shtresa pra three tier. Më poshtë po jap grafikisht formën e një arkitekture të tillë. Aplication Business Services Server GUI Database Presentation Logic Server Data Data Business Access Access DBMS Logic Logic logic
Data Services
37
Klienti komunikon me shtresën e mesit ose siç quhet middle tier duke përdorur protokollohet standardi si TCP/IP, NetBEUIetj, më pas kljo shtresë e mesit komunikon me shtresën e tretë pra RDBMS duke përdorur protokolle komunikimi me database ose mekanizmin e ODBC. Shtresa e mesit është përgjegjës për: •Implementimin e logjikës së biznesit dhe formimin e kërkesave ndaj database-it. •Përpunimin e përgjigjeve që vijnë nga database duke aplikuar përsëri logjike biznesi dhe gjenerimin e përgjigjeve ndaj klientit. Në këtë rast nuk kërkohet një lidhje e veçant për çdo përdorues pasi shum sesione përdoruesish mund të ndajnë një lidhje të caktuar duke bërë të mundur ruajtje të burimeve të server-it. Nëpërmjet kësaj arkitekture ne mund të implementojmë fizikisht të tre shtresat presentation logic, business logic dhe data access logic dhe që ka të miren që ne mund të ndryshojmë secilën nga tre shtrsat pa ndikuar shumë në shtresën tjetër. Shpesh është e mundur që bussiness logic dhe data access logic të qëndrojnë në të njëjtën makinë dhe kjo është një zgjidhje optimale. Në këtë rast kemi një shtresëzim logjik.
38
Kjo lloj arkitekture sot konsiderohet si e përshtatshme për aplikacionet në enterprise dhe Internet pasi janë më të menazhueshme, mund të mirëmbahen më lehtë dhe janë fleksibil duke ju përshtatur ndryshimeve të kërkesave të biznesit. Multi-tier Në këtë arkitekturë logjika e biznesit ndahet dhe shpërndahet në disa makina duke shfrytëzuar kështu procesimin e shpërndarë në paralel. Aplikacionet më të përshtatshme për këtë lloj arkitekture janë aplikacionet që shfrytëzojnë Internetin.
Lidhjet në Lidhjet janë klasifikuar si “një-një” (1:1), “një-shumë” dhe “shumë-shumë” (M:N). Tregon simboli 1:1 në këtë lidhje një njësi është e lidhur me një tjetër dhe anasjelltas. P.sh. një drejtor administron vetëm një shkallë dhe vetëm një shkallë është administruar vetëm nga një drejtor, që sjell lidhjen 1:1 ndërmjet tyre. Ekzistenca e lidhjes 1:1 shpesh nënkupton që komponentët nuk janë përcaktuar si duhet. Megjithatë ka raste kur 1:1 janë përcaktuar në mënyrë të përshtatshme. P.sh. supozojmë ju administroni bazën e të dhënave të një kompanie punëson pilot, llogaritare, mekanike personel shërbimi etj. Pilotët kanë disa atribute, që nuk i kanë punonjësit tjerë siç janë liçensa, raporti mjekësor, eksponenca e fluturimit, kontrollet periodike mjekësore. N.q.s. ju i vendosni të gjitha vetitë specifike të pilotit në tabelën PUNONJËS, ju do të keni shumë “asgjë”, për punonjësit që nuk janë pilotë. Për të eliminuar përdorimin e “asgjë” është mirë të ndahen atributet e pilotit në tabelën PILOT që është lidhur me PUNONJËS me lidhjen 1:1. (Sepse pilotët kanë disa atribute që janë njëlloj me punonjësit e tjerë siç janë emri, datëlindja, data e fillimit të punës etj.) Lidhja 1:m është ideale në sistemin relacional dhe përbën blloqet kryesore në sistemin relacional. Më poshtë do të tregojmë se si konvertohen lidhjet M:N në 1:M.
Në këtë rast jemi duke punuar me njësi 1:M. Ne mund të ekzminojmë këtë lidhje modelin entyti-relation ship. (E-R). Një model figura të thjeshta të 39
lidhjeve ndërmjet njësive që do të përdorni diagrame entyti relation ship ose ERD ndërtuar modelin ERD. Për të ilustruar ERD
Të dy modelet përdorin karakteristikat për të paraqitur emrat e njësive janë me forma të mëdha: PUNONJËS, DEPA, dhe përdoren me numër njëjës., • Lidhjet janë folje aktive ose pasive dhe shkruhen me P.sh. pikturon, punon për, prodhon
të vogla.
40
Duke u nisur nga shpnimet e mësipërme paraqitet në modelin E_R më poshtë
PIKTOR dhe PIKTURË do të
Modeli Crow’s Foot.
Modeli Chen
PIKTORI
PIKTORI
Pikturon
pikturon
PIKTURA
PIKTURA
Fig. Lidhjet ndërmjet PIKTOR dhe PIKTURA. Orientimi i ERD nuk është material. Lidhjet e mësipërme mund të paraqiten
PIKTORI
1 PIKTORI
pikturon
PIKTURA
pikturon
M PIKTURA
Fig. Paraqitja alternativë e modeleve.
Një paraqitje konkrete e lidhjeve të mësipërme.
41
PIKTORI KODI_PIKTORI
EMËR_PIKTORI
123
Luan
126
Besnik
Kodi_Pikturës
Titulli_Pikturës Kodi_Piktorit
1338 1339 1340 1341 1342
123 123 126 123 123
Në mënyrë të ngjashme me një universitet R.S. mund të ketë disa seksione, për çdo seksion i duhe një kursi. P.sh. kursi i Finance II mund të ketë seksione njeri të Hënë, Mërkurë, Premte (hmp) nga ora deri 11:00 dhe një tjetër Martë, Ejte, Shtunë (MES) nga ora 18:00 deri ora 19:00. Meqenëse çdo seksion është si KLASË, atëherë kemi lidhjen 1:M ndërmjet KURS dhe KLASË . Paraqitja e saj është: Modeli Crow’s Foot ka
KURS
KLASË
Modeli Chen KURS
1 ka
KLASË
M
Fig. Relacioni 1:M ndërmjet KURS dhe KLASE. Ky model mund të ilustrohet me tabela në formë të
:
Ermi i databazës: KURS_BOLEGJ Emri i tabelës: KURS. Çelësi primar: KURS_KOD Çelësi i jashtëm: s’ka KURS_KOD DEPT_KOD
KURS_PERSHK
KURS_KREDIT
42
ACCT_211 ACCT_212 CIS_220 CIS_420 QM_261 QM_362
ACCT ACCT CIS CIS CIS CIS
Accounting I Accounting II Hyrje në informatikë Database Design Hyrje në Statistikë Aplikime të Statistikës
3 3 3 4 3 4
Emri i tabelës: KURS. Çelësi primar: KURS_KOD Çelësi i jashtëm: KURS_KOD. Klase_Kod Kurs_Kod Klase_Seksion Klase_orë HMP 18012 ACCT_211 1 10013
ACCT_211
2
10014
ACCT_211
3
10015
ACCT_212
1
10016 10017
ACCT_212 CIS_220
2 1
10018
CIS_220
2
10019 10020
CIS_220 CIS_420
3 1
10021 10022
QM_261 QM_261
1 2
10023
QM_362
1
10024
QM_362
2
8-8:50am HMP 9-9:45AM ME 2:302:45pm HMP 1010:50am E 6-8:40pm
HMP 99:50am HMP 1010:50am M 6-8:40 pm HMP 88:50am ME 1-2:50pm HMP 1112:50pm ME 2:303:45pm HMP 1010:50 am
Klase_Sallë Prof_Num A-311 105 A-200
105
A-252
342
A-311
301
A-252 B-209
301 228
B-211
114
B-209 B-209
228 162
B-200 B-200
114 114
B-200
162
B-200
162
Fig. Baza e të dhënave KURS_KOLEGY Në tabelën KLASE përbërësi KLASE_KOD përcakton në mënyrë të vetme çdo rresht, duke qenë çelës primar. Megjithatë kombinimi KURS_KOD dhe KLASE_SEKSION përcaktojnë në mënyrë të vetme çdo rresht të tabelës dhe formojnë çelës kandidat. Lidhja 1:M implementohet lehtë në modelin relacional. Duhet të jemi të sigurtë që çelësi primar i një tabele është çelës i jashtëm në tabelën me shumë.
43
Në lidhjen M:N lindin probleme në modelin relacional, por problemi zgjidhet duke dekompozuar atë në disa relacione 1:M. Për të trajtuar problemin e shtruar le të ekzamonijmë mjedisin e kolegjit në të cilin çdo student mund të ndjekë disa KLASA dhe çdo klasë ka disa studentë. Figura në vazhdim tregon modelin ERD për këtë problem. Modeli Crow’s Foot STUDENT
ndjek
KLASË
Modeli Chen M STUDENT
KLASË
ndjek
N
Figura: Modeli M:N për lidhjen ndërmjet STUDENT dhe KLASË Vetitë e modelit ER sapotreguara janë: • Çdo KLASÇ ka shum STUDENT-ë dhe çdo student ndjek shum KLASA. • Ndryshe mund të themi se ka shum rreshta në tabelën KLASA për një rresht në tabelën STUDENT dhe ka shumë rreshta në tabelën STUDENT për një rresht në tabelën KLASA. Le të paraqesim shembullin e një kolegji me dy studentë: MBIEMRI KLASAT E ZGJEDHURA SHKËMBI
MALI
Accounting 1, ACCT-211, CODE Hyrje në Informatikë, CIS-220, 10018, Hyrje në Statistikë, QM-261, 1002. Accounting 1, ACCT-211, CODE Hyrje në Informatikë, CIS-220, 10018, Hyrje në Statistikë, QM-261, 1002.
10018, CODE CODE 10018, CODE CODE
Ky relacion mund të paraqitet në formë tabelare si në figurën në vazhdim. Emri i Databazës CH2-TEXT 44
Emri i tabelës STUDENT STUD_KOD MBIEMRI 321452 SHKËMBI 321452 SHKËMBI 321452 SHKËMBI 324257 MALI 324257 MALI 324257 MALI
KLASE_KOD 10014 10018 10021 10014 10018 10021
Emri i tabelës KLASË Klasë_kod Stud_kod
Kurs_kod Klase_seksion Klasë_orë Kasë_sallë Prof_kod
10014
321452
3
10014
324257
ACCT211 ACCT211
10018
321452
CIS-220
2
10018
324257
CIS-220
2
10021
321452
QM-261
1
10021
324257
QM-261
1
3
HM 2:303:45pm HM 2:303:45pm HEP 99:50am HEP 99:50am HEP 39:50am HEP 39:50am
B 201
342
B 201
342
A 112
114
A 112
114
C 305
114
C 305
114
Fatmirësisht Ne mund të shmangim problemet që lindin nga lidhja M:N duke krijuar njësi të kompozuara ose një urë. Meqenëse tabela e këtillë është përdorur për të lidhur tabelat që më parë përfaqësonin lidhjen M:N. Njësia e kompozuar përfshin si çelës të jashtëm të paktën çelës primar të tabelave që do të lidhen. Konceptuesi i Bazës së të dhënave ka dy opsione kryesore për të pëpërcaktuar çelësin primar të tabelës së kompozuar: - Bëjhmë kombinimin e dy çelësave të jashtëm, - Krijojnë një çelës të ri primar. Tabela REGJISTRIM lidh dy tabelat dhe quhet tabelë lidhëse. Kanë në dukje se tabelat STUDENT dhe KLASË kanë nga një rresht për njësi. Tabela REGJISTRIM ka shumëzimin të tyre. Në tabelën e lidhjes mund të vendson të dhëna sipas rastit për efekte raportimesh. Për të përcaktuar gradën e studentit në një lënd duhen dhe KLASE_KOD dhe STUDENT_KOD. 45
Lidhja e tabelave të mësipërme paraqitet në modelin e të dhënave në vazhdim. Modeli Crow’s Foot STUDENT
kryen
KLASË
Diagrama E-R e rreshtuar :2 relacionale 1:M STUDENT
REGJISTRIM
Gjendet në
bën pjesë në
KLASË
Modeli Chen STUDENT
1 STUDENT
KLASË
gjendet
M
N Regjistrmi
1
KLASË
në shembullin e mësipërm kemi ilustruar lidhjen ndërmjet STUDENT dhe KLSË. Figura mun të zgjerohet duke shtuar relacionin 1:M ndërmjet KURS dhe KLASË, dhe marrin figurën në vazhdim:
46
Modeli E-R Në mësimet e mëparëshme pamë lidhjet dhe paraqitjen e tyre në modelin ERD. Modeli ERD ka në bazën e tij tre komponentë: njësitë, atributet dhe lidhjet. Duke përmbledhur ata që thamë atributet paraqiten si më poshtë: Marim në konsideratë njësinë STUDENT që përmban atribute EMËR_STUD, MBIEMËR_STUD, STUD_INIT (iniciale), STUD_EMAIL, STUD_PHONE. Paraqitja e kësaj njësie në dy modelet do të jetë: Modeli Chen STUD_INIT MBIEMER_STUD
STUD_EMAIL
EMER_STUD
STUD_PHONE
Modeli Crow’s Foot STUDENT EMËR_STUD MBIEMËR_STUD STUD_INIT STUD_EMAIL STUD_PHONE Fig. Atributet e njësisë STUDENT në dy modelet.
47
Pjesëmarja në lidhje Një njësi që merr pjesë në lidhje mund të jetë opsionale ose e detyrueshme (mandatory). Pjesëmarja në relacion është opsimale n,q,s, ndodhja e njërës njësi nuk e ka të detyrueshme Ndodhjen e tjetrës. P.sh. në relacionin “kursi gjeneron klasë”. Në relacionin KURS mund të shtohen KURSE të reja pa patur nevojë që më parë të jetë krijuar relacioni KLASË. Kjo lidhje është realizuar duke vendosur një O në anën e njësisë opsioanle. Kordinaliteti minimum për njësitë opsionale është O. Pjesëmarja në relacion është e detyrueshme(mandatory) n.q.s. ndodhja e një njësie kërkon ndodhjen e njësisë koresponduese. Ekzistenca e lidhjes së detyrueshme tregon që kordinaliteti minimal është 1 për njësinë e detyrueshme. Pjesëmarja në relacion është mjaft e rëndësishme në proçesin e konceptimit të bazave të të dhënave. Supozojmë se në Universitet ku ka profesorë që japim mësim dhe profesorë që bëjnë kërkim. Le të marrim në konsideratë lidhjen “PROFESORI mëson KLASË”. Nga njëra anë KLASË mësohet nga PROFESORI, por duke patur PROFESORË që nuk mëson KLASË del që KLASË është opsimale lidhur me PROFESOR. Njësia PROFESOR është edetyrueshme me KLASË. Në modelin Crow’s Foot do kemi: Fortësia e lidhjeve: Për të kuptuar lidhjet është e domosdodhme të njihen njësitë që bëjnë pjesë në këto lidhje. Përpara se të shohim klasifikimin e lidhjeve duhet të shohim ekzistencën e varësive ndërmjet tyre. Ekzistenca e varur: (Varësi ekzistente) N.q.s. ekzistenca një njësi varet nga ekzistenca një njësi ose disa të tjera, quhet ekzistencialisht e varur. P.sh. n.q.s. në një kompani jepen kompesime për personat në varrësi të një tjetri, relacioni PUNONJËS dhe I/Të_VARUR shprehin këtë fakt. Në këtë rast njësia I/TË_VARUR është ekzistencialisht e varur nga PUNONJËS. (Njësia TË_VARUR ekziston në saje të PUNONJËS.) N.q.s. njësia nuk është e varur nga njësi të tjera atëherë themi se njësia është ekzistencialisht e pavarur. Lidhjet e dobëta: N.q.s. një njësi është ekzistencialisht e pavarur, lidhja ndërmjet tyre quhet lidhje e dobët ose lidhje e papërcaktuar. Nga pikpamja e databazave lidhja e 48
dobët ekziston n.q.s. PK (Primary Keg) e njësisë në fjalë nuk përmban komponentë të çelësit primar PK nga njësia prind . p.sh. KURS(KOD_KURS, KOD_DEPT, PËRSHK_KURS, KREDIT_KURS) KLASË(KOD_KLASË,KOD_KURS, SEKSION_KLASË, ORË_KLASË..) Në këtë rast lidhja e dobët ekziston ndërmjet KURS dhe KLASË, sepse KOD_KLASË është PK për njësinë KLASË, ndërsa KURS_KOD FK (pra çelësi primar i KLASË nuk përmban KOD_KURS në çelësin primar). Në figurën në vazhdim po japim paraqitjen e lidhjes së dobët në modelin Crow;s Foot, e cila paraqitet me vija të ndërprera, modeli Chen nuk bën dallim ndërmjet tyre. KURS KLASË KO_KURS KOD_KLASË gjeneron KOD_DEPT SEKSION_KLASË PËRSHK_KURS KURS_KOD (FK) KREDIT_KURS ORË KLASË Fig. Lidhja e dobët ndërmjet KURS dhe KLASË. Lidhjet e dobëta: Lidhje e fortë ndryshe e njoheu si lidhja përcaktuese ekziston kur njësitë e lidhura janë të varura ekzistencialisht. Nga pikpamja e databaze lidhja e fortë ndërmjet dy njësive çfaqet kur PK e njësisë së varur përmban Pk e njësisë prind si komponent p.sh. KURS (KURS_KOD, KOD_DEPT, PËRSHK_KURS,KREDIT_KURS) KLASË (KURS_KOD, SEKSION KLASË, ORË_LASË,......) Në relacionin KLASË, çelësi primar është formuar nga KURS_KOD+SEKSION_KLASË. Siç shihet KURS_KOD është PK në relacionin KURS. Paraqitja është si më poshtë. KURS KURS_KOD KOD_DEPT PËRSHK_KURS KREDIT_KURS PROFESOR
gjeneron shënim: më vonë.
O
KLASË SEKSION_KLASË KURS_KOD ORË_KLASË
O – do të shihet KLASË 49
Mëson
O
Fig. Një njësi opsionale në relacionin Profesori mësonKlasë Duhet vpnp np dukje se semantika e priblemit përcakton tipin e pjesëmarjes në relacion. P.sh. Universiteti ofron disa tipe kursesh dh çdo kurs ka disa klasa. Vemë në dukje diferencën ndërmjet kursit dhe klasës: një KLASË përbën një ofertë specifike (seksion) të KURS.(kurset paraqiten në katalogët e universitetit, ndërsa KLASA-t përcaktohen pas regjistrimit). Duke analizuar njësinë KLASË në “KURS gjeneron KLASË në “kurs gjeneron KLASË” është e lehtë të shihet që klasa nuk mund të ekzistojë pa kurs. Si rrjedhim konkludojmë se KURS është e detyrueshme në relacion. Por ne mund të paraqesim dy skenarë për njësinë KLASË që paraqiten në figurat në vazhdim. Skenarët janë pjesë e semantikës së problemit, dhe varen nga fakti nga fakti se si janë përcaktuar relacionet: 1. KLASË është opsional: Për departamentin është e mundur të krijojë njësinë KURS dhe pastaj të krjojë njësinë KLASË pasi të marrë masat e mësimdhënes. Në botën reale, ky skenar është i ngjashëm me faktin që mund të ketë kurse për të cilët akoma nuk është caktuar seksioni. KURS
KLASË gjeneron
O
Fig. KLASË është opsional me KURS. 2. KLASË është e detyrueshme: Kjo kanditë ishte krijuar nga kufizimet që rrjedhin nga semantika e shprehjes “Çdo kurs gjeneron një ose disa KLASË”. Në termet e E-R çdo KURS në “gjeneron” duhet të ketë një klasë.
50
KURS
KLASË gjeneron
O
Fig. KURS dhe KLASË në lidhjen e detyrueshme. Në fig. që sapo dhamë KURS nuk pranohet n.q.s. nuk i bashkëshoqërohet një saksion. Lidhjet e forta dhe njësitë e dobëta Kemi parë se lidhjet e forta kanë një efekt në vizatimin e njësive të lidhura. Në termat e databazës ekzistenca Ka e lidhjeve të forta ndërmjet njësisë prind dhe njësisë të lidhur me të i bashkëshoqërohet njësia e dobët. Meqenëse njësitë e dobëta mund të luajnë një rol të rëndësishëm në implementimin e databazës, le t’i shohim ata: Njësia e dobët quhet ajo që plotëson dy kondita: 1. Ajo është ekzistencialisht e varur, pra ajo nuk mund të ekzistojë pa njësinë me të cilën është e lidhur. 2. Ajo ka çelës primar është pjesërisht ose totalisht i derivuar nga njësia prind. p.sh. një kompani sigurimesh mundtë sigurojë punonjësin dhe personet e varur prej tij. Një PUNONJËS mund të ketë ose jo TË_VARUR, por TË_VARUR nuk mund të ekzistojnë pa PUNONJËS. Me fjalë tjera TË_VARUR është njësi e dobët në lidhjen “PUNONJËS ka TË_VARUR”. Paraqitja e tyre bëhet” Modeli Chen PUNONJËS
1
M TË_VARUR O (1,1)
(0,N) KOD_PUN EM:R_PUN MBIEMËR_PUN INIT_PUN DLIN)PUN
opsionale (min. 0)
(e detyrueshme min. 1)
KOD_PUN KOD_VAR EMËR_VAR DLIN_VAR
51
Crow’s Foot model PUNONJËS KOD_PUN EMËR_PUN MBIEMËR_PUN INIT_PUN DLIN_PUN
Ka
0
TË_VARUR KOD_PUN KOD_VAR EMËR_VAR DLIN_VAR
Njësia e dobët trashëgon një pjesë ose të gjithë pjesët e çelësit të saj primar nga kundrpjesa e fortë. P.sh. të paktën një pjesë e çelësit TË_VARUR do të trashëgohet nga njësia PUNONJËS: PUNONJËS(KOD_PUN, EMËR_PUN, MBIEMËR_PUN, INIT_PUN, DL_PUN) TË_VARUR( KOD_PUN, KOD_IVARUR, EMËR_IVARUR, DL_IVARUR). Shkalla e lidhjeve: Shkalla e lidhjeve tregon numrin r njësive të lidhura. Një lidhje unare ekziston kur bashkëshoqërimi realizohet me një njësi të vetme. Një lidhje binare ekziston kur dy njësi janë të lidhura. Një lidhje ternare kur janë bashkëshoqëruar tre njësi. Lidhje të tjera ndeshen radhe dhe nuk kanë emërtime speciale. Në vazhdim po japim shembul për secilin: Modeli Chen PUNONJËS
PROFESOR
mëson martuar
Unore
KLASË
Binare
Kontributor
KFM
MARRËSI
FOND
Ternare
Modeli Crow’s Foot 52
PUNONJËS
PROFESOR
KLASE
mëson
Unare
Binare
KONTRIBUTOR
KFM
Kontribon për
Marës
merr nga
I shpërndarë
Ternare
FOND
Siç shihet në modelin Crow’s Foot kërkohetkalimi i KFM nga lidhje në njësi. Modeli Chen e shpreh më qartë lidhjen ternare. Ne shembujt e dhënë në njësinë PUNONJËS mund të kemi martesa brenda punonjësve të ndërmarjes. Duhet theksuar se shumica e lidhjeve janë binare. Modelet ternare nuk janë shum praktik në realizim. Lidhjet
:
Shpesh herë lidhjet vendosen brenda të njëjtës bashkësi njësish. Lidhjet ndërmjet të njëjtës bashkësi njësish quhen . Lidhjet shprehen në tre format: një-një-, një-disa, disa-disa. Një ndërmarje ka një njësi PUNONJËS. Disa nga punonjësit janë martuar brënda ndërmarjes. Në këtë menyrë kenmi lidhjen martesa, e cila është 1:1. 1 PUNONJËS martesa 1 Lidhja një-disa: Le të shohim lidhjen administrim në skedarin punonjës.
53
1 PUNONJËS N
administrimi
Çdo punonjë ja 1 administrator, ndërsa një administrator ka disa punonjës. Meqenëse kemi një tip regjistrimi lidhja çfaqet si cikël. Le të marrim dy ndodhje të kësaj strukture: TOMI ANA
MARIJA
GENCI
TOMI
DITI
INA
FREDI
SUELA
MERI
GRIDI TOMI
TOMI
TOMI
TOMI
Lidhja disa-disa: Në disa organizma një punonjës mund të ketë më shum se një administrator, kjo quhetc e organizmit. Në këtë rast lidhja ndërmjet punënjësve është M:N. Shembull më tipik është ai i llogarisë së materialeve. M DETA 2 N
artikull
Në figurën në vazhdim, po japim dy ndodhje të kësaj strukture. A V
B
X U
Y V
X U
Y V
Z V
W
54
Varësitë funksionale Studimi i gjendjes ekzistuese (një proces informatizimi) dhe nevojat e reja na çojnë në përcaktimin e bashkësisë së të dhënave të domosdoshme për aplikimin, që lejon të ndërtohet ai që auhet fjalot i të dhënave elementare. Për të optimizuar sistemin e informacionit dhe më vonë trajtimet e tij duhet me regrupuar të dhënat në bashkësi koherente. Disa të dhëna janë të lidhura ndërmjet tyre. Më praktikisht duhet vënë në dukje që njohja e disa të dhënave sjell njohjen e disa të tjerave. P.sh. njohja e KNAC (kodit nacional) lejon njohjen e emrit dhe mbiemrit të personit. Trajtimi i këtyre problemeve na çon në studimin e varësive funksionale. Koncepti i varësisë funksionale. Përkufizimi: Le të jetë dhënë relacioni R(X,Y,Z) (ku X,Y, dhe Z janë bashkësi përbërësish, Z mund të jetë boshe). Do të themi që ekziston një varësi funksionale ndërmjet X dhe Y e skenuar X Y, atëherë dhe vatëm atëherë kur cilado qoftë vlera e ( X,Y,Z) dhe (X,Y’,Z’) kemi: Y=Y’ (njohja e vlerës së X sjell e shumta një vlerë të Y). p.sh. le të marrim relacionet: PERSONI (KP, EMRI, MBIEMRI) MAKINA (KM, MARKA, TIPI, FUQIA, NGJYRA) ZOTËRON (KP, KM, DATA, ÇMIMI) Tek relacionet makina kemi varësitë: KM NGJYRA TIPI MARKA TIPI FUQIA (TIPI, MARKA) FUQIA. Përndryshe varësitë e mëposhtme nuk ekzistojnë. FUQIA TIPI ; TIPI NGJYRA. n.q.s. pjesa e majtë përmban disa atribute atëherë flasim për varësi funksionale me pjesë të majtë të kompozuar. Veti të varësisë funksionale: Varësitë funksionale i përgjigjen shumë rregullave evidente: 1. Refleksioni
55
N.q.s. Y ⊆ X rrjedh që XY Një bashkësi përcakton vetveten ose një pjese të saj. 2. Shtimi: N.q.s. XY sjell XZYZ Pra të dy përbërësit mund të pasurohen me një të tretë. 3. Tranzitiviteti X Y dhe Y Z atëherë X Z. Tre rregullat e mësipërme formojnë aksionet e varësive funksionale. Nga aksionet e mësipërme dhe tre rregullat e mëposhtme: 4. Bashkimi i XY dhe XZ .. XYZ. 5. Pseudo_tranzitiviteti : X Y dhe WYZ..WXZ. 6. Dekompozimi : XY dhe Z ⊆ Y .. XZ. Rregulli që përdoret në ndërtimin e skemave relacionale. Varësitë funksionale elementare: Përkufizimi: varësia funksionale e formës XA, ku A është përbërësi vetëm, që nuk bën pjesë në X( A ⊄ X) dhe ku nuk ekziston X’ ⊂ X e tillë që X’A. I vetmi rregull i inferencës që zbatohet në varësitë funksionale elementare është traziviteti. Varësitë funksionale Direkte Një varësi funksionale AB është direkte n,q,s, nuk ekziston C, që të gjeneronte varësinë tranzitive ACB P.sh. Nr_Fature Nr_shitësit Nr_Shitësi Emër_shitësi Nr_Fature Emër_Shitësi
direkte direkte jo direkte
Varësia e tretë nuk është direkte. Kjo varësi është e paqartë dhe nuk përfshihet në analizën e problemit. Tentativat për gjetjen e varësive funksionale: Varësitë funksionale që i interesojnë konceptuesit janë ato elementare dhe direkte, të cilat po i shënojmë CFE. Tentativa për gjetjen e tyre (VFE) fillon nga fjalori i të dhënave: • Kërkohen VFE me dy rubrika elementare dhe direkte. 56
• Kërkohen VF me anë t majtë të kompozuar elementare dhe direkte. Paraqitja grafike e VF. Më parë se ta paraqesim varësitë funksionale të gjetura gjatë studimit të fjalorit të të dhënave, përdoret një formalizues në formën e grafit të varësive funksiona. VF me dy rubrika paraqiten me një shigjetë që shkon nga Burimi Destinacioni. p.sh.
KM Ngjyra
Tipi
Marka
Fuqia
Paraqitja e VF me anë të majtë bëhet: Nr_Fature
Ref_artikullit
Sasia_faturizuar Konkluzion: Njohja e varësive funksionale ndërmjet të dhënave është një menyrë për të analizuar modelimin dhe të arrihet që ai të jetë korekt. Kjo është një fazë e rëndësishme me analizën e problemit. Format normale Hapat e normalizimit Në figurën 7.1 janë treguar hapat bazë në proçesin e normalizimit. Së pari janë përcaktuar pamjet e përdoruesve. Pas kësaj çdo pamje e përdoruesit është konvertuar në një relacion të panormalizuar. Pasi hiqen grupet përsëritës duke e shkruar disa herë përbërësin nga relacioni i panormalizuar, atëherë relacioni është në formën e parë normale (1NF).
57
Pamjet e përdoruesve Relacionet e panormalizuara
Kanë grupe të përsëritin
Rel. Normaliz.1
Hiqen grupet e përsëritur
Hiqen varësitë e pjesëshme
Rel. Normaliz.2 Hiqen varësitë tranzitive
Rel. Normaliz.3
Fig. 7.1 Hapat e normalizimit Pas kësaj varësitë e pjesëshme dhe relacionet kalojnë në 2NF. Në fund hiqen varësitë tranzitive dhe relacionet kalojnë në 3NF. Procesi i normalizimit është i lidhur ngushtë me përkufizimet e varësive funksionale dhe realizohet nëpërmjet procesit të dekompozimit të vazhdueshëm. Relacionet e panormalizuara. Le të marrim në konsideratë relacionin STUDENT në formë të shtrirë si më poshtë: Disa vlera në prerjene e rreshtit me kolona STUDENT#
EMER_ STUD
42125
ARBEN
DREJTIMI _ KRYESOR IS
68134
LUAN
PM
KURSI#
TITULLI_ KURSIT
IS350 IS465
DATABASE SYSANAL
EMRI_ INSTRU_ KTORIT CODT KEMP
IS465 PM300 QM440
SYSANAL BIZNES KERKOP
KEMP LEVIS KEMP
VENDI_ ENSTRU_ KTORIT B104 B213 B213 B317 213
GRADA A C A B C
Fig. 7.2 Shembull relacioni të panormalizuar
58
Si rezultat në këtë relacion ka clera të shumëfishta në prerjen edisa kollonave me rreshtat. P.sh. përbërësi kuri merr vlera të shumëfishta meqenëse një student ndjek disa kurse. Një relacion të panormalizuar një përbërës i vetëm nuk mund të shërbejë si çelës primar. Po të marim në relacionin STUDENT përbërësin STUDENT # si çelës primar atëherë lidhjet ndërmjet përbërësve do të paraqiten si më poshtë duke përdorur metodën e skemave flluskore. M:N
M:N
1:1 EMËR_ STUDENTI
STUDENT
DREJTIMI KRYESOR
KURSI#
GRADA
Siç shihet nga figura lidhja ndërmjet STUDENT# dhe EMER_STUDENT si dhe DREJTIMI_KRYESOR është një-nga-një dhe është një-disa duke filluar nga përbërësi KURSI#. Pra STUDENT# nuk përcakton në mënyrë unike të gjithë përbërësit. E meta kryesore e relacioneve të panormalizuara është se ata përmbajnë teprime. Në relacionin STUDENT p.sh. informacionet lidhur me kursin IS465 paraqiten në disa vende. Supozojmë se ne duam të ndryshojmë emërin e këtij lursi nga SYSANAL në SYSANAL&DES. Për të bërë këtë ndryshim ne duhet të kërkojmë në të gjithë relacionin STUDENT për të lokalizuar të gjitha ndodhjet e KURSI# IS465. Një paraqitje e shkurtër e relacionit të panormalizuar është paraqitur në figurën në vazhdim:
STUDENT#
EMER_ STUDENTI
DREJTIMI_ KRYESOR
KURSI#
. . . . . . .
GRADA
STUDENT STUDENT# 3821 69173 . . .
EMER_ STUDENT ARBEN LUAN
DREJTIMI KRYESOR IS PM
STUDENT-KURS 59
STUDENT#
KURSI#
38214 38214 69173 69173 69173 . . . .
IS350 IS465 SI465 PM300 QM400
TITULLI_ KURSIT DATABASE SYSANAL SYSANAL PRODMGT OPRES
EMRI_ INSTRUKTORIT CODD KEMP KEMP LEVIS KEMP
VENDI_ INSTUKT. B104 B213 B213 D317 B213
GRADA A C A B C
Fig. 7.3 Normalizimi i relacioneve duke hequr grupet e përsëritur Normalizimi i relacioneve Forma e Parë Normale Relacioni i normalizuar është relacioni që përmban vetëm vlera elementare në prerjen e çdo kollone me çdo shtyllë. Kështu një relacion i normalizuar nuk përmban grupe të përsësitura. Për të normalizuar relacionin që përmban vetëm një grup të përsëriturlëvizim grupu\in e përsëritur dhe formojmë dy relacione të reja. Kjo procedurë është ilustruar me relacionin STUDENT në fig. 7.3. Dy relacionet e formuara janë: 1.
2.
STUDENT, që përmban ato atribute që janë në grupin përsëritës: STUDENT#_EMËR_STUDENTI dhe DREJTIMI_KRYESOR. Çelësi primar për këtë relacion është STUDENT#. Ky relacion është 3NF siç do të shohim. Relacioni STUDENT_KURS, që përmban ato atribute që janë në grupin përsëritës. Çelësi primar i këtij relacioni është i përbërë nga STUDENT# dhe KURS#.
Relacioni STUDENT_KURS në fig. 7.3 është në formën e parë normale (1NF). Një relacion është në formën e parë normale nëqoftëse nuk përmban grupe të përsëritur. Megjithëse relacioni është në formën e parë normale, ai nuk është akoma një paraqitje ideale e këtyre të dhënave. E keqja e kërij relacioni është se ka teprime. Nëqoftëse në i lejmë të dhënat në këtë formë do të ndeshim anomali nëproçesin e futjes, fshirjes dhe modifikimit të të dhënave. Anomalia e futjes: Supozojmë se duak të fusim të dhëna për një kurs të ri KURS# dhe TITULL_KURSI. P.sh. ne duam të fusim BA200 dhe INTROINFO. Ne nuk mundet t’i regjistrojmë këto të dhëna pa patur të paktën një student të regjistruar në këtë kurs.
60
Anomalia e fshirjes: Supozojmë se vetëm një student është regjistruar në një kurs. Në qoftë se studenti e le kursin (ose shkollën) ne duhet të heqim n-ëshen nga baza e të dhënave. Kjo do të sjellë humbjen e informacionit për titullin e lëndës dhe instruktorin. Anomalia e modifikimit: Supozojmë se duam të ndryshojmë titullin e kursit IS465 nga SYSANAL në SYSANAL&DES. Meqenëse titulli i këtij kursi çfaqet disa herë në STUDENT_KURS përdoruesi duhet të kërkojë në të gjitha n-ëshet e relacionit dhe çdo herë të modifikojmë titullin e kursit. Kjo proçedurë mund të jetë e pamjaftueshme dhe mund të rezultojë në paqëndrueshmëri nëqoftëse nuk janë korigjuar të gjitha n=ëshet. Arsyeja e këtyre anomalive në STUDENT_KURS është se disa atribute jo çelës në këtë relacion varen vetëm nga KURSI# si në fig. 4=7. Varësi të pjesëshme TITULLI KURSIT
STUDENTI GRADA
EMRI INSTRUKTORIT
KURSI#
VENDI INSTRUKTORIT
Fig. 7.4. Varësia e atributeve jo çelës me çelësin primar të përbërë Vemë në dukje se vetëm atributi GRADA varet nga të dy STUDENT# dhe KURSI#, kjo për arsye se për të njohur një gradë ne duhet të njohim edhe STUDENT# dhe KURSI#. Një atribut që varet nga i gjithë çelësi i përbërë quhet plotësisht i varur nga ky çelës. Atributet e tjera jo çelës (TITULLI_KURSIT, EMRI_INSTRUKTORIT, VENDI_INSTRUKTORIT) janp tp varur vetëm në KURSI Këto atribute pjesërisht të varur nga çelësi primar. Forma e Dytë Normale Një relacion është në formën e dytë normale në qoftë se ai është në formën e parë normale dhe varësitë funksionale të pjesëshme janë eleminuar. Për të transformuar relacionin me varësi funksionale të pjesëshm në formën e dytë normale ne krijojmë dy relacione të reja: njerin me atributet që janë plotësisht të varur STUDENT#, KURS# nga çelësi primar dhe tjetrin me atributet që janë të varur KURS# nga një pjesëe çelësit. Ky proces është ilustruar në fig. 7.5. 61
STUDENT_KURS STUDENT#
KURSI#
TITULLI_ KURSI
EMËR_ INSTRUKTORI
VEND_ INSTRUKTORI
GRADA
REGJISTRIMI STUDENT 38214 38214 69173 69173 69173 . . . .
KURSI# IS350 IS465 IS465 PM300 QM440
GRADA A C A B C
KURSI_INSTRUKTOR 3NF
KURSI# IS350 IS465 PM300 QM440
TITULLI_ KRYESOR DBASE SYSANAL PRODMGT OPRES
EMRI_ INSTR. COOD KEMë LEWIS KEMP
VENDI_ INSTR. B104 B213 D317 B213
2NF Fig. 7.5. Kthimi i relacionit në 2NF 1. Relacioni REGJISTRIMI me çelsin e kompozuar STUDENT# dhe KURSI#. Atributi jo çelës GRADA është i varur plotësisht në çelësin primar. Ky relacion është në formën e tretë normale. 2. Relacioni KURS_INSTRUKTOR në çelësin primar KURSI#. Atributet jo çelës (TITULLI_KURSIT, EMËRI_INSTRUKTORIT dhe VENDI_INSTRUKTORIT) janë të varur vetëm në KURSI#. Anomalitë e përshkruara për 1NF janë eleminuar në relacionet e reja. Vemë në dukje se çdo kurs është përshkruar vetëm një herë në relacionin KURS_INSTRUKTOR. Si rezultat ndonjë modifikim në të dhënat e kursit (p.sh. ndryshimi i titullit) është reduktuar në një n-ëshe të vetme. Nga ana tjetër meqenëse të dhënat e kursit janë të ndara nga ana tjetër nga të dhënat e studentit, një kurs i ri mund të shtohet ose një i vjetër të hiqet pa iu referuar të dhënave të studentit. Në skemën e paraiqtur relacionin KURS_INSTRUKTOR mund të bëjmë skemën e mëposhtme:
KURS#
TITULLI_ KURSI
EMËR_ NSTRUKTORI
VENDI_ INSTRUKTORI
Vemë në dukje se çdo atrribut jo çelës varet nga KURS#. Megjithatë VINDIINSTRUKTORIT varet nga EMRIINSTRUKTORIT. 62
Ky është një shembull i varësisë tranzitive. Varësia tranzitive ndodh atëherë kur një atribut jo çelës ( si VENDI INSTRUKTORIT) është i varur nga një ose më shum atribute jo çelës ( si EMRI INSTRUKTORIT). Varësia tranzitive e thjeshtë paraqitet si më poshtë:
Çelës primar
A
B
Në këtë rast kemi varësi tranzitive ndërmjet çelësit primar dhe atributeve A dhe B. Varësitë tranzitive japin efektin e tyre në futjen, fshirjen dhe modifikimin duke shkaktuar anomali. Anomalia e futjes. Supozojmë se duam të fusim të dhëna për një instruktor të ri në relacionin KURS_INSTRUKTOR. Meqenëse të dhënat e instruktorit varen nga KURS#, ne nuk mund të fusim të dhëna për instruktorin gjersa ai të jetë caktuar për të zhvilluar një kurs. Anomali e fshirjes: Fshirja e të dhënave për një kurs mund të çojë në humbjen e të dhënave të instruktorit. Anomali e modifikimit: Të dhënat e instruktorit çfaqen disa herë në relacionin KURS_INSTRUKTOR. (p.sh. instruktori KEMP është dy herë) si rezultat ndonjë ndrishim në të dhënat e instruktorit bën që të kërkohet në të gjithë relacionin. Eliminimi i këtyre anomalive bëhet duke kaluar relacionin në formën e tretë normale. Forma e tretë Normale Relacioni është në formën e tretë normale (3NF) në qoftë se ai është në formën e dytë normale dhe nuk përmban varësi tranzitive. Relacioni në formën e tretë normale ka formën e mëposhtme:
Çelësi primar
Atributi 1
Atributi 2
........
Atributi n
Kjo do të thotë se çdo atribut / përbërës jo çelës është plotësisht i varur nga çelësi primar dhe nuk kemi varësi tranzitive. Proçesi i heqjes së varësive tranzitive është trguar në fig. 7.6. Stributi /përbërësi jo çelës që merr pjesë në varësinë tranzitive (EMËR_INSTRUKTORI dhe VENDI_INSTRUKTORI) janë hequr duke formuar relacionin e ri INSTRUKTOR. Çelësi primar i tij është EMRI_INSTRUKTORIT, meqenëse ky atribut përcakton vendin e instruktorit. KURS_INSTRUKTORI KURSI#
TITULLI_ KRYESOR
EMËR_ VEND_ INSTRUKTORI INSTRUKTORI
63
KURS KURSI# IS350 IS465 PM300 QM440
INSTRUKTORI TITULLI_ KURSI DBASE SYSANAL PRODMGT OPRES
EMËR_ INSTRUKTORI COD KEMP LEVIS KEMP
EMËR_ INSTRUKTORI COOD KEMP LEVIS
VEND_ INSTRUKTORI B104 B213 B317
3NF 3NF Fig. 7.6. Kthimi në 3NF Analisti i bazës së të dhënave merret me këtë proçes duke parë vlefshmërinë e tij. Meqenëse përbërësi EMRIËINSTRUKTORIT bëhet çelës primar në relacionin e ri KURS. Në këtë rast themi se EMRI_INSTRUKTORIT është çelësi jashtëm në relacionin KURS. Tani proçesi i normalizimit është kompletuar. Aplikimi ynë me anë të transformimeve të thjeshta është kthyer në 4 relacione të 3NF. Relacionet janë përmbledhur në fig.7.7. STUDENT STUDENT# 38214 69173
INSTRUKTOR
EMËR_ DREJTIMI_ EMRI_ STUDENTI INSTRUKTORIT KRYESOR ARBEN IS CODD LUAN PM KEMP LEVIS . . . .
KURS KURS# IS350 IS465 PM300 QM440 . . . . .
TITULLI_ KURSIT DBASE SYSANAL PRODMGT OPRES
EMRI_ INSTRUKTORIT CODD KEMP LEWIS KEMP
VENDI_ INSTRUKTORIT B104 B213 D217
REGJISTRIMI Fig. 7.2. Relacionet në formën normale Forma Normale Boyce Codd (BNCF) STUDENT# 38214 38214 69173 69173 69173 . . . . .
KURSI# IS350 IS465 IS465 PM300 QM440
GRADA A C A B C
64
b) c)
Relacionet në formën e tretë normale janë të mjaftueshme për shumë probleme praktike në bazat e të dhënave. Megjithatë 3NF nuk garanton eliminimin e gjithë anomalive. Kërkimet e mëtejshme kanë identifikuar hapa shtesë në proçesin e normalizimit pët të eleminuat ndonjë anomali që ka mbetur. Kur një relacion ka më shumë e një çelës kandidat (pra çelësa të muëshëm për të qenë primar nga të cilët zgjidhet vetëm njëri), mund të ndodhin anomali megjithëse relacionet janë në 3NF. Le të marrim në konsideratë relacionin ST_DR_UDH që tregohet nç fig. 7.8. Çelës primar i këtij relacioni është i përbërë nga (STUDENT#, DREJTIM). Rregullat sintaktike për relacionin janë: 1. Çdo student mund të mbrojë në disa drejtime. 2. Për çdo drejtim një student ka një udhëheqës (kjo konditë është e vërtetë n.q.s. STUDENT + DREJTIM është çelës primar).. 3. Çdo drejtim ka disa udhëheqësa. 4. Çdo udhëheqës ka vetëm një drejtim. Diagrama e varësisë që përnbledh këto rregulla është treguar në fig. 7.8.b. ST_DR_UDH STUDENT#
DREJTIMI
UDHËHEQËSI
234
FIZIKË
AJNSHTAJN
234
MUZIKË
MOXART
546
BIOLOGJI
DARVIN
879
FIZIKË
BORI
985
FIZIKË
AJNSHTAJN
STUDENT# UDHËHEQËS DREJTIMI
(a)
(b)
ST_UDH STUDENT# UDHËHEQËSI UDHËHEQËSI 234 AJNSHTAJN DREJTIMI AJNSHTAJN 234 MOXART FIZIKË MOXART DARVIN MUZIKË 546 DARVIN BORI BIOLOGJI 879 BORI 989 AJNSHTAJN FIZIKË
UDH_DR
(c) Fig 7.8 Forma BCNF (a) relacioni në 3NF diagrama e varësisë relacionet në BNCF Është e qartë se relacioni është 3NF meqenëse nuk ka varësi funksionaletë pjesëshme dhe tranzitive. Megjithëatë ka akoma anomali në relacionin e ndërtuar.
65
P.sh. supozojmë e studenti #546 ndryshon drejtimin nga BIOlLOGJI në MATEMATIKË. Kur n-ëshja e këtij studenti do të modifikohet do të humbasim faktin që DARVIN udhëheq BIOLLOGJINË. Përndryshe në qoftë se të fusim një n-ëshe me informacionin që WATSON udhëheq INFORMATIKË, kjo nuk mund të bëhet gjersa një student të regjistrohet në këtë drejtim. Në relacionin ST_DR_UDH janë dy çelësa kandidatë (STUDENT#, DREJTIM) dhe (STUDENT#, UDHËHEQËS). Ne kemi zgjedhur të parin si çelës primar. Vemë në dukje se dy çelësat kandidatë priten, meqenëse kanë të përbashkët STUDENT#. Anomalia ndodh kur kemi mbulime të çelësave kandidatë. Kjo është situatë e rallë, por mund të ndodhë. R.F. Boyce dhe E.F. Codd e konstaton këtë mangësi dhe propozuan një përcaktim më të fortë të 3NF. Përcaktimi i tyre lidhet me konceptin e determinantit. Determinanti është një atribut/përbërës (i thjeshtë ose i përbërë) me të cilin etributet e tjera janë plotësisht të varur funksionalisht. P.sh. në relacionin ST_DR_UDH atributi UDHËHEQËS Është determinant, meqenëse atributi DREJTIMI është plotësisht i varur nga UDHËHEQËS (fig. 7.8.b.). Themi se relacioni është në BNCF atëherë dhe vetëm atëherë kur determinanti është çelës kandidat. Duke përdorur rregullin e Boyce-Codd ne shohim se ST_DR_UDH nuk është në formën BNCF (është në 3NF), sepse UDHËHEQËSI është determinant, por ai nuk është çelës kandidat (një udhëheqës mund të ketë disa studentë). Për të zgjidhur problemin kalojmë relacionin nga 3NF në BNCF. Rezultati i një projeksioni të tillë është treguar në fi. 7.8.c. Varësitë funksionale shumëvlerëshe Deri tani kemi futur konceptin e varësisë funksionale që ka çuar në dekompozimin e relacioneve në formën e tretë normale dhe në formën normale të BYOCE-CODD. Kjo është e pamjaftueshme për të eleminuar teprimet dhe anomalitë e modifikimit. Le të marrim relacionin: STUDENT(NS, KURSI, SPORTI) Një zgjerim i këtij relacioni paraqitet më poshtë: STUDENT NS 10 0 10 0 20 0 20 0
KURSI Baza të dhënash
sporti Tenis
Baza të dhënash
Futboll
Baza të dhënash
Çiklizëm
Matematikë
çiklizëm
Në këtë relacion: 66
NS – kodi i studentit KURSI – kurset e ndjekura SPORTI – janë sportet praktike. Teprimet në këtë relacion duken qartë dhe megjithatë nga fakti I mungesës së varësisë funksionale (duket qartë që nuk ka varësi funksionale). Ky relacion deri tani është i padekompozueshëm. Shembulli i mësipërm tregon pamjaftueshmërinë e konceptit të varësisë funksionale, që nuk lejon të kapet pavarësia që ekziston ndërmjet kurseve të ndjekura dhe sporteve praktike. Për këtë përgjithësohet koncepti i varësive funksionale duke futur atë të varësisë shumëvlerëshe (VSH). Përkufizim: Le të jetë R(A1, A2, . . . ., AN) një skemë e relacionit dhe X e Y nënbashkësi të A1, A2, . . . . AN. Do themi se X Y (varësi shumëvlerëshe e Y nga X) n.q.s. duke qenë dhënë vlera e X ka një bashkësi vlerash të të bashkëshoqëruara dhe kjo bashkësi është e pavarur nga përbërësit e tjerë të relacionit R. Varësitë shumëvlerëshe karakterizohen nga një pavarësi atributesh Y dhe Z të nga një bashkësi e tretë X. Formalisht kemi: ( X Y) ⇒ {(X,Y,Z) dhe (X, Y’, Z’) ∈ R ⇒ (X,Y’,Z) dhe (X,Y,Z’,) ∈ R} ku X,Y,Z,Y’,Z’, paraqesin vlerat e X,Y,Z. Shembull: Tek relacioni STUDENT X ⇒ NS Y ⇒ KURSI Z ⇒ SPORTI X Y Z (100, Baza të Dhënash, Tenis) X Y’ Z (100, Baza të dhënash, Tenis)
X Y Z (200, Baza të Dhënash, Çiklizëm)
X= 100 Y = Baza të Dhënash Z = Tenis Y’ = Baza të dhënash Z’ = Futboll X Y’ Z’ (100, Baza të dhënash, Futboll) X Y Z’ (100, Baza të dhënash, Futboll)
X Y’ Z’ (200, Matematikë, Çiklizëm) 67
X Y’ Z (200, Matematikë, Çiklizëm)
X Y Z’ (200, Baza të dhënash, Çiklizëm)
Është për të vënë në dukje se VF janë rast i veçantë i VSH. Në fakt: (X) ⇒ {(X,Y,Z) dhe (X,Y’,Z’) ∈ R (X,Y’,Z) dhe (X,Y,Z’) ∈ R}. nga fakti se Y = Y’. Pra ( XY) (XY). Aksionet e Vsh janë: 1. Komplementi : (X→→Y) ⇒ (X→→R-X-Y) 2. Tranzitiviteti: (X→→Y) dhe (Y→→Z) ⇒ (X→→Z) 3. Bashkimi : (X→→Y) dhe (X→→Z) ⇒ (X→→YZ). Duke nisur nga aksionet e mësipërme është e mundur të futet koncepti i varësisë shumëvlerëshe elementare. Përkufizim: Varësia shumëvlerëshe X→→Y elementare n.q.s.:
e një relacioni R është
1. Y nuk është bosh dhe nuk pritet me X 2. R nuk përmban një tjetër V.SH të tipit X’Y’ ku X’CX dhe Y’cy. p.sh. le të jetç relacioni: FLUTURIM(NF, AVION, PILOT) NF – numri i fluturimit. Këtu supozohet se ekziston një bashkësi avionesh dhe një bashkësi pilotësh. Çdo pilot mund të drejtojë çdo avion me çdo fluturim. Në këtë mënyrë bashkësitë e avionave dhe pilotëve janë të pavarura. Prej këtej dalin dy VSH elementare. NF →→AVION NF→→PILOT
Forma e katërt normale:
68
Një relacion është në formën e katërt normale atëherë dhe vetëm atëherë kur tëvetmet varësi shumëvlerëshe elementare janë ato nëtë cilat një çelës përcakton një përbërës. Në trajtë shembulli relacioni STUDENT nuk është në formën e katërt normale. Çelësi në këtë rast është bashkësia e përbërësve (komplet n-ëshja) Në të ekzistojnë VSH elementare NSKURSI NS SPORTI Është treguar se çdo relacion ka një dekompozim në formën e katërt normale që ështe pa humbje. STUDENT (NS, KURSI, SPORTI) (NS, KURSI)
(NS,SPORTI)
V.SH. elementare të dyja
Varësitë funksionale shumëclerëshe Forma e katërt Normale (4NF) Edhe kur relacioni është në BNCF mund të ndodhin anomali, e cila shprehet në proçesin e modifikimit. P.sh. le të konsiderojmë relacionin e panormalizuar OFERTE në fig. 7.9.a. Në relacion bëjmë supozimet e mëposhtme: 1. Secili kurs ka një ose disa instruktorë 2. Për secilin kurs të gjithë librat e treguar janë përdorur. 3. Teksti, i cili është përdorur për një kurs të dhënë është i pavarur nga instruktori, pra e njëjta bashkësi librash është përdorur pa vënë re instruktorin.
OFERTE OFERTE
KURSI MS_DOS MS_DOS MS_DOS MS_DOS MS_DOS MS_DOS DBASE DBASE
INSTRUKTORI ILIRI ARJANI PETRITI ILIRI ARJANI PETRITI MPZA MOZA
LIBRI ARBEN ARBEN ARBEN FATI FATI FATI ARI GENTI
69
KURSI MS_DOS
INSTRUKTORI ILIRI PETRITI ARJANI
LIBRI ARBEN FATI
DBASE
MOZA
ARI GENTI
(a) Relacioni i panormalizuar (b) Relacioni i normalizuar Fig. 7.9 Relacioni me varësi shumë vlerëshe Në fig. 7.9.b relacioni OFERTË është i normalizuar. Kështu për çdo kurs të gjithë kombinimet e mundshme të teksteve dhe profesioneve janë çfaqur në relacion. Vemë në dukje se çelësi primar i këtij relacionji përbëhet prej tre atributeve. (KURSI, INSTRUKTORI, LIBRI). Meqenëse këtu nuk ka determinant (përveç çelësit primar relacioni është në BNCF). Megjithatë ai përmban teprime në të dhënat. Supozojmë se duam të shtojmë një libër të tretë me autor JONA. Kjo do të kërkojë shtimin e 3 rrehtave, nga një për secilin instruktor. Le të shohim varësitë funksionale në këtë relacion. Për çdo kurs është përcaktuar grupi i instruktorëve (pra 1:M) dhe grupi i librave (lidhja 1:M). Megjithatë tekstet dhe instruktorët janë të pavarur nga njëri tjetri, kështuqë lidhja paraqitet si më poshtë. Tipi i varësisë në këtë figurë është shumëvlerëshe. Për të hequr varësinë shumëvlerëshe e projektojmë relacionin në de relacione, ku secili përmban një nga atributet e pavarur. Fig. 7-10 tregon rezultatin.
KURSI
INSTRUKTORI
MËSUESI KURSI MS_DOS MS_DOS MS_DOS DBASE
INSTRUKTORI ILIRI PETRITI ARJANI MOZA
LIBRI
LIBRI KURSI MS_DOS MS_DOS DBASE DBASE
LIBRI ARBEN FATI ARI GENTI
Fig. 7.10 Relacioni në formën e katërt normale Një relacion është në formën e katërt normale (4NF) në qoftë se ai është në BNCF dhe nuk përmban varësi funksionale shumëvlerëshe.
70
Forma të tjera normale: Format normale jashtë UNF janë përcaktuar, por interesi i tyre është vetëm në fushën e kërkimit, prandaj po japim shkurtimisht përkufizimet e tyre. Forma e pestë normale. (5NF); Kjo formë normale vepron me atë që quhet varësia bashkuese (join depedency). Një relacion që ka varësi bashkuese nuk mund të dekompozohet nëpërmjet projeksionit në relacione të tjera pa rezultate të rreme (sporious results). Forma e pestë normale jep përkufizime për heqjen e varësive bashkuese n.q.s. ekzistojnë. Ushtrime dhe Problema 1.
Klasifikoni secilin nga relacionet e mëposhtme si të normalizuara, 1NF, 2NF, 3NF. a) PUNONJËS(PUNONJËS#, EMËRPUNONJËSI, KODIPUNËS.) b) PUNONJËS(PUNONJËS#, EMËRPUNONJËSI,
)
2.
c) PUNONJËS(PUNONJËS#, EMËRPUNONJËSI, KODIPUNËS,PËRSHKRIMPUNE.) d) PUNONJËS(PUNONJËS#, EMËRPUNONJËSI, PROJEKT#,ORË_PUNE.) Për secilin nga relacionet e mëposhtme të bëhen: a) Jepni formën normale të gjendjes që janë. b) Identifikoni ndonjë varësi të padëshiruar. c) Jepni shembull të anomalisë së futjes dhe fshirjes. d) Normalizoni relacionin më tej. PUNONJËS
PUN#
KURS
INTERESI
123
NIVELI I
LOJË ME BULA
123
NIVELI II
LOJË ME BULA
456
MJESHTËR
SKI
456
MJESHTËR
LOJË ME BULA
LOJTARI BENI GIMI TONI MIRI TIMI
POZICIONI SM P SM QM SM
TRAJNERI NIKU EDI PJERNI GONI NIKU
FUTBOLL
PUN# PUN#
KURS INTERESI
TRAJNERI
POZOCIONI
3. Në figurën në vazhdim jepet paraqitja hierarkike (e panormalizuar) e informacioneve të mbledhura për personelin e një kompanie. Figura duhet të kuptohet si më poshtë: • Kompani ka një bashkësi departamentesh. • Çdo departament ka një bashkësi punonjësish, projektesh dhe zyrash. 71
• Çdo punonjës ka historikun e punës së tij (punët që ka kryer punonjësi). Për secilën nga punët punonjësi ka edhe historinë e pagave të tij. • Çdo zyrë ka bashkësinë e telefonave. Baza e të dhënave përmban informacionet e mëposhtëm. • Për çdo departament: numurin e departamentit (unik), buxhetin dhe numurin punonjësit që është manaxher i departamentit (unik) Departamenti
Punonjësi
Projekti
Detyra
Zyra Telefoni
Historiku i pagës
• Për çdo punonjës : numurin e punonjësit (unik), numurin e projektit të çastit, numurin e zyrës, numurin e telefonit, titullin e ëdo pune që ka kryer punonjësi, datën dhe rrogën për çdo ndryshim në këtë detyrë. • Për çdo projekt: numurin e projektit (unik) dhe buxhetin. • Për çdo zyrë : numurin e zyrës (unik) sipërfaqen, dhe numurat (inuk) të telefonave të instaluar në këtë zyrë. Ndërtoni një bashkësi të normalizuar që paraqesin këto informacione.
Gjuha SQL (Structured Query Language SQL përbëhet nga dy gjuhë: DDL – Data Description Language DML – Manipulation Language. Për të ilustruar paraqitjen e komandave të SQL do të na shërbejë si bazë një baze të dhënash e përbërë nga 3 relacione. -
STUDENT (Kod_s, emër_s, mosha, qyteti) Relacioni i cili jep informacione mbi stidentët me Kod_s - kodi e studentit
72
Emër_s – emrin e studentit Mosha - moshe e studentit Qyteti - qyteti i banimit. NDJEK (Kod_s, kod_mod, n_mes) Kod_s : kodi i studentit Kod_mod : kodi i modulit N_mes : nota mesatare KURS (kod_mod, titulli, përgjegjësi) Kod_mod : kodi i modulit Titulli : emërtimi i kursit Përgjegjës : përgjegjësi i modulit.
DDL:
Komandat e përcaktimit të të dhënave Krijimi i një baze të dhënash (katalogu i bazës) -
Nga një pikpamje e DBMS një bazë të dhënash përmban relacione bazë dhe relacione të . Mënyra më e natyrshme e DBMS është konzervojë relacionet në një katalog të Dbazës. Për këtëpërdoret komanda. Creata database emër_dbase: Kat D-Base Kat tabelë
Krijimi i tabelave relacioneve: Creat table
emër_tabele
atributi 1 atributi 2 ------atributi n
type (gjatësia) [kufizimet]; type (gjatësia) [kufizimet]; type (gjatësi) [kufizimet];
73
Krijimi i tabelës identifikphet nga emri i tabelës. Në të janë përcaktuar emrat e atributëve (ose kolonave), tipet e tyre, gjatësitë dhe kufizime të mundshme (konditat e integritetit). Tipi p.sh. mund të jetë: Char (n) – ku n jep gjatësinë e vargut të karaktereve Numeric (n1, n2) – n1 sasia e tabelave e shifrave dhe presja n2 sasia e shifrave pas presjes. Date . . . . Kufizimet p.sh. mund të jenë: Not null – që ndalon atributin korespondues të jetë null. Primary key – që tregon se atributi është çelës primar. Ky operacion krijon një tabelë boshe: qëllimi i saj është të kryojë strukturën e tabelës. •
Heqja e tabelës:
Drop table emër_tabele; Heq të gjitha të dhënat duke pastruar dhe strukturën e tabelës. •
Krijimi i indeksit: Create index emër_indeksi on emër_table (kdone1....)
Krijoni indeksin në një tabelë kur proçesin emrin dhe atributet për të cilat kërkojmë të gjenerojmë indeks. •
Heqja e indeksit Drop index
•
Emër_tabele.
Modifikimi i strukturës së tabelës Është e mundur të modifikohet struktura e tabelës. - Duke shtuar në tabelë një ose disa kolona (atribute) - Duke modifikuar tipin e të dhënave bashkëshoqëruar një ose disa kolonave. Kujdes: Është e pamundur një suprimonhet një kolonë.
1. Modify Table (Emër_Tabele, Atribut1,Atribut2,--74
2.
Alter Table Emër_tabele ADD(atributi tipi)
→ p.sh.
Shtimi: ALTER TABLE PRODUCT ADD(P_SALLECODE CHAR(I); Modif: ALTER TABLE PRODUCT MODIFY(P_PRICE-DECHAL(3,C))
DML: Ekzistojnë dy tipe komandash të manipulimit të të dhënave: - Komandat e modifikimit të të dhënave. - Komandat e seleksionimit të të dhënave. Komandat e modifikimit të të dhënave: • Shtimi i elementeve në një tabelë. Insert into emër_tabele [(kolonë1, kolonë2, - - - kolonën)] Values (V1, V2, - - -Vn) Shton një rresht në tabelën e specifikuar. Mundet të preçizphen vetëm disa kolona për të tjerat vendosen vlerat null ( ). • Modifikimi i vlerave në një tabelë: Update emër_table set cdone1=vlerë1, - - - [where kondite] p.sh. Modifikimi i qytetit të studentit me kod 1234 Update STUDENT set qyteti = “Durrës” Where kod_s = 1234 • Heqja e rreshtave në tabelë: Delete from emër_tabele [where kondite]; Suprimon rreshtat që plotësojnë konditën. p.sh. Delete from STUDENT WHERE qyteti = “KORÇË” Heq studentët nga korça
75
Komandat e seleksionit të të dhënave Blloku i kualifikimit Struktura e bllokut të kualifikimit është ndërtuar nga 3 elementë të cilat janë. Select , From dhe Where. Forma e përgjithshme e bllokut të kualifikimit është: Select From Where
atr1, atr2, - - -,atrn. Emër_tabele.
Në shprehjen logjike mund të përdorim: 1 operatorët e (>,<,>=, <=,<>,=) 2 lidhësit logjik (AND, OR, NOT) 3 Operacionet bashkësive (UNION, INTERSECT, MINUS) 4 Bërja pjesë jo e elementit (in, notion). 5 Operatorët bashkësuar. Operatori Between Ekzistojnë dy forma të thjeshtuara të bllokut të kualifikimit. -
A para kur është hequr where. Select atr1, atr2, - - - atrn From Emër_tabele.
Kjo korespondon me operacionin e projeksionit të relacionit mbi përbërësit atr1, atr2, - - -,atrn. p.sh.
Select emër_s From student; Ekuivalent me projeksionin Projeksion (Student, emër_s); - E dyta është rasti kur lista e përbërësve është zëvendësuar me * . Select * From Emër_tabele Wherë Konditë
Select X1, X2, - - -,Xn From Emër_tabele. Where konditë
Lidhur me konditat le të marrim disa shembuj. - Simbolet e krahasimit. p.sh. Kodet e studentëve që kanë mesatare >8 në M2
76
Select Kod_s From Ndjek Where Kod _ mod = “M2” AND n_mes >8. -
Bërja pjesë në bashkësi me operatorin IN. p.sh. Lista e emrave të studentëve që banojnë në Korçë, Vlorë.
Select Emër_s From Student Where qyteti IN (‘Elbasan’, ‘Korçë’, ‘Vlorë’); - Vlerat në një interval me operatorin Between. p. sh. Emrat e studentëve me moshë ndërmjet 20 dhe 24 vjet. Select Emër_s From Student Where mosha between 20 and 24. - Mbi prezencën e disa karaktereve në një varg me operatorin like ‘varg’. Në ‘varg’ shenja * zëvendëson një varg çfarëdo dhe shenja ? zëvendëson një karakter çfarëdo. p.sh.: Emrat e studentëve që banojnë në qytet që fillojnë me B. Select Emër_s From Student Where qyteti like ‘B*’; Modifikimi i një kondite bëhet duke përdorur NOT. P.sh. NOT IN ose NOT LIKE p.sh. Emrat dhe qytetet e studentëve që nuk banojnë në Tiranë dhe Durrës. Select Emër_s, qyteti From Student Where qyteti not in (‘Tiranë’, ‘Durës’);
77
Në SQL ekziston mundësia e merrjes së rezultateve duke përdorur order by p.sh. Listoni emrat e qyteteve dhe studentave që nuk banojnë të Tiranë, të renditur sipas rendit alfabetik të qyteteve, pastaj sipas emrave për studentët e të njëjtit qytet. Select Qytet, Emër From STUDENT Where qyteti <> ‘Tiranë’ Order by qytet , emër; → renditja në dy kutere. Funksionet e llogaritjes në kolonë Si në algjebër relacionale, mund të bëhen llogaritje mbi kolonat e tabelës, këto funksione janë. Sum – shuma e vlerave të kolonës Avg – mesatarja Max – maksimumi Min – Minimumi Count – Numërimi p.sh. 1. Nota më e vogël, më e madhe dhe mesatarja e përgjithëshme në modulin ‘M1’. Select Min (n_mes), Max (n_mes), Avg (n_mes) From Ndjek Where kod_mod = ‘M1’ 2. Numërimi i studentëve që ndjekin modulin M1. Select Count (*) From Ndjek Where kod_mod = ‘M1’; Agragatët Këtu mund të ndërtohen agragatet (ndarje horizontale e një relacioni). Për ndarjen e një relacioni përdoret group by. Shembull: Emrat e qyteteve dhe për secilin prej tyre numërin e studentëve që banojnë aty
78
Select qyteti, count (*) From Student Group by qyteti → Krijon relacion të ri.
qyteti
Sasia
-
20 30
Mund të bëhen selsksione në funksion të rezultateve të funksioneve të llogaritjes mbi bashkësi me ndihmën e Having. Shembull: Emrat e qyteteve që kanë më shumë se 10 studentë. Select qyteti. Count (*) From Student Group by qyteti Having count (*) > 10
funksioni i llogaritjes.
Blloqet e kualifikimit që shtrëngohen Një konditë mund të përmbajë një bllok tketër Shembull: “Arben”
Emrat e studentëve që banojnë në të njëjtin qytet me studentin Select Emër_s From Student. From Student Where Emër_s= ‘Arben’);
Prod. Operacioni Jointure kryhet duke vendosur në From listën e relacioneve Shembull: Emrat e studentëve dhe notat që kanë marrë në lëndë të ndryshme. Select Emër_s, kod_mod, 1_mes From Student Ndjek Where student.kod_s = Ndjek. Kod_s. Qulifikatorët ANY dhe ALL Është e mundur të krahasosh një shprehje që jep vlerë me rezultatet e një nënblloku ose me ndonjë nga vlerat e saj. SQL propozon përdorimin e kualifikatorëve ALL dhe ANY. Më saktësisht (le të jetë o një nga operatorët <,>,=,- -) - Kondita f o ANY është e vërtetë atëherë dhe vetëm atëherë kur foV është i vërtetë për të paktën një vlerë të rezultatit të nënbllokut. 79
-
Kondita foALL është e vërtetë atëherë dhe vetëm atëherë kur foV është e vërtetë për të gjitha vlerat V të rezultatit të kërkesës.
Vërejtje - Predikatet IN dhe =ANY janë ekuivalente - Predikatet NOT IN dhe <>ALL janë ekuivalente Shembull: Studentët E Tiranës që kanë moshën më të vogël se mosha maksimale e qytetit të Durrësit. Select Emër_s From Student Where Qyteti = ‘Tiranë’ AND mosha është e vërtetë atëherë dhe vetëm atëherë kur rezultati nuk është bosh. Shembull: Studentët që janë të regjistruar në kurse. Select emër_s From Student 80
Where EXIST (Select * From Ndjek Where kodi_s = Student. Kodi_s Është e relacionit Ndjek • Së fundi në SQL ekzistojnë operatërot e lidhjes ndërmjet kërkesave: - UNION - INTERSECT - MINUS Këto korespondojnë me operatorët e bashkimit, Prerje dhe diferencës në gjuhët algjebrik. Shembull : Jepni kodet e studentëve që ndjekin kurset ‘M1’ dhe ‘M2’ Select kod_s From Ndjek Where kod_mod = ‘M1’ INTERSECT Select kod_s From Ndjek Where kod_mod = ‘M2’;
SQL2 – Shprehjet e avancuara -
CASE : shprehje e CAST : shprehje e kthimit të tipit “Rresht shprehje vlerë” ndërto dhe ndërto një n-ëshe.
CASE sintaksa CASE WHEN kond1 then rez1 WHEN kond2 THEN rez2 WHEN kondn THEN rezn [ELSE rez x] END. n.q.s. kond1 është e vërtetë atëherë rez1 e me radhë, n.q.s. asnjëra prej tyre nuk plotësohet atëherë rezx, n.q.s. nuk ka ELSE atëherë ELSE NULL (bashkësi boshe). Le të marim relacionin 81
PUNONJËS (KP, EMRI, PAGA, RAJONI) KP – kodi punonjësit EMRI – emri i punonjësit PAGA – paga e punonjësit RAJON – rajoni i punës sipas kategorisë së (sportiv, muzik etj). M (RAJONI, KATI, TVSH, DIR) RAJONI – emri i rajonit KATI – kati ku ndodhet rajoni TVSH – TVSH që përdoret për rajonin DIR – drejtori i rajonit. MV ( RAJONI, MUAJI, PL, PH) RAJONI – emri i rajonit MUAJI - emri i muajit PL – sasia parave të lejuara për të prishur (PL) PH – sasia e parave të harxhuara (PH). Për të ilustruar CASE le të modifikojmë pagat e punonjësit sipas rajonit. Për ata të muzikës e rritëm 20%, për ata të sportit 1,1%. UPDATE PUNONJËS SET PAGA = CASE WHEN RAJONI = “Muzikë” THEN PAGA = PAGA WHEN RAJONI = “Sport” THEN PAGA=PAGA ELSE 0 END. Variantet e mundëshme: CASE vlerë 1 WHEN vlerë11 THEN rez 1 WHEN vlerë12 THEN rez2 WHEN vlerën THEN rez n [ELSE rezx] END. CASE WHEN clerë1 = vlerë11 THEN 82
WHEN vlerë 1 = vlerë 12 THEN WHEN vlerë1 = vlerë 1n THEN ELSE rezx END.
SQL 2 UNION, INTESECTION, DIFFERENCE Versioni i thjeshtë (e kemi parë) operator 2 bllok kualifikimi> ku operata = (UNION, INTERSECT, EXCEPT) të dy blloqet duhet të jenë kompatibël. d.m.th. n.q.s. jepen relacionet R(X1, X2, - - -, Xn) dhe S (Y1, Y2 - - - YP) Duhet n = p dhe Fusha (Xi) = Fusha (Yi) -
R UNOIN S eleminon dublimet R UNION ALL S nuk eliminon dublimet.
N.q.s. n<>p përdoret R UNION CORRESPONDING S Bashkimi (me eleminim) bëhet vetëm mbi kolona e përbashkëta. p.sh. R(X1, X2, X3, X4) dhe S(X1, X3, X5) bëjmë R (X1, X3) ∪ S (X1, X3) R UNION CORRESPONDING BY kolonat S (kolonat e S) p.sh
R UNION CORRESPONDING BY (X3) S bën R (X3) ∪ S(X3).
Të njejtat probleme trajtohen për INTESECTION, DIFFERENCE.
83
Modifikimi i skemës: Të shtohet një kolonë në një tabelë M(RAJONI, KATI, TVSH, DIR) Tipi ALTER TABLE M ADD COLUMN NBPUN (NUMBER) ⇓ M( RAJONI, KATI, TVSH, DIR, NBPUN) Vlera implicite të NBPUN janë 0. UPDATE M SET NBPUN = 0; Ose
Variabël që lëviz me M UPDATE M X SET NBPUN = (SELECT COUNT (*) FROM PUNONJëS WHERE PUNONJëS, RAJONI = X. RAJONI)
Vendos numrat e punonjësve tek relacioni M i modifikuar Pamjet dhe relacionet e
(SNAPSHOP)
Derivimi i relacioneve të reja Koncepti i nënskemave të jashtme i ofrohet përdoruesit nëpërmjet konceptit të fotos (Snapshop) dhe pamjes (vues). Foto = Snapshop Forma e realizimit të një foto bëhet me CREATE SNAPSHOP [REFRESH ]
S
AS
Çfarë bëhet: • Llogaritet blloku she shohet rezultati • Tabel s është “read-only”
84
• S’mund të manipulohet si relacion
• •
SELECT * FROM S S’mund të rifreskohet periodikisht (çdo ditë, muaj, . . .) Është i dobishëm në mjediset e shpërndarë.
P.sh. ne mund të krijojmë foton në sistemin hekurudhor. CREATE SNAPSHOP TR4002 AS FROM TIPI_VAGONIT WHERE NO_VAGONIT IN (SELECT NO_NOVAGONIT FROM TRENI WHERE NO_TRENI = “4002”) Duke proceduar në këtë mënyrë ne krijojmë në bazën e të dhënave një relacion të ri për të cilin skema është: TR 4002 (TIPI_VAGONIT). Përcaktimi i pamjes: Në vend që të llogarisim shprehjen relacionale dhe të materializohet shpërthimi i saj, mund të konsiderohet që një shprehje e tillë përcakton një relacion tëri virtual që quhet pamje. Në sistemin Relacional përdoret skema e mëposhtme në përcaktimin e pamjes: DEFINE VIEW V [Lista e përbërësve] AS < bllok kualifikimi>. Pamja V është përcaktuar si një relacion virtual mbi relacionet (d.m.th. mbi relacionet bazë ose pamje të tjera) tashmë të përcaktuara, që nedo i quajmë relacione burim. Duke rimarrë shembullin tonë është e mundur për një përdorues në Tiranë të krijojmë një pamje “ GJEN_VAGON”, që korespondon me nënbashkësinë e vagonave në stacionin e Tiranës. DEFINE VIEW GJEN_VAGON AS SELECT NO_VAGONIT, TIPI_VAGONIT, GJENDJA FROM VAGON WHERE STACIONI = “TIRANË”
85
Pamja GJEN_VAGON ka përbërësit e përmendur me SELECT dhe jep relacionin GJEN_VAGON (NO_VAGONIT, TIPI_VAGONIT, GJENDJA). Një pamje është një dritare dinamike me\bi bazën, në këtë kuptim të gjitha modifikimet e kryera mbi një relacion burimi janë pasqyruar automatikisht në pamjen. Në shembullin që dhamë mund të njohim “vagonat disponibel në Tiranë” SELECT NO_VAGONI FROM GJEN_VAGON WHERE GJENDJA = “ Disponibel“ Për të trajtuar një kërkesë të tillë, SQBDH relacionare krijon atë që është e përshtatëshme për ta quajtur kompozimi i pamjes. SELECT NO_VAGONI FROM VAGONI WHERE GJENDJA = “Disponibel “ AND STACIONI = “Tiranë”. Ka një kontradiktë në vizionin e pamjes si dinamike: Në proçesin e modifikimit ky proçes duhet të shtrihet gjerë në relacionin bazë. • Për të bërë një modifikim nëpërmjet një pamje, duhet të jetë e mundur të shtrihet ky modifikim gjer te relacionet burim. N.q.s. pamja është e tillë që ekziston një korespondencë biunivoke ndërmjet n-ësheve të pamjes dhe të atyre të një dhe vetë një relacioni burim modifikimet dhe fshirjet mund të shtrihen pa asnjë problem. • Lidhur me futjen n.q.s. pamja është projeksion i një relacioni, atëherë duhet përcaktuar cila dotë jetë vlera e përbërësve që nuk shfaqen në pamje. Në rastin e pamjes GJEN_VAGON futja e një vagoni të ri nëpërmjet pamjes bën të papërcaktuara vlerat për PESHA_BOSH dhe KAPACITETI. Prej këtij del se shtrirja e futjes dhe modifikimeve nëpërmjet pamjes është i pasigurtë. Në vazhdim po japim një shembull për të argumentuar këtë fenomen: Le të marrim parasyshë relacionet PUN (NUM, EMRI, KODIND) dhe NDER(KODIND, DREJ) 86
NUM - kodi i punonjësit EMRI – emri i punonjësit Kodind – kodi i ndërmarjes Drej – emri i drejtorit
Në formë të shtrirë: PUN NUM e1 e2 e3 e4 e5
EMRI Ilsi Skënder Luan Ela Monda
KODIND d1 d1 d1 d2 d2
KODIND
DREJ
d1
Bujar
d2
Besi
NDER
Supozojmë një pamje PUND të përcaktuar mbi produktin e këtyre dy relacioneve mbi KODIND: DEFINE VIEW PUND AS SELECT NUM, EMRI, KODIND, DREJ FROM PUN, NDER WHERE PUN.KODIND = DREJ. KODIND Reaultatet marrim PUND NUM e1 e2 e3 e4 e5
EMRI Ilsi Skënder Luan Ela Monda
KODIND d1 d1 d1 d2 d2
DREJ Bujar Bujar Bujar Besi Besi
N.q.s. autorizojmë përdoruesin të modifikojë pamjen PUND si më poshtë: MODIFY PUND SET DREJ = “fred” WHERE NUM = e1 Ndryshojnë drejtorin pa marrë parasyshë se ai i takon ndërmarjes.
87
SQL procedurale SQL nuk suporton ekzekutimin e procedurave të bazuara në disa kondita logjike. Pra SQL nuk i pranon strukturat IF THEN ELSE < kryej procedurën alternative>. END IF. Nga ana tjetër SQL nuk suporton ciklet. Pra SQL nuk suporton DO WHILE END DO N.q.s. jeni të interesuar të përdorni IF_THEN_ELS ose DO_WHILE, ju mund të përdorni gjuhë programimi të tilla si COBOL, FORTRAN, C, PASCAL ose VISUAL BASIC. Ju mund të integroni shprehjet e SQL me gjuhët e programimit. Përdorimi i Blloqeve të kualifikimit që shtrëngohen është përafrimi më i mirë me aftësitë procedurale në aplikimet e biznesit. Mungesa e aftësive procedurale ka bërë që shumë aplikime biznesi të bazohen me shkrimin e rreshtave të programeve në COBOL. Në sistemet e databazave përdoret Procedural SQL. Kodi procedural ekzekutohet nga DBMS kur thërritet (direkt ose indirekt) përdoruesi fundor. Këto elemente janë implementuar në Oracel SQL +, por jo në SQL2 por kryesisht në SQL3. PL/SQL2 mund të përdoret për -
Trigerat Procedurat e Ruajtjes Funksionet PL/SQL.
Nuk duhen ngatëruarfunksionet PL/SQL me funksione tashmë të ndërtuara në SQL, siç janë MIN, MAX. Këto funksione përdoren në shprehjet SQL ndërsa funksionet PL/SQL thërriten nga programet PL/SQL.
88
Trigerat Një triger është kod procedural që thërret automatikisht nga RDBMS, gjatë ndodhje së një ngjarje ne marim e të dhënave. Vlen të përmendet: • Trigeri thëritet paraose pas një rresht është i selektuar, inseruar ose update. • Trigeri është i bashkëshoqëruar me një tabelë të DB. • Çdo tabelë mund të ketë një ose disa Trigera. • Trigeri ekzekutohet si pjesë e transaksionit që e përmban atë. • Trigeri mund të përdoret për të theksuar kondita, që nuk mund të bëhen gjat dezinjimit të DBMS dhe në proçesin e implementimit. Për të parë se si është krijuar dhe përdorur trigeri do të shohim një problem të thjeshtë inventarizimi. . p.sh. n.q.s. produkti në dorë (stok) është modifikuar, kur produkti shitet, sistemi kontrollon automatikisht kur produkti në dorë kalon nën minimum të lejueshëm. Për të demostruar këtë proçes le të fillojmë me modifikimin e tabelës: PRODUCT (P_KOD, P_PËRSHKRIM, P_INDATE, P_NËDORË, P_MIN, P_ÇMIM, P_DISCOUNT, SH_KOD, P_MIN_POROSI, P_RIPOROSI). P_min - minimumi i lejeshëm. SHITËS (SH_KOD, SH_EMËR, SH_KODZONE, SH_KONTAKT, SH_PHONE, SH_GJENDJE, SH_POROSI) SH_EMËR - emri i njësisë SH_KONTAKT - personi i kontaktit SH_POROSI - ka pasur pasuri të mëparëshme Për të demostruar proçesin le të fillojmë me modifikimin për të shtuar P_MIN_POROSI dhe riporosi (P_RIPOROSI). Vlerat fillestare të P_RIPOROSI mbushen PO/JO (1/0). Tabela produkt e modifikuar parqitet. P_KOD
P_PËRSH
P_INDATE
P_NËDORË
P_MIN
P_ÇMIM
P_DISCO
SH_KOD
P_MIN_POR
P_RIPOR
1QER/31
Panel pikture
03_DHJ_02
8
5
20.000
0.00
25595
25
0
2232QWE
Kalavidë
24_JAN_03
6
5
990
0.05
24288
15
0
89
N.q.s. ne e bëjmë sasinë e produktit “11QER/31” në 4 dokumente: SQL > SELECT * FROM PRODUKT WHERE P.KOD = 11QER/31 P_DKO
P_PËRSHK
11QER/31 Panel pikt
P_INDATE P_NËDORË P_MIN P_ÇMIM
03_DHJ_02
8
5
SH_KOD P_DIS
20000
P_MIN_POR
P_RIP
25
0
25595
SQL > UPDATE PRODUCT SET P_NËDORË = 4 WHERE P_KOD = “11QER/31”. - 1 row update (përgjigjet sistemi) SQL > SELECT * FROM PRODUCT WHERE P_KOD = “11QER/31” P_KOD
P_PËRSHK
11QER/31 Panel pikt
P_INDATE P_NËDORË P_MIN P_ÇMIM
03_DHJ_02
4
5
SH_KOD P_DISC P_MIN_POR P_RIP
20000
25595
25
1
Trogeri më lartë ka punuar mjaft mirë. Ai e ka ndryshuar vlerën e P_RIPOROSI nga NO(0) në YES (1). Le të shohim se çfarë ndodh kur ne modifikojmë sasin minimum për produktin “2232/QWE” duke bërë që sasia në dorë për të të jetë nën minimum. SQL > SELECT * FROM PRODUCT WHERE P_KOD = “2232/QWE”. P_KOD
P_PËRSHK
2232/QWE kacavide
P_INDATE P_NËDORË P_MIN P_ÇMIM P_DISC SH_KOD P_MIN_POR P_RIP
03_DHJ_02
6
5
990
24288
15
0
SQK > UPDATE PRODUCT SET P_MIN = 7 WHERE P_CODE = “2232/QWE” 1 row update. SQL > SELECT * FROM PRODUCT WHERE P_CODE = “2232/QWE”. P_KOD 2232/QWE
P_PËRSHK
Kaçavidë
- - - - - - - - P_NËDORË 7
P_MIN 6
- -
- - - - - - - -
P_RIP 0
Megjithse P_MIN është më e vogël se P_NËDORË në rubrikën P_RIPOROSI ngelë NO (0). Përgjigja është e thjeshtë se modifikuam P_MIN dhe trogeri që ndërton në punën vetëm kur modifikohet P_NËDORË.
90
Për të eleminuar këtë mospërputhje duhet ndryshuar trigeri duke përfshirë dhe atributin P_MIN. Ky triger ndërtohet si më poshtë: >SQL CREATE OR REPLACE TRIGGER TRG_PRODUC_RIPOROSI AFTER INSERT OR UPDATE OF P_NËDORË, P_MIN ON PRODUCT BEGIN UPDATE PRODUCT SET P_RIPOROSI = 1 WHERE P_NËDORË <=P_MIN END; Në këtë rast problemi ecën në të dyja situatat. Në proçesin e mësipërm n.q.s. ndryshojnë P_NËDORË për produktin “11QER/31” siç tregohet më poshtë. SQL > UPDATE PRODUCT SET P_NËDORË = 28 WHERE P_KOD = “11QER/31”. Do të marrim tabelën. Duke pasur tabelën PRODUKT do të krijojmë triger për të vlerësuar P_NËDORË . N.q.s. sasia në dorë është nën minimumin e treguar në P_MIN, atëherë kolona P_RIPOROSI do të bëhet Yes (1). Sintaksa e krijimit të trigerit në Oracle është: CREATE OR REPLACE TRIGER [BEFORE/AFTER] [DELETE/INSERT/UPDATE] OF ON [FOR EACH ROW] BEGIN PL/SQL instruksionet END. Trigeri që do të krijojmë siç thamë më lartë do të jetë: SQL > LIST (listohet) 1. CREATE OR REPLACE TIGER TRG_PRODUK_P_POROSI 2. AFTER INSERT OR UPDATE OF P_NËDORË NË PRODUKT 3. BEGIN 4. UPDATE PRODUKT 5. SEP P_RIPOROSI =1 91
6. WHEN P_NEDORE <= P_MIN 7. END; SQL > RUN - Trigger created.
P_KODE 11QER/31
- - - -
P_NËDORË P_MIN 29 5
P_RIPOROSI 1
Vini re se P_RIPOROSI ngelet përsëri 1 megjithse plotësohet kondita P_NËDORË > P_MIN. Dalim në konkluzionin që trigeri ynë nuk i ka marrë në konsideratë të gjitha rastet. P_RIPOROSI kalon 1 dhe nuk kalon më në 0. Si rezultat duhet përmirësuar trigeri që të japë përgjigje korrekte në të gjitha rastet. SQL > CREATE OR REPLACE TIGER TRG_PRODUK_P_RIPOROSI. BEFORE INSERT OR UPDATE OF P_NËDORË P_MIN ON PRODUKT FOR EACH ROW BEGIN IF : NEW. P_NËDORË < = :NEW. P_MIN THEN :NEW. P-P_RIPOROSI:=1 ELSE : NEW. P_RIPOROSI: = 0: END IF END. • EACH ROW përdoret për të trigjeruar të gjitha rreshtat e prekur nga trigeri. • Është e përdorur : NEW për vlerat e reja, po kështu mund të përdoret: OLD për vlerat e vjetra. Ne mund të krijojmë tabelën REGJISTRIM për të lidhur tabelat STUDENT dhe KLASE. Në këtë shembull çelësi primar i tabelës REGJISTRIM është krijuar si çelës i kompozuar i çelësave të jashtëm STUD_KOD dhe KLASE_KOD. (Konceptuesi mund të krijojë çelës promar si RESHT_REGJISTRIMI duke përdorur vlera të ndryshme për rreshtat. Paraqitja e databazës do të jetë:
92
Emri i tabelës: STUDENT Çelësi primar: STUD_KOD Çelësi i jashtëm: ju STUD_KOD EMRI 321452 324257
SHKËMBI MALI
Emri i tabelës: REGJISTRIM Çelësi primar : KLASE_KOD + STUD_KOD KLASE_KOD STUD_KOD GRADA_REGJISTRIMIT
10014 10014 10018 10018 10021 10021
321452 324257 321452 324257 321452 324257
C B A B C C
Çlësi i KLASE_KOD, STUD_KOD
jashtëm:
Emri i tabelës : KLASE Çelësi primar : KLASE_KOD Çelësi i jashtëm: KURS_KOD KLASE_KOD
KURS_KOD
KLASE_SEKSION
10014 10018 10021
ACCT_211 CIS_220 QM_261
3 2 1
KLASE_ORË HM 2:30. 3:45am HEP 9:00. 9:50am HEP 9:00.
KLASE_SALLE
PROF_KOD
B201 A112 C305
342 114 114
93
Koncepte bazë Termi Object – oriented (00) e ka origjinën te gjuhët e programimit 00. Gjuha e parë 00 është SIMULA mëtej C++ etj. Konceptet 00 aplikuar në B.Dh. Diferenca: -
Objekti në gjuhët e programimit 00 ekziston vetëm gjatë ekzekutimit të programit. Objekti në BDh 00 ekziston përherë dhe mund të ndahet në disa programe. Bazat e të dhënave 00 krijojnë një sistem unik gjenerimi që quhet identifikues objekti (OID = objekt identifikimi).
* OID ↔çelës primar në bazat relacionale. Struktura e brendëshme e një objekti përfshin specifikimin e * Variablave të ndodhjes. ⇓ mbajnë vlerat që përcaktojnë gjendjen e brendëshme të objektit Këtu mund të themi : Variabël i ndodhjes = atribut Sistemet Object – Oriented lejojnë përcaktimin e operacioneve ose funksioneve që mund të aplikohen në një objekt të tipit të caktuar. * Një operacion përcaktohet me dy pjesë -
signature (interface) specifikon emrin e operacionit dhe variablat metoda (trupi) specifikon implementimin e operacionit
Koncept tjetër është: 1 2 • hierarhia e tipeve dhe klasave
94
Trashëgimia Lejon përcaktimin e tipeve të reja duke trashëguar operacione dhe struktura të përcaktuara në tipet dhe klasat e mëparëshme. Problem tjetër në BDh 00 është paraqitja e relacioneve ndërmjet objekteve. Lidhje nuk paraqitet në mënyrë eksplicie, por bëhet duke përdorur metoda të përshtatshme që pozicionojnë në obkektet e lidhura. Koncept tjetër është polimorfizmi i operatorit, i cili i referohet një operacioni që ka aftësinë të zbatohet nëp objekte të tipave të ndryshme. p.sh: një operacion që shërben për llogaritjen e sipërfaqes së një objekti gjeometrik mund të ndryshojë në implementimin e tij, në varësi të faktit nëse figura është trekëndësh apo katërkëndësh. Kjo mund të kërkojë përdorimin e rilidhjes së vonëshme të emrit të operacionit me metodën e përshtatshme në ekzekutimin, kur tipi i objektit në të cilin do të zbatohet operacioni bëhet i njohur. Identifikimi i objektit Siç thamë identifikimi i objektit bëhet me OID. Vlera e OID është e padukshme tek përdoruesi i jashtëm. - Vetia kryesore e OID është inimutabël, d.m.th. që vlera e një OID për një objekt të veçantë nuk mund të ndryshojë. - Një OID duhet përdorur vetëm një herë. Këto dy veti sjellin që një OID të mos varet nga ndonjë vlerë e atributeve të objektit, meqenëse vlera e një atributi mund të ndryshojë. Disa sisteme përdorin adresën fizike si OID duke rritur efektivitetin e kapjes së objektit. N.q.s. adresa fizike ndryshon një shënjues indirekt na çon në pozicionin e ri. Disa modele 00 kërkojnë që gjithçka të paraqitet si objekt, pavarësisht në se është vlerë e thjeshtë apo objekt kompleks. Në këtë rast çdo vlerë bazë qoftë e plotë, varg apo Booleane ka OID. Kjo lejon që dy vlera bazë kanë OID të ndryshme, të cilat në disa raste mund të jenë të dobishme. p.sh. një vlerë e plotë 50 mund të përdoret për të paraqitur peshën në kg. dhe herë të tjera moshën e personit. Në këtë rast mund të krijohen dy objekte me dy OID të ndrushme dhe të dyja të kenë të njejtën vlerë bazë 50.
95
Kjo është e dobishme si model teorik, por nuk është shumë praktike sepse mund të kërkojë nga gjeneratori shumë OID. Megjithatë shumë sisteme oo i pranojnë të dy dhe objektet dhe vlerat. Struktura e objektit Në një bazë të dhënash 00 vlerat (gjendjet) e objekteve mund të ndërtohen nga objekte të tjera duke përdorur disa tipe konstruktorësh. Çdo objekt paraqitet si treshe i, c, v, OID
vlera(gjendja) konstruktori
ekzistojnë tipe të ndryshëm konstruktorësh në varësi të modelit të të dhënave ose modelit 00. Tipet e konstruktorëve bazë janë Atomi, n-ëshja, set. Të tjerë konstruktorë janë List dhe array. Vlerat atomike janë elemente të fushës D. Në to përfshihen. Integer, real, strong, Boolean që janë të dhëna bazë dhe ndonjë tip tjetër që mbështetet nga sistemi. Një vlerë v është interpretuar për bazë të vlerës së konstruktorit c në tre (i,c,v) N.q.s. c = atom, vlera e v është atomike në fushën D. N.q.s. c = set, vlera e v është bashkësia e identifikatorëve të objekteve {i1, i2 . . . .in}, të cilët janë OID për bashkësinë e objekteve që janë të të njëjtit tip. N.q.s. c = tuple (n-ëshe) vlera e v është n-ëshja e formës , ku çdo aj është atributi ( i quajtur variabli i ndodhjes në terminologjinë 00. N.q.s. c = lost, vlera e v është listë e renditur e identifikuesve të objekteve [i1, i2, . . .,in] të të njëjtit tip. 96
N.q.s. c = array , vlera e v është varg i identifikuesve të objekteve. Të gjitha vlerat në një objekt jo atomik referohen tek objektet e tjerë nëpërmjet identifikatorit të tyre. I vetmi rast kur vlera duhet është objekti atomik. Në bashkësinë e typeve bën pjesë dhe tipi bag. Bag është i ngjashëm me set, veçse ky lejon vlera të dublikuara. Në shembullin e mëposhtëm le të pranojmë se çdo gjë është objekt, duke përfshirë dhe vlerat bazë. Le të pranojmë se kemikonstruktorë : atom, set, tuple. Tani do të paraqesim disa objekte të bazës së të dhënave KOMPANIA duke përdorur modelin e ndërtuar. Do të përdorim i1, i2, i3, . . . . si të gjeneruar nga sistemi. Një objekt është përcaktuar nga treshja: (OID, tipi konstruktor, vlera) Le të marrim në konsideratë objektet e mëparshëm: O1 = ( i1, atom, Tiranë) O1 = (i2, atom, Durrës) O3 = (i3, atom, Vlorrë) O4 = (i4, atom, 5) O5 = (i5, atom, Research) O6 = (i6, atom 6_MAI_02) përfaqëson vlerën 5 O7 = (i7, set, i1, i2, i3) O8 = (i8, tuple,
Objekti O8 është tuple; që paraqet Departamentin 5 dhe ka atributet DNAME, DNUMBER, MGR, LOCATION si vlera. Atributi MGR ka objektin tuple O9 si vlerë të tij, i cili ka dy atribute. Vlera e atributit MANAGER është i12 ( i patreguar), i cili është punonjës që administron Departamentin. Ndërsa vlera MANAGERSTRAGE është një tjetër objekt atomik, vlera e të cilit është data. Vlera e atributit PUNONJËS e O8 është objekti set të punonjësve që punojnë në Departamentin etj. Në këtë model një objekt mund të paraqitet si një strukturë grafi, meqenëse ata mund të ndërtohen duke aplikuar në mënyrë të përsëritur tre konstruktorët bazë.
Tipi konstruktor Në gjuhën e përcaktimit të të dhënave (OODDL), që përfshin tipet e mëparshme të konstruktorëve, mund të përdoret për të përcaktuar tipet e objekteve për aplikimet e bazave të të dhënave. Këta tipe konstruktorësh mund të përdoren për të përcaktuar strukturën e të dhënave për një skemë të bazës së të shënave. Figura më poshtë tregon se ei mund të deklarohen PUNONJËS dhe DEPARTAMENT. define type punonjës: tuple (emri : string. nss : string datëlindja : Date seksi : Char dept : departament); define type Date: tuple (viti : integer, muaji : integer, dita : integer); define type Departament: tuple (demer : string, dnumer : string, mgr : tuple (manager: Punonjës 98
date fill:date); vendet : set (string) punonjës : (Punonjës); projekte : set (Projekte); tip bazë Leksionin e ardhshëm do të shohim se si integrohen strukturën e përgjithshme të objektit.
në
Shtërngimi i operacioneve dhe i metodave Koncepti i shtrëngimit është një nga karakteristikat kryesore të gjuhëve OO. Ky koncept është i lidhur ngushtë me tipin abstrakt të të dhënave dhe informacioneve. Në bazat e të dhënave tradicionale ky koncept nuk është aplikuar, meqenëse këto koncept kanë filluar të implementohen me tipin abstrakt të aplikuar në OO. Në përcaktimin e objektit mund të përdoren disa operacione për të krijuar ose prishur objekte, të tjera operacione modifikojnë objektet, të tjerë mund të jenë për të marrë pjesë të objektit ose për të kryer veprime mbi vlerën e objektit. Për të Karakterizuar objektin së bashku me veprimet që kryhen në të është përdorur termi klasë. Le të marim në konsideratë tipin Punonjës dhe Departament dhe të bëjmë zgjerimin e tij në përcaktimin e klasës së objekteve. define class Punonjës type tuple (emri: string, nss : string, datëlindja : Date, seksi : Char dept : Departamenti);
Signature
operations mosha (p:punonjës) : integer; krijo_pu_të_ri (Punonjës: prish_pun(p:Punonjës) boolean;
metadata
define class Departament : type (demër: string, dnumër: integer, mgr : tuple ( manager: Punonjës, 99
date_fill: Date), vendet: set (string), punonjës : set (punonjës), prijekte : set (Projekte) ; tipi bazë operations numri_i_pun (d:Departament) : integer; krijo_dept_ri: Departament, prish_dept (d : Departament) : boolean, shto_pun (d: Departament, p: Punonjçs) boolean, (* shto punonjës të ri në departament*) hiq_pun (d:Departament, p:Punonjës): boolean. (*heq një punonjë nga departamenti*). Fig: Përdorimi i OODL për të përcaktuar klasat Punonjës dhe Departament. Një nga karakteristikat e objekteve është persistenca. Një objekt persistent mund të ruhet në databazë dhe pas përfindimit të programit. Objektet të tilla mund të thuren nga sistemi dhe gjuhët tjera të programit. Një objekt B quhet i pakapshëm nga një objekt A n.q.s.grafi i objektit A lidhet me objektin B. P.sh. të gjithë objektet që kemi në konsideratë (që i pamë leksionin e kaluar) janë të kapshëm nga objekti O8. O8 O4
O5 O12
O7 O6
O10 O12
O13
O11 O14
O15
O16
O17
Veti tjetër ështa transistenca (objekti zhduket)
100
Tipet dhe klasat e hierarhive dhe trashëgimive Një karakteristikë tjetër kryesore e sistemeve 00 është se ata lejojnë tipin dhe klasat e trashëgimisë dhe hierarhisë. Tipet dhe klasat e hierarhisë. Në shumë aplikime të bazave të të dhënave ka shumë objekte që janë të të njëjtit tip. Këtu bazat e të dhënave OO krijojnë mundësinë për klasifikimin e objekteve bazuar në tipin e tyre, siç bëhet në bazat e tjera të të dhënave. Në bazat e të dhënave OO e re është që sistemi lejon përcaktimin e tipeve të reja bazuar në tipe të tjera të përcaktuar duke futur konceptin e hierarhisë. Tipi është përcaktuar duke dhënë emrin r tipit dhe duke përcaktuar numrin e atributeve ( v variablat e ndodhjes) dhe relacionet (metodat) për tipin. Në disa raste atributet dhe relacionet së bashku quhen funksione, për të thjeshtuarterminologjinë. Një tip mund të përcaktohet si më poshtë formalisht TYPE_NAME: function, function, . . . . . . ,function p.sh. një tip që përshkruan karakteristikate personit mund të përcaktohet. PERSON: Emri, Adresa, Datëlindja, Mosha, Nss Në këtë tip Emri, Adresa, Datëlindja, Nss janë implementuar si atribute të ruajtur, ndërsa mosha si metodë që llogarit moshën nga Datëlindja dhe Data_aktuale. Koncepti i nëntipit është i dobishëm kur konceptuesi ose përdoruesi mund të krijojë tip të ri, i cili është i ngjashëm por jo identik me një tip tashmë të përcaktuar, të cilin do ta quajmë supertip. p.sh supozojmë se duam të përcaktojmë dy tipe të reja PUNONJËS dhe STUDENT si më poshtë: PUNONJËS: Emri, Adresa, Datëlindja, mosha, Nss, Paga. STUDENT: Emri, Adresa, Datëlindja, Mosha, Nss, Dega, Grada. Këtu duhet që si STUDENT ashtu dhe PUNONJËS përfshijnë të gjitha funksionet e përcaktuara tek PERSON, plus disa funksione shum specifike të tyre, të cilët mund t’i deklarojmë si nëntipe të PERSON. Secili prej tyre do të trashëgojë funksionet e përcaktuara më parë tek PERSON: Emri, Adresa, Datëlindja, Mosha, Nss. Për PUNONJËS paga mund të jetë atribut i ruajtur. Për STUDENT është e nevojshme Dega dhe GRADA.
101
Deklarimi i tyre bëhet: PUNONJËS : subtype_of PERSON, Paga STUDENT : subtype _of. Person: Dega, Grada. Në këtë mënyrë secili prej tyre trashëgon funksionet e PERSON. Objektet komplekse Ekzistojnë dy tipe objektesh komplekse: -
të strukturuar të pastrukturuar.
Objektet komplekse të pastrukturuar dhe tipi i zgjerueshëm: Një objektin kompleks i pastrukturuar, i prodhura nga DBMS, lejon ruajtjen dhe hapjen e objekteve të mëdha, që janë të nevojshëm në aplikime. Shembuj tipik janë bitmap images dhe vargje të gjata të tekstit që njihen si binary large objects ose BLOB. Këta objekte janë të pastrukturuar np kuptimin që DBMS nuk din se si është struktura e tyre. Meqenëse OO DBMS lejon përdoruesit të krijojnë tipe të reja dhe tipi përfshin si strukturën dhe informacionin, mund ta shohim OO DBMS sikur ka një tip të zgjerueshëm.
Objektet komplekse Në këtë rast struktura e objektit është e njëhur nga OODBMS. Si shembull merret objekti DEPARTAMENT. Në nivelin e parë objekti ka strukturë tuple me gjashtë atribute: demerdnumer, mgr, vendet, punonjës dhe projekt. Në këtë strukturë vetëm demer dhe dnumer kanë vlerë bazë, të tjerat kanë vlera kompleksive dhe prej këtu ndërtojmë nivelin e dytë të objekteve komplekse. Njëri prej tyre
Tuple mgr
Vendet set punonjës set. Projekt set.
Secili prej tyre ka strukturë në nivelin e dytë.
102
Polimorfizmi Një karakteristikë tjetër e sistemeve OO është se ata prodhojnë poliformizmin e operacioneve, që ndryshe njihet si mbulim i operatorëve (operator overlooding). Ky koncept tregon që i njëjtë emër operatori ose simbol të futet në dy ose më shumë implementime të ndryshme të operatorit në varësi të objektit në të cilin operatori aplikohet. Kjo ilustrohet me një shembull të thjeshtë në gjuhët e programimit. Simboli “+” merr kuptim të ndryshëm kur operatorët janë integer, string apo bashkësi (PASCAL). Në bazat e të dhënave OO ndodh e njëjta situatë. Le të marrim në konsideratë GEOMETRIC_OBJECT dhe nëntipit GEOMETRIC_OBJECT : From, sipërfaqja, Pika_Referimit. KATËRKËNDËSH subtype_of GEOMETRIK _OBJECT (Forma =’katërkëndësh’) Gjatësi, Gjerësia TREKËNDËSH subtype_of GEOMETRIK_OBJECT (Forma = ‘Trekëndëshi’): Brinja1, Brinja2, Këndi. RRETHI subtype_of GEOMETRIC_OBJECT (Forma = ‘Rreth):Rrezja Këtu funksioni Sipërfaqja është deklaruar për të gjithë objektet e tipit GEOMETRIC_OBJECT. Megjithëse implementimi i metodës për sipërfaqja mund të ndryshojë për secilin nëntip të GEOMETRIC_OBJECT. Një mundësi është të ketë një implementim të përgjithshëm për llogaritjen e sipërfaqes së GEOMETRIC_OBJECT të përgjithësuar (p.sh. duke shkruar një algoritëm të përgjithshëm për llog. E sipërfaqes së poligonit) dhe pastaj duke shkruar allgoritme më efikase për llogaritjen e sipërfaqes së objekteve gjeometrike siç janë: rrethi, katërkëndëshi, trekëndëshi etj.
Trashëgimia e shumëfishtë Trashëgimia e shumëfishtë ndodh kur ndonjë nëntip T është nëntip i dy ose më shumë tipeve të ndryshme dhe trashëgon funksionet (atributet dhe metodat) e dy suporteve.
103
p.sh. mund të krijojmë nëntipin INXHINIER_MANAXHER që është nëntipi i të dyjave INXHINIER dhe MANAXHER. Një problem që mund të ndodhë në këtë rast është që të dy supertipet prej të cilave trashëgon nëntipi, është se mund të kenë funksione të ndryshme me të njejtin emër duke krijuar dykuptim. Për të dy MANAXHER dhe INXHINIER mund të kenë funksionin Paga. N.q.s. funksioni Paga është implementimi me metoda të ndryshme në supertipet MANAXHER dhe INXHINIER dykuptimi trashëgohet në nëNtipin INXHINIER_MANAXHER. Është e mundur që supertipet INXHINIER dhe MANAXHER të trashpgojnë funksionin Paga nga i njëjti supertip dhe në këtë rast nuk ekziston dy kuptimi. Ekzistojnë disa menyra për të vepruar me dy kuptimin nëtrashëgiminë e shumëfishtë. Një zgjidhje është që sistemi të kontrollojë dykuptimin kur krojihet nëntipi dhe t’i lejojë përdoruesit të zgjedhë funksionin që do të trashëgohet. Një menyrë tjetër është përdorimi i sitemit implicit (default). Rruga e tretë është ndryshimi i emrit të njëjtit prej funksioneve. Konkluzioni mbi SGBD OO Avantazhet: • Ato të përafrimit objekti i orientuar: ripërdorimi, lehtësimin. • Modeli i të dhënave është i pasur. • Merr në llogari dinamikën • Lehtësi në përdorimin e LMD. Disa avantazhe ose probleme të pazgjidhura • Thjeshtësia e modelit relacional humbet. • Nuk ka akoma konsensur mbi një LMDS standarde të tipit SQL me të cilin përdoruesit janë mësuar. • Konceptimi i skemës konceptuale nuk është i lehtë.
104
Zgjerimi i gjuhës SQL në O2SQL O2SQL ka karakteristikat e mëposhtme: • Në O2 përdoren tipet atomike Boolean, Char, Integer, Real, String, dhe Bit. Tipi konstruktuar përfshin Tuple, list, set dhe unique set. Ndryshimi set dhe unique set është se i dyti nuk lejon dublime. Përcaktimi i klasës: class definition përbëhet nga dy pjesë: tipi i objektit metoda. Egziston një ndryshim në O2 ndërmjet vlerave dhe objekteve -
Vlera ka vetëm tip dhe përfaqëson vetveten. Nuk ka O2. Objekti i përket një klase: ka tip dhe metodë. Objekti ka OID.
Sistemi O2 ka gjuhën O2C, e cila mund të përdoret për të përcaktuar klasat, metodat dhe tipet. Në vazhdim do të japim deklarimet në O2 për bazën e të dhënave të një zyre turistike:
105
Kapsulimi (Encapsulation) SQBOO nuk e aplikojnë kapsulimin strikt. Ky është i rëndë për t’u aplikuar,sepse e bënë të vështirë LMD. Shkallët e kapsulimit përcaktohen si më poshtë: 1. Kapsulimi strikt. Akcesi ( lexim shkrimi ) i të dhënave të objektit në një klasë tjetër kërkon thirjen e një metode të klasës së objektit. 2. Kapsulimi me shkrim. Aksesi në shkrim bëhet duke thërritur një metodë, aksesi në lexim bëhet direkt. 3. Kapsulimi i pjesshëm: klasat e objekteve kanë dy tipe të dhënash, të dhënat publike të direkt dhe të dhënat private të aksesushme me tkurrjen e metodës. Në O2 kemi: • Privat : ( implicit) që paraqet kapsulimi strikt. • Read : (opsion i mundëshëm në atribut) që paraqet kapsulimin në shkrim. • Public : pa kapsulim. Gjuha O2SQL Një bazë të dhënash “ projekt ” është përshkruar nga bashkësia e klasave në O2 si më poshtë: Class Projekt Type tuple (n_projekt:string, titull : string, buxheti : real, p_ekipi : ekipi , (ekipi i projektit) p_kërkues : set (kërkues)) (kërkuesit e projektit) end; Class Personi type tuple (emri : string, mbiemri : string, adresa : tuple (rruga : string, p_qyteti:qyteti)) end;
106
Class ekipi type tuple (emri : string, tema : string, përgjegjës : kërkues) end; Class kërkues inherit Personi Type tuple (aktiviteti : Text, punon_në : ekipi) end; Në vazhdim kryejmë deklarimet e më poshtme: Name Projekt : unique set (Projekt) Name ekipet : unique set (ekipi) Name kërkuesit : unique set (kërkues).
Jepni përgjigjet në O2SQL për pyetjet e mëposhtëme: 1. Emrat dhe mbiemrat e kërkuesve që punojnë në projekte Select tuple (w. Mbiemër, kërkuesit, emri) From w in kërkuesit. emri Type:tuple 2. Emrat dhe adresat e kërkuesve që punojnë në projektin PE2 Select tuple (emri: w. Emri, adresa: w. Adresa) From w in Person v in Projekt Where v. n_ projekti = “Pe234”. AND. 3. Emri i ekipit që siguronë projektin “PE234” dhe emrin e mbiemrin e kërkuesit përgjegjës i ekipit. Select tuple (emri_ek : w. emri, emri: v.emri, mbiemri : v. mbiemri) From w in ekipi v in kërkues Where projekte. N_projekt = “PE234” AND v. aktiviteti = “përgjegjës”. 107
4. Titulli i projektit të siguruar nga ekipi ku përgjegjës është “Beni”. Select From Where
Projekt. Titulli Projekte v in kërkuesit v emri = “Beni” AND v aktivitet = “ përgjegjës
5. Titujt e projekteve dhe numrin e kërkuesve që punojn në këto projekte. Select tuple (titulli : Projekte.titulli, numër:COUNT (Projekte. P_ekipi) From Projekte v in kërkuesit v. punon_në = p_ekipi 6. Titujt e projekteve ku punojnë më shumëç kërkues. Select tuple (titulli : Projekte. Titulli, numri : MAX (Projekte. P_ekipi) From Projekte 7. Renditja e projekteve në funksion të buxhetit që i është caktuar. Sort w in Projekte By
w. Buxheti
8. Emrat e ekipeve që punojnë në projekte për të cilat buxheti është ndërmjet 100.000 dhe 150.000 Select w. emër From w in ekipet V in Projektet Where v. buxheti > 100.000 AND v. buxheti <150.000 9. Duke marrë në konsiderat operatorin e Grupimit Group X in Z By (a1: q1, a2:q2, - - - - an, qn)
përgjigjuni pyetjes
108
Për çdo ekip mandarin global të buxhetit. Select Sum (w. buxheti) Group w in Projekte By (ekipi : w. p_ekipi) 10.
Për çdo ekip, numërin e projekteve për të cilat buxheti kalon mesataren e projekteve. Select Count (w. buxheti) Group w in Projekte By (ekipi : w. p_ekipi, buxheti: buxheti > AVG (w. buxheti)
11.
Emrat e kërkuesve dhe numrin e projekteve ku ata punojnë Select tuple (kërkuesi : kërkuesit. emri, numri: COUNT (n_ projekti) Group w in Projektet By (p_kërkues: w. kërkues)
12.
Kërkuesit që punojnë me një projekt
13.
Kërkuesit që punojnë në maksimumin e projekteve.
Projeksioni: Ku operacion qëndron në aksedimin e një ose disa atributeve të n_ëshes. Marrim me konsideratë disa raste: • Projeksioni mbi një atribut atomik: Emri i vendit bashkëshoqëruar tek V_Franca: V_Franca. Emër Tipi i rezultatit string • Projeksioni mbi një atribut jo atomik. Të gjendet adresa e kullës_eiffel Kulla_Eiffel. Adresë. Type dy rezultat : tuple( rruga: string, qyteti:qytet);
109
• Projeksioni duke përdorur navigimin ndërmjet objekteve dhe lidhjeve ndërmjet klasave. Emri i qytetit dhe adresa e kullës_eiffel. Kulla_eiffel. adresa. qyteti. emri. Tipi i rezultatit string. Përdor Monument dhe Sheshi nëpërmjet Inherit. Projeksioni mbi një atribut koleksion. Të gjithë qytetet e Francës. V_Franca. qytetet. Tipi i rezultatit set (qytet). Në atributet shumëvlerësh duhet patur kujdes. Nuk ka kuptim. V_Franca.qytet.emër. Nga ana intuitëve do të na japë gjithë qytetet e Francës (emrit). Kjo do të realizohet nëpërmjet me Select.
Përdorimi i metodave Thirrja e një metode bëhet në mënyrë klasike duke e zbatuar mbi objektin në fjalë dhe duke i dhënë parametrat. Emri i vendit bashkëshoqëruar V_Francë V_Francë. P_emër Tipi i rezultatit string. Kërkesa mbi koleksionet: Dallojmë disa kategori operacionesg mbi koleksionet: • Me marrë të gjithë koleksionin. • Seleksionimi i disa objekteve duke aplikuar një filter. • Zbatimi i operacioneve .
110
p.sh. për të marrë të gjithë koleksionin përdoren operacionet e më poshtëm Lista e të gjitha vendeve: Em_vende Type : list (vendi) Vendi i tretë :
Em_vende [2] Tipi : Vendi.
11 vendet e para
Em_vendet [0:10] Typa : list (vende).
Filtri
Select_From_Where.
Në SQL komandën e pyetjeve të të dhënave të futur në SQL, por të adaptuar me modën e objekteve. Në veçanti shprehja e disa kërkesave që në SQL bëjnë të përdoren disa bashkime bëhet më thjeshtë në modën e objekteve nga fakti se lidhjet e objekteve paraqesin bashkime implicite. Forma e përgjithëshme e bllokut të pyetjes është: Select From Where Në formën e tij të thjeshtë, filtri select i O2SQL bazohet në koleksionin e treguar pas fjalës çelës from. N.q.s. ky koleksion është një list (respektivisht një bashkësi) rezultati do të jetë një listë (respektivisht një bashkësi). O2 SQL përdor nocionin e variablit që paraqet një element të koleksionit. Fjala from mund të përcaktojë shumë variabla, secili i bashkëshoqërur një koleksioni. Froma e përgjithshme është: variabël në koleksion. p.sh.
Emrat e qyteteve të Francës Select w. emër From w in V_Franca. qyteti Tipi i rezultatit set (string). 111
Select w. emër From w in Em_qytete Where v. vendi:emër = “Francë” Tipi i rezultatit set (string). Në rastin kur kërkimi bëhet në lista ose bashkësi, rezultati është bashkësi. P.sh. Emrat e hoteleve me 2 yje në Londër Select h. Emër From w in Em_qytet. H in w. hotele Where w.emri = “Londër” and h.yje = “ ** ”. Tipi i rez . set (string). Ndërimi i n-ësheve: Është e mundur të përdoren konstruktorët e n-ësheve, për të marrë rezultate më të përpunuar. - parisi dhe hotelet e tij: tuple (emër:Paris, emër, hotele: Paris.hotele) tipi i rezultatit:tuple (emër:string, hotele:set(hotele) - Emrat e hoteleve me 2yje në Londër dhe pension komplet. Select tuple (hotel:h.emër, pension:h.pension_complet). From w in Em_qytete H in w. hotele Where w. emër = “Londër” dhe h.yje = “ ** “. Rezultati: set (tuple (hotel: string, pension:integer)
112
Operacionet mbi listat: Në mënyrë të përgjithshme O2SQL ofron operacionet e mëposhtëm mbi listat: • • • • • • • •
Kapja e elementit të i x[i-1] Kapja e elementit të parë : first (x) Kapja e elementit të fundit : last (x) Sasia e elementeve të listët : count (x) El. Më i vogël Min(x) dhe më i madhë Max(x) Shuma e elementeve sum(x) ose mesatarja avg (x) Lidhja e dy listave X dhe Y : X+Y. Lista boshe : Kist ( );
p.sh. popullsia totale e vendeve sum (select p_popullsia From p in Em_Vende); Tipi i rezultatit : integer. Operacione mbi bashkësitë: • • • • • •
Bashkimi X union Y (ose X+Y) Diferenca e dy bashkësive X exept Y (ose x-y) Prerja : X intersect Y (ose X*Y) Minimumi, maksimumi, shuma, mesatarja Kordinaliteti count (x) Bashkësia boshe set ( )
p. sh. Emrat e qyteteve që kanë më shumë se 5o hotele Select w. emër From w in Em_qytet Where count (w.hotele) > 50 Tipi rez: string. Çmimi që duhet paguar për të vizatuar kullën _eiffel
për 7 persona:
7*(( kulla_eiffel.tarifa)+ (element (select m.tarif from m i Monumentet_e_Parisit. Where m.emri = “Harku i Triumfit “ ))) Rezultati : integer.
113
Quantifikatorët: • Exist x in y : p(x) Jep True n.q.s. tëpaktën një element i listës ose i bashkësisë kënaq predikatin p. p.sh. A ka ndonjë vend ku ka më shumë se 50 qytete për të vizatuar: exist p in Em_Vende : Count (p.qytete) > 50 rezultati i boolean •
Forall x in y :p(x)
Jep true n.q.s. të gjithë elementet e bashkësisë ose listës kënaqin predikatin p. p.sh. Shëtitjet në Paris ku është e mundur të shohësh të gjitha vendet e vizitueshme: Select t From t in Paris.shëtitje Where forall m in Monumentet eParisit: m in t.vende Rezultati set (shëtitje). Renditja Forma e përgjithëshme e operacionit të renditjes është si më poshtë: Sort x in z by f1, f2, - - - -,fn. Ku f1,f2, - - - -,fn janë kërkesa ku çfaqet x si variabël dhe z si një bashkësi. Rezultati është një lisrë që përmban gjithë elementet e z. Kjo listë është renditja sipas çelësave të dhënë në fi. p.sh. Renditim qytetet sipas vendeve dhe sipas rendit alfabetik të emrave në çdo vend. ( 2 kutere). sort w in Em_qytete by w.vende, v.emër. rezultati : listë e qyteteve.
114
Grupimi Group x in z By (a1:q1,a2:q2, - - -,an:qn) q1,q2, - - -qn janë kërkesa x,z. Ndarja bëhet si kërkesave të by. p.sh.
Rigrupo qytetet sipas shteteve group w in Em_qytete by (vende: w. vende) Baza e të dhënave:
Për të ilistruar operacionet ne supozojmë se kemi një bazë të dhënash të një agjensie udhëtimi të përcaktuar si më poshtë: Class vendi Type tuple (emër: string, public kryeqiteti:qytet, public popullsia : integer, qytetet : set (qytet))
Class qytet type tuple (emër:string public popullsia:integer shteti : vendi public vendet_vizitë:set (place) public hotelet:set (hotel) method write public shëtitjet : set (shëtitje)) public w _qytetet (c:qytete)method. public r_qytete:set (qytet) public w_shteti (c:vendi), public w_emri (c:string) public r_shteti : vendi public r_emri :string end; end;
Class sheshi type tuple (emri:string emri_anglisht:string, read foto : bitmap read përshkrimi : string, adresa : tuple (rruga: string Class qyteti: qytet public tarifa I integer) end;
Class Monument inherit sheshi type tuple (shekulli : integer, ditët t mbyllura : list (string)) end; Muze inherit sheshi type tuple (ditë_vizitë:list(string) specialiteti : string end;
115
Class Hotel type tuple ( public emri : string, yjet : string mëngjez:integer gjysëm_ pension: integer komplet_ pension : integer adresa : string, qytetet : qytet) method
Class Shëtitje type tuple (emri : string: shshet : list (sheshi)) method end;
end;
Në proçesin e konceptimit të OO ekzistojnë mënyra e deklarimit të objekteve persistente nëpërmjet shprehjes name. p.sh. name Em_vende : list (vendi); name Em_qytete : list (qytet); name Monumentet_e_Parisit : set (Monument); name Qyt_Monument : set (qytet); name Muzetë : set (Muze); name Em_sheshe : set (sheshi); Përveç këtyre veçojmë dhe objektet e mëposhtëm (për arsye spjegimi) constant name V_Franca : Vendi; constant name Paris : qytet; constant name Romë : qytet; constant name kulla_eiffel: Monument:
116
Lidhur me veprimin JOIN kemi folur të gjithë produktet quhen inner për ojoin. Ky veprim paraqitet dhe në format outer join, e cila ka dy paraqitje: Left outer join dhe right outer join. Left outer join – merr rreshtat në tabelën e parë, bashkohen me të dytës pa çiftim KLIENT KOD_KLI 1132445 1217782 1312243 1321242 1542311 1657399
AGJENTI MBIEM_KLI MALI FUSHA SHKËMBI ARA DETI PYLLI
ZIP_KL I 32145 37134 34129 37134 37134 32145
KOD_AGENT 231 125 167 125 421 231
KOD_AGJENT
AGJENT_PHONE
125 167 231 333
6152439887 6153426778 6152431124 9041234445
Natyral join: KOD_KLI
MBIEM_KLI
ZIP_KLI
KLI_KOD_AGET
AGENT.AGENT_KODE
12217782
FUSHA ARA SHKËMBI MALI PYLLI
32145 37134 34129 32145 32145
125 125 167 231 231
125 125 167 231 231
1321242 1312243 1132445 1657399
Left outer join KOD_KLI 12217782
1321242 1312243 1132445 1657399 1542311
MBIEM_KLI
FUSHA ARA SHKËMBI MALI PYLLI DETI
AGENT_PHONE
6152439887 6152439887 6153426778 6259431124 6152431124
= ZIP_KLI
32145 37134 34129 32145 32145 37134
KOD_AGENT
AGENT_PHONE
125 125 167 231 231 421
6152439887 6152439887 6153426778 6259431124 6152431124
I pa përcaktuar RIGHT JOIN KOD_KLI
MBIEM_KLI
ZIP_KLI
KOD_AGENT
AGENT_PHONE
117
12217782
1321242 1312243 1132445 1657399
FUSHA ARA SHKËMBI MALI PYLLI
32145 37134 34129 32145 32145
125 125 167 231 231 333
6152439887 6152439887 6153426778 6259431124 6152431124 9041234445
Përdorni databazën e vogël më poshtë për të vënë në dukje diferencën ndërmjet: natyral join equi joi (o – join) outer join STUDENT
PROFESOR
KOD_STUD KOD_PROF 100278 128569 2 512272 4 531235 2 531235 553427 1 KOD_PROF KOD_DEPT 1 2 2 6 3 6 4 4
Natural Join KOD_STUD 128569 512272 531235 553427
STUD_KOD_PROF PROFESOR)KOD)PROF KOD_DEPT 2 2 6 4 4 4 2 2 6 1 1 2
Left outer join KOD_STUD 128569 512272 531235 552427 531235
KOD_PROF 2 4 2 1
KOD_DEPT 6 4 6 2
Right outer join 118
KOD_STUD 128569 512272 531235 552427 531235
KOD_PROF 2 4 2 1 3
KOD_DEPT 6 4 6 2 6
2. Ndërtoni doagramën E-R • Supozojmë se kemi mdelin E-R SHOFER
drejton
MAKINË
119
Shoferi nga shumë makina në ndryshime dhe një makinë drejtohet nga shumë shoferë Si mundë ta konvertoni këtë në relacionë 1:M.
Le të marrim në konsideratë shumën relacionale si më poshtë: LLOGARIA Emri_degës SHKOZET LABINOT LAPRAKE KOMBINAT QENDËR KURBIN PLAZH
Numri_Llogarisë A – 101 A – 215 A – 102 A – 305 A – 201 A – 222 A - 217
DEGA Emri_degës SHKOZET LABINOT LAPRAKE KOMBINAT QENDËR KURBIN PLAZH
Qyteti_degës DURRËS ELBASAN TIRANË TIRANË TIRANË LAÇ DURRËS
Bilanci 500 700 400 350 900 700 750
Asetet 9.000.000 2100.000 1700.000 400.000 8.000.000 300.000 7.100.000
KLIENT EMER_KLIENT JULIAN SAIMIR HALIM LUAN FATMIR TAULANT ALBAN
RRUGA_KLIENT KRYESORE ELBASANIT KRYESORE ELBASANIT 4 SHKURTI GORICË KOMBINAT
QYTETI_KLIENT DURRËS TIRANË DURRËS TIRANË TIRANË BERAT ELBASAN
120
DEPOZITUES EMRI_DEPOZITUES NUMRI_LLOGARISË SAIMIR A_101 HALIM A_215 FATMIR A_305 TAULANT A_217 HUA EMRI_DEGËS SHKOZET LABINOT LAPRAKE KOMBINAT QENDËR KURBIN PLAZH
KODI_HUASË H_17 H_23 H_15 H_14 H_93 H_11 H_16
HUAMARRËS EMËR_KLIENTI JULIAN SAIMIR ASTRIT LUANI BES AGRONI
MANDATI 1000 2000 1500 1500 500 900 1300
KODI_HUASë H_17 H_23 H_15 H_14 H_93 H_16
121
Përdorni databazën e treguar më poshtë për t’iu përgjigjur pyetjeve. PRODUKT KOD_PRODUKT
12_WWWP2 1QQ23_55 231_78_W 335 64 AJ AR/31/TYR DT_34_WWW EER_67/W ER_56/DF FRE_TRYS SE_67_85 ZW_QR/AV ZX_VRFJR
PËRSHKRIM_PRODUKT
DATA_STOKUT_PROD
PROD_NË_DORË
PRODH_ÇMIM
KODI
07_04_02 19_03_02
12 123 45 18 8 11 9 7 87 34 14 15
50 100
123 123 121 123 121 123 121 125 125
SHITJE KOD_SHITëË
120 121 122 123 124 125
EMER_SHITJE SHITE_KONTAKTI KODI_ZONËS_SHIT PHON_SHIT
Arben Mali
615
8P5_124
1. Për çdo tabelë identifikohni çelësin primar dhe çelësin e jashtëm. N.q.s. tabela nuk ka çelës të jashtëm shkruani “asgjë” 2. Vizatoni diagramin e lidhjes. 3. Vizatoni skemën relacionale. 4. Formuloni 5 pyetje dhe përgjigjuni në gjuhët algjebrike.
122
