1. Datubāze (Database)
Datu/informācijas kopums, kas tiek uzskatīts kā viena loģiska vienība. Kā jau tas parasti – pats pirmais, kas darbā ar datubāzēm jāatceras – tās ir dažādas. Lai gan formālajā definīcijā īpašas atšķirības nav, tomēr, piemēram, Oraclē datubāze sastāv no loģiskās un fiziskās struktūras, tas ir viss failu kopums, kas pastāvīgi glabājas serverī un ko instance (procesi un atmiņa uz servera) startējoties atver. Savukārt, SQL Serverī Datubāze ir vairāk kā viens loģisks lietotājs, kam pieder noteikti objekti, piemēram, tabulas un skatījumi un Oraclē, tam atbilst jēdziens shēma (Schema).
2. Tabulas (Table)
Tabulas ir relāciju datubāzes pamatvienība, kurā glabā datus. Katrai tabulai ir nosaukums. Katrai tabulai ir fiksēts skaits kolonu (vismaz viena) un parasti neierobežots skaits ierakstu. Tabulu piemēri – Organizācijas, Personas, Adreses.
3. Kolonas (Column)
Kolona ir kādas tabulas vai skatījuma atribūts, kam ir savs nosaukums un noteikts datu tips. Vienā kolonā parasti tiek glabāti dati, kuri pēc sava mērķa un sūtības ir vieni un tie paši. Kolonu piemēri Personu tabulai – Vārds, Uzvārds, Personas kods.
4. Ieraksti (Row)
Ieraksts ir loģiski saistīta datu kopa tabulā, kur visi ieraksti sastāv no vienām un tām pašām kolonām. Ieraksta piemērs Personas tabulā Jānis, Bērziņš, 01010112345.
5. Skatījumi (View)
Skatījums ir virtuāla vai loģiska tabula datubāzē, kas nesatur datus, bet ir balstīts uz vaicājumu. Izmainot datus tabulā, attiecīgi mainās arī dati skatījumā. Skatījumus veido dažādu iemeslu dēļ, no kuriem populārākie varētu būt, lai nebūtu jāraksta vienmēr bieži izmantots vaicājums, bet tā vietā izmantot skatījumu, un ierobežot pieejas tiesības lietotājiem izmantojot skatījumus, kas ierobežo pieejamo datu kopu. Skatījuma piemērs Personas adreses, kas kombinē (join) datus no Personu un Adrešu tabulām.
6. Indeksi (Index)
Indeksi ir datu struktūras, kuru primārais uzdevums ir ātri atlasīt noteiktus datus tabulā. Indeksi parasti tiek veidoti uz vienas vai vairākām kolonām tabulā. Gluži kā terminu indekss grāmatā, kas norāda kurā(-s) lappusē(-s) ir atrodams noteiktais termins, tā arī datubāzē indekss norāda kurā ierakstā ir atrodama Persona ar Vārdu Jānis. Bez indeksa nāktos skanēt cauri visu tabulu. Piemērs – indekss uz kolonu Vārds tabulā Persona, ļauj ātri atrast visu personu ierakstus ar noteiktu vārdu. Vairāk par indeksiem, to uzbūvi un pielietojumu lasīt šeit.
7. Ierobežojumi (Constraint)
Ierobežojumi nodrošina biznesa prasību un datu integritātes īstenošanu datubāzē. Ierobežojumi ir vairāku veidu, parastākie ir šādi:
Nav null (Not null) – pārbaudes ierobežojuma speciālgadījums, kolonai ir jābūt netukšai.
Primārā atslēga (Primary key) – unikāls veids kā identificēt ierakstu, sastāv no vienas vai vairākām kolonām. Piemēram, Personas kods Personai.
Unikālā atslēga (Unique key) – atšķirībā no Primārās atslēgas kolona var būt tukša, bet visām, netukšajām vērtībām (vērtību kombinācijām) ir jābūt unikālām, piemēram, Vārds, Uzvārds, Dzimšanas datums un Dzimšanas vieta personai.
Ārējās atslēgas (Foreign key) – vērtību kopa ir ierobežota ar citas tabulas primārās vai unikālās atslēgas vērtību kopu, piemēram, adreses identifikators Personu tabulā, kas norāda personas adresi.
Pārbaudes ierobežojums (Check constraint) – vienai vai vairākām kolonām jāatbilst noteiktai loģiskai izteiksmei, piemēram, personas dzimšanas datums nedrīkst būt mazāks kā 1900. gada 1. janvāris.
8. Saglabātās procedūras, funkcijas, pakotnes (Stored procedure, function, package)
SQL teikumu un procedurālu elementu (nosacījumi, cikli, mainīgie, to definēšana, vērtību piešķiršana utt.) kopums, kas tiek saglabāts datubāzē un kam tiek piešķirts noteikts nosaukums. Tādējādi šādu saglabātu procedūru ir iespējams izpildīt datubāzē to izsaucot no jebkura klienta. Saglabātas procedūras piemērs – mēnešalgas aprēķins uzņēmuma darbiniekam balstoties uz mēneša laikā ievadīto informāciju par nostrādātajām stundām. Vairāk par saglabātajām procedūrām.
9. Trigeri (Trigger)
SQL teikumu un procedurālu elementu kopums, kas tiek automātiski izpildīts, pēc vai pirms kāda noteikta notikuma. Notikumi pamatā ir divu veidu – datu manipulācijas valodas teikums (Insert, Update, Delete), kas veic izmaiņas noteiktā tabulā vai Datu definēšanas valodas teikums. Dažādās datubāzēs iespējamie trigeru veidi ir dažādi. Trigera piemērs – katrai rindiņai, kas tiek pievienota tabulai, automātiski atsevišķā kolonā tiek saglabāts lietotāja vārds, kas to izdarījis.
10. Transakcijas (Transaction)
Izmaiņu kopums datubāzē, kur tām ir jāatbilst četrām (ACID, no angļu valodas pazīmju pirmajiem burtiem) pazīmēm:
1) Atomitāte, atomaritāte (Atomicity) – visām izmaiņām ir vai nu jātiek izpildītām, vai arī jātiek atceltām, piemēram, naudas pārskaitīšana no viena konta otrā nozīmē naudas izņemšanu no pirmā konta un naudas pieskaitīšanu otrajam kontam, ja tiks izpildīta tikai viena no šīm darbībām, tad iegūtais rezultāts būs nekorekts.
2) Konsistence, saskanīgums (Consistency) – transakcijas sākumā un beigās netiek pārkāpti ierobežojumi, piemēram, ja konta stāvoklim vienmēr jābūt lielākam par 0), tad naudas pārskaitījums, kas konta stāvokli pazeminās zem nulles, netiks pieļauts.
3) Izolētība (Isolation) – transakcijas izmaiņas nav redzamas citās operācijās, piemēram, naudas pārskaitīšanas laikā citi lietotāji nekad neredzēs stāvokli, kad nauda ir abos kontos, vai tieši otrādi tā nav nevienā kontā.
4) Ilgstamība, paliekamība (Durability) – garantija, ka tiklīdz, kā transakcija ir pabeigta, tās izmaiņas netiks zaudētas pat datubāzes avārijas rezultātā.
11. Tiesības (Permission, Privilege)
Atļauja veikt noteiktu operāciju. Pamatā dalās divās daļās – tiesības veikt noteiktu darbību datubāzē, piemēram, izveidot tabulu, vai tiesības veikt noteiktas datu manipulācijas ar esošiem objektiem, piemēram, dot lasīšanas tiesības uz tabulu Personas citiem datubāzes lietotājiem.
12. Lomas (Role)
Tiesību kopums, kam piešķirts vārds.
13. Bloķēšana (Locking)
Tiesību aizliegums vienlaicīgi darboties ar vieniem un tiem pašiem ierakstiem. Parasti darbības dalās divās daļās – lasīšanā (DML Select teikums) un rakstīšanā (DML Insert, Delete, Update). Tas par ko parasti interesējas vai datubāzes lasītāji bloķē rakstītājus un rakstītāji bloķē lasītājus, t.i. vai vienas tabulas rindu vienlaicīgi var viens vai vairāki lietotāji lasīt un viens lietotājs rakstīt. Parasti, lasītāji citus lasītājus nebloķē, un rakstītāji savukārt citus rakstītājus bloķē, t.i. vienlaicīgi vienas tabulas vienu rindu var lasīt no vairākiem pieslēgumiem, bet rakstīt var tikai viens. Bez tam mehānisms cik lielā līmenī notiek bloķēšana arī ir atšķirīgs (ierakstu, datu bāzes bloku, tabulu).
14. Strukturēta vaicājumu valoda (SQL)
Īss apraksts paskaidrots šeit.
SQL elementu un konstrukciju indekss ir šeit.
15. Datu manipulēšanas, definēšanas, kontroles un transakciju kontroles valoda (DML, DDL, DCL, TCl)
16. Tālākā lasāmviela
- Wikipedia – relational database;
- Joe Celko “Thinking in Sets” – prezentācijas par datubāzu teoriju;
- Dažu relāciju datubāzu vadības sistēmu uzskaitījums.
Datubāzes 
4 gadi studiju pa kaaju…
visu laiku tika macits ka view -> skats nevis skatijums
tie Ierobežojumi arii kka manuprat neatbilst patiesibai
Ne viss, kas rakstīts internetā, ir taisnība un nekam nevar ticēt 100%, tai skaitā arī tam, kas ir šai vietnē 🙂
Bet skatoties http://www.termini.lv view ir tulkots kā skatījums un constraint netiek tulkots nekādi, savukārt tildes vārdnīcā, kas gan, protams, nav nekāda mega autoritāte, constraint tomēr ir ierobežojums.
Ak jel, skatiijums..
..nezinu, kaut kaa mani tas vairs nepaarsteidz.. 🙂
he he labs, bet terminos ir skatijums 😀 😀 😀
# view
Personālie datori. Angļu-latviešu-krievu skaidrojošā vārdnīca. Sast.: A. Baums, J. Borzovs, A. Gobzemis, I. Freibergs, G. Fricnovičs, I. Ilziņa – A/s Dati – 1998 – 255 lpp.
(D98)
skatījums
Personālie datori. Angļu-latviešu-krievu skaidrojošā vārdnīca. Sast.: A. Baums, J. Borzovs, A. Gobzemis, I. Freibergs, G. Fricnovičs, I. Ilziņa – A/s Dati – 1998 – 255 lpp.
(D98)
Vai locking tiešām ir bloķēšana? varbūt resursu slēgšana?
Vispār ar tiem terminu tulkojumiem tā traki.. pēc
http://termini.lza.lv/term.php?term=locking&list=locking&lang=
sanāk, ka locking = sprostojums..
tad savukārt acquire lock būtu = saņemt sprostojumu? 🙂
Nu bet ja tur paskatās, tad sprostojums ir mašīnbūvei 😉 Bet locking action tulkots kā bloķējoša darbība. Ziepes sākas tad, ka piemēram Oraclē nav tikai lock, bet ir arī tāds jēdziens kā latch, kurš ir tāds kā viegls blociņš (lightweight lock) 🙂
Par SQL Server..
“Unikālā atslēga (Unique key) – atšķirībā no Primārās atslēgas kolona var būt tukša, bet visām, netukšajām vērtībām (vērtību kombinācijām) ir jābūt unikālām, piemēram, Vārds, Uzvārds, Dzimšanas datums un Dzimšanas vieta personai.”
Te sanāk tā interesanti. Ja kolona “Vārds” ir ar unikālu atslēgu, tad tādā tabulā var glabāties tikai viena rinda ar “Null” vērtību kolonā “Vārds”..
Tātad, lai arī Null pēc idejas nav vienāds ar Null, pārbaudot unikalitāti Null skaitās vienāds ar Null.
Njā interesanti.
create table uk_test (vards varchar(10));
alter table uk_test add constraint vrd_uk unique (vards);
Command(s) completed successfully.
insert into uk_test values (null);
(1 row(s) affected)
insert into uk_test values (null);
Msg 2627, Level 14, State 1, Line 1
Violation of UNIQUE KEY constraint 'vrd_uk'. Cannot insert duplicate key in object 'dbo.uk_test'.
The statement has been terminated.
select COUNT(*) from uk_test;
-----------
1
(1 row(s) affected)
Bet oraclē tas pats:
SQL> create table uk_test (vards varchar(10));
Table created.
SQL> alter table uk_test add constraint vrd_uk unique (vards);
Table altered.
SQL> insert into uk_test values (null);
1 row created.
SQL> insert into uk_test values (null);
1 row created.
SQL> insert into uk_test values (null);
1 row created.
SQL> select COUNT(*) from uk_test;
COUNT(*)
----------
3
Tai pašā laikā, protams uz NENULL vērtībām ir kļūda:
SQL> insert into uk_test values ('a');
1 row created.
SQL> insert into uk_test values ('a');
insert into uk_test values ('a')
*
ERROR at line 1:
ORA-00001: unique constraint (GINTS.VRD_UK) violated
Kā redzams kārtējo reizi jāsaprot ka DBVS ir dažādas. BTW nezināju par šo, ļoti labs kārtējais arguments kāpēc nevar uzskatīt, ka mūsu aplikācijai ir vienalga kāda būs DBVS apakšā.
Noderīgs raksts! Paldies.
Jautājums par transakcijām.
Ir SQL Server, kam ir linkotais server- Oracle.
–
SQL Server daļā ir procedūra transakcijā, kas izsauc Oracle procedūru- tātad, sākas distributed transaction.
Oracle pusē ir update tabulā, tur transakcija sākas bez “Begin Transaction”, bet ir Commit. Es saprotu, ka šajā gadījumā Commit attieksies uz visu transakciju? Respektīvi- būs kļūda, jo Oracle šajā gadījumā nav nekādu tiesību beigt SQL Server sākto transakciju.. Pareizi? Un šajā gadījumā- Oracle nav jābūt nekādiem “Commit-iem”?
–
SQL Server pusi, šķiet, saprotu: http://www.sqlblog.lv/2011/09/ligzdotas-nested-transakcijas.html
Oraclē transakcija sākas automātiski ar pirmo izmaiņu un beidzas ar commit vai rollback, tur nekāds begin transaction nav nepieciešams.
Man grūti komentēt, kas šajā gadījumā notiks, vai tā tiešām arī Oraclesprāt būs tiešām distributed transaction, jo normāli par tādām uzskatā, tādas transakcijas, kas izmanto datubāzes linku (oracle objekts), vai šādā veidā pielinkots serveris arī tam atbilst.
Sīkāk par tām šeit
http://download.oracle.com/docs/cd/E11882_01/server.112/e25789/transact.htm#CNCPT1125
Iespējams, ka vajag vienkārši notestēt 🙂 Vienu commit pielikt/noraut jau nav grūti 🙂
Kāpēc Oracle nelamājas, ja Commit/Rollback notiek iekš citas procedūras, kā tā, kas sākusi transakciju? (ligzdoto transakciju gadījumā).
Tā ir tā kā “fīča”?
droši vien diezgan stulbi jautājumi, bet man izskatās, ka dēļ šīs īpašības var uzrauties uz ļoti daudzām visai mistiskām problēmām..
Oraclē principā nav tāda jēdziena nested transactions (neesmu gan vēl izpētījis, kas tas īsti ir SQL Serverī).
Kā jau rakstīju jebkura transakcija sākas ar kaut kādām izmaiņām un beidzas ar commit vai rollback.
Transakcija var sākties jebkur – atsevišķā SQL teikumā vai procedūrā un beigties arī jebkur – ar atsevišķu commit vai rollback, vai tas arī var būt iekļauts procedūrā.
Transakcija ir visas sesijas ietvaros nevis tikai vienas procas robežās, piemēram.
Pa vidu var būt savepoint un tad var teikt rollback to xxx;
Vēl ir tāds jēdziens kā autonomās transakcijas, kad kādā koda gabalā var izsaukt citu f-ju vai procedūru (standalone vai pakotne), kura darbojas autonomajā transakcijā, t.i., galvenās transakcijas darbība tiek apturēta, ir palaista jauna pilnīgi neatkarīga transakcija un tai ir obligāti jābeidzas ar commit vai rollback. Kad autonomā tiek pabeigta (piemēram, veiksmīgi), tad darbība atgriežas izsaucošajā un tās apstiprināšana vai atcelšana nekādi vairs neietekmē autonomajā transakcijā veiktās darbības. To parasti izmanto piemēram kļūdu logošanā, lai piefiksētu kļūdu, bet pašā galvenajā transakcijā veiktu atriti. Ar autonomajām transakcijām ir jābūt ļoti uzmanīgam, jo to rezultāts ir neatgriezenisks un diezgan reti to PATIEŠĀM vajag.
Autonomās transakcijas izklausās ļoti laba reti vajadzīgā lieta (un par šo jautājumu vienreiz jau galva sāpēja)- SQL Server to tik skaistā veidā nedara. Risinājums bija CLR procedūra.
Lai nu kā- tas, ka Commit var būt paslēpies kādā no procedūrām, ko es izsaucu, man kaut kā ļoti nepatīk..
Tā nu tas ir – katra DBVS ir savādāka. Bet nu – ja pats raksti abus galus, tad vari to kontrolēt. Ja otru galu rakstā kāds cits, tad iespaido viņu ar e-pastiem, zvaniem utt jebkādā citā veidā informē viņu par iespējamiem riskiem un sekām 😉