Un tutorial SQL ilustrat pentru începători. Arhive de categorii: Cărți SQL Limbajul de programare SQL pentru manechin

De la autor: te-au numit ceainic? Ei bine, asta se poate repara! Fiecare samovar a fost cândva un ceainic! Sau fiecare profesionist a fost cândva un samovar? Nu, ceva nu este în regulă din nou! În general, MySQL pentru începători.

De ce neochii au nevoie de MySQL

Dacă aveți de gând să vă conectați serios viața cu Internetul, atunci imediat la primii pași în „web” veți întâlni acest SGBD. MySQL poate fi numit în siguranță sistemul de gestionare a bazelor de date „întregul internet”. Nicio resursă mai mult sau mai puțin serioasă nu se poate descurca fără ea, ea fiind prezentă în panoul de administrare al fiecărei găzduiri. Și, mai ales, CMS populare și chiar motoare „auto-fabricate” sunt construite cu participarea ei.

În general, nu te poți descurca fără această platformă. Dar pentru a-l studia, vei avea nevoie și de abordarea potrivită, de instrumentele potrivite și, cel mai important, de dorință și răbdare. Sper că ai destule din ultimele componente. Și fii pregătit pentru faptul că creierul tău va fierbe și aburii vor ieși din cap, ca dintr-un fierbător adevărat

Dar MySQL este atât de greu pentru proști doar dacă începi să-l înveți greșit. Nu vom face o astfel de greșeală și vom începe cunoașterea acestei tehnologii de la bun început.

Noțiuni de bază

Mai întâi, să trecem prin conceptele de bază pe care le vom aminti în această publicație:

Baza de date (DB) este principala unitate constitutivă a SGBD. Baza de date include tabele, care constau din coloane și înregistrări (rânduri). Celulele formate la intersecție conțin date structurate de un anumit tip.

DBMS (sistem de management al bazelor de date) - un set de toate modulele software pentru administrarea bazelor de date.

SQL este un limbaj de interogare structurat cu care dezvoltatorul „comunica” cu nucleul (serverul) SGBD. Ca orice limbaj de programare, SQL are propria sa sintaxă, un set de comenzi și operatori și tipuri de date acceptate.

Cred că cunoştinţele teoretice sunt suficiente pentru a începe. Vom „picta” golurile lipsă în teorie cu practică. Acum rămâne să alegeți instrumentul software potrivit.

Alegerea instrumentului potrivit

Destul de „săpat” în întreaga gamă de shell-uri MySQL pentru începători, mi-am dat seama că acestea pur și simplu nu există. Toate produsele software de administrare DBMS necesită un server de baze de date deja instalat. În general, am decis încă o dată să nu inventez un „scooter” și am optat pentru pachetul intern Denwer. Îl puteți descărca de pe site-ul oficial.

Acesta include deja toate componentele DBMS, permițând unui începător să înceapă cunoașterea practică cu MySQL imediat după o instalare simplă și ușor de înțeles. În plus, Denwer include mai multe instrumente necesare unui dezvoltator începător: un server local, PHP.

Primii pasi

Nu voi descrie procesul de instalare a setului „domnului”, deoarece totul se întâmplă automat acolo. După începerea instalării, aveți timp doar să apăsați tastele necesare. Exact ceea ce aveți nevoie în varianta MySQL pentru manechin.

Când procesul de instalare se încheie, porniți serverul local, așteptați câteva secunde. După aceea, tastați localhost în bara de adrese a browserului dvs.

Pe pagina „Ura, a funcționat!” urmați unul dintre linkurile din imagine. După aceea, veți fi dus la phpMyAdmin - un shell pentru administrarea bazelor de date.

Făcând clic pe linkul http://downloads.mysql.com/docs/world.sql.zip, veți descărca un exemplu de bază de date de testare de pe site-ul web oficial MySQL. Din nou, accesați phpMyAdmin, în meniul principal din partea de sus, accesați fila „Import”. În fereastra „Import în curent”, în prima secțiune („Fișier de importat”), setați valoarea la „Prezentare generală a computerului dvs.”.

În fereastra de explorare, selectați arhiva cu baza de date eșantion descărcată. Nu uitați să faceți clic pe OK în partea de jos a ferestrei principale.

Vă sfătuiesc să nu modificați încă valorile parametrilor specificati. Acest lucru poate duce la afișarea incorectă a datelor sursă importate. Dacă sistemul phpMyAdmin a dat o eroare că nu poate recunoaște algoritmul de comprimare a bazei de date, atunci dezarhivați-l și repetați întregul proces de import de la început.

Dacă totul a mers bine, atunci va apărea un mesaj de program în partea de sus că importul a avut succes, iar în stânga în lista de baze de date mai există unul (cuvânt).

Să ne uităm la structura sa din interior, astfel încât să vă puteți imagina mai clar cu ce veți avea de a face.

Faceți clic pe numele bazei de date MySQL pentru începători. Sub acesta, va fi afișată o listă cu tabele din care constă. Faceți clic pe una dintre ele. Apoi accesați elementul din meniul de sus „Structură”. Zona principală de lucru afișează structura tabelului: toate numele coloanelor, tipurile de date și toate atributele.

Acest tutorial este ceva ca o „ștampilă a memoriei mele” în limbajul SQL (DDL, DML), adică. acestea sunt informații care s-au acumulat în cursul activităților mele profesionale și sunt stocate constant în capul meu. Acesta este un minim suficient pentru mine, care este folosit cel mai des atunci când lucrez cu baze de date. Dacă apare nevoia de a folosi constructe SQL mai complete, atunci de obicei apelez la biblioteca MSDN aflată pe Internet pentru ajutor. În opinia mea, este foarte dificil să ții totul în cap și nu este nevoie în mod special de acest lucru. Dar cunoașterea construcțiilor de bază este foarte utilă, pentru că. sunt aplicabile aproape în aceeași formă în multe baze de date relaționale precum Oracle, MySQL, Firebird. Diferențele sunt în principal în tipurile de date, care pot diferi în detalii. Nu există atât de multe construcții de bază ale limbajului SQL și, cu o practică constantă, acestea sunt reținute rapid. De exemplu, pentru a crea obiecte (tabele, constrângeri, indexuri etc.) este suficient să ai un editor de text al mediului (IDE) la îndemână pentru a lucra cu o bază de date și nu este nevoie să înveți un set de instrumente vizuale ascuțit pentru lucrul cu un anumit tip de bază de date (MS SQL, Oracle, MySQL, Firebird, …). Acest lucru este, de asemenea, convenabil, deoarece întregul text se află în fața ochilor și nu trebuie să parcurgeți numeroase file pentru a crea, de exemplu, un index sau o limită. Când lucrați constant cu baza de date, crearea, modificarea și mai ales re-crearea unui obiect folosind scripturi este de multe ori mai rapidă decât dacă se face în modul vizual. Tot în modul script (respectiv, cu atenția cuvenită), este mai ușor să stabiliți și să controlați regulile de denumire a obiectelor (parerea mea subiectivă). În plus, scripturile sunt convenabile de utilizat atunci când modificările făcute într-o bază de date (de exemplu, una de test) trebuie transferate în aceeași formă într-o altă bază de date (productivă).

Limbajul SQL este împărțit în mai multe părți, aici voi lua în considerare cele mai importante 2 părți ale acestuia:

• DML - Data Manipulation Language (limbaj de manipulare a datelor), care conține următoarele constructe:
  • SELECT - selectarea datelor
  • INSERT - introducerea de date noi
  • UPDATE - actualizare de date
  • DELETE - ștergerea datelor
  • MERGE - fuziunea datelor

pentru că Sunt un practicant, ca atare va fi puțină teorie în acest manual și toate construcțiile vor fi explicate cu exemple practice. În plus, cred că un limbaj de programare, și mai ales SQL, poate fi stăpânit doar în practică, atingându-l singur și înțelegând ce se întâmplă când executați cutare sau cutare construcție.

Acest tutorial a fost creat pe principiul Step by Step, adică. este necesar să o citim secvenţial şi de preferinţă imediat după exemple. Dar dacă pe parcurs trebuie să aflați mai detaliat despre o comandă, atunci utilizați o căutare specifică pe Internet, de exemplu, în biblioteca MSDN.

Când am scris acest tutorial, am folosit o bază de date MS SQL Server versiunea 2014 și am folosit MS SQL Server Management Studio (SSMS) pentru a rula scripturile.

Pe scurt despre MS SQL Server Management Studio (SSMS)

SQL Server Management Studio (SSMS) este un utilitar pentru Microsoft SQL Server pentru configurarea, gestionarea și administrarea componentelor bazei de date. Acest utilitar conține un editor de scripturi (pe care îl vom folosi în principal) și un program grafic care funcționează cu obiecte și setări de server. Instrumentul principal al SQL Server Management Studio este Object Explorer, care permite utilizatorului să vizualizeze, să preia și să gestioneze obiectele serverului. Acest text este împrumutat parțial de la Wikipedia.

Pentru a crea un nou editor de scripturi, utilizați butonul Interogare nouă:

Pentru a schimba baza de date curentă, puteți utiliza lista derulantă:

Pentru a executa o anumită comandă (sau un grup de comenzi), selectați-o și apăsați butonul „Execute” sau apăsați tasta „F5”. Dacă în editor există o singură comandă în acest moment sau dacă trebuie să executați toate comenzile, atunci nu trebuie să selectați nimic.

După executarea scripturilor, în special a celor care creează obiecte (tabele, coloane, indexuri), pentru a vedea modificările, utilizați Refresh din meniul contextual, evidențiind grupul corespunzător (de exemplu, Tabele), tabelul în sine sau grupul Coloane din acesta .

De fapt, acesta este tot ce trebuie să știm pentru a completa exemplele date aici. Restul utilitarului SSMS este ușor de învățat pe cont propriu.

Un pic de teorie

O bază de date relațională (RDB, sau mai departe în contextul unei baze de date) este o colecție de tabele interconectate. În linii mari, o bază de date este un fișier în care datele sunt stocate într-o formă structurată.

DBMS - sistemul de gestionare a acestor baze de date, de ex. acesta este un set de instrumente pentru lucrul cu un anumit tip de bază de date (MS SQL, Oracle, MySQL, Firebird, ...).

Notă
pentru că în viață, în vorbirea colocvială, spunem mai ales: „Oracle DB”, sau chiar doar „Oracle”, adică de fapt „Oracle DBMS”, apoi în contextul acestui tutorial se va folosi uneori termenul DB. Din context, cred că va fi clar ce anume este în joc.

Un tabel este o colecție de coloane. Coloanele pot fi numite și câmpuri sau coloane, toate aceste cuvinte vor fi folosite ca sinonime, exprimând același lucru.

Tabelul este obiectul principal al RDB, toate datele RDB sunt stocate linie cu linie în coloanele tabelului. Liniile, înregistrările sunt, de asemenea, sinonime.

Pentru fiecare tabel, precum și coloanele sale, sunt date nume, după care se face referire la acestea.
Numele obiectului (numele tabelului, numele coloanei, numele indexului etc.) în MS SQL poate avea o lungime maximă de 128 de caractere.

Pentru trimitere– în baza de date ORACLE, numele obiectelor pot avea o lungime maximă de 30 de caractere. Prin urmare, pentru o anumită bază de date, trebuie să vă dezvoltați propriile reguli pentru denumirea obiectelor pentru a îndeplini limita numărului de caractere.

SQL este un limbaj care vă permite să interogați baza de date prin intermediul SGBD. Într-un anumit SGBD, limbajul SQL poate avea o implementare specifică (propul său dialect).

DDL și DML sunt un subset al limbajului SQL:

• Limbajul DDL este folosit pentru a crea și modifica structura bazei de date, de ex. pentru a crea/modifica/sterge tabele si relatii.
• Limbajul DML vă permite să manipulați datele din tabel, de ex. cu replicile ei. Vă permite să selectați date din tabele, să adăugați date noi în tabele și să actualizați și să ștergeți datele existente.

În limbajul SQL, puteți utiliza 2 tipuri de comentarii (pe o singură linie și pe mai multe rânduri):

Comentariu pe o singură linie
Și

/* comentariu pe mai multe linii */

De fapt, totul pentru teoria acestui lucru va fi suficient.

DDL - Data Definition Language (limbaj de descriere a datelor)

De exemplu, luați în considerare un tabel cu date despre angajați, sub forma familiară unei persoane care nu este programator:

În acest caz, coloanele din tabel au următoarele nume: Număr de personal, Nume complet, Data nașterii, E-mail, Funcție, Departament.

Fiecare dintre aceste coloane poate fi caracterizată prin tipul de date pe care le conține:

• Număr de personal - număr întreg
• nume complet - șir
• Data nașterii - data
• E-mail - șir
• Poziție - șir
• departament – ​​sfoară

Tipul de coloană este o caracteristică care indică ce fel de date poate stoca această coloană.

Pentru început, va fi suficient să vă amintiți doar următoarele tipuri de date de bază utilizate în MS SQL:

Sens	Notare în MS SQL	Descriere
Șir de lungime variabilă	varchar(N) Și nvarchar(N)	Cu numărul N, putem specifica lungimea maximă posibilă a șirului pentru coloana corespunzătoare. De exemplu, dacă vrem să spunem că valoarea coloanei „Nume” poate conține maximum 30 de caractere, atunci trebuie să setăm tipul acesteia la nvarchar (30). Diferența dintre varchar și nvarchar este că varchar vă permite să stocați șiruri în format ASCII, unde un caracter ocupă 1 octet, în timp ce nvarchar stochează șiruri în format Unicode, unde fiecare caracter ocupă 2 octeți. Tipul varchar ar trebui folosit numai dacă sunteți 100% sigur că câmpul nu va trebui să stocheze caractere Unicode. De exemplu, varchar poate fi folosit pentru a stoca adrese de e-mail, deoarece de obicei conțin doar caractere ASCII.
Snur de lungime fixă	char(N) Și nchar(N)	Acest tip diferă de un șir de lungime variabilă prin faptul că, dacă lungimea șirului este mai mică de N caractere, atunci este întotdeauna completat în dreapta până la lungimea de N spații și stocat în baza de date sub această formă, adică. în baza de date ocupă exact N caractere (unde un caracter ocupă 1 octet pentru char și 2 octeți pentru nchar). În practica mea, acest tip este foarte rar folosit, iar dacă este folosit, atunci este folosit în principal în formatul char (1), adică. când câmpul este definit de un singur caracter.
Întreg	int	Acest tip ne permite să folosim numai numere întregi, atât pozitive, cât și negative, în coloană. Pentru referință (acest lucru nu este atât de relevant pentru noi acum) - intervalul de numere pe care tipul int îl permite de la -2 147 483 648 la 2 147 483 647. Acesta este de obicei tipul principal care este utilizat pentru a seta identificatorii.
Număr real sau real	pluti	În termeni simpli, acestea sunt numere în care poate fi prezentă un punct zecimal (virgulă).
data de	Data	Dacă coloana trebuie să stocheze doar Data, care constă din trei componente: Număr, Lună și An. De exemplu, 15.02.2014 (15.02.2014). Acest tip poate fi folosit pentru coloana „Data admiterii”, „Data nașterii”, etc., adică. în cazurile în care este important pentru noi să fixăm doar data, sau când componenta de timp nu este importantă pentru noi și poate fi aruncată sau dacă nu este cunoscută.
Timp	timp	Acest tip poate fi utilizat dacă coloana trebuie să stocheze numai date de timp, de ex. Ore, minute, secunde și milisecunde. De exemplu, 17:38:31.3231603 De exemplu, „Ora de plecare a zborului” zilnică.
data si ora	datetime	Acest tip vă permite să stocați atât data, cât și ora în același timp. De exemplu, 02/15/2014 5:38:31.323 PM De exemplu, aceasta ar putea fi data și ora unui eveniment.
Steag	pic	Acest tip este util pentru stocarea valorilor Da/Nu, unde Da va fi stocat ca 1 și Nu va fi stocat ca 0.

De asemenea, valoarea câmpului, în cazul în care nu este interzis, poate să nu fie specificată, în acest scop fiind folosit cuvântul cheie NULL.

Pentru a rula exemplele, să creăm o bază de date de testare numită Test.

O bază de date simplă (fără a specifica parametri suplimentari) poate fi creată prin rularea următoarei comenzi:

Test CREATE DATABASE
Puteți șterge baza de date cu comanda (ar trebui să fiți foarte atenți cu această comandă):

Testul DROP DATABASE
Pentru a trece la baza noastră de date, puteți rula comanda:

Testul SUA
Alternativ, selectați baza de date Test din lista derulantă din zona de meniu SSMS. La serviciu, folosesc adesea această metodă de comutare între baze de date.

Acum în baza noastră de date putem crea un tabel folosind descrierile așa cum sunt, folosind spații și caractere chirilice:

CREATE TABLE [Angajați]([Număr de personal] int, [Nume] nvarchar(30), [Data nașterii] data, nvarchar(30), [Posiție] nvarchar(30), [Departament] nvarchar(30))
În acest caz, va trebui să introducem numele între paranteze drepte […].

Dar în baza de date, pentru o mai mare comoditate, este mai bine să specificați toate numele obiectelor în latină și să nu folosiți spații în nume. În MS SQL, de obicei, în acest caz, fiecare cuvânt începe cu o literă mare, de exemplu, pentru câmpul „Număr de personal”, am putea seta numele NumărPersonal. De asemenea, puteți utiliza numere în nume, de exemplu, PhoneNumber1.

Pe o notă
În unele DBMS, următorul format de nume „PHONE_NUMBER” poate fi mai preferabil, de exemplu, acest format este adesea folosit în baza de date ORACLE. Desigur, la setarea numelui câmpului, este de dorit ca acesta să nu se potrivească cu cuvintele cheie utilizate în SGBD.

Din acest motiv, puteți uita de sintaxa parantezelor drepte și puteți șterge tabelul [Angajați]:

DROP TABLE [Angajați]
De exemplu, un tabel cu angajați poate fi numit „Angajați”, iar câmpurile sale pot primi următoarele nume:

• ID - Număr de personal (ID de angajat)
• Nume - nume complet
• Ziua de naștere - Data nașterii
• E-mail
• Poziţie
• Departament - Departament

Foarte des, cuvântul ID este folosit pentru a denumi câmpul de identificare.

Acum să creăm tabelul nostru:

CREATE TABLE Angajații (ID int, Nume nvarchar(30), Data nașterii, Email nvarchar(30), Poziția nvarchar(30), Departament nvarchar(30))
Puteți utiliza opțiunea NOT NULL pentru a specifica coloanele necesare.

Pentru un tabel deja existent, câmpurile pot fi redefinite folosind următoarele comenzi:

Actualizați câmpul ID ALTER TABLE Angajații ALTER COLUMN ID int NOT NULL -- update Nume câmp ALTER TABLE Angajații ALTER COLUMN Nume nvarchar(30) NOT NULL

Pe o notă
Conceptul general al limbajului SQL pentru majoritatea DBMS rămâne același (cel puțin, pot judeca acest lucru din DBMS-ul cu care am avut șansa să lucrez). Diferența dintre DDL în diferite SGBD-uri constă în principal în tipurile de date (nu doar numele lor pot diferi aici, ci și detaliile implementării lor), însăși specificul implementării limbajului SQL poate diferi ușor (adică esența comenzile este aceeași, dar pot exista mici diferențe în dialect, din păcate, dar nu există un singur standard). Cunoscând elementele de bază ale SQL, puteți trece cu ușurință de la un SGBD la altul. în acest caz, va trebui doar să înțelegeți detaliile implementării comenzilor în noul SGBD, adică. în cele mai multe cazuri, va fi suficient doar să faci o analogie.

Crearea tabelului CREATE TABLE Angajații (ID int, -- în ORACLE, tipul int este echivalentul (învelișului) pentru numărul (38) Nume nvarchar2(30), -- nvarchar2 în ORACLE este echivalent cu nvarchar în MS SQL Data nașterii, e-mail nvarchar2( 30) , Poziția nvarchar2(30), Departamentul nvarchar2(30)); -- actualizarea câmpurilor ID și Nume (aici MODIFY(…) este folosită în loc de ALTER COLUMN ALTER TABLE Angajații MODIFY(ID int NOT NULL,Name nvarchar2(30) NOT NULL); -- adăugarea unui PK (în acest caz, construcția arată ca în MS SQL, va fi afișată mai jos) ALTER TABLE Angajații ADD CONSTRAINT PK_Employees PRIMARY KEY(ID);
Pentru ORACLE, există diferențe în ceea ce privește implementarea tipului varchar2, codificarea acestuia depinde de setările bazei de date și textul poate fi salvat, de exemplu, în codificare UTF-8. În plus, lungimea câmpului în ORACLE poate fi setată atât în ​​octeți, cât și în caractere, pentru aceasta se folosesc opțiuni suplimentare BYTE și CHAR, care sunt specificate după lungimea câmpului, de exemplu:

NAME varchar2(30 BYTE) -- capacitatea câmpului va fi de 30 de octeți NAME varchar2(30 CHAR) -- capacitatea câmpului va fi de 30 de caractere
Ce optiune va fi folosita implicit BYTE sau CHAR, in cazul unei specificari simple de tip varchar2(30) in ORACLE, depinde de setarile bazei de date, poate fi setata uneori si in setarile IDE. În general, uneori te poți încurca cu ușurință, așa că în cazul ORACLE, dacă se folosește tipul varchar2 (și uneori acest lucru este justificat aici, de exemplu, când folosești codificarea UTF-8), prefer să scriu în mod explicit CHAR (pentru că de obicei este mai convenabil să citiți lungimea unui șir în caractere).

Dar în acest caz, dacă există deja unele date în tabel, atunci pentru executarea cu succes a comenzilor, este necesar ca câmpurile ID și Nume din toate rândurile tabelului să fie completate. Să demonstrăm acest lucru cu un exemplu, să inserăm date în tabel în câmpurile ID, Poziție și Departament, acest lucru se poate face cu următorul script:

INSERT Angajații (ID, Poziție, Departament) VALORI (1000,N"Director",N"Administrație"), (1001,N"Programator",N"IT"), (1002,N"Contabil", N"Contabilitate" ), (1003,N"Programator senior",N"IT")
În acest caz, comanda INSERT va arunca și o eroare, deoarece la inserare, nu am specificat valoarea câmpului obligatoriu Nume.
Dacă aveam deja aceste date în tabelul original, atunci comanda „ALTER TABLE Employees ALTER COLUMN ID int NOT NULL” ar fi fost executată cu succes, iar comanda „ALTER TABLE Employees ALTER COLUMN Name int NOT NULL” ar fi emis o eroare mesaj, că există valori NULL (nespecificate) în câmpul Nume.

Să adăugăm valori pentru câmpul Nume și să completăm din nou datele:

De asemenea, opțiunea NOT NULL poate fi folosită direct la crearea unui nou tabel, adică. în contextul comenzii CREATE TABLE.

Mai întâi, ștergeți tabelul cu comanda:

DROP TABLE Angajații
Acum să creăm un tabel cu coloanele obligatorii ID și Nume:

CREATE TABLE Angajații (ID int NU NUL, Nume nvarchar(30) NU NULL, Data nașterii, E-mail nvarchar(30), Poziția nvarchar(30), Departament nvarchar(30))
De asemenea, puteți scrie NULL după numele coloanei, ceea ce va însemna că valorile NULL (nespecificate) vor fi permise în ea, dar acest lucru nu este necesar, deoarece această caracteristică este implicită implicită.

Dacă, dimpotrivă, doriți să faceți opțională o coloană existentă, atunci utilizați următoarea sintaxă a comenzii:

ALTER TABLE Angajații ALTER COLUMN Nume nvarchar(30) NULL
Sau pur și simplu:

ALTER TABLE Angajații ALTER COLUMN Nume nvarchar(30)
Cu această comandă, putem, de asemenea, să schimbăm tipul câmpului cu un alt tip compatibil sau să modificăm lungimea acestuia. De exemplu, să extindem câmpul Nume la 50 de caractere:

ALTER TABLE Angajații ALTER COLUMN Nume nvarchar(50)

cheia principala

La crearea unui tabel, este de dorit ca acesta să aibă o coloană unică sau un set de coloane unic pentru fiecare dintre rândurile sale - o înregistrare poate fi identificată în mod unic prin această valoare unică. Această valoare se numește cheia primară a tabelului. Pentru tabelul nostru Angajați, această valoare unică ar putea fi coloana ID (care conține „Numărul de personal al angajatului” – chiar dacă în cazul nostru această valoare este unică pentru fiecare angajat și nu poate fi repetată).

Puteți crea o cheie primară pentru un tabel existent utilizând comanda:

ALTER TABLE Angajații ADD CONSTRAINT PK_Angajații CHEIE PRIMĂRĂ(ID)
Unde „PK_Employees” este numele constrângerii responsabile pentru cheia primară. De obicei, cheia primară este numită cu prefixul „PK_” urmat de numele tabelului.

Dacă cheia primară constă din mai multe câmpuri, atunci aceste câmpuri trebuie listate între paranteze separate prin virgule:

ALTER TABLE nume_tabel ADD CONSTRAINT nume_constrângere PRIMARY KEY(câmp1, câmp2,...)
Este de remarcat faptul că în MS SQL toate câmpurile care sunt incluse în cheia primară trebuie să aibă caracteristica NOT NULL.

De asemenea, cheia primară poate fi definită direct la crearea unui tabel, adică în contextul comenzii CREATE TABLE. Să ștergem tabelul:

DROP TABLE Angajații
Și apoi creați-l folosind următoarea sintaxă:

CREATE TABLE Angajații(ID int NU NULL, Nume nvarchar(30) NU NULL, data nașterii, e-mail nvarchar(30), Poziția nvarchar(30), Departament nvarchar(30), CONSTRAINT PK_Employees PRIMARY KEY(ID) -- descrieți PK după toate câmpurile ca o constrângere)
După creare, completați datele din tabel:

INSERT Angajați (ID, Poziție, Departament, Nume) VALORI (1000,N"Director",N"Administrație",N"Ivanov II.), (1001,N"Programator",N"IT",N" Petrov PP" ), (1002,N"Contabil",N"Contabilitate",N"Sidorov SS"), (1003,N"Programator senior",N"IT",N"Andreev A. DAR")
Dacă cheia primară din tabel constă numai din valorile unei coloane, atunci se poate folosi următoarea sintaxă:

CREATE TABLE Angajații(ID int NOT NULL CONSTRAINT PK_Employees PRIMARY KEY, -- specificați Nume nvarchar(30) NOT NULL, Data nașterii, E-mail nvarchar(30), Poziția nvarchar(30), Departament nvarchar(30))
De fapt, numele constrângerii poate fi omis, caz în care i se va da un nume de sistem (cum ar fi „PK__Employee__3214EC278DA42077”):

CREATE TABLE Angajații(ID int NU NULL, Nume nvarchar(30) NU NULL, Data nașterii, E-mail nvarchar(30), Poziția nvarchar(30), Departament nvarchar(30), CHEIE PRIMARIA (ID))
Sau:

CREATE TABLE Angajații (ID int NOT NULL CHEIE PRIMARĂ, Nume nvarchar(30) NU NULL, Data nașterii, E-mail nvarchar(30), Poziția nvarchar(30), Departament nvarchar(30))
Dar aș recomanda să setați întotdeauna în mod explicit numele constrângerii pentru tabelele permanente, deoarece printr-un nume dat în mod explicit și ușor de înțeles, ulterior va fi mai ușor să îl manipulați, de exemplu, îl puteți șterge:

ALTER TABLE Angajații DROP CONSTRAINT PK_Angajați
Dar o astfel de sintaxă scurtă, fără a specifica numele restricțiilor, este convenabilă de utilizat atunci când se creează tabele de baze de date temporare (numele unui tabel temporar începe cu # sau ##), care vor fi șterse după utilizare.

Să rezumam

Până acum am acoperit următoarele comenzi:

• CREAȚI TABEL table_name (enumerarea câmpurilor și a tipurilor acestora, restricții) - folosit pentru a crea un nou tabel în baza de date curentă;
• DROP TABLE table_name - folosit pentru a șterge un tabel din baza de date curentă;
• ALTER TABLE table_name ALTER COLONA nume_coloană … – folosit pentru a actualiza tipul coloanei sau pentru a modifica setările acesteia (de exemplu, pentru a seta caracteristica NULL sau NOT NULL);
• ALTER TABLE table_name ADĂUGAȚI CONSTRINGERE nume_constrângere CHEIA PRINCIPALA(câmp1, câmp2,...) – adăugarea unei chei primare la un tabel existent;
• ALTER TABLE table_name CONSTRINGERE DE CĂDERARE constraint_name - eliminați constrângerea din tabel.

Câteva despre mesele temporare

Decuparea din MSDN. Există două tipuri de tabele temporare în MS SQL Server: locale (#) și globale (##). Tabelele temporare locale sunt vizibile numai pentru creatorii lor până când sesiunea de conectare cu instanța SQL Server este încheiată odată ce sunt create pentru prima dată. Tabelele temporare locale sunt eliminate automat după ce un utilizator se deconectează de la o instanță a SQL Server. Tabelele temporare globale sunt vizibile pentru toți utilizatorii în timpul oricăror sesiuni de conexiune după crearea acestor tabele și sunt șterse atunci când toți utilizatorii care fac referire la aceste tabele se deconectează de la instanța SQL Server.

Tabelele temporare sunt create în baza de date a sistemului tempdb, de exemplu. creând-le, nu înfundam baza de date principală, altfel tabelele temporare sunt complet identice cu tabelele obișnuite, pot fi șterse și folosind comanda DROP TABLE. Tabelele temporare locale (#) sunt mai frecvent utilizate.

Pentru a crea un tabel temporar, puteți folosi comanda CREATE TABLE:

CREATE TABLE #Temp(ID int, Nume nvarchar(30))
Deoarece un tabel temporar în MS SQL este similar cu un tabel obișnuit, îl puteți șterge în consecință cu comanda DROP TABLE:

DROP TABLE #Temp

De asemenea, puteți crea un tabel temporar (precum și un tabel obișnuit) și îl puteți completa imediat cu datele returnate de interogare folosind sintaxa SELECT ... INTO:

SELECT ID, Nume INTO #Temp FROM Angajati

Pe o notă
În diferite SGBD, implementarea tabelelor temporare poate diferi. De exemplu, în DBMS-ul ORACLE și Firebird, structura tabelelor temporare trebuie definită în prealabil prin comanda CREATE GLOBAL TEMPORARY TABLE, indicând specificul stocării datelor în acesta, apoi utilizatorul îl vede printre tabelele principale și lucrează cu el. ca la o masă obișnuită.

Normalizarea bazei de date - împărțirea în sub-tabele (directoare) și determinarea relațiilor

Tabelul nostru actual de angajați are dezavantajul că utilizatorul poate introduce orice text în câmpurile Poziție și Departament, care este în primul rând plin de erori, deoarece pentru un angajat poate indica pur și simplu „IT” ca departament, iar pentru al doilea angajat, pentru de exemplu , introduceți „departamentul IT”, aveți al treilea „IT”. Ca urmare, nu va fi clar ce a vrut să spună utilizatorul, adică. Acești angajați sunt angajați ai aceluiași departament sau utilizatorul s-a descris și acestea sunt 3 departamente diferite? Și cu atât mai mult, în acest caz, nu vom putea grupa corect datele pentru un raport, unde ar putea fi necesar să se arate numărul de angajați în contextul fiecărui departament.

Al doilea dezavantaj este cantitatea de stocare a acestor informații și duplicarea acesteia, adică. pentru fiecare angajat este indicat numele complet al departamentului, ceea ce necesită un loc în baza de date pentru a stoca fiecare caracter din numele departamentului.

Al treilea dezavantaj este dificultatea actualizării acestor câmpuri dacă numele unei poziții se schimbă, de exemplu, dacă trebuie să redenumiți poziția „Programator” în „Programator junior”. În acest caz, va trebui să facem modificări la fiecare linie a tabelului, în care Poziția este egală cu „Programator”.

Pentru a evita aceste neajunsuri, se folosește așa-numita normalizare a bazei de date - împărțirea acesteia în sub-tabele, tabele de referință. Nu este necesar să urci în jungla teoriei și să studiezi ce sunt formele normale, este suficient să înțelegem esența normalizării.

Să creăm 2 tabele de referință „Poziții” și „Departamente”, primul se va numi Posturi, iar al doilea, respectiv, Departamente:

CREATE TABLE Poziții(ID int IDENTITY(1,1) NOT NULL CONSTRAINT PK_Positions CHEIE PRIMARĂ, Nume nvarchar(30) NOT NULL) CREATE TABLE Departamente(ID int IDENTITY(1,1) NOT NULL CONSTRAINT PK_Departments CHEIE PRIMARĂ, Nume nvarchar(30) ) NU NUL)
Rețineți că aici am folosit noua opțiune IDENTITATE, ceea ce înseamnă că datele din coloana ID vor fi numerotate automat, începând de la 1, cu un pas de 1, adică. atunci când se adaugă înregistrări noi, li se vor atribui succesiv valorile 1, 2, 3 și așa mai departe. Astfel de câmpuri sunt de obicei numite auto-incrementare. Un singur câmp cu proprietatea IDENTITATE poate fi definit într-un tabel și, de obicei, dar nu neapărat, un astfel de câmp este cheia primară pentru acel tabel.

Pe o notă
În diferite SGBD, implementarea câmpurilor cu contor se poate face diferit. În MySQL, de exemplu, un astfel de câmp este definit folosind opțiunea AUTO_INCREMENT. În ORACLE și Firebird, această funcționalitate ar putea fi emulată anterior folosind SEQUENCE. Dar din câte știu, ORACLE a adăugat acum opțiunea GENERATE CA IDENTITATE.

Să completăm automat aceste tabele, pe baza datelor curente înregistrate în câmpurile Poziție și Departament din tabelul Angajați:

Completați câmpul Nume din tabelul Poziții cu valori unice din câmpul Poziție din tabelul Angajați INSERT Posiții (Nume) SELECTARE DISTINCT Poziția FROM Angajații WHERE Poziția NU ESTE NUL -- eliminați înregistrările fără nicio poziție specificată
Vom face același lucru pentru tabelul Departamente:

INSERT Departments(Nume) SELECT DISTINCT Department FROM Angajații WHERE Departamentul NU ESTE NUL
Dacă deschidem acum tabelele Poziții și Departamente, vom vedea un set numerotat de valori după câmpul ID:

SELECTAȚI * FROM Poziții

SELECT * FROM Departamente

Aceste tabele vor juca acum rolul de directoare pentru stabilirea posturilor și departamentelor. Ne vom referi acum la ID-urile postului și departamentelor. În primul rând, să creăm noi câmpuri în tabelul Angajați pentru a stoca datele ID:

Adăugați câmp pentru ID-ul poziției ALTER TABLE Angajații ADD PositionID int -- adăugați câmp pentru ID-ul departamentului ALTER TABLE Angajații ADD DepartmentID int
Tipul câmpurilor de referință trebuie să fie același ca în directoare, în acest caz este int.

De asemenea, puteți adăuga mai multe câmpuri la tabel simultan cu o singură comandă, listând câmpurile separate prin virgule:

ALTER TABLE Angajații ADD PositionID int, DepartmentID int
Acum să scriem link-uri (constrângeri de referință - CHEIE STRĂINĂ) pentru aceste câmpuri, astfel încât utilizatorul să nu aibă posibilitatea de a scrie în aceste câmpuri, valori care nu se află printre valorile ID din directoare.

ALTER TABLE Angajații ADD CONSTRAINT FK_Employees_PositionID FOREIGN KEY(PositionID) REFERINȚE Poziții(ID)
Și vom face același lucru pentru al doilea câmp:

ALTER TABLE Angajații ADD CONSTRAINT FK_Employees_DepartmentID FOREIGN KEY(DepartmentID) REFERINȚE Departamente(ID)
Acum, utilizatorul va putea introduce în aceste câmpuri numai valorile ID din cartea de referință corespunzătoare. În consecință, pentru a utiliza un nou departament sau poziție, va trebui mai întâi să adauge o nouă intrare în directorul corespunzător. pentru că pozițiile și departamentele sunt acum stocate în directoare într-o singură copie, apoi pentru a schimba numele, este suficient să îl schimbați doar în director.

Numele unei constrângeri referenţiale este de obicei compus, constă din prefixul „FK_”, urmat de numele tabelului, iar după liniuţă urmează numele câmpului care se referă la identificatorul tabelului de căutare.

Identificatorul (ID) este de obicei o valoare internă care este folosită numai pentru legături și ce valoare este stocată acolo, în cele mai multe cazuri, este absolut indiferent, deci nu este nevoie să încerci să scapi de găurile din succesiunea numerelor care apar în timpul lucrului cu un tabel, de exemplu, după ștergerea înregistrărilor din manual.

ALTER TABLE table ADD CONSTRAINT constraint_name FOREIGN KEY(câmp1, câmp2,…) REFERINȚE tabel de căutare (câmp1, câmp2,…)
În acest caz, în tabelul „table_reference”, cheia primară este reprezentată de o combinație de mai multe câmpuri (câmp1, câmp2, ...).

De fapt, acum să actualizăm câmpurile PositionID și DepartmentID cu valorile ID din directoare. Să folosim comanda UPDATE DML în acest scop:

UPDATE e SET PositionID=(SELECT ID FROM Poziții WHERE Nume=e.Posiție), DepartmentID=(SELECT ID FROM Departments WHERE Nume=e.Department) FROM Angajați e
Să vedem ce se întâmplă rulând interogarea:

SELECTAȚI * FROM Angajați

Gata, câmpurile PositionID și DepartmentID sunt completate cu posturile și departamentele corespunzătoare cu ID-uri de nevoie în câmpurile Poziție și Departament din tabelul Angajați acum, puteți șterge aceste câmpuri:

ALTER TABLE Angajații DROP COLUMN Poziția, Departamentul
Tabelul arată acum așa:

SELECTAȚI * FROM Angajați

ID	Nume	Zi de nastere	E-mail	ID poziție	ID departament
1000	Ivanov I.I.	NUL	NUL	2	1
1001	Petrov P.P.	NUL	NUL	3	3
1002	Sidorov S.S.	NUL	NUL	1	2
1003	Andreev A.A.	NUL	NUL	4	3

Acestea. în cele din urmă am scăpat de stocarea informațiilor redundante. Acum, după numerele de poziție și departament, le putem determina în mod unic numele folosind valorile din tabelele de căutare:

SELECT e.ID,e.Name,p.Name PositionName,d.Name DepartmentName FROM Angajați e LEFT JOIN Departamente d ON d.ID=e.DepartmentID LEFT JOIN Poziții p ON p.ID=e.PositionID

În Object Inspector, putem vedea toate obiectele create pentru un anumit tabel. De aici puteți efectua și diverse manipulări cu aceste obiecte - de exemplu, redenumiți sau ștergeți obiecte.

De asemenea, este de remarcat faptul că un tabel se poate referi la el însuși, de ex. puteți crea un link recursiv. De exemplu, să adăugăm un alt câmp ManagerID la tabelul nostru cu angajați, care va indica angajatul căruia îi raportează acest angajat. Să creăm un câmp:

ALTER TABLE Angajații ADD ManagerID int
Valoarea NULL este permisă în acest câmp, câmpul va fi gol dacă, de exemplu, nu există superiori peste angajat.

Acum să creăm o CHEIE STRĂINĂ pe tabelul Angajați:

ALTER TABLE Angajații ADD CONSTRAINT FK_Employees_ManagerID CHEIE STRĂINĂ (ManagerID) REFERINȚE Angajații (ID)
Să creăm acum o diagramă și să vedem cum arată relațiile dintre tabelele noastre pe ea:

Ca rezultat, ar trebui să vedem următoarea imagine (tabelul Angajații este legat de tabelele Poziții și Departamente și se referă și la sine):

În cele din urmă, este de menționat că cheile de referință pot include opțiuni suplimentare ON DELETE CASCADE și ON UPDATE CASCADE, care indică cum să se comportă la ștergerea sau actualizarea unei înregistrări la care se face referire în tabelul de căutare. Dacă aceste opțiuni nu sunt specificate, atunci nu putem schimba ID-ul din tabelul de director al intrării care are legături din alt tabel și nici nu putem șterge o astfel de intrare din director până când nu ștergem toate rândurile care se referă la această intrare sau, Să actualizați aceste linii de referință la o altă valoare.

De exemplu, să recreăm tabelul cu opțiunea ON DELETE CASCADE pentru FK_Employees_DepartmentID:

DROP TABLE Angajații CREATE TABLE Angajații(ID int NOT NULL, Nume nvarchar(30), data nașterii, e-mail nvarchar(30), PositionID int, DepartmentID int, ManagerID int, CONSTRAINT PK_Employees PRIMARY KEY (ID), CONSTRAINT FK_Employees_DepartmentID FOREIGN KEY ) REFERINȚE Departamente(ID) ON DELETE CASCADE, CONSTRAINT FK_Employees_PositionID FOREIGN KEY(PositionID) REFERINȚE Poziții(ID), CONSTRAINT FK_Employees_ManagerID FOREIGN KEY (ManagerID) REFERINȚE Employees(ID)Nameye) )VALORI (1000,N"Ivanov II","19550219",2,1,NULL), (1001,N"Petrov PP","19831203",3,3,1003), (1002 ,N"Sidorov SS" ,"19760607",1,2,1000), (1003,N"Andreev AA","19820417",4,3,1000)
Să eliminăm departamentul cu ID 3 din tabelul Departamente:

DELETE Departamentele WHERE ID=3
Să ne uităm la datele din tabelul Angajații:

SELECTAȚI * FROM Angajați

ID	Nume	Zi de nastere	E-mail	ID poziție	ID departament	ID manager
1000	Ivanov I.I.	1955-02-19	NUL	2	1	NUL
1002	Sidorov S.S.	1976-06-07	NUL	1	2	1000

După cum puteți vedea, datele pentru departamentul 3 au fost și ele șterse din tabelul Angajații.

Opțiunea ON UPDATE CASCADE se comportă în mod similar, dar are efect la actualizarea valorii ID din director. De exemplu, dacă schimbăm ID-ul poziției în directorul de poziții, atunci în acest caz DepartmentID din tabelul Angajați va fi actualizat la noua valoare ID pe care am setat-o ​​în director. Dar în acest caz, pur și simplu nu va fi posibil să se demonstreze acest lucru, deoarece. coloana ID din tabelul Departamente are opțiunea IDENTITATE, care ne va împiedica să executăm următoarea interogare (schimbați ID-ul departamentului 3 în 30):

UPDATE Departamente SET ID=30 WHERE ID=3
Principalul lucru este să înțelegeți esența acestor 2 opțiuni ON DELETE CASCADE și ON UPDATE CASCADE. Folosesc aceste opțiuni în ocazii foarte rare și vă recomand să vă gândiți bine înainte de a le specifica într-o constrângere referențială. dacă ștergeți accidental o înregistrare din tabelul de referință, acest lucru poate duce la probleme mari și poate crea o reacție în lanț.

Să restabilim departamentul 3:

Acordați permisiunea de a adăuga/modifica valorile IDENTITY ​​SET IDENTITY_INSERT Departamente ON INSERT Departments(ID,Name) VALUES(3,N"IT") -- refuza adăugarea/modificarea IDENTITY values ​​​​SET IDENTITY_INSERT Departments OFF
Ștergeți complet tabelul de angajați folosind comanda TRUNCATE TABLE:

TRUNCATE TABLE Angajații
Și din nou, reîncărcați datele în ele folosind comanda anterioară INSERT:

INSERT Angajații (ID, Nume, Zi de naștere, ID Poziție, ID Departament, ID Manager) VALORI (1000,N"Ivanov II","19550219",2,1,NULL), (1001,N"Petrov P.P." ,"19831203",3 ,3,1003), (1002,N"Sidorov SS","19760607",1,2,1000), (1003,N"Andreev AA","19820417" ,4,3,1000)

Să rezumam

În acest moment, au fost adăugate câteva comenzi DDL la cunoștințele noastre:

• Adăugarea proprietății IDENTITATE la câmp - vă permite să faceți acest câmp automat completat (contor câmp) pentru tabel;
• ALTER TABLE table_name ADĂUGA list_of_fields_with_characteristics – vă permite să adăugați noi câmpuri la tabel;
• ALTER TABLE table_name COLOCARE COLONA list_of_fields - vă permite să eliminați câmpuri din tabel;
• ALTER TABLE table_name ADĂUGAȚI CONSTRINGERE nume_constrângere CHEIE EXTERNĂ(câmpuri) REFERINȚE lookup_table(fields) – vă permite să definiți o relație între un tabel și un tabel de căutare.

Alte restricții - UNIQUE, DEFAULT, VERIFICARE

Cu constrângerea UNIQUE, puteți spune că valoarea pentru fiecare rând dintr-un anumit câmp sau set de câmpuri trebuie să fie unică. În cazul tabelului Angajați, putem impune o astfel de restricție în câmpul Email. Doar pre-populați e-mailul cu valori dacă acestea nu sunt deja definite:

UPDATE Angajații SET Email=" [email protected]„WHERE ID=1000 UPDATE Angajații SET Email=" [email protected]" WHERE ID=1001 UPDATE Angajații SET Email=" [email protected]„WHERE ID=1002 UPDATE Angajații SET Email=" [email protected]" WHERE ID=1003
Și acum puteți impune o restricție unică pe acest câmp:

ALTER TABLE Angajații ADD CONSTRAINT UQ_Employees_Email UNIQUE(E-mail)
Acum utilizatorul nu va putea introduce același e-mail pentru mai mulți angajați.

Constrângerea de unicitate este de obicei denumită după cum urmează - mai întâi vine prefixul „UQ_”, apoi numele tabelului și după liniuță este numele câmpului asupra căruia este impusă această constrângere.

În consecință, dacă o combinație de câmpuri ar trebui să fie unică în contextul rândurilor din tabel, atunci le enumerăm separate prin virgule:

ALTER TABLE nume_tabel ADD CONSTRAINT nume_constrângere UNIQUE(câmp1, câmp2,...)
Adăugând o constrângere DEFAULT unui câmp, putem seta o valoare implicită care va fi înlocuită dacă câmpul nu este listat în lista de câmpuri a comenzii INSERT atunci când este inserată o nouă înregistrare. Această restricție poate fi setată direct la crearea unui tabel.

Să adăugăm un câmp nou „Data recrutării” la tabelul Angajați și să-i denumim HireDate și să spunem că valoarea implicită pentru acest câmp va fi data curentă:

ALTER TABLE Angajații ADD HireDate data NOT NULL DEFAULT SYSDATETIME()
Sau dacă coloana HireDate există deja, atunci se poate folosi următoarea sintaxă:

ALTER TABLE Angajații ADAUGĂ SYSDATETIME() IMPLICITĂ PENTRU HireDate
Aici nu am specificat numele constrângerii, pentru că în cazul DEFAULT, am fost de părere că acest lucru nu este atât de critic. Dar dacă o faci într-un mod bun, atunci cred că nu trebuie să fii leneș și ar trebui să setezi un nume normal. Acest lucru se face după cum urmează:

ALTER TABLE Angajații ADD CONSTRAINT DF_Employees_HireDate DEFAULT SYSDATETIME() FOR HireDate
Deoarece această coloană nu exista înainte, atunci când este adăugată la fiecare înregistrare, valoarea datei curente va fi inserată în câmpul HireDate.

La adăugarea unei noi intrări, data curentă va fi de asemenea inserată automat, desigur, dacă nu o setăm în mod explicit, adică. nespecificate în lista de coloane. Să arătăm acest lucru cu un exemplu fără a specifica câmpul HireDate din lista de valori adăugate:

INSERT Angajații(ID,Nume,E-mail)VALUES(1004,N"Sergeev S.S."," [email protected]")
Să vedem ce s-a întâmplat:

SELECTAȚI * FROM Angajați

ID	Nume	Zi de nastere	E-mail	ID poziție	ID departament	ID manager	Data angajării
1000	Ivanov I.I.	1955-02-19	[email protected]	2	1	NUL	2015-04-08
1001	Petrov P.P.	1983-12-03	[email protected]	3	4	1003	2015-04-08
1002	Sidorov S.S.	1976-06-07	[email protected]	1	2	1000	2015-04-08
1003	Andreev A.A.	1982-04-17	[email protected]	4	3	1000	2015-04-08
1004	Sergheev S.S.	NUL	[email protected]	NUL	NUL	NUL	2015-04-08

Constrângerea de verificare CHECK este utilizată atunci când este necesară verificarea valorilor introduse în câmp. De exemplu, să impunem această restricție în câmpul numărul de personal, care este identificatorul nostru de angajat (ID). Folosind această constrângere, să presupunem că numerele de personal trebuie să aibă o valoare de la 1000 la 1999:

ALTER TABLE Angajații ADD CONSTRAINT CK_Employees_ID VERIFICARE (ID ÎNTRE 1000 ȘI 1999)
Constrângerea este de obicei numită la fel, mai întâi cu prefixul „CK_”, apoi numele tabelului și numele câmpului pe care se aplică constrângerea.

Să încercăm să introducem o intrare nevalidă pentru a verifica dacă restricția funcționează (ar trebui să obținem eroarea corespunzătoare):

INSERT Angajații(ID,E-mail) VALUES(2000," [email protected]")
Acum să schimbăm valoarea de inserat la 1500 și să ne asigurăm că înregistrarea este inserată:

INSERT Angajații(ID,E-mail) VALUES(1500," [email protected]")
De asemenea, puteți crea constrângeri UNIQUE și CHECK fără a specifica un nume:

ALTER TABLE Angajații ADD UNIQUE(E-mail) ALTER TABLE Angajații ADD CHECK(ID ÎNTRE 1000 ȘI 1999)
Dar aceasta nu este o practică bună și este mai bine să specificați în mod explicit numele constrângerii, deoarece pentru a vă da seama mai târziu ce va fi mai dificil, va trebui să deschideți obiectul și să vedeți de ce este responsabil.

Cu un nume bun, multe informații despre o constrângere pot fi învățate direct din numele acesteia.

Și, în consecință, toate aceste restricții pot fi create imediat la crearea unui tabel, dacă acesta nu există deja. Să ștergem tabelul:

DROP TABLE Angajații
Și recreați-l cu toate constrângerile create cu o singură comandă CREATE TABLE:

CREATE TABLE Employees(ID int NOT NULL, Nume nvarchar(30), Data zilei de naștere, Email nvarchar(30), PositionID int, DepartmentID int, HireDate date NOT NULL DEFAULT SYSDATETIME(), -- pentru DEFAULT voi arunca un CONSTRAINT PK_Employees PRIMARY CHEIE excepție (ID), CONSTRAINT FK_Employees_DepartmentID FOREIGN KEY(DepartmentID) REFERINȚE Departamente(ID), CONSTRAINT FK_Employees_PositionID FOREIGN KEY(PositionID) REFERINȚE Poziții(ID), CONSTRAINT UQ_Employees_Employees_Email_Email), UNCONSTRAINT CHEIE CHEIE_Email)

INSERT Angajații (ID, Nume, Zi de naștere, E-mail, ID Poziție, ID Departament) VALORI (1000,N"Ivanov I.I.","19550219"," [email protected]",2,1), (1001,N"Petrov P.P.","19831203"," [email protected]",3,3), (1002,N"Sidorov S.S.","19760607"," [email protected]",1,2), (1003,N"Andreev A.A.","19820417"," [email protected]",4,3)

Câteva informații despre indecșii creați la crearea constrângerilor PRIMARY KEY și UNIQUE

După cum puteți vedea în captura de ecran de mai sus, la crearea constrângerilor PRIMARY KEY și UNIQUE, indexurile cu aceleași nume (PK_Employees și UQ_Employees_Email) au fost creați automat. În mod implicit, indexul pentru cheia primară este creat ca CLUSTERED, iar pentru toți ceilalți indecși ca NONCLUSTERED. Merită spus că conceptul de index cluster nu este disponibil în toate SGBD. Un tabel poate avea un singur index CLUSTERED. CLUSTERED - înseamnă că înregistrările tabelului vor fi sortate după acest index, se mai poate spune că acest index are acces direct la toate datele din tabel. Este, ca să spunem așa, indexul principal al tabelului. Ca să spun și mai aspru, este un index înșurubat pe masă. Indexul grupat este un instrument foarte puternic care poate ajuta la optimizarea interogărilor, țineți cont de acest lucru. Dacă vrem să spunem că indexul grupat este folosit nu în cheia primară, ci pentru un alt index, atunci când creăm cheia primară, trebuie să specificăm opțiunea NONCLUSTERED:

ALTER TABLE nume_tabel ADD CONSTRAINT nume_constrângere PRIMARY KEY NONCLUSTERED(câmp1, câmp2,...)
De exemplu, să facem ca indicele de constrângere PK_Employees să nu fie grupat, iar indicele de constrângere UQ_Employees_Email să fie grupat. În primul rând, să eliminăm aceste restricții:

ALTER TABLE Angajații DROP CONSTRAINT PK_Angajați ALTER TABLE Angajații DROP CONSTRAINT UQ_Employees_Email
Și acum să le creăm cu opțiunile CLUSTERED și NONCLUSTERED:

ALTER TABLE Angajații ADD CONSTRAINT PK_Employees CHEIE PRIMARĂ NONCLUSTERED (ID) ALTER TABLE Angajații ADD CONSTRAINT UQ_Employees_Email UNIQUE CLUSTERED (E-mail)
Acum, când selectăm din tabelul de angajați, putem vedea că înregistrările sunt sortate după indexul grupat UQ_Employees_Email:

SELECTAȚI * FROM Angajați

ID	Nume	Zi de nastere	E-mail	ID poziție	ID departament	Data angajării
1003	Andreev A.A.	1982-04-17	[email protected]	4	3	2015-04-08
1000	Ivanov I.I.	1955-02-19	[email protected]	2	1	2015-04-08
1001	Petrov P.P.	1983-12-03	[email protected]	3	3	2015-04-08
1002	Sidorov S.S.	1976-06-07	[email protected]	1	2	2015-04-08

Înainte de aceasta, când indexul grupat era indexul PK_Employees, înregistrările erau sortate implicit după câmpul ID.

Dar în acest caz, acesta este doar un exemplu care arată esența indexului grupat, deoarece. cel mai probabil, interogările vor fi făcute către tabelul Angajați prin câmpul ID și, în unele cazuri, acesta poate acționa ca referință.

Pentru directoare, este de obicei recomandabil ca indexul grupat să fie construit pe cheia primară, deoarece în cereri, ne referim adesea la identificatorul directorului pentru a obține, de exemplu, numele (Posiție, Departament). Aici ne amintim despre ce am scris mai sus, că indexul grupat are acces direct la rândurile tabelului și de aici rezultă că putem obține valoarea oricărei coloane fără suprasarcină suplimentară.

Indexul grupat este benefic pentru a fi aplicat câmpurilor care sunt selectate cel mai des.

Uneori, tabelele creează o cheie printr-un câmp surogat, caz în care este util să păstrați opțiunea index CLUSTERED pentru un index mai adecvat și să specificați opțiunea NONCLUSTERED atunci când creați o cheie primară surogat.

Să rezumam

În această etapă, ne-am familiarizat cu toate tipurile de restricții, în forma lor cea mai simplă, care sunt create printr-o comandă precum „ALTER TABLE table_name ADD CONSTRAINT constraint_name ...”:

• CHEIA PRINCIPALA- cheia principala;
• CHEIE EXTERNĂ- stabilirea legaturilor si monitorizarea integritatii referentiale a datelor;
• UNIC- vă permite să creați unicitate;
• VERIFICA- vă permite să efectuați corectitudinea datelor introduse;
• MOD IMPLICIT– vă permite să setați valoarea implicită;
• De asemenea, este de remarcat faptul că toate restricțiile pot fi eliminate folosind comanda " ALTER TABLE table_name CONSTRINGERE DE CĂDERARE nume_constrângere”.

De asemenea, am atins parțial subiectul indicilor și am analizat conceptul de cluster ( CLUSTRATE) și non-cluster ( NEGRUPAT) index.

Crearea de indici autonomi

Autosuficiența se referă aici la indecșii care nu sunt creați pentru o constrângere PRIMARY KEY sau UNIQUE.

Indecșii unui câmp sau câmpuri pot fi creați cu următoarea comandă:

CREATE INDEX IDX_Employees_Name ON Angajati(Nume)
De asemenea, puteți specifica aici opțiunile CLUSTERED, NONCLUSTERED, UNIQUE și, de asemenea, puteți specifica direcția de sortare pentru fiecare câmp individual ASC (implicit) sau DESC:

CREAȚI INDEX UNIC NECLUSTERED UQ_Employees_EmailDesc ON Angajații (E-mail DESC)
La crearea unui index non-clustered, opțiunea NONCLUSTERED poate fi omisă, așa cum este implicit implicit, este afișat aici pur și simplu pentru a indica poziția opțiunii CLUSTERED sau NONCLUSTERED în comandă.

Puteți elimina indexul cu următoarea comandă:

DROP INDEX IDX_Employees_Name ON Angajații
Indecșii simpli, la fel ca și constrângerile, pot fi creați în contextul comenzii CREATE TABLE.

De exemplu, să ștergem din nou tabelul:

DROP TABLE Angajații
Și recreați-l cu toate constrângerile și indecșii creați cu o singură comandă CREATE TABLE:

CREATE TABLE Angajații(ID int NOT NULL, Nume nvarchar(30), Data zilei de naștere, Email nvarchar(30), PositionID int, DepartmentID int, HireDate data NOT NULL CONSTRAINT DF_Employees_HireDate DEFAULT SYSDATETIME(), ManagerID int, CONSTRAINT PK_Employees PRIMARY (PRIMARY) ), CONSTRAINT FK_Employees_DepartmentID FOREIGN KEY(DepartmentID) REFERINȚE Departamente(ID), CONSTRAINT FK_Employees_PositionID FOREIGN KEY(PositionID) REFERINȚE Poziții(ID), CONSTRAINT FK_Employees_ManagerID FOREIGN KEY(ID) CONSTRAINTEmployees_ManagerID CHEIE STRĂINĂ(Employees_ConsEmail0, CONSTRAINT) 1999), INDEX IDX_Employees_Name(Nume))
În cele din urmă, introduceți în tabelul angajaților noștri:

INSERT ANgajați (ID, Nume, Zi de naștere, E-mail, ID poziția, ID departament, ID manager) VALORI (1000,N"Ivanov II","19550219"," [email protected]",2,1,NULL), (1001,N"Petrov P.P.","19831203"," [email protected]",3,3,1003), (1002,N"Sidorov S.S.","19760607"," [email protected]",1,2,1000), (1003,N"Andreev A.A.","19820417"," [email protected]",4,3,1000)
În plus, este de remarcat faptul că valorile pot fi incluse într-un index non-cluster, specificându-le în INCLUDE. Acestea. în acest caz, indexul INCLUDE va ​​semăna oarecum cu un index grupat, doar că acum indicele nu este atașat tabelului, dar valorile necesare sunt atașate indexului. În consecință, astfel de indecși pot îmbunătăți considerabil performanța interogărilor selectate (SELECT), dacă toate câmpurile enumerate sunt în index, atunci este posibil să nu fie deloc nevoie să accesați tabelul. Dar acest lucru crește în mod natural dimensiunea indicelui, deoarece valorile câmpurilor enumerate sunt duplicate în index.

Decuparea din MSDN. Sintaxă generală de comandă pentru crearea indexurilor

CREATE [UNIQUE] [CLUSTER | NONCLUSTERED ] INDEX nume_index ACTIVAT