Community Technical Preview (CTP)-utgåvan av SQL Server 2016 har gett oss möjlighet att prova några av de nya funktionerna som kommer att finnas tillgängliga i den kommande versionen.
Dynamisk datamaskering
Den här funktionen låter dig skydda konfidentiell data från användare som inte har behörighet att se den genom att dölja en del av eller hela innehållet i en kolumn. Till exempel kan du exponera en del av ett kreditkortsnummer för att hjälpa personalen att se de fyra sista siffrorna; du kan välja att helt dölja uppgifter som finns i en lönekolumn.
Om du använder SQL Server CTP 2.0 måste du köra det här kommandot för att aktivera dynamisk datamaskering:
DBCC TRACEON(209,219,-1)
Använd inte det här kommandot om du använder en senare version av CTP, eftersom detta kommer att inaktivera dynamisk datamaskering. (Om du använder CTP 2.0 och du inte gör det kör det här DBCC-kommandot eller så kör du CTP2.1+ och du gör det kör det här kommandot kommer du att få felet "Felaktig syntax nära 'maskerad'" när du försöker definiera en dynamisk mask för en kolumn.
Följande SQL skapar en tabell som använder dynamisk datamaskering för att dölja innehållet i tre kolumner. Innehållet i CreditCard kolumner är delvis exponerade. Vad som exponeras i Phone kolumnen lämnas till den dynamiska datamasken. Standardinställningen för en strängkolumn är "xxxx". Standardinställningen för en numerisk kolumn är "0". Email kolumn använder en dynamisk datamask specifikt inriktad på innehållet i den kolumnen.
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')
Använda isql program som ingår i vår distribution av SQL Server ODBC-drivrutiner, loggar vi in med ett SQL Server-konto som inte är behörigt att se innehållet i en maskerad kolumn:
$ /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 loggar sedan in med ett konto som har tillräckliga 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-support
JavaScript Object Notation (JSON) är ett textformat som underlättar utbyte av data. I takt med att fler applikationsutvecklare använder JSON som sitt föredragna dataformat, växer behovet av JSON-vänliga databaser. Som en konsekvens har flera NoSQL-databaser valt JSON som sitt primära dataformat. En sådan databas är MongoDB.
På våra testmaskiner använde vi SQL Server 2016:s JSON-stöd för att utbyta data mellan SQL Server och MongoDB.
Vi använde bulkkopieringsprogrammet (bcp) som ingår i vår SQL Server ODBC-drivrutinsdistribution för att exportera kunddata som vi skapade tidigare i JSON-format. (Kommandot bcp ansluter till SQL Server som "sa" och så exponeras data i de maskerade kolumnerna.)
$ 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 importerade sedan JSON-data till 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" }
>
Säkerhet på radnivå
Med sin Row-Level Security-funktion kan SQL Server 2016 begränsa åtkomst till raddata baserat på en SQL Server-inloggning. Row-Level Security är transparent för SQL Server-användare, de är omedvetna om att rader som de inte har behörighet att se filtreras från deras frågeresultat.
För att prova den här funktionen med vår SQL Server ODBC-drivrutin återgav vi Microsofts säkerhetsexempel på radnivå. Vi gjorde detta i en databas som hade SQL Server-användare med namnet "Sales1" och "Sales2", som har SELECT privilegier.
Vi skapade och fyllde i en tabell med lite försäljningsdata. SalesRep kolumnen lagrar användarnamnet för den relevanta säljaren.
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);
Säkerhet på radnivå implementeras med en tabellvärderad funktion som antingen returnerar en enda rad, om användaren har rätt åtkomst, eller inga resultat. I följande exempel returnerar den tabellvärderade funktionen en rad om SalesRep kolumnen är densamma som användaren som kör frågan.
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 använde SQL Server ODBC-drivrutinen för att ansluta till databasen som Sales2-användare. Säkerhet på radnivå säkerställer att denna användare endast kan se försäljningar gjorda av användaren 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 | +------------+----------+-----------+-------+ | | | | | +------------+----------+-----------+-------+
R i databasen
Med Microsofts köp av Revolution Analytics, en leverantör av mjukvara och tjänster för programmeringsspråket R, kan de integrera R med SQL Server. SQL Server 2016 kommer att vara den första versionen av databasen som innehåller R, vilket gör att R-kod kan köras inuti SQL Server-databasmotorn.
Om du har en tidigare version av SQL Server är alternativet att extrahera data från SQL Server till R genom att använda ODBC. RODBC-paketet tillhandahöll ett ODBC-gränssnitt för R. Vi byggde RODBC mot unixODBC Driver Manager som ingår i vår SQL Server-drivrutinsdistribution och hämtade sedan en del SQL Server-data från 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