Faça uma excursão do Access pelo SQL Server

Promova a continuidade dos negócios

Para a solução do Access, você deseja mantê-la em funcionamento com o mínimo de interrupções, mas as opções com um banco de dados back-end do Access são limitadas. Fazer backup do banco de dados do Access é essencial para proteger seus dados, mas isso exige que os usuários fiquem offline. Além disso, há um tempo de inatividade não planejado causado por atualizações de manutenção de hardware/software, interrupções de rede ou de energia, falhas de hardware, violações de segurança ou até mesmo ataques cibernéticos. Para minimizar o tempo de inatividade e o impacto na sua empresa, você pode fazer o backup de um banco de dados do SQL Server enquanto ele estiver em uso. Além disso, o SQL Server também oferece estratégias de alta disponibilidade (HA) e recuperação de desastres (DR). Essas duas tecnologias combinadas são chamadas de HADR. Para obter mais informações, confira Continuidade dos negócios e recuperação de banco de dados e Mantendo a continuidade dos negócios com o SQL Server (e-book).

Faça backup durante o uso

O SQL Server usa um processo de backup online que pode ocorrer enquanto o banco de dados está sendo executado. Você pode fazer um backup completo, um backup parcial ou um backup de arquivo. Um backup copia dados e logs de transação para garantir uma operação de restauração completa. Especialmente para soluções locais, esteja ciente das diferenças entre as opções de recuperação simples e completa e como elas afetam o crescimento do log de transações. Para mais informações, confira Modelos de Recuperação.

A maioria das operações de backup ocorre imediatamente, exceto as operações de gerenciamento de arquivos e de banco de dados. Por outro lado, se você tentar criar ou excluir um arquivo de banco de dados enquanto uma operação de backup estiver em andamento, a operação falhará. Para mais informações, confira Visão Geral do Backup.

HADR

As duas técnicas mais comuns para obter alta disponibilidade e continuidade de negócios são espelhamento e clustering. O SQL Server integra as tecnologias de espelhamento e clustering com "Sempre em Instâncias de Cluster de Failover" e "Sempre em Grupos de Disponibilidade".

O espelhamento é uma solução de continuidade a nível de banco de dados que oferece suporte a failover quase instantâneo, mantendo um banco de dados em espera, uma cópia completa ou um espelhamento do banco de dados ativo em hardware separado. Ele pode operar em um modo síncrono (alta segurança), no qual uma transação de entrada é comprometida a todos os servidores ao mesmo tempo, ou em um modo assíncrono (alto desempenho), em que uma transação de entrada é comprometida ao banco de dados ativo e, em seguida, em um ponto pré-determinado, copiada para o espelho. O espelhamento é uma solução a nível de banco de dados e funciona apenas com bancos de dados que usam o modelo de recuperação completa.

O clustering é uma solução a nível do servidor que combina servidores em um único armazenamento de dados que enxerga o usuário como uma única instância. Os usuários se conectam à instância e nunca precisam saber qual servidor da instância está ativo no momento. Se um servidor falhar ou precisar ser colocado offline para manutenção, a experiência do usuário não será alterada. Cada servidor no cluster é monitorado pelo gerenciador de cluster usando uma pulsação; portanto, ele detecta quando o servidor ativo no cluster fica offline e tenta alternar facilmente para o próximo servidor no cluster, embora haja um atraso de tempo variável durante a alternância.

Para obter mais informações, confira Instâncias de Cluster de Failover Always On e Grupos de disponibilidade Always On: uma solução de alta disponibilidade e recuperação de desastres.

Início da página

Segurança do SQL Server

Embora você possa proteger seu banco de dados do Access usando a Central de Confiabilidade e criptografando o banco de dados, o SQL Server possui recursos de segurança mais avançados. Vamos analisar três recursos que se destacam para o usuário do Access. Para obter mais informações, confira Protegendo o SQL Server.

Autenticação de banco de dados

Existem quatro métodos de autenticação de banco de dados no SQL Server, cada um dos quais você pode especificar em uma cadeia de conexão ODBC. Para obter mais informações, confira Vincular ou importar dados de um banco de dados do Azure SQL Server. Cada método tem seus próprios benefícios.

Autenticação integrada do Windows    Use credenciais do Windows para validação de usuário, funções de segurança e limitação de usuários a recursos e dados. Você pode aproveitar as credenciais de domínio e gerenciar facilmente os direitos de usuário em seu aplicativo. Opcionalmente, insira um Nome de Entidade de Serviço (SPNs). Para mais informações, confira Escolher um modo de autenticação.

Autenticação do SQL Server    Os usuários precisam se conectar com as credenciais que foram configuradas no banco de dados, digitando o ID de logon e a senha na primeira vez em que acessarem o banco de dados em uma sessão. Para mais informações, confira Escolher um modo de autenticação.

Autenticação integrada do Azure Active Directory    Conecte-se ao banco de dados SQL Server do Azure usando o Azure Active Directory. Depois de configurar a autenticação do Azure Active Directory, nenhum logon adicional e senha são necessários. Confira mais informações em Conectando-se ao banco de dados SQL por autenticação do Azure Active Directory.

Autenticação de Senha do Active Directory    Conecte-se com as credenciais definidas no Azure Active Directory inserindo o nome de logon e a senha. Confira mais informações em Conectando-se ao banco de dados SQL por autenticação do Azure Active Directory.

Dica    Use a Detecção de ameaças para receber alertas sobre atividades anômalas no banco de dados, indicando possíveis ameaças de segurança a um banco de dados do Azure SQL Server. Para obter mais informações, confira Detecção de ameaças do banco de dados SQL.

Segurança de aplicativos

O SQL Server tem dois recursos de segurança a nível de aplicativo que você pode aproveitar com o Access.

Mascaramento de Dados Dinâmicos    Ocultar informações confidenciais mascarando-as para usuários não privilegiados. Por exemplo, você pode mascarar os números da Previdência Social, parcial ou integralmente.

Uma máscara de dados parcial

Uma máscara de dados completa

Existem várias maneiras de definir uma máscara de dados, e você pode aplicá-las a diferentes tipos de dados. O mascaramento de dados é orientado por política a nível de tabela e coluna para um conjunto definido de usuários e é aplicado em tempo real para consulta. Para mais informações, confira Mascaramento de dados dinâmicos.

Segurança em nível de linha    Usando a Segurança em Nível de Linha, você pode controlar o acesso a linhas específicas do banco de dados com informações confidenciais, com base nas características do usuário. O sistema de banco de dados aplica essas restrições de acesso e isso torna o sistema de segurança mais confiável e robusto.

Existem dois tipos de predicados de segurança:

• Um predicado de filtro filtra linhas de uma consulta. O filtro é transparente e o usuário final não tem conhecimento de nenhuma filtragem.

• Um predicado de bloqueio evita ações não autorizadas e lança uma exceção se a ação não puder ser executada.

Para obter mais informações, confira Segurança em nível de linha.

Protegendo Dados com Criptografia

Proteja os dados em repouso, em trânsito e em uso sem afetar o desempenho do banco de dados. Para mais informações, confira Criptografia do SQL Server.

Criptografia em repouso    Para proteger dados pessoais contra ataques de mídia offline na camada de armazenamento físico, use a criptografia em repouso, também chamada de Transparent Data Encryption (TDE). Isso significa que seus dados estão protegidos, mesmo se a mídia física for roubada ou descartada indevidamente. A TDE executa criptografia e descriptografia em tempo real de bancos de dados, backups e logs de transações, sem exigir qualquer alteração em seus aplicativos.

Criptografia em trânsito    Para proteger contra intromissões e ataques “man-in-the-middle”, você pode criptografar dados transmitidos pela rede. O SQL Server oferece suporte a TLS (Transport Layer Security) 1.2 para comunicações altamente seguras. O protocolo TDS (Tabular Data Stream) também é usado para proteger as comunicações em redes não confiáveis.

Criptografia em uso no cliente    Para proteger dados pessoais durante o uso, “Always Encrypted” é o recurso ideal. Os dados pessoais são criptografados e descriptografados por um driver no computador cliente sem revelar as chaves de criptografia para o mecanismo do banco de dados. Como resultado, os dados criptografados só são visíveis para as pessoas responsáveis pelo gerenciamento desses dados, e não para outros usuários altamente privilegiados que não devem ter acesso. Dependendo do tipo de criptografia selecionada, Always Encrypted pode limitar algumas funcionalidades do banco de dados, como pesquisa, agrupamento e indexação de colunas criptografadas.

Início da página

Lidar com questões de privacidade

As preocupações com privacidade são tão comuns que a União Europeia definiu requisitos legais por meio do Regulamento Geral de Proteção de Dados (GDPR). Felizmente, um back-end do SQL Server é adequado para responder a esses requisitos. Pense em implementar o GDPR em uma estrutura de três etapas.

Passo 1: Avaliar e gerenciar o risco de conformidade

O GDPR exige que você identifique e inventarie as informações pessoais que você possui em tabelas e arquivos. Essas informações podem ser qualquer coisa, desde um nome, uma foto, um endereço de email, dados bancários, postagens em sites de redes sociais, informações médicas ou até mesmo um endereço IP.

A nova ferramenta de Desoberta e Classificação de Dados SQL, incorporada ao SQL Server Management Studio, ajuda você a descobrir, classificar, rotular e gerar relatórios sobre dados confidenciais, aplicando dois atributos de metadados a colunas:

• Rótulos    Para definir a sensibilidade dos dados.

• Tipos de informação    Para fornecer maior granularidade sobre os tipos de dados armazenados em uma coluna.

Outro mecanismo de descoberta que você pode usar é a pesquisa de texto completo, que inclui o uso dos predicados CONTAINS e FREETEXT e funções com valor de conjunto de linhas como CONTAINSTABLE e FREETEXTTABLE para uso com a instrução SELECT. Usando a pesquisa de texto completo, você pode pesquisar tabelas para descobrir palavras, combinações de palavras ou variações de uma palavra, como sinônimos ou flexões verbais. Para mais informações, confira Pesquisa de Texto Completo.

Passo 2: Proteger informações pessoais

O GDPR exige que você proteja informações pessoais e limite o acesso a elas. Além das etapas padrão que você toma para gerenciar o acesso à sua rede e recursos, como configurações de firewall, você pode usar os recursos de segurança do SQL Server para ajudá-lo a controlar o acesso a dados:

• Autenticação do SQL Server para gerenciar a identidade do usuário e impedir o acesso não autorizado.

• Segurança em nível de linha para limitar o acesso a linhas em uma tabela com base no relacionamento entre o usuário e esses dados.

• Mascaramento Dinâmico de Dados para limitar a exposição a dados pessoais, mascarando-os para usuários não privilegiados.

• Criptografia para garantir que os dados pessoais estejam protegidos durante a transmissão e o armazenamento e estejam protegidos contra comprometimentos, inclusive no lado do servidor.

Para mais informações, confira Segurança do SQL Server.

Etapa 3: Responda eficientemente às solicitações

O GDPR exige que você mantenha registros de processamento de dados pessoais e disponibilize esses registros para as autoridades de supervisão mediante solicitação. Se ocorrerem problemas, incluindo a liberação acidental de dados, os controles de proteção permitirão que você responda rapidamente. Os dados devem estar rapidamente disponíveis quando o relatório for necessário. Por exemplo, o GDPR exige que uma violação de dados pessoais seja informada à autoridade supervisora “em até 72 horas após ter tomado conhecimento desta”.

O SQL Server 2017 ajuda você a relatar tarefas de várias maneiras:

• Auditoria do SQL Server ajuda a garantir que existam registros persistentes de acesso ao banco de dados e atividades de processamento. Ela realiza uma auditoria detalhada que rastreia as atividades do banco de dados para ajudar você a entender e identificar possíveis ameaças, suspeitas de abuso ou violações de segurança. Você pode executar prontamente a perícia de dados.

• As tabelas temporais do SQL Server são tabelas de usuário com versão do sistema projetadas para manter um histórico completo de alterações de dados. Você pode usá-las para relatórios fáceis e análises pontuais.

• Avaliação de Vulnerabilidade SQL ajuda a detectar problemas de segurança e permissões. Quando um problema é detectado, você também pode fazer uma busca detalhada nos relatórios de verificação do banco de dados para localizar ações para resolução.

Para mais informações, confira Criar uma plataforma de confiança (e-book) e Uma jornada à conformidade com o GDPR.

Início da página

Crie instantâneos do banco de dados

Um instantâneo do banco de dados é uma exibição somente leitura e estática de um banco de dados do SQL Server em um determinado momento. Embora você possa copiar um arquivo de banco de dados do Access para criar efetivamente um instantâneo de banco de dados, o Access não tem uma metodologia interna como o SQL Server. Você pode usar um instantâneo do banco de dados para gravar relatórios com base nos dados no momento da criação do instantâneo do banco de dados. Você também pode usar um instantâneo de banco de dados para manter dados históricos, como um para cada trimestre financeiro usado para criar relatórios de fim de período. Recomendamos as seguintes práticas:

• Nomeie o instantâneo    Cada instantâneo do banco de dados requer um nome de banco de dados exclusivo. Adicione a finalidade e o prazo ao nome para facilitar a identificação. Por exemplo, para obter um instantâneo do banco de dados AdventureWorks três vezes por dia, em intervalos de 6 horas entre as 6h e as 18h com base em um relógio de 24 horas, nomeie-os como AdventureWorks_snapshot_0600, AdventureWorks_snapshot_1200 e AdventureWorks_snapshot_1800.

• Limite o número de instantâneos    Cada instantâneo do banco de dados persiste até que seja explicitamente descartado. Como cada instantâneo continuará a crescer, talvez você queira economizar espaço em disco excluindo um instantâneo mais antigo depois de criar um novo. Por exemplo, se você estiver fazendo relatórios diários, mantenha o instantâneo do banco de dados por 24 horas e, em seguida, descarte e substitua por um novo.

• Conecte-se ao instantâneo correto    Para usar um instantâneo de banco de dados, o front-end do Access precisa saber o local correto. Quando você substitui um novo instantâneo por um existente, é necessário redirecionar o acesso ao novo instantâneo. Adicione lógica ao front-end do Access para verificar se você está se conectando ao snapshot correto do banco de dados.

Veja como criar um instantâneo do banco de dados:

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;  

Para obter mais informações, confira Instantâneos do banco de dados (SQL Server).

Início da página

Controle de simultaneidade

Quando muitas pessoas tentam modificar dados em um banco de dados ao mesmo tempo, é necessário um sistema de controles para que as modificações feitas por uma pessoa não afetem adversamente as de outra pessoa. Isso é chamado de controle de simultaneidade e existem duas estratégias básicas de bloqueio, pessimistas e otimistas. O bloqueio pode impedir que os usuários modifiquem dados de uma maneira que afete outros usuários. O bloqueio também ajuda a garantir a integridade do banco de dados, especialmente com consultas que, de outra forma, podem produzir resultados inesperados. Existem diferenças importantes na maneira como o Access e o SQL Server implementam essas estratégias de controle de simultaneidade.

No Access, a estratégia de bloqueio padrão é otimista e concede a propriedade do bloqueio à primeira pessoa a tentar gravar em um registro. O Access exibe a caixa de diálogo Conflito de Gravação para a outra pessoa tentando gravar no mesmo registro ao mesmo tempo. Para resolver o conflito, a outra pessoa pode salvar o registro ou copiá-lo para a área de transferência, ou descartar as alterações.

Você também pode usar a propriedade RecordLocks para alterar a estratégia de controle de simultaneidade. Essa propriedade afeta formulários, relatórios e consultas, e possui três configurações:

• Sem proteção    Em um formulário, os usuários podem tentar editar o mesmo registro simultaneamente, mas a caixa de diálogo de Conflito de Gravação pode aparecer. Em um relatório, os registros não são bloqueados enquanto o relatório é visualizado ou impresso. Em uma consulta, os registros não são bloqueados enquanto a consulta é executada. Esta é a forma com que o Access implementa o bloqueio otimista.

• Todos os Registros    Todos os registros na tabela ou consulta subjacente se encontram bloqueados enquanto o formulário se encontra aberto no Modo Formulário ou Modo Folha de Dados, enquanto o relatório é visualizado ou impresso, ou enquanto a consulta é executada. Os usuários podem ler os registros durante o bloqueio.

• Registro Editado    Para formulários e consultas, uma página de registros é bloqueada assim que qualquer usuário começa a editar qualquer campo no registro, e permanece bloqueada até que o usuário passe para outro registro. Consequentemente, um registro pode ser editado por apenas um usuário por vez. Esta é a forma com que o Access implementa o bloqueio pessimista.

Para obter mais informações, confira Caixa de diálogo de Conflito de gravação e Propriedade RecordLocks.

No SQL Server, o controle de simultaneidade funciona da seguinte maneira:

• Pessimista    Depois que um usuário executa uma ação que faz com que um bloqueio seja aplicado, outros usuários não podem executar ações que entrariam em conflito com o bloqueio até que o proprietário o libere. Esse controle de simultaneidade é usado principalmente em ambientes onde há alta contenção de dados.

• Otimista    No controle de simultaneidade otimista, os usuários não bloqueiam dados quando os lêem. Quando um usuário atualiza dados, o sistema verifica se outro usuário alterou os dados após a leitura. Se outro usuário atualizou os dados, um erro será gerado. Normalmente, o usuário que recebe o erro reverte a transação e inicia novamente. Esse controle de simultaneidade é usado principalmente em ambientes onde há baixa contenção de dados.

Você pode especificar o tipo de controle de simultaneidade selecionando vários níveis de isolamento de transação, que definem o nível de proteção para a transação de modificações feitas por outras transações usando a instrução SET TRANSACTION:

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

Para obter mais informações, confira Bloqueio de transação e Guia de versão de linha.

Início da página

Melhore o desempenho da consulta

Depois de ter uma consulta de passagem do Access funcionando, aproveite as maneiras sofisticadas com que o SQL Server pode executá-la com mais eficiência.

Ao contrário de um banco de dados do Access, o SQL Server fornece consultas paralelas para otimizar a execução de consultas e operações de índice para computadores que possuem mais de um microprocessador (CPU). Como o SQL Server pode executar uma operação de consulta ou índice em paralelo usando diversos threads de trabalho do sistema, a operação pode ser concluída de maneira rápida e eficiente.

As consultas são um componente crítico para melhorar o desempenho geral da sua solução de banco de dados. Consultas inválidas são executadas indefinidamente, esgotam o tempo limite e usam recursos como CPUs, memória e largura de banda de rede. Isso dificulta a disponibilidade de informações críticas de negócios. Até mesmo uma consulta incorreta pode causar sérios problemas de desempenho no seu banco de dados.

Para obter mais informações, confira Consultas mais rápidas com o SQL Server (e-book).

Otimização de consulta

Várias ferramentas trabalham juntas para ajudar você a analisar o desempenho de uma consulta e a melhorá-la: Otimizador de Consultas, planos de execução e Repositório de Consultas.

Otimizador de consultas

O otimizador de consultas é um dos componentes mais importantes do SQL Server. Use o otimizador de consultas para analisar uma consulta e determinar a maneira mais eficiente de acessar os dados necessários. A entrada para o Query Optimizer consiste na consulta, no esquema do banco de dados (definições de tabela e índice) e nas estatísticas do banco de dados. A saída do otimizador de consultas é um plano de execução.

Para mais informações, confira o Otimizador de Consultas do SQL Server.

Plano de execução

Um plano de execução é uma definição que sequencia as tabelas de origem a serem acessadas e os métodos usados para extrair dados de cada tabela. Otimização é o processo de selecionar um plano de execução a partir de vários possíveis planos. Cada plano de execução possível tem um custo associado na quantidade de recursos de computação usados e o Otimizador de Consultas escolhe aquele com o menor custo estimado.

O SQL Server também deve se ajustar dinamicamente às mudanças de condições no banco de dados. Regressões em planos de execução de consulta podem afetar significativamente o desempenho. Certas mudanças em um banco de dados podem fazer com que um plano de execução seja ineficiente ou inválido, com base no novo estado do banco de dados. O SQL Server detecta as alterações que invalidam um plano de execução e marca o plano como não válido.

Um novo plano deve então ser recompilado para a próxima conexão que executa a consulta. As condições que invalidam um plano incluem:

• Alterações feitas em uma tabela ou exibição referenciada pela consulta (ALTER TABLE e ALTER VIEW).

• Alterações nos índices usados pelo plano de execução.

• Atualizações nas estatísticas usadas pelo plano de execução, geradas explicitamente a partir de uma instrução, como UPDATE STATISTICS, ou automaticamente.

Para mais informações, confira Planos de execução.

Repositório de Consultas

O Repositório de Consultas fornece informações sobre a escolha e o desempenho do plano de execução. Ele simplifica a solução de problemas de desempenho, ajudando você a encontrar rapidamente diferenças de desempenho causadas por alterações no plano de execução. A Loja de Consultas reúne dados de telemetria, como um histórico de consultas, planos, estatísticas de runtime e estatísticas de espera. Use a instrução ALTER DATABASE para implementar o Repositório de Consultas:

ALTER DATABASE AdventureWorks2012 SET QUERY_STORE = ON;

Para obter mais informações, confira Monitorando o desempenho usando o Repositório de Consultas.

ALTER DATABASE [YourDatabaseName] SET COMPATIBILITY_LEVEL = 140;

Formas de consultar

No SQL Server, existem várias maneiras de consultar, e cada uma delas tem seus benefícios. Você quer saber quais são elas, para poder fazer a escolha certa para sua solução do Access. A melhor maneira de criar suas consultas TSQL é editá-las e testá-las interativamente usando o editor Transact-SQL do SQL Server Management Studio (SSMS), que tem o intellisense para ajudá-lo a escolher as palavras-chave corretas e verificar erros de sintaxe.

Exibições

No SQL Server, uma exibição é como uma tabela virtual em que os dados da exibição são provenientes de uma ou mais tabelas ou outras exibições. No entanto, as exibições são referenciadas exatamente como as tabelas nas consultas. As exibições podem ocultar a complexidade das consultas e ajudar a proteger os dados, limitando o conjunto de linhas e colunas. A seguir, um exemplo de uma exibição simples:

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;

Para otimizar o desempenho e editar os resultados da visualização, crie uma visualização indexada, que persiste no banco de dados como uma tabela, tem armazenamento alocado para ela e pode ser consultada como qualquer tabela. Para usá-la no Access, crie um link para a exibição da mesma forma que você vincula a uma tabela. Este é um exemplo de uma exibição indexada:

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

No entanto, existem restrições. Não é possível atualizar dados se mais de uma tabela base for afetada ou se a exibição contiver funções agregadas ou uma cláusula DISTINCT. Se o SQL Server retornar uma mensagem de erro informando que não sabe qual registro excluir, talvez seja necessário adicionar um gatilho de exclusão na exibição. Por fim, você não pode usar a cláusula ORDER BY como pode com uma consulta do Access.

Para mais informações, confira Exibições e Criar exibições indexadas.

Procedimentos armazenados

Um procedimento armazenado é um grupo de uma ou mais instruções TSQL que recebem parâmetros de entrada, retornam parâmetros de saída e indicam sucesso ou falha com um valor de status. Eles atuam como uma camada intermediária entre o front-end do Access e o back-end do SQL Server. Os procedimentos armazenados podem ser tão simples quanto uma instrução SELECT ou tão complexos quanto qualquer programa. Aqui está um exemplo:

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;  

Quando você usa um procedimento armazenado no Access, ele geralmente retorna um conjunto de resultados para um formulário ou relatório. No entanto, ele pode realizar outras ações que não retornam resultados, como declarações DDL ou DML. Ao usar uma consulta de passagem, certifique-se de definir a propriedade Devolve Registros adequadamente.

Para mais informações, confira Procedimentos armazenados.

Common Table Expressions

Um Common Table Expressions (CTE) é como uma tabela temporária que gera um conjunto de resultados nomeado. Ele existe apenas para a execução de uma única consulta ou instrução DML. Um CTE é construído na mesma linha de código que a instrução SELECT ou a instrução DML que o utiliza, enquanto criar e usar uma tabela ou exibição temporária é geralmente um processo de duas etapas. Aqui está um exemplo:

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

Um CTE tem vários benefícios, incluindo o seguinte:

• Como os CTEs são temporários, você não precisa criá-los como objetos de banco de dados permanentes, como exibições.

• Você pode fazer referência ao mesmo CTE mais de uma vez em uma consulta ou instrução DML, tornando seu código mais gerenciável.

• Você pode usar consultas que fazem referência a um CTE para definir um cursor.

Para mais informações, confira WITH common_table_expression.

Funções Definidas pelo Usuário

Uma função definida pelo usuário (UDF) pode executar consultas e cálculos e retornar valores escalares ou conjuntos de resultados de dados. Elas são como funções em linguagens de programação que aceitam parâmetros, executam uma ação como um cálculo complexo e retornam o resultado dessa ação como um valor. Aqui está um exemplo:

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

As UDFs têm certas limitações. Por exemplo, elas não podem usar determinadas funções não determinísticas do sistema, executar instruções DML ou DDL ou fazer consultas SQL dinâmicas.

Para mais informações, confira Funções definidas pelo usuário.

Início da página

Adicionar chaves e índices

Independentemente de qual seja o sistema de banco de dados que você usa, chaves e índices andam de mãos dadas.

Chaves

No SQL Server, certifique-se de criar chaves primárias para cada tabela e chaves estrangeiras para cada tabela relacionada. O recurso equivalente no SQL Server para o tipo de dados AutoNumber do Access é a propriedade IDENTITY, que pode ser usada para criar valores de chave. Depois de aplicar essa propriedade a qualquer coluna numérica, ela se tornará somente leitura e será mantida pelo sistema de banco de dados. Ao inserir um registro em uma tabela que contém uma coluna IDENTITY, o sistema incrementa automaticamente o valor da coluna IDENTITY em 1 e iniciando em 1, mas você pode controlar esses valores com argumentos.

Para mais informações, confira CRIAR TABELA, IDENTIDADE (Propriedade).

Índices

Como sempre, a seleção de índices é um ato de equilíbrio entre a velocidade da consulta e o custo de atualização. No Access, você tem um tipo de índice, mas no SQL Server você tem doze. Felizmente, você pode usar o otimizador de consulta para ajudá-lo a escolher com segurança o índice mais eficaz. E no Azure SQL, você pode usar o gerenciamento automático de índices, um recurso de ajuste automático, o qual recomenda para você a adição ou remoção de índices. Ao contrário do Access, você deve criar seus próprios índices para chaves estrangeiras no SQL Server. Você também pode criar índices em uma exibição indexada para melhorar o desempenho da consulta. A desvantagem de uma exibição indexada é o aumento da sobrecarga quando você modifica os dados nas tabelas base da exibição, porque a exibição também deve ser atualizada. Para obter mais informações, confira Arquitetura e guia de design do SQL Server e índices.

Início da página

Realizar transações

Executar um Online Transaction Process (OLTP) é difícil ao usar o Access, mas é relativamente fácil com o SQL Server. Uma transação é uma única unidade de trabalho que confirma todas as alterações de dados quando bem-sucedida, mas reverte as alterações quando não bem-sucedida. Uma transação deve ter quatro propriedades, geralmente chamadas de ACID:

• Atomicidade    Uma transação deve ser uma unidade atômica de trabalho; todas as modificações de dados são executadas ou nenhuma é executada.

• Consistência    Quando concluída, uma transação deve deixar todos os dados em um estado consistente. Isso significa que todas as regras de integridade de dados são aplicadas.

• Isolamento    As alterações feitas por transações simultâneas são isoladas da transação atual.

• Durabilidade    Depois que uma transação é concluída, as alterações são permanentes, mesmo no caso de uma falha no sistema.

As transações são usadas para garantir a integridade de dados, como uma retirada de dinheiro de um caixa eletrônico ou um depósito automático de um cheque. Você pode fazer transações explícitas, implícitas ou com escopo de lote. Aqui estão dois exemplos de TSQL:

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

Para mais informações, confira Transações.

Início da página

Usando restrições e gatilhos

Todos os bancos de dados têm formas de manter a integridade dos dados.

Restrições

No Access, você aplica a integridade referencial em um relacionamento de tabela por meio de emparelhamentos de chave primária-chave estrangeira, atualizações e exclusões em cascata e regras de validação. Para obter mais informações, confira Guia para relações de tabela e Restringir entrada de dados usando regras de validação.

No SQL Server, você usa as restrições UNIQUE e CHECK, que são objetos de banco de dados que reforçam a integridade dos dados nas tabelas do SQL Server. Para validar que um valor é válido em outra tabela, use uma restrição de chave estrangeira. Para validar se um valor em uma coluna está dentro de um intervalo específico, use uma restrição de verificação. Esses objetos são sua primeira linha de defesa e são projetados para funcionar de maneira eficiente. Para mais informações, confira Restrições Exclusivas e Restrições de Verificação.

Gatilhos

O Access não possui gatilhos de banco de dados. No SQL Server, você pode usar gatilhos para impor regras complexas de integridade de dados e para executar essa lógica de negócios no servidor. Um acionador de banco de dados é um procedimento armazenado que é executado quando ações específicas ocorrem em um banco de dados. O gatilho é um evento, como adicionar ou excluir um registro em uma tabela, que é acionado e, em seguida, executa o procedimento armazenado. Embora um banco de dados do Access possa garantir a integridade referencial quando um usuário tenta atualizar ou excluir dados, o SQL Server possui um conjunto sofisticado de gatilhos. Por exemplo, você pode programar um gatilho para excluir registros em massa e garantir a integridade dos dados. Você pode até adicionar gatilhos a tabelas e exibições.

Para obter mais informações, confira Gatilhos - DML, Gatilhos - DDL e Projetando um gatilho T-SQL.

Início da página

Usar colunas computadas

No Access, você cria uma coluna calculada adicionando-a a uma consulta e criando uma expressão, como:

Extended Price: [Quantity] * [Unit Price]

No SQL Server, o recurso equivalente é chamado de coluna computada, que é uma coluna virtual que não é fisicamente armazenada na tabela, a menos que a coluna esteja marcada como PERSISTED. Como uma coluna calculada, uma coluna computada usa dados de outras colunas em uma expressão. Para criar uma coluna computada, adicione-a a uma tabela. Por exemplo:

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

Para obter mais informações, confira Especificar colunas computadas em uma tabela.

Início da página

Adicionar carimbo de data/hora aos dados

Às vezes, você adiciona um campo de tabela para inserir um carimbo de data/hora quando um registro é criado para que você possa registrar em log a entrada de dados. No Access, você pode simplesmente criar uma coluna de data com o valor padrão de =Now(). Para registrar uma data ou hora no SQL Server, use o tipo de dados datetime2 com o valor padrão de SYSDATETIME().

Observação    Evite confundir rowversion com a adição de um timestamp (carimbo de data/hora) aos seus dados. A palavra-chave timestamp é um sinônimo de rowversion no SQL Server, mas você deve usar a palavra-chave rowversion. No SQL Server, rowversion é um tipo de dados que expõe números binários exclusivos gerados automaticamente de um banco de dados, e é geralmente usado como um mecanismo para marcação de versão nas linhas da tabela. No entanto, o tipo de dados rowversion é apenas um número de incremento; ele não preserva uma data ou uma hora e tampouco é projetado para carimbo de data/hora em uma linha.

Para mais informações, confira rowversion. Para obter mais informações sobre como usar o rowversion para minimizar conflitos de registros, confira Migrar um banco de dados do Access para o SQL Server.

Início da página

Gerenciar objetos grandes

No Access, você gerencia dados não estruturados, como arquivos, fotos e imagens, usando o tipo de dados Anexo. Na terminologia do SQL Server, os dados não estruturados são chamados de Blob (Objeto Binário Grande) e existem várias maneiras de trabalhar com eles:

FILESTREAM    Usa o tipo de dados varbinary(max) para armazenar os dados não estruturados no sistema de arquivos em vez do banco de dados. Para obter mais informações, confira Acessar dados do FILESTREAM com o Transact-SQL.

FileTable    Armazena blobs em tabelas especiais chamadas FileTables e fornece compatibilidade com aplicativos do Windows como se eles estivessem armazenados no sistema de arquivos, sem fazer quaisquer alterações em seus aplicativos clientes. FileTable requer o uso de FILESTREAM. Para mais informações, confira FileTables.

Remote BLOB store (RBS)    Armazena objetos binários grandes (BLOBs) em soluções de armazenamento de mercadorias em vez de diretamente no servidor. Isso economiza espaço e reduz os recursos de hardware. Para obter mais informações, confira Dados de objeto binário grande (Blob).

Início da página

Trabalhar com dados hierárquicos

Embora os bancos de dados relacionais, como o Access, sejam muito flexíveis, o trabalho com relacionamentos hierárquicos é uma exceção e geralmente requer instruções ou códigos SQL complexos. Exemplos de dados hierárquicos incluem: uma estrutura organizacional, um sistema de arquivos, uma taxonomia de termos de um idioma e um gráfico de links entre páginas da Web. O SQL Server possui um tipo de dados hierarchyid interno e um conjunto de funções hierárquicas para armazenar, consultar e gerenciar facilmente dados hierárquicos.

Para mais informações, confira Dados hierárquicos e Tutorial: Usando o tipo de dados hierarchyid.

Início da página

Manipular o texto JSON

JavaScript Object Notation (JSON) é um serviço da Web que usa texto legível para transmitir dados como pares atributo-valor na comunicação assíncrona navegador-servidor. Por exemplo:

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

O Access não tem nenhuma maneira interna de gerenciar dados JSON, mas no SQL Server você pode armazenar, indexar, consultar e extrair dados JSON sem problemas. Você pode converter e armazenar texto JSON em uma tabela ou formatar dados como texto JSON. Por exemplo, você pode querer formatar os resultados da consulta como JSON para um aplicativo da Web ou adicionar estruturas de dados JSON em linhas e colunas.

Observação    O JSON não é suportado no VBA. Como alternativa, você pode usar XML no VBA usando a biblioteca MSXML.

Para mais informações, confira Dados JSON no SQL Server.

Início da Página

Recursos

Agora é um ótimo momento para aprender mais sobre o SQL Server e o Transact SQL (TSQL). Como você viu, há muitos recursos como os do Access, mas também há recursos que o Access simplesmente não possui. Para elevar seu aprendizado ao próximo nível, aqui estão alguns recursos:

Início da página