Sqlserver
 sql >> Base de Dados >  >> RDS >> Sqlserver

SQL Server 2016


A versão Community Technical Preview (CTP) do SQL Server 2016 nos deu a oportunidade de experimentar alguns dos novos recursos que estarão disponíveis na próxima versão.

Mascaramento dinâmico de dados


Esse recurso permite proteger dados confidenciais de usuários que não estão autorizados a vê-los, obscurecendo parte ou todo o conteúdo de uma coluna. Por exemplo, você pode expor parte de um número de cartão de crédito para permitir que a equipe de suporte técnico veja os últimos quatro dígitos; você pode optar por ocultar completamente os dados mantidos em uma coluna de salário.

Se você estiver usando o SQL Server CTP 2.0, precisará executar este comando para habilitar o mascaramento de dados dinâmicos:
DBCC TRACEON(209,219,-1)

Não use este comando se estiver usando uma versão posterior do CTP, pois isso desabilitará o mascaramento dinâmico de dados. (Se você estiver usando o CTP 2.0 e não execute este comando DBCC ou você está executando o CTP2.1+ e você faz execute este comando, você receberá o erro "Sintaxe incorreta perto de 'mascarado'" ao tentar definir uma máscara dinâmica para uma coluna.

O SQL a seguir cria uma tabela que usa mascaramento de dados dinâmicos para ocultar o conteúdo de três colunas. O conteúdo do CreditCard coluna estão parcialmente expostas. O que é exposto no Phone coluna é deixada para a máscara de dados dinâmicos. O padrão para uma coluna de string é "xxxx". O padrão para uma coluna numérica é "0". O Email column usa uma máscara de dados dinâmica especificamente voltada para o conteúdo dessa coluna.
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')

Usando o isql incluído em nossa distribuição de driver ODBC do SQL Server, efetuamos login com uma conta do SQL Server que não está autorizada a exibir o conteúdo de uma coluna mascarada:
$ /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] |
+----+-------+-----------+-------+---------------+

Em seguida, efetuamos login com uma conta que tenha privilégios suficientes:
$ /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] |
+----+-------+-----------+--------------+------------------------+

Suporte a JSON


JavaScript Object Notation (JSON) é um formato de texto que facilita o intercâmbio de dados. À medida que mais desenvolvedores de aplicativos adotam o JSON como seu formato de dados preferido, cresce a necessidade de bancos de dados compatíveis com JSON. Como consequência, vários bancos de dados NoSQL escolheram JSON como seu formato de dados primário. Um desses bancos de dados é o MongoDB.

Em nossas máquinas de teste, usamos o suporte JSON do SQL Server 2016 para trocar dados entre o SQL Server e o MongoDB.

Usamos o programa de cópia em massa (bcp) incluído na distribuição do driver ODBC do SQL Server para exportar os dados do cliente que criamos anteriormente no formato JSON. (O comando bcp se conecta ao SQL Server como "sa" e, portanto, os dados nas colunas mascaradas são expostos.)
$ 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"}]

Em seguida, importamos os dados JSON para o 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" }
>

Segurança em nível de linha


Com seu recurso de segurança em nível de linha, o SQL Server 2016 pode restringir o acesso a dados de linha com base em um logon do SQL Server. A segurança em nível de linha é transparente para os usuários do SQL Server, eles não sabem que as linhas que não estão autorizadas a ver estão sendo filtradas dos resultados da consulta.

Para testar esse recurso com nosso driver ODBC do SQL Server, reproduzimos o exemplo de segurança em nível de linha da Microsoft. Fizemos isso em um banco de dados que tinha usuários do SQL Server chamados "Sales1" e "Sales2", que têm SELECT privilégios.

Criamos e preenchemos uma tabela com alguns dados de vendas. O SalesRep A coluna armazena o nome de usuário do representante de vendas relevante.
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);

A segurança em nível de linha é implementada com uma função com valor de tabela que retorna uma única linha, se o usuário tiver o acesso apropriado, ou nenhum resultado. No exemplo a seguir, a função com valor de tabela retorna uma linha se o SalesRep coluna é a mesma que o usuário que está executando a consulta.
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);

Usamos o driver ODBC do SQL Server para conectar ao banco de dados como o usuário Sales2. A segurança em nível de linha garante que esse usuário possa ver apenas as vendas feitas pelo usuário 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   |
+------------+----------+-----------+-------+
|            |          |           |       |
+------------+----------+-----------+-------+

No banco de dados R


Com a compra da Revolution Analytics pela Microsoft, fornecedora de software e serviços para a linguagem de programação R, eles podem integrar o R ​​ao SQL Server. O SQL Server 2016 será a primeira versão do banco de dados a incorporar R, permitindo que o código R seja executado dentro do mecanismo de banco de dados SQL Server.

Se você tiver uma versão anterior do SQL Server, a alternativa é extrair dados do SQL Server para o R usando ODBC. O pacote RODBC forneceu uma interface ODBC para R. Construímos o RODBC com base no gerenciador de driver unixODBC incluído na distribuição de nosso driver do SQL Server e, em seguida, recuperamos alguns dados do SQL Server do 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