Cuprins

Capitolul I. PREZENTAREA SOCIETĂȚII.......................................................................................................2

Scurt istoric.........................................................................................................................................................2
Capitolul II. MODELAREA CONCEPTUALĂ A DATELOR..........................................................................3
Modelul Entitate-Asociere (EA)........................................................................................................................3
Modelul Entitate-Asociere.................................................................................................................................5
Restricții..............................................................................................................................................................6
Restricţii structurale......................................................................................................................................6
Restricţii de integritate de roluri...................................................................................................................6
Restricții de integritate de asocieri................................................................................................................8
Dependente funcționale......................................................................................................................................9
Matricea dependenţelor funcţionale...................................................................................................................12
Capitolul III. MODELAREA CONCEPTUALĂ A PRELUCRĂRILOR.......................................................14
Modelarea unui proces.....................................................................................................................................14
Etapa 1: Definirea domeniului investigat.......................................................................................................14
Etapa 2: Evenimente identificate....................................................................................................................15
Etapa 3: Întocmirea tabloului evenimente-rezultate.....................................................................................15
Etapa a 4-a: Identificarea operaţiilor.............................................................................................................16
Etapa a 5-a: Identificarea sincronizărilor......................................................................................................16
Etapa a 6-a: Identificarea regulilor de emisie................................................................................................17
Etapa a 7-a: Elaborarea modelului conceptual al prelucrărilor...................................................................17
Capitolul IV. MODELAREA LOGICĂ A DATELOR.....................................................................................20
1. Modelul relaţional....................................................................................................................................20
Tipuri de relaţii intre tabelele..........................................................................................................................23
2. Modelarea fizică a datelor........................................................................................................................24
Limbajul SQL...................................................................................................................................................26
Capitolul I. PREZENTAREA SOCIETĂȚII

Scurt istoric

CrisMario este o companie leader pe piaţa din Europa în dezvoltarea de programe

pentru automatizarea şi gestionarea proceselor de afaceri în cadrul intreprinderilor.
CrisMario are o expertiză puternică pe produsele de gestiune ERP, acoperind o gamă
larga de clienţi, de la intreprinderile mici pana la cele foarte mari. De asemenea,
portofoliul nostru mai cuprinde produse complementare necesare în mediul de afaceri.
Cele mai multe din aceste produse s-au conceput prin utilizarea platformei de dezvoltare
Microsoft.
CrisMario este o companie internaţională cu peste 6500 de angajaţi care îşi desfăşoară
activitatea în 6 ţări. Produsele foarte bune care oferite sunt rezultatul unui organizaţii
motivate şi foarte bine pregătite profesional care lucreaza în echipe şi aplică cele mai
moderne şi bune practici disponibile în industria de software.
CrisMario este lider în furnizarea de servicii outsourcing în Accounting şi Payroll în
regiunea nordică a Europei, cu peste 1.600 de angajați competenți și dedicați . Ca parte a
strategiei de a oferi un cost eficient și servicii de procesare inalt specializate, un Shared
Service Center a fost înființat în România în luna noiembrie 2010.
Fiind o companie nordica o caracterizează un  stil de management nordic. Acest
lucru înseamnă că se vor trata angajații și clienții firmei cu respect , se construiesc  relații
bazate pe incredere si loialitate și se pune munca în echipă în fața performanțelor
personale. Angajaţii sunt devotaţi și adaugă valoare organizaţiei . Până în prezent, sunt
furnizate servicii doar către  alte companii din grup . În viitorul apropiat se vor  oferi
serviciile de outsourcing si pentru companiile din România.
Calificarea personalului este corespunzătoare tipului de muncă realizat de angajaţi
şi aceştia prezintă o structura pe vârstă echilibrată.
Capitolul II. MODELAREA CONCEPTUALĂ A DATELOR

Un model conceptual este un ansamblu de concepte şi reguli de combinare a acestor

concepte permiţând reprezentarea realităţii circumscrise domeniului supus informatizării.
Pentru definirea modelului conceptual al datelor se apelează la modele intermediare care
sunt folosite ca suport al unei metodologii de proiectare.

Modelul Entitate-Asociere (EA)

Modelul EA urmăreşte obţinerea unei reprezentări fidele, utilizând concepte specifice, a
realităţii (problemei de rezolvat ce urmează a fi informatizată). Această reprezentare a lumii
reale se va realiza făcându-se abstracţie de orice restricţie fie ea informatică sau organizatorică.
Modelul entitate-asociere permite reprezentarea informaţiilor despre structura bazelor de
date folosind trei elemente de construcţie: entităţi, atribute ale entităţilor şi asocieri între entităţi.
Entităţile modelează clase de obiecte concrete sau abstracte despre care se colectează
informaţii, au existenţă independentă şi pot fi identificate în mod unic.
Am ales ca domeniu de studiu crearea unui sistem de baze de date care gestioneză
procesul de recrutare a SC CrisMario SRL. Entităţile pe care le-am definit sunt: candidat,
angajator, post, contract, dosar, criterii .
Entităţile sunt de două categorii:
1. Entităţi independente (sau tari) sunt cele care au existenţă independentă de alte entităţi,
2. Entităţi dependente (sau slabe) sunt formate din instanţa care işi justifică încadrarea în clasa
respectivă doar atâta timp cât într-o altă entitate (tata) există o anumită instanţă de care sunt
dependente.
Tipul de entitate reprezintă un concept generic desemnând mulţimea tuturor entităţilor
prezentând aceleaşi caracteristici constructive.
În cazul nostru tipul de entitate candidat desemnează ansamblul candidaţilor la posturile
societăţii, candidaţi descrişi plecând de la aceleaşi caracteristici comune: CNP, nume, prenume,
data naşterii, număr telefon, adresă e-mail, studii, loc de muncă anterior, dataang, data încheierii,
domeniu, funcţia, experienţa, CUI, cod post.
Atributele modelează proprietăţi atomice distincte ale entităţilor. Fiecare atribut prezintă
un domeniu, adică o mulţime de valori admise.
Atributele pot fi clasificate în funcție de mai multe criterii:
1. După complexitate atributelor, acestea sunt:
a. elementare (simple) ale căror realizări nu pot fi descompuse;
b. decompozabile (complexe) ale căror realizări sunt decompozabile.
 2. În functie de obligativitatea atributelor distingem atribute:
a. obligatorii: trebuie să prezinte obligatoriu o realizare, ceea ce corespunde
sintagmei NOT NULL – orice realizare;
b. opţionale: pot sa nu prezinte nici o valoare (realizare) în cadrul unei entităţi.
3. Dupa realizarile atributelor, acestea se impart in atribute:
a. monovaloare: atribute care prezintă o singură valoare în cadrul unei entităţi;
b. multivaloare: atribute care prezintă mai multe realizări în cadrul aceleiaşi
entităţi.
TIPUL DE ENTITATE reprezintă un concept generic desemnând mulţimea tuturor
entităţilor prezentând aceleaşi caracteristici constructive.
Tipul de entitate Post este definit prin următoarele atribute: cod post, domeniu post,
disponibilitate, număr post, CNP, CUI, număr contract.
Angajator definit prin: CUI, nume firmă,CAEN, sediu social, telefon, fax, e-mail, data
înfinţării, website.
Contract definit prin: număr contract, data începerii, tip contract, durata, CNP, CUI.
Dosar definit prin: coddosar, număr contract, adeverinţa medicală, certificat de naştere,
buletin, certificat căsătorie, diplomă studii.
Criterii definit prin: experienţă minimă, domeniu corespunzător, studii superioare, CNP,
cod post.
În continuare am prezentat atributele tipului de entitate candidat clasificându-le după
mai multe criterii.

Tipul atributului în Tipul atributului în funcție de

Atribut
funcție de complexitate realizările prezentate de acestea
CNP Elementar (simplu) Obligatoriu Monovaloare
Nume Elementar (simplu) Obligatoriu Monovaloare
Prenume Elementar (simplu) Obligatoriu Monovaloare
Data_nașterii Decompozabil (complex) Obligatoriu Monovaloare
E-mail Elementar (simplu) Opţional Monovaloare
Nr_telefon Elementar (simplu) Obligatoriu Multivaloare
Studii Decompozabil (complex) Obligatoriu Multivaloare
Loc_muncă_anterio
Elementar (simplu) Obligatoriu Multivaloare
r
Data_ang Decompozabil (complex) Obligatoriu Monovaloare
Data_încheierii Decompozabil (complex) Obligatoriu Monovaloare
Domeniu Elementar (simplu) Obligatoriu Monovaloare
Funcția Elementar (simplu) Obligatoriu Monovaloare
CUI Elementar (simplu) Obligatoriu Monovaloare
Cod_post Elementar (simplu) Obligatoriu Monovaloare
 Entităţile şi asocierile care formează diagrama EA se transformă pe baza unor reguli clare
în structura relaţională a bazei de date. Rezultă schema preliminară a acesteia formată din tabele
(relaţii în terminologia relaţională), coloanele acestora (atribute ale relaţiilor) şi constrângerile
de integritate care pot fi deduse automat din diagrama incluzand unele interdependenţe între date
numite şi dependenţe funcţionale.
Asocierea dintre entităţi exprimă legătura stabilită dintre acestea şi rolul pe care îl joacă
fiecare entitate participantă la legătură.

Modelul Entitate-Asociere

CANDIDAT 1,n 1,1 POST 1,1 1,n ANGAJATOR

CNP Solicită Cod_post Oferă CUI
CUI Solicitat CNP oferi
Cod_post CUI t
0,n 1,1 Număr_contract 1,n
1,n Încheie 1,1
Emite

Respectă Prevede

1,1 Presupune 1,1 încheiat

CRITERII 1,1 CONTRACT 1,1 DOSAR

Acte necesare
CNP Număr_contract Cod_dosar
Cod_post CNP Cuprinde Număr_contract
1,1 CUI
Cerute 1,1 1,1

Restricții

 Restricţiile de integritate definesc cerinţele pe care datele trebuie să le respecte pentru a

fi corecte şi coerente în raport cu realitatea pe care o reflectă.

Carte de identitate validă

Perioada de probă = 3 luni
Data încheiere contract să fie anterioară datei angajării
  Restricţiile de domeniu reprezintă condiţii (reguli) care privesc ansamblul de valori
admise pentru un atribut în cadrul tipului sau domeniului său.

Carte de indentitate tip {BI,CI}

Număr post >= 1
Perioada contract = {3 luni,6 luni, 12 luni}

Restricţii structurale

semnează aparține
încheie
Candidat Contarct
respectă contractează
emite

respectă obține Angajator

Criterii
aparține
aparține Postul

Restricţii de integritate de roluri

a) Restricţia de incluziune de roluri

încheie
Candidat Contract încheiat

I
obține
Postul acordat

Candidaţii încheie contractul de muncă şi primesc postul la care au candidat. Între rolul
acordat şi rolul încheiat se manifestă o restricţie de incluziune de rol.

b) Restricţia de egalitate de roluri

 Candidat Contract

Respectă Criterii

Candidaţii care încheie un contract de muncă, deci joacă rol de posesori în asocierea
încheie înseamnă că au respectat criteriile, deci joacă rol de angajat în asocierea respectă,
reciproca fiind valabilă: orice candidat care respectă criteriile trebuie să aibă un contract de
muncă. Dar nu toţi candidaţii sunt angajaţi, deci există entităţi ale tipului contribuabil care nu
joacă rolul de posesor în asocierea încheie.

c) Restricția de excluziune de roluri

obține
Candidat Postul
angajat
este oferă
#
angajator
Angajator

Excluziunea de roluri specifică faptul că rolul jucat de candidat în asocierea obţine

exclude existenţa rolului jucat de angajator în asocierea oferă.

Restricții de integritate de asocieri

a) Restricţia de incluziune de asocieri

încheie
Candidat Contract

I
obține
Postul
 Această restricţie exprimă faptul că existenţa asocierii dintre candidat şi contract de
muncă determină existenţa asocierii dintre candidat şi post. Candidatul nu poate primi postul
dacă nu încheie un contract de muncă.

b) Restricţia de excluziune de asocieri

obține
Candidat Postul
#

este oferă
Angajator

Rezulă că persoana care obţine postul nu poate fi angajator. Rezultă că între Obţine
(postul) şi Este (angajator) este o excluziune de asocieri.

c) Restricţia de egalitate de asocieri

deținător încheie
Candidat Contract
obligat
respectă
=

Criterii

Între aceste asocieri se stabileşte o restricţie de egalitate de asocieri deoarece încheierea

unui contract de muncă implică respectarea criteriilor, iar respectarea acestor criterii implică
necesitatea obţinerea contractului de muncă. Toate rolurile deţinător implică toate rolurile
obligat.

Dependente funcționale

Conceptul de dependente functionale (DF) evidentiaza raporturile de determinare stabilite

intre atributele unei entitati. Prin intermediul DF se pun in relatie doua atribute, si anume:
 Determinantul

Determinantul Determinatul

Dependenţele funcţionale evidenţiază raporturile de determinare stabilite între atributele

unei entităţi. O dependenţă funcţională pune în relaţie două atribute: determinantul şi
determinatul.
Matricea dependenţelor funcţionale
Matricea dependenţelor funcţionale se poate realiza în două variante, si anume:
 matricea simplificată
 matricea completă
Matricea simplificată reprezintă un tablou în care coloanele cuprind atributele cu rol de
determinanţi in cadrul dependenţelor funcţionale identificate, iar fiecare linie a matricei contine
un atribut ce aparţine mulţimii atributelor ce caracterizeaza tipurile de entitati care au fost
identificate si formalizate in cadrul procesului studiat.
Matricea completă a dependenţelor funcţionale reprezintă un tablou asemănător matricii
simplificate cu deosebirea că numărul de coloane este egal cu numărul liniilor, prin urmare in
antet de coloană vom regasi, orice atribut regăsit şi in antetul de linii şi nu doar atributele /grupul
de atribute cu rol de determinant într- o dependenţă funcţională.
În cazul studiului nostru există următoarele dependenţe funcţionale:
Număr contract Tip contract
Această df subliniază faptul că unei realizări a atributului Număr contract îi va
corespunde întotdeauna aceeaşi realizare a atributului Tip contract.
Determinantul reprezintă atributul/grupul de atribute din stânga df care prin valoarea sa
determină valoarea luată de atributul cu rol de determinat.
CNP Nume, Data naşterii
CNP Nume
CNP Data naşterii
 Acestea sunt dependenţe funcţionale complete deoarece nume sau data naşterii sunt
dependente funcţional de CNP, fără să fie dependente funcţional de niciuna dintre componentele
atributului CNP.
Mai avem situaţia dependenţei funcţionale parţiale:
Cod_post, Domeniu Nume post
Unde nume post depinde de Cod_post dar şi de o parte din domeniu.
Dependenţa multivaloare se manifestă atunci când valorii unui atribut/grup de atribute
îi corepund mai multe valori ale unui alt atribut.
Domeniu Număr posturi
În acest caz este redat numărul posturilor dintr-un anumit departament.
Proprietăţile dependenţelor funcţionale
Proprietăţile dependenţelor funcţionale, numite şi regulile lui Amstrong sunt:
a) Reflexivitatea:
Dacă Y⊂ X atunci se verifică df X Y unde X şi Y sunt atribute/grupuri de atribute aparţinând
unui tip de entitate.
b) Dezvoltarea:
Pentru orice Z ⊂ R dacă se verifică X Y atunci se verifică şi df XZ YZ.
Tranzitivitatea:
Dacă se verifică df X Y şi df Y Z atunci este adevărată şi df X Z.
c) Aditivitatea:
Dacă X Y şi X Z atunci există df X YZ.
d) Pseudotranzitivitatea:
Dacă există dependenţele funcţionale X Y şi WY Z atunci se verifică df XW Z.
e) Descompunerea:
Dacă se verifică df X Y atunci se verifică şi df X Z dacă Z⊂Y.
 Matricea dependenţelor funcţionale

Matricea completă
Atribut Determinanţi
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 1 19 20 21 1+6 1+9
8
1.CNP 1
2.Nume 1 1
3.Prenume 1 1
4.Data_naşterii 1 1
5.Domeniu 1 1
6.Experienţa 1 1
7.Studii 1 1
8.CUI 1
9.Nume_firmă 1 1
10.CAEN 1 1
11.Data_înfiinţării 1 1
12.Număr_contract 1 1 1
13.Tip_contract 1 1
14.Codpost 1 1
15.Domeniu_post 1 1
16.Număr_posturi 1 1
17.Coddosar 1 1
18.Experienţa_minimă 1 1
19.Domeniu_corespunzător 1 1
20.Studii_superioare 1 1
 Din analiza matricei complete a DF constatăm:
 diagonala de valori 1 rezultată (aşa cum am precizat şi în cadrul matricei simplificate)
este consecinţa proprietăţii de reflexivitate a df;
 existenţa dependenţelor elementare (prezentând un determinant elementar, format dintr-
un atribut);
 existenţa dependenţelor neelementare al căror determinant este format dintr-un grup de
atribute.
 existenţa unor dependenţe multivaloare între atributele cod care conduc la apariţia mai
multor valori 1 în cadrul liniilor matricei.

În realizarea MCD am respectat următoarelor reguli:

 Regula de unicitate a numelor se aplică tuturor elementelor care participă la definirea

MCD: tipuri de entităţi, tipuri de asocieri, atribute, roluri. Această regulă impune
eliminarea din model a omonimelor şi sinonimelor. Aceasta înseamnă că nu vom putea
da, în cadrul aceluiaşi MCD, şi unui atribut şi unui tip de entitate acelaşi nume, de
exemplu Candidat. Vom numi tipul de entitate Candidat iar atributul va primi denumirea
Nume.
 Fiecare atribut defineşte un singur tip de entitate sau un singur tip de asociere.
 Pentru fiecare realizare a asocierii nu există decât o singură realizare a fiecărei entităţi
participante la asociere.
 Regula proprietăţilor şi determinantului unei entităţi precizează că un atribut care este
determinat de mai mulţi determinanţi, aceştia fiind identificatori ai unor tipuri de entităţi
diferite, trebuie să definească tipul de asociere creat între respectivele tipuri de entităţi.
 Evitarea includerii în MCD a atributelor rezultate din calcule. Prezenţa unor astfel de
atribute în MCD se justifică numai dacă ele sunt purtătoare ale unei informaţii cu o
anumită relevanţă şi frecvenţă de utilizare.De exemplu Experienţa (=
Year(data_încheierii)-Year(dataang))
 Regula atributelor decompozabile precizează că pot fi menţinute în cadrul MCD atribute
complexe în măsura în care prelucrările nu impun descompunerea lor pe componente
elementare. Un exemplu este reprezentat de atributul adresa care se poate descompune pe
următoarele componente: cod poştal, localitate, stradă, număr, nr. apartament. În cazul
nostru se impune descompunerea atributului adresa pe componentele sale elementare
deoarece candidaţii sunt adesea selectaţi după criteriul oraşului.
 Am stabilit cu atenţie identificatorii entităţilor reţinând în grupul de atribute un număr cât
mai mic de elemente (atribute).
Capitolul III. MODELAREA CONCEPTUALĂ A PRELUCRĂRILOR

Modelarea unui proces

Procesul constituie un subansamblu al unei activităţi în care punctele de intrare şi de

ieşire sunt stabile şi independente de particularităţile organizatorice, este format din succesiunea
de operaţii executate şi generatoare la rândul lor de evenimente emise.
Operaţia este o secvenţă continuă de acţiuni elementare producătoare de evenimente care
se execută neîntrerupt din momentul declanşării ei de către unul sau mai multe evenimente. Ea
determină întotdeauna producerea unui eveniment / unor evenimente.
Regula de emisie reprezintă o propoziţie logică care dacă se dovedeşte adevărată va
determina producerea unui anumit eveniment. Este expresia condiţiilor referitoare la contextul în
care se va derula operaţia.
Evenimentul reprezintă o circumstanţă (un semnal) adusă la cunoştinţa sistemului la care
acesta trebuie să răspundă.
Etapa 1: Definirea domeniului investigat
Se analizează ce se întâmplă în momentul în care un candidat trimite un CV angajatorului
în vederea obţinerii unui post. Postul este oferit în condiţiile în care candidatul deţine experienţa
şi cunoştinţele necesare descrierii postului şi actele necesare sunt valide.
a) Candidatul
 solicită ocuparea unui post pe baza unui CV
 se prezintă la sediul firmei
 este testat
 întocmeşte dosarul de angajare
 semnează contractul

b) Angajatorul
 verifică CV-ul
 verificarea experienţei necesare postului solicitat
 testează candidatul
 verifică actele candidatului
 întocmeşte şi semnează contractul de muncă
 înregistrează contractul de muncă
 Etapa 2: Evenimente identificate

E1: Depunere CV de către candidat

E2: CV refuzat
E3: CV în aşteptare
E4: CV nou acceptat
E5: CV acceptat
E6: Prezentarea la sediul firmei a candidatului
E7: Test respins
E8: Test aprobat
E9: Depunere dosar
E10: Dosar incomplet
E11: Dosar completat
E12: Dosar complet
E13: Contract încheiat
E14: Primire contract candidat
E15: Adăugare contract la dosar
E16: Contract înregistrat
E17: Angajare efectuată

Etapa 3: Întocmirea tabloului evenimente-rezultate

Nr.
EVENIMENTE EVENIMENTE
crt ACŢIUNI EXECUTATE
DECLANŞATOARE REZULTATE
.
CV refuzat
sau
Depunere CV de către
1. Analiza CV-ului CV în aşteptare
candidat
sau
CV acceptat
2. CV în aşteptare Eliberarea unui post CV nou acceptat
Test aprobat
3. CV nou acceptat Testarea aptitudinilor Sau
Test respins
CV acceptat
Test aprobat
Şi
4. Testarea aptitudinilor Sau
Prezentarea la sediul firmei
Test respins
a candidatului
5. Test aprobat Pregătirea documentelor Depunere dosar
6. Depunere dosar Verficarea completitudinii actelor Dosar complet
necesare Sau
 Dosar incomplet
7 Dosar incomplet Înapoierea dosarului Dosar completat
Întocmirea şi semnarea
8. Dosar completat Contract încheiat
contractului de muncă
Întocmirea şi semnarea
9. Dosar complet Contract încheiat
contractului de muncă
Distribuirea contractului de muncă Primire contract candidat
10. Contract încheiat (câte un exemplar pentru fiecare şi
parte) Adăugare contract la dosar
11. Adăugare contract la dosar Înregistrarea contractului în sistem Contract înregistrat
Candidatul poate începe activitatea
12. Contract înregistrat Angajare efectuată
la data stabilită

Etapa a 4-a: Identificarea operaţiilor

OP1= Analiza CV-ului
OP2= Eliberarea unui post
OP3= Testarea aptitudinilor
OP4= Pregătirea documentelor
OP5= Verficarea completitudinii actelor necesare
OP6= Înapoierea dosarului
OP7= Întocmirea şi semnarea contractului de muncă
OP8= Distribuirea contractului de muncă (câte un exemplar pentru fiecare parte)
OP9= Înregistrarea contractului în sistem
OP10= Candidatul poate începe activitatea la data stabilită

Etapa a 5-a: Identificarea sincronizărilor

Sincronizările ce apar în cadrul modelului conceptual al prelucrărilor au fost deja marcate
în cadrul etapei a 3-a, “Întocmirea tabloului evenimente-rezultate”, deoarece acestea reprezintă
cazurile unde în cadrul primei coloane a tabloului evenimente-rezultate (cea a evenimentelor
declanşatoare) apar două sau mai multe evenimente legate printr-un operator logic (şi / sau).
Etapa a 6-a: Identificarea regulilor de emisie
OPERAŢIE REGULI DE EMISIE
R1,1- experienţa >= experienţa minimă
R1,2- Număr post >=1
Operaţia 1
R1,3- Candidatul deţine experienţa ncesară şi există posturi
disponibile
Operaţia 3 R3,1- Testul nu este realizat corect
Operaţia 5 R4,1- Dosarul este incomplet

Etapa a 7-a: Elaborarea modelului conceptual al prelucrărilor

a) Analiza candidatului

E1

Operaţia 1 Analiza CV-ului

Verifică dacă acesta deţine experienţa menţionată în CV este mai mare decât experienţa
necesară postului solicitat (experienţa > experienţa minimă) şi dacă există posturi disponibile
R1 R2 R1 şi R2
Operaţia 2 Eliberarea unui post
Realizarea unui post liber conform cerinţei

Operaţia 3 E2 Testarea
E3
aptitudinilor E4
Candidatul completează un test
NOT OK OK

E4 si E6 sau E5 și E6
E5
E6

E7 E8
 b) Întocmirea dosarului
E8

Operaţia 4 Pregătirea documentelor

Candidatul aduce documentele necesare dosarului de angajare

E9
Operaţia 5 Verficarea completitudinii actelor necesare
Angajatorul verifică existenţa tuturor actelor necesare
NOT OK OK

E10

Operaţia 6 Înapoierea dosarului

Dosarul este restituit candidatului în vederea completării acestuia

E11
E12

c) Efectuarea angajării

E11 E12

Operaţia 7 Întocmirea şi E11

semnarea
sau E12 contractului de muncă
Angajatorul emite un contract de muncă, acesta fiind semnat cu acordul ambelor părţi

E13
Operaţia 8 Distribuirea contractului de muncă (câte un exemplar pentru fiecare parte)
Fiecare parte (candidat şi angajator) primeşte câte un exemplar

E14 Operaţia 9 E15

Înregistrarea contractului în sistem
Contractul primeşte un număr de înregistrare

E16

Operaţia 10 Candidatul poate începe activitatea la data stabilită

E17
Capitolul IV. MODELAREA LOGICĂ A DATELOR

Modelul logic al datelor este o reprezentare a modelului conceptual al datelor în funcţie

de posibilităţile oferite de tehnica de calcul a momentului.

1. Modelul relaţional
Modelul relaţional este un model simplu, care permite utilizatorului să vadă baza de date ca o
colecţie de tabele, o reprezentare accesibilă atât informaticienilor cât şi neinformaticienilor.
Relaţia
 este o submulţime a produsului cartezian de N domenii
 se prezintă sub formă bidimensională (tabelară) pe linii şi coloane
 este formată din linii (rânduri) şi coloane
 mai este numită şi tabelă
Tuplul
 reprezintă o linie în cadrul tabelului
 se mai numeşte înregistrare (în engleză “record”)
Domeniul
 reprezintă un set de valori pe care le poate lua o dată (un atribut)
Atributul
 reprezintă o caracteristică care poate lua valori într-un domeniu, fiecărei caracteristici
fiindu-i rezervată o coloană în cadrul relaţiei
Cheia primară
 reprezintă un atribut sau un grup minimal de atribute ale cărui realizări pot permite
identificarea unică a unui tuplu într-o tabelă.
Cheia candidat
 reprezintă un atribut sau grup de atribute care pot prin realizările lor să identifice un
tuplu;
 dintre cheile candidate se alege atributul sau grupul de atribute care va juca rol de cheie
primară.
Cheia externă
 este un atribut din schema unei tabele care joacă rol de cheie primară într-o altă tabelă;
 atributul cu rol de cheie externă trebuie să respecte cerinţele de integritate referenţială
Schema unei relaţii
 •reprezintă lista atributelor aparţinând relaţiei, cu domeniile lor.
Gradul relaţiei
 reprezintă numărul de coloane (atribute) ale relaţiei.
Cardinalitatea relaţiei
 reprezintă numărul de rânduri ale acesteia.
 Tabel Angajator:

Cheia primară Atribute

Data
CUI Nume firmă CAEN Sediu social Telefon Fax E-mail Website
înfiinţării
RO787672 Centru de Afaceri http://
SC Visma
6920 et. 9-10-11, 0369454980 0251.411688 recrutare@visma.com 19.06.2008 www.vis
Services SRL
SIBIU ma.ro

Tuplu

Cardinalitatea relaţiei = 1
Gradul relaţiei = 9

Lista atributelor unei relaţii, împreună cu domeniile corespunzătoare formează schema relaţiei. Mulţimea schemelor
relaţionale constituie schema bazei de date. Colecţia valorilor curent memorate, în schema bazei de date, poartă numele de
bază de date relaţională
 Reguli de trecere de la modelul EA la schema bazei de date relaţionale

Regula 1
 fiecărui tip de entitate (din modelul EA) îi este asociată schema unei relaţii formată din
toate atributele tipului de entitate;
 identificatorul tipului de entitate devine cheia primară a relaţiei.
Regula 2
 dacă într-o asociere binară A fiecare dintre entităţi prezintă pentru cuplul entitate-asociere
cardinalitatea (0,1) sau (1,1) se adaugă în schema relaţiei R1 corespunzând entităţii E1
cheia primară a celeilalte relaţii, R2 corespunzătoare entităţii E2 participante la asociere;
 heia externă va trebui să respecte restricţia de integritate referenţială.
Regula 3
 dacă într-o asociere A există o singură entitate E1 pentru care cardinalitatea cuplului EA
este egală cu (0,1) sau (1,1) se adaugă în schema relaţiei R1, ce corespunde entităţii E1
cheia primară a relaţiei R2 care corespunde entităţii E2 participante la asociere;
 acest “transport” al cheii relaţiei R2 în schema relaţiei R1 (unde va juca rolul de cheie
externă) este impus de rolul dominant al primei relaţii asupra celei de a doua;
 când între două entităţi se stabileşte o asociere 1:n înseamnă că entitatea care prezintă
pentru cuplul EA cardinalitatea (1,n) sau (0,n) este dominantă, iar cea de a doua va fi
considerată entitate “fiu” şi va primi drept cheie externă cheia primară a entităţii
“părinte”, iar dacă sunt definite atribute pentru asocierea A ele vor fi cuprinse în schema
relaţiei “fiu”.
Regula 4
 dacă într-o asociere A nu există nici o entitate E pentru care cardinalitatea cuplului (EA)
să fie egală cu (0,1) sau (1,1) se va defini o a treia relaţie cuprinzând în schema sa cheile
primare ale celorlalte două relaţii (corespunzătoare entităţilor participante la asociere)
împreună cu toate atributele definite pentru asocierea A.
Tipuri de relaţii intre tabelele bazei de date Recrutare personal:

Tabelul Angajator Candidat Post Contract Dosar Criterii

Angajator - - 1:n 1:n - -
Candidat - - 1:n 1:n - 1:1
Post 1:n 1:n - 1:n - 1:n
Contract 1:n 1:n 1:n - 1:n -
Dosar - - - 1:n - -
Criterii - 1:1 1:n - - -

1: 1 one-to-one
1 : n one-to-many
 2. Modelarea fizică a datelor
Rezultatul trecerii de la MLD la MFD este reprezentat de schema internă a bazei de date. În această etapă vor fi
create tabelele, penru fiecare dintre acestea specificându-se toate elementele necesare.
Atributele tipurilor de entităţi:

Tip de entitate Atribute Tip de date şi lungime Proprietăţi Reguli de validare Text de validare
Unique,
CUI Text
Required
Nume_firmă Text Required
CAEN Number Required
Sediu_social Text Required
Angajator Telefon Text Required
Fax Text
E-mail Text Required
Unique,
Data_înfiinţării Date
Required
Website Hyperlink
CNP Number Required
Nume Text Required
Required,
Prenume Text
Indexed
[Data Candidatul nu are
Adresa Text Required vârsta necesară
naşterii]<=#01/01/1996#
Data_naşterii Date Required angajării
Candidat Adresa_e-mail Text Required
Număr_telefon Text Required
Număr_fax Text [Data începerii] < [Data Data introdusă nu
încheierii] este corectă
Studii Text Required
Loc_de_ muncă_anterior Text
Dataang Date
Data_încheierii Date/Time
 Domeniu Text
Funcţia Text
Experienţa Text
Codpost Number Required
Număr_contract Autonumber Required
Data_începerii Date Indexed
Tip_contract Text Required
Contract
Durata Text Required
CNP Text Required
CUI Number Required
Codpost Number Required
Domeniu_post Text Required
Nume_post Text Indexed
Post Disponbilitate Yes/No Required
Număr Number Required
CNP Number Required
Număr_contract Number Required
Număr_contract Number Required
Buletin Yes/No Required
Adeverinţă_medicală Yes/No Required
Dosar
Certificat_naştere Yes/No Required
Certificat_căsătorie Yes/No
Diplomă_studii Yes/No Required
Criterii Experinţa_minimă Text Required
[Experienţa] >= 1
Domeniu_corespunzător Text Required
Experienţa minimă
Studii_superioare Yes/No Required
este de 1 an
Cod post Number Required
CNP Text Required
Limbajul SQL

SQL (Structured Query Language) este în prezent, unul din cele mai puternice limbaje
structurate pentru interogarea bazelor de date relaţionale.
Cu ajutorul următoarelor interogări am reuşit să modific anumite date din tabele, să şterg
sau să introduc date noi:

1. Ordonarea candidaţilor în ordine alfabetică

SELECT Candidat.CNP, Candidat.Nume, Candidat.Prenume, Candidat.Studii,
Candidat.Loc_de_muncă_anterior, Candidat.Data_încheierii, Candidat.Funcția
FROM Candidat
ORDER BY Candidat.Nume;

2. Selectarea candidaţilor din Sibiu

SELECT Candidat.CNP, Candidat.Nume, Candidat.Prenume, Candidat.Oraș
FROM Candidat
WHERE (((Candidat.Oraș)="SB"));

3. Candidaţi la un post în domeniile existente în cadrul firmei

SELECT Candidat.CNP, Candidat.Nume, Candidat.Domeniu, Post.Nume_post,
Post.Domeniu_post
FROM Candidat INNER JOIN Post ON Candidat.CNP =Post.CNP
WHERE Post.Domeniu_post=Candidat.Domeniu

4. Ştergerea posturilor nedisponibile

DELETE *
FROM Post
WHERE Număr=0

5. Afişarea candidaţilor care au experienţa necesară angajării

SELECT Nume,CNP,YEAR(YEAR(Candidat.data_încheirii))-YEAR(Candidat.Dataang) AS
Experienţa
FROM Candidat
GROUP BY Experienţa
HAVING Experienţa= (SELECT MAX(Experienţa_minimă) FROM Criterii)

6. Afişarea contractelor din dosarul 11 şi 25

SELECT Contract.Număr_contract
FROM Contract INNERJOIN Dosar ON Contract.Număr_contract =Dosar.Număr_contract
WHERE Număr_dosar=11
INTERSECT
SELECT Contract.Număr_contract
FROM Contract INNERJOIN Dosar ON Contract.Număr_contract =Dosar.Număr_contract
WHERE Număr_dosar=25

7. Număr contracte încheiate

SELECT SUM(Număr_contract) AS Total_contracte, Tip_contract
FROM Contract
GROUP BY Tip_contract

8. Înregistrarea unui nou contract de muncă

INSERT INTO Contract (Număr_contract, Data_începerii, Tip_contract, Durata)
VALUES (74, 15.11.2014, ’Perioadă de probă’, ’3 luni’)

Am creat un formular pentru înregistrarea contractelor de muncă:

Scopul următorului raport este de a avea o evidenţă a candidaţilor în legătură cu studiile şi

experienţa acestora: