Iepazīšanās ar Access, izmantojot SQL Server

Darba nepārtrauktības nodrošināšana

Ja jums ir Access risinājums, ir svarīgi nodrošināt tā darbību ar minimāliem pārtraukumiem, taču Access aizmugursistēmas datu bāzes iespējas ir ierobežotas. Ir svarīgi dublēt Access datu bāzi, lai aizsargātu datus, taču tad lietotājiem ir jābūt bezsaistē. Pēc tam ir neplānota dīkstāve, ko izraisa aparatūras/programmatūras uzturēšanas jauninājumi, tīkla vai strāvas padeves pārtraukumi, aparatūras kļūmes, drošības pārkāpumi vai pat kiberuzbrukumi. Lai samazinātu dīkstāves laiku un ietekmi uz uzņēmumu, varat dublēt SQL Server datu bāzi, kamēr tā tiek izmantota. Turklāt SQL Server piedāvā arī augstas pieejamības (high availability — HA) un ārkārtas atkopšanas (disaster recovery — DR) stratēģijas. Šo divu tehnoloģiju apvienojumu dēvē par HADR. Papildinformāciju skatiet rakstā Darba nepārtrauktība un datu bāzes atkopšana un Darba nepārtrauktības nodrošināšana, izmantojot SQL Server (e-grāmata).

Dublēšana lietošanas laikā

SQL Server izmanto tiešsaistes dublēšanas procesu, ko var izmantot datu bāzes darbības laikā. Varat veikt pilnu dublēšanu, daļēju dublēšanu vai failu dublēšanu. Dublēšanas procesā tiek kopēti dati un transakciju žurnāli, lai nodrošinātu pilnīgu atkopšanas darbību. It īpaši darbā ar lokālo risinājumu ir jāņem vērā atšķirības starp vienkāršām un pilnām atkopšanas opcijām un to, kā tās ietekmē transakciju žurnālu pieaugumu. Papildinformāciju skatiet rakstā Atkopšanas modeļi.

Lielākā daļa dublēšanas darbību notiek uzreiz, izņemot failu pārvaldību un datu bāzes samazināšanas darbības. Savukārt, ja mēģināt izveidot vai izdzēst datu bāzes failu, kamēr notiek dublēšana, darbība neizdodas. Papildinformāciju skatiet rakstā Dublēšanas pārskats.

HADR

Divi visbiežāk sastopamie paņēmieni, kā sasniegt augstu pieejamību un darba nepārtrauktību, ir spoguļošana un grupēšana. SQL Server integrē spoguļošanas un grupēšanas tehnoloģiju ar "vienmēr ieslēgtām kļūmjpārleces klasteru instancēm" un "vienmēr ieslēgtām pieejamības grupām".

Spoguļošana ir datu bāzes līmeņa nepārtrauktības risinājums, kas atbalsta gandrīz acumirklīgu kļūmjpārlēci, uzturot gaidstāves datu bāzi, aktīvās datu bāzes pilnu kopiju vai spoguļdatu bāzi atsevišķā aparatūrā. Tā var darboties sinhronā (augstas drošības) režīmā, kur ienākošā transakcija tiek nodota visiem serveriem vienlaikus, vai asinhronā (augstas veiktspējas) režīmā, kur ienākošā transakcija tiek nodota aktīvai datu bāzei un pēc tam kādā iepriekšnoteiktā brīdi tiek pārkopēta uz spoguļdatu bāzi. Spoguļošana ir datu bāzes līmeņa risinājums, kas darbojas tikai ar tām datu bāzēm, kas izmanto pilnu atkopšanas modeli.

Klasteris ir servera līmeņa risinājums, kas apvieno serverus vienā datu krātuvē, kas lietotājam izskatās kā viena instance. Lietotāji izveido savienojumu ar instanci, un viņiem nekad nav nepieciešams zināt, kurš serveris pašlaik ir aktīvs instancē. Ja kāds serveris nedarbojas vai tam ir jāveic bezsaistes uzturēšana, lietotājs to nemana. Katru klastera serveri pārrauga klastera pārvaldnieks, kas izmanto periodiskos kontrolziņojumus, lai noteiktu, kad klastera aktīvais serveris ir bezsaistē, un mēģina nemanāmi pārslēgties uz nākamo klastera serveri, lai gan pārslēgšanās laikā vērojama zināma laika aizkave.

Papildinformāciju skatiet rakstā Vienmēr ieslēgtas kļūmjpārlēces klasteru instances un Vienmēr ieslēgtas pieejamības grupas: augstas pieejamības un ārkārtas atkopšanas risinājums.

Uz lapas sākumu

SQL Server drošība

Lai gan varat aizsargāt savu Access datu bāzi, izmantojot drošības kontroles centru un šifrējot datu bāzi, SQL Server piedāvā papildu drošības līdzekļus. Aplūkosim trīs iespējas, kas Access lietotājam var šķist noderīgas. Papildinformāciju skatiet rakstā SQL Server nodrošināšana.

Datu bāzes autentifikācija

Platformā SQL Server ir četras datu bāzu autentifikācijas metodes, kuras varat norādīt ODBC savienojuma virknē. Papildinformāciju skatiet Datu saistīšana vai importēšana no Azure SQL Server datu bāzes. Katrai metodei ir savas priekšrocības.

Integrētā Windows autentifikācija    Izmantojiet Windows akreditācijas datus lietotāju validācijai, drošības lomām un lietotāju līdzekļu un datu lietošanas ierobežojumiem. Varat izmantot domēnu akreditācijas datus un ērti pārvaldīt lietotāju tiesības savā lietojumprogrammā. Ja vēlaties, ievadiet pakalpojuma pamatnosaukumus (SPN). Papildinformāciju skatiet rakstā Autentifikācijas režīma izvēle.

SQL Server autentifikācija    Lietotājiem ir jāizveido savienojums, izmantojot akreditācijas datus, kas iestatīti datu bāzē, ievadot pieteikšanās ID un paroli (ja lietotājs pirmo reizi piekļūst datu bāzei sesijā). Papildinformāciju skatiet rakstā Autentifikācijas režīma izvēle.

Azure Active Directory integrētā autentifikācija    Izveidojiet savienojumu ar Azure SQL Server datu bāzi, izmantojot Azure Active Directory. Kad esat konfigurējis Azure Active Directory autentifikāciju, nav nepieciešams papildu pieteikšanās vārds un parole. Papildinformāciju skatiet rakstā Savienojuma izveide ar SQL datu bāzi, izmantojot Azure Active Directory autentifikāciju.

Active Directory paroles autentifikācija    Izveidojiet savienojumu, izmantojot akreditācijas datus, kas iestatīti Azure Active Directory bāzē, ievadot pieteikšanās vārdu un paroli. Papildinformāciju skatiet rakstā Savienojuma izveide ar SQL datu bāzi, izmantojot Azure Active Directory autentifikāciju.

Padoms   . Izmantojiet apdraudējumu noteikšanu, lai saņemtu brīdinājumus par anomālu datu bāzu darbību, kas norāda uz iespējamiem drošības apdraudējumiem Azure SQL Server datu bāzē. Papildinformāciju skatiet rakstā SQL datu bāzes apdraudējumu noteikšana.

Lietojumprogrammas drošība

Platformai SQL Server ir divi lietojumprogrammas līmeņa drošības līdzekļi, ko varat izmantot kopā ar Access.

Dinamiskā datu maskēšana    Maskējiet sensitīvu informāciju, noslēpjot to no lietotājiem, kuriem nav atbilstošu atļauju. Piemēram, varat daļēji vai pilnībā maskēt sociālās apdrošināšanas numurus.

Daļēja datu maska

Pilna datu maska

Pastāv vairāki veidi, kā definēt datu masku, un varat to lietot dažādiem datu tipiem. Datu maskēšanas pamatā ir politikas tabulu un kolonnu līmenī. Tā ir paredzēta noteiktai lietotāju kopai un to var lietot reāllaikā, lai veiktu vaicājumus. Papildinformāciju skatiet rakstā Dinamiskā datu maskēšana.

Rindas līmeņa drošība    Varat izmantot rindas līmeņa drošību, lai kontrolētu piekļuvi konkrētām datu bāzes rindām, kurās ir sensitīva informācija, kuru pamatā ir lietotāju īpašības. Datu bāzu sistēma lieto šos piekļuves ierobežojumus, padarot drošības sistēmu uzticamāku un stabilāku.

Pastāv divu veidu drošības predikāti:

• Filtra predikāts filtrē rindas no vaicājuma. Filtrs ir caurspīdīgs, un lietotājs nemana, ka notiek filtrēšana.

• Bloķēšanas predikāts novērš nesankcionētas darbības, un, ja darbību nevar veikt, izraisa izņēmumu.

Papildinformāciju skatiet rakstā Rindas līmeņa drošība.

Datu aizsardzība, izmantojot šifrēšanu

Aizsargājiet datus, kad tie atrodas dīkstāvē, tiek pārsūtīti vai tiek lietoti, neietekmējot datu bāzes veiktspēju. Papildinformāciju skatiet rakstā SQL Server šifrēšana.

Šifrēšana dīkstāvē    Lai aizsargātu personas datus pret bezsaistes multivides uzbrukumiem fiziskās krātuves slānī, izmantojiet šifrēšanu dīkstāvē, kas tiek dēvēta arī par caurspīdīgo datu šifrēšanu (Transparent Data Encryption — TDE). Tas nozīmē, ka jūsu dati tiek aizsargāti pat tad, ja fiziskais datu nesējs ir nozagts vai nepareizi noņemts. TDE veic datu bāzu, dublējumu un transakciju žurnālu reāllaika šifrēšanu un atšifrēšanu bez nepieciešamības veikt izmaiņas lietojumprogrammās.

Šifrēšana datu pārsūtīšanas laikā    Lai nodrošinātu aizsardzību pret spiegošanu un "starpnieku" uzbrukumiem, varat šifrēt datus, kas tiek pārsūtīti visā tīklā. SQL Server atbalsta transporta slāņa drošību (TLS) 1.2, lai nodrošinātu ļoti drošu saziņu. Tabulas datu plūsmas (TDS) protokols tiek lietots arī, lai aizsargātu saziņu neuzticamos tīklos.

Šifrēšana, kas tiek izmantota klienta datu lietošanas laikā    Lai aizsargātu personas datus lietošanas laikā, jums ir vajadzīgs līdzeklis "Always Encrypted". Personas datus šifrē un atšifrē klienta datora draiveris, neizpaužot šifrēšanas atslēgas datu bāzu programmai. Tādējādi šifrētie dati ir redzami tikai personām, kas ir atbildīgas par šo datu pārvaldību, un nav pieejami citiem priviliģētiem lietotāji, kuri nedrīkst piekļūt datiem. Atkarībā no atlasītā šifrēšanas veida, līdzeklis Always Encrypted, iespējams, var ierobežot dažas datu bāzes funkcijas, piemēram, meklēšanu, grupēšanu, kā arī šifrēto kolonnu indeksēšanu.

Uz lapas sākumu

Konfidencialitātes problēmu risināšana

Konfidencialitātes problēmas ir tik plaši izplatītas, ka Eiropas Savienība ir definējusi juridiskās prasības, izmantojot vispārējo datu aizsardzības regulu (VDAR). Par laimi, SQL Server aizmugursistēma ir labi piemērota, lai atbilstu šīm prasībām. Padomājiet par VDAR ieviešanu trīs soļu struktūrā.

1. darbība. Atbilstības riska novērtēšana un pārvaldība

VDAR pieprasa, lai jūs identificētu un uzskaitītu personas informāciju, kas atrodas tabulās un failos. Šī informācija var būt jebkas: vārds, fotoattēls, e-pasta adrese, bankas konta informācija, ziņas sociālajos tīklos, medicīniskā informācija vai pat IP adrese.

Jauns rīks SQL Data Discovery and Classification, kas iebūvēts komplektā SQL Server Management Studio, palīdz atklāt, klasificēt, apzīmēt un ziņot par sensitīviem datiem, lietojot divus metadatu atribūtus kolonnās:

• Etiķetes    Lai definētu sensitīvos datus.

• Informācijas veidi    Lai nodrošinātu papildu informāciju par kolonnā saglabātajiem datu tipiem.

Cits atklāšanas mehānisms, ko varat izmantot, ir pilna teksta meklēšana, kas ietver iespēju izmantot predikātus CONTAINS un FREETEXT un rindu kopas vērtību funkcijas, piemēram, CONTAINSTABLE un FREETEXTTABLE, kas jāizmanto kopā ar priekšrakstu SELECT. Izmantojot pilna teksta meklēšanu, varat meklēt tabulās, lai atklātu vārdus, vārdu kombinācijas vai vārdu variācijas, piemēram, sinonīmus vai vārdus ar mainīgām galotnēm. Papildinformācijai skatiet sadaļu Pilna teksta meklēšana.

2. darbība. Personas informācijas aizsardzība

VDAR pieprasa, lai jūs aizsargātu personas informāciju un ierobežotu piekļuvi tai. Papildus standarta darbībām, kuras veicat, lai pārvaldītu piekļuvi savam tīklam un resursiem, piemēram, ugunsmūra iestatījumiem, varat izmantot SQL Server drošības līdzekļus, lai palīdzētu kontrolēt piekļuvi datiem:

• SQL Server autentifikācija lietotāja identitātes pārvaldībai un nesankcionētas piekļuves novēršanai.

• Rindu līmeņa drošība, lai ierobežotu piekļuvi tabulas rindām, pamatojoties uz relāciju starp lietotāju un šiem datiem.

• Dinamiskā datu maskēšana, lai ierobežotu piekļuvi personas datiem, noslēpjot tos no lietotājiem, kam nav atļauju tiem piekļūt.

• Šifrēšana, lai nodrošinātu, ka personas dati tiek aizsargāti pārsūtīšanas un glabāšanas laikā, un tiek aizsargāti pret apdraudējumiem, tostarp serverī.

Papildinformāciju skatiet sadaļā SQL Server drošība.

3. darbība. Efektīva atbildēšana uz pieprasījumiem

VDAR pieprasa, lai jūs uzturētu personas datu apstrādes ierakstus un pēc pieprasījuma padarītu šos ierakstus pieejamus uzraudzības iestādēm. Ja rodas problēmas, tostarp nejauša datu noplūde, aizsardzības vadīklas ļauj ātri reaģēt. Datiem jābūt ātri pieejamiem, ja nepieciešams ziņot atbilstošajām iestādēm. Piemēram, VDAR pieprasa, lai par personas datu pārkāpumu tiktu ziņots uzraudzības iestādei “ne vēlāk kā 72 stundu laikā pēc tam, kad tas ir kļuvis zināms”.

SQL Server 2017 palīdz jums veikt atskaišu izveides uzdevumus vairākos veidos.

• SQL Server Audit palīdz nodrošināt, ka pastāv pastāvīgs datu bāzes piekļuves un apstrādes darbību reģistrs. Tas veic detalizētu auditēšanu, kas izseko datu bāzu darbībām, lai palīdzētu jums izprast un identificēt potenciālos apdraudējumus, iespējamos pārkāpumus vai drošības pārkāpumus. Varat viegli veikt datu analīzi.

• SQL Server pagaidu tabulas ir sistēmas versijas lietotāja tabulas, kas veidotas, lai nodrošinātu pilnu datu izmaiņu vēsturi. Tās var izmantot, lai atvieglotu ziņošanu un noteikta laika punkta analīzi.

• SQL Vulnerability Assessment palīdz noteikt problēmas, kas saistītas ar drošību un atļaujām. Kad tiek noteikta problēma, varat arī detalizēti skatīt datu bāzu skenēšanas atskaites, lai atrastu darbības risinājumam.

Papildinformāciju skatiet rakstā Uzticēšanās platformas izveide (e-grāmata) un Ceļš uz VDAR atbilstību.

Uz lapas sākumu

Datu bāzu momentuzņēmumu izveide

Datu bāzes momentuzņēmums ir tikai lasāms, statisks SQL Server datu bāzes skats noteiktā laika posmā. Lai gan varat kopēt Access datu bāzes failu, lai efektīvi izveidotu datu bāzes momentuzņēmumu, programmā Access nav iebūvēta metodika kā serverī SQL Server. Datu bāzes momentuzņēmumu var izmantot, lai rakstītu atskaites, pamatojoties uz datu bāzes momentuzņēmuma izveides laikā esošajiem datiem. Varat arī izmantot datu bāzes momentuzņēmumu, lai uzturētu vēsturiskus datus, piemēram, vienu momentuzņēmumu katram finanšu gada ceturksnim, kas tiek izmantots, lai sakārtotu perioda beigu atskaites. Iesakām šādas iespējas:

• Nosaukuma piešķiršana momentuzņēmumam    Katram datu bāzes momentuzņēmumam nepieciešams unikāls datu bāzes nosaukums. Lai atvieglotu nosaukuma identificēšanu, pievienojiet tam nolūku un laika periodu. Piemēram, lai trīs reizes dienā uzņemtu AdventureWorks datu bāzes momentuzņēmumu 6 stundu intervālā no plkst. 6.00 līdz 18.00, pamatojoties uz 24 stundu pulksteni, piešķiriet tiem nosaukumus AdventureWorks_snapshot_0600, AdventureWorks_snapshot_1200 un AdventureWorks_snapshot_1800.

• Momentuzņēmumu skaita ierobežošana    Katrs datu bāzes momentuzņēmums tiek saglabāts, līdz tas tiek tieši atmests. Tā kā katra momentuzņēmuma lielums turpinās pieaugt, iespējams, vēlēsities ietaupīt vietu diskā, izdzēšot iepriekšējo momentuzņēmumu pēc jauna momentuzņēmuma izveides. Piemēram, ja gatavojat ikdienas atskaites, paturiet datu bāzes momentuzņēmumu 24 stundas un pēc tam atmetiet to un aizstājiet ar jaunu.

• Savienojuma izveide ar pareizo momentuzņēmumu    Lai izmantotu datu bāzes momentuzņēmumu, Access priekšgalsistēmai ir jāzina pareizā atrašanās vieta. Kad aizstājat esošu momentuzņēmumu ar jaunu, programmai Access ir jānorāda jaunā momentuzņēmuma atrašanās vieta. Pievienojiet loģiku Access priekšgalsistēmai, lai pārliecinātos, vai veidojat savienojumu ar pareizo datu bāzes momentuzņēmumu.

Tālāk aprakstīts, kā izveidot datu bāzes momentuzņēmumu.

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;  

Papildinformāciju skatiet rakstā Datu bāzes momentuzņēmumi (SQL Server).

Uz lapas sākumu

Laiksakritības vadība

Ja daudzi lietotāji vienlaikus mēģina modificēt datus datu bāzē, ir nepieciešama vadīklu sistēma, lai viena lietotāja veiktās izmaiņas nekaitētu citai personai. To dēvē par laiksakritības vadību, un pastāv divas pamata bloķēšanas stratēģijas — pesimistiskā un optimistiskā. Bloķēšana var neļaut lietotājiem mainīt datus tādā veidā, kas ietekmē citus lietotājus. Bloķēšana arī palīdz nodrošināt datu bāzu integritāti, it īpaši ar vaicājumiem, kas pretējā gadījumā var radīt neparedzētus rezultātus. Starp veidiem, kā Access un SQL Server ievieš šīs laiksakritības vadības stratēģijas, pastāv būtiskas atšķirības.

Programmā Access noklusējuma bloķēšanas stratēģijas iestatījums ir optimistisks, un pirmajai personai, kas mēģina rakstīt ierakstu, tiek piešķirtas bloķēšanas īpašumtiesības. Citam lietotājam, kurš mēģina vienlaikus rakstīt tajā pašā ierakstā, programma Access parāda rakstīšanas konflikta dialoglodziņu. Lai novērstu konfliktu, otra persona var saglabāt ierakstu, kopēt to starpliktuvē vai atmest izmaiņas.

Varat arī izmantot rekvizītu RecordLocks, lai mainītu laiksakritības vadības stratēģiju. Šis rekvizīts ietekmē formas, atskaites un vaicājumus, un tam ir trīs iestatījumi:

• Bez bloķēšanas    Formā lietotāji var mēģināt vienlaikus rediģēt vienu ierakstu, bet var tikt parādīts rakstīšanas konflikta dialoglodziņš. Atskaitē ieraksti netiek bloķēti, kamēr atskaite tiek priekšskatīta vai drukāta. Vaicājumā ieraksti netiek bloķēti vaicājuma izpildes laikā. Šis ir veids, kā Access ievieš optimistisko bloķēšanu.

• Visi ieraksti    Visi ieraksti pamatā esošajā tabulā vai vaicājumā tiek bloķēti, kad forma ir atvērta skatā Forma vai Datu lapa, kad tiek priekšskatīta vai drukāta atskaite vai kamēr tiek izpildīts vaicājums. Lietotāji var lasīt ierakstus bloķēšanas laikā.

• Rediģētais ieraksts    Formām un vaicājumiem ierakstu lapa tiek bloķēta, tiklīdz kāds lietotājs sāk rediģēt kādu ieraksta lauku, un tā paliek bloķēta, līdz lietotājs pāriet uz citu ierakstu. Līdz ar to ierakstu vienlaikus var rediģēt tikai viens lietotājs. Šis ir veids, kā Access ievieš pesimistisko bloķēšanu.

Papildinformāciju skatiet rakstā Rakstīšanas konflikta dialoglodziņš un Rekvizīts RecordLocks.

Serverī SQL Server laiksakritības vadība darbojas šādi:

• Pesimistiski    Pēc tam, kad lietotājs veic darbību, kas izraisa bloķēšanu, citi lietotāji nevar veikt darbības, kas varētu būt pretrunā ar bloķēšanu, līdz īpašnieks to atbloķē. Šī laiksakritības vadīkla galvenokārt tiek lietota vidē, kur pastāv liels datu saturs.

• Optimistiski    Optimistiskā laiksakritības vadīkla: lietotāji nebloķē datus, kad tos lasa. Kad lietotājs atjaunina datus, sistēma pārbauda, vai cits lietotājs ir mainījis datus pēc to izlasīšanas. Ja cits lietotājs ir atjauninājis datus, tiek parādīta kļūda. Parasti lietotājs, kas saņem kļūdu, veic transakcijas atriti un sāk darbu no jauna. Šī laiksakritības vadīkla galvenokārt tiek lietota vidē, kur pastāv neliels datu saturs.

Varat norādīt laiksakritības vadības tipu, atlasot vairākus transakcijas atdalīšanas līmeņus, kas definē transakcijas aizsardzības līmeni no izmaiņām, kuras veikušas citas transakcijas, izmantojot priekšrakstu SET TRANSACTION:

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

Papildinformāciju skatiet rakstā Transakciju bloķēšanas un rindu versiju izveides ceļvedis.

Uz lapas sākumu

Vaicājumu veiktspējas uzlabošana

Ja varat izpildīt Access tranzītvaicājumus, izmantojiet SQL Server piedāvātās priekšrocības, lai nodrošinātu vaicājumu efektīvāku izpildi.

Atšķirībā no Access datu bāzes, SQL Server nodrošina paralēlus vaicājumus, lai optimizētu vaicājumu izpildi un indeksēšanas darbības datoros, kuros ir vairāk par vienu mikroprocesoru (CPU). Tā kā SQL Server var veikt vaicājumu vai indeksēšanas darbību paralēli, izmantojot vairākus sistēmas darba pavedienus, šo darbību var pabeigt ātri un efektīvi.

Vaicājumi ir būtisks elements, lai uzlabotu jūsu datu bāzes risinājuma vispārējo veiktspēju. Nepareizi vaicājumi tiek palaisti nenoteiktu laiku, pieprasa taimautu un izmanto resursus, piemēram, centrālos procesorus, atmiņu un tīkla platumu. Tas kavē svarīgas biznesa informācijas pieejamību. Pat viens nepareizs vaicājums var izraisīt nopietnas veiktspējas problēmas jūsu datu bāzē.

Papildinformāciju skatiet rakstā Ātrāka vaicājumu veikšana, izmantojot SQL Server (e-grāmata).

Vaicājumu optimizācija

Pastāv vairāki rīki, kas sadarbojas, lai palīdzētu jums analizēt vaicājuma veiktspēju un to uzlabot. Vaicājumu optimizētājs, izpildes plāni un vaicājumu krātuve (Query Store).

Vaicājumu optimizētājs

Vaicājumu optimizētājs ir viens no svarīgākajiem SQL Server komponentiem. Izmantojiet vaicājumu optimizētāju, lai analizētu vaicājumu un noteiktu visefektīvāko veidu, kā piekļūt nepieciešamajiem datiem. Vaicājumu optimizētāja ievade sastāv no vaicājuma, datu bāzes shēmas (tabulu un indeksu definīcijas) un datu bāzes statistikas. Vaicājuma optimizētāja izvade ir izpildes plāns.

Papildinformāciju skatiet rakstā SQL Server vaicājumu optimizētājs.

Izpildes plāns

Izpildes plāns ir definīcija, kas secīgi izveido avota tabulas, kam piekļūt, un metodes, kas tiek izmantotas, lai izvilktu datus no katras tabulas. Optimizācija ir process, kura laikā tiek atlasīts viens izpildes plāns no, iespējams, daudziem iespējamiem plāniem. Katram iespējamajam izpildes plānam ir saistītās izmaksas izmantoto resursu apjoma veidā, un vaicājuma optimizētājs izvēlas to, kam ir viszemākās aprēķinātās izmaksas.

Serverim SQL Server ir arī dinamiski jāpielāgojas datu bāzes mainīgajiem nosacījumiem. Regresijas vaicājumu izpildes plānos var būtiski ietekmēt veiktspēju. Noteiktas datu bāzes izmaiņas var radīt neefektīvus vai nederīgus izpildes plānus, pamatojoties uz jauno datu bāzes stāvokli. SQL Server nosaka izmaiņas, kas izpildes plānu padara nederīgu, un atzīmē plānu kā nederīgu.

Pēc tam ir jāizveido jauns plāns nākamajam savienojumam, kas izpilda vaicājumu. Nosacījumi, kas padara plānu nederīgu, ir šādi:

• Izmaiņas, kas veiktas tabulai vai skatam, uz ko atsaucas vaicājums (ALTER TABLE un ALTER VIEW).

• Izmaiņas indeksos, ko izmanto izpildes plāns.

• Statistikas datu atjauninājumi, kas tiek izmantoti izpildes plānā un kas tiek ģenerēti tieši no priekšraksta, piemēram, UPDATE STATISTICS, vai automātiski.

Papildinformāciju skatiet rakstā Izpildes plāni.

Vaicājumu krātuve

Vaicājumu krātuve nodrošina ieskatu par izpildīšanas plāna izvēli un veiktspēju. Tā atvieglo veiktspējas problēmu novēršanu, ļaujot ātri atrast veiktspējas atšķirības, ko izraisa izpildes plāna izmaiņas. Vaicājumu krātuve apkopo telemetrijas datus, piemēram, vaicājumu vēsturi, plānus, izpildlaika statistiku un gaidīšanas statistiku. Izmantojiet priekšrakstu ALTER DATABASE, lai ieviestu vaicājuma krātuvi:

ALTER DATABASE AdventureWorks2012 SET QUERY_STORE = ON;

Papildinformāciju skatiet rakstā Veiktspējas pārraudzīšana, izmantojot vaicājumu krātuvi.

ALTER DATABASE [YourDatabaseName] SET COMPATIBILITY_LEVEL = 140;

Vaicājumu veidi

Serverī SQL Server pastāv vairāki veidi, kā veikt vaicājumus, un katram veidam ir savas priekšrocības. Ir svarīgi zināt, kādas tās ir, lai varētu izdarīt pareizo izvēli savam Access risinājumam. Labākais veids, kā izveidot TSQL vaicājumus, ir interaktīvi rediģēt un testēt tos, izmantojot SQL Server Management Studio (SSMS) Transact-SQL redaktoru, kas, izmantojot IntelliSense, var palīdzēt jums izvēlieties pareizos atslēgvārdus un pārbaudīt sintakses kļūdas.

Skati

Serverī SQL Server skats ir kā virtuāla tabula, kur skata dati tiek iegūti no vienas vai vairākām tabulām vai citiem skatiem. Taču skatiem tiek veidotas atsauces tāpat kā tabulām vaicājumos. Skati var paslēpt vaicājumu sarežģītību un palīdzēt aizsargāt datus, ierobežojot rindu un kolonnu kopu. Tālāk norādīts vienkārša skata piemērs:

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;

Lai nodrošinātu optimālu veiktspēju un rediģētu skata rezultātus, izveidojiet indeksētu skatu, kas tiek glabāts datu bāzē kā tabula, tam ir piešķirta krātuve un tam var veikt vaicājumus kā jebkurai tabulai. Lai to izmantotu programmā Access, izveidojiet saiti uz skatu tāpat, kā veidojat saiti uz tabulu. Tālāk parādīts indeksēta skata piemērs:

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);  

Tomēr pastāv ierobežojumi. Nevar atjaunināt datus, ja tiek ietekmēta vairāk nekā viena pamata tabula, skatā ir apkopotas funkcijas, vai skatā atrodas klauzula DISTINCT. Ja SQL Server atgriež kļūdas ziņojumu, kurā ir norādīts, ka tas nezina, kuru ierakstu izdzēst, iespējams, skatam būs jāpievieno dzēšanas trigeris. Visbeidzot, jūs nevarat izmantot klauzulu ORDER BY tā, kā to var darīt Access vaicājumā.

Papildinformāciju skatiet rakstā Skati un Indeksētu skatu izveide.

Iekļautās procedūras

Iekļautās procedūras ir viena vai vairāku TSQL priekšrakstu grupa, kas izmanto ievades parametrus, atgriež izvades parametrus un norāda sekmīgu vai kļūdainu statusa vērtību. Tās darbojas kā vidējais slānis starp Access priekšgalsistēmu un SQL Server aizmugursistēmu. Iekļautās procedūras var būt tikpat vienkāršas kā priekšraksts SELECT vai tikpat sarežģītas kā jebkura programma. Piemērs.

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;  

Ja programmā Access izmantojat iekļauto procedūru, tā parasti atgriež rezultātu, kas ir iestatīts atpakaļ uz formu vai atskaiti. Tomēr tā var veikt arī citas darbības, kas neatgriež rezultātus, piemēram, DDL vai DML priekšrakstus. Ja izmantojat tranzītvaicājumu, pārliecinieties, vai rekvizīts Returns Records ir iestatīts atbilstoši.

Papildinformāciju skatiet rakstā Iekļautās procedūras.

Bieži lietotas tabulu izteiksmes

Bieži lietotās tabulu izteiksmes (Common Table Expressions — CTE) ir kā pagaidu tabula, kas ģenerē nosauktu rezultātu kopu. Tā pastāv tikai viena vaicājuma vai DML priekšraksta izpildei. CTE ir izstrādāta, izmantojot to pašu koda rindu kā priekšrakstā SELECT vai DML priekšrakstā, kas to izmanto, savukārt pagaidu tabulas vai skata izveide un lietošana parasti ir divu soļu process. Piemērs.

-- 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;

CTE izteiksmēm ir vairākas priekšrocības, tostarp:

• Tā kā CTE ir pārejošas, jums tās nav jāizveido kā pastāvīgi datu bāzu objekti, piemēram, skati.

• Vaicājumā vai DML priekšrakstā varat atsaukties uz vienu un to pašu CTE vairāk nekā vienu reizi, kas ļauj vieglāk pārvaldīt jūsu kodu.

• Varat izmantot vaicājumus, kas atsaucas uz CTE, lai definētu kursoru.

Papildinformāciju skatiet rakstā WITH common_table_expression.

Lietotāja definētas funkcijas

Lietotāja definēta funkcija (UDF) var veikt vaicājumus un aprēķinus un atgriezt vai nu skalāras vērtības, vai datu rezultātu kopas. Tās ir līdzīgas programmēšanas valodu funkcijām, kas akceptē parametrus, veic darbības, piemēram, kompleksus aprēķinus, un atgriež šīs darbības rezultātu kā vērtību. Piemērs.

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';  

UDF funkcijām ir noteikti ierobežojumi. Piemēram, tās nevar izmantot noteiktas sistēmas funkcijas, kas nav stingri noteiktas, izpildīt DML vai DDL priekšrakstus vai izpildīt dinamiskus SQL vaicājumus.

Papildinformāciju skatiet rakstā Lietotāja definētās funkcijas.

Uz lapas sākumu

Atslēgu un indeksu pievienošana

Neatkarīgi no tā, kādu datu bāzu sistēmu lietojat, taustiņi un indeksi iet roku rokā.

Atslēgas

Serverī SQL Server noteikti jāizveido primārās atslēgas katrai tabulai un ārējās atslēgas katrai saistītajai tabulai. Ekvivalents datu tipa Access AutoNumber līdzeklis serverī SQL Server ir rekvizīts IDENTITY, ko var izmantot atslēgas vērtību izveidei. Kad šis rekvizīts tiek lietots jebkurai skaitliskai kolonnai, tas kļūst tikai lasāms un to uztur datu bāzes sistēma. Ja ievietojat ierakstu tabulā, kurā ir kolonna IDENTITY, sistēma automātiski palielina kolonnas IDENTITY vērtību par 1 un sākot no 1, taču varat kontrolēt šīs vērtības, izmantojot argumentus.

Papildinformāciju skatiet rakstā TABULAS IDENTITĀTES IZVEIDE (Rekvizīts).

Indeksi

Kā vienmēr, indeksu atlase ir atkarīga no vaicājuma ātrumu un atjaunināšanas izmaksām. Programmā Access ir viena veida indekss, bet serverī SQL Server ir divpadsmit. Par laimi, varat izmantot vaicājumu optimizētāju, lai palīdzētu droši izvēlēties visefektīvāko indeksu. Izmantojot Azure SQL, varat izmantot automātisko indeksēšanas pārvaldību — automātiskās regulēšanas līdzekli, kas iesaka pievienot vai noņemt indeksus. Atšķirībā no Access jums ir jāizveido savi ārējo atslēgu indeksi serverī SQL Server. Varat arī izveidot indeksus indeksētā skatā, lai uzlabotu vaicājuma veiktspēju. Diemžēl, ja modificējat datus skata pamattabulās, palielinās atmiņas lietojums, jo ir jāatjaunina arī skats. Papildinformāciju skatiet rakstā SQL Server indeksa arhitektūra un izstrādes rokasgrāmata un Indeksi.

Uz lapas sākumu

Transakciju izpilde

Tiešsaistes transakciju procesa (OLTP) veikšana ir sarežģīta programmā Access, bet relatīvi vienkārša, izmantojot SQL Server. Transakcija ir viena darba vienība, kas ievieš visas datu izmaiņas, kad tās ir veiksmīgas, bet veic nesekmīgo izmaiņu atriti. Transakcijai ir jābūt četrām īpašībām, kas bieži tiek dēvētas par ACID (Atomicity, Consistency, Isolation, Durability):

• Atomitāte (Atomicity)    Transakcijai ir jābūt atomu veida darba vienībai; vai nu tiek izpildītas visas datu modifikācijas, vai neviena.

• Konsekvence (Consistency)    Kad transakcija ir pabeigta, visiem tās datiem ir jāpaliek nemainīgā stāvoklī. Tas nozīmē, ka tiek lietotas visas datu integritātes kārtulas.

• Atdalīšana (Isolation)    Vienlaicīgu transakciju veiktās izmaiņas tiek atdalītas no pašreizējās transakcijas.

• Ilglaicība (Durability)    Kad transakcija ir pabeigta, veiktās izmaiņas ir pastāvīgas arī sistēmas kļūmes gadījumā.

Jūs izmantojat transakciju, lai nodrošinātu garantētu datu integritāti, piemēram, naudas izņemšanu no bankomāta vai automātisku algas depozītu. Varat veikt tiešas, netiešas vai pakešapstrādes transakcijas. Tālāk sniegti divi TSQL piemēri.

-- 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;

Papildinformāciju skatiet sadaļā Transakcijas.

Uz lapas sākumu

Ierobežojumu un trigeru izmantošana

Visām datu bāzēm ir veidi, kā uzturēt datu integritāti.

Ierobežojumi

Programmā Access tabulu relācijā tiek ieviesta attiecinošā integritāte, izmantojot ārējo atslēgu un primāro atslēgu pārus, kaskadētās atjaunināšanas un dzēšanas iespējas, kā arī validācijas kārtulas. Papildinformāciju skatiet rakstā Tabulu relāciju ceļvedis un Datu ievades ierobežošana, izmantojot validācijas kārtulas.

Serverī SQL Server varat izmantot ierobežojumus UNIQUE un CHECK, kas ir datu bāzes objekti, kas ievieš datu integritāti SQL Server tabulās. Lai pārbaudītu, vai vērtība ir derīga citā tabulā, izmantojiet ārējās atslēgas ierobežojumu. Lai pārbaudītu, vai kolonnā atrodamā vērtība ir noteiktā diapazonā, izmantojiet ierobežojumu Check. Šie objekti ir jūsu pirmā aizsardzība, un tie ir paredzēti efektīvai darba nodrošināšanai. Papildinformāciju skatiet rakstā Ierobežojumi Unique un Check.

Trigeri

Programmā Access nav datu bāzu trigeru. Serverī SQL Server varat izmantot trigerus, lai ieviestu sarežģītas datu integritātes kārtulas un palaistu šo biznesa loģiku serverī. Datu bāzes trigeris ir iekļauta procedūra, kas tiek palaista, ja datu bāzē tiek veiktas noteiktas darbības. Trigeris ir notikums, piemēram, ieraksta pievienošana tabulai vai tā dzēšana, kas tiek palaists, un pēc tam izpilda iekļauto procedūru. Lai gan Access datu bāze var ieviest attiecinošo integritāti, kad lietotājs mēģina atjaunināt vai dzēst datus, serverim SQL Server ir sarežģīta trigeru kopa. Piemēram, varat ieprogrammēt trigeri izdzēst ierakstus masveidā un nodrošināt datu integritāti. Varat arī pievienot trigerus tabulām un skatiem.

Papildinformāciju skatiet rakstā Trigeri — DML, Trigeri — DDL un T-SQL trigera izveide.

Uz lapas sākumu

Aprēķināto kolonnu izmantošana

Programmā Access jūs izveidojat aprēķināmo kolonnu, pievienojot to vaicājumam un izveidojot izteiksmi, piemēram:

Extended Price: [Quantity] * [Unit Price]

Serverī SQL Server ekvivalents līdzeklis tiek dēvēts par aprēķināto kolonnu, kas ir virtuāla kolonna, kas netiek fiziski glabāta tabulā, ja vien kolonna nav atzīmēta kā PERSISTED. Līdzīgi kā aprēķināmā kolonna, aprēķinātā kolonna izteiksmē izmanto datus no citām kolonnām. Lai izveidotu aprēķināto kolonnu, pievienojiet to tabulai. Piemērs.

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

Papildinformāciju skatiet rakstā Aprēķināto kolonnu norādīšana tabulā.

Uz lapas sākumu

Datu laikspiedolu izmantošana

Dažreiz varat pievienot tabulas lauku, lai ierakstītu laikspiedolu, kad tiek izveidots ieraksts, ar mērķi reģistrēt datu ievadi. Programmā Access varat vienkārši izveidot datuma kolonnu ar noklusējuma vērtību =Now(). Lai ierakstītu datumu vai laiku serverī SQL Server, izmantojiet datu tipu datetime2 ar noklusējuma vērtību SYSDATETIME().

Piezīme    Izvairieties no mulsinoša datu tipa rowversion, pievienojot datiem laikspiedolu. Atslēgvārds laikspiedols ir sinonīms vārdam rowversion serverī SQL Server, bet ir jāizmanto atslēgvārds rowversion. Serverī SQL Server rowversion ir datu tips, kas atklāj automātiski ģenerētus, unikālus bināros skaitļus datu bāzē, un parasti tiek lietots kā mehānisms tabulas rindu versijas atzīmēšanai. Tomēr datu tips rowversion ir tikai pieauguma skaitlis, kas nesaglabā datumu vai laiku, un tas nav paredzēts rindas laikspiedolu veidošanai.

Papildinformāciju skatiet rakstā rowversion. Papildinformāciju par to, kā izmantot datu tipu rowversion, lai samazinātu ierakstu konfliktus, skatiet rakstā Access datu bāzes migrēšana uz SQL Server.

Uz lapas sākumu

Lielu objektu pārvaldība

Programmā Access varat pārvaldīt nestrukturētus datus, piemēram, failus, fotoattēlus un attēlus, izmantojot datu tipu Pielikums. SQL Server terminoloģijā nestrukturēti dati tiek dēvēti par BLOB (lielu bināro objektu), un pastāv vairāki veidi, kā ar tiem strādāt:

FILESTREAM    Izmantojiet datu tipu varbinary(max), lai glabātu nestrukturētus datus failu sistēmā, nevis datu bāzē. Papildinformāciju skatiet rakstā Access FILESTREAM dati ar Transact-SQL.

FileTable    Glabā BLOB īpašās tabulās, kas tiek dēvētas par FileTables, un nodrošina saderību ar Windows lietojumprogrammām tā, it kā tās būtu saglabātas failu sistēmā, neveicot nekādas izmaiņas klienta lietojumprogrammās. Lai varētu izmantot FileTable, ir nepieciešams FILESTREAM. Papildinformāciju skatiet rakstā FileTable.

Attālā BLOB krātuve (RBS)    Glabājiet lielus bināros objektus (BLOB) dalīto failu sistēmas risinājumos, nevis tieši serverī. Tas ietaupa vietu un samazina aparatūras resursus. Papildinformāciju skatiet rakstā Lielu bināro objektu (BLOB) dati.

Uz lapas sākumu

Darbs ar hierarhiskiem datiem

Kaut arī relāciju datu bāzes, piemēram, Access, ir ļoti elastīgas, darbs ar hierarhiskajām attiecībām ir izņēmums, un bieži vien ir nepieciešami sarežģīti SQL priekšraksti vai kodi. Hierarhisko datu piemēri: organizācijas struktūra, failu sistēma, valodas terminu taksonomija un saišu diagramma starp tīmekļa lapām. Serverī SQL Server ir iebūvēts datu tips hierarchyid un hierarhisko funkciju kopa, lai ērti glabātu, veidotu vaicājumus un pārvaldītu hierarhijas datus.

Papildinformāciju skatiet sadaļā Hierarhijas dati un Apmācība: Datu tipa hierarchyid izmantošana.

Uz lapas sākumu

JSON tekstu manipulācija

JavaScript Object Notation (JSON) ir tīmekļa pakalpojums, kas izmanto cilvēkiem salasāmu tekstu, lai pārraidītu datus kā atribūtu un vērtību pārus asinhronā pārlūkprogrammas un servera saziņā. Piemērs.

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

Programmā Access nav iebūvētu paņēmienu, kā pārvaldīt JSON datus, bet serverī SQL Server varat ērti glabāt, indeksēt, veidot vaicājumus un izvilkt JSON datus. Varat konvertēt un glabāt JSON tekstu tabulā vai formatēt datus kā JSON tekstu. Piemēram, vēlaties formatēt vaicājuma rezultātus kā JSON tīmekļa lietojumprogrammai vai pievienot JSON datu struktūras rindās un kolonnās.

Piezīme    JSON netiek atbalstīts valodā VBA. Kā alternatīvu varat izmantot XML valodā VBA, izmantojot MSXML bibliotēku.

Papildinformāciju skatiet rakstā JSON dati serverī SQL Server.

Uz lapas sākumu

Resursi

Tagad ir piemērots brīdis, lai uzzinātu vairāk par SQL Server un Transact SQL (TSQL). Kā jau redzējāt, pastāv daudz līdzekļu, kas ir pieejami programmā Access, bet pastāv arī iespējas, kuras Access nepiedāvā. Lai pārietu uz apmācību nākamo līmeni, izpētiet šos mācību resursus:

Uz lapas sākumu