Community Technical Preview (CTP)-udgivelsen af SQL Server 2016 har givet os mulighed for at prøve nogle af de nye funktioner, der vil være tilgængelige i den kommende version.
Dynamisk datamaskering
Denne funktion giver dig mulighed for at beskytte fortrolige data fra brugere, der ikke er autoriseret til at se dem, ved at skjule noget af eller hele en kolonnes indhold. For eksempel kan du blotlægge en del af et kreditkortnummer for at gøre det muligt for helpdesk-personalet at se de sidste fire cifre; du kan vælge helt at skjule data i en lønkolonne.
Hvis du bruger SQL Server CTP 2.0, skal du køre denne kommando for at aktivere dynamisk datamaskering:
DBCC TRACEON(209,219,-1)
Brug ikke denne kommando, hvis du bruger en nyere version af CTP, da dette vil deaktivere dynamisk datamaskering. (Hvis du bruger CTP 2.0, og du ikke gør det kør denne DBCC-kommando, eller du kører CTP2.1+, og du gør det køre denne kommando, vil du få fejlen "Forkert syntaks nær 'maskeret'", når du forsøger at definere en dynamisk maske for en kolonne.
Følgende SQL opretter en tabel, der bruger dynamisk datamaskering til at skjule indholdet af tre kolonner. Indholdet af CreditCard søjlen er delvist eksponeret. Hvad bliver afsløret i Phone kolonnen overlades til den dynamiske datamaske. Standarden for en strengkolonne er "xxxx". Standarden for en numerisk kolonne er "0". Email kolonne bruger en dynamisk datamaske, der er specifikt rettet mod indholdet af den pågældende kolonne.
CREATE TABLE Customer
(ID int IDENTITY PRIMARY KEY,
Name varchar(100) NOT NULL,
CreditCard varchar(9) MASKED WITH (FUNCTION = 'partial(0,"xxxxx",4)') NULL,
Phone varchar(12) MASKED WITH (FUNCTION = 'default()') NULL,
Email varchar(100) MASKED WITH (FUNCTION = 'email()') NULL);
INSERT INTO Customer VALUES('A Name', '111222333', '01937 860000',
'someone@somedomain')
Brug af isql program inkluderet i vores SQL Server ODBC driver distribution, logger vi på med en SQL Server konto, der ikke er autoriseret til at se indholdet af en maskeret kolonne:
$ /usr/local/easysoft/unixODBC/bin/isql.sh -v SQLSERVER_2016 myuser mypassword +---------------------------------------+ | Connected! | | | | sql-statement | | help [tablename] | | quit | | | +---------------------------------------+ SQL> select * from customer +----+-------+-----------+-------+---------------+ | ID | Name | CreditCard| Phone | Email | +----+-------+-----------+-------+---------------+ | 1 | A Name| xxxxx2333 | xxxx | [email protected] | +----+-------+-----------+-------+---------------+
Vi logger derefter på med en konto, der har tilstrækkelige privilegier:
$ /usr/local/easysoft/unixODBC/bin/isql.sh -v SQLSERVER_2016 sa mypassword +---------------------------------------+ | Connected! | | | | sql-statement | | help [tablename] | | quit | | | +---------------------------------------+ SQL> select * from customer +----+-------+-----------+--------------+------------------------+ | ID | Name | CreditCard| Phone | Email | +----+-------+-----------+--------------+------------------------+ | 1 | A Name| 111222333 | 01937 860000 | [email protected] | +----+-------+-----------+--------------+------------------------+
JSON-understøttelse
JavaScript Object Notation (JSON) er et tekstformat, der letter udvekslingen af data. Efterhånden som flere applikationsudviklere anvender JSON som deres foretrukne dataformat, vokser behovet for JSON-venlige databaser. Som en konsekvens heraf har flere NoSQL-databaser valgt JSON som deres primære dataformat. En sådan database er MongoDB.
På vores testmaskiner brugte vi SQL Server 2016's JSON-understøttelse til at udveksle data mellem SQL Server og MongoDB.
Vi brugte bulk copy-programmet (bcp) inkluderet i vores SQL Server ODBC-driverdistribution til at eksportere de kundedata, vi oprettede tidligere i JSON-format. (Bcp-kommandoen opretter forbindelse til SQL Server som "sa", og dataene i de maskerede kolonner er afsløret.)
$ cd /usr/local/easysoft/sqlserver/bcp
$ ./bcp "select * from customer for json auto" queryout customer.json -U sa -c
Password:
Starting copy...
1 row successfully bulk-copied to host file. Total received: 1
Clock Time (ms.) Total : 12129 Average : 0.082 rows per second
$ more customer.json
[{"ID":1,"Name":"A Name","CreditCard":"111222333","Phone":"01937 860000",
"Email":"someone@somedomain"}]
Vi importerede derefter JSON-dataene til MongoDB:
$ cd /opt/mongodb-linux-x86_64-ubuntu1404-3.0.7/bin $ ./mongoimport --db=SQLServer --collection=Customer --file=customer.json --jsonArray $ connected to: localhost imported 1 document
$ ./mongo
MongoDB shell version: 3.0.7
connecting to: test
> use SQLServer
switched to db SQLServer
> db.Customer.find()
{ "_id" : ObjectId("56334017f6df768ab87f2e8c"), "ID" : 1, "Name" :
"A Name", "CreditCard" : "111222333", "Phone" : "01937 860000",
"Email" : "someone@somedomain" }
>
Sikkerhed på rækkeniveau
Med sin Row-Level Security-funktion er SQL Server 2016 i stand til at begrænse adgangen til rækkedata baseret på et SQL Server-login. Sikkerhed på rækkeniveau er gennemsigtig for SQL Server-brugere, de er uvidende om, at rækker, de ikke har tilladelse til at se, bliver filtreret fra deres forespørgselsresultater.
For at prøve denne funktion med vores SQL Server ODBC-driver gengav vi Microsofts sikkerhedseksempel på rækkeniveau. Vi gjorde dette i en database, der havde SQL Server-brugere ved navn "Sales1" og "Sales2", som har SELECT privilegier.
Vi oprettede og udfyldte en tabel med nogle salgsdata. SalesRep kolonnen gemmer brugernavnet på den relevante salgsrepræsentant.
CREATE TABLE Sales ( OrderID int, SalesRep sysname, Product varchar(10), Qty int ); INSERT Sales VALUES (1, 'Sales1', 'Valve', 5), (2, 'Sales1', 'Wheel', 2), (3, 'Sales1', 'Valve', 4), (4, 'Sales2', 'Bracket', 2), (5, 'Sales2', 'Wheel', 5), (6, 'Sales2', 'Seat', 5);
Sikkerhed på rækkeniveau implementeres med en funktion med tabelværdi, der enten returnerer en enkelt række, hvis brugeren har den rette adgang, eller ingen resultater. I det følgende eksempel returnerer funktionen tabelværdi en række, hvis SalesRep kolonnen er den samme som brugeren, der udfører forespørgslen.
CREATE SCHEMA Security;
CREATE FUNCTION Security.fn_securitypredicate(@SalesRep AS sysname)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS fn_securitypredicate_result
WHERE @SalesRep = USER_NAME();
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.fn_securitypredicate(SalesRep)
ON dbo.Sales
WITH (STATE = ON);
Vi brugte SQL Server ODBC-driveren til at oprette forbindelse til databasen som Sales2-bruger. Sikkerhed på rækkeniveau sikrer, at denne bruger kun kan se salg foretaget af brugeren Sales2.
$ /usr/local/easysoft/unixODBC/bin/isql.sh -v SQLSERVER_2016 Sales2 mypassword +---------------------------------------+ | Connected! | | | | sql-statement | | help [tablename] | | quit | | | +---------------------------------------+ SQL> select * from Sales +------------+----------+-----------+-------+ | OrderID | SalesRep | Product | Qty | +------------+----------+-----------+-------+ | 4 | Sales2 | Bracket | 2 | | 5 | Sales2 | Wheel | 5 | | 6 | Sales2 | Seat | 5 | +------------+----------+-----------+-------+ SQL> select * from Sales where OrderID = 1 +------------+----------+-----------+-------+ | OrderID | SalesRep | Product | Qty | +------------+----------+-----------+-------+ | | | | | +------------+----------+-----------+-------+
In-database R
Med Microsofts køb af Revolution Analytics, en udbyder af software og tjenester til programmeringssproget R, er de i stand til at integrere R med SQL Server. SQL Server 2016 vil være den første version af databasen, der inkorporerer R, hvilket gør det muligt at køre R-kode inde i SQL Server-databasemotoren.
Hvis du har en tidligere version af SQL Server, er alternativet at udtrække data fra SQL Server til R ved at bruge ODBC. RODBC-pakken gav en ODBC-grænseflade til R. Vi byggede RODBC mod unixODBC Driver Manager inkluderet i vores SQL Server-driverdistribution og hentede derefter nogle SQL Server-data fra R:
# export ODBC_LIBS=/usr/local/easysoft/unixODBC/lib
# export ODBC_INCLUDE=/usr/local/easysoft/unixODBC/include
# R CMD INSTALL RODBC_1.3-12.tar.gz
$ R
> library("RODBC")
> ch <- odbcConnect("SQLSERVER_2016")
> sqlQuery(ch, paste("SELECT * from Customer"))
ID Name CreditCard Phone Email
1 1 A Name 111222333 01937 860000 someone@somedomain