Aplicarea integritatii Datelor
Bazele de date sunt la fel de folositoare ca si calitatea datelor pe care le contin. Calitatea datelor este determinata de mai multi factori distincti, si fiecare faza din ciclul de viata a unei baze de date contribuie la calitatea finala a acesteia.
Design-ul logic al bazei de date, aplicatiile client si utilizatorul final care introduce datele in baza de date au roluri cheie in obtinerea calitatii finale.
Integritatea datelor este un factor improtant care contribuie la calitatea per ansamblu a datelor, si SQL Server 2000, ca sistem de management a bazelor de date relationale, pune la dispozitie diverse cai de promulgare a integritatii datelor. Acest capitol va arata:
Tipuri de integritate ale datelor si cum Serverul SQL va ajuta sa le aplicati
Cum sa identificati in mod unic coloane dintr-un tabel folosind PRIMARY KEY si
restrictiile UNIQUE
Cum sa validati valori in coloane noi folosind restrictiii CHECK si obiecte RULE
Cum sa furnizati valori implicite pentru coloane folosind restrictiile DEFAULT
si obiectele DEFAULT
Cum sa aplicati integritatea referentiala intre tabele folosind restrictiile FOREIGN KEY si cum sa utilizati integritatea referentiala prin cascade
Care constrangere este potrivita in fiecare caz
Tipuri de integritate ale datelor
Considerati o baza de date de tip comercial in care sa stocati informatii despre produse, clienti, vanzari, si asa mai departe.
Puteti masura integritatea datelor continute in aceasta baza de date in mai multe feluriS
Este informatia legata unui produs stocat intr-un mod consistent, si este usor de recuperat ? aveti produse diferite cu acelasi nume sau acelasi cod?
Puteti identifica clientul dumneavoastra intr-o maniera unica, chiar daca au acelasi nume ?
xista vanzari care sa nu aiba legatura cu un client anume?
xista vanzari ale unor produse neexistente?
veti o structura consistenta de preturi pentru produsele dumneavoastra?
Pentru garantarea integritatii datelor continute intr-o baza de date, trebuie sa va asigurati:
Ca fiecare valoare individuala este conforma cu o regula specifica (integritatea domeniului
Ca fiecare obiect poate si identificat in mod unic si fara echivoc (integritatea entitatii)
Ca data relatata este corect conectata (integritatea relationala)
Integritatea Domeniului
Aplicand regulile de afaceri pentru a valida datele stocate in baza de date intareste integritatea domeniului. aplicatia bazei dumneavoastra de date are diferite feluri de a valida data introdusa in baza de date, in felul urmator:
Coloana pentru date este restrictionata de valorile pe care puteti sa le introduceti in aceasta coloana. Aceasta va impiedica sa introduceti descrieri textuale in coloana de date si date in coloana de preturi
Puteti restrictiona lungimea maxima si lungimea minima pentru fiecare valoare data. De exemplu, puteti determina daca, codul produsului ar trebui sa aiba cel putin cinci caractere lungime si mai putine caractede decat zece.
Puteti restrictiona datele care se potrivesc unui anumit format. Acest lucru poate fi foarte folositor pentru a valida codurile postale sau codurile ZIP sau chiar numerele de telefon.
Poate sa fie folositor sa restrictionati aria valida de valori. puteti limita valoarea de introdus, ca ziua de nastere a unui nou client al unei banci, pana la date cuprinse intre 1800-01-01 si ziua curenta, pentru a evita posibilele greseli.
Semnificatia afacerii dupa o coloana poate avea nevoie de aplicare astfel incat valorile introduse in interiorul coloanei trebuie sa fie una din posibilele valori intr-o lista fixata . Aplicatia dumneavoastra pentru vanzari, de exemplu, poate clasifica clienti ca si clienti individuali, institutii publice, sau afaceri.
Integritatea entitatii
Orice obiect real ar trebui sa fie usor de identificat intr-o baza de date. Este dificil sa ne referim la un client astfel clientul care locuieste in Seattle, are 4 copii si 300 angajati, are varsta 40 de ani, primul nume este Peter, si numarul sau de telefon se termina in 345. Pentru oameni aceasta data poate sa fie de ajuns pentru cautarea in memoria noastra si identificarea clientului. Cu toate acestea, pentru un program de calculator, cum ar fi SQL Server 2000, aceasta metoda de identificare va forta Serverul SQL sa aplice diferite conditii in secventa , o conditie pentru fiecare atribut. Probabil ca ar fi fost mai usor sa identifice fiecare client dupa o singura valoare unica, cum ar fi de exemplu 256634, stocata intr-o coloana de identificare, cum ar fi CustomerID. In acest fel, pentru a cauta un client, Serverul SQL va trebui sa aplice o conditie foarte simpla CustomerID = 25634.
Acesta este un lucru iimportant in mod special daca doriti sa faceti o legatura intre informatie si alte entitati, deoarece fiecare legatura ar trebui bazata pe cel mai simplu link posibil.
Integritatea Referentiala
Bazele de date relationale sunt denumite ‘relationale’ deoarece unitatile de date stocate in acestea sunt legate intre ele prin relatii :
Clientii au reprezentanti de vanzari care ii servesc
Clientii inainteaza comenzi
Comenzile au o anumita ordine
Fiecare obiect intr-o ordine face referire la un singur produs
Produsele sunt organizate pe categorii
Produsele provin de la producatori
Trebuie sa va asigurati ca toate aceste legaturi sunt bine stabilite, si ca data noastra nu contine nici o data orfana, care sa nu poata avea nici o legatura cu restul datelor.
Integritatea utilizatorului definit
In unele situatii, se poate cere sa aplicati reguli de integritate complexe, care sunt imposibil de aplicat folosind structuri relationale standard. in aceste situatiii, puteti creea proceduri stocate, triggeri, functii definite de catre utilizator, sau componente externe pentru a obtine functionalitatea complexa de care aveti nevoie.
Aplicarea integritatii: restrictii (Integritatea Datelor Declarative)
Serverul SQL foloseste structuri SQL-Transact pentru aplicarea integritatii datelor. Puteti creea aceste structuri in timpul crearii tabelului sau prin alterarea definitiei tabelului dupa crearea acestuia si chiar dupa ce data a fost inserata in tabel.
Pentru a aplica integritatea entitatii, Serverul SQL foloseste restrictiile PRIMARY KEY si UNIQUE, indecsii UNIQUE, si proprietatea IDENTITY.
Functia IDENTITY este folosita pentru crearea unui camp IDENTITY intr-un tabel creat folosind comanda SELECT INTO.
Pentru integritatea domeniului, Serverul SQL pune la dispozitie restrictii le CHECK, comenzile DEFAULTl, restrictii le FOREIGN KEY, comenzile NULL si NOT NULL, si obiectele RULE si DEFAULT.
Nota
Comenzile DEFAULT sunt numite deasemenea si restrictiile DEFAULT. Deoarece restrictiile DEFAULT ne restrictioneaza valorile de introdus intr-o coloana ci mai degraba pun la dispozitie valori pentru coloane goale in operatiile INSERT, Serverul SQL 2000 le denumeste proprietati, in loc de restrictii , reflectand scopul lor cu mai multa acuratete.
Pentru aplicatrea integritatii referentiale, puteti folosi restrictii le FOREIGN KEY si CHECK. Folosind structuri complexe, cum ar fi procedurile stocate, triggerii, si functiile definite de utilizator ca facand parte din definitiile restrictiilor, este posibil sa aplicati reguli complexe de integritate in afaceri.
Cheile principale
Pentru a aplica integritatea entitatii intr-un anumit tabel, selectati campurile sau combinatiile de campuri care identifica in mod unic fiecare linie.
In general tabelele reprezinta o entitate, cum ar fi Products, si principala cheie poate sa fie la fel de simpla ca si un singur camp , care contin identificatorii unici pentru obiectele acelei entitati. A-ti putea considera numele unui produs ca un identificator unic, dar de obicei nu sunt unice intr-un tabel. De aceea, pentru a identifica in mod unic fiecare produs, veti introduce o valoare unica in campul ProductID. Prin aceasta se evita ambiguitatea cand ne referim la un produs anume. Urmarind un design al unei baze de date pur relational, ar trebui sa identificati care set de atribute naturale se identifica in mod unic cu fiecare obiect din aceea entitate. in unele cazuri, acest set va fi un singur atribut cu toate ca, in majoritatea cazurilor, setul va fi o colectie de atribute diferite. intr-un design pur relational, ar trebui sa definiti PRIMARY KEY pe acest set de atribute. Cu toate acestea, puteti creea un atribut artificial, numit ‘cheia surogata’, care se identifica in mod unic cu fiecare linie, functionand ca o simplificare a PRIMARY KEY naturala.
Nota
Puteti folosi PRIMARY KEY naturala sau o cheie artificiala surogata ca si PRIMARY KEY ce depinde de implementarea produsului pentru baze de date pe care o folositi.
Recomandarile in acest capitol se refera la Serverul SQL 2000. daca aveti nevoie sa implementati baza de date pe un alt sistem de baze de date, va recomandam sa urmariti o abordare relationala mai standard.
Punand la dispozitie o coloana artificiala intreaga pentru a fi folosita ca o cheie primara are cateva avantaje. Are o valoare scurta -numai 4 biti- si Serverul SQL foloseste aceasta valoare foarte eficient in cautarea operatiunilor si alaturarea tabelelor prin intermediul acestui camp.
Puteti defini restrictia cheii primare la nivel de coloana, dupa definitia coloanei, sau la nivel de tabel, ca parte componenta a unui tabel. O alta posibilitate este sa creati mai intai tabelul si sa adaugati restrictia principalei chei mai tarziu, folosind comanda ALTER TABLE.
Observatie
Punand la dispozitie un nume cat mai simplu restrictiilor principalei chei va va ajuta cand atunci va veti referi la restrictia in alte declaratii si cum sa identificati restrictia dupa ce a-ti primit un mesaj de la Serverul SQL.
Deoarece exista o singura restrictie PRIMARY KEY ,o denumire recomandata standard pentru PRIMARY KEY poate fi PK_TableName.
Puteti folosi codul sursa din Paragraful I.1 pentru a creea PRIMARY KEY intr-o singura coloana a unui tabel, folosind comanda CREATE TABLE.
Paragraful I.1 Definirea PRIMARY KEY intr-o singura coloana
-- Defirea PRIMARY KEY intr-o singura coloana
-- folosind numele restrictiei DEFAULT
CREATE tabel NewRegions (
RegionID int NOT NULL
PRIMARY KEY NONCLUSTERED,
RegionDescription nchar (50) NOT NULL ,
GO
DROP tabel NewRegions
GO
-- Definirea PRIMARY KEY intr-o singura coloana
-- specificarea numelui restrictiei
CREATE tabel NewRegions (
RegionID int NOT NULL
CONSTRAINT PK_NewRegions
PRIMARY KEY NONCLUSTERED,
RegionDescription nchar (50) NOT NULL ,
GO
DROP tabel NewRegions
GO
-- Definirea PRIMARY KEY intr-o singura coloana
-- specificarea numelui restrictiei
-- si definirea restrictiei la nivelul tabelului
CREATE tabel NewRegions (
RegionID int NOT NULL,
RegionDescription nchar (50) NOT NULL ,
CONSTRAINT PK_NewRegions
PRIMARY KEY NONCLUSTERED (RegionID),
GO
DROP tabel NewRegions
GO
-- Definirea PRIMARY KEY intr-o singura coloana
-- specificarea numelui restrictiei
-- si definirea restrictiei la nivelul tabelului
-- folosind comanda ALTER TABLE
CREATE tabel NewRegions (
RegionID int NOT NULL,
RegionDescription nchar (50) NOT NULL)
GO
ALTER tabel NewRegions
ADD CONSTRAINT PK_NewRegions
PRIMARY KEY NONCLUSTERED (RegionID)
GO
DROP tabel NewRegions
GO
Pentru a defini cheia primara intr-o coloana, coloana nu poate sa accepte spatii goale.
Deoarece valorile cheilor primare trebuie sa fie unice, serverul SQL creaza un index UNIQUE
cu scopul de a verifica daca noi valori exista deja in coloana. Fara acest index, Serverul SQL ar fi trebuit sa citeasca absolut fiecare linie pentru a determina unicitatea fiecarei noi valori. Acest index ia acelasi nume ca si restrictia cheii principale, si nu poate fi mutat din nou fara eliminarea restrictiei .
Puteti pune la dispozitie proprietati pentru index, cum ar fi CLUSTERED, NONCLUSTERED, sau FILLFACTOR, in definitia restrictiei . Paragraful I.2 arata cum sa declarati indexul unei PRIMARY KEY ca si NONCLUSTERED si cu un FILLFACTOR de 70%.
Paragraful I.2 Definirea PRIMARY KEY isi Proprietatile Select pentru UNIQUE INDEX
-- Definirea PRIMARY KEY intr-o singura coloana
-- si creerea indexului nonclustered
-- si 70% FillFactor
CREATE tabel NewRegions (
RegionID int NOT NULL
PRIMARY KEY NONC
LUSTERED WITH FILLFACTOR = 70,
RegionDescription nchar (50) NOT NULL ,
GO
DROP tabel NewRegions
GO
Atentie
Este important sa intelegeti ca o restrictie este o definitie care aplica validarea datelor, in timp ce un index este o structura de depozitare care accelereaza procesele de cautare. O cheie primara nu este un index, dar foloseste un index din motive legate de performanta.
Este posibil sa creati o cheie primara intr-un grup de coloane. in acest caz, nici una dintre coloane din cheia primara nu poate accepta spatii libere.
Atentie
Puteti folosi pana la 16 coloane in definirea PRIMARY KEY, atat timp cat marimea totala a cheii este mai mica de 900 bytes. Este recomandat sa tineti marimea cheii cat mai mica cu putinta.
Figura I.3 ne arata cum sa creati o restrictie PRIMARY KEY prin combinarea coloanelor ProductID si SaleID folosind doua versiuni diferite. Prima versiune creaza PRIMARY KEY direct prin comanda CREATE TABLE; a doua vresiune creaza PRIMARY KEY folosind comanda ALTER TABLE, dupa crearea tabelului.
Paragraful I.3 Definirea PRIMARY KEY in mod Multicoloana
-- Definirea unui compozit PRIMARY KEY in 2 coloane
-- specifica numele restrictiei
CREATE tabel ProductSales (
ProductID int NOT NULL,
SaleID int NOT NULL,
Quantity int NOT NULL,
Price money NOT NULL,
Description varchar(200) NULL,
CONSTRAINT PK_ProductSales
PRIMARY KEY NONCLUSTERED (ProductID, SaleID)
GO
DROP tabel ProductSales
GO
-- Definirea unui compozit PRIMARY KEY in 2 coloane
-- folosind comanda ALTER tabel
CREATE tabel ProductSales (
ProductID int NOT NULL,
SaleID int NOT NULL,
Quantity int NOT NULL,
Price money NOT NULL,
Description varchar(200) NULL)
ALTER tabel ProductSales
ADD CONSTRAINT PK_ProductSales
PRIMARY KEY NONCLUSTERED (ProductID, SaleID)
GO
DROP tabel ProductSales
GO
Serverul SQL poate sa puna la dispozitie automat valori pentru o cheie principala definita intr-o singura coloana in urmatoarele feluri:
Folosind proprietatea IDENTITY pentru coloana cu scopul de a specifica provenienta si sa incrementeze valoarea.
Folosind tipul de data uniqueidentifier combinat cu functia NEWID ca o definitie DEFAULT pentru a pune la dispozitie valori automate IGU (Identificatori globali Unici).
Declarand o functie definita de utilizator ca definitie DEFAULT, pentru a pune la dispozitie o valoare unica coloanei.
Declarand coloana un tip de date timestamp sau rowversion. Cu toate ca aceasta este o optiune corecta, nu este o solutie recomandata deoarece aceste valori se schimba de fiecare data cand linia este modificata. Avand definitia PRIMARY KEY definita in coloana timestamp va face aceasta restricitie nepotrivita ca si referirea restrictiilor pentru FOREIGN KEY definita in cadrul tabelelor relatate.
Atentie
Pentru multe sisteme de baze de date relationale, urmarind standardul ANSI SQL-92, o coloana timestamp retine data si ora ultimei modificari a liniei. Serverul SQL implementeaza valorile timestamp intr-un fel diferit, si nu este o valoare de data sau ora. De aceea exista noul item: rowversion.
Ar trebui sa folositi tipul de date rowversion, in loc de timestamp, deoarece versiunile viitoare de Server SQL ar putea implementa tipul de date timestamp in diferite moduri, probabil in felul in care este sugerat in standardul ANSI SQL-92.
Atentie
Daca folositi tipuri de date rowversion sau timestamp pentru o coloana cheie primara si nu specifica si NONCLUSTERED, linia se va muta fizic de fiecare data cand linia se va schimba deoarece Serverul SQL va schimba valoarea coloanei automat.
Puteti folosi Enterprise Manager pentru a defini PRIMARY KEY intr-un tabel. Pentru a realiza acest lucru, click dreapta pe tabel si selectati Design tabel pentru a afisa formularul Design Table.
Pentru a specifica mai multe proprietati despre PRIMARY KEY, puteti deschide formularul Properties dand click pe icoana tabel and Index Properties din toolbar . in sectiunea Indexex/Keys, puteti modifica sau sterge definitia PRIMARY KEY folosind acest formular.
Figura I.1 arata formularul Properties in care puteti afla cum sa schimbati proprietatea FILLFACTOR sau proprietatea CLUSTERED a indexului asociat lui PRIMARY KEY.
Figure I.2. Folosirea Formularulului Indexului Properties Pentru a Schimba Proprietati Ale Indexului PRIMARY KEY.
Restrictiile UNIQUE
Puteti creea o PRIMARY KEY pentru a aplica unicitatea intr-un camp sau intr-un grup de campuri, dar puteti avea doar o singura PRIMARY KEY pentru un tabel.
Daca doriti aplicarea unicitatii in alte coloane, puteti creea o restrictie UNIQUE.
Daca doriti sa aveti unicitate in alte coloane, puteti crea o restrictie UNIQUE. De exemplu, puteti avea o PRIMARY KEY definita in cheia surogata EmployeeID din tabelul Employees , dar doriti sa aplicati unicitatea pentru:
Numarul asigurarii sociale daca toti angajatii au o asigurare
Numarul national de identificare in tarile in care acesta este standardul de identificare
Numarul de identificare al pasaportului
Numarul licentei de sofer de pe permisul de conducere.
Numele complet nu este de obicei o buna referinta pentru o restrictie UNIQUE, deoarece puteti avea mai multi angajati cu acelasi nume.
ProductName poate fi o buna referinta, doar daca nu aveti mai multe produse cu aceiasi denumire si diferite marimi, culori, sau alte atribute. in acest caz, fie puneti la dispozitie un nume cu o descriere completa, incluzand toate aceste atribute, sau considerati combinatia de nume si atribute ca fiind unica in tabelul dumneavoastra.
O restrictie UNIQUE este similara cu una PRIMARY KEY, dar puteti avea mai mult de o restrictie UNIQUE pentru fiecare tabel. Cand declarati o restrictie UNIQUE, Serverul SQL creaza un index UNIQUE pentru a accelera procesul de cautare de duplicate. in acest caz, indexul ia valoarea implicita NONCLUSTERED, deoarece puteti avea mai mult de o restrictie UNIQUE dar numai un index cu clustere.
Observatie
Numarul de restrictii UNIQUE dintr-un tabel este limitat de numarul maxim de indecsi pentru fiecare tabel, adica 249 de indecsi nonclustered plus un index clustered.
Contrar restrictiei PRIMARY KEY, restrictia UNIQUE poate accepta valori NULL, insa numai una. daca restrictia este definita intr-o combinatie de campuri, fiecare camp poate accepta NULL si poate avea valori NULL, atata timp cat combinatia de valori este unica.
Sa presupunem ca a-ti declarat o restrictie UNIQUE in combinatia de campuri (HouseNumber, HouseName, Apartment, Address, City). In acest caz, puteti avea multe linii in care oricare din aceste campuri sunt NULL, dar numai o linie poate avea toate aceste NULL. in acest exemplu, tabelul poate avea diferite combinatii de intrari NULL:
Numai o linie cu NULL in toate aceste campuri.
Multe linii cu valori NULL in HouseNumber, HouseName, Apartment, Address sau City, atata timp cat celelalte campuri nu sunt NULL in acelasi timp.
Multe linii cu valori NOT NULL in aceste campuri.
Daca doriti sa aplicati unicitatea intr-o coloana care accepta multe valori NULL, o restrictie UNIQUE nu poate sa va ajute. in acest caz, ar trebui sa folositi un trigger sau o restrictie CHECK cu o functie definita de utilizator.
Daca incercati sa creati o restrictie UNIQUE pe o line sau combinatie de linii cu valori care sa nu fie unice veti primi un mesaj de eroare.
Puteti specifica optiuni pentru indexul UNIQUE, in acelasi fel ca si la definirea PRIMARY KEY. Pentru mai multe optiuni cu indexul, puteti creea un index UNIQUE in loc de o restrictie UNIQUE.
Puteti folosi paragraful Paragraful I.4 pentru a creea o restrictie UNIQUE intr-o singura coloana a tabelului, folosind declaratiile CREATE si tabel ALTER tabel , folosind optiuni de sintaxa diferite.
Paragraful I.4 Crearea restrictiilorUNIQUE
-- Definirea unei restrictii UNIQUE intr-o singura coloana
-- folosind numele implicit al restrictiei
CREATE tabel NewRegions (
RegionID int NOT NULL
UNIQUE NONCLUSTERED,
RegionDescription nchar (50) NOT NULL ,
GO
DROP tabel NewRegions
GO
-- Definirea unei restrictii UNIQUE intr-o singura coloana
-- specificand numele restrictiei
CREATE tabel NewRegions (
RegionID int NOT NULL
CONSTRAINT UC_NewRegions
UNIQUE NONCLUSTERED,
RegionDescription nchar (50) NOT NULL ,
GO
DROP tabel NewRegions
GO
-- Definirea unei restrictii UNIQUE intr-o singura coloana
-- specificand numele restrictiei
-- si definind restrictia la nivelul tabelului
CREATE tabel NewRegions (
RegionID int NOT NULL,
RegionDescription nchar (50) NOT NULL ,
CONSTRAINT UC_NewRegions
UNIQUE NONCLUSTERED (RegionID),
GO
DROP tabel NewRegions
GO
-- Definirea unei restrictii UNIQUE intr-o singura coloana
-- specificand numele restrictiei
-- si definind restrictia la nivelul tabelului
-- folosind declaratia ALTER tabel
CREATE tabel NewRegions (
RegionID int NOT NULL,
RegionDescription nchar (50) NOT NULL)
ALTER tabel NewRegions
ADD CONSTRAINT UC_NewRegions
UNIQUE NONCLUSTERED (RegionID)
GO
DROP tabel NewRegions
GO
Asa cum a fost explicat anterior in acest capitol pentru PRIMARY KEYs, puteti pune la dispozitie proprietati pentru index, cum ar fi CLUSTERED, NONCLUSTERED, sau FILLFACTOR, in definirea restrictiei . Paragraful I.5 arata cum sa declarati indexul unei restrictii UNIQUE ca nonclustered si cu FILLFACTOR de 70%.
Paragraful I.5 Crearea unei restrictii UNIQUE si Definirea Prprietatilor UNIQUE INDEX
-- Definirea unei restrictii UNIQUE intr-o singura coloana
-- si crearea indexului nonclustered
-- si 70% FillFactor
CREATE tabel NewRegions (
RegionID int NOT NULL
UNIQUE NONCLUSTERED WITH FILLFACTOR = 70,
RegionDescription nchar (50) NOT NULL ,
GO
DROP tabel NewRegions
GO
Paragraful I.6 arata cum sa creati o restrictie multicoloana UNIQUE. O restrictie UNIQUE este limitata la 16 coloane si 900 bytes ca marime.
Paragraful I.6 Crearea Unei restrictii UNIQUE Multicoloana
-- Definirea unei restrictii UNIQUE in doua coloane
-- specificand numele restrictiei
CREATE tabel ProductSales (
ProductID int NOT NULL,
SaleID int NOT NULL,
Quantity int NOT NULL,
Price money NOT NULL,
Description varchar(200) NULL,
CONSTRAINT UC_ProductSales
UNIQUE NONCLUSTERED (ProductID, SaleID)
GO
DROP tabel ProductSales
GO
-- Definirea unei restrictii UNIQUE in doua coloane
-- folosind declaratia ALTER TABLE
CREATE tabel ProductSales (
ProductID int NOT NULL,
SaleID int NOT NULL,
Quantity int NOT NULL,
Price money NOT NULL,
Description varchar(200) NULL)
ALTER tabel ProductSales
ADD CONSTRAINT UC_ProductSales
UNIQUE NONCLUSTERED (ProductID, SaleID)
GO
DROP tabel ProductSales
GO
Puteti pune la dispozitie valori implicite pentru un camp UNIQUE in acelasi mod ca si la PRIMARY KEY astfel:
Folosind proprietatea IDENTITY pentru coloana, specificand radacina si incrementand valorile.
Folosind tipul de date uniqueidentifier combinat cu functia NEWID ca o restrictie DEFAULT pentru a pune la dispozitie valori automate GUID (Global Unique Identifier).
Declarand o functie definita de utilizator ca o restrictie DEFAULT, pentru a pune la dispozitie valori unice coloanei.
Declarand coloana folosind un tip de date timestamp sau rowversion. Cu toate acestea , aceasta optiune este nefolositoare dearece valorile timestamp sunt unice, in pofida existentei unei restrictii UNIQUE, si se schimba de fiecare data cand se schimba si linia.
Atentie
O proprietate IDENTITY nu garanteaza unicitatea pe coloana sa. Serverul SQL nu garanteaza unicitatea pe coloanele IDENTITY doar daca definiti o restrictie PRIMARY KEY, o restrictie UNIQUE, sau un index UNIQUE pe aceea coloana.
Puteti folosi Enterprise Manager pentru a defini o restrictie UNIQUE intr-un tabel. Pentru a realiza acelasi lucru, click dreapta pe tabel si selectati Design tabel pentru a afisa formularul Design Table, si apoi click pe icoana tabel and Index Properties din bara de comenzi. in tabul Indexes/Keys, puteti crea, modifica, sau sterge restrictiile UNIQUE.
In formularul Properties, aveti de ales intre a creea o restrictie UNIQUE sau un index UNIQUE. Folositi indexul UNIQUE daca doriti sa puneti la dispozitie o extrafunctionalitate ca si Ignore Duplicate Key sau Do Not Automatically Recompute Statistics.
Figura I.3 arata formularul Properties in care puteti vedea cum sa definiti proprietati pentru o restrictie UNIQUE.
Figura I.4 arata un formular similar in scopul specifica rii proprietatilor pentru indexul UNIQUE asociat restrictiei UNIQUE.
Figura I.3. Folosirea formularului Properties; definirea proprietatilor pentru o restrictie UNIQUE.
Figura I.4. Folosirea unui formular similar; specificarea proprietatilor pentru indexul UNIQUE asociat restrictiei UNIQUE.
Figura I.3 Folosirea Formularului Properties; Definirea proprietatilor pentru o restrictie UNIQUE
Figura II.4. Folosirea Formularului Properties; Definirea Proprietatilor Unui Index UNIQUE
Restrictiile CHECK
O restrictie CHECK defineste o conditie pentru una sau mai multe coloane dintr-un tabel in operatiile INSERT si UPDATE.
Aceasta conditie poate fi definita de oricare expresie care returneaza TRUE sau FALSE. daca, conditia returneaza TRUE, operatia continua, dar daca operatia returneaza FALSE, operatia este intoarsa automat cu un pas inapoi.
Este posibil sa aveti multe restrictii CHECK per un tabel, in acest caz, ele vor fi verificate in ordinea creearii.
Daca o restrictie CHECK esueaza, operatia este intoarsa inapoi cu un pas si nici o alta restrictie CHECK nu mai este testata. in aceste situatia, clientul primeste un singur mesaj de eroare cu informatii despre restrictia CHECK ce a esuat. Pentru a defini o restrictie CHECK, puteti folosi orice expresie atata timp cat aceasta face referire numai la coloane in acelasi tabel. O restrictie CHECK nu poate face referire la alte linii din acelasi tabel sau alte tabele, dar este corecta utilizarea unei functii definite de utilizator ca parte a definitiei CHECK, si functia definita de utilizator poate folosi date din alte tabele, baze de date sau servere.
Puteti utiliza restrictia CHECK pentru a verifica:
Daca valoarea are un format valid. De exemplu, Postcode ar trebui sa fie un numar de 5 cifre.
Daca valoarea este intre anumite limite de date valide. De exemplu UnitPrice ar trebui sa fie intre 1 si 1,000, sau mai mare decat 0.
Daca valoarea nu este egala cu orice valoare specifica rezervata. De exemplu, numele unui nou produs nu ar trebui sa fie un string ('').
Rezultatul unei functii aplicata acestei valori. De exemplu, PaymentDue nu ar trebui sa inatarzie cu mai mult de 90 de zile de la SaleDate.
Puteti defini restrictii CHECK pe o singura coloana in timpul crearii unui tabel. Paragraful I.7 demonstraza cum sa creati o restrictie CHECK in tabelul NewEmployees pentru a va asigura ca, coloana PostCode accepta numai stringuri cu cinci caractere. Al doilea exemplu din Paragraful I.7 este crearea unei restrictii CHECK care sa aplice valori pozitive coloanei UnitPrice din tabelul Products.
Listing I.7 Crearea Unei restrictii CHECK cu declaratia CREATE tabel
-- Definirea unei restrictii CHECK intr-o singura coloana
-- folosind numele restrictiei implicit
CREATE tabel NewEmployees (
EmployeeID int NOT NULL,
EmployeeName varchar(50) NOT NULL,
PostCode char(5) NOT NULL
CHECK (PostCode LIKE '[0-9][0-9][0-9][0-9][0-9]')
GO
DROP tabel NewEmployees
GO
-- Definirea unei restrictii CHECK intr-o singura coloana
-- specificand numele restrictiei
CREATE tabel NewProducts (
ProductID int NOT NULL,
ProductName varchar(50) NOT NULL,
UnitPrice money NOT NULL
CONSTRAINT CC_Prod_UnitPrice
CHECK (UnitPrice > 0)
GO
DROP tabel NewProducts
GO
Puteti crea o restrictie CHECK la nivel de tabel cu declaratia CREATE TABLE. Aceasta este singura modalitate de a o defini daca restrictia CHECK face referire la mai mult de o coloana. Expresia poate contine orice numar de subexpresii folosind operatori logici atata timp cat expresia totala este evaluata la TRUE sau FALSE.
Paragraful I.8 contine trei exemple de restrictii CHECK:
Restrictia CC_Prod_Name CHECK forteaza coloana ProductName sa accepte numai stringuri care nu sunt nule .
Restrictia CC_Order_DueDate CHECK verifica daca timpul intre DueDate si SaleDate este mai mic sau egal decat 90 de zile.
Al treilea exemplu creaza restrictia CC_Order_DueDate CHECK pentru a verifica trei conditii in mod simultan:
o DueDate ar trebui sa fie cu maxim 90 dupa SaleDate.
o SaleDate nu poate sa fie o data in viitor.
o ShipmentMethod poate avea doar trei valori posibile aer('A'), pamant ('L'), sau apa ('S').
Paragraful I.8 Crearea restrictiilor Multicoloana CHECK cu declaratia CREATE tabel
-- Definirea unei restrictii CHECK intr-o singura coloana
-- specificand numele restrictiei
-- si definind restrictia la nivel de tabel
CREATE tabel NewProducts (
ProductID int NOT NULL,
ProductName varchar(50) NOT NULL,
UnitPrice money NOT NULL ,
CONSTRAINT CC_Prod_Name
CHECK (ProductName <> '')
GO
DROP tabel NewProducts
GO
-- Definirea unei restrictii CHECK intr-o singura coloana
-- specificand numele restrictiei
-- si definind restrictia la nivel de tabel
-- ca o expresie
CREATE tabel NewOrders (
OrderID int NOT NULL,
CustomerID int NOT NULL,
SaleDate smalldatetime NOT NULL ,
DueDate smalldatetime NOT NULL,
CONSTRAINT CC_Order_DueDate
CHECK (DATEDIFF(day, SaleDate, DueDate) <= 90)
GO
DROP tabel NewOrders
GO
-- Definirea unei restrictii CHECK intr-o singura coloana
-- specificand numele restrictiei
-- si definind restrictia la nivel de tabel
-- ca o expresie multipla legata prin operatori logici
CREATE tabel NewOrders (
OrderID int NOT NULL,
CustomerID int NOT NULL,
SaleDate smalldatetime NOT NULL ,
DueDate smalldatetime NOT NULL,
ShipmentMethod char(1) NOT NULL,
CONSTRAINT CC_Order_DueDate
CHECK
((DATEDIFF(day, SaleDate, DueDate) <= 90)
AND
(DATEDIFF(day, CURRENT_TIMESTAMP, SaleDate) <= 0)
AND (ShipmentMethod in ('A', 'L', 'S'))
GO
DROP tabel NewOrders
GO
Este posibil sa creati restrictii CHECK pentru tabele existente folosind declaratia ALTER tabel , ca in Paragraful I.9 ,in acest caz, puteti specifica daca este necesara verificarea datelor.
Primul exemplu din Paragraful I.9 creaza trei restrictii CHECK in tabelul NewOrders:
O restrictie CHECK pentru fiecare conditie utilizata in ultimul exemplu din Paragraful I.8
Al doilea exemplu din Paragraful I.9 creaza aceeasi restrictie CHECK ca si in primul exemplu, dar in acest caz se specifica sa nu fie verificate datele pentru prima si a treia restrictie CHECK.
Observatie
Daca creati o restrictie CHECK ca o secventa de conditii multiple, legate numai prin intermediul operatorului AND, fragmentati-o in cateva restrictii CHECK. Intretinerea acestor restrictii va fi mai usoara, si veti avea mai multa flexibilitatepentru activarea si dezactivarea conditiilor individuale, daca acest lucru se cere.
Paragraful I.9 Crearea restrictiilor CHECK prin intermediul declaratiilor ALTER TABLE
-- Definirea restrictiilor multiple CHECK
-- in tabelele existente specificand
-- numele restrictiei si definind
-- restrictia la nivel de tabel
-- folosind declaratia ALTER tabel
-- verificand datele existente
CREATE tabel NewOrders (
OrderID int NOT NULL,
CustomerID int NOT NULL,
SaleDate smalldatetime NOT NULL ,
DueDate smalldatetime NOT NULL,
ShipmentMethod char(1) NOT NULL)
ALTER tabel NewOrders
ADD CONSTRAINT CC_Order_DueDate
CHECK (DATEDIFF(day, SaleDate, DueDate) <= 90)
ALTER tabel NewOrders
ADD CONSTRAINT CC_Order_SaleDate
CHECK (DATEDIFF(day, CURRENT_TIMESTAMP, SaleDate) <= 0)
ALTER tabel NewOrders
ADD CONSTRAINT CC_Order_Shipment
CHECK (ShipmentMethod in ('A', 'L', 'S'))
GO
DROP tabel NewOrders
GO
-- Definirea restrictiilormultiple CHECK
-- in tabelele existente specifica nd
-- numele restrictiei si definind
-- restrictia la nivel de tabel
-- folosind declaratia ALTER tabel
-- verificand datele existente
-- numai pentru una din restrictii
CREATE tabel NewOrders (
OrderID int NOT NULL,
CustomerID int NOT NULL,
SaleDate smalldatetime NOT NULL ,
DueDate smalldatetime NOT NULL,
ShipmentMethod char(1) NOT NULL)
ALTER tabel NewOrders
WITH NOCHECK
ADD CONSTRAINT CC_Order_DueDate
CHECK (DATEDIFF(day, SaleDate, DueDate) <= 90)
ALTER tabel NewOrders
ADD CONSTRAINT CC_Order_SaleDate
CHECK (DATEDIFF(day, CURRENT_TIMESTAMP,
ALTER tabel NewOrders
WITH NOCHECK
ADD CONSTRAINT CC_Order_Shipment
CHECK (ShipmentMethod in ('A', 'L', 'S'))
GO
DROP tabel NewOrders
GO
GO
Pentru a modifica o restrictie CHECK, trebuie sa renuntati la restrictie si sa o recreati folosind Enterprise Manager.
Pentru a modifica restrictia CHECK folosind Enterprise Manager, click dreapta pe tabel si selectati Design tabel pentru a afisa formularul Design Table. Click pe icoana tabel and Index Properties din toolbar pentru a afisa formularul Properties, si selectati tabul Check Constraints. Figura I.5 arata cum sa verificati tabul Check Constraints al formularului Properties. Folosind acest formular, puteti :
Modifica numele restrictie CHECK.
Modifica expresia restrictiei .
Specifica daca doriti sa verificati datele existente.
Selecta daca doriti sa aplicati aceasta restrictie cand primiti date de la replica(activata implicit).
Aplica restrictia pentru declaratia INSERT si UPDATE (activata implicit).
Atentie
Cand modificati o restrictie CHECK folosind Enterprise Manager, Check Existing Data este dezactivata implicit. Cu toate acestea, cand creati o noua restrictie folosind Transact-SQL, aceasta optiune este activata implicit.
Observatie
Daca utilizati Enterprise Manager pentru a modifica restrictia CHECK, Enterprise Manager se va dezactiva si va recreea restrictia pentru dumneavoastra folosind noile setari.
Atentie
Verificarea restrictiilor este evaluata cand inserati datele si cand incercati sa modificati o coloana care este referita de o restrictie de verificare. Cu toate acestea, daca modificati o coloana intr-o linie preexistenta, doar aceasta coloana va fi verificata in locul restrictiei CHECK; cealalta coloana va ramane neverificata.
Verficarea restrictiilor produce anumite supraincarcari. Puteti deactiva o restrictie CHECK pentru operatiunile INSERT si UPDATE daca data de inserat este deja verificata cu aceleasi conditii. Pentru a dezactiva o restrictie pentru operatiunile INSERT si UPDATE, puteti folosi declaratiile ALTER TABLE.
Paragraful I.10 arata cum sa dezactivati si sa reactivati o restrictie CHECK.
Paragraful I.10 Utilizarea Declaratiei ALTER tabel Pentru a Activa si Dezactiva Restrictiile
-- Crearea unei restrictii CHECK
-- in tabelele existente specificand
-- numele restrictiei si definind
-- restrictia la nivel de tabel
-- folosind declaratia ALTER TABLE
-- verificand datele existente
-- Crearea tabelului
CREATE tabel NewOrders (
OrderID int NOT NULL,
CustomerID int NOT NULL,
SaleDate smalldatetime NOT NULL ,
DueDate smalldatetime NOT NULL,
ShipmentMethod char(1) NOT NULL)
-- Crearea restrictiei
ALTER tabel NewOrders
ADD CONSTRAINT CC_Order_DueDate
CHECK (DATEDIFF(day, SaleDate, DueDate) <= 90)
-- Dezactivarea restrictiei
ALTER tabel NewOrders
NOCHECK CONSTRAINT CC_Order_DueDate
-- Reactivarea restrictiei
ALTER tabel NewOrders
CHECK CONSTRAINT CC_Order_DueDate
GO
DROP tabel NewOrders
GO
Datele replicate au fost deja verificate in Publisher. Puteti creea o restrictie CHECK care este dezactivata pentru datele replicate specificand NOT FOR REPLICATION dupa cuvantul cheie CHECK.
Paragraful I.11 arata cum sa utilizati optiunea NOT FOR REPLICATION in declaratiile CREATE tabel si ALTER TABLE.
Paragraful I.11 Folosirea Optiunii NOT FOR REPLICATION Pentru a Evita Verificarea Datelor Replicate
-- Definirea unei restrictii CHECK intr-o singura coloana
-- folosind numele restrictiei implicit
-- specificand NOT FOR REPLICATION
CREATE tabel NewEmployees (
EmployeeID int NOT NULL,
EmployeeName varchar(50) NOT NULL,
PostCode char(5) NOT NULL
CHECK NOT FOR REPLICATION (PostCode LIKE '[0-9][0-9][0-9][0-9][0-9]')
GO
DROP tabel NewEmployees
GO
-- Definirea restrictiei multiple CHECK
-- in tabelele existente specificand
-- numele restrictiei si definind
-- restrictia la nivel de tabele
-- folosind declaratia ALTER tabel
-- verificand datele existente
-- specificand NOT FOR REPLICATION
CREATE tabel NewOrders (
OrderID int NOT NULL,
CustomerID int NOT NULL,
SaleDate smalldatetime NOT NULL ,
DueDate smalldatetime NOT NULL,
ShipmentMethod char(1) NOT NULL)
ALTER tabel NewOrders
ADD CONSTRAINT CC_Order_DueDate
CHECK NOT FOR REPLICATION
(DATEDIFF(day, SaleDate, DueDate) <= 90)
ALTER tabel NewOrders
ADD CONSTRAINT CC_Order_SaleDate
CHECK NOT FOR REPLICATION
(DATEDIFF(day, CURRENT_TIMESTAMP, SaleDate) <= 0)
ALTER tabel NewOrders
ADD CONSTRAINT CC_Order_Shipment
CHECK NOT FOR REPLICATION
(ShipmentMethod in ('A', 'L', 'S'))
GO
DROP tabel NewOrders
GO
Atentie
Daca dezactivati restrictia CHECK pentru a importa date, verificati datele pentru a vedea daca, conditia de verificare poate fi inca valida inaintea reactivarii restrictiei .
Puteti inlatura restrictia CHECK folosind declaratia ALTER TABLE. Inlaturand un tabel se inlatura si restrictiile asociate cu tabelul.
Folositi exemplul din Paragraful I.12 pentru a crea tabelul NewProducts, incluzand restrictia CC_Prod_UnitPrice CHECK, si renuntati la restrictie utilizand declaratia ALTER TABLE.
Paragraful I.12 Folosirea Declaratiei ALTER tabel Pentru a Inlatura Restrictiile CHECK
-- Definirea unei restrictii CHECK intr-o singura coloana
-- specificand numele restrictiei
CREATE tabel NewProducts (
ProductID int NOT NULL,
ProductName varchar(50) NOT NULL,
UnitPrice money NOT NULL
CONSTRAINT CC_Prod_UnitPrice
CHECK (UnitPrice > 0)
GO
-- Inlaturarea restrictiei
-- specificand numele acesteia
ALTER tabel NewProducts
DROP CONSTRAINT CC_Prod_UnitPrice
GO
DROP tabel NewProducts
Tip
Punerea la dispozitie a numelor restrictiilor face mai usoara inlaturarea, dezactivarea si reactivarea acestora. Altfel, ar trebui sa utilizati procedura stocata sistem sp_helpconstraint pentru a recupera informatii despre existenta restrictiilor intr-un tabel.
Definitiile DEFAULT
Puteti explicita o definitie DEFAULT pentru coloane cu scopul evitarii intrari de date repetitive. Daca o coloana are o definitie DEFAULT, aceasta valoare va fi pusa la dispozitie daca nu utilizati o valoare specifica pentru coloana din declaratia INSERT. Definitiile DEFAULT sunt aplicate numai la operatiunile INSERT.
Puteti pune la dispozitie ca o definitie DEFAULT orice expresie care este evaluata la o singura valoare scalara cu un tip de data compatibil cu tipul de data al coloanei in care definitia DEFAULT este definita. Aceasta expresie poate fi:
O valoare constanta
Orice functie scalara sistem
Rezultatul unei functii scalare definita de utilizator
Orice expresie scalara obtinuta din orice combinatie din variantele anterioare, incluzand expresiile matematice.
Puteti creea o definitie DEFAULT pentru o noua coloana utilizand declaratiile CREATE tabel sau ALTER TABLE, definind restrictiile DEFAULT la nivel de coloana. Pentru a forta utilizarea valorii implicite, puteti omite coloana, utiliza cuvantul cheie DEFAULT, sau declaratiile DEFAULT VALUES pentru INSERT, asa cum este detaliat in Paragraful I.13.
Atentie
Daca inserati in mod explicit valoarea NULL intr-o coloana ce accepta NULL, si coloana contine o definitie DEFAULT, definitia DEFAULT nu va fi aplicata.
Atentie
Puteti avea numai o definitie DEFAULT per coloana, in caz contrar, Serverul SQL nu va stii ce valoare sa utilizeze. Daca incercati sa creati mai mult de o definitie DEFAULT pentru o coloana, veti primi un mesaj de eroare.
Paragraful I.13 Creearea Definitiilor DEFAULT Folosind Declaratia CREATE tabel
-- Creearea tabelului NewCustomers
-- punand la dispozitie valoarea 'London'
-- ca o definitie a coloanei DEFAULT
-- pentru coloana City,
-- o restrictie DEFAULT numita
-- pentru coloana CustomerName,
-- Data si ora curenta
-- pentru coloana CreaDate
-- si numele de logare
-- pentru coloana CreaUser
CREATE tabel NewCustomers(
CustomerID int NOT NULL
IDENTITY(1,1)
PRIMARY KEY,
CustomerName varchar(30) NOT NULL
CONSTRAINT Def_CustName
DEFAULT 'To be entered',
City varchar(30)
DEFAULT 'London',
CreaDate smalldatetime
DEFAULT Getdate(),
CreaUser nvarchar(128)
DEFAULT System_User)
GO
-- Inserarea datelor in tabelul NewCustomers
-- Punand la dispozitie valori pentru CustomerName
-- si campurile City
INSERT NewCustomers (CustomerName, City)
VALUES ('MyComp corp.', 'New York')
-- Inserarea datelor in tabelul NewCustomers
-- Omitand inserarea campului City
INSERT NewCustomers (CustomerName)
VALUES ('ACME Inc.')
SELECT *
FROM NewCustomers
-- Inserarea datelor in tabelul NewCustomers
-- Punand la dispozitie valoarea implicita
-- pentru campul City
INSERT NewCustomers (CustomerName, City)
VALUES ('NewDotCompany Ltd.', DEFAULT)
SELECT *
FROM NewCustomers
-- Inserarea datelor in tabelul NewCustomers
-- Punand la dispozitie valoarea implicita
-- pentru fiecare camp nenul
INSERT NewCustomers
DEFAULT VALUES
SELECT *
FROM NewCustomers
-- Renuntarea la tabelul de test
DROP tabel NewCustomers
CustomerID CustomerName City CreaDate CreaUser
--------
MyComp corp. New York 2000-11-11 17:35:00 sa
ACME Inc. Lon+++don 2000-11-11 17:35:00 sa
CustomerID CustomerName City CreaDate CreaUser
MyComp corp. New York 2000-11-11 17:35:00 sa
ACME Inc. London 2000-11-11 17:35:00 sa
NewDotCompany Ltd. London 2000-11-11 17:35:00 sa
CustomerID CustomerName City CreaDate CreaUser
MyComp corp. New York 2000-11-11 17:35:00 sa
ACME Inc. London 2000-11-11 17:35:00 sa
NewDotCompany Ltd. London 2000-11-11 17:35:00 sa
To be entered London 2000-11-11 17:35:00 sa
Nota
Va puteti referi la definitiile DEFAULT ca si restrictii DEFAULT sau proprietati DEFAULT deasemenea.
Serverul SQL 2000 face referinta la ele ca si definitii DEFAULT, dar versiunile anterioare le numeau restrictii DEFAULT si folosind SQL-DMO se refera la ele ca proprietati DEFAULT.
Puteti adauga definitii DEFAULT unei coloane existente folosind declaratia ALTER TABLE, ca in Paragraful I.14.
Paragraful I.14 Crearea Unor Noi Proprietati DEFAULT Pentru Coloane Noi si Existente cu Declaratia ALTER tabel .
-- Crearea tabelului NewCustomers
-- punand la dispozitie valoarea 'London'
-- ca o definitie a coloanei DEFAULT
-- pentru coloana City,
-- si o restrictie numita DEFAULT
-- pentru coloana CustomerName
CREATE tabel NewCustomers(
CustomerID int NOT NULL
IDENTITY(1,1)
PRIMARY KEY,
CustomerName varchar(30) NOT NULL
CONSTRAINT Def_CustName
DEFAULT 'To be entered',
City varchar(30)
DEFAULT 'London',
CreaDate smalldatetime
DEFAULT CURRENT_TIMESTAMP)
GO
-- introduceti date
INSERT NewCustomers (CustomerName, City)
VALUES ('MyComp corp.', 'New York')
INSERT NewCustomers (CustomerName)
VALUES ('ACME Inc.')
INSERT NewCustomers (CustomerName, City)
VALUES ('NewDotCompany Ltd.', DEFAULT)
INSERT NewCustomers
DEFAULT VALUES
SELECT *
FROM NewCustomers
GO
-- folositi ALTER TABLE
-- pentru a adauga o coloana noua
-- cu o definitie DEFAULT
-- completand aceasta noua coloana
-- in liniile existente
ALTER tabel NewCustomers
ADD CreditLimit money
DEFAULT 1000.0
WITH VALUES
SELECT *
FROM NewCustomers
GO
-- Rrenuntati la tabelul de test
DROP tabel NewCustomers
CustomerID CustomerName City CreaDate
MyComp corp. New York 2000-11-11 17:35:00
ACME Inc. London 2000-11-11 17:35:00
NewDotCompany Ltd. London 2000-11-11 17:35:00
To be entered London 2000-11-11 17:35:00
CustomerID CustomerName City CreaDate CreditLimit
1 MyComp corp. New York 2000-11-11 17:58:00 1000.0000
ACME Inc. London 2000-11-11 17:58:00 1000.0000
NewDotCompany Ltd.London 2000-11-11 17:58:00 1000.0000
To be entered London 2000-11-11 17:58:00 1000.0000
Chei Straine
Daca aveti doua tabele care sa aiba relatii intre ele -cum ar fi TableA si TableB-relatiile intre ele pot fi de urmatoarele tipuri:
Relatii unu la unu— Figura I.6 arata relatia intre tabelul Customers si tabelul PublicCustomers. Fiecare linie din PublicCustomers este in relatie cu o singura linie din tabelul Customers, dar nu fiecare linie din tabelul Customers are o relatie cu o linie din tabelul PublicCustomers. Ca si in acest exemplu, puteti folosi relatiile unu la unu pentru a expanda un tabel creand un subtabel cu scopul de a stoca informatia care se afla in relatie cu anumite linii specifice.
Figura I.6. O relatie unu la unu.
Unu la mai multe— Figure I.7 arata relatiile intre tabelul Products si [Order Details]. Pentru fiecare produs, puteti avea una, mai multe, sau nici o linie cu relatii intre ele in tabelul [Order Details] si fiecare linie din tabelul [Order Details] este in relatie cu o singura linie din tabelul Products.
Figura I.7. O relatie unu la mai multe.
Mai multe la mai multe— EFiercare angajat poate munci in diferite teritorii, si in fiecare teritoriu puteti avea mai multi angajati. Figura I.8 arata relatia dintre tabelul Employees si Territories. asa cum puteti vedea in diagrama problema este rezolvata printr0un tabel de intersectie, EmployeesTerritories, care contine cheia de conectare la ambele tabele.
Figura I.8. O relatie mai multe la mai multe.
Pentru a stabili o relatie de la un tabel, care poate fi numit tabelul “ copil ”, catre alt tabel, care poate fi numit tabelul “ parinte ”, trebuie sa creati in tabelul “ copil ” o restrictie FOREIGN KEY.
Cand definiti o FOREIGN KEY in tabelul “ copil ”, aceasta restrictie aplica anumite reguli atat in tabelul “ parinte ”, cat si in tabelul “ copil ”:
In tabelul “ parinte ”, nu puteti modifica campul aflat in relatie cu orice linie care la randul ei este in relatie cu o alta linie din tabelul “ copil ”. De exemplu, nu puteti schimba codul produsului, altfel vanzarile acestui produs vor fi invalide.
Nu puteti sterge o linie din tabelul “ parinte ” care are relatii cu linii din tabelul “ copil ”. De exemplu, nu puteti sterge un produs cu vanzari, altfel vanzarile acestui produs vor fi orfane.
Nu puteti insera noi linii in tabelul “ copil ” unde campul aflat in relatie contine valori neexistente in campul cu care se afla in relatie din tabelul “ parinte ”. De exemplu nu puteti creea o vanzare pentru un produs neexistent.
Nu puteti modifica camp ul aflat in relatie din tabelul “ copil ” cu o noua valoare care nu exista in tabelul “ parinte ”. De exemplu, nu puteti schimba codul produsului intr-o vanzare cu un cod al unui produs neexistent.
Dupa ce FOREIGN KEY este creata, Serverul SQL va verifica fiecare declaratie ce implica tabelele pentru a preveni orice violare a relatiilor intre ele. in acest caz, declaratia va fi respinsa si data nu va mai fi modificata.
Atentie
Deoarece Serverul SQL verifica restrictiile inaintea modificarii datelor, daca oricare restrictie esueaza, datele nu vor mai fi niciodata modificate. De aceea aceasta actiune anulata va anula orice trigger care fusese definit anterior.
Puteti declara restrictia FOREIGN KEY fie folosind declaratia CREATE tabel sau ALTER TABLE
Paragraful I.16 arata un exemplu concret.
Paragraful I.16. Crearea restrictiei FOREIGN KEY cu declaratia CREATE tabel sau ALTER TABLE.
-- Crearea tabelelor Customers si Orders
CREATE tabel Customers(
CustomerID int
PRIMARY KEY,
CustomerName varchar(20) NOT NULL)
CREATE tabel Orders(
OrderID int
IDENTITY(1,1)
PRIMARY KEY,
CustomerID int NOT NULL,
OrderDate smalldatetime NOT NULL
DEFAULT CURRENT_TIMESTAMP)
GO
-- Crearea restrictiei FOREIGN KEY
ALTER tabel Orders
ADD CONSTRAINT FK_Orders
FOREIGN KEY (CustomerID)
REFERENCES Customers (CustomerID)
GO
-- Sau a-ti putea defini Orders
-- tabelul cu References
-- fara folosirea declaratiei ALTER TABLE
-- pentru a defini FOREIGN KEY
CREATE tabel Orders(
OrderID int
IDENTITY(1,1)
PRIMARY KEY,
CustomerID int NOT NULL
REFERENCES Customers(CustomerID),
OrderDate smalldatetime NOT NULL
DEFAULT CURRENT_TIMESTAMP)
--GO
-- Inserarea unor Customers
INSERT Customers
VALUES (1, 'MyComp corp.')
INSERT Customers
VALUES (2, 'ACME Inc.')
INSERT Customers
VALUES (3, 'NewDotCompany Ltd.')
-- Inserarea unor Orders
-- cu Date implicite
INSERT Orders (CustomerID)
VALUES (1)
INSERT Orders (CustomerID)
VALUES (2)
INSERT Orders (CustomerID)
VALUES (3)
INSERT Orders (CustomerID)
VALUES (3)
-- Incercarea sa upgradati clientul 3 PRIMARY KEY
-- cu o alta valoare
PRINT CHAR(10) + 'Trying to update a customer PK'+ CHAR(10)
UPDATE Customers
SET CustomerID = 30
WHERE CustomerID = 3
-- Incercarea de a insera o noua comanda pentru un
-- client neexistent
PRINT CHAR(10) + 'Trying to insert an orphan Order'+ CHAR(10)
INSERT Orders (CustomerID)
VALUES (10)
GO
DROP tabel Orders
DROP tabel Customers
Trying to update a customer PK
Server: Msg 547, Level 16, State 1, Line 1
UPDATE statement conflicted with COLUMN REFERENCE constraint 'FK_Orders'. The
conflict
occurred in database 'ByExample', tabel 'Orders', column 'CustomerID'.
The statement has been terminated.
Trying to insert an orphan Order
Server: Msg 547, Level 16, State 1, Line 1
INSERT statement conflicted with COLUMN FOREIGN KEY constraint 'FK_Orders'. The
conflict
occurred in database 'ByExample', tabel 'Customers', column 'CustomerID'.
The statement has been terminated.
Atentie
Avand o FOREIGN KEY definita intr-o coloana nu impiedica aceasta coloana sa fie nula.De aceea, este posibil sa avem linii orfane care sa nu aiba legaturi cu orice linie din tabelul parinte . Pentru a rezolva aceasta sitiatie, ar trebui sa declarati coloana ca fiind nenula.
Nota
Este necesar ca, campul sau grupul de campuri din tabelul parinte sa aiba definite un index UNIQUE. De aceea, este recomandat sa folositi cheia primara pentru campul respectiv.
Puteti folosi Enterprise Manager pentru a creea restrictii FOREIGN KEY. Cea mai simpla metoda
este sa folositi ustensila Diagram.
Figure I.10 arata cum sa creati si sa modificati restrictiile FOREIGN KEY folosind formularul Properties al tabelului “ copil ”.
Figura I.10. Folosirea formularului Properties; definirea relatiilor dintre tabele.
v
Puteti preveni verificarea datelor existente cand creati restrictia FOREIGN KEY folosind optiunea WITH NOCHECK.
Pentru a modifica restrictia FOREIGN KEY, trebuie sa renuntati la restrictie si apoi sa o recreati.
Nota
Amintiti-va ca puteti folosi ALTER TABLE NOCHECK CONSTRAINT pentru a dezactiva verificarea restrictiei si ALTER TABLE CHECK CONSTRAINT pentru a reactiva restrictia .
Pentru a preveni verificarea restrictiei FOREIGN KEY de date replicate, folositi predicatul NOT FOR REPLICATION.
Atentie
Pentru a creea o restrictie FOREIGN KEY care face referire la un index multicoloana UNIQUE, restrictii PRIMARY KEY sau UNIQUE, in tabelul “ parinte ”, trebuie sa creati FOREIGN KEY in grupul campurilor relatate.
Restrictiile FOREIGN KEY sunt anulate automat cand tabelul este anulat. Cu toate acestea, pentru a anula o restrictie puteti folosi declaratia ALTER TABLE DROP CONSTRAINT, specificand numele restrictiei pe care doriti sa o anulati.
Nota
Cand creati o restrictie FOREIGN KEY, Serverul SQL nu creeaza nici un index pe coloanele selectate. Totusi, coloanele incluse in restrictiile FOREIGN KEY sunt bune candidate pentru un index.
Operatii cascadate : Integritate referentiala declarativa cascadata.
Standardul ANSI stabileste patru moduri de rezolvare a modificarilor care pot afecta integritatea definitiilor preferentiale.
RESTRICT sau NO ACTION—Incercarea de a sterge sau a modifica o linie care este legata de anumite linii intr-un tabel “ copil ”, produce mesaj de eroare si operatia este intoarsa inapoi cu un pas. Acest lucru este implicit pentru Serverul SQL 2000.
Modificarile CASCADE—ale unui camp UNIQUE sunt cascadate la fiecare FOREIGN KEY care face referire la camp . stergerea unei linii forteaza stergerea fiecarei linii unde referintele FOREIGN KEY fac referire la linia stearsa. Acest mod este optional in Serverul SQL 2000.
SET NULL—Cand integritatea referentiala este afectata pentru anumite valori FOREIGN KEY , datorita unui upgrade sau operatiei de stergere in tabelul “ parinte ”, acele valori sunt setate NULL. Acest mod nu este implemetat in Serverul SQL 2000.
SET DEFAULT—Daca integritatea referentiala este afectata pentru anumite valori FOREIGN KEY datorita unui upgrade sau a unei operatii de stergere din tabelul “ parinte ”, valorile FOREIGN KEY sunt setate la o valoare implicita. Acest mod nu este implemetat in Serverul SQL 2000.
In sectiunile urmatoare veti observa cum sa implementati operatii cascadate in Serverul SQL 2000.
Operatiile cascadate interactioneaza cu trigger-ii in urmatoarele feluri:
1. Trigger-ii INSTEAD OF din tabelul original, se executa prima data, de obicei odata cu executia modificarilor din tabelele interioare, pe care le considerati primare pentru primul nivel de update.
2. Toate operatiile cascadate din tabelele cu prim nivel de update se executa fara o ordine predefinita. Operatiile cascadate sunt continuate prin intermediul tabelelor aflate in relatie, eventual fortand operatiile cascadate ulterioare sa fie executate afectand alte tabele, pana in momentul in care nu mai exista tabele in care sa se aplice operatii cascadate.
3. Trigger-ii AFTER de pe nivelul cel mai scazut al operatiilor cascadate se activeaza primii. La acest nivel trigger-ii din tabelele afectate se activeaza fara o ordine predefinita. La fiecare executie a triggeri-lor se trece la un nivel superior. in acest fel, avand un tabel dat, Serverul SQL, incearca sa activeze fiecare trigger AFTER doar o singura data. Trigger-ii AFTER de pe aceste nivele se activeaza numai daca trigger-ul este activat datorita modificarilor unei sau mai multor linii.
4. Trigger-ii AFTER de pe primul nivel de update se activeaza indifferent de numarul de linii afectate.
Atentie
Datorita faptului ca interactiunea dintre restrictii si triggeri poate sa fie foarte complexa, tot timpul documentati-va si mentineti proiectul cat mai simplu.
Stergeri Cascadate
Pentru a defini o restrictie FOREIGN KEY ca o actiune cascadata DELETE, trebuie sa folositi ON DELETE CASCADE in clauza REFERENCES apartinand definitiei FOREIGN KEY din declaratia CREATE tabel sau ALTER TABLE.
In Paragraful I.17, creati tabelul Customers si tabelul Orders. definiti o restrictie FOREIGN KEY dintre aceste doua tabele cu optiunea ON DELETE CASCADE. Clientul 2 are trei linii aflate in relatie in tabelul Orders. Operatia care a sters clientul 2 din tabelul Customers forteaza stergerea celor trei linii aflate in relatie din tabelul Orders.
Paragraful I.17 Stergerea Succesiva a Liniilor din Tabel Aflate in Relatie cu Restrictia FOREIGN KEY Definite ca ON DELETE CASCADE
Crearea tabelelor Customers si Orders
CREATE tabel Customers(
CustomerID int
PRIMARY KEY,
CustomerName varchar(20) NOT NULL)
CREATE tabel Orders(
OrderID int
IDENTITY(1,1)
PRIMARY KEY,
CustomerID int NOT NULL,
OrderDate smalldatetime NOT NULL
DEFAULT CURRENT_TIMESTAMP)
GO
-- Crearea restrictiei FOREIGN KEY
-- cu CASCADE
ALTER tabel Orders
ADD CONSTRAINT FK_Orders
FOREIGN KEY (CustomerID)
REFERENCES Customers (CustomerID)
ON DELETE CASCADE -- This is optional
ON UPDATE CASCADE
GO
-- Inroducerea unor clienti
INSERT Customers
VALUES (1, 'MyComp corp.')
INSERT Customers
VALUES (2, 'ACME Inc.')
INSERT Customers
VALUES (3, 'NewDotCompany Ltd.')
-- Introducerea unor comenzi
-- cu datele implicite
INSERT Orders (CustomerID)
VALUES (1)
INSERT Orders (CustomerID)
VALUES (1)
INSERT Orders (CustomerID)
VALUES (2)
INSERT Orders (CustomerID)
VALUES (2)
INSERT Orders (CustomerID)
VALUES (2)
INSERT Orders (CustomerID)
VALUES (3)
INSERT Orders (CustomerID)
VALUES (3)
-- Afisarea datelor
PRINT CHAR(10) + 'Original Customers table'+ CHAR(10)
SELECT *
FROM Customers
PRINT CHAR(10) + 'Original Orders table'+ CHAR(10)
SELECT *
FROM Orders
GO
-- Update client 3
-- Modificarea CustomerID de la 3 la 30
UPDATE Customers
SET CustomerID = 30
WHERE CustomerID = 3
PRINT CHAR(10) + 'Customers tabel after update Customer 3'+ CHAR(10)
SELECT *
FROM Customers
PRINT CHAR(10) + 'Orders tabel after update Customer 3'+ CHAR(10)
SELECT *
FROM Orders
GO
DROP tabel Orders
DROP tabel Customers
Original Customers table
CustomerID CustomerName
MyComp corp.
ACME Inc.
NewDotCompany Ltd.
Original Orders table
OrderID CustomerID OrderDate
1 2000-11-12 23:59:00
1 2000-11-12 23:59:00
2 2000-11-12 23:59:00
2 2000-11-12 23:59:00
2 2000-11-12 23:59:00
3 2000-11-12 23:59:00
3 2000-11-12 23:59:00
Customers tabel after update Customer 3
CustomerID CustomerName
MyComp corp.
ACME Inc.
30 NewDotCompany Ltd.
Orders tabel after update Customer 3
OrderID CustomerID OrderDate
1 2000-11-12 23:59:00
1 2000-11-12 23:59:00
2 2000-11-12 23:59:00
2 2000-11-12 23:59:00
2 2000-11-12 23:59:00
30 2000-11-12 23:59:00
30 2000-11-12 23:59:00
Structuri de Integritate Specifice Transact-SQL
Limbajul Transact-SQL pune la dispozitie o alternativa la restrictiile CHECK si DEFAULT cu obiectele RULE si DEFAULT. Obiectele RULE si DEFAULT nu sunt standard ANSI, asadar nu este recomandat sa folositi restrictii ca un mod general de a pune la dispozitie aceeasi functionalitate. Unul dintre motivele folosirii acestor obiecte Transact-SQL este de a creea tipuri de date definite de catre utilizator, incluzand nu numai tipul de data, dar si valoarea DEFAULT si RULE pentru a verifica integritatea domeniului. daca o coloana utilizeaza una din aceste tipuri de date definite de utilizator, ca un tip de date, aceasta coloana va mosteni definitia DEFAULT cat si definitia RULE. Folosirea obiectelor DEFAULT si RULE poate ajuta in decursul procesului. daca aceeasi conditie ar fi aplicata la coloane multiple.
Obiecte DEFAULT
Obiectele DEFAULT sunt similare definitiilor DEFAULT ale unei coloane, dar puteti creea obiecte DEFAULT in mod independent ale oricarei coloane si sa le inlocuiti cu coloane specifice sau tipuri de date definite de utilizator mai tarziu. Pentru a creea un obiect DEFAULT, folositi declaratia CREATE DEFAULT, punand la dispozitie un nume unic pentru obiectul DEFAULT si definind obiectul ca si o constanta, o functie incorporata sau orice expresie scalara valida. Pentru a sterge un obiect DEFAULT, trebuie sa folositi declaratia DROP DEFAULT. Nu puteti renunta la un obiect DEFAULT daca este folosit oriunde in baza de date.
Atentie
Singura cale de a modifica definitiile obiectelor DEFAULT si RULE este de a renunta si de a recreea obiectele. Inainte de renuntarea la un obiect trebuie sa reinlocuiti obiectul din fiecare camp si tip de data definita de utilizator.
Nota
Obiectele DEFAULT si RULE sunt locale intr-o baza de date. Prin urmare obiectele DEFAULT si RULE create in baza de date Master pot fi folosite numai in baza de date Master.
Puteti vedea un exemplu complet despre cum puteti utiliza obiectele DEFAULT in Paragraful I.19
Paragraful I.19 Crearea Obiectelor Indepedente DEFAULT si Inlocuirea lor mai Tarziu cu Orice Camp sau Tip de Data Definita de Utilizator.
-- Crearea unui obiect DEFAULT folosind o constanta
CREATE DEFAULT NoSales
AS 0
GO
-- Crearea obiectelor folosind expresiile DEFAULT
-- bazate pe functii incorporate
CREATE DEFAULT ThisMonth
AS Month(CURRENT_TIMESTAMP)
GO
CREATE DEFAULT UserDB
AS SYSTEM_USER
+ '- '+ DB_NAME(DB_ID())
GO
-- Crearea a doua tipuri de date definite de utilizator
EXEC sp_addtype 'UDDTLoginDB', 'nvarchar(256)', 'NULL'
EXEC sp_addtype 'UDDTSales', 'money', 'NULL'
GO
-- Crearea unui tabel pentru a verifica obeiectele DEFAULT
-- si tipurile de date definite de utilizator
CREATE tabel TestDefaults(
ID int NOT NULL
IDENTITY(1,1)
PRIMARY KEY,
TotalSales money NULL,
SalesMonth tinyint NULL,
WhoWhere UDDTLoginDB)
GO
-- Inserarea unei noi linii goale in tabel
INSERT TestDefaults
DEFAULT VALUES
PRINT char(10) + 'No defaults defined'+ CHAR(10)
SELECT *
FROM TestDefaults
GO
-- Inlocuirea obiectelor NoSales DEFAULT
-- cu campul TotalSales din tabelul TestDefaults
EXEC sp_bindefault 'NoSales', 'TestDefaults.TotalSales'
GO
-- Inserarea unei noi linii goale in tabel
INSERT TestDefaults
DEFAULT VALUES
PRINT CHAR(10) + 'Only DEFAULT on TotalSales defined'+ CHAR(10)
SELECT *
FROM TestDefaults
GO
-- Inlocuirea obiectului ThisMonth DEFAULT
-- cu campul SalesMonth din tabelul TestDefaults
EXEC sp_bindefault 'ThisMonth', 'TestDefaults.SalesMonth'
GO
-- Inserarea unei noi linii goale in table
INSERT TestDefaults
DEFAULT VALUES
PRINT CHAR(10) + 'DEFAULT defined on TotalSales and SalesMonth'+ CHAR(10)
SELECT *
FROM TestDefaults
GO
-- Inlocuirea obiectului UserDB DEFAULT
-- cu tipul de date definit de utilizator UDDTLginDB
EXEC sp_bindefault 'UserDB', 'UDDTLoginDB'
GO
-- Inserarea unei noi linii goale in tabel
INSERT TestDefaults
DEFAULT VALUES
PRINT CHAR(10) + 'DEFAULT defined on TotalSales, SalesMonth'
PRINT 'and the UDDTLoginDB User-Defined Data Type'+ CHAR(10)
SELECT *
FROM TestDefaults
GO
-- Adaugarea unei noi coloane in tabelul TestDefaults
-- Folosind tipul de date UDDTSales
ALTER tabel TestDefaults
ADD ProjectedSales UDDTSales
GO
PRINT CHAR(10) + 'Add an empty field using the UDDTSales data type'+ CHAR(10)
SELECT *
FROM TestDefaults
GO
-- Inlocuirea obiectului NoSales DEFAULT
-- cu tipul de date definite de utilizator UDDTSales
-- numai pentru coloane viitoare
EXEC sp_bindefault 'NoSales', 'UDDTSales', 'futureonly'
GO
-- Inserarea unei noi linii in tabel
INSERT TestDefaults
DEFAULT VALUES
PRINT CHAR(10) + 'DEFAULT defined on UDDTSales data type as futureonly'
PRINT 'does not affect the existing fields using this UDDT'+ CHAR(10)
SELECT *
FROM TestDefaults
GO
-- Renuntarea la tot in ordine
-- Primul tabel
-- Urmatorul UDDT
-- Ultimul DEFAULT
DROP tabel TestDefaults
EXEC sp_droptype 'UDDTSales'
EXEC sp_droptype 'UDDTLoginDB'
DROP DEFAULT NoSales
DROP DEFAULT ThisMonth
DROP DEFAULT UserDB
Type added.
Type added.
No defaults defined
ID TotalSales SalesMonth WhoWhere
1 NULL NULL NULL
Default bound to column.
Only DEFAULT on TotalSales defined
ID TotalSales SalesMonth WhoWhere
1 NULL NULL NULL
2 .0000 NULL NULL
Default bound to column.
DEFAULT defined on TotalSales and SalesMonth
ID TotalSales SalesMonth WhoWhere
1 NULL NULL NULL
2 .0000 NULL NULL
3 .0000 11 NULL
Default bound to data type.
The new default has been bound to columns(s) of the specified user data type.
DEFAULT defined on TotalSales, SalesMonth and the UDDTLoginDB User-Defined Data Type
ID TotalSales SalesMonth WhoWhere
1 NULL NULL NULL
2 .0000 NULL NULL
3 .0000 11 NULL
4 .0000 11 sa – ByExample
Add an empty field using the UDDTSales data type
ID TotalSales SalesMonth WhoWhere ProjectedSales
1 NULL NULL NULL NULL
2 .0000 NULL NULL NULL
3 .0000 11 NULL NULL
4 .0000 11 sa - ByExample NULL
Default bound to data type.
DEFAULT defined on UDDTSales data type as future only does not affect the existing fields
using this UDDT
ID TotalSales SalesMonth WhoWhere ProjectedSales
1 NULL NULL NULL NULL
2 .0000 NULL NULL NULL
3 .0000 11 NULL NULL
4 .0000 11 sa - ByExample NULL
5 .0000 11 sa - ByExample NULL
Type has been dropped.
Type has been dropped.
Obiecte Rule
Obiectele rule sunt similare restrictiilorcheck. Cu toate acestea, puteti creea obiecte RULE in mod independent de orice coloana si sa il inlocuiti ulterior cu coloane specifice sau tipuri de date definite de catre utilizator.
Pentru a creea un obiect RULE, folositi declaratia CREATE RULE, punand la dispozitie un nume unic pentru obiectul RULE si definind obiectul ca orice expresie care intoarce TRUE sau FALSE.
Atentie
Nu puteti folosi functii definite de catre utilizator ca parte componenta a definitiei obiectelor DEFAULT sau RULE.
Pentru a sterge un obiect RULE, trebuie folosita declaratia DROP RULE. Nu puteti renunta la un obiect RULE daca este folosit oriunde un baza dumneavoastra de date.
Puteti inlocui numai o regula cu un tip de data definit de utilizator sau un camp al unui tabel. Cu toate acestea, o regula poate coexista cu una sau mai mute restrictii CHECK intr-un camp ; in acest caz, toate conditiile vor fi verificate. daca inlocuiti o noua regula cu un camp sau tip de data definit de catre utilizator, vechea regula va fi anulata automat.
Puteti vedea un exemplu despre cum sa folositi obiecte RULE in Paragraful I.20.
Paragraful I.20 Crearea Obiectelor Independente RULE si Inlocuirea Lor Ulterior cu Orice camp sau Tip de Data definita de Catre Utilizator
-- Definirea unui tabel pentru testarea crearii RULE
CREATE tabel NewEmployees (
EmployeeID int NOT NULL,
EmployeeName varchar(50) NOT NULL,
PostCode char(5) NOT NULL )
GO
-- Crearea obiectului RULE
CREATE RULE RUPostCode
AS
(@PCode LIKE '[0-9][0-9][0-9][0-9][0-9]')
GO
-- Inlocuirea RULE cu coloana PostCode
EXEC sp_bindrule 'RUPostCode', 'NewEmployees.PostCode'
GO
-- Inserarea datelor in tabele pentru testarea RULE
INSERT NewEmployees
VALUES (1, 'Paul', 'GL513')
INSERT NewEmployees
VALUES (2, 'Eladio', '01380')
SELECT *
FROM NewEmployees
GO
DROP tabel NewEmployees
GO
DROP RULE RUPostCode
GO
Rule bound to tabel column.
Server: Msg 513, Level 16, State 1, Line 1
A column insert or update conflicts with a rule imposed by a previous CREATE RULE
statement. The statement was terminated. The conflict occurred in database
'ByExample',
table 'NewEmployees', column 'PostCode'.
The statement has been terminated.
EmployeeID EmployeeName PostCode
Eladio 01380
Nota
Amintiti-va sa pastrati totul cat mai simplu. Complicand baza de date pot aparea probleme la executie si in intretinerea acesteia.
Ce urmeaza?
In acest capitol a fost descrisa creearea si utilizarea structurilor pentru aplicarea integritatii datelor.
Capitolul II acopera creearea si stocarea procedurilor, in care puteti testa integritatea datelor inainte de a incerca orice modificare, avand control superior asupra datelor si acces la multe verificari de conditii complexe.
Capitolul III acopera trigger-ii, care reprezinta o alta cale de aplicare a integritatii datelor. in acest capitol, veti vedea cum sa creeati triggeri pentru aplicarea integritatii domeniului si integritatea referentiala.
Functiile definite de utilizator sunt descries in Capitolul IV. Este posibil sa folositi UDF ca parte a definitiilor restrictii lor.
|
