BAZE DE DATE - II

2. Sisteme de gestionare a bazelor de date

2.1. Introducere
2.2. Avantaje ale sistemelor de gestiune a bazei de date
2.3. Dezavantaje ale unei baze de date
2.4. Organizarea logică a datelor
2.5. Modelul ierarhic al bazei de date
2.6. Modelul bazei de date tip reţea
2.7.Modelul bazei de date relaţionale
 2.1. Introducere

• O bază de date este un grup mare de fişiere care au

ceva în comun.
• Într-o bază de date, datele sunt integrate şi au ceva în
comun încât un set de programe, software oferă acces
către toate datele.
• Prin urmare, redundanţa datelor este minimalizată,
datele pot fi împărţite de toţi utilizatorii şi
inconsistenţa datelor este minimizată.
• Programul software (sau grup de programe) care
oferă acces către o bază de date este cunoscut ca
sistemul de gestiune al bazei de date (SGBD).
• O bază de date cu un SGBD (pentru exemplul cu
universitatea) este arătată în figura 1.
Fig.1. Sistemul de gestiune al bazei de date oferă acces la toate datele din baza de date
 2.2. Avantaje ale sistemelor de gestiune a bazei
de date
• Având o bază de date, doar un singur program -
SGBD - trebuie scris sau achiziţionat.
• Chiar mai mult, doar un singur program principal
trebuie menţinut, documentat sau învăţat de către
utilizatori.
• Cu o bază de date obişnuită, utilizatorii pot folosi toate
fişierele cu date, introduce datele o singură dată şi
schimba datele o singură dată.
• Redundanţa şi inconsistenţa, prin urmare, sunt mult
reduse cu ajutorul unei baze de date. Accesul este
disponibil pentru mulţi, iar integritatea datelor
confidenţiale poate fi menţinută prin intermediul unui
sistem de securitate.
• Un sistem de gestiune al bazei de date permite
utilizatorilor un acces mult mai bun către informaţiile
organizaţionale.
• Organizaţiile au acumulat o bogăţie de date, dar
traducerea acestor date în informaţii cu înţeles, s-a
dovedit în timp dificilă.
• În aceste circumstanţe, o organizaţie poate fi bogată
în date, dar săracă în informaţii; o bază de date poate
transforma o bogăţie de date într-o bogăţie de
informaţii.
• Structura unei baze de date integrate oferă o
flexibilitate mare în ceea ce priveşte tipurile de
rapoarte ce pot fi generate şi tipurile de cercetări
on-line ce pot fi făcute.
• Acest scop extins al informaţiilor disponibile dă
posibilitatea managementului să ia decizii mai
informate şi deci mai bune.
• Majoritatea bazelor de date sunt independente de
programele care le folosesc şi de hardware-ul pe care
se află.
• Informaţiile din fişiere sunt organizate într-un mod ce
permite accesul generalizat.
• Aceasta înseamnă că seturi de date pot fi adresate
prin programe scrise în multe limbaje diferite de
calculatoare electronice.
• Aceeaşi bază de date poate fi accesată de asemenea
printr-un limbaj elementar, proiectat pentru a fi mai
simplu de învăţat şi folosit decât un limbaj de
programe tradiţional.
• În cele din urmă, actualizarea şi întreţinerea este
simplificată deoarece toate datele sunt colectate,
administrate, actualizate şi purificate printr-un program
software.
• Deşi redundanţa este minimizată cu ajutorul unei baze
de date, trebuie menţinută o redundanţă a datelor
pentru a mări eficienţa prelucrării.
• Această redundanţă controlată a datelor este mică,
oarecum în comparaţie cu redundanţa unui mediu
tradiţional de fişiere.
• Prin minimizarea redundanţei datelor, colectarea
datelor şi procedurile de actualizare sunt simplificate.
• Integritatea datelor - sau acurateţea şi accesibilitatea
datelor - este mărită, deoarece toate informaţiile
despre un eveniment sau entitate sunt actualizate
într-un singur loc - baza de date centrală.
• O bază de date şi un SGBD permit programatorilor şi
analiştilor de sisteme să-şi îndeplinească funcţiile mai
uşor şi mai eficient.
• Mediul bazei de date oferă informaţii care ar consuma
prea mult timp sau ar fi nepractice de obţinut folosind
organizarea tradiţională a fişierelor.
• Cerinţa de programare este simplificată cu un SGBD
deoarece datele sunt mult mai repede disponibile.
• Într-o bază de date, datele sunt independente de
programele de aplicaţii.
• Aceasta înseamnă că, pot fi adăugate, modificate şi
şterse câmpuri din baza de date fără a afecta
programele de aplicaţii evidente.
• Adăugarea unui câmp la o înregistrare dintr-un fişier
tradiţional poate necesita modificarea şi testarea a
zeci poate chiar sute de programe dependente de
vechea structură a fişierelor.
• Cu un SGBD, programele pot fi schimbate fără a
schimba stocarea datelor, şi stocarea datelor poate fi
schimbată fără a schimba programele.
• După cum este arătat în figura 1, SGBD-ul are rol de
interfaţă între programe şi date astfel încât programele
sunt preocupate doar de numele simbolice ale datelor,
şi nu de stocarea lor fizică.
• Independenţa datelor eliberează programatorul şi
utilizatorul de cerinţa detailată şi complexă de a
actualiza structura fizică a datelor.
• Aceasta contribuie semnificativ la flexibilitatea
programelor de apăraţii într-un mediu SGBD.
 2.3. Dezavantaje ale unei baze de date
• Dezavantajele sistemelor de gestiune a bazelor de
date sunt relativ puţine, pe termen lung ele sunt
depăşite de avantaje.
• Un dezavantaj este că bazele de date şi programele
SGBD pot deveni destul de complexe. Stabilirea
legăturilor dintre multiple fişiere poate fi complicată şi
conceptele pot fi dificile pentru utilizatori.
• Prin urmare, administrarea unei baze de date necesită
proiectanţi experimentaţi de baze de date şi personal
administrativ experimentat şi câteodată o antrenare
extensivă a utilizatorilor.
• Tendinţa actuală de programare a bazelor de date
este de a produce sisteme de gestiune a bazei de
date ce sunt uşor de înţeles pentru utilizatori şi uşor
de întreţinut pentru organizaţii.
• Un alt dezavantaj al bazei de date este că software-ul
SGBD creează o supraîncărcare a sistemului
deoarece în general necesită mai multă prelucrare
decât programe de fişiere şi mai mult spaţiu pe disc
pentru stocarea software-ului (fişiere şi date despre
fişiere).
• Similar cu alte sisteme de software complexe, costul -
referitor la hardware, software şi personal - poate fi
ridicat pentru organizaţiile mici.
• Când SGBD-ul are un eşec în funcţionare, nimeni nu
mai poate accesa baza de date.
• În plus, când este folosit doar un singur SGBD în
cadrul unei organizaţii, se pun anumite restricţii de
capacitate a acelui SGBD pentru toţi utilizatorii.
 2.4. Organizarea logică a datelor
• Exact cum există multe moduri de a structura
organizaţiile de afaceri, există multe moduri de a
structura datele de care au nevoie acele organizaţii.
• Capacitatea unui manager de a folosi o bază de date
este foarte dependentă de modul în care este
structurată logic şi fizic baza de date, exact cum
capacitatea unui funcţionar de a găsi un fişier de
personal depinde de modul cum sunt organizate
dulapurile cu fişierele personalului.
• La structurarea logică a unei baze de date, afacerile
trebuie să ia în considerare caracteristicile datelor şi
modul cum vor fi accesate datele.
• În exemplul dulapului cu fişiere al funcţionarului, un
fişier de personal poate fi structurat logic bazându-se
pe nume, departament sau divizie, salariu sau chiar
numărul de telefon de la birou.
• Accesarea fişierelor după nume, are în vedere un
fişier structurat secvenţial după nume în ordine
alfabetică.
• Există patru modele principale de structurare logică a
bazelor de date: ierarhic, de reţea, relaţional şi orientat
pe obiect.
• Folosind opinii logice sau conceptuale ale datelor
care pot fi apoi implementate fizic în oricare bază de
date cu orice SGBD.
• SGBD-urile ierarhice, de reţea şi orientate pe
obiect leagă de obicei împreună datele ce au legături
între ele.
• SGBD-urile relaţionale se referă la date prin
informaţiile conţinute de ele.
 2.5. Modelul ierarhic al bazei de date
• Modelul ierarhic se referă la date prin structurarea
rigidă a datelor într-un "arbore" inversat în care
înregistrările conţin două elemente:
– o singură rădăcină sau câmp principal, adesea
denumit cheie, care identifică tipul, locaţia sau
ordinea înregistrărilor;
– un număr variabil de câmpuri subordonate care
defineşte restul datelor din cadrul unei înregistrări.
• Ca o regulă, în timp ce toate câmpurile au doar un
singur "părinte", fiecare părinte poate avea mai mulţi
"copii".
• Un exemplu de bază de date ierarhică este arătată în
figura 2.
Fig. 4. Modelul bazei de date ierarhice
• Structura ierarhică a fost dezvoltată simplu deoarece
relaţiile ierarhice se găsesc în mod obişnuit în multe
organizaţii de afaceri tradiţionale şi procese.
• Spre exemplu - managementul de vârf la cel mai înalt
nivel, managementul de mijloc la nivele mai joase şi
alţi angajaţi la cele mai joase nivele.
• În cadrul fiecărei ierarhii un angajat are doar un
singur manager.
• Structura ierarhică este caracterizată de această
relaţie de unu la mulţi.
• O abordare ierarhică este foarte uşor de proiectat şi
de înţeles pentru utilizatori, de vreme ce de obicei este
modelată după organizaţiile din lumea adevărată.
• Dar poate cel mai puternic avantaj al modelului
ierarhic este viteza şi eficienţa cu care se pot căuta
datele. De ce? Deoarece o mare parte a bazei de date
este eliminată în căutare odată cu fiecare mers în
josul arborelui.
• După cum este arătat în figura 2 jumătate din
înregistrările bazei de date (vânzările Coastei de Est)
sunt eliminate de îndată ce căutarea se îndreaptă spre
vânzările Coastei de vest, şi două treimi din vânzările
Coastei de Vest sunt eliminate de îndată ce căutarea
se îndreaptă spre echipament de susţinere.
• Din acest motiv multe sisteme de operare pe bază de
software folosesc o abordare ierarhică pentru a găsi
fişierele din directoare şi subdirectoare; este o
abordare simplă care poate fi foarte rapidă ăi eficientă
în căutare - presupunând bineînţeles că ierarhia a fost
bine instalată.
• În sfârşit, datorită relaţiilor explicite dintr-un model
ierarhic, integritatea bazei de date este puternic
menţinută.
• În fond, fiecare "copil" dintr-o bază de date ierarhică
trebuie să aparţină unui, "părinte".
• Dar există probleme cu abordarea ierarhică.

• În modelul ierarhic, fiecare relaţie trebuie să fie

definită explicit când este creată baza de date.
• Fiecare înregistrare dintr-o bază de date ierarhică
poate conţine doar un câmp cheie şi este permisă
doar o relaţie între oricare două câmpuri.
• Aceasta poate crea o problemă deoarece datele din
lumea adevărată nu se conformează întotdeauna unei
astfel de ierarhii stricte.
• Spre exemplu, într-o organizaţie matriceală un
angajat poate raporta la mai mulţi manageri; aceasta
ar fi incomod de mânuit pentru o structură ierarhică.
• Mai mult, toate căutările de date trebuie să pornească
din vârf sau "rădăcina" arborelui şi să circule în jos de
la "părinte" la "copil".
• În plus, faptul că această bază de date are restricţii la
relaţiile de tip "unu la mai mulţi", poate face foarte
incomode unele cercetări mai ales dacă structura
explicită a bazei de date nu este cunoscută unui
utilizator.
• Un alt dezavantaj semnificativ al modelului ierarhic
este faptul că este dificil de găsit relaţii, de tip "veri" în
arbore. În exemplul arătat în figura 2, nu există nici o
relaţie directă între obiecte de porţelan vândute pe
coasta de est şi vânzările de porţelanuri pe coasta de
vest.
• O comparaţie a vânzărilor de porţelanuri pe ansamblul
companiei ar face necesare două cercetări separate şi
apoi un alt pas combinând rezultatele cercetărilor.
 2.6. Modelul bazei de date tip reţea
• Modelul tip reţea creează relaţii între date prin
intermediul unei structuri de legături în care
înregistrările subordonate (numite "membrii", nu
"copii") pot fi legate de mai mulţi părinţi (numiţi
proprietari).
• În mod similar cu modelul ierarhic, modelul tip reţea
foloseşte verigi explicite, numite indicatori, pentru a
lega subordonaţii şi părinţii.
• Acest tip de relaţie este numită set. Fizic, indicatorii
sunt adrese de stocare ce conţin locaţia unei
înregistrări.
• Cu abordarea tip reţea, o înregistrare membru poate fi
legată de o înregistrare proprietar şi în acelaşi timp
poate fi chiar ea o înregistrare proprietar legată de alte
secţiuni de membrii (vezi fig.3).
Fig. 3. Modelul bazei de date tip reţea.
• În acest fel, sunt posibile relaţiile de tip "mulţi la
mulţi" cu un model tip reţea al bazei de date - un
avantaj semnificativ al modelului tip reţea faţă de
modelul ierarhic.
• În figura 3, informaţiile despre vânzări ale
porţelanurilor, echipamentelor de construcţii şi
echipamentelor de susţinere, sunt subordonate unei
locaţii de membrii.
• Informaţiile despre fiecare au doi părinţi sau
proprietari, Coasta de Est şi Coasta de Vest.
• Problema obţinerii unei imagini complete despre
vânzările de porţelanuri în întreaga ţară, care există la
modelul ierarhic, nu mai apare la modelul tip reţea.
• Mai mult căutările datelor nu trebuie să pornească de
la o rădăcină - s-ar putea să nici nu existe o singură
rădăcină la o reţea - ceea ce oferă o mai mare
flexibilitate căutărilor de date.
• Modelul tip reţea nu plasează nici o restricţie asupra
numărului de relaţii sau seturi în care poate fi implicat
un câmp.
• Acest lucru este mult mai relevant în relaţiile de
afaceri din lumea adevărată unde, spre exemplu,
vânzătorii au mulţi clienţi şi clienţii au mulţi vânzători.
• Pentru flexibilitate şi adaptabilitate la situaţiile din
lumea reală, oarecum, bazele de date tip reţea au
plătit un preţ în termeni de complexitate.
• Pentru fiecare set, trebuie menţinută o pereche de
indicatori. Când creşte numărul seturilor sau relaţiilor,
depăşirea devine substanţială.
• Modelul tip reţea este de departe cel mai complicat
tip de bază de date de proiectat şi implementat.
 2.7.Modelul bazei de date relaţionale

• În timp ce majoritatea organizaţiilor de afaceri sunt

organizate într-un mod ierarhic, majoritatea datelor
despre afaceri sunt organizate tradiţional în tabele
simple cu coloane şi rânduri, mai ales datele contabile
şi financiare.
• Tabelele permit comparaţii rapide pe linie sau coloană
şi punctele sunt uşor de reperat prin găsirea punctului
de intersecţie a unei anumite linii şi coloane.
• Modelul relaţional se bazează pe conceptul simplu de
tabele pentru a capitaliza caracteristicile rândurilor şi
coloanelor de date.
• Şi aceasta este mult mai relevantă în situaţiile de
afaceri din lumea reală.
• Unele firme, spre exemplu sunt bazate pe o structură
de tip proiect sau matrice în care un angajat poate
"aparţine" mai multor supraveghetori în acelaşi timp şi
depăşi liniile de autoritate.
• Într-o bază de date relaţională, aceste tabele despre
entităţi sunt numite relaţii şi modelul se bazează pe
teoria matematică a mulţimilor şi relaţiilor.
• În acest model, fiecare rând de date este echivalent
cu o înregistrare şi fiecare coloană de date este
echivalentă cu un câmp.
• În terminologia modelului relaţional, un rând este
numit "tuple" şi o coloană este numită "atribut".
• O bază de date relaţională nu este întotdeauna un
tabel mare (de obicei numit fişier plat) conţinând toate
coloanele şi toate liniile. Acest tip ar conţine prea
multă redundanţă a datelor.
• O bază de date este de obicei proiectată ca multe
tabele ce au ceva în comun.
• Există unele principii fundamentale într-o bază de date
relaţională:
– În primul rând, ordinea liniilor sau coloanelor
dintr-un tabel este irelevantă. Aceasta deoarece
poziţia lor faţă de alte linii şi coloane este irelevantă
în găsirea datelor bazate pe anumite linii şi coloane;
– În al doilea rând fiecare linie trebuie să fie unic
identificabilă de datele din linie - un fel de date
cheie (ex.: un număr de asigurare socială sau
matricolul angajatului) ;
– În al treilea rând, fiecare tabel trebuie să aibă un
identificator unic - numele relaţiei ;
– În al patrulea rând, nu pot exista linii sau coloane
duplicate ;
– În sfârşit, poate exista doar o singură valoare în
fiecare celulă linie-coloană dintr-un tabel.
• Unul dintre cele mai mari avantaje ale modelului
relaţional este simplitatea sa conceptuală şi
capacitatea de a lega înregistrări într-un mod ce nu
este predefinit.
• Aceasta oferă o mare flexibilitate. Modelul relaţional
sau tabelar de date poate fi folosit într-o varietate de
aplicaţii. Mulţi oameni pot vizualiza uşor modelul
relaţional ca pe un tabel, dar modelul foloseşte o
terminologie nefamiliară.
• Luaţi în considerare exemplul tabelului bazei de date
relaţionale despre managerii din Coasta de Est, arătat
în figura 3 Tabelul conţine date despre entitatea
numită managerii din Coasta de Est. Atributele
(coloanele) sau caracteristicile despre entitate sunt
nume, funcţie, vârstă şi divizie.
• Liniile sau faptele entităţii sunt cele două înregistrări despre
Smith A. şi W. Jones.

• Legăturile dintre date şi dintre tabele - sunt implicite, deoarece

ele nu sunt în mod necesar legate fizic într-un aparat de
stocare ci sunt legate implicit de design-ul tabelelor în linii şi
coloane.

Fig. 3. Modelul relaţional al bazei de date - tabel.

• Această proprietate de legături implicite oferă poate
cel mai puternic beneficiu al modelului relaţional -
flexibilitate în găsirea de legături între date.
• Spre deosebire de modelele ierarhice şi cele tip reţea,
unde singurele legături sunt cele rigid construite în
proiect, toate datele dintr-un tabel şi dintre tabele pot fi
legate şi comparate.
• Aceasta oferă modelului relaţional o mai mare
independenţă a datelor faţă de modele ierarhice şi
cele tip reţea.
• Desigur, ca la toate tabelele, o persoană ce caută
date trebuie doar să ştie două lucruri: identificatorul
liniei ce va fi căutată şi coloana dorită.
• Sunt posibile căutări în baza de date şi cu chiar mai
puţine informaţii.
• Modelul relaţional este actual cel mai utilizat dintre
cele patru structuri de baze de date deoarece oferă
cea mai mare flexibilitate şi uşurinţă în folosire. Dar
există unele dezavantaje.
• Deoarece bazele de date cu scală mare pot fi
compuse din multe tabele intercorelate, proiectul de
ansamblu, poate fi complex şi prin urmare poate avea
timpi mai lenţi de căutare şi de acces (în comparaţie
cu modelele ierarhice şi cele tip reţea).
• În al doilea rând, integritatea datelor nu este o parte
moştenită de la acest model ci de la modele ierarhice
şi cele tip reţea.
• Prin urmare, trebuie întărit cu principii bune de
proiectare. Mijlocul principal de întărire a integrităţii
datelor în bazele de date relaţionale este prin
intermediul normalizării.
 2.7.1. Normalizarea
• Normalizarea este o metodă pentru analizarea şi
reducerea unei baze de date relaţionale la forma sa
cea mai restrânsă pentru redundanţa minimă,
integritate a datelor maximă şi cea mai bună
performanţă de prelucrare.
• În mod deosebit, normalizarea are câteva scopuri:
– eliminarea redundanţei cauzate de câmpuri repetate în
cadrul unui fişier, câmpuri care nu descriu direct entitatea şi
câmpuri care pot fi derivate din alte câmpuri;
– evitarea anomaliilor de actualizare (ex.: erori din introducere,
ştergere şi modificare de înregistrări);
– reprezentarea exactă a punctelor ce sunt modelate;
– simplificarea întreţinerii şi salvării informaţiilor.
• Toate tabelele dintr-o bază de date trebuie privite
îndeaproape pentru a detecta încălcările regulilor de
normalizare.
• Un tabel în prima formă normală se supune
principiului bazei de date relaţionale, de o singură
valoare într-o celulă şi nu pot fi repetate atribute
pentru a trece de acea restricţie.
• De exemplu, să luăm în considerare un tabel de
personal despre angajaţi cu atributele obişnuite de
nume, vârstă, numărul de asigurare socială şi aşa mai
departe.
• Fiecare angajat are doar o singură valoare pentru
fiecare din aceste atribute, dar ce se întâmplă cu un
atribut despre numele copiilor, când un angajat poate
avea mai mult decât un copil?
• Dacă numele lor sunt stocate într-o listă de câmpuri
cum ar fi copiii, copil 2 şi aşa mai departe, principiul
unei singure valori pe celulă este păstrat, dar tabelul
ar fi nefuncţional.
• Un tabel cu patru atribute copil, de exemplu, ar eşua
pentru o familie cu cinci şi pregătirea de atribute în
plus pentru poate doisprezece copii ar fi foarte mare
pier-dere de resurse de stocare, de vreme ce numărul
mediu de copii dintr-o familie este de trei.
• Mai mult, pentru a căuta un copil după nume ar
însemna căutarea în toate câmpurile "copil".
• La fel, calcularea numărului de copii necesită
verificarea tuturor câmpurilor "copil".
• Într-o bază de date mare multe "treceri" prin tabel
pentru astfel de date pot transforma o simplă căutare
într-o cerinţă complexă - legarea resurselor
calculatorului electronic.
• Problema constă în faptul că, copiii unui angajat nu
sunt doar simple atribute ale angajatului ci constituie
ei însăşi o altă entitate, ce are legătură cu a
angajaţilor.
• Ca o soluţie de normalizare, s-ar crea un tabel numit
Copii pentru a stoca numele copiilor. Acest tabel ar fi
legat de tabelul Personal folosind o cheie ce ar exista
în ambele tabele ca un atribut - de exemplu, numărul
asigurării sociale a părintelui.
• Un tabel se spune că este în a doua formă normală
când întâlneşte calificările pentru prima formă normală
şi reduce datele stocate nenecesare în fişiere multiple.
• Acest scop de normalizare foarte subtil este de a
elimina atribute ce pot deriva din alte atribute. Dacă,
spre exemplu fişierul Copii conţine numărul de
asigurare socială al părintelui şi numele părintelui,
unul din aceste atribute este redundant.
• Evident, dacă se cunoaşte numărul de asigurare
socială al părintelui, se poate căuta numele
corespunzător din fişierul Personal. Stocarea numelui
părintelui în fişierul Copii face risipă de spaţiu şi
introduce posibilitatea inconsistenţei.
• Similar, un câmp nu ar trebui să fie un câmp calculat
al altuia. Într-o bază de date despre personal, spre
exemplu, s-ar putea să existe un atribut pentru
numărul de ani pe care un angajat i-a lucrat pentru
companie.
• Oricum, dacă există deja un atribut pentru data
angajării, nu ar trebui creat şi un atribut pentru anii
lucraţi, deoarece se poate calcula simplu vechimea
prin scăderea datei de angajare din data prezentă.
• Mai mult, dacă ar exista un astfel de câmp atribut
calculat, baza de date ar trebui actualizată perpetuu la
aniversarea fiecărei date de angajare a unui angajat.
• O altă problemă obişnuită de normalizare este
duplicarea tabelelor - două sau mai multe tabele care
urmăresc esenţial aceeaşi entitate.
• Un sistem real de vânzări de proprietăţi, spre
exemplu, poate avea tabele separate pentru clădiri cu
birouri, spaţii de vânzare, depozite şi proprietăţi
rezidenţiale. Toate aceste tabele conţin de fapt
aceleaşi entităţi: proprietăţi.
• Păstrarea de fişiere separate pentru tipuri diferite de
proprietăţi fac mai dificile căutările pentru o anumită
clădire. Pentru a găsi, proprietatea de pe b-dul
Dimitrie Cantemir nr. 43, s-ar putea să trebuiască
căutat în toate patru tabele, dacă nu este cunoscut
tipul proprietăţii.
• Dacă o proprietate este transformată din birou în
spaţiu de vânzare, înregistrarea ar trebui ştearsă din
tabelul despre birouri şi introdusă în tabelul despre
spaţii de vânzare. Aceste cerinţe pot fi simplificate prin
combinarea celor patru tabele într-unul singur şi
adăugând un nou câmp pentru a arăta tipul de
proprietate.