Sqlserver
 sql >> Baza danych >  >> RDS >> Sqlserver

Serwer SQL 2016

Wersja Community Technical Preview (CTP) SQL Server 2016 dała nam możliwość wypróbowania niektórych nowych funkcji, które będą dostępne w nadchodzącej wersji.

dynamiczne maskowanie danych

Ta funkcja pozwala chronić poufne dane przed użytkownikami, którzy nie są upoważnieni do ich przeglądania, zasłaniając część lub całość zawartości kolumny. Na przykład możesz ujawnić część numeru karty kredytowej, aby umożliwić personelowi pomocy technicznej zobaczenie ostatnich czterech cyfr; możesz całkowicie ukryć dane przechowywane w kolumnie wynagrodzeń.

Jeśli używasz SQL Server CTP 2.0, musisz uruchomić to polecenie, aby włączyć dynamiczne maskowanie danych:

DBCC TRACEON(209,219,-1)

Nie używaj tego polecenia, jeśli używasz nowszej wersji CTP, ponieważ spowoduje to wyłączenie dynamicznego maskowania danych. (Jeśli używasz CTP 2.0, a nie) uruchom to polecenie DBCC lub używasz CTP2.1+ i tak uruchom to polecenie, przy próbie zdefiniowania dynamicznej maski dla kolumny pojawi się błąd „Nieprawidłowa składnia w pobliżu „maski”.

Poniższy kod SQL tworzy tabelę, która używa dynamicznego maskowania danych w celu ukrycia zawartości trzech kolumn. Zawartość CreditCard kolumny są częściowo odsłonięte. Co zostanie ujawnione w Phone kolumna pozostaje do dynamicznej maski danych. Domyślna kolumna ciągu to „xxxx”. Domyślna kolumna liczbowa to „0”. Email kolumna używa dynamicznej maski danych specjalnie dostosowanej do zawartości tej kolumny.

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

Korzystanie z isql program zawarty w naszej dystrybucji sterowników ODBC SQL Server, logujemy się za pomocą konta SQL Server, które nie ma uprawnień do przeglądania zawartości kolumny maskowanej:

$ /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] |
+----+-------+-----------+-------+---------------+

Następnie logujemy się na konto, które ma wystarczające uprawnienia:

$ /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] |
+----+-------+-----------+--------------+------------------------+

Obsługa JSON

JavaScript Object Notation (JSON) to format tekstowy, który ułatwia wymianę danych. Ponieważ coraz więcej programistów aplikacji przyjmuje JSON jako preferowany format danych, rośnie zapotrzebowanie na bazy danych przyjazne dla JSON. W rezultacie kilka baz danych NoSQL wybrało JSON jako podstawowy format danych. Jedną z takich baz danych jest MongoDB.

Na naszych maszynach testowych używaliśmy obsługi JSON SQL Server 2016 do wymiany danych między SQL Server i MongoDB.

Użyliśmy programu do kopiowania zbiorczego (bcp) zawartego w naszej dystrybucji sterownika ODBC SQL Server, aby wyeksportować utworzone wcześniej dane klientów w formacie JSON. (Polecenie bcp łączy się z serwerem SQL jako „sa”, dzięki czemu dane w maskowanych kolumnach są ujawniane.)

$ 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"}]

Następnie zaimportowaliśmy dane JSON do 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" }
>

Bezpieczeństwo na poziomie wiersza

Dzięki funkcji Row-Level Security, SQL Server 2016 może ograniczyć dostęp do danych wierszy na podstawie loginu SQL Server. Bezpieczeństwo na poziomie wiersza jest niewidoczne dla użytkowników SQL Server, nie są oni świadomi, że wiersze, których nie mają autoryzacji, są filtrowane z wyników zapytań.

Aby wypróbować tę funkcję z naszym sterownikiem ODBC SQL Server, odtworzyliśmy przykład zabezpieczeń na poziomie wiersza firmy Microsoft. Zrobiliśmy to w bazie danych, która miała użytkowników SQL Server o nazwach „Sales1” i „Sales2”, którzy mają SELECT przywileje.

Stworzyliśmy i wypełniliśmy tabelę danymi sprzedażowymi. SalesRep kolumna przechowuje nazwę użytkownika odpowiedniego przedstawiciela handlowego.

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

Zabezpieczenia na poziomie wiersza są implementowane za pomocą funkcji o wartości tabeli, która zwraca pojedynczy wiersz, jeśli użytkownik ma odpowiedni dostęp, lub nie ma wyników. W poniższym przykładzie funkcja o wartości tabeli zwraca wiersz, jeśli SalesRep kolumna jest taka sama, jak użytkownik wykonujący zapytanie.

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

Użyliśmy sterownika ODBC serwera SQL Server do połączenia się z bazą danych jako użytkownik Sales2. Zabezpieczenia na poziomie wiersza zapewniają, że ten użytkownik może zobaczyć tylko sprzedaż dokonaną przez użytkownika Sprzedaż2.

$ /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   |
+------------+----------+-----------+-------+
|            |          |           |       |
+------------+----------+-----------+-------+

W bazie danych R

Wraz z zakupem przez Microsoft Revolution Analytics, dostawcy oprogramowania i usług dla języka programowania R, są oni w stanie zintegrować R z SQL Server. SQL Server 2016 będzie pierwszą wersją bazy danych zawierającą R, umożliwiając uruchamianie kodu R w silniku bazy danych SQL Server.

Jeśli masz wcześniejszą wersję programu SQL Server, alternatywą jest wyodrębnienie danych z programu SQL Server do języka R przy użyciu ODBC. Pakiet RODBC zapewnia interfejs ODBC dla języka R. Zbudowaliśmy RODBC w oparciu o menedżera sterowników unixODBC zawartego w naszej dystrybucji sterownika SQL Server, a następnie pobraliśmy niektóre dane SQL Server z 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

  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Wskaźniki wydajności serwera SQL pozwalające wyprzedzić konkurencję

  2. Jak zwrócić przyrostowy numer grupy na grupę w SQL?

  3. Tabele SQL Server:jaka jest różnica między @, # i ##?

  4. Konwertuj format daty na format DD/MMM/RRRR w SQL Server

  5. Ustawienie limitu czasu dla SQL Server