Efectuarea unei excursii Access prin SQL Server

Generarea continuității activității

Se recomandă să mențineți soluția Access actualizată și funcțională cu întreruperi minime, dar opțiunile dvs. cu bază de date back-end Access sunt limitate. Efectuarea unui backup pentru baza dvs. de date Access cu scopul de a proteja datele este esențială, dar presupune ca utilizatorii să fie offline. Apoi, există perioade neplanificate de întreruperi cauzate de upgrade-uri de întreținere hardware/software, întreruperi de rețea sau de curent, erori de hardware, încălcări ale securității sau chiar atacuri cibernetice. Pentru a reduce la minimum timpul de funcționare și impactul asupra firmei dvs., puteți face backup unei baze de date SQL Server în timp ce este utilizată. În plus, SQL Server oferă și strategii de disponibilitate ridicată (HA) și de recuperare în caz de dezastru (DR). Aceste două tehnologii combinate sunt numite HADR. Pentru mai multe informații, consultați Continuitatea activității și recuperarea bazei de date și Generarea continuității activității cu SQL Server (carte în format electronic).

Backup în timpul utilizării

SQL Server utilizează un proces de backup online care se poate realiza în timp ce baza de date rulează. Puteți face backup complet, backup parțial sau backup pentru fișier. Un backup presupune copierea datelor și jurnalelor de tranzacții pentru a asigura o operațiune de restaurare completă. Mai cu seamă în cazul unei soluții locale, trebuie să recunoașteți diferențele dintre opțiunile de recuperare simplă și de recuperare completă, precum și modul în care acestea afectează creșterea jurnalului de tranzacții. Pentru mai multe informații, consultați Modele de recuperare.

Majoritatea operațiunilor de backup au loc imediat, cu excepția operațiunilor de gestionare a fișierelor și de reducere a bazei de date. Însă, dacă încercați să creați sau să ștergeți un fișier bază de date în timp ce o operațiune de backup este în curs de desfășurare, operațiunea nu va reuși. Pentru mai multe informații, consultați Prezentare generală backup.

HADR

Două dintre cele mai uzuale tehnici pentru a obține o disponibilitate ridicate și o continuitate a activității sunt reproducerea în oglindă și gruparea în cluster. SQL Server integrează tehnologia de reproducere în oglindă și de grupare în cluster cu „Instanțe cluster de reluare în caz de nereușită Always on” și „Grupuri de disponibilitate Always on”.

Reproducerea în oglindă este o soluție de continuitate la nivel de bază de date care acceptă reluarea în caz de nereușită aproape instant, menținând o bază de date standby, o copiere sau o reproducere în oglindă completă a bazei de date active pe hardware separat. Poate funcționa în mod sincron (de înaltă siguranță), unde o tranzacție de intrare este comisă pentru toate serverele simultan sau într-un mod asincron (de înaltă performanță), unde o tranzacție de intrare este comisă la baza de date activă, apoi la un anumit punct predefinit reprodus în oglindă. Reproducerea în oglindă este o soluție la nivel de bază de date și funcționează doar cu baze de date care utilizează modelul de recuperare completă.

Gruparea în cluster este o soluție la nivel de server care combină serverele într-un singur spațiu de stocare a datelor, care îi apare utilizatorului ca o singură instanță. Utilizatorii se conectează la instanță și nu trebuie să știe niciodată ce server din instanță este activ în mod curent. Dacă un server eșuează sau trebuie să fie offline pentru întreținere, experiența de utilizator nu se modifică. Fiecare server din cluster este monitorizat de managerul de clustere prin intermediul unui mesaj repetat, astfel încât detectează când serverul activ din cluster trece offline și încearcă să comute cu ușurință la serverul următor din cluster, deși există un timp variabil de întârziere pentru comutare.

Pentru mai multe informații, consultați Instanțe cluster de reluare în caz de nereușită Always on și Grupuri de disponibilitate Always on: o soluție de disponibilitate ridicată și de recuperare în caz de dezastru.

Începutul paginii

SQL Server Security

Deși vă puteți proteja baza de date Access utilizând Centrul de autorizare și criptând baza de date, SQL Server are caracteristici de securitate mai complexe. Să examinăm trei capacități care ies în evidență pentru utilizatorul Access. Pentru mai multe informații, consultați Securizarea SQL Server.

Autentificarea bazei de date

Există patru metode de autentificare a bazei de date în SQL Server, iar pe fiecare o puteți specifica într-un șir de conexiune ODBC. Pentru mai multe informații, consultați Legarea sau importul datelor de la o bază de date Azure SQL Server. Fiecare metodă are propriile avantaje.

Autentificare Windows integrată    Utilizați acreditările Windows pentru validarea utilizatorilor, rolurile de securitate și limitarea utilizatorilor la caracteristici și date. Puteți să utilizați acreditările de domeniu și să gestionați cu ușurință drepturile de utilizator în aplicația dvs. Opțional, introduceți Nume principale de serviciu (SPN). Pentru mai multe informații, consultați Alegerea unui mod de autentificare.

Autentificarea SQL Server    Utilizatorii trebuie să se conecteze cu acreditările care au fost configurate în baza de date, introducând ID-ul de conectare și parola prima dată când accesează baza de date într-o sesiune. Pentru mai multe informații, consultați Alegerea unui mod de autentificare.

Autentificare Azure Active Directory integrată    Conectați-vă la baza de date Azure SQL Server utilizând Azure Active Directory. După ce ați configurat autentificarea Azure Active Directory, nu sunt necesare date suplimentare de conectare și parola. Pentru mai multe informații, consultați Conectarea la baza de date SQL utilizând autentificarea Azure Active Directory.

Autentificare cu parolă Active Directory    Conectați-vă cu acreditările care au fost configurate în Azure Active Directory, introducând numele de conectare și parola. Pentru mai multe informații, consultați Conectarea la baza de date SQL utilizând autentificarea Azure Active Directory.

Sfat    Utilizați Detectarea amenințărilor pentru a primi avertizări despre o activitate anormală a bazei de date care prezintă amenințări de securitate potențiale la adresa unei baze de date Azure SQL Server. Pentru mai multe informații, consultați Detectarea amenințărilor la baza de date SQL.

Securitatea aplicațiilor

SQL Server are două caracteristici de securitate la nivel de aplicație de care puteți beneficia cu Access.

Mascarea datelor dinamice    Ascundeți informațiile confidențiale mascându-le de utilizatorii care nu sunt privilegiați. De exemplu, puteți să mascați un cod numeric personal parțial sau în întregime.

O mască de date parțială

O mască de date completă

Există mai multe moduri prin care puteți să definiți o mască de date și le puteți aplica la tipuri de date diferite. Mascarea datelor este guvernată de politici la nivel de tabel și de coloană pentru un set definit de utilizatori și se aplică în timp real la interogare. Pentru mai multe informații, consultați Mascarea datelor dinamice.

Securitate la nivel de rând    Puteți controla accesul la anumite rânduri ale bazei de date cu informații confidențiale, pe baza caracteristicilor utilizatorului, utilizând securitatea la nivel de rând. Sistemul bazei de date aplică aceste restricții de acces, ceea ce face ca sistemul de securitate să fie mai fiabil și mai robust.

Există două tipuri de predicate de securitate:

• Un predicat de filtrare filtrează rândurile dintr-o interogare. Filtrul este transparent, iar utilizatorul final nu remarcă nicio filtrare.

• Un predicat de blocare împiedică orice acțiune neautorizată și generează o excepție în cazul în care acțiunea nu poate fi efectuată.

Pentru mai multe informații, consultați Securitate la nivel de rând.

Protejarea datelor cu criptare

Protejați datele inactive, care sunt în tranzit, precum și în timp ce le utilizați fără să afectați performanța bazei de date. Pentru mai multe informații, consultați Criptarea SQL Server.

Criptarea datelor inactive    Pentru a securiza datele cu caracter personal împotriva atacurilor din partea unor suporturi offline la stratul de stocare fizic, utilizați criptarea-datelor-inactive, numită și Criptarea transparentă a datelor (TDE). Acest lucru înseamnă că datele dvs. sunt protejate chiar dacă suportul fizic este furat sau eliminat în mod nepotrivit. TDE efectuează criptarea și decriptarea în timp real a bazelor de date, a backupurilor și a jurnalelor de tranzacții fără a necesita nicio modificare a aplicațiilor dvs.

Criptarea în tranzit    Pentru a vă proteja împotriva intruziunilor și „atacurilor de tip interpunere”, puteți cripta datele transmise în rețea. SQL Server acceptă Transport Layer Security (TLS) 1.2 pentru comunicații foarte sigure. Protocolul Fluxul de date tabelare (TDS) este utilizat, de asemenea, pentru a proteja comunicațiile în rețelele care nu sunt de încredere.

Criptarea utilizată pentru client    Pentru a proteja datele cu caracter personal în timpul utilizării, se recomandă folosirea caracteristicii „Always Encrypted”. Datele cu caracter personal sunt criptate și decriptate de un driver de pe computerul client fără a afișa chei de criptare în motorul de baze de date. Prin urmare, datele criptate sunt vizibile doar pentru persoanele responsabile cu gestionarea respectivelor date, nu pentru alți utilizatori foarte privilegiați, care nu ar trebui să aibă acces. În funcție de tipul de criptare selectat, Always Encrypted poate limita anumite funcționalități ale bazei de date, cum ar fi căutarea, gruparea și indexarea coloanelor criptate.

Începutul paginii

Gestionarea problemelor de confidențialitate

Problemele de confidențialitate sunt atât de răspândite, încât Uniunea Europeană a definit cerințele legale prin intermediul Regulamentului general privind protecția datelor (GDPR). Din fericire, un back-end SQL Server este potrivit pentru a îndeplini aceste cerințe. Gândiți-vă la implementarea GDPR într-un cadru în trei pași.

Pasul 1: Evaluarea și gestionarea riscului de conformitate

GDPR vă solicită să identificați și să inventariați informațiile personale pe care le aveți în tabele și fișiere. Aceste informații pot îmbrăca orice formă, de la un nume, o fotografie, o adresă de e-mail, detalii bancare, postări pe rețele web sociale, informații medicale sau chiar o adresă IP.

Un nou instrument, Descoperirea și clasificarea datelor SQL, construit în SQL Server Management Studio vă ajută să descoperiți, să clasificați, să etichetați și să raportați despre date cu caracter personal, aplicând două atribute metadate pentru coloane:

• Etichete    Pentru a defini confidențialitatea datelor.

• Tipuri de informații    Pentru a furniza o granularitate suplimentară privind tipurile de date stocate într-o coloană.

Un alt mecanism de descoperire pe care îl puteți utiliza este căutarea în text complet, care include utilizarea predicatelor CONTAINS și FREETEXT și a funcțiilor cu valoare de set de rând, cum ar fi CONTAINSTABLE și FREETEXTTABLE, pentru utilizare cu instrucțiunea SELECT. Utilizând căutarea în text complet, puteți căuta în tabele pentru a descoperi cuvinte, combinații de cuvinte sau variante ale un cuvânt, cum ar fi sinonime sau forme flexionare. Pentru mai multe informații, consultați Căutare în text complet.

Pasul 2: Protejarea informațiilor personale

GDPR vă solicită să securizați informațiile personale și să limitați accesul la acestea. În plus față de pașii standard pe care îi efectuați pentru a gestiona accesul la rețea și resurse, cum ar fi setările firewallului, puteți utiliza caracteristici de securitate SQL Server care vă ajută să controlați accesul la date:

• Autentificarea SQL Server pentru a gestiona identitatea utilizatorului și a împiedica accesul neautorizat.

• Securitatea la nivel de rând pentru a limita accesul la rândurile dintr-un tabel, în funcție de relația dintre utilizator și datele respective.

• Mascarea datelor dinamice pentru a limita expunerea la date cu caracter personal, mascându-le de utilizatorii care nu sunt privilegiați.

• Criptarea pentru a vă asigura că datele cu caracter personal sunt protejate în timpul transmiterii și stocării și sunt protejate împotriva compromiterii, inclusiv pe partea de server.

Pentru mai multe informații, consultați Criptarea SQL Server.

Pasul 3: Răspuns eficient la solicitări

GDPR vă solicită să păstrați înregistrări ale procesării datelor cu caracter personal și să le puneți la dispoziția autorităților de supraveghere, la cerere. Dacă apar probleme, inclusiv lansări accidentale de date, controalele de protecție vă permit să reacționați rapid. Datele trebuie să fie disponibile rapid atunci când este necesară raportare. De exemplu, potrivit GDPR, încălcarea datelor cu caracter personal trebuie să fie raportată autorității de supraveghere „în termen de cel mult 72 de ore de la data la care a luat cunoștință de aceasta”.

SQL Server 2017 vă ajută să raportați activități în mai multe moduri:

• Auditarea SQL Server vă ajută să vă asigurați că există înregistrări persistente ale activităților de accesare și de procesare a bazelor de date. Aceasta efectuează un audit de finețe, care urmărește activitățile bazei de date pentru a vă ajuta să înțelegeți și să identificați amenințări potențiale, situații potențiale de abuz sau încălcări de securitate. Puteți efectua cu ușurință analize de date.

• Tabelele temporale SQL Server sunt tabele de utilizator cu versiune de sistem proiectate pentru a păstra un istoric complet al modificărilor de date. Le puteți utiliza pentru raportare simplă și analiză punctuală.

• Evaluarea vulnerabilității SQL vă ajută să detectați problemele de securitate și de permisiuni. Atunci când este detectată o problemă, puteți, de asemenea, să detaliați rapoartele de scanare a bazei de date pentru a găsi acțiuni pentru rezoluție.

Pentru mai multe informații, consultați Crearea unei platforme de încredere (carte în format electronic) și Călătoria spre asigurarea conformității cu GDPR.

Începutul paginii

Crearea unui instantaneu al bazei de date

Un instantaneu al unei baze de date este o vizualizare statică, doar în citire, a unei baze de date SQL Server la un moment dat. Deși puteți să copiați un fișier bază de date Access pentru a crea în mod eficient un instantaneu al unei baze de date, Access nu are o metodologie predefinită ca SQL Server. Puteți utiliza un instantaneu al bazei de date pentru scrierea de rapoarte pa baza datelor în momentul creării unui instantaneu al bazei de date. De asemenea, puteți utiliza un instantaneu al bazei de date pentru a menține date istorice, cum ar fi câte unul pentru fiecare trimestru fiscal pe care-l utilizați pentru a înregistra rapoartele de sfârșit de perioadă. Vă recomandăm următoarele cele mai bune practici:

• Denumiți instantaneul    Fiecare instantaneu al bazei de date necesită un nume unic al bazei de date. Adăugați scopul și intervalul de timp la nume, pentru facilitarea identificării. De exemplu, pentru a face un instantaneu al unei baze de date AdventureWorks de trei ori pe zi, la intervale de 6 ore, între 6 dimineața și 6 seara, pe baza unui interval orar de 24 de ore, denumiți-le AdventureWorks_snapshot_0600, AdventureWorks_snapshot_1200 și AdventureWorks_snapshot_1800.

• Limitați numărul de instantanee    Fiecare instantaneu al bazei de date persistă până când este retras în mod explicit. Întrucât fiecare instantaneu va continua să crească, se recomandă să economisiți spațiu pe disc ștergând un instantaneu mai vechi după ce creați un instantaneu nou. De exemplu, dacă faceți rapoarte zilnice, păstrați instantaneul bazei de date timp de 24 de ore, apoi eliminați-o și înlocuiți-o cu una nouă.

• Conectarea la instantaneul corect    Pentru a utiliza un instantaneu al unei baze de date, baza de date front-end Access trebuie să știe locația corectă. Atunci când înlocuiți un instantaneu existent cu unul nou, trebuie să redirecționați Access la noul instantaneu. Adăugați logică la front-end Access pentru a vă asigura că vă conectați la instantaneul bazei de date corecte.

Iată cum să creați un instantaneu al unei baze de date:

CREATE DATABASE AdventureWorks_dbss1800 ON  
( NAME = AdventureWorks_Data, FILENAME =   
'C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Data\AdventureWorks_snapshot_0600' )  
AS SNAPSHOT OF AdventureWorks;  

Pentru mai multe informații, consultați Instantaneu al bazei de date (SQL Server).

Începutul paginii

Controlul concurenței

Atunci când mai multe persoane încearcă să modifice datele dintr-o bază de date în același timp, este necesar un sistem de controale pentru ca modificările efectuate de o singură persoană să nu le afecteze în mod negativ pe cele ale altei persoane. Acest lucru se numește controlul concurenței și există două strategii de blocare de bază, pesimistă și optimistă. Blocarea poate împiedica utilizatorii să modifice date într-un mod care să îi afecteze pe alți utilizatori. De asemenea, blocarea vă ajută să asigurați integritatea bazei de date, mai ales cu interogări care, în caz contrar, ar putea produce rezultate neașteptate. Există diferențe importante între modul în care Access și SQL Server implementează aceste strategii de control al concurenței.

În Access, strategia de blocare implicită este optimistă și acordă calitatea de proprietar asupra blocării primei persoane care încearcă să scrie într-o înregistrare. Access afișează caseta de dialog Conflict la scriere pentru altă persoană care încearcă să scrie aceeași înregistrare în același timp. Pentru a rezolva conflictul, cealaltă persoană poate salva înregistrarea, o poate copia în clipboard sau poate elimina modificările.

De asemenea, puteți utiliza proprietatea RecordLocks pentru a modifica strategia de control al concurenței. Această proprietate afectează formularele, rapoartele și interogările și are trei setări:

• Fără blocare    Într-un formular, utilizatorii pot încerca să editeze aceeași înregistrare simultan, dar este posibil să se afișeze caseta de dialog Conflict la scriere. În unele rapoarte, înregistrările nu sunt blocate când raportul este previzualizat sau imprimat. Într-o interogare, înregistrările nu sunt blocate în timp ce rulează interogarea. Aceasta este modalitatea Access de a implementa blocarea optimistă.

• Toate înregistrările    Toate înregistrările din tabelul sau interogarea subiacentă sunt blocate în timp ce formularul este deschis în vizualizarea Formular sau vizualizarea Foaie de date în timp ce raportul este previzualizat sau imprimat sau în timp ce rulează interogarea. Utilizatorii pot citi înregistrările în timpul blocării.

• Înregistrare editată    Pentru formulare și interogări, o pagină de înregistrări este blocată imediat ce un utilizator începe editarea oricărui câmp din înregistrare și rămâne blocată până când utilizatorul trece la o altă înregistrare. Prin urmare, o înregistrare poate fi editată de un singur utilizator o dată. Aceasta este modalitatea Access de a implementa blocarea pesimistă.

Pentru mai multe informații, consultați Caseta de dialog Conflict la scriere și Proprietatea RecordLocks.

În SQL Server, controlul concurenței funcționează astfel:

• Pesimist    După ce un utilizator efectuează o acțiune care determină aplicarea unei blocări, ceilalți utilizatori nu pot efectua acțiuni care să contravină blocării până când proprietarul o eliberează. Acest control al concurenței este utilizat în principal în mediile în care există o ocupare mare în ceea ce privește datele.

• Optimist    În cazul unui control optimist al concurenței, utilizatorii nu blochează date atunci când îl citesc. Atunci când un utilizator actualizează date, sistemul verifică dacă un alt utilizator a schimbat datele după ce a fost citit. Dacă un alt utilizator a actualizat datele, apare o eroare. De obicei, utilizatorul care primește eroarea anulează tranzacția și începe din nou. Acest control al concurenței este utilizat în principal în mediile în care există o ocupare mică în ceea ce privește datele.

Aveți posibilitatea să specificați tipul control al concurenței, selectând mai multe niveluri de izolare a tranzacțiilor, care definesc nivelul de protecție pentru tranzacție din modificările efectuate de alte tranzacții, utilizând instrucțiunea SET TRANSACTION:

 SET TRANSACTION ISOLATION LEVEL
 { READ UNCOMMITTED
    | READ COMMITTED
    | REPEATABLE READ  
    | SNAPSHOT
    | SERIALIZABLE
 }

Pentru mai multe informații, consultați Ghidul de blocare a tranzacției și de gestionare a versiunilor pentru rânduri.

Începutul paginii

Îmbunătățirea performanței interogărilor

După lucrul cu o interogare directă Access, profitați de modurile sofisticate în care SQL Server o poate face să funcționeze mai eficient.

Spre deosebire de o bază de date Access, SQL Server furnizează interogări paralele pentru optimizarea executării interogărilor și a operațiunilor de indexare pentru computere care au mai multe microprocesoare (CPU). Întrucât SQL Server poate efectua o interogare sau o operațiune de indexare în paralel utilizând mai multe fire de lucru ale sistemului, operațiunea poate fi finalizată rapid și eficient.

Interogările reprezintă o componentă critică în ceea ce privește îmbunătățirea performanței generale a soluției de baze de date. Interogările eronate rulează pe termen nedefinit, până la expirare și utilizează resurse precum CPU, memoria și bandit de rețea. Acest lucru împiedică disponibilitatea informațiilor critice de afaceri. Chiar și o singură interogare incorectă poate cauza probleme serioase de performanță pentru baza dvs. de date.

Pentru mai multe informații, consultați Interogarea mai rapidă cu SQL Server (carte în format electronic).

Optimizare interogare

Mai multe instrumente conlucrează pentru a vă ajuta să analizați performanța unei interogări și să o îmbunătățiți: Utilitarul de optimizare a interogărilor, planurile de executare și depozitul de interogări.

Utilitarul de optimizare a interogărilor

Utilitarul de optimizare a interogărilor este una dintre componentele cele mai importante ale SQL Server. Folosiți Utilitarul de optimizare a interogărilor pentru a analiza o interogare și a determina modul cel mai eficient de accesare a datelor obligatorii. Intrările în Utilitarul de optimizare a interogărilor constau în interogare, schema bazei de date (definițiile de tabel și index) și statisticile bazei de date. Ieșirile din Utilitarul de optimizare a interogărilor constau într-un plan de executare.

Pentru mai multe informații, consultați Utilitarul de optimizare a interogărilor SQL Server.

Plan de executare

Un plan de executare este o definiție care secvențiază tabelele sursă de accesat și metodele utilizate pentru a extrage date din fiecare tabel. Optimizarea este procesul de selectare a unui plan de executare din mai multe planuri posibile. Fiecare plan de executare posibil are un cost asociat în volumul de resurse de calcul utilizate, iar Utilitarul de optimizare a interogărilor o alege pe cea cu cel mai mic cost estimat.

De asemenea, SQL Server trebuie să se adapteze dinamic la condițiile mereu în schimbare din baza de date. Regresia în cadrul planurilor de executare a interogării poate avea un impact profund negativ asupra performanței. Din cauza unor modificări operate într-o bază de date, un plan de executare poate să fie ori ineficient, ori nevalid în funcție de starea nouă a bazei de date. SQL Server detectează modificările care anulează un plan de executare și marchează planul ca nevalid.

Un plan nou trebuie apoi recompilat pentru următoarea conexiune care execută interogarea. Între condițiile care anulează un plan se numără:

• Modificările efectuate într-un tabel sau într-o vizualizare la care face referire interogarea (ALTER TABLE și ALTER VIEW).

• Modificări ale indexurilor utilizate de planul de executare.

• Actualizări ale statisticilor utilizate de planul de executare, generate explicit dintr-o instrucțiune, cum ar fi UPDATE STATISTICS sau automat.

Pentru mai multe informații, consultați Planuri de executare.

Depozit de interogare

Depozitul de interogare furnizează detalii despre alegerea și performanța planului de executare. Simplifică depanarea performanței, ajutându-vă să găsiți rapid diferențele de performanță determinate de modificările planului de executare. Depozitul de interogări colectează date de telemetrie, cum ar fi un istoric de interogări, planuri, statistici de execuție și statistici de așteptare. Utilizați instrucțiunea ALTER DATABASE pentru a implementa Depozitul de interogări:

ALTER DATABASE AdventureWorks2012 SET QUERY_STORE = ON;

Pentru mai multe informații, consultați Monitorizarea performanței utilizând Depozitul de interogări.

ALTER DATABASE [YourDatabaseName] SET COMPATIBILITY_LEVEL = 140;

Modalități de interogare

În SQL Server, există mai multe modalități de a interoga, fiecare având propriile avantaje. Se recomandă să le cunoașteți pe toate pentru a putea face alegerea corectă în cazul soluției dvs. Access. Cea mai bună metodă de a crea interogări TSQL este să le editați și să le testați în mod interactiv, utilizând editorul Transact-SQL SQL Server Management Studio (SSMS), care are IntelliSense pentru a vă ajuta să alegeți cuvintele cheie potrivite și să verificați erorile de sintaxă.

Vizualizări

În SQL Server, o vizualizare este ca un tabel virtual în care datele vizualizării provin dintr-unul sau mai multe tabele sau din alte vizualizări. Cu toate acestea, vizualizările sunt menționate la fel ca tabelele din interogări. Vizualizările pot ascunde complexitatea interogărilor și ajută la protejarea datelor, limitând setul de rânduri și coloane. Iată un exemplu de vizualizare simplă:

CREATE VIEW HumanResources.EmployeeHireDate AS  
SELECT p.FirstName, p.LastName, e.HireDate  
FROM HumanResources.Employee AS e JOIN Person.Person AS p  
ON e.BusinessEntityID = p.BusinessEntityID;

Pentru performanțe optime și pentru a edita rezultatele vizualizării, creați o vizualizare indexată, care persistă în baza de date, cum ar fi un tabel, care are spațiu de stocare alocat special și care poate fi interogată ca orice tabel. Pentru a-l utiliza în Access, conectați-l la vizualizare în același fel în care creați un link la un tabel. Iată un exemplu de vizualizare indexată:

CREATE VIEW Sales.vOrders  
WITH SCHEMABINDING  
AS  
    SELECT SUM(UnitPrice*OrderQty*(1.00-UnitPriceDiscount)) AS Revenue,  
        OrderDate, ProductID, COUNT_BIG(*) AS COUNT  
    FROM Sales.SalesOrderDetail AS od, Sales.SalesOrderHeader AS o  
    WHERE od.SalesOrderID = o.SalesOrderID  
    GROUP BY OrderDate, ProductID;  

CREATE UNIQUE CLUSTERED INDEX IDX_V1   
    ON Sales.vOrders (OrderDate, ProductID);  

Există totuși restricții. Nu puteți actualiza datele dacă sunt afectate mai multe tabele de bază sau dacă vizualizarea conține funcții agregate sau o clauză DISTINCT. Dacă SQL Server returnează un mesaj de eroare care spune că nu știe ce înregistrare să șteargă, se recomandă să adăugați un trigger de ștergere în vizualizare. În cele din urmă, nu puteți utiliza clauza ORDER BY, așa cum o faceți cu o interogare Access.

Pentru mai multe informații, consultați Vizualizări și Crearea de vizualizări indexate.

Proceduri stocate

O procedură stocată este un grup de una sau mai multe instrucțiuni TSQL care include parametri de intrare, returnează parametri de ieșire și indică succesul sau eșecul cu o valoare de stare. Ele acționează ca nivel intermediar între front-end Access și back-end SQL Server. Procedurile stocate pot fi la fel de simple precum o instrucțiune SELECT sau la fel de complexe precum orice program. Iată un exemplu:

CREATE PROCEDURE HumanResources.uspGetEmployees   
    @LastName nvarchar(50),   
    @FirstName nvarchar(50)   
AS   
    SET NOCOUNT ON;  
    SELECT FirstName, LastName, Department  
    FROM HumanResources.vEmployeeDepartmentHistory  
    WHERE FirstName = @FirstName AND LastName = @LastName  
    AND EndDate IS NULL;  

Atunci când utilizați o procedură stocată în Access, aceasta returnează, de obicei, un set de rezultate înapoi la un formular sau un raport. Cu toate acestea, poate efectua și alte acțiuni care nu returnează rezultate, cum ar fi instrucțiunile DDL sau DML. Atunci când utilizați o interogare directă, asigurați-vă că setați proprietatea Returnează înregistrările în mod corespunzător.

Pentru mai multe informații, consultați Proceduri stocate.

Expresii de tabel comune

Expresiile de tabel comune(CTE) se aseamănă cu un tabel temporar care generează un set de rezultate denumit. Acesta există doar pentru executarea unei singure interogări sau a unei instrucțiuni DML. Un CTE este construit în același prefix ca instrucțiunea SELECT sau instrucțiunea DML care îl utilizează, în timp ce crearea și utilizarea unui tabel sau a unei vizualizări temporare este, de obicei, un proces în doi pași. Iată un exemplu:

-- Define the CTE expression name and column list.  
WITH Sales_CTE (SalesPersonID, SalesOrderID, SalesYear)  
AS  
-- Define the CTE query.  
(  
    SELECT SalesPersonID, SalesOrderID, YEAR(OrderDate) AS SalesYear  
    FROM Sales.SalesOrderHeader  
    WHERE SalesPersonID IS NOT NULL  
)  
-- Define the outer query referencing the CTE name.  
SELECT SalesPersonID, COUNT(SalesOrderID) AS TotalSales, SalesYear  
FROM Sales_CTE  
GROUP BY SalesYear, SalesPersonID  
ORDER BY SalesPersonID, SalesYear;

Un CTE are mai multe beneficii, inclusiv următoarele:

• Întrucât CTE sunt tranzitorii, nu trebuie să le creați ca obiecte de bază de date permanente, cum ar fi vizualizările.

• Puteți face referire la același CTE de mai multe ori într-o interogare sau instrucțiune DML, făcând codul mai ușor de gestionat.

• Puteți utiliza interogările care fac referire la un CTE pentru a defini un cursor.

Pentru mai multe informații, consultați WITH common_table_expression

Funcții definite de utilizator

O funcție definită de utilizator (UDF) poate efectua interogări și calcule și poate returna valori scalare sau seturi de rezultate de date. Ele seamănă cu funcțiile din limbajele de programare care acceptă parametri, efectuează o acțiune, cum ar fi un calcul complex, și returnează rezultatul acțiunii respective ca valoare. Iată un exemplu:

CREATE FUNCTION dbo.ISOweek (@DATE datetime)  
RETURNS int WITH SCHEMABINDING -- Helps improve performance
WITH EXECUTE AS CALLER  
AS  
BEGIN  
     DECLARE @ISOweek int;  
     SET @ISOweek= DATEPART(wk,@DATE)+1  
          -DATEPART(wk,CAST(DATEPART(yy,@DATE) as CHAR(4))+'0104');  
-- Special cases: Jan 1-3 may belong to the previous year  
     IF (@ISOweek=0)   
          SET @ISOweek=dbo.ISOweek(CAST(DATEPART(yy,@DATE)-1   
               AS CHAR(4))+'12'+ CAST(24+DATEPART(DAY,@DATE) AS CHAR(2)))+1;  
-- Special case: Dec 29-31 may belong to the next year  
     IF ((DATEPART(mm,@DATE)=12) AND   
          ((DATEPART(dd,@DATE)-DATEPART(dw,@DATE))>= 28))  
          SET @ISOweek=1;  
     RETURN(@ISOweek);  
END;  
GO  
SET DATEFIRST 1;  
SELECT dbo.ISOweek(CONVERT(DATETIME,'12/26/2004',101)) AS 'ISO Week';  

Un UDF are anumite limitări. De exemplu, nu pot utiliza anumite funcții de sistem nedeterministe, nu pot efectua instrucțiuni DML sau DDL sau interogări SQL dinamice.

Pentru mai multe informații, consultați Funcții definite de utilizator.

Începutul paginii

Adăugarea cheilor și a indexurilor

Indiferent de sistemul de bază de date pe care îl utilizați, tastele și indexurile sunt utilizate împreună.

Chei

În SQL Server, asigurați-vă că creați chei primare pentru fiecare tabel și chei străine pentru fiecare tabel asociat. Caracteristica echivalentă din SQL Server pentru tipul de date Numerotare automată Access este proprietatea IDENTITY, care poate fi utilizată pentru a crea valorile cheii. După aplicarea acestei proprietăți la o coloană numerică oarecare, aceasta devine doar în citire și este menținută de sistemul de baze de date. Atunci când inserați o înregistrare într-un tabel care conține o coloană IDENTITY, sistemul incrementează automat valoarea pentru coloana de IDENTITY cu 1 și începe de la 1, dar puteți să controlați aceste valori cu argumente.

Pentru mai multe informații, consultați CREATE TABLE, IDENTITY (proprietate).

Indexuri

Ca întotdeauna, selectarea indexurilor este un act de echilibrare între viteza de interogare și costul actualizării. În Access, aveți un tip de index, dar în SQL Server aveți douăsprezece. Din fericire, puteți utiliza Utilitarul de optimizare a interogărilor pentru a vă ajuta să alegeți în mod fiabil cel mai eficient index. Iar în Azure SQL, puteți utiliza gestionarea automată a indexurilor, o caracteristică de reglare automată, care recomandă adăugarea sau eliminarea indexurilor pentru dvs. Spre deosebire de Access, trebuie să vă creați propriile indexuri pentru cheile străine în SQL Server. De asemenea, puteți crea indexuri într-o vizualizare indexată pentru a îmbunătăți performanța interogărilor. Dezavantajul unei vizualizări indexate este supraîncărcarea ridicată atunci când modificați datele în tabelele de bază ale vizualizării, deoarece vizualizarea trebuie să fie și ea actualizată. Pentru mai multe informații, consultați Ghidul pentru arhitectura și designul indexului SQL Server și Indexuri.

Începutul paginii

Efectuarea tranzacțiilor

Efectuarea unui proces de tranzacție online (OLTP) este dificilă atunci când utilizați Access, dar relativ ușoară cu SQL Server. O tranzacție este o singură unitate de lucru care comite toate modificările de date atunci când procesul reușește, dar anulează modificările atunci când eșuează. O tranzacție trebuie să aibă patru proprietăți, numite adesea ACID:

• Atomicitatea    O tranzacție trebuie să fie o unitate de lucru atomică; fie sunt efectuate toate modificările de date, fie nu este efectuată niciuna.

• Consistență    Atunci când este finalizată, o tranzacție trebuie să lase toate datele într-o stare de consistență. Acest lucru înseamnă că se aplică toate regulile de integritate a datelor.

• Izolare    Modificările efectuate de tranzacțiile concurente sunt izolate de tranzacția curentă.

• Durabilitate    După ce s-a finalizat o tranzacție, modificările sunt permanente, chiar și în cazul unei erori de sistem.

Utilizați o tranzacție pentru o integritate a datelor garantată, cum ar fi retragerea de numerar din ATM sau depozitarea automată a cecului pentru salarii. Puteți efectua tranzacții explicite, implicite sau din domeniul de aplicare al lotului. Iată două exemple TSQL:

-- Using an explicit transaction

BEGIN TRANSACTION;  
DELETE FROM HumanResources.JobCandidate  
    WHERE JobCandidateID = 13;  
COMMIT;  

-- the ROLLBACK statement rolls back the INSERT statement, but the created table still exists.

CREATE TABLE ValueTable (id int);  
BEGIN TRANSACTION;  
       INSERT INTO ValueTable VALUES(1);  
       INSERT INTO ValueTable VALUES(2);  
ROLLBACK;

Pentru mai multe informații, consultați Tranzacții.

Începutul paginii

Utilizarea restricțiilor și a triggerelor

Toate bazele de date prezintă modalități de a menține integritatea datelor.

Restricții

În Access, impuneți integritatea referențială într-o relație între tabele prin intermediul asocierilor de chei străine și chei primare, actualizări în cascadă și ștergeri, precum și reguli de validare. Pentru mai multe informații, consultați Ghid pentru relațiile între tabele și Crearea unei reguli de validare pentru a valida datele dintr-un câmp.

În SQL Server, utilizați restricțiile UNIQUE și CHECK, care sunt obiecte de bază de date ce impun integritatea datelor în tabelele SQL Server. Pentru a valida faptul că o valoare este validă în alt tabel, utilizați o restricție pentru cheia străină. Pentru a valida faptul că o valoare dintr-o coloană se încadrează într-un anumit interval, utilizați o restricție Check. Aceste obiecte sunt prima voastră linie de apărare și sunt proiectate să funcționeze eficient. Pentru mai multe informații, consultațiRestricții Unique și restricții Check.

Triggere

Access nu are triggere pentru baza de date. În SQL Server, puteți utiliza triggere pentru a impune norme complexe de integritate a datelor și pentru a executa această logică de business pe server. Un trigger al bazei de date este o procedură stocată, care rulează când apar anumite acțiuni într-o bază de date. Triggerul este un eveniment, cum ar fi adăugarea sau ștergerea unei înregistrări într-un tabel, care declanșează și apoi execută procedura stocată. Deși o bază de date Access poate asigura integritatea referențială atunci când un utilizator încearcă să actualizeze sau să șteargă date, SQL Server are un set sofisticat de triggere. De exemplu, puteți să programați un trigger pentru a șterge înregistrările în masă și a asigura integritatea datelor. Puteți chiar să adăugați triggere la tabele și vizualizări.

Pentru mai multe informații, consultați Triggere - DML, Triggere - DDL și Proiectarea unui trigger T-SQL.

Începutul paginii

Utilizarea coloanelor calculate (computed)

În Access, creați o coloană calculată (calculated) adăugând-o la o interogare și construind o expresie, cum ar fi:

Extended Price: [Quantity] * [Unit Price]

În SQL Server, caracteristica echivalentă se numește coloană calculată (computed) și este o coloană virtuală care nu este stocată fizic în tabel, cu excepția cazului în care coloana este marcată PERSISTED. O coloană calculată utilizează date din alte coloane într-o expresie. Pentru a crea o coloană calculată, adăugați-o într-un tabel. De exemplu:

CREATE TABLE dbo.Products   
(  
    ProductID int IDENTITY (1,1) NOT NULL  
  , QtyAvailable smallint  
  , UnitPrice money  
  , InventoryValue AS QtyAvailable * UnitPrice  
);  

Pentru mai multe informații, consultați Specificarea coloanelor calculate într-un tabel.

Începutul paginii

Marcarea temporală a datelor

Adăugați un câmp de tabel pentru a înregistra o marcă de timp la crearea unei înregistrări, astfel încât să puteți înregistra introducerea datelor. În Access, puteți pur și simplu să creați o coloană de dată cu valoarea implicită =Now(). Pentru a înregistra o dată sau o oră în SQL Server, utilizați tipul de dată datetime2 cu valoarea implicită SYSDATETIME().

Notă    Nu confundați rowversion cu adăugarea unei mărci de timp la datele dvs. Marca de timp a cuvintelor cheie este un sinonim pentru rowversion în SQL Server, dar ar trebui să utilizați rowversion pentru cuvinte cheie. În SQL Server, rowversion este un tip de date care prezintă numere binare unice, generate automat într-o bază de date și este utilizat în general ca mecanism pentru rânduri de tabel cu marcarea versiunilor. Cu toate acestea, tipul de date rowversion reprezintă un număr de incrementare, nu păstrează o dată sau o oră și nu este proiectat pentru marcarea temporală a unui rând.

Pentru mai multe informații, consultați rowversion. Pentru mai multe informații despre utilizarea rowversion pentru a reduce la minimum conflictele de înregistrări, consultați Migrarea unei baze de date Access la SQL Server.

Începutul paginii

Gestionarea obiectelor mari

În Access, gestionați date nestructurate, cum ar fi fișiere, fotografii și imagini, utilizând tipul de date Atașare. În terminologia SQL Server, datele nestructurate se numesc Blob (obiect mare binar) și există mai multe modalități de a lucra cu acestea:

FILESTREAM    Utilizează tipul de date varbinary (max) pentru a stoca date nestructurate în sistemul de fișiere, nu în baza de date. Pentru mai multe informații, consultați Accesarea datelor FILESTREAM cu Transact-SQL.

FileTable    Stochează bloburi în tabele speciale, numite FileTables și asigură compatibilitatea cu aplicațiile Windows, ca și când ar fi stocate în sistemul de fișiere și fără a opera modificări la aplicațiile client. FileTable necesită utilizarea FILESTREAM. Pentru mai multe informații, consultați FileTables.

Depozit de BLOBURI la distanță (RBS)    Stochează obiecte mari binare (BLOBURI) în soluții de stocare a produselor, nu direct pe server. Aceasta permite economisirea spațiului și reducerea resurselor hardware. Pentru mai multe informații, consultați Date obiect mare binar (Blob).

Începutul paginii

Lucrul cu date ierarhice

Deși bazele de date relaționale, cum ar fi Access, sunt foarte flexibile, lucrul cu relațiile ierarhice este o excepție, necesitând adesea instrucțiuni sau cod SQL complexe. Între exemplele de date ierarhice se numără: structura organizațională, sistemul de fișiere, taxonomia termenilor lingvistici și graficul de linkuri între pagini web. SQL Server are un tip de date hierarchyid predefinit și un set de funcții ierarhice pentru a stoca, a interoga și a gestiona cu ușurință date ierarhice.

Pentru mai multe informații, consultați Date ierarhice și Tutorial: utilizarea tipului de date hierarchyid.

Începutul paginii

Manipularea textului JSON

JavaScript Object Notation (JSON) este un serviciu web care utilizează texte ușor de citit de utilizatori pentru a transmite date sub formă de perechi atribut-valoare în comunicare asincronă între browsere și servere. De exemplu:

{
"firstName": "Mary",
"lastName": "Contrary",
"spouse": null,
"age": 27
}

Access nu are moduri predefinite de gestionare a datelor JSON, dar în SQL Server puteți să stocați, să indexați, să interogați și să extrageți cu ușurință date JSON. Puteți să convertiți și să stocați text JSON într-un tabel sau să formatați datele ca text JSON. De exemplu, puteți să formatați rezultatele interogării ca JSON pentru o aplicație web sau să adăugați structuri de date JSON în rânduri și coloane.

Notă    JSON nu este acceptat în VBA. Ca alternativă, puteți utiliza XML în VBA utilizând biblioteca MSXML.

Pentru mai multe informații, consultați Date JSON în SQL Server.

Începutul paginii

Resurse

Acum este momentul potrivit să aflați mai multe despre SQL Server și Transact SQL (TSQL). După cum ați remarcat, există multe funcții ca Access, dar și capacități pe care Access pur și simplu nu le are. Pentru a trece la următorul nivel, iată câteva resurse de învățare:

Începutul paginii