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ët9. 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) Struktura e Db

Përdoruesi Të dhënatfundor

Të dhënat e Të dhënat 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

DBMS

Metadata

Klientët

Produktet

Shërbimet

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 55 4 273394   36123 Arjan Tirana 52 2 321456 T1 $100  Besnik Skembi 52 2 456920   25246 Elton Durësi 56 3 412123 T1 $250  Agron Deti 55 4 719412   36123 Arjan Tirana 65 7 721892 T2 $150  Skender Kodra 56 7 920032   36123 Arjan Tirana 52 2 622321 S1 $300  Vera Fusha 89 5 420012   36155 Elton Durësi 52 3 451154 T1 $100  Petrit Degoi 52 2 125983   25246 Xhim Kovça 55 4 721182 T2 $850  Luan Curi 65 4 654322   37118 Arjan Tirana 65 5 921128 S1 $120  Alma Ferra 89 5 652421   37119 Xhim Kovça 66 3 425126 S1 $250  Genti Ullari 78 6 189124   25432 Elton Durësi 55 4 645133 T2 $100  Monda Dardha 67 7 254125   37118 Xhim Kovça 52 3 654331 S2 $100  

Legjenda: K_EMËR : Emri i klientit A_EMËR : Emri i Agjentit K_PHONE : Numri i telefonit A_PHONE: Numri i telefonit të

agjentit të klientit TP : Tipi i sigurimit K_ADRESE: Adresa e klientit AMT : Mandati i sigurimit K_ZIP : Kodi ZIP i klientit REN : Data e renovimit të

sigurimit

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ë.

5

Departamenti i shitjes

Programet e administrimit të skedarëve Raportet

Skedari KLIENT

Skedari SHITJE

Programet e administrimit të skedarëve Raportet

Departamenti i personelit

Programet e administrimit të skedarëve

RaportetSkedari Agjent

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 kontrolluaraSë pari: hapsira e kujtesës shpenzohet shpejtSë dyti: të njëjtat të dhëna regjistrohen disa herëSë treti: paqëndrueshmëria (njëri ekorigjon tjetri jo)

2. Mungesa e elasticitetitNuk 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 programimitDuhet 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. relacionale1990: B.D. objekt2000: 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ë

Tre pamje përdoruesish të ndryshme.

12

Klientat Klientat

Porositë Porositë Dërgesat

Klientat

Klientat

Klientat

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ë.

Niveli konceptial Niveli i brendshëm

Skema e brendshme

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

NdërfaqësiPërdoruesi/Sistem

SQBDHUdhëzuesi

Fjalorit të të dhënave

Administrimi Bazave të të

Dhënave

Baza e të dhënave

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:

FurnizuesiNum_Furnizuesit Emri Qyteti

F1 Arben DurrësF2 Luan TiranëF3 Besnik TiranëF4 Dritan DurrësF5 Ermir Elbasan

Pjesa Furnizimi

Me të dy relacionet.Shënimet e këtij operatori çfaqen në disa forma:

R3 = R1UR2R3 = UNION (R1, R2)R3 = APPEND (R1, R2)

Num_Pjesë Emri PjesësP5 VideP1 DadoP18 Bulon

Num_Furnizuesit Num_PjesësF1 P1F2 P18F3 P5F4 P18F5 P18

17

Me këtë rast përbërësit e R1 dhe R2 janë identike dhe rezultati R3 ka po ata atribute.

P.sh.:

R1 R2Furnizimi Furnizimi 2

R3 = Furnizues1 U Furnizues 2

Furnizimi

Num_Furnizuesit Num_PjesësF1 P1F2 P18F8 P18F3 P5F2 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 Seleksioni (Furnizues, Num_pjesës=P5)

Num_Furnizuesit Num_PjesësF1 P1F2 P18F5 P18

Num_Furnizuesit Num_PjesësF3 P5F1 P1F2 P18

Num_F Emri Num_PjeseF1 Arben P5F2 Luan P5F3 Besnik P5

Num_F Emri Num_PjeseF1 Arben P5F2 Luan P5F3 Besnik P5F1 Arben P1F2 Luan P1F3 Besnik P1

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-

Shënime: R3 = JOIN (R1, R2 kandita).

p.sh.:

F1 F2

JOIN (F1, F2, F1. NUM-F =. NUM –F)

Num-F Emri Num-PjeseF1 Erban P1F1 Arben P18F2 Luan P5

Bashkimi pa kondit korespondon me prodhimin kortezian

PrerjaOperacioni 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 R2R3 = AND (R2, R2)R3 = INTERSECT (R1, R2)

Num_ F EmerF1 ArbenF2 LuanF3 Besnik

Num_F Num_PjeseF1 P1F1 P18F2 P5

19

p.sh.

Furni. 1

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 antiprojeksionitR1 = Antiprojeksion (R, s).

p.sh.

FURNIZIMNum_Furnizuesi Num_ Pjese

F1 P1F2 P18F1 P5F3 P5F1 P18F5 P18

Num_F Emri QytetiF1 Arben DurrësF3 Besnik TiranëF4 Fatmir Durrës Num_F Emri Qyteti

F1 Arben Durrës

F3 Besnik Tiranë

Num_F Emri QytetiF1 Arben DurrësF2 Luan TiranëF3 Besnik Tiranë

20

R1 = FURNIZIM ] NUM_FURNIZUESI[Fusha e përcaktimit NUM_PJES = (P1, P5, P18)

R1 NUM_FURNIZUESI

F1.

Pjestimi – jep njëshet që realizojnë rezultatet në vlerat e dhëna për n-ëshet e zgjedhura.P araqitja:

R1 = R SR1 = DIVIDE (R, S)

p.sh.

FURNIZIM

SNum_Furnizuesi Num_Pjese

F1 P1F2 P18F1 P18F5 P5

R1 = FURNIZIM S

Funksionet e llogaritjesMundë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ë.

Num_Pjese

P1

P18

Num_FurnizuesiF1

21

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-ëshatRezultati = Projeksion (R1, Em_Pjese). Jep listën e emrave

Agregatet

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 relacioniFURNIZIM (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

FLUTURIMETNumri. Flut. Origjina DestinacioniBA533 Napoli Lohndë GKBA528 Londër A PisaKG2544 Verona Londër GKKG2540 Venecia/MP Londër GKKG946 Venecia/MP MançesterBR382 Londër/GK Kai – TakBA019 Londër/HW Kai – Tak

AEROPORTET NDALIMET

Përgjigjuni pyetjeve në SQL:1. Cilat aeroporte janë në Angli?2. Cilat aeroporte mund të kapen nga Pisa?3. Cilat udhëtime kanë më shum se 2 ndalime?4. Në cilat vende ndalon BA 768?5. Cilat fluturime fillojnë nga një aeroport Anglez?6. 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 SHIJAFROM VERËWHERE GRADA >13 UNIONSELECT SHIJA

FROM VERËWHERE VITI_PRODH = 1997.

Emër_Aeroporti Emër vendiNapoli ItaliLondër/ GK AngliLondër/ GK AngliPisa ItaliVerona ItaliVenecia/ MP ItaliMançester AngliKai - Tak Hong - Kong

Numri_fluturimeve

Emër_Aeroporti

Numri Ndalimit

BR 382 Dubai 1BA 019 Dubai 1BA 019 Shangai 2

23

5. Të llogaritet grada mesatare e “Chablis”.

SELECT AVG (GRADA)FROM VEREWHERE SHIJA = “CHABLIS”

6. Të gjenden të gjitha kodet e verërave që janë pirë nga më shum se 100 vetë.

SELECT NVFROM ABUZIVGROUP 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, NVFROM VERËWHERE VITI_PRODH: 1997

AND GRADA > 13OP.DERED BY SHIJA, ASC, NV DESC.

3. Emrat e pijetarëve që kanë pirë Chablos. (3 mënyrë)

I. SELECT UNIQUE EMRIFROM PIJETAR, VERË, ABUZIVWHERE PIJETAR, NP = ABUZIV, NPAND ABUZIV, NV = VERË, NV.AND VERE, SHIJA. = “ Chablis”

24

II. SELECT UNIQUE EMRIFROM PIJETARWHERE NP IN

(SELECT NBFROM ABUZIV. NV = VERË. NVAND VERË. SHIJE = “CHABLIS”).

III. SELECT UNIQUE EMRIFROM PIJETARWHERE. NP. IN

(SELECT NPFROM ABUZIVWHERE NV. IN(SELECT NVFROM VERËWHERE SHIJA = “Chablis”).

4. Të jepet shija e verërave të gradës mbi 13 ose të prodhuara në vitin 1997.

SELECT SHIJAFROM VERËWHERE GRADA > 13

UNIONSELECT SHIJAFROM 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 NVFROM ABUZIVGROUP 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

Pjesa Furnizimi

Kolonat janë quajtur atribute.Ç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.

Kod_furnizuesi Emri QytetiF1 Arben DurrësF2 Luan TiranëF3 Besnik TiranëF4 Dritan Durrës F5 Ermir Elbasan

Kod_Furnizuesi Kod_PjesëF1 P1F2 P18F3 P5F4 P18F5 P18

Kodi_Pjesës Emri_Pjesës SasiaP5 Vidë 100P1 Dado 50P18 Bulon 150

27

- Ç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

Ç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ë:

StudentStud_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ËRNë 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.

28

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).

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.

PRODUKTKOD_PROD PËRSHK_PROD ÇMIM_PROD COD_SHITËSI001278-AB SHEQER 65 23212321UUV VERË 250 235QER.34256 VAJ VEJETALL 170 231SRE. 657UG TAPETË 6500 232ZZX. 324Q 800 235SHITËS

29

KOD_SHITËSI EMËR SHITËSI KODI_ZONËS_SHITËSIT PHON_SHITËS230 Arben Mali 608 555_234231 Vera Shkëmbi 615 123_536232 Gent Deti 608 224_194233 Arjan Kodra 904 342_656234 Mira Pasha 615 123_324235 Gëzim Pylli 615 899_425

Ç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.

30

Sistemi i bazave të të dhënave

Dept.PersonelitDept. ShitjesDept. i financave

DBMS

Database

PunënjësitKlientëtShitjetInventariLlogaria

Sistemi i skedarëve

Dept. Personelit Dept. Shitjes Dept. Financës

Punonjësit

Komplementet e mjedisit të bazave të të dhënave

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ë

31

Klientët Shitjet Inventari Llogaria

Ndërfaqësi përdorues(sistem)

Fjalori i të dhënave

Administrimi i BDh

SQBh BDh

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.

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

32

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:

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

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ëri-tjetrin. 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

Single Tier

Use srvice Client, Peer Business Services ose server

Data services

GUI

Presentation Logic

Busines Logic

Data Acces Logic

DBMS

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

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.

Thin client/fat server.

36

Tow-tier fat client/thin Server

User ServicesClient

Business Services

Server Data Services

GUIPresentation Logic

Business Logic

Data Access Logic

DBMS

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.

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/serverDuke 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 tier ose siç quhet three-tier client/server.

Three-tierKjo 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ë.

37

Two-tier thin client/fat Server

User Services Client

Busines Services Server

Data Services

GUI

Presentation Logic

Busines Logic

DBMS

Data Access Logic

Threetier Client/Server

User Services Client

Aplication Business Services Server

Database Data Services Server

GUI

Presentation Logic

Business LogicData Access logicData Access LogicDBMS

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.

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.

38

Multi-tierNë 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ë 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

39

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 të vogla. P.sh. pikturon, punon për, prodhon

40

Duke u nisur nga shpnimet e mësipërme PIKTOR dhe PIKTURË do të paraqitet në modelin E_R më poshtë

Modeli Crow’s Foot. Modeli Chen

Pikturon

Fig. Lidhjet ndërmjet PIKTOR dhe PIKTURA.

Orientimi i ERD nuk është material. Lidhjet e mësipërme mund të paraqiten

pikturon

1 M

Fig. Paraqitja alternativë e modeleve.

Një paraqitje konkrete e lidhjeve të mësipërme.

41

PIKTORI

PIKTURA

PIKTORI

pikturon

PIKTURA

PIKTORI PIKTURA

PIKTURAPIKTORI pikturon

PIKTORI

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

Modeli Chen

1 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_BOLEGJEmri i tabelës: KURS.Çelësi primar: KURS_KODÇelësi i jashtëm: s’kaKURS_KOD DEPT_KOD KURS_PERSHK KURS_KREDIT

KODI_PIKTORI EMËR_PIKTORI

123 Luan

126 Besnik Kodi_Pikturës Titulli_Pikturës Kodi_Piktorit

1338 1231339 1231340 1261341 1231342 123

42

KURS KLASË

KLASËKURS ka

ACCT_211 ACCT Accounting I 3ACCT_212 ACCT Accounting II 3

CIS_220 CIS Hyrje në informatikë 3CIS_420 CIS Database Design 4QM_261 CIS Hyrje në Statistikë 3QM_362 CIS Aplikime të Statistikës 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ë Klase_Sallë Prof_Num18012 ACCT_211 1 HMP

8-8:50amA-311 105

10013 ACCT_211 2 HMP 9-9:45AM

A-200 105

10014 ACCT_211 3 ME 2:30-2:45pm

A-252 342

10015 ACCT_212 1 HMP 10-10:50am

A-311 301

10016 ACCT_212 2 E 6-8:40pm A-252 30110017 CIS_220 1 HMP 9-

9:50amB-209 228

10018 CIS_220 2 HMP 10-10:50am

B-211 114

10019 CIS_220 3 M 6-8:40 pm B-209 22810020 CIS_420 1 HMP 8-

8:50amB-209 162

10021 QM_261 1 ME 1-2:50pm B-200 11410022 QM_261 2 HMP 11-

12:50pmB-200 114

10023 QM_362 1 ME 2:30-3:45pm

B-200 162

10024 QM_362 2 HMP 10-10:50 am

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

ndjek

Modeli Chen

M 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ËMBIAccounting 1, ACCT-211, CODE 10018, Hyrje në Informatikë, CIS-220, CODE 10018, Hyrje në Statistikë, QM-261, CODE 1002.

MALIAccounting 1, ACCT-211, CODE 10018, Hyrje në Informatikë, CIS-220, CODE 10018, Hyrje në Statistikë, QM-261, CODE 1002.

Ky relacion mund të paraqitet në formë tabelare si në figurën në vazhdim.

Emri i Databazës CH2-TEXT

44

KLASË

KLASËSTUDENT ndjek

STUDENT

Emri i tabelës STUDENTSTUD_KOD MBIEMRI KLASE_KOD

321452 SHKËMBI 10014321452 SHKËMBI 10018321452 SHKËMBI 10021324257 MALI 10014324257 MALI 10018324257 MALI 10021

Emri i tabelës KLASËKlasë_kod Stud_kod Kurs_kod Klase_seksion Klasë_orë Kasë_sallë Prof_kod10014 321452 ACCT-

2113 HM 2:30-

3:45pmB 201 342

10014 324257 ACCT-211

3 HM 2:30-3:45pm

B 201 342

10018 321452 CIS-220 2 HEP 9-9:50am

A 112 114

10018 324257 CIS-220 2 HEP 9-9:50am

A 112 114

10021 321452 QM-261 1 HEP 3-9:50am

C 305 114

10021 324257 QM-261 1 HEP 3-9:50am

C 305 114

FatmirësishtNe 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

kryen

Diagrama E-R e rreshtuar :2 relacionale 1:M

Gjendet në bën pjesë në

Modeli Chen

1 M N 1

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

KLASËSTUDENT

STUDENT REGJISTRIM KLASË

KLASË

KLASËSTUDENT Regjistrmi

STUDENT gjendet

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

Modeli Crow’s Foot

Fig. Atributet e njësisë STUDENT në dy modelet.

STUDENTEMËR_STUDMBIEMËR_STUDSTUD_INITSTUD_EMAILSTUD_PHONE

47

STUD_INIT

MBIEMER_STUD STUD_EMAIL

EMER_STUD STUD_PHONE

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.

gjeneron

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ë.

gjeneron O

shënim: O – do të shihet më vonë.

KURSKO_KURSKOD_DEPTPËRSHK_KURSKREDIT_KURS

KLASËKOD_KLASËSEKSION_KLASËKURS_KOD (FK)ORË KLASË

KLASËSEKSION_KLASËKURS_KODORË_KLASË

KURSKURS_KODKOD_DEPTPËRSHK_KURSKREDIT_KURS

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.

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ë. <egjithatë KLASË duhet të krijohet apo kursi është krijuar.

PROFESOR

50

KLASË

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 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 1 M

O (0,N) (1,1)

KOD_PUN KOD_PUNEM:R_PUN opsionale (e detyrueshme KOD_VARMBIEMËR_PUN (min. 0) min. 1) EMËR_VARINIT_PUN DLIN_VARDLIN)PUN

51

KURS KLASË

PUNONJËS Ka

TË_VARUR

Crow’s Foot model

Ka 0

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

Unore Binare Ternare

Modeli Crow’s Foot

52

PUNONJËSKOD_PUNEMËR_PUNMBIEMËR_PUNINIT_PUNDLIN_PUN

TË_VARURKOD_PUNKOD_VAREMËR_VARDLIN_VAR

PUNONJËS PROFESOR

martuar

mëson

KLASË

Kontributor KFM MARRËSI

FOND

mëson

Unare Binare

Kontribon për merr nga

I shpërndarë

Ternare

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

martesa1

Lidhja një-disa: Le të shohim lidhjen administrim në skedarin punonjës.

53

PUNONJËSPROFESOR KLASE

KONTRIBUTOR KFM Marës

FOND

PUNONJËS

1

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:

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

N artikull

Në figurën në vazhdim, po japim dy ndodhje të kësaj strukture.

54

PUNONJËS

TOMI

GENCIANA DITI

TOMI INA GRIDI

MARIJA

SUELA MERIFREDI

TOMI TOMI TOMITOMI

DETA 2

A

Y Z

B

V X

U V

YX

U V V W

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 NGJYRATIPI MARKATIPI 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 N.q.s. Y X rrjedh që XY

55

Një bashkësi përcakton vetveten ose një pjese të saj.

2. Shtimi:N.q.s. XY sjell XZYZPra të dy përbërësit mund të pasurohen me një të tretë.

3. TranzitivitetiX 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 DirekteNjë 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 direkteNr_Shitësi Emër_shitësi direkteNr_Fature Emër_Shitësi 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. Kërkohen VF me anë t majtë të kompozuar elementare dhe direkte.

56

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

Kanë grupe të përsëritin

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 kolonaSTUDENT# EMER_

STUDDREJTIMI_KRYESOR

KURSI# TITULLI_KURSIT

EMRI_INSTRU_KTORIT

VENDI_ENSTRU_KTORIT

GRADA

42125 ARBEN IS IS350IS465

DATABASESYSANAL

CODTKEMP

B104B213

AC

68134 LUAN PM IS465PM300QM440

SYSANALBIZNESKERKOP

KEMPLEVISKEMP

B213B317213

ABC

Fig. 7.2 Shembull relacioni të panormalizuar

58

Pamjet e përdoruesve

Relacionet e panormalizuara

Rel. Normaliz.1

Rel. Normaliz.2

Rel. Normaliz.3

Hiqen grupet e përsëritur

Hiqen varësitë e pjesëshme

Hiqen varësitë tranzitive

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:N1:1

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

STUDENTSTUDENT# EMER_

STUDENTDREJTIMI KRYESOR

3821 ARBEN IS69173 LUAN PM. . .

STUDENT-KURS

59

STUDENT EMËR_STUDENTI

DREJTIMI KRYESOR

KURSI# GRADA

KURSI# . . . . . . . GRADA

STUDENT# KURSI# TITULLI_KURSIT

EMRI_INSTRUKTORIT

VENDI_INSTUKT.

GRADA

38214 IS350 DATABASE CODD B104 A38214 IS465 SYSANAL KEMP B213 C69173 SI465 SYSANAL KEMP B213 A69173 PM300 PRODMGT LEVIS D317 B69173 QM400 OPRES KEMP B213 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. 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.

2. 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

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ë KURSIKëto atribute pjesërisht të varur nga çelësi primar.

Forma e Dytë NormaleNjë 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

TITULLI KURSIT

EMRI INSTRUKTORIT

VENDI INSTRUKTORIT

STUDENTI

KURSI#

GRADA

STUDENT_KURSSTUDENT# KURSI# TITULLI_

KURSIEMËR_

INSTRUKTORIVEND_

INSTRUKTORIGRADA

REGJISTRIMI

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:

KURSI# TITULLI_KRYESOR

EMRI_INSTR.

VENDI_INSTR.

IS350 DBASE COOD B104IS465 SYSANAL KEMë B213PM300 PRODMGT LEWIS D317QM440 OPRES KEMP B213

STUDENT KURSI# GRADA38214 IS350 A38214 IS465 C69173 IS465 A69173 PM300 B69173 QM440 C. . . .

62

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.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ë:

A

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ë NormaleRelacioni ë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:

. . . . . . . .

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

63

Çelës primar B

Çelësi primar Atributi 1 Atributi 2 Atributi n

KURS INSTRUKTORI

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 INSTRUKTOR

KURS REGJISTRIMI Fig. 7.2. Relacionet në formën normaleForma Normale Boyce Codd (BNCF)

KURSI# TITULLI_KRYESOR

EMËR_INSTRUKTORI

VEND_INSTRUKTORI

KURSI# TITULLI_KURSI

EMËR_INSTRUKTORI

IS350 DBASE CODIS465 SYSANAL KEMP

PM300 PRODMGT LEVISQM440 OPRES KEMP

EMËR_INSTRUKTORI

VEND_INSTRUKTORI

COOD B104KEMP B213LEVIS B317

STUDENT# EMËR_STUDENTI

DREJTIMI_KRYESOR

38214 ARBEN IS

69173 LUAN PM

EMRI_INSTRUKTORIT

VENDI_INSTRUKTORIT

CODD B104

KEMP B213

LEVIS D217. . . .

STUDENT# KURSI# GRADA38214 IS350 A38214 IS465 C69173 IS465 A69173 PM300 B69173 QM440 C

. . . . .

KURS# TITULLI_KURSIT

EMRI_INSTRUKTORIT

IS350 DBASE CODD

IS465 SYSANAL KEMP

PM300 PRODMGT LEWIS

QM440 OPRES KEMP

. . . . .

64

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_UDHSTUDENT# DREJTIMI UDHËHEQËSI

234 FIZIKË AJNSHTAJN

234 MUZIKË MOXART

546 BIOLOGJI DARVIN

879 FIZIKË BORI

985 FIZIKË AJNSHTAJN

(a) (b)

ST_UDH UDH_DR

UDHËHEQËSI DREJTIMIAJNSHTAJN FIZIKË

MOXART MUZIKË

DARVIN BIOLOGJI

BORI FIZIKË

(c)

Fig 7.8 Forma BCNF (a) relacioni në 3NF(b) diagrama e varësisë(c) 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.

STUDENT# UDHËHEQËSI234 AJNSHTAJN234 MOXART546 DARVIN879 BORI989 AJNSHTAJN

65

STUDENT#

DREJTIMI

UDHËHEQËS

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

Në këtë relacion:

NS KURSI sporti

100 Baza të dhënash Tenis100 Baza të dhënash Futboll

200 Baza të dhënash Çiklizëm

200 Matematikë çiklizëm

66

NS – kodi i studentitKURSI – kurset e ndjekuraSPORTI – 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= 100

X NS Y = Baza të DhënashY KURSI Z = TenisZ SPORTI Y’ = Baza të dhënash

Z’ = Futboll

X Y Z X Y’ Z’(100, Baza të Dhënash, Tenis) (100, Baza të dhënash, Futboll) X Y’ Z X Y Z’ (100, Baza të dhënash, Tenis) (100, Baza të dhënash, Futboll)

X Y Z X Y’ Z’(200, Baza të Dhënash, Çiklizëm) (200, Matematikë, Çiklizëm)

67

X Y’ Z X Y Z’ (200, Matematikë, Çiklizëm) (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 : (XY) (X R-X-Y)2. Tranzitiviteti: (XY) dhe (YZ) (XZ) 3. Bashkimi : (XY) dhe (XZ) (XYZ).

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 XY e një relacioni R është elementare n.q.s.:

1. Y nuk është bosh dhe nuk pritet me X2. 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 AVIONNF 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 elementareNSKURSINS 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.

OFERTEOFERTE

KURSI INSTRUKTORI LIBRIMS_DOSMS_DOSMS_DOSMS_DOSMS_DOSMS_DOSDBASEDBASE

ILIRIARJANIPETRITIILIRIARJANIPETRITIMPZAMOZA

ARBENARBENARBENFATIFATIFATIARIGENTI

69

(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.

MËSUESI LIBRIFig. 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.

Forma të tjera normale:

KURSI INSTRUKTORI LIBRIMS_DOS ILIRI

PETRITIARJANI

ARBENFATI

DBASE MOZA ARIGENTI

KURSI LIBRIMS_DOSMS_DOSDBASEDBASE

ARBENFATIARIGENTI

KURSI INSTRUKTORIMS_DOSMS_DOSMS_DOSDBASE

ILIRIPETRITIARJANIMOZA

70

KURSI INSTRUKTORI LIBRI

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,<KODIPUNËS,#VITE>)c) PUNONJËS(PUNONJËS#, EMËRPUNONJËSI, KODIPUNËS,PËRSHKRIMPUNE.)d) PUNONJËS(PUNONJËS#, EMËRPUNONJËSI, PROJEKT#,ORË_PUNE.)

2. 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 FUTBOLL

PUN# KURS

PUN# 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. Ç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.

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 POZICIONI TRAJNERIBENI SM NIKUGIMI P EDITONI SM PJERNIMIRI QM GONITIMI SM NIKU

71

Ç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)

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 LanguageDML – 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 studentitEmër_s – emrin e studentitMosha - moshe e studentitQyteti - qyteti i banimit.

72

Departamenti

Punonjësi Projekti Zyra

Detyra

Historiku i pagës

Telefoni

NDJEK (Kod_s, kod_mod, n_mes)

Kod_s : kodi i studentitKod_mod : kodi i modulitN_mes : nota mesatare

KURS (kod_mod, titulli, përgjegjësi)

Kod_mod : kodi i modulitTitulli : emërtimi i kursitPë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 type (gjatësia) [kufizimet];atributi 2 type (gjatësia) [kufizimet];- - - - - - - atributi n type (gjatësi) [kufizimet];

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).

73

Tipi p.sh. mund të jetë:

Char (n) – ku n jep gjatësinë e vargut të karaktereveNumeric (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:

Heq të gjitha të dhënat duke pastruar dhe strukturën e tabelës.

Krijimi i indeksit:

Krijoni indeksin në një tabelë kur proçesin emrin dhe atributet për të cilat kërkojmë të gjenerojmë indeks.

Heqja e indeksit 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,---

2. Alter Table Emër_tabele p.sh. Shtimi: ALTER TABLE PRODUCT ADD(atributi tipi) ADD(P_SALLECODE CHAR(I);

Modif: ALTER TABLE PRODUCT MODIFY(P_PRICE-DECHAL(3,C))

74

Drop table emër_tabele;

Create index emër_indeksi on emër_table (kdone1....)

Drop index

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ë.

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ë:

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

Insert into emër_tabele [(kolonë1, kolonë2, - - - kolonën)]Values (V1, V2, - - -Vn)

Update emër_table set cdone1=vlerë1, - - - - [where kondite]

Komandat e seleksionit të të dhënave

Blloku i kualifikimitStruktura 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 atr1, atr2, - - -,atrn.

From Emër_tabele.Where <konditë>

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 * Select X1, X2, - - -,Xn

From Emër_tabele From Emër_tabele.Wherë Konditë 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_sFrom NdjekWhere 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_sFrom StudentWhere 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_sFrom StudentWhere 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_sFrom StudentWhere 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, qytetiFrom StudentWhere 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ërFrom STUDENTWhere 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ësAvg – mesatarjaMax – maksimumiMin – MinimumiCount – 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 NdjekWhere 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 StudentGroup by qyteti Krijon relacion të ri.

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 StudentGroup by qytetiHaving count (*) > 10 funksioni i llogaritjes.

Blloqet e kualifikimit që shtrëngohen

Një konditë mund të përmbajë një bllok tketër

Shembull: Emrat e studentëve që banojnë në të njëjtin qytet me studentin “Arben”

Select Emër_s From Student.

From StudentWhere 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_mesFrom Student NdjekWhere 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<nënblloku> ë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.

qyteti Sasia

--

2030

79

- Kondita foALL <nënblloku> ë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_sFrom StudentWhere Qyteti = ‘Tiranë’

AND mosha <ANY (Select mosha From Student Where qyteti = ‘Durrës’);

Plotësohet pa ndonjë rast.Sigurisht do të jetë më i vogël sa maksimumi.

Shembull: Studentin më të ri të Tiranës.

Select Emër_sFrom StudentWhere qyteti = ‘Tiranë’

AND mosha <= ALL (select mosha From Student Where qyteti = ‘Tirana’);

Dhet të jetë <= se të gjitha pra është minimumi

SQL ofron një tjetër mundësi të kualifikimit për të testuar nëse rrezultati i një nënkërkese është bosh ose jo.Bëhet fjalë për predikatin EXIST.

EXIST <nënkërkesë> ë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_sFrom 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_sFrom NdjekWhere kod_mod = ‘M1’

INTERSECTSelect kod_sFrom NdjekWhere 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

CASEWHEN 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 relacioninPUNONJËS (KP, EMRI, PAGA, RAJONI)

81

KP – kodi punonjësitEMRI – emri i punonjësitPAGA – paga e punonjësitRAJON – rajoni i punës sipas kategorisë së (sportiv, muzik etj).

M (RAJONI, KATI, TVSH, DIR)

RAJONI – emri i rajonitKATI – kati ku ndodhet rajoniTVSH – TVSH që përdoret për rajoninDIR – drejtori i rajonit.

MV ( RAJONI, MUAJI, PL, PH)

RAJONI – emri i rajonitMUAJI - emri i muajitPL – 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ËSSET 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.

CASEWHEN clerë1 = vlerë11 THENWHEN vlerë 1 = vlerë 12 THEN

82

WHEN vlerë1 = vlerë 1n THENELSE rezx

END.

SQL 2 UNION, INTESECTION, DIFFERENCE

Versioni i thjeshtë (e kemi parë)<bllok kualifikim> 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) Sbën R (X3) S(X3).

Të njejtat probleme trajtohen për INTESECTION, DIFFERENCE.

Modifikimi i skemës:

83

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 MUPDATE M X SET NBPUN = (SELECT COUNT (*)

FROM PUNONJëSWHERE 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 S AS<bllok kualifikimi>[REFRESH <periode>]

Çfarë bëhet: Llogaritet blloku she shohet rezultati Tabel s është “read-only”

S’mund të manipulohet si relacion

84

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 ASFROM TIPI_VAGONITWHERE NO_VAGONIT IN

(SELECT NO_NOVAGONITFROM TRENIWHERE 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_VAGONAS SELECT NO_VAGONIT, TIPI_VAGONIT, GJENDJAFROM VAGONWHERE 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_VAGONIFROM GJEN_VAGONWHERE 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_VAGONIFROM VAGONIWHERE 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ë relacionetPUN (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ë:

PUNNDER

Supozojmë një pamje PUND të përcaktuar mbi produktin e këtyre dy relacioneve mbi KODIND:

DEFINE VIEW PUNDAS SELECT NUM, EMRI, KODIND, DREJ

FROM PUN, NDERWHERE PUN.KODIND = DREJ. KODIND

Reaultatet marrim

PUND

N.q.s. autorizojmë përdoruesin të modifikojë pamjen PUND si më poshtë:

MODIFY PUNDSET DREJ = “fred”WHERE NUM = e1

Ndryshojnë drejtorin pa marrë parasyshë se ai i takon ndërmarjes.

NUM EMRI KODINDe1 Ilsi d1e2 Skënder d1e3 Luan d1e4 Ela d2e5 Monda d2

KODIND DREJ

d1 Bujar

d2 Besi

NUM EMRI KODIND DREJe1 Ilsi d1 Bujare2 Skënder d1 Bujare3 Luan d1 Bujare4 Ela d2 Besie5 Monda d2 Besi

87

SQL procedurale

SQL nuk suporton ekzekutimin e procedurave të bazuara në disa kondita logjike. Pra SQL nuk i pranon strukturat

IF <kondite> THEN <kryej procedurë > ELSE < kryej procedurën alternative>.END IF.

Nga ana tjetër SQL nuk suporton ciklet. Pra SQL nuk suporton

DO WHILE

<kryej procedurë>

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 kontaktitSH_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_RIPOR1QER/31 Panel

pikture03_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 P_INDATE P_NËDORË P_MIN P_ÇMIM SH_KOD P_DIS P_MIN_POR P_RIP

11QER/31 Panel pikt 03_DHJ_02 8 5 20000 25595 25 0

SQL > UPDATE PRODUCTSET P_NËDORË = 4WHERE P_KOD = “11QER/31”.

- 1 row update (përgjigjet sistemi)

SQL > SELECT * FROM PRODUCT WHERE P_KOD = “11QER/31”

P_KOD P_PËRSHK P_INDATE P_NËDORË P_MIN P_ÇMIM SH_KOD P_DISC P_MIN_POR P_RIP

11QER/31 Panel pikt 03_DHJ_02 4 5 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 P_INDATE P_NËDORË P_MIN P_ÇMIM P_DISC SH_KOD P_MIN_POR P_RIP

2232/QWE kacavide 03_DHJ_02 6 5 990 24288 15 0

SQK > UPDATE PRODUCT

SET P_MIN = 7WHERE P_CODE = “2232/QWE”

1 row update.

SQL > SELECT * FROM PRODUCT WHERE P_CODE = “2232/QWE”.

P_KOD P_PËRSHK - - - - - - - - P_NËDORË P_MIN - - - - - - - - - - P_RIP

2232/QWE Kaçavidë 7 6 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ë:

>SQLCREATE OR REPLACE TRIGGER TRG_PRODUC_RIPOROSIAFTER INSERT OR UPDATE OF P_NËDORË, P_MIN ON PRODUCTBEGIN

UPDATE PRODUCT SET P_RIPOROSI = 1WHERE 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 PRODUCTSET P_NËDORË = 28WHERE 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 <emër trigeri>[BEFORE/AFTER] [DELETE/INSERT/UPDATE] OF <emër kolone> ON

<emër tabele>[FOR EACH ROW]BEGIN

PL/SQL instruksionetEND.

Trigeri që do të krijojmë siç thamë më lartë do të jetë:

SQL > LIST (listohet)

1. CREATE OR REPLACE TIGER TRG_PRODUK_P_POROSI2. AFTER INSERT OR UPDATE OF P_NËDORË NË PRODUKT3. BEGIN4. UPDATE PRODUKT5. SEP P_RIPOROSI =1

91

6. WHEN P_NEDORE <= P_MIN7. END;

SQL > RUN- Trigger created.

P_KODE P_NËDORË P_MIN P_RIPOROSI 11QER/31 - - - - 29 5 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 PRODUKTFOR EACH ROWBEGIN

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: juSTUD_KOD EMRI

321452324257

SHKËMBIMALI

Emri i tabelës: REGJISTRIMÇelësi primar : KLASE_KOD + STUD_KODÇlësi i jashtëm: KLASE_KOD, STUD_KOD

Emri i tabelës : KLASEÇelësi primar : KLASE_KODÇelësi i jashtëm: KURS_KOD

KLASE_KOD KURS_KOD KLASE_SEKSION KLASE_ORË KLASE_SALLE PROF_KOD

100141001810021

ACCT_211CIS_220QM_261

321

HM 2:30. 3:45amHEP 9:00. 9:50amHEP 9:00.

B201A112C305

342114114

KLASE_KOD STUD_KOD GRADA_REGJISTRIMIT

100141001410018100181002110021

321452324257321452324257321452324257

CBABCC

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.

Kjo është e dobishme si model teorik, por nuk është shumë praktike sepse mund të kërkojë nga gjeneratori shumë OID.

95

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 <a1:i1, a2:i2, an :in>, 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.

N.q.s. c = array , vlera e v është varg i identifikuesve të objekteve.

96

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 5O7 = (i7, set, i1, i2, i3)O8 = (i8, tuple, <DNAME: i5, DNUMBER: i4, MGR: i9, LOCATION:i7,

PUNONJËS: i10, PROJEKT : i11)O9 = (i9, tuple, <MANAGER:i12, MANAGERSTRADE: i6)O10 = (i10, set, {i12, i13, i14})O11 = (i11, set, {i15, i16, i17})O12 = ( i12, atom, )O13 = O14 = O15 = (i15, atom, Alpha )O16 = O17 =

Le ti analizojmë objektet e paraqitura:Gjashtë objektet e para janë vlera atomike (O1O5)

Objekti i shtatë është objekt set,që paraqet bashkësinë e vendeve të Departamentit 5

Bshkësia {i1, i2, i3} i referohet

{Tiranë, Durrës, Vlorë}

Objekti O8 është tuple; që paraqet Departamentin 5 dhe ka atributet

97

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 : Dateseksi : Chardept : departament);

define type Date:tuple (viti : integer,

muaji : integer,dita : integer);

define type Departament:tuple (demer : string,

dnumer : string, mgr : tuple (manager: Punonjës

date fill:date);vendet : set (string)

98

punonjës : (Punonjës);projekte : set (Projekte); tip bazë

Leksionin e ardhshëm do të shohim se si integrohen në strukturën e përgjithshme të objektit.

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ëstype

tuple (emri: string,nss : string, Signaturedatëlindja : Date,seksi : Chardept : Departamenti);

operations

mosha (p:punonjës) : integer;krijo_pu_të_ri (Punonjës: metadata

prish_pun(p:Punonjës) boolean;

define class Departament :type (demër: string,

dnumër: integer,mgr : tuple ( manager: Punonjës,

date_fill: Date),vendet: set (string),

99

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.

Veti tjetër ështa transistenca (objekti zhduket)

100

O8

O5 O7O4 O10 O11

O6O12 O12 O13 O14 O15 O16 O17

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, . . . . . . ,functionp.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, PagaSTUDENT : 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

Vendet setTuple mgr 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 atomikeBoolean, Char, Integer, Real, String, dhe Bit.

Tipi konstruktuar përfshinTuple, 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 ProjektType 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 Personitype tuple (emri : string,mbiemri : string,adresa : tuple (rruga : string, p_qyteti:qyteti))

end;

106

Class ekipitype tuple (emri : string,

tema : string, përgjegjës : kërkues)

end;

Class kërkues inherit PersoniType 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 ProjektWhere 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 ekipiv in kërkues

Where projekte. N_projekt = “PE234” ANDv. aktiviteti = “përgjegjës”.

107

4. Titulli i projektit të siguruar nga ekipi ku përgjegjës është “Beni”.

Select Projekt. TitulliFrom Projekte

v in kërkuesitWhere 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 Projektev in kërkuesitv. 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 ekipetV 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 ProjekteBy (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 ProjekteBy (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 ProjektetBy (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ërTipi i rezultatit string

Projeksioni mbi një atribut jo atomik.

Të gjendet adresa e kullës_eiffelKulla_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ërTipi 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 <rezulteti i kërkuar>From <emrat e koleksioneve dhe të variablave>Where <konditë>

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ësSelect w. emërFrom w in V_Franca. qyteti

Tipi i rezultatit set (string).

111

Select w. emërFrom w in Em_qyteteWhere 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ërFrom w in Em_qytet.

H in w. hoteleWhere 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_qyteteH 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ërFrom w in Em_qytetWhere 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.

Quantifikatorët:

113

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 tFrom t in Paris.shëtitjeWhere 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 zby 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_qyteteby w.vende, v.emër.

rezultati : listë e qyteteve.

Grupimi

114

Group x in zBy (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 shtetevegroup w in Em_qyteteby (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 Class qytetType tuple (emër: string, type tuple (emër:string

public kryeqiteti:qytet, public popullsia:integerpublic popullsia : integer, shteti : vendi

qytetet : set (qytet)) 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 : vendipublic r_emri :string end;end;

Class sheshi Class Monument inherit sheshitype tuple (emri:string type tuple (shekulli : integer,

emri_anglisht:string, ditët t mbyllura : list (string))read foto : bitmapread përshkrimi : string, end;

adresa : tuple (rruga: string Class Muze inherit sheshiqyteti: qytet type tuple (ditë_vizitë:list(string)

public tarifa I integer) specialiteti : stringend;

end;

115

Class Hotel Class Shëtitjetype tuple ( type tuple (emri : string:

public emri : string, shshet : list (sheshi))yjet : string methodmëngjez:integergjysëm_ pension: integer end;komplet_ pension : integeradresa : string,qytetet : qytet)

method

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 o-join. 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 AGJENTI

KOD_AGJENT AGJENT_PHONE

125167231333

6152439887615342677861524311249041234445

Natyral join:KOD_KLI MBIEM_KLI ZIP_KLI KLI_KOD_AGET AGENT.AGENT_KODE AGENT_PHONE

122177821321242131224311324451657399

FUSHAARASHKËMBIMALIPYLLI

3214537134341293214532145

125125167231231

125125167231231

61524398876152439887615342677862594311246152431124

Left outer join

KOD_KLI MBIEM_KLI ZIP_KLI KOD_AGENT AGENT_PHONE1221778213212421312243113244516573991542311

FUSHAARASHKËMBIMALIPYLLIDETI

321453713434129321453214537134

125125167231231421

61524398876152439887615342677862594311246152431124

I pa përcaktuar

RIGHT JOINKOD_KLI MBIEM_KLI ZIP_KLI KOD_AGENT AGENT_PHONE122177821321242

FUSHAARA

3214537134

125125

61524398876152439887

KOD_KLI MBIEM_KLI ZIP_KLI

KOD_AGENT

113244512177821312243132124215423111657399

MALIFUSHASHKËMBIARA DETIPYLLI

321453713434129371343713432145

231125167125421231

117

=

131224311324451657399

SHKËMBIMALIPYLLI

341293214532145

167231231333

6153426778625943112461524311249041234445

Përdorni databazën e vogël më poshtë për të vënë në dukje diferencën ndërmjet:natyral joinequi joi (o – join)outer join

STUDENT PROFESOR

KOD_PROF KOD_DEPT1234

2664

Natural JoinKOD_STUD STUD_KOD_PROF PROFESOR)KOD)PROF KOD_DEPT128569512272531235553427

2421

2421

6462

Left outer joinKOD_STUD KOD_PROF KOD_DEPT

128569512272531235552427531235

2421

6462

Right outer joinKOD_STUD KOD_PROF KOD_DEPT

KOD_STUD KOD_PROF100278128569512272531235531235553427

242

1

118

128569512272531235552427531235

24213

64626

2. Ndërtoni doagramën E-R

Supozojmë se kemi mdelin E-R

drejton

119

SHOFER MAKINË

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ë:

LLOGARIAEmri_degës Numri_Llogarisë BilanciSHKOZETLABINOTLAPRAKEKOMBINATQENDËRKURBIN PLAZH

A – 101A – 215A – 102A – 305A – 201A – 222A - 217

500700400350900700750

DEGAEmri_degës Qyteti_degës AsetetSHKOZETLABINOTLAPRAKEKOMBINATQENDËRKURBIN PLAZH

DURRËSELBASANTIRANËTIRANËTIRANËLAÇDURRËS

9.000.0002100.0001700.000400.0008.000.000300.0007.100.000

KlientEMER_KLIENT RRUGA_KLIENT QYTETI_KLIENTJULIANSAIMIRHALIMLUANFATMIRTAULANTALBAN

KRYESOREELBASANITKRYESOREELBASANIT4 SHKURTIGORICËKOMBINAT

DURRËSTIRANËDURRËSTIRANËTIRANËBERATELBASAN

120

DEPOZITUESEMRI_DEPOZITUES NUMRI_LLOGARISËSAIMIRHALIMFATMIRTAULANT

A_101A_215A_305A_217

HUAEMRI_DEGËS KODI_HUASË MANDATISHKOZETLABINOTLAPRAKEKOMBINATQENDËRKURBIN PLAZH

H_17H_23H_15H_14H_93H_11H_16

10002000150015005009001300

HUAMARRËSEMËR_KLIENTI KODI_HUASËJULIANSAIMIRASTRITLUANIBESAGRONI

H_17H_23H_15H_14H_93H_16

121

Përdorni databazën e treguar më poshtë për t’iu përgjigjur pyetjeve.

PRODUKTKOD_PRODUKT PËRSHKRIM_PRODUKT DATA_STOKUT_PROD PROD_NË_DORË PRODH_ÇMIM KODI

12_WWWP2 07_04_02 12 50 1231QQ23_55 19_03_02 123 100 123231_78_W 45 121335 64 AJ 18 123AR/31/TYR 8 121DT_34_WWW 11 123EER_67/W 9 121ER_56/DF 7 125FRE_TRYS 87 125SE_67_85 34ZW_QR/AV 14ZX_VRFJR 15

SHITJEKOD_SHITëË EMER_SHITJE SHITE_KONTAKTI KODI_ZONËS_SHIT PHON_SHIT120121122123124125

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