Podatki so vedno struktura in vsebina, sintaksa in semantika. V okviru podatkovnih baz so to tabele, povezave med tabelami, poizvedbami in njihovimi rezultati. Ne moremo reči, da je prevladujoča ideja relacijskih baz podatkov idealna, vendar je praktična, priročna in vam omogoča, da opišete katerokoli področje uporabe.
Če je baza podatkov niz tabel, je sistem za upravljanje baz podatkov (DBMS) podpora več podatkovnih baz naenkrat in vsaka od njih ima ustrezno funkcionalnost v smislu upravljanja, delovanja in branja. Sčasoma je DBMS našel veliko precej specifičnih funkcij, ki se štejejo za de facto standard in imajo svoj jezik opisa, dela in vzorčenja.
Osnovna funkcionalnost baze podatkov
Podatkovne baze omogočajo prikaz podatkovnih nizov prek sistema tabel, določanje razmerij med tabelami, določanje zahtevanih poizvedb, obliko želenih rezultatov in zagotavljanje dveh različic dela:
) sprememba;
samo za branje.
Dejansko ni več potrebe po DBMS in vam ni treba zagotoviti dostopa do programske kode za upravljanje ali delo (sprememba ali branje). Uporabnik nima neposrednega dostopa do podatkov, vendar ima zaradi specifične kode širok spekter funkcionalnosti, ki jih izvaja DBMS.
Oblika, protokol in splošni algoritem za uporabo baze podatkov so vedno znani, čeprav uveljavljeni sistem razvrščanja DBMS kaže veliko različnih konceptov in možnosti izvajanja.
Koncepti sistemovupravljanje podatkov
Osnovni koncept, ki je seveda vodil že od svojega rojstva in se izboljšuje do danes, je temelj oblikovanja sistemov za upravljanje baz podatkov - relacijskih odnosov. DB je skupek tabel in povezav med njimi. Tako je bilo, vendar ne bo predolgo.
Drugi podatkovni modeli:
hierarhični;
omrežje;
ER-model (bistvo - komunikacija);
objektno usmerjena;
objektno-relacijski itd.
Imajo svoje niše, vendar vsaka od njih temelji na istem relacijskem odnosu. V bistvu je v različnih konceptih podatkov, organiziranih v podatkovnem sistemu, nedvoumno in očitno samo ena stvar: vsi podatki imajo vedno smisel. Kako prikazati vsebino formalnega modela računalniške baze podatkov? Sodeč po nekaj imen modelov baze podatkov, ni nobenega posebnega problema, vendar še vedno "čisti relacijski odnosi" najdejo točno tisto, kar ni praktična uporaba: kako imenovati rešeno nalogo obdelave podatkov, ki pridevnik priložiti imenu baze podatkov - ni pomembno, pomembno je naloga je rešena.
Klasifikacija sistemov za upravljanje podatkov
Zelo glavna kategorija, ki ima velik praktičen pomen: primernost sistema za reševanje problema. Tukaj lahko vse DBMS razdelite v štiri glavne skupine:
podatkovni model;
razvejanost;
načini dostopa;
stopnja univerzalnosti.
To je splošna klasifikacija sodobnih podatkovnih baz. Pojem fragmentacije je pomemben, čeprav semantično ni pomembno, kako porazdeljena je baza podatkov,da ima potrebno možnost dostopa.
Pomembni so tudi načini dostopa do podatkov: stran lahko zahteva informacije iz podatkovne baze, ki jo upravlja Oracle, vendar pridobivanje /pisanje tukaj ne bo enako kot pri uporabi MySQL. Stopnja univerzalnosti je relativni kriterij, vendar jo je treba v večini primerov upoštevati. Vsak projekt ne zahteva dinamike in visoke ravni varnostnega dostopa, zanesljivosti shranjevanja itd. Številne naloge zahtevajo razvoj področja uporabe. Izbira DBMS z omejeno funkcionalnostjo lahko v prihodnosti privede do nepotrebnih stroškov za zamenjavo sistema z omejenimi zmogljivostmi.
Funkcionalnost DBMS
V skladu z ustaljeno tradicijo imajo funkcije klasifikacije in DBMS pomembno vlogo pri razvoju tehnične naloge ali projekta IT, ki vključuje velike količine podatkov. V tem primeru lahko izraz "velik" pomeni raven tega (obdelavo slik) ali število zapisov (obdelava besedila).
Funkcionalnost naloge in pričakovana rešitev lahko postavita jasne zahteve. Zlasti izbor DBMS (razvrščanje po podatkih):
prikaz podatkov (video, avdio, besedilo, različne kombinacije);
format in mesto shranjevanja (lokalno, distribuirano);
uporabniki (eden, veliko).
Ta stran vprašanja vpliva le na nekatere pomembne točke v korist enega DBMS drugega. Obstaja veliko področij uporabe, za kateraizbor klasifikacije podatkovne baze po katerem koli merilu nima pomena. Na primer, izbira sistema za upravljanje spletnega mesta za namene razvoja spletnega mesta bo razvijalca postavila pred nedvoumno izbiro samo ene posebne podatkovne baze.
Velike baze podatkov in kompleksne povezave
Trenutna raven podatkovne baze (razvrstitev po pomenu in odgovornosti):
terabajtov informacij (ena velika datoteka, veliko majhnih datotek);
megabajtov (več datotek, ki opisujejo eno bazo podatkov in vsebuje podatke).
Toda pomen in odgovornost sta vedno velika, ne samo v prvem primeru. Veliko je odgovornih projektov, kjer majhne količine informacij sprejemajo odločitve.
Običajno prvo merilo opredeljuje kot absolutni vodja Oracla, drugi - MySQL. Imajo veliko skupnega, vendar veliko kardinalnih razlik. Ko gre za združevanje spletnega vira z bazo podatkov Oracle brez uporabe lastnih orodij in tehnologij, obstaja veliko vprašanj. Težko je povezati se - dolg čas ni nenavaden in pogosto le pogoj za dosego rešitve. Manj težav pri dostavi podatkov, ko se nahajajo v lokalnem omrežju strežnika MS SQL Server, do katerega je povezava na voljo prek več strojnih usmerjevalnikov. Dejansko so v praksi vse komponente pomembne: arhitektura DBMS, klasifikacija DBMS po funkcijah, vsestranskost povezave in pasovna širina komunikacijskih kanalov.
Dostop in varnost shranjevanja
Znanje DBMS, klasifikacija, teorija baz podatkov na splošno,praktične izkušnje in druge konceptualne točke so seveda pomembne. Zanesljivost komponente strojne opreme je danes zelo visoka, vendar je vprašanje kakovosti kode, še posebej njene semantike, še vedno pomembno. Zbirka podatkov lahko varno dostopa do vseh baz podatkov, toda kaj je z običajno prakso kopiranja podatkovnih baz za ustvarjanje varnostnih kopij?
Ta perverzna ideja je značilna za baze podatkov, ki se nahajajo v eni datoteki in v več datotekah. V prvem primeru bo izginotje enega bajta ali bita pokvarilo celotno datoteko, v drugem primeru pa bo nepopolna kopija opisa baze podatkov ali datotek, ki vsebujejo podatke, povzročila nepredvidljive posledice. Čudno je, da razvijalcem DBMS ni mar za ta dejstva, če pa so naredili potrebne korake in zaprli enkrat za vsa vprašanja o razpoložljivosti podatkov izven sistema upravljanja, bi nastala dilema: klasifikacija DBMS bi bila poenostavljena do te mere: (varno, varno, vedno je na voljo vse);
ni mogoče uporabiti (vse, kar upravlja razvijalec DBMS).
Ne morete nadzorovati vsega, bolj izkušenega programerja, več možnosti zapušča stranki. Zapiranje podatkov za zunanjo kontrolo in spremembo pomeni, da rešena naloga ni dolgo življenje. Vprašanje varnosti in razpoložljivosti podatkov je zunaj vsake odločitve. Nanaša se na infrastrukturo podjetja, lokalno omrežje, varnost na obrobju itd. Podatki, baze podatkov in njihovi sistemi upravljanja morajo biti čim bolj odprti in dostopni.spoštovanje uveljavljenih, dokazanih, dolgoletnih pravil in naravnih zahtev.
Socialni vidik DBMS
Glede na različne načine klasifikacije DBMS je treba posebno pozornost nameniti socialni komponenti v kontekstu teorije in njeni uporabi v praksi.
Ko so se na strežniku pojavila lokalna omrežja in baze podatkov, DBMS pa je omogočal dostop številnim uporabnikom, je bilo vse zelo preprosto: arhitektura datotečnega strežnika je zelo praktična, danes so:
datotečni strežnik; ]
odjemalski strežnik;
vgrajena podatkovna zbirka.
Tri strani ene medalje: ni pomembno, kje je v bistvu sama baza podatkov, kateri je izbran DBMS. , mora biti čim bolj mobilen in dostopen, vendar v okviru splošne varnosti pod strogim varovanjem, ne le v. \ t
Relacijski odnosi: perspektive
Obstoječe zamisli o DBMS, njihova klasifikacija, akumuliran edinstven potencial pri razvoju baze podatkov in razvoj baze podatkov. Teorije in praksa uporabe so nedvomne. Razvijalci DBMS in potrošnikov informacij so šli daleč, in z vsakim dnem se je dinamika izboljšav hitro pospešila. Koncept relacij se drži, še vedno močne pozicije in nobena druga arhitektura ali zamisel o dajanju ničesar ne bo. Toda, ali je pravilna za njeno zaroto: tabela je razmerje med podatki in razmerje med tabelami - ali je isti odnos?Zakaj naj bi bila glava v tabeli, in če ni podatkov, potem ni tabele? Zakaj je pravokotna miza vedno in podatki v njej strogi tip in velikost?
Za informacijski svet so značilne gladke oblike in ne le pravokotniki. Ni čas, da sprejmemo presenetljivo preprosto idejo: obstaja miza, v njej pa je klobuk ali ne - primer določenega primera. Koliko jih bo v tabeli vrstic - vedno je jasno: od začetka do omejitev določenega DBMS-a, zakaj tega pozitivnega ne morete pripisati številu stolpcev? Če uporabimo abstrakcijo, na katero sodi moderno objektno usmerjeno programiranje, v relacijske odnose, potem sledi zelo perspektivni korak: DBMS, v katerem ni pomembno, tabela ali preprosto podana, in če je tabela, ki jo bo in bo tam. vrstico ali stolpec in kako bodo na svoji ravni medsebojno povezani - vprašanje uporabe. Kako bo vse povezano z vsemi podatki in tabelami - tudi vprašanje obsega, ne pa kompetence razvijalca, ali DBMS ali kodo, ki jo uporablja.
Pomembni so tudi načini dostopa do podatkov: stran lahko zahteva informacije iz podatkovne baze, ki jo upravlja Oracle, vendar pridobivanje /pisanje tukaj ne bo enako kot pri uporabi MySQL. Stopnja univerzalnosti je relativni kriterij, vendar jo je treba v večini primerov upoštevati. Vsak projekt ne zahteva dinamike in visoke ravni varnostnega dostopa, zanesljivosti shranjevanja itd. Številne naloge zahtevajo razvoj področja uporabe. Izbira DBMS z omejeno funkcionalnostjo lahko v prihodnosti privede do nepotrebnih stroškov za zamenjavo sistema z omejenimi zmogljivostmi. 
