ERP datu bāzu denormalizācija un tās ietekme uz programmatÅ«ras izstrādi: kroga atvērÅ”ana Tortugā

Sveiki! Mani sauc Andrejs Semenovs, es esmu Sportmaster vecākais analÄ«tiÄ·is. Å ajā ierakstā es vēlos izvirzÄ«t jautājumu par ERP sistēmu datu bāzu denormalizāciju. ApskatÄ«sim vispārÄ«gos nosacÄ«jumus, kā arÄ« konkrētu piemēru ā€“ pieņemsim, ka tas bÅ«tu brÄ«niŔķīgs monopola krogs pirātiem un jÅ«rniekiem. Kurā pirāti un jÅ«rnieki jāapkalpo dažādi, jo Å”o labo kungu priekÅ”stati par skaistumu un patērētāju modeļiem bÅ«tiski atŔķiras.

Kā padarÄ«t visus laimÄ«gus? Kā izvairÄ«ties no trakuma, veidojot un uzturot Ŕādu sistēmu? Ko darÄ«t, ja krodziņā sāk ierasties ne tikai parastie pirāti un jÅ«rnieki?

ERP datu bāzu denormalizācija un tās ietekme uz programmatÅ«ras izstrādi: kroga atvērÅ”ana Tortugā

Viss ir zem griezuma. Bet iesim kārtībā.

1. Ierobežojumi un pieņēmumi

Viss iepriekÅ” minētais attiecas tikai uz relāciju datu bāzēm. Denormalizācijas sekas modifikācijas, dzÄ“Å”anas un ievietoÅ”anas anomāliju veidā, kas ir labi aptvertas, tostarp internetā, netiek ņemtas vērā. Ārpus Ŕīs publikācijas jomas ir gadÄ«jumi, kad denormalizācija ir izplatÄ«ta vieta, ar klasiskiem piemēriem: pases sērija un numurs, datums un laiks utt.

Ziņojumā izmantotas intuitÄ«vas un praktiski pielietojamas normālu formu definÄ«cijas, neatsaucoties uz matemātiskiem terminiem. Tādā formā, kādā tās var tikt pielietotas reālu biznesa procesu (BP) pārbaudē un industriālās programmatÅ«ras projektÄ“Å”anā.

Tiek apgalvots, ka datu noliktavu, ziņoÅ”anas rÄ«ku un integrācijas lÄ«gumu dizains (kuros tiek izmantots informācijas tabulas attēlojums) atŔķiras no ERP sistēmu datu bāzu dizaina ar to, ka patēriņa vienkārŔība un apzinātas denormalizācijas izmantoÅ”ana, lai to panāktu, var bÅ«t svarÄ«gāka par integritāti. aizsardzÄ«bas dati. Es piekrÄ«tu Å”im viedoklim, un tālāk aprakstÄ«tais attiecas tikai uz ERP sistēmu pamatdatu un darÄ«jumu datu modeļiem.

Normālo formu skaidrojums sniegts, izmantojot vairumam lasÄ«tāju ikdienas lÄ«menÄ« saprotamu piemēru. Tomēr kā vizuālu ilustrāciju 4.ā€“5. punktā apzināti tika izmantots ā€œizdomātsā€ uzdevums. Ja jÅ«s to nedarÄ«sit un paņemsiet kādu mācÄ«bu grāmatu piemēru, piemēram, to paÅ”u pasÅ«tÄ«jumu glabāŔanas modeli no 2. punkta, jÅ«s varat nonākt situācijā, kad lasÄ«tāja uzmanÄ«ba tiks novirzÄ«ta no piedāvātās procesa dekompozÄ«cijas uz modeli, uz personÄ«go pieredzi un uztveri par to, kā jāveido procesi un modeļi datu glabāŔanai IS. Citiem vārdiem sakot, ņemiet divus kvalificētus IT analÄ«tiÄ·us, lai viens sniedz pakalpojumus loÄ£istikas pārvadātājiem, kas pārvadā pasažierus, otrs - loÄ£istikas pakalpojumus, kas pārvadā maŔīnas mikroshēmu ražoÅ”anai. PalÅ«dziet viņiem, iepriekÅ” neapspriežot automatizētos BP, izveidot datu modeli informācijas glabāŔanai par dzelzceļa braucienu.

Pastāv varbÅ«tÄ«ba, kas nav nulle, ka piedāvātajos modeļos jÅ«s atradÄ«siet ne tikai ievērojami atŔķirÄ«gu atribÅ«tu kopu, bet arÄ« atŔķirÄ«gas entÄ«tiju kopas, jo katrs analÄ«tiÄ·is paļausies uz viņam pazÄ«stamiem procesiem un uzdevumiem. Un Ŕādā situācijā nevar pateikt, kurÅ” modelis ir ā€œpareizsā€, jo nav vērtÄ“Å”anas kritērija.

2. Normālās formas

ERP datu bāzu denormalizācija un tās ietekme uz programmatÅ«ras izstrādi: kroga atvērÅ”ana Tortugā

Pirmā parastā datu bāzes forma prasa visu atribūtu atomitāti.
Jo Ä«paÅ”i, ja objektam A ir neatslēgas atribÅ«ti a un b, piemēram, c=f(a,b) un tabulā, kas apraksta objektu A, tiek saglabāta atribÅ«ta c vērtÄ«ba, tad datu bāzē tiek pārkāpta pirmā normālā forma. . Piemēram, ja pasÅ«tÄ«juma specifikācijā ir norādÄ«ts daudzums, kura mērvienÄ«bas ir atkarÄ«gas no preces veida: vienā gadÄ«jumā tie var bÅ«t gabali, citā litri, treÅ”ajā iepakojumi, kas sastāv no gabaliem (modelÄ« virs Good_count_WR) , tad datu bāzē tiek pārkāpta atribÅ«tu atomitāte. Å ajā gadÄ«jumā, lai pateiktu, kādam jābÅ«t pasÅ«tÄ«juma specifikācijas tabulu klasterim, nepiecieÅ”ams mērÄ·tiecÄ«gs darba procesa apraksts IS, un, tā kā procesi var bÅ«t dažādi, var bÅ«t daudz ā€œpareizoā€ versiju.

Otrā parastā datu bāzes forma pieprasa atbilstÄ«bu pirmajai veidlapai un savai tabulai katrai entÄ«tijai, kas saistÄ«ta ar darba procesu IS. Ja vienā tabulā ir atkarÄ«bas c=f1(a) un d=f2(b) un nav atkarÄ«bas c=f3(b), tad tabulā tiek pārkāpta otrā normālā forma. IepriekÅ” minētajā piemērā pasÅ«tÄ«jumu tabulā nav atkarÄ«bas starp pasÅ«tÄ«jumu un adresi. Mainiet ielas vai pilsētas nosaukumu, un jÅ«s neietekmēsit pasÅ«tÄ«juma bÅ«tiskos atribÅ«tus.

TreŔā parastās formas datu bāze prasa atbilstÄ«bu otrajai normālajai formai un funkcionālu atkarÄ«bu neesamÄ«bu starp dažādu entÄ«tiju atribÅ«tiem. Å o noteikumu var formulēt Ŕādi: "ir jāaprēķina viss, ko var aprēķināt." Citiem vārdiem sakot, ja ir divi objekti A un B. Tabulā, kurā glabājas objekta A atribÅ«ti, atribÅ«ts C izpaužas, un objektam B ir atribÅ«ts b, tā ka pastāv c=f4(b), tad treŔā normālā forma. tiek pārkāpts. Tālāk esoÅ”ajā piemērā atribÅ«ts Gabalu daudzums (Total_count_WR) pasÅ«tÄ«juma ierakstā nepārprotami apgalvo, ka tiek pārkāpta treŔā parastā forma

3. Mana pieeja normalizācijas pielietoŔanai

1. Tikai mērÄ·a automatizēts biznesa process var nodroÅ”ināt analÄ«tiÄ·im kritērijus entÄ«tiju un atribÅ«tu identificÄ“Å”anai, veidojot datu uzglabāŔanas modeli. Procesa modeļa izveide ir priekÅ”noteikums normāla datu modeļa izveidei.

2. TreŔās normālās formas sasniegÅ”ana tieŔā nozÄ«mē var nebÅ«t praktiska ERP sistēmu izveides praksē, ja ir izpildÄ«ti daži vai visi no Å”iem nosacÄ«jumiem:

  • automatizētie procesi reti tiek mainÄ«ti,
  • pētniecÄ«bas un izstrādes termiņi ir saspringti,
  • prasÄ«bas attiecÄ«bā uz datu integritāti ir salÄ«dzinoÅ”i zemas (iespējamas kļūdas rÅ«pnieciskajā programmatÅ«rā programmatÅ«ras klientam neizraisa naudas vai klientu zaudējumus)
  • uc

Aprakstītajos apstākļos atseviŔķu objektu un to atribūtu dzīves cikla apzināŔanas un aprakstīŔanas izmaksas var nebūt attaisnojamas no ekonomiskās efektivitātes viedokļa.

3. Jebkuras datu modeļa denormalizācijas sekas jau izveidotā IS var mazināt, veicot rÅ«pÄ«gu iepriekŔēju koda izpēti un testÄ“Å”anu.

4. Denormalizācija ir veids, kā pārnest darbaspēka izmaksas no datu avotu izpētes un biznesa procesa projektÄ“Å”anas stadijas uz izstrādes stadiju, no ievieÅ”anas perioda uz sistēmas izstrādes periodu.

5. Ir vēlams tiekties pēc datu bāzes treŔās parastās formas, ja:

  • Izmaiņu virziens automatizētajos biznesa procesos ir grÅ«ti prognozējams
  • IevieÅ”anas un/vai izstrādes komandā ir vāja darba sadale
  • Integrācijas shēmā iekļautās sistēmas attÄ«stās saskaņā ar saviem plāniem
  • Datu neatbilstÄ«bas rezultātā uzņēmums var zaudēt klientus vai naudu

6. Datu modeļa izstrādi analÄ«tiÄ·im vajadzētu veikt tikai saistÄ«bā ar mērÄ·a biznesa procesa un procesa modeļiem IS. Ja izstrādātājs izstrādā datu modeli, viņam bÅ«s jāiedziļinās priekÅ”meta jomā tādā mērā, lai viņŔ jo Ä«paÅ”i saprastu atŔķirÄ«bu starp atribÅ«tu vērtÄ«bām - nepiecieÅ”ams nosacÄ«jums atomu atribÅ«tu izolÄ“Å”anai. Tādējādi, uzņemoties neparastas funkcijas.

4 Ilustrācijas uzdevums

Pieņemsim, ka jums ostā ir maza robotu krodziņŔ. JÅ«su tirgus segments: jÅ«rnieki un pirāti, kuri ierodas ostā un kuriem ir nepiecieÅ”ama atpÅ«ta. JÅ«s pārdodat tēju ar timiānu jÅ«rniekiem, bet ruma un kaulu Ä·emmes bārdu Ä·emmÄ“Å”anai pirātiem. Pakalpojumu paŔā krodziņā nodroÅ”ina saimniece robots un bārmenis robots. Pateicoties JÅ«su augstajai kvalitātei un zemajām cenām, JÅ«s esat izdzinuÅ”i savus konkurentus, lai visi, kas nokāpj no kuÄ£a, nāk uz JÅ«su tavernu, kas ir vienÄ«gā ostā.

Tavernas informācijas sistēmu komplekss sastāv no Ŕādas programmatÅ«ras:

  • AgrÄ«nās brÄ«dināŔanas sistēma par klientu, kas atpazÄ«st savu kategoriju, pamatojoties uz raksturÄ«gajām iezÄ«mēm
  • VadÄ«bas sistēma robotu saimniecēm un robotu bārmeņiem
  • Noliktavas un piegādes vadÄ«bas sistēma lÄ«dz tirdzniecÄ«bas vietai
  • Piegādātāju attiecÄ«bu pārvaldÄ«bas sistēma (SURP)

Process:

AgrÄ«nās brÄ«dināŔanas sistēma atpazÄ«st cilvēkus, kas atstāj kuÄ£i. Ja cilvēks ir tÄ«ri noskÅ«ts, viņa viņu identificē kā jÅ«rnieku, ja cilvēkam konstatē bārdu, tad viņŔ tiek identificēts kā pirāts.

Ieejot krodziņā, viesis dzird savai kategorijai atbilstoÅ”u robota saimnieces sveicienu, piemēram: ā€œHo-ho-ho, dārgais pirāt, ej pie galdiņa Nr...ā€

Viesis dodas pie norādÄ«tā galdiņa, kur robots bārmenis viņam jau ir sagatavojis preces atbilstoÅ”i kategorijai. Bārmenis robots nodod informāciju noliktavas sistēmai, ka jāpalielina nākamā piegādes daļa; noliktavas IS, pamatojoties uz atlikuÅ”ajiem atlikumiem noliktavā, vadÄ«bas sistēmā Ä£enerē pirkuma pieprasÄ«jumu.

Lai gan agrÄ«nās brÄ«dināŔanas sistēmu, iespējams, ir izstrādājusi jÅ«su iekŔējā IT, bāra robotu pārvaldÄ«bas programmu, iespējams, ir izveidojis ārējs darbuzņēmējs tieÅ”i jÅ«su uzņēmumam. Un sistēmas noliktavu pārvaldÄ«Å”anai un attiecÄ«bām ar piegādātājiem ir pielāgoti iepakoti risinājumi no tirgus.

5. Denormalizācijas piemēri un tās ietekme uz programmatūras izstrādi

Veidojot biznesa procesu, aptaujātie mācÄ«bu priekÅ”metu eksperti vienbalsÄ«gi apgalvoja, ka visā pasaulē pirāti dzer rumu un Ä·emmē bārdu ar kaulu Ä·emmēm, bet jÅ«rnieki dzer tēju ar timiānu un vienmēr ir tÄ«ri noskÅ«ties.

Parādās klientu tipu katalogs ar divām vērtībām: 1 - pirāti, 2 - jūrnieki, kas ir kopīgs visai uzņēmuma informācijas ķēdei.

Klientu apziņoÅ”anas sistēma nekavējoties saglabā attēlu apstrādes rezultātu kā atpazÄ«tā klienta identifikatoru (ID) un tā veidu: jÅ«rnieks vai pirāts.

Atpazīts objekta ID
Klienta kategorija

100500
Pirāts

100501
Pirāts

100502
JÅ«rnieks

Atzīmēsim to vēlreiz

1. Mūsu jūrnieki patiesībā ir noskūti cilvēki
2. Mūsu pirāti patiesībā ir bārdaini cilvēki

Kādas problēmas Å”ajā gadÄ«jumā ir jānovērÅ”, lai mÅ«su struktÅ«ra censtos pēc treŔās normālās formas:

  • atribÅ«ta atomitātes pārkāpums ā€” klienta kategorija
  • sajaucot analizēto faktu un secinājumu vienā tabulā
  • fiksētas funkcionālās attiecÄ«bas starp dažādu entÄ«tiju atribÅ«tiem.

Normalizētā formā mēs iegūsim divas tabulas:

  • atpazÄ«Å”anas rezultāts noteiktu pazÄ«mju kopas veidā,

Atpazīts objekta ID
Sejas apmatojums

100500
Jā

100501
Jā

100502
Nē

  • klienta veida noteikÅ”anas rezultāts kā IS iegultās loÄ£ikas pielietojums, lai interpretētu noteiktos raksturlielumus

Atpazīts objekta ID
Identifikācijas ID
Klienta kategorija

100500
100001
Pirāts

100501
100002
Pirāts

100502
100003
JÅ«rnieks

Kā normalizēta datu uzglabāŔanas organizācija var veicināt IP kompleksa attÄ«stÄ«bu? Pieņemsim, ka jÅ«s pēkŔņi iegÅ«stat jaunus klientus. Lai tie ir japāņu pirāti, kuriem varbÅ«t nav bārdas, bet viņi staigā ar papagaiļu plecā, un vides aizsardzÄ«bas pirāti, kurus var viegli atpazÄ«t pēc Grētas zilā profila kreisajā krÅ«tÄ«s.

Vides pirāti, protams, nevar izmantot kaulu ķemmes un pieprasa analogu, kas izgatavots no pārstrādātas jūras plastmasas.

Programmas algoritmi ir jāpārstrādā atbilstoÅ”i jaunajiem ievadiem. Ja tiktu ievēroti normalizācijas noteikumi, tad dažās sistēmās bÅ«tu tikai jāpapildina ievades atseviŔķiem procesa atzariem un jāveido jauni zari tikai tiem gadÄ«jumiem un tajās IS, kur sejas matiem ir nozÄ«me. Bet, tā kā noteikumi netika ievēroti, jums bÅ«s jāanalizē viss kods visā ķēdē, kurā tiek izmantotas klienta tipa direktorija vērtÄ«bas, un skaidri jānosaka, ka vienā gadÄ«jumā algoritmam ir jāņem vērā profesionālis. klienta aktivitāte un citas fiziskas Ä«paŔības.

Tādā formā, kas meklē lai normalizētu, mēs iegūsim divas tabulas ar operatīvajiem datiem un divus direktorijus:

ERP datu bāzu denormalizācija un tās ietekme uz programmatÅ«ras izstrādi: kroga atvērÅ”ana Tortugā

  • atpazÄ«Å”anas rezultāts noteiktu pazÄ«mju kopas veidā,

Atpazīts objekta ID
Grēta uz kreisās krūtīm
Putns uz pleca
Sejas apmatojums

100510
1
1
1

100511
0
0
1

100512

1
0

  • klienta veida noteikÅ”anas rezultāts (lai tas bÅ«tu pielāgots skats, kurā tiek parādÄ«ti apraksti no direktorijiem)

Vai konstatētā denormalizācija nozÄ«mē, ka sistēmas nevar modificēt, lai tās atbilstu jauniem nosacÄ«jumiem? Protams, nē. Ja iedomājamies, ka visas informācijas sistēmas ir izveidojusi viena komanda ar nulles kadru mainÄ«bu, norises ir labi dokumentētas un informācija tiek nodota komandas iekÅ”ienē bez zaudējumiem, tad nepiecieÅ”amās izmaiņas var veikt ar niecÄ«gi mazu piepÅ«li. Bet, ja atgriezÄ«simies pie sākotnējiem problēmas apstākļiem, 1,5 tastatÅ«ras tiks izdzēstas tikai kopÄ«gu diskusiju protokolu drukāŔanai un vēl 0,5 - iepirkuma procedÅ«ru apstrādei.

IepriekÅ” minētajā piemērā tiek pārkāptas visas trÄ«s normālās formas, mēģināsim tās pārkāpt atseviŔķi.

Pirmās normālās formas pārkāpums:

Pieņemsim, ka preces tiek piegādātas uz jÅ«su noliktavu no piegādātāju noliktavām, paņemot, izmantojot vienu 1.5 tonnu smagu gazeli, kas pieder jÅ«su tavernai. JÅ«su pasÅ«tÄ«jumu apjoms ir tik mazs attiecÄ«bā pret piegādātāju apgrozÄ«jumu, ka tie vienmēr tiek izpildÄ«ti individuāli, negaidot ražoÅ”anu. Vai jums ir nepiecieÅ”amas atseviŔķas tabulas ar Ŕādu biznesa procesu: transportlÄ«dzekļi, transportlÄ«dzekļu veidi, vai pasÅ«tÄ«jumos izbraukuÅ”ajiem piegādātājiem ir nepiecieÅ”ams nodalÄ«t plānu un faktu?

Iedomājieties, cik daudz ā€œpapilduā€ savienojumu bÅ«s jāraksta jÅ«su programmētājiem, ja programmas izstrādei izmantosit tālāk norādÄ«to modeli.

ERP datu bāzu denormalizācija un tās ietekme uz programmatÅ«ras izstrādi: kroga atvērÅ”ana Tortugā

Pieņemsim, ka nolēmām, ka piedāvātā struktÅ«ra ir nevajadzÄ«gi sarežģīta, mÅ«su gadÄ«jumā plāna un fakta nodalÄ«Å”ana pasÅ«tÄ«juma ierakstā ir lieka informācija, un Ä£enerētā pasÅ«tÄ«juma specifikācija tiek pārrakstÄ«ta, pamatojoties uz saņemto preču pieņemÅ”anas rezultātiem, reta kļūda -neadekvātas kvalitātes preču ŔķiroÅ”ana un pienākÅ”ana tiek nokārtota ārpus IS.
Un tad kādu dienu tu redzi, kā visa kroga zāle ir piepildīta ar saŔutuŔiem un nekoptiem pirātiem. Kas notika?

Izrādās, augot jÅ«su biznesam, pieauga arÄ« patēriņŔ. Savulaik tika pieņemts vadÄ«bas lēmums, ka gadÄ«jumā, ja gazele ir pārslogota pēc tilpuma un/vai svara, kas bija ārkārtÄ«gi reti, piegādātājs slodzei pieŔķirs prioritāti par labu dzērieniem.

Nepiegādātās preces nonāca nākamajā pasÅ«tÄ«jumā un aizveda ar jaunu reisu, minimālā atlikuma klātbÅ«tne noliktavā krodziņā ļāva nepamanÄ«t trÅ«kstoÅ”os gadÄ«jumus.

Pēdējais konkurents slēdzās ostā, un pārdurtais gazeļu pārslodzes gadÄ«jums, kas tika apiets ar prioritāŔu noteikÅ”anu, pamatojoties uz pieņēmumu par minimālā bilances pietiekamÄ«bu un transportlÄ«dzekļa periodisku pārslodzi, kļuva par ierastu praksi. Izveidotā sistēma ideāli darbosies saskaņā ar tajā iestrādātajiem algoritmiem un tai bÅ«s liegta iespēja izsekot sistemātiskai plānoto pasÅ«tÄ«jumu neizpildei. Problēmu varēs atklāt tikai sabojāta reputācija un neapmierināti klienti.

Uzmanīgs lasītājs, iespējams, ir pamanījis, ka pasūtītais daudzums pasūtījuma specifikācijā (T_ORDER_SPEC) 2. un 5. sadaļā var atbilst vai neatbilst pirmās parastās formas prasībām. Tas viss ir atkarīgs no tā, vai, ņemot vērā izvēlēto preču sortimentu, vienā laukā var ietilpt būtībā dažādas mērvienības.

Otrās normālās formas pārkāpums:

Pieaugot jÅ«su vajadzÄ«bām, jÅ«s iegādājaties vēl pāris dažāda izmēra transportlÄ«dzekļus. IepriekÅ” minētajā kontekstā transportlÄ«dzekļu kataloga izveide tika uzskatÄ«ta par lieku, kā rezultātā visi datu apstrādes algoritmi, kas apkalpo piegādes un noliktavas vajadzÄ«bas, uztver kravas kustÄ«bu no piegādātāja uz noliktavu kā tikai 1,5 tonnas smagas lidmaŔīnas lidojumu. gazele. Tātad, vienlaikus ar jaunu transportlÄ«dzekļu iegādi, jÅ«s joprojām izveidojat transportlÄ«dzekļa direktoriju, bet, to pabeidzot, jums bÅ«s jāanalizē viss kods, kas norāda uz kravas kustÄ«bu, lai noskaidrotu, vai katrā konkrētajā vietā ir atsauces uz Ä«paŔībām no paÅ”a transportlÄ«dzekļa, no kura sākās uzņēmējdarbÄ«ba.

TreŔās normālās formas pārkāpums:

Kādā brÄ«dÄ« sākat veidot lojalitātes programmu, parādās ieraksts par pastāvÄ«go klientu. Kāpēc, piemēram, tērēt laiku materiālu skatu veidoÅ”anai, kas glabā apkopotus datus par pārdoÅ”anu individuālam klientam, lai tos izmantotu atskaitēs un pārsÅ«tÄ«tu uz analÄ«tiskajām sistēmām, ja lojalitātes programmas sākumā visu, kas interesē klientu, var ievietot klienta uzskaitē ? Un patieŔām, no pirmā acu uzmetiena, nav jēgas. Taču ikreiz, kad jÅ«su uzņēmums savieno, piemēram, jaunus pārdoÅ”anas kanālus, jÅ«su analÄ«tiÄ·u vidÅ« ir jābÅ«t kādam, kurÅ” atcerēsies, ka Ŕāds apkopoÅ”anas atribÅ«ts pastāv.

Veidojot katru jaunu procesu, piemēram, pārdoÅ”anu internetā, pārdoÅ”anu caur izplatÄ«tājiem, kas pieslēgti kopējai lojalitātes sistēmai, kādam ir jāpatur prātā, ka visiem jaunajiem procesiem ir jānodroÅ”ina datu integritāte koda lÄ«menÄ«. RÅ«pnieciskai datubāzei ar tÅ«kstoÅ” tabulām tas Ŕķiet neiespējams uzdevums.

Pieredzējis izstrādātājs, protams, zina, kā novērst visas iepriekÅ” minētās problēmas, taču, manuprāt, pieredzējuÅ”a analÄ«tiÄ·a uzdevums nav tās celt gaismā.

Es vēlos izteikt pateicÄ«bu vadoÅ”ajam izstrādātājam Jevgeņijam Jaruhinam par viņa vērtÄ«gajām atsauksmēm publikācijas sagatavoÅ”anas laikā.

Literatūra

https://habr.com/en/post/254773/
Konolija Tomasa, Bega Kerolaina. Datu bāze. ProjektÄ“Å”ana, ievieÅ”ana un atbalsts. Teorija un prakse

Avots: www.habr.com

Pievieno komentāru