Kanoninės schemos ir reliacinis modelis
5 (100%) 1 vote

Kanoninės schemos ir reliacinis modelis

1 4

ĮVADAS 4

2 9

KANONINĖS SCHEMOS IR RELIACINIS MODELIS 9

2.1. Duomenų pavaizdavimas lentelinėje formoje 9

2.2 Duomenų bazių kanoninės schemos 11

2.3. Duomenų bazių valdymo sistemos 14

2.4. Kanoninių schemų klasifikavimas 15

2.5. Kanoninių schemų transformavimas 16

2.6. Reliacinės algebros operacijos 21

2.7. Reliacinio skaičiavimo kalba SQL 30

2.7.1 Duomenų bazės deklaravimas 30

2.7.2. Duomenų lentelių sukūrimas 30

2.7.3 Paprastosios užklausos 31

2.7.4. Duomenų įterpimas, modifikavimas, pašalinimas 34

2.7.5. Lentelių struktūros modifikavimas 35

2.7.6. Virtualios lentelės ir sinonimai 36

2.7.7. Indeksų sukūrimas 38

2.7.8. Išraiškų panaudojimas 39

2.7.9. Agreguotų funkcijų panaudojimas 41

2.7.10. Predikatai BETWEEN, IN ir LIKE operatoriuje SELECT 42

2.7.11. Rezultatų rūšiavimas 44

2.7.12. Eilučių grupavimas 45

2.7.13. Sąlygotos eilučių grupės 47

2.7.14. Lentelių sumavimas 47

2.7.15. Lentelių sujungimas 48

2.7.16. Rezultatų lentelių rūšiavimas ir grupavimas 50

2.7.17. Vidinis lentelių sujungimas 51

2.7.18. Sub-užklausos su pavienėmis grąžinamomis reikšmėmis 54

2.7.19. Sub-užklausos su grupe grąžinamų reikšmių 56

2.7.20. Raktažodžių ANY ir ALL panaudojimas 57

2.7.21. Predikato EXISTS panaudojimas 58

2.7.22. Koreliuotos vidinės užklausos 59

3 61

FUNKCINĖS PRIKLAUSOMYBĖS IR RAKTAI 61

3.1. Funkcinių priklausomybių apibrėžimas 61

3.2. Funkcinių priklausomybių išvedimo taisyklės 62

3.3. Galinė funkcinių priklausomybių aibė 65

3.4. Išvedimo taisyklių savybės 67

3.5. Santykių schemos raktai 72

4 74

FUNKCINIŲ PRIKLAUSOMYBIŲ DENGTYS 74

IR JŲ EKVIVALENTIŠKUMAS 74

4.1. Išvesties orientuotieji acikliniai grafai 74

4.2. Užduotų funkcinių priklausomybių ir atributų aibių ekvivalentiškumas 78

4.3. Tiesioginės funkcinės priklausomybės 81

4.4. Minimalios funkcinių priklausomybių dengtys 84

4.5. Redukuotosios ir optimaliosios dengtys 91

5 96

SUDĖTINIŲ FUNKCINIŲ PRIKLAUSOMYBIŲ DENGTYS 96

5.1. Sudėtinės funkcinės priklausomybės 96

5.2. Sudėtinių funkcinių priklausomybių aibės pertvarkymas 99

5.3. Funkcinių priklausomybių atstatymas iš struktūrinių tipų aibės 105

6 110

JUNGIMO/PROJEKCIJOS PRIKLAUSOMYBĖS IR RELIACINIŲ SCHEMŲ PROJEKTAVIMAS 110

6.1. Daugiareikšmės priklausomybės 110

6.2. Jungimo/projekcijos priklausomybės 112

6.3. Pagrindinis duomenų bazių projektavimo kriterijus 116

6.4. Reliacinių schemų projektavimo dekompozicijos metodas 120

6.5. Nenormalizuotų schemų trūkumai 131

6.6. Dekompozicijos metodo trūkumai 133

6.7. Pilnosios reliacinės duomenų bazės. 137

6.8. Duomenų bazių projektavimo sintezės metodas 137

LITERATŪRA 144



1

ĮVADAS

Tradicinis duomenų bazių projektavimas apibrėžiamas, kaip procesas, kurio metu yra analizuojami vartotojų poreikiai, aprašomos duomenų savybės ir poreikiams. relevantinė informacija atvaizduojama DBVS palaikomomis duomenų struktūromis [1]. Šis procesas suskaidomas į keturis etapus: reikalavimų analizės fazę, konceptualaus, loginio ir fizinio projektavimo fazes. Konceptualaus projektavimo fazėje modeliuojama vartotojų informacija bei jos apdorojimas. Šioje fazėje naudojami trys pagrindiniai semantiniai modeliai – objektinis, EER- ir reliacinis duomenų modeliai. Šie modeliai yra neutralūs, neorientuoti į konkretų DBVS palaikomą modelį. Reikalavimų analizės fazėje giliai analizuojama organizacijos veikla ir rezultate tiksliai aprašomos atskirų vartotojų grupių funkcijos. Tačiau duomenų struktūros paprastai lieka netiksliai apibrėžtos, neformalizuotos. Konceptualaus projektavimo fazėje formalizuojami semantiniai sąryšiai tarp probleminių sąvokų, panaudojant tam tikrą vieną ar net kelis semantinius duomenų modelius. Pastaruoju atveju integruojant atskirų vartotojų grupių informacijos poreikius konceptualiniame lygmenyje skirtingus duomenų semantinius modelius tenka transformuoti, kad specifikuoti duomenų bendrąsias savybes globalinėje schemoje. Loginio projektavimo fazėje sudaroma DB loginė schema, orientuota į pasiriktos DBVS duomenų modelį, kuris gali skirtis nuo duomenų modelio, panaudoto, sudarant globalinę schemą. Čia taip reikalingos modelio transformacijos, ypač tuo atveju, kai norima loginę schemą suprojektuoti automatizuotu būdu. Savo ruožtu, kuriant sofistines, plačios paskirties DBVS stengiamasi suprogramuoti unifikuotus duomenų manipuliavimo modulius, orientuotus į tipinių plataus spektro semantinių duomenų sąryšių apdorojimą. Tokie sąryšiai dar vadinami duomenų abstrakcijomis. Fizinio projektavimo metu DBVS palaikomo duomenų modelio loginė schema papildoma konkrečios kompiuterinės aplinkos ir operacinės sistemos duomenų fiziniais parametrais. Šitokia nuosekli projektavimo fazių seka būdinga taip vadinamai duomenų tiesioginei inžinerijai.

Konceptualaus projektavimo fazėje, kai aprašomi įvairių vartotojų informacijos poreikiai fiksuojami semantiniai sąryšiai tarp probleminių sąvokų, aptinkamos “siauros”, nesuderintos arba, atvirkščiai, “persotintos”, plačios sąvokos. Šiuo atveju poreikių integracijos etape tenka įvesti naujas sąvokas (dalykinės srities konceptus), kad panaikinti sąvokų nesuderinamumą ir užpildyti pastebėtas semantines spragas. Tokie procesai yra “humanizuoti”, čia reikalingi ekspertai, gerai išmanantys dalykinę
sritį, kad duomenų modelius būtų galima semantiškai praturtinti. Analogiška situacija pastebima, sprendžiant duomenų atvirkštinės inžinerijos uždavinius [2], kai projektuojant konceptualaus lygio globalinę schemą panaudojamos palikuoninės veikiančios DB ir jų schemos bei įvertinami nauji informacijos poreikiai. Šiuo atveju reikalavimų integracijos procese fiksuojant semantinius sąryšius tarp konceptų gali atsirasti taip vadinamos semantinės spragos, kurios užpildomos įvedant naujus adjekvačius konceptus. EER- diagramos naudojamas kaip reliacinių duomenų bazių modelio kvazi-standartas, ir jų pagalba specifikuojami duomenų struktūriniai apribojimai. Tiesioginės inžinerijos atveju struktūriniai EER-apribojimai transformuojami į reliacinius apribojimus, o atvirkštinės inžinerijos atveju EER- apribojimai transformuojami į koncepcinio OBJEKTŲ-SĄVYBIŲ modelio konstrukcijas [3], semantinės išraiškos galimybių požiūriu būdingas abstraktiems duomenų tipams, kurių aprašymui gali būti panaudojama SQL3 kalba [4].

Vienas iš pagrindinių tikslų projektuojant DBVS yra “padengti” vartotojų, naudojančių duomenų bazes, uždavinių semantiką. Projektuojamos plačios paskirties DBVS orientuojamos į tam tikro duomenų modelio panaudojimą. Objektiniuose ir EER duomenų modeliuose naudojamos bendrosios duomenų abstrakcijos yra tipo/supertipo (specializavimo/apibendrinimo), agregavimo ir asociatyviniai sąryšiai. Asociatyviniai sąryšiai duomenų bazių koncepcinio projektavimo stadijoje yra materializuojami arba, kitais žodžiais tariant, paverčiami agregatinių sąryšių tipais. Tarp dalykinės srities konceptų užduoti tipo/supertipo sąryšiai dar vadinami isa sąryšiais. Agregatinius ir isa sąryšius, specifikuotus duomenų bazių koncepcinėse schemose, vadinsime pagrindiniais struktūriniais apribojimais. Šaltiniuose [5,6] pateikta jungtinė semantinių sąryšių taksonomija. Šios klasifikacijos sąryšiai naudojami lingvistikoje, logikoje ir kognityvinėje psichologijoje. Išsami šių semantinių sąryšių analizė pateikta [5]. Specifikuojant semantinius sąryšius panaudosime apibendrintas objektinės orientacijos duomenų abstrakcijas [3], būdingas abstraktiems duomenų tipams [4].

Daugeliui šiandienos kompanijų globalus priėjimas prie duomenų bazių (DB) yra pagrindinis sėkmės šaltinis. Tačiau tai taip pat yra didelė problema, nes daugelis duomenų bazių atsirado nepriklausomai viena nuo kitos laiko atžvilgiu. Žlugo arba nedavė tikėtinos naudos nemažai duomenų integravimo projektų. “Techninės” priežastys – tai struktūrinis ir semantinis heterogeniškumas, taip pat integravimo uždavinio sudėtingumas, be to, dažnai neįvertinama duomenų integravimo kaina ir nauda. Federatyvinio informacijos integravimo požiūriu [30] naudojami trys metodai, kaip išspręsti heterogeniškų duomenų bazių schemų integravimo problemą [31,32,33]. Kad išvengti semantinių konfliktų tarp skirtingų schemų specifikacijų, jos turi turėti bendresnį vieningą duomenų modelį, kurio pagrindu turi būti sudarytos koncepcinio lygio schemos organizacijos padaliniams ir aktoriams. Ši problematika yra organizacijų modeliavimo problematika [7,34,35]. Pragmatiniai ir semantiniai aspektai detaliai išnagrinėti monografijoje [8]. Pagrindinės nuostatos, kurių prisilaikoma šioje monografijoje pragmatiniais klausimais, pateiktos [9].

Informacijos sistema yra įmonės arba organizacijos dalis ir jos branduolį sudaro duomenų saugyklos, patalpintos kompiuterinės sistemos išorinėje atmintyje. Kadangi informacijos sistemos apima daug organizacijos padalinių, tai duomenų įvedimas, saugojimas, apdorojimas ir panaudojimas būna paskirstytas, priklausomai nuo to, kokie vartotojai ir kokius informacinius uždavinius sprendžia valdymo procese. Vartotojų informacijos poreikiai sąlygoja informacijos sistemos turinį, išreiškiamą realaus pasaulio objektais ir sąryšiais tarp jų. Apibrėžiant organizacijos modelį knygos [10] autoriai naudoja koncepcinio modelio sąvoką. Jos turinį sudaro objektų sistema, kurios pagrindu apibrėžiama realaus pasaulio nagrinėjama dalis.

Informacijos sistema (IS) susideda iš trijų dalių [11]: koncepcinės schemos, informacijos bazės ir informacinio procesoriaus. Koncepcinė schema ir informacijos bazė yra statinė sistemos dalis, kai tuo tarpu informacinis procesorius keičia bazės turinį prisilaikant apribojimų, kuriuos išreiškia koncepcinė schema. Klasikinis ESYBIŲ-RYŠIŲ (ER) formalizmas [12] ir jo išvystymai siekia aprašyti objektų sistemos statinę struktūrą. ER-diagramos yra grafinė notacija, charakterizuojanti esybių tipus, jų atributus ir sąryšius, kurie sujungia tarpusavyje objektus. ER-formalizmo pasekėjai [13,14] stengėsi padidinti koncepcinių schemų išraiškos galimybes. Šios koncepcinių schemų galimybės padengiamos įvairiais apribojimais. Struktūriniai apribojimai yra pateikiami deklaratyvioje formoje ir tik vėliau juos informacinis procesorius konvertuoja į procedūrinę formą. Struktūriniai apribojimai susiaurina reikšmių sritis, kuriose esybių arba sąryšių atributai yra interpretuojami.

Vartotojų poreikių nustatymas apima tris modeliavimo lygius [15] : meta-lygį, probleminį lygį ir egzempliorių lygį. Kitais žodžiais tariant visi trys lygiai yra sudaryti iš meta-tipų, tipų ir tipų- egzempliorių.
Egzempliorių lygis susideda iš probleminės srities konceptų pavyzdžių. Probleminio lygio konceptai yra meta-lygio sąvokų (AGENTAS, ĮVYKIS, VEIKSMAS, ESYBĖ, RYŠYS) pavyzdžiai. Probleminio lygio sąvokos įvardina probleminės srities objektus arba sąryšius (PIRKĖJAS, PARDAVĖJAS, UŽSAKYMAS). Meta-sąvokos ir meta-ryšiai apibrėžiami naudojant į tikslus orientuotą vartotojų poreikių nustatymo terminologiją. ESYBĖS, RYŠIAI, ĮVYKIAI, AGENTAI yra sąvokos, kurios naudojamos kaip specialūs meta-sąvokos OBJEKTAS atvejai. RYŠYS gali būti nagrinėjamas kaip subordinuotas OBJEKTAS. OBJEKTAS ir RYŠYS turi savo egzempliorius. RYŠIŲ-EGZEMPLIORIŲ egzistavimas sąlygojamas sąryšių tarp atatinkamų OBJEKTŲ-EGZEMPLIORIŲ egzistavimu. Paprastai objekto-egzemplioriaus sąvoka reiškia kokį nors pavienį daiktą, t. y. objekto pavyzdį, o OBJEKTAS reiškia panašių daiktų klasę. Šiame darbe OBJEKTO sąvoka naudojama kaip objektų-egzempliorių KLASĖ, kadangi mes norime OBJEKTĄ suprasti kaip tipą, t. y. kaip esybių aibę su identiška struktūra. Trečiojo skyriaus teoriniame nagrinėjime mes norime apsiriboti objektų sistemos statine struktūra.

Daktaro tezėse [16] narinėjamas ESYBIŲ-RYŠIŲ-LAIKO modelis, išplėstasis ER-modelis, kuris naudojamas istorinei informacijai ir įmonės funkcijoms modeliuoti. Laikas yra įvedamas kaip atskira esybių klasė. Kiekvienas objektas arba objektų sąryšis gali būti sujungtas su LAIKU. Tai yra gera idėja natūraliau pavaizduojant objektus ir tuo pačiu jų schemas. Tačiau laike egzistuojantys objektai ir sąryšiai ER-formalizmo kalbos prasme yra RYŠIAI, kurie savyje apjungia laiką. Koncepcinių schemų prasme, statiniu aspektu LAIKĄ galima traktuoti kaip probleminį objektą, nesuteikiant jam ypatingo statuso.

Funkcinė metodologija [17,18] orientuota į valdymo funkcijų dekompoziciją, kai tuo tarpu objektinės metodologijos [19,20] orientuotos pirmiausia į objektų identifikavimą. Vėliau prie šių objektų, duomenų objektų, prijungiamos procedūros. Tai yra du skirtingi konceptualaus modeliavimo prasme požiūriai. Šiose dviejų krypčių metodologijose naudojami trijų tipų modeliai: objektų sistemos modelis, būsenų transformavimo ir duomenų srautų diagramos. Šie trys modeliuojamos sistemos aspektai tarpusavyje suderinami. Funkcijos gali būti dekomponuotos iki subfunkcijų ir, analogiškai, objektai gali būti suskaidyti į subobjektus tam, kad subfunkcijos ir subobjektai tarpusavyje “susibalansuotų”. Būsenų transformavimo diagramos iliustruoja veiksmus, kurie priklauso nuo objektų atributų reikšmių, ir šiose diagramose naudojami veiksmai yra funkcijos iš duomenų srautų diagramų; būsenų diagramų įvykiai traktuojami kaip procedūros objektų atributų reikšmių atžvilgiu. Kiekviena duomenų srautų diagramos saugykla yra objektų ir sąryšių rinkinys iš objektų sistemos modelio; srautų diagramos funkcijos manipuliuoja duomenimis, specifikuotais objektų sistemos atributais.

Šiame leidinyje ketvirtame ir penktame skyriuose išsamiai išnagrinėti struktūrinių tipų projektavimo klausimai, kurie teoriniu požiūriu nėra pakankamai vientisai ištirti objektinės metodologijos srityje [19,20]. Šias spragas pabandyta užpildyti pasinaudojant nusistovėjusiais konceptais iš duomenų bazių reliacinės teorijos [21]. Šioje teorijoje pakankamai detaliai išnagrinėtos duomenų priklausomybės – funkcinės, daugiareikšmės, jungimo-projekcijos. Jų pagrindu išvystyti duomenų bazių loginės struktūros projektavimo dekompozicijos ir sintezės metodai. Minėtos duomenų priklausomybės sudaro fundamentalų pagrindą objektų sistemos vienareikšmiškam, normalizuotam išskyrimui. Šios duomenų priklausomybės yra populiarios, tačiau jų yra ir daugiau.Visas kitas priklausomybes, kurios padidina duomenų semantinės išraiškos galimybes, “padengiamos” procedūriniais objektais, kurie realizuojami duomenų apdorojimo procedūromis IS eksploatavimo metu. Objektų sistemoje šioms procedūroms numatomi duomenų objektų atitikmenys. Procedūra PR bus adekvati objektui Q, jeigu procedūros PR kiekvienas išėjimo kintamasis yra objekto Q savybė ir kiekvienam objektui-egzemplioriui q*Q procedūra PR priskiria tiksliai po vieną objekto Q savybių reikšmę. Tai yra procedūrinių ir duomenų objektų suderinamumo kriterijus. Juo vadovaujantis duomenų objektai yra specializuojami, o procesai iš srautų diagramos dekomponuojami, kad gauti subalansuotą objektų sistemą. Monografijoje pateiktas koncepcinių taip vadinamų OP schemų matematinis pagrindimas. Šiomis schemomis specifikuojami specializuoti objektai su adekvačiomis objektų savybėmis. Objekto Q savybė P yra adekvati, jeigu kiekvienas objektas-egzempliorius q*Q įgauna tiksliai po vieną kiekvienos savybės P reikšmę.

Meta-sąryšis tarp ESYBĖS ir OBJEKTO įvairiuose požiūriuose yra skirtingai suprantami. Požiūryje [15] ESYBĖ yra OBJEKTO specialus atvejis. Priešingai [20], ESYBĖS konceptas apima objektus-egzempliorius, OBJEKTUS-klases, atributus, ryšius ir asociacijas. Čia OBJEKTO konceptas yra specialus ESYBĖS koncepto atvejas. Ta pati esybė pasireiškia skirtingai ir elgiasi skirtingai, priklausomai nuo konteksto, kuriame ESYBĘ vartoja tas pats arba kitas vartotojas.

Vartotojų informacijos poreikių nustatymo ir žinių atvaizdavimo procese specialistai ir ekspertai manipuliuoja
kurie yra įtraukiami į IS konceptualų modelį. Jis atvaizduoja duomenų savybes ir struktūrinius apribojimus. Probleminės srities priežasčių-pasekmių fenomenas sąlygoja tarp esybių taksonominius sąryšius. Taksonominiai sąryšiai yra keliai, vedantys nuo bendresnių esybių prie detalesnių. Formaliai žiūrint šie sąryšiai yra dalinis sutvarkymas – jie yra tranzityvūs, refleksyvūs ir antisimetriniai. Šis požiūris yra aprašytas [22]. Pasinaudojant esybių vardų aibės daliniu sutvarkymu apibrėžiamas universalus struktūrinis tipas. Bet kuris objektas Q yra universalaus tipo potipis. Suprantama, kad šis pasiūlytas formalizmas nėra vienintelis. Čia žinomos analogiškos paskirties kitos matematinės schemos [23,24]. Siūlomas požiūris yra žinių atvaizdavimo abstrakčioje semiotinėje erdvėje metodo [25] dalinio atvejo išvystymas, pritaikant jį objektinių duomenų bazių koncepcinių schemų projektavimui. Objektinėse duomenų bazėse naudojamos struktūrinių tipų elgsenos standartinės funkcijos [26].Koncepcinėje schemoje specifikuoti objektų apribojimai, kurie pateikiami deklaratyvinėje formoje, programų sudarymo arba generavimo CASE priemonėmis etape konvertuojami į procedūrinę formą. Apribojimų korektiškumas kontroliuojamas dviejose stadijose – programos kompiliavimo metu (static type cheking) ir jos vykdymo metu (run time checking) [27]. Struktūrinis OP modelio komponentas papildytas tipinėmis struktūrinių tipų elgsenos funkcijomis ir vartotojo užduotomis operacijomis [28] išbaigia šį modelį. Šis išbaigtas modelis traktuojamas objektiniu. Objektinio komponento kalbos prototipu yra SQL3 kalba [29], kuri atžvilgiu SQL turi abstrakčių duomenų tipų praplėtimą.

Įvade trumpai apžvelgti įvairūs požiūriai į informacijos sistemų duomenų semantikos analizę ir duomenų struktūrų projektavimą. Pagrindinis duomenų bazių projektavimo metodas, kuris turi pakankamą teorinį išbaigtumą yra reliacinių duomenų bazių projektavimo dekompozicijos metodas [21], kuris išvystytas šeštajame skyriuje iki universalių struktūrinių tipų sintezės metodo. Šis metodas gali būti panaudotas objektinių duomenų bazių ir duomenų objektų struktūriniam komponentui projektuoti. Pateikta teorinė medžiaga yra naudojama Kauno technologijos universiteto Informatikos fakultete, skaitant bakalaurinių studijų “Duomenų bazių” paskaitų kursą ir magistrinių studijų kursą “Duomenų bazės ir semantiniai modeliai”.

2

KANONINĖS SCHEMOS IR RELIACINIS MODELIS

2.1. Duomenų pavaizdavimas lentelinėje formoje

Reliacinės duomenų bazės yra populiarios, jos orientuotas vartotojui betarpiškam naudojimui. Reliacinių duomenų bazių modelio pagrindiniai privalumai yra:

– duomenų struktūros paprastumas ;

– nesudėtingi duomenų manipuliavimo metodai ir kalbos.

Visi duomenys, kur jie bebūtų užrašyti, – ar kompiuterio ekrane,ar atspausdinti popieriuje – pateikiami lentelėse. Programuotojas loginiame lygyje taipogi įsivaizduoja duomenų pateikimo formą lentelinę.Tos pačios lentelės visos eilutės turi tą patį formatą. Lentelės duomenys charakterizuoja vieną apibendrintą dalykinės srities objektą, o viena lentelės eilutė charakterizuoja vieną realaus pasaulio objektą-egzempliorių (konkretų tarnautoją, padalinį, detalę ir t.t.). Jeigu du apibendrinti informaciniai objektai TARNAUTOJAS ir PADALINYS susieti tarpusavyje sąryšiu, pavyzdžiui VYKDOMOS_PAREIGOS , tai toks sąryšis traktuojamas kaip savarankiškas apibendrintas objektas ir jam skiriama duomenų bazėje nauja lentelė, kur surašomi duomenys, charakterizuojantys sąryšį VYKDOMOS_PAREIGOS.

Paimkime pavyzdį (žr. 2.1 lentelę.). Lentelėje Grafikas surašyti duomenys, kurie charakterizuoja lėktuvų reisus.

2.1 lentelė. Grafikas

REISO_NR IŠSKRIDI-MO_PUNKTAS ATVYKI-MO_PUNKTAS IŠSKRIDI-MO_LAIKAS ATVYKI-MO_LAIKAS

t1 83 Vilnius Berlynas 11.30 13.43

t2 84 Berlynas Vilnius 15.00 17.13

… 213 Vilnius Talinas 11.43 12.45

Šiuo metu Jūs matote 30% šio straipsnio.
Matomi 2557 žodžiai iš 8523 žodžių.
Peržiūrėkite iki 100 straipsnių per 24 val. Pasirinkite apmokėjimo būdą:
El. bankininkyste - 1,45 Eur.
Įveskite savo el. paštą (juo išsiųsime atrakinimo kodą) ir spauskite Tęsti.
SMS žinute - 2,90 Eur.
Siųskite sms numeriu 1337 su tekstu INFO MEDIA ir įveskite gautą atrakinimo kodą.
Turite atrakinimo kodą?
Po mokėjimo iškart gausite atrakinimo kodą, kurį įveskite į laukelį žemiau:
Kodas suteikia galimybę atrakinti iki 100 straispnių svetainėje ir galioja 24 val.