Tranzactii.

Optiuni avansate
Tranzacții
Concept. Noțiuni generale
Tranzacţiile sunt folosite pentru a conserva integritatea bazelor de date, prin garantarea faptului
că un set de instrucţiuni SQL se execută în totalitate sau nu se execută deloc. Cu alte cuvinte,
o tranzacţie este un bloc de instrucţiuni SQL. De asemenea, se pot și anula anumite instrucţiuni
specificate. Pot exista şi puncte de salvare până la care se poate executa o revenire, adică o
anulare a instrucţiunilor specficate de la acel punct înainte.

Un SGBD deservește mai mulți utilizatori simultan, astfel că datele din tabele sunt accesate
concurent de mai mulți utilizatori. Astfel, este necesar să existe garanția că, indiferent de
numărul de accesări simultane ale bazei de date și de diversele operații pe care ei le efectuează
pe baza de date, este asigurată consistența și integritatea datelor.

Tranzacțiile au acest rol, de a garanta integritatea datelor, asigurând faptul că un set de

instrucțiuni aflat în interiorul unei tranzacții, fie se execută în totalitate, fie nu se execută deloc.

Astfel, în cazul în care au intervenit diverse probleme la execuția instrucțiunilor, ele nu se vor
executa, iar integritatea bazei de date nu este afectată.

O tranzacție reprezintă un set de instrucțiuni SQL care împreună formează o unitate de lucru.
Se utilizează pe baza de date și reprezintă propagarea uneia sau mai multor modificări în baza
de date.

O tranzacţie (transaction) este o unitate logică de prelucrare indivizibilă (atomică) a datelor

unei baze de date prin care se asigură consistenţa acesteia.

Tranzacțiile se folosesc doar pentru instrucțiunile de manipulare a datelor care afectează

tabelele bazelor de date. Deci, este vorba de instrucțiunile de manipulare INSERT, UPDATE
și DELETE.

Instrucțiunea de manipulare SELECT se poate folosi în cadrul tranzacțiilor, deși rularea

instrucțiunilor SELECT nu afectează înregistrările din tabele. Pot fi extrase, în interiorul unei
tranzacții date introduse, chiar dacă nu sunt comise (stocate definitiv) în baza de date.

Limbajul de Control al Tranzacțiilor (Transaction Control Language - TCL) este format

din acele elemente ale limbajului SQL care sunt destinate asigurării siguranței tranzacționării.
 Tranzacțiile permit efectuarea operațiunilor critice – cum ar fi accesul concurent la date,
modificarea unor porțiuni foarte importante ale datelor, modificări ale datelor care trebuie să
fie atomice – în siguranță, astfel încât, după execuția completă a tranzacției, starea datelor este
predictibilă, acestea aflându-se fie în starea inițială (adică nu s-a efectuat nici o modificare),
fie în starea finală, adică starea dorită la momentul inițierii tranzacției.

O tranzacție se pornește la începutul setului de instrucțiuni, iar în cazul în care una dintre
instrucțiuni eșuează, nu se va efectua nici o modificare asupra bazei de date. Aceasta înseamnă
că setul de instrucțiuni care reprezintă o tranzacție este unitar. Astfel, într-o tranzacție se poate
condiționa executarea unor instrucțiuni de executarea cu succes a celor precedente. În timpul
unei tranzacții, doar utilizatorul care a inițiat tranzacția are acces la datele respective.

Instrucțiunile de definire (descriere) a datelor (creare de tabele, ștergere de tabele, etc., adică
instrucțiuni CREATE, ALTER, DROP) se pot regăsi în interiorul unei tranzacții, dar ele nu
vor fi anulate, dacă în interiorul tranzacției se încearcă o reveniere, adică o anulare a
comenzilor executate anterior. Aceste comenzi ce afectează structura unei tabele se execută
(comit) automat în baza de date.

O tranzacție începe cu comanda START TRANSACTION. În interiorul unei tranzacții, pe

lângă instrucțiunile SQL ce sunt conținute de tranzacție, pot fi menționate trei comenzi
specifice tranzacțiilor.

Astfel, o tranzacție se va încheia cu COMMIT dacă nu s-a înregistrat nici o problemă și se

dorește salvarea instrucțiunilor executate până la acel moment sau se va încheia cu
ROLLBACK dacă se dorește anularea comenzilor executate.

În interiorul unei tranzacții mai pot fi definite puncte de salvare prin comanda SAVEPOINT,
astfel că, o revenire (ROLLBACK) se poate face până la începutul tranzacției, anulând tot
ceea ce s-a executat în interiorul tranzacției sau până la un punct de salvare (SAVEPOINT),
anulând acele comenzi cuprinse între definirea punctului de salvare indicat și comanda
ROLLBACK.

O tranzacție este o operație indivizibilă de acces la baza de date care fie execută cu succes
toate operațiile (instrucțiunile), caz în care se vor valida modificările efectuate asupra bazei de
date (adică se va realiza COMMIT la finalul tranzacției), fie nu poate efectua din diferite
motive toate operațiie și va fi anulată (adică se încheia tranzacția cu ROLLBACK).

Proprietățile tranzacțiilor
Sunt patru prorpietăți de bază ale tranzacțiilor pe care le vom defini în continuare. Este vorba
despre următoarele proprietăți:

· Atomicitate (Atomicity) – asigură faptul că toate operațiile (instrucțiunile) se execută cu

succes. Dacă una dintre operații eșuează, atunci toate operațiile trebuie anulate. Doar atunci
 când toate operațiile sunt executate cu succes se vor salva în baza de date rezultatele tuturor
instrucțiunilor plasate în tranzacție.
· Consistență (Consistency) – asigură că numai operațiile efectuate cu succes vor produce
modificări asupra bazei de date, adică datele care suferă modificări nu vor putea fi expuse
decât fie în starea lor inițială, fie după ce modificările au fost salvate (tranzacția s-a încheiat cu
succes).
· Izolare (Isolation) – datele procesate de tranzacție nu trebuie să fie vizibile utilizatorilor
înainte sau în timpul tranzacției, acest lucru oferă posibilitatea ca anumite tranzacții să ruleze
independent de alte tranzacții. Este permisă setarea unui anumit grad de izolare în care se
setează:
· dacă se pot citi datele neîncheiate;
· dacă se pot modifica datele incluse în cadrul tranzacției.
· Durabilitate (Durability) – asigură faptul ca rezultatele unei tranzacții să rămână (să persiste)
chiar dacă sistemul suferă vreo defecțiune.

Cele patru proprietăți sunt denumite, prescurtat, ACID (de la prima literă a fiecărei proprietăți).
În continuare vom dezvolta cele aceste proprietăți (ACID) ale tranzacțiilor pentru a înțelege
mai bine la ce se referă ele.

Atomicitatea reprezintă proprietatea unei tranzacții de a reprezenta o unitate de execuție

indivizibilă, adică de a executa fie toate instrucțiunile, fie nimic. Astfel, toate acțiunile
(operațiile) din interiorul unei tranzacții sunt considerate un tot unitar (o unitate) care
garantează execuția în totalitate sau deloc a unității.

Consistența reprezintă proprietatea unei tranzacții de a efectua modificări corecte asupra bazei
de date. O tranzacție executată cu succes (COMMIT) transformă o bază de date dintr-o stare
consistentă (corectă) într-o altă stare consistentă. Starea unei baze de date este consistentă
dacă respectă toate regulile de integritate (constrângerile) implicite sau explicite.

O tranzacție trebuie să asigure consistența unei baze de date în diferite situații:

· tranzacția se execută individual sau concurent cu alte tranzacții;
· apar defecțiuni ale sistemului în cursul execuției tranzacției.

Izolarea reprezintă proprietatea unei tranzacții de a face vizibile modificările efectuate doar
după ce a fost validată (după ce s-a efectuat COMMIT). Astfel, dacă un utilizator execută o
serie de operații, dar tranzacția nu a fost încă validată (comisă), deci, nu s-a executat
COMMIT, atunci nici un alt utilizator nu va vedea modificările operate de acesta.

Doar utilizatorul care execută diverse operații are posibilitatea de a vizualiza modificările
produse de aceste operații în baza de date înainte de validarea tranzacției (de a se efectua
COMMIT). Astfel, operațiile dintr-o tranzacție sunt izolate, alți utilizatori nu au acces la ele
înainte de validarea tranzacției.
Durabilitatea reprezintă proprietatea unei tranzacții, prin care, după validare (după ce se
efectuează COMMIT), modificările efectuate de tranzacție în baza de date nu se mai pierd din
cauza unei defectări ulterioare a sistemului.

De asemenea, după ce s-a executat COMMIT într-o tranzacție, nu se mai poate executa
ROLLBACK, adică nu va mai avea nici un efect o instrucțiune de anulare, operațiile au fost
deja validate prin COMMIT.

Este valabilă și reciproca, dacă s-a executat ROLLBACK, deci, s-au anulat operațiile efectuate
în tranzacție, nu va mai avea nici un efect execuția unei instrucțiuni COMMIT. Ar trebui, din
nou, executate instrucțiunile și abia apoi validate (comise).

Utilizare tranzacții
Sintaxa prin care este pornită o tranzacție și este încheiată cu succes (COMMIT) sau anulată
(ROLLBACK) este următoarea:

START TRANSACTION
instrucțiuni
COMMIT | ROLLBACK;

În interiorul unei tranzacții se execută o serie de instrucţiuni, după care se execută una din cele
două comenzi specificate, COMMIT pentru salvarea instrucţiunilor executate până la acel
moment sau ROLLBACK pentru anularea instrucţiunilor precedente.

Există și varianta de a defini puncte de salvare (SAVEPOINT) pe parcursul tranzacției și de a

executa reveniri până la un anumit punct de salvare. Prezentăm și un astfel de exemplu:

START TRANSACTION
set_instrucțiuni1
SAVEPOINT nume_punct1;
set_instrucțiuni2
SAVEPOINT nume_punct2;
set_instrucțiuni3
ROLLBACK TO nume_punct2;
...
COMMIT | ROLLBACK;

În exemplul anterior, sunt definite trei puncte de salvare (SAVEPOINT), fiecare după câte un
set de instrucțiuni. La un moment dat se execută o revenire până la un anumit punct de salvare
(nume_punct2), aceasta înseamnă că vor fi anulate instrucțiunile executate după acel punct de
salvare și până la comanda ROLLBACK, în situația noastră setul de instrucțiuni denumite
set_instrucțiuni3.
În final, avem posibilitatea de a încheia tranzacția prin COMMIT care va duce la salvarea
seturilor de instrucțiuni ce nu au fost anulate (asupra cărora nu s-a realizat o revenire), adică,
set_instrucțiuni1 și set_instrucțiuni2, sau să anulăm toate instrucțiunile efectuate în
tranzacție prin ROLLBACK.

Iată și un alt exemplu în care se face o revenire până la un alt punct de salvare, nu până la
ultimul definit, ca în exemplul precedent, fapt ce va duce la anularea mai multor seturi de
instrucțiuni, iar după această revenire mai sunt executate alte instrucțiuni până la finalizarea
tranzacției.

START TRANSACTION
set_instrucțiuni1
SAVEPOINT nume_punct1;
set_instrucțiuni2
SAVEPOINT nume_punct2;
set_instrucțiuni3
ROLLBACK TO nume_punct1;
set_instrucțiuni4
COMMIT | ROLLBACK;

În acest exemplu se face o revenire până la punctul de salvare nume_punct1, ce va duce la

anularea seturilor de instrucțiuni denumite set_instrucțiuni2 și set_instrucțiuni3. După
această revenire se mai execută un set de instrucțiuni, iar la final avem posibilitatea să încheiem
tranzacția prin COMMIT, fapt ce va duce la salvarea în baza de date a seturilor de instrucțiuni
asupra cărora nu s-a efectuat nici o revenire, este vorba despre set_instrucțiuni1 și
set_instrucțiuni4, sau, avem posibilitatea să anulăm și aceste seturi de instrucțiuni prin
efectuarea ROLLBACK.

Prin utilizarea tranzacţiilor, așa cum am menționat anterior, ne asigurăm asupra integrităţii
datelor, deoarece ştim sigur că un set de instrucţiuni fie s-a executat în totalitate, fie nu s-a
executat deloc, astfel că nu putem avea efecutate doar anumite operaţii iar altele nu şi astfel să
avem date alterate în baza noastră de date.

AUTOCOMMIT
În MySQL, opțiunea AUTOCOMMIT este activată implicit, adică, dacă nu suntem în
interiorul unei tranzacții, deci, nu am pornit o tranzacție cu instrucțiunea START
TRANSACTION, dar au fost executate instrucțiuni de manipulare a datelor ce afectează
conținutul tabelelor (INSERT, UPDATE sau DELETE), atunci se face COMMIT automat,
deci, se salvează definitiv în tabele modificările efectuate.

Pentru sesiunea curentă se poate dezactiva această opțiune prin stabilirea modului
AUTOCOMMIT la valoarea 0. Pentru această dezactivare va fi executată următoarea
comandă:
SET AUTOCOMMIT = 0;
După dezactivarea acestei opțiuni, pentru efectuarea operațiilor de manipulare care afectează
conținutul bazei de date, este necesară utilizarea tranzacțiilor. Altfel, operațiile de manipulare
asupra bazei de date (INSERT, UPDATE, DELETE) nu vor conduce la rezultate persisitente
în baza de date.

Se poate reacitva opțiunea AUTOCOMMIT, fapt ce duce, practic la o revenire la starea

implicită, iar pentru aceasta se va executa comanda:
SET AUTOCOMMIT = 1;

Folosirea unei tranzacții, adică specificarea explicită a comenzii de pornire a unei tranzacții
(START TRANSACTION) va dezactiva modul AUTOCOMMIT pentru seria de instrucțiuni
din interiorul tranzacției.

Modul AUTOCOMMIT va rămâne dezactivat până la finalizarea tranzacției prin executarea

uneia din comenzile COMMIT sau ROLLBACK, după care se reactivează automat, astfel
încât pot fi efectuate operații de manipulare în afara tranzacțiilor, fără a fi necesară o altă
operațiune.

În concluzie, tranzacțiile sunt utile atunci când se operează cu instrucțiuni ce afectează

integritatea bazelor de date. Utilizarea lor garantează faptul că nu vor fi alterate datele existente
în baza de date la momentul inițierii tranzacției, iar baza de date, în urma efectuării unei
tranzacții, va rămâne într-o stare consistentă (corectă), fie în starea inițială, care era corectă, fie
într-o nouă stare, care la rândul ei este consistentă (corectă).

Opțiuni avansate. Clauze posibile ale constrângerii

de integritate referențială
Sintaxa generală a unei definiții de cheie externă (FOREIGN KEY) este următoarea:

[CONSTRAINT nume_constrângere] FOREIGN KEY (nume_coloană)

REFERENCES nume_tabelă(nume_coloană)
[ON UPDATE acțiune] [ON DELETE acțiune];

Așadar, față de ceea ce cunoașteam până acum despre constrângerea FOREIGN KEY, mai
observăm aici două clauze posibile – ON UPDATE, respectiv, ON DELETE, după fiecare
astfel de clauză putându-se specifica o acțiune.
 Cele două clauze reprezintă acțiunile ce se vor desfășura în cazul în care se realizează operația
UPDATE, respectiv, DELETE, asupra valorilor din coloanele ce sunt referențiate în
constrângere.

Acțiunile posibile în cadrul clauzelor ON UPDATE, respectiv, ON DELETE, sunt

următoarele:
· CASCADE – această acțiune va produce următorul efect: la modificarea înregistrării din tabela
părinte (cea în care coloana este PRIMARY KEY) sunt afectate automat (în cascadă) toate
înregistrările care depind de aceasta. În cazul în care acțiunea CASCADE este specificată pe
clauza ON UPDATE, atunci la operația de actualizare UPDATE pe tabela părinte a coloanei
ce realizează relaționarea prin FOREIGN KEY cu o altă tabelă se va produce automat și
actualizarea valorilor din coloana FOREIGN KEY. Dacă este specificată acțiunea CASCADE
pe clauza ON DELETE, atunci la ștergerea unei înregistrări din tabela părinte, se vor șterge în
cascadă înregistrările corespondente din cealaltă tabelă.
· RESTRICT – această acțiune interzice operațiile care ar putea lăsa înregistrări fără
corespondent;
· NO ACTION – această acțiune este echivalentă cu RESTRICT în MySQL;
· SET NULL – această acțiune va stabili valoarea NULL înregistrărilor dependente pe coloana
ce joacă rolul de cheie externă, în măsura în care definiția coloanei nu include modificatorul
NOT NULL.

Implicit, constrângerea FOREIGN KEY are clauzele ON UPDATE, respectiv, ON DELETE

cu valorile RESTRICT (sau NO ACTION în MySQL). Aceasta înseamnă că tentativa de
modificare a unei valori dintr-o coloană care are corespondent în altă tabelă, sau de ștergere a
unor înregistrări care conțin valori pe o coloană ce au corespondent într-o altă tabelă va cauza
eroare, sistemul nepermițând acest lucru.

Proprietatea aceasta a cheii externe de a garanta referirea de valori valide din tabela părinte
poartă numele de constrângere de integritate referențială.

Pentru a defini o cheie externă (FOREIGN KEY) este necesar să fie îndeplinite următoarele
condiții:
· Tabelele implicate în relație trebuie să folosească motorul de stocare (engine) InnoDB;
celelalte motorare de stocare nu suportă această facilitate;
· Coloana FOREIGN KEY și coloana referită din cealaltă tabelă (PRIMARY KEY) trebuie să
aibă tipuri de dată compatibile (pentru numere întregi același tip de dată și aceeași dimensiune
și acceași setare SIGNED sau UNISGNED; pentru coloane de tip șir de caractere, coloanele
trebuie să aibă același set de caractere – CHARSET, și același collation, dar nu neapărat
aceeași lungime);
· Coloanele implicate din ambele tabele trebuie să fie indexate (cheia externă dintr-o tabelă și
cea referită din cealaltă tabelă).
Subinterogări utilizate în instrucțiunea INSERT
INSERT INTO...SELECT
În continuare vom discuta despre posibilitatea de a insera într-o tabelă valori obținute din
executarea unei instrucțiuni SELECT, totul într-o singură instrucțiune INSERT. Aceasta
înseamnă că subinterogările pot fi utilizate, nu doar în cadrul unei instrucțiuni de regăsire
SELECT, ci și în celelalte instrucțiuni de manipulare, după cum vom vedea în cele ce urmează.

Sintaxa unei instrucțiuni INSERT ce va introduce date provenite dintr-o subinterogare, adică
dintr-o instrucțiune SELECT este următoarea:

INSERT INTO nume_tabelă [(nume_coloană1 [, nume_coloană2, …])]

SELECT * | coloană1, ..., coloanăn
FROM table1 [AS t1] [, table2 [AS t2]]
[WHERE condiții] … ;

Observăm din sintaxa acestei instrucțiuni că, spre deosebire de formele instrucțiunii INSERT
cunoscute până în prezent și asupra cărora ne-am aplecat cu atenție în prima parte a cursului
nostru, lipsește clauza VALUES, practic, după cuvintele cheie INSERT INTO urmate de
numele tabelei, este trecută direct instrucțiunea SELECT care aduce acele valori ce urmează
a fi inserate în tabelă pe care este executată instrucțiunea INSERT.

Condiția necesară pentru executarea cu succes a unei astfel de instrucțiuni INSERT INTO ...
SELECT este ca numărul de coloane specificate în INSERT să fie egal cu numărul de coloane
extrase în instrucțiunea SELECT și, în plus, tipurile de dată să fie compatibile pentru fiecare
coloană în parte.

Lista de coloane poate fi omisă din instrucțiunea INSERT în cazul în care comanda SELECT
va returna un număr de coloane egal cu cel existent în tabela în care se face INSERT.

Evident, tipurile de date ale coloanelor rezultate din interogare trebuie să fie compatibile cu
tipurile de date ale coloanelor din tabela în care se inserează înregistrări.

O copie a unei tabele se poate realiza prin folosirea unei instrucțiuni INSERT INTO ...
SELECT. În acest caz în subinterogarea SELECT din cadrul instrucțiuni se vor selecta toate
coloanele din tabela căreia i se va face copia, deci, SELECT * FROM nume_tabelă.

Prin această instrucțiune se pot adăuga date într-o tabelă provenite dintr-o altă tabelă. În loc de
clauza VALUES, apare în instrucțiunea INSERT o subinterogare.
Utilizarea subinterogărilor pentru crearea unei
tabele și duplicarea structurii unei tabele
CREATE TABLE AS SELECT
Pot fi create tabele și prin folosirea unei instrucțiuni SELECT în cadrul unei instrucțiuni
speciale CREATE TABLE.

Sintaxa acestei instrucțiuni CREATE TABLE diferă de cea cunoscută în care sunt specificate
în mod explicit coloanele componente și proprietățile lor, plus, eventualele restricții impuse
asupra anumitor coloane.

Vom reda în continuare, sintaxa acestei comenzi:

CREATE TABLE nume_tabelă [AS]
SELECT * | column_name(s)
FROM tabela_origine
[WHERE … ];

Va fi creată o nouă tabelă ce va conține coloanele tabelei de origine, adică tabelei din care au
fost extrase coloane în instrucțiunea SELECT.

Structura noii tabele va conține coloanele selectate, preluând tipurile de date și caracteristicile
acelor coloane. Instrucțiunea SELECT dintr-o astfel de comandă de creare a unei tabele, poate
extrage date din mai multe tabele. Astfel, tabela nou creată va conține acele coloane extrase
din tabelele specificate în instrucțiunea SELECT, aceste coloane având tipurile de date din
tabelele de origine.

Această instrucțiune nu va copia indecși sau constrângeri de integritate definite pe coloanele

din tabelele de origine.

Crearea unei copii a unei tabele

Pot fi create și copii ale structurii unei tabele. În acest sens se va utiliza următoarea sintaxă:

CREATE TABLE nume_tabelă_nouă

LIKE nume_tabelă_veche;

După executarea unei astfel de instrucțiuni tabela nouă va avea aceași structură cu cea veche.
Dacă, însă, tabela veche conține înregistrări, acestea nu vor fi preluate în noua tabelă.
Dacă pe tabela veche sunt indecși definiți, aceștia vor fi copiați în noua tabelă, dar cheile
externe (FOREIGN KEYS) nu vor fi copiate, chiar dacă există în tabela veche astfel de chei
definite

La toate aceste instrucțiuni de creare a tabelor, ca și la cea deja cunoscută de creare a unei
tabele prin specificarea explicită a coloanelor componente și ale proprietăților acestora, poate
fi adăugată clauza IF NOT EXISTS care va înlocui generarea unei erori cu un warning , în
situația în care în baza de date curentă mai există o tabelă cu același nume.

Motoarele de stocare (engine) MyISAM și InnoDB

Unele baze de date au mai multe modalități de stocare a informației, cunoscute sub numele de
storage engine. MySQL conține mai multe astfel de engine-uri se stocare care mai sunt
cunoscute și ca tipuri de tabele sau motoare de stocare. Dintre acestea, cele mai importante sunt
MyISAM și InnoDB.

InnoDB este folosit pentru bazele de date tranzacționale (la care integritatea este forțată de
engine). Pentru că verifică integritatea datelor și asigură sincronizarea datelor din tabelele
relaționate, engine-ul InnoDB este mai lent, el fiind folosit în programele care necesită
prelucrarea tranzacțiilor.

MyISAM nu are integritatea datelor forțată și tranzacțiile trebuie implementate de

programator. Acest engine este folosit, în general, în aplicațiile unde prelucrările sunt mai
puține, iar interogările sunt mai dese.

Așadar, InnoDB permite definirea cheilor externe, deci, a constrângerilor de integritate

referențială, în timp ce MyISAM este mai rapid. În cazul ambelor tipuri de tabele (engine-uri
de stocare) fișierele de date sunt portabile.

Dezavantajul engine-ului InnoDB, comparativ cu MyISAM este că ocupă mai mult spațiu pe
disc, stocarea datelor putând fi făcută în mai multe fișiere.

Decizia de utilizare a unui anumit storage engine trebuie luată ținând cont de modul în care
sunt utilizate informațiile din tabele. În funcție de operațiile care sunt preponderente se va alege
motorul de stocare potrivit.

Dacă avem nevoie de definirea de constrângeri de integritate referențială sau de tranzacții,

atunci trebuie ales ca motor de stocare InnoDB.
Schimbarea motorului de stocare al unei tabele se pote face prin executarea instrucțiunii
următoare (schimbarea nu va altera datele stocate în tabela respectivă, dar operația poate să
dureze dacă sunt foarte mari tabelele):

ALTER TABLE nume_tabelă ENGINE InnoDB | MyISAM;

Motorul de stocare poate fi specificat explicit încă de la crearea tabelei prin plasarea la finalul
enumerării listei de coloane a clauzei ENGINE urmată de numele motorului de stocare.

Astfel, instrucțiunea CREATE TABLE va conține la final specficarea explicită a motorului

de stocare pe care îl utilizează:

CREATE TABLE nume_tabelă(

nume_coloană1 tip_dată[(dimensiune)] [modificatori],
nume_coloană2 tip_dată[(dimensiune)] [modificatori,]
....
[constrângeri]
) ENGINE = motor_stocare;
În sintaxa prezentată, motor_stocare reprezintă engine-ul pe care îl vom utiliza în tabelă.
Valorile posibile sunt: MyISAM, InnoDB sau alte motoare de stocare care există în baza de
date respectivă.

CHARACTER SET și COLLATION

CHARACTER SET
La crearea unei tabele se poate specifica și setul de caractere ce pot fi stocate în tabela
respectivă. Acest lucru se va utiliza atunci când dorim stocarea șirurilor de caractere cu
diacritice (caractere românești) sau a deosebirii dintre litere mari și litere mici, dar și alte
situații.
Implicit datele stocate în tabele sunt case-insensitive.

Există mai multe seturi de caractere ce pot fi definite pe o tabelă. Această stabilire a setului de
caractere se face utilizând proprietatea CHARACTER SET.

Un set de caractere (CHARACTER SET) reprezintă o listă de caractere posibile împreună cu

codurile numerice asociate (asignate) lor. Fiecare caracter are corespondent o codificare
numerică. Mai există un cuvânt cheie, în MySQL, ce poate fi utilizat pentru denumirea setului
de caractere, sinonim cu CHARACTER SET. Este vorba despre CHARSET.

Cel mai cunoscut set de caractere este ASCII. Acesta este un set de caractere pentru limba
engleză americană, deci, nu conține caractere românești. Fiecărui caracter îi corespunde o
codificare ASCII. Se găsesc pe internet, la foarte multe surse codificările numerice ale codului
ASCII (de exemplu aici: http://www.asciitable.com/).

Un alt set de caractere pentru caractere Unicode este UTF8. Acesta este utilizat pentru scrierea
cu diacritice (caractere românești).
 Se poate stoca un set de caractere pentru toată baza de date, deci, pentru toate tabelele din bază
și atunci proprietatea CHARACTER SET va fi declarată în cadrul instrucțiunii de creare a
bazei de date (CREATE DATABASE).

Setul de caractere utilizat se poate schimba, dacă tabele sunt deja create, și prin instrucțiunea
ALTER TABLE.

În MySQL, lista seturilor de caractere disponibilă poate fi vizualizată prin executarea

comenzii:

SHOW CHARACTER SET;

sau
SHOW CHARSET;

COLLATION
Collation-ul unui șir de caractere reprezintă un set de reguli ce specifică în ce fel sunt
comparate între ele caractere componente ale unui set de caractere. Adică, literele mici și
literele mari pot fi considerate, sau nu, echivalente.

Deci, putem spune că dacă majusculele și literele mici sunt echivalente avem un collation case
insensitive, iar dacă nu sunt echivalente, atunci este case sensitive. De asemenea, se pot
considera literele cu sau fără diacritice ca fiind sau nu echivalente.

Un șir de caractere poate avea un singur set de caractere și un singur collation. În MySQL
denumirea fiecărui collation începe cu numele setului de caractere urmat de _ și se încheie cu
tipul de collation precedat de caracterul _ (underscore).

Se pot întâlni următoarele tipuri de collation:

· _ci – collation case insensitive;
· _cs – collation case sensitive;
· _bin – collation de tip binary; caracterele sunt comparate exclusiv pe baza codului lor

Vizualizarea listei de collation-uri posibile în MySQL se poate face prin executarea comenzii:
SHOW COLLATION;

Concluzii
Așadar, în acest ultim capitol am prezentat diverse opțiuni avansate de lucru cu baze de date
MySQL. Am introdus conceptul de tranzacție, o noțiune destul de simplă dar foarte importantă
pentru asigurarea consistenței bazelor de date. De asemenea, am adus câteva completării, prin
prezentarea unor opțiuni suplimentare, constrângerii de integritate referențială care a fost
discutată în cadrul lecției despre comenzile limbajului de descriere a datelor. Am prezentat și
utilizarea subinterogărilor în instrucțiunea INSERT, respectiv, în instrucțiunea CREATE
TABLE, iar în final am discutat despre cele mai importante două motoare de stocare specifice
MySQL și despre seturile de caractere (CHARACTER SET) și COLLATION din MySQL.

Concluzii finale
La finalul acestui curs (SQL Fundamentals – modulul 1) putem spune că am parcurs atât
noțiunile teoretice de baze de date relaționale, cât și noțiunile fundamentale ale limbajului SQL,
precum și noțiuni complexe cum ar fi join-urile, subinterogările, tabelele virtuale, tabelele
temporare, tranzacțiile, dar și noțiuni de optimizare și opțiuni avansate de lucru.

Acest curs va conține și o anexă în care mai prezentăm câteva opțiuni avansate ale MySQL,
dintre care amintim aici: tipuri de date mai puțin utilizate în practica curentă (BLOB, ENUM,
etc.), join-uri utilizate în instrucțiunile UPDATE și DELETE, subinterogări utilizate în
instrucțiunile UPDATE și DELETE.

De asemenea, anexa va conține la final, o bibliografie ce a fost utilizată pentru redactarea

tuturor capitolelor (lecțiilor) acestui curs, precum și pentru redactarea anexei suplimentare.