Introdução a Banco de Dados

Gustavo Aguilar
2022
SUMÁRIO
Capítulo 1. Introdução ao Mundo dos Dados ...................................................... 6

Dado, Metadado e Pirâmide do Conhecimento .............................................................. 6

Tipos de Dados .............................................................................................................................. 8

Perfis de Profissionais da Área de Dados ...................................................................... 12

Escalabilidade e Elasticidade .............................................................................................. 15

Tipos de Workloads de Dados ............................................................................................. 17

Capítulo 2. Introdução a Banco de Dados ......................................................... 24

Conceitos Básicos de Banco de Dados - Parte I......................................................... 24

Conceitos Básicos de Banco de Dados - Parte II....................................................... 26

Data Warehouse, Data Lake e Big Data .......................................................................... 29

Projeto de Banco de Dados .................................................................................................. 34

Capítulo 3. Sistemas Gerenciadores de Bancos de Dados ......................... 39

Antepassados dos SGBDs ..................................................................................................... 39

Características Gerais dos SGBDs..................................................................................... 41

Arquitetura ANSI/SPARC e Independência de dados ............................................. 43

Tipos de SGBDs .......................................................................................................................... 45

Tipos de Arquiteturas de SGBDs ....................................................................................... 49

Componentes e Funcionamento de um SGBD ............................................................ 51

Capítulo 4. Introdução a Banco de Dados Relacional ................................... 56

Teoria de Banco de Dados Relacional.............................................................................. 56

As 12 Regras de Codd ............................................................................................................. 60

As Propriedades ACID ............................................................................................................ 65

A Linguagem SQL...................................................................................................................... 66

Padronização da Linguagem SQL, Classes de Instruções SQL e Dialetos .... 72

Uma “Sopa de Letrinhas” ...................................................................................................... 75

2
Capítulo 5. Introdução ao Microsoft SQL Server ............................................ 81

Introdução ao SQL Server..................................................................................................... 81

Conceitos Básicos do SQL Server ...................................................................................... 82

Instalação do SQL Server...................................................................................................... 82

Capítulo 6. Ferramentas Client ............................................................................... 84

Ferramentas Client................................................................................................................... 84

Instalação e Overview do SQL Server Management Studio ................................. 90

Instalação e Overview do Azure Data Studio .............................................................. 90

Instalação e Overview do Banco de Dados de Exemplo AdventureWorks .... 90

Capítulo 7. Utilização Básica do SQL Server ..................................................... 94

Criação de Estruturas de Dados ......................................................................................... 95

Demonstração: Criação de Estruturas de Dados ........................................................ 97

Alteração de Estruturas de Dados .................................................................................... 97

Remoção de Estruturas de Dados ..................................................................................... 98

Selecionando Dados ................................................................................................................ 99

Demonstração: Selecionando Dados .............................................................................104

Ordenando Dados ...................................................................................................................104

Demonstração: Ordenando Dados ..................................................................................106

Filtrando Dados........................................................................................................................ 106

Demonstração: Filtrando Dados....................................................................................... 110

Inserindo Dados ......................................................................................................................110

Atualizando Dados .................................................................................................................114

Excluindo Dados ......................................................................................................................115

Capítulo 8. Segurança no SQL Server ............................................................... 120

Introdução à Segurança no SQL Server .......................................................................120

Concessão e Revogação de Privilégios .........................................................................122

3
Capítulo 9. Backup no SQL Server ...................................................................... 125

Conceitos Básicos de Backup............................................................................................ 125

Fazendo Backup no SQL Server ....................................................................................... 126

Referências ...................................................................................................................... 128

4
1
Capítulo 1. Introdução ao Mundo dos Dados
Dado, Metadado e Pirâmide do Conhecimento
Dados podem ser entendidos com uma coleção de fatos em uma
forma bruta ou desorganizada, como números ou caracteres. Dessa forma,
entende-se que está sendo feita referência a dados brutos (raw data), ou
seja, dados não tratados. Sem contexto, os dados normalmente têm pouco
significado. Por exemplo, 01102008 é apenas uma sequência de números
sem importância aparente.

Quando se fala em metadado, cujo prefixo “Meta” vem do grego e

significa “além de”, está se falando acerca dos dados para facilitar o
entendimento dos relacionamentos entre os dados, contribuindo para a
adição de contexto a eles. Nesse sentido, pode-se informar do que se trata
o dado: 01102008 ➔ “isso é uma data”.

Neste exemplo, olhando no contexto de 'esta é uma data', pode-se

facilmente reconhecer que está sendo feita referência a 01 de outubro de
2008. Dessa forma, ao adicionar contexto e valor aos números, eles passam
a ter mais significado. Tem-se então a possiblidade de geração de
informação, que são dados que foram processados de forma a facilitar a
visualização, medição e análise para um propósito específico. No nosso
exemplo, 01102008, ao ser processada dentro de um contexto, pode ser a
informação de uma data de casamento de algum casal.

Esses conceitos fundamentais de dados e informação fazem parte

das bases para a Pirâmide do Conhecimento, ou Pirâmide DIKW (Data-
Information-Knowledge-Wisdom), que se trata de uma hierarquia
informacional utilizada principalmente nos campos da Ciência da
Informação e da Gestão do Conhecimento. Nessa pirâmide, composta de
quatro camadas (dados, informação, conhecimento e sabedoria), cada uma
dessas camadas acrescenta certos atributos sobre a anterior.

6
 Figura 1 – Pirâmide do Conhecimento.

Fonte: o autor.

Como visto, os dados significam números, imagens, palavras etc. O

dado, visto como “matéria-prima”, é a base da pirâmide e se encontra em
estado bruto, não possuindo um significado em si, se analisado de forma
isolada. Entretanto, por estar na base dessa pirâmide e ser essencial para se
chegar ao topo dela, é considerado de extremo valor pelas organizações, na
era da informação em que vivemos.

As informações são simplesmente uma compreensão das relações

entre as partes dos dados, ou entre as partes dos dados e outras
informações. Embora a informação envolva a compreensão das relações
entre os dados, ela geralmente não explica quais motivos dos dados serem
o que são, e nem dá uma indicação de como os dados podem mudar ao longo
do tempo. Essa informação, vista como os dados que ganharam um
significado após terem sido analisados, processados ou relacionados,
normalmente respondem questões como “o quê?”, “quem?”, “onde?” ou
“quando?”.

Já o conhecimento tem o papel de acrescentar a forma de como usar

adequadamente a informação. Sendo visto então como informação que foi
enriquecida, sintetizada e/ou agrupada, responde a questões do tipo
“como?” e “por quê?”.

Quando esse conhecimento é concretizado e experienciado, tendo

sua aplicabilidade constatada, passa a ser visto como sabedoria. E é nesse

7
ponto da pirâmide que processos automatizados, robotizados ou de
inteligência artificial entram. Esses, possuindo insumos suficientes para
tomar uma decisão ou fazer um julgamento de uma determinada situação,
buscam para além disso, gerar mais sabedoria agregada dentro do
ecossistema em que estão inseridos.

Tipos de Dados
Quando se fala em dados estruturados por trás está implicitamente
envolvida a definição do modelo de dados, seja ele gráfico ou não. Essa
definição contém quais campos de dados serão provisionados, como esses
dados serão armazenados, ou seja, o tipo de dados dele (numérico, moeda,
alfabético, data, binário etc.) e quaisquer restrições na entrada de dados
(quantidade de caracteres, precisão, obrigatoriedade etc.). Com isso, pode-
se perceber que dados estruturados são aqueles organizados e
representados com uma estrutura rígida, a qual foi previamente planejada
para armazená-los (MONTEIRO, 2019). Nesse planejamento, um dos pontos
principais é definir acerca de cada campo de informação que o conjunto de
dados irá conter.

Para armazenamento de dados estruturados, existem diversos

recursos tecnológicos, como arquivos textos tabulados (flat files) e planilhas
eletrônicas, dentre os mais antigos, ou como as tabelas, nos famosos e
muito utilizados bancos de dados relacionais. Tanto para o armazenamento
em planilhas eletrônicas, quanto para o armazenamento em bancos de
dados relacionais, o formato utilizado é o tabular, onde os dados são
dispostos em linhas e colunas, em que um determinado registro é visto como
uma tupla (linha formada por uma lista ordenada de colunas).

8
 Figura 2 – Dados estruturados em flat files e em planilha eletrônica.

Fonte: o autor.

O formato de dados estruturados é o mais utilizado mundialmente,

apesar de se estimar que apenas entre 5 e 10% do volume total de
informações produzidas pela humanidade sejam estruturadas.

Já os dados não estruturados possuem uma estrutura interna, mas

não são estruturados por meio de modelos ou esquemas de dados
predefinidos, como explica TAYLOR (2018). Podem ser gerados por humanos
ou por máquinas, e um dos tipos mais comuns de dados não estruturados é
o texto. O texto não estruturado é gerado e coletado em uma ampla
variedade de formulários, incluindo documentos do Word, mensagens de e-
mail, apresentações em PowerPoint, respostas a pesquisas, transcrições de
gravações de atendimentos de call center e postagens em blogs e sites de
mídia social.

Dentre os outros tipos de dados não estruturados, podemos

encontrar arquivos de imagens, áudio e vídeo. Dados gerados por
equipamentos é uma outra categoria de dados não estruturados que cresce
exponencialmente ao longo do mundo. Nela encontra-se, por exemplo,
arquivos de log de sites, servidores, redes e aplicativos (principalmente os
móveis), os quais produzem uma grande quantidade de dados de atividade
e desempenho. Em outra categoria, podemos encontrar os dados não
estruturados gerados pelos sensores de equipamentos, satélites e outros
dispositivos conectados à Internet das Coisas (IoT).

9
 Figura 3 - Informações não estruturadas de relacionamentos em uma rede
social.

Fonte: iStock/aelitta, 2019.

Com o advento da Internet e redes sociais, o volume de dados não

estruturados se tornou o maior volume de dados produzido pela
humanidade, sendo que, até 2025, o IDG projeta que haverá 163 zettabytes
de dados no mundo, dos quais estima-se que 80% serão dados não
estruturados.

Entre os dados estruturados e os não estruturados surge o tipo de

dado semiestruturado, que não contém toda a rigidez requerida na
definição dos tipos de dados estruturados, mas que por outro lado procuram
manter certa uniformidade no armazenamento das informações. Para isso,
os dados semiestruturados mantêm tags e marcações internas que
identificam elementos de dados separados, o que permite o agrupamento e
formação de hierarquias de informações (TAYLOR, 2018).

A título de exemplo, podemos ter dados estruturados sendo

armazenados em formatos que possuem uma estrutura flexível, como os
formatos XML e JSON.

• Formato XML (Extensible Markup Language): estrutura orientada a

tags, altamente flexível e muito usado para transporte de dados na
Web.

10
 Figura 4 - Exemplo de formato XML.

Fonte: Joe Marini, 2019.

• Formato JSON (JavaScript Object Notation): um padrão aberto,

cuja estrutura consiste em armazenar dados em pares campo-valor
(filed : values).

Figura 5 - Exemplo de formato JSON.

Fonte: MongoDB, Inc., 2019.

Da mesma forma que os dados estruturados, os dados

semiestruturados correspondem ao menor volume de dados produzidos pela
humanidade, algo estimado entre 5 e 10%. Em plena “Era da Informação”, o
uso massivo de Internet banda larga, a computação ubíqua e a Internet das
Coisas (IOT), juntamente com o uso intensivo de redes sociais para
divulgação de informações e conteúdo, vemos um crescimento exponencial
do volume de dados, principalmente não estruturados (fotos, vídeos, posts,
likes, snaps etc.).

11
 Figura 6 - O que acontece em 1 minuto de Internet.

Fonte: Lori Lewis.

Perfis de Profissionais da Área de Dados

No contexto desse boom de informações, inúmeros tipos de dados e
soluções para trabalhar com estes dados, fica muito nítida a necessidade e
a grande importância do profissional de dados para projetar, implementar e
operar soluções que lidem com essa gama e volume de dados crescentes.

Na figura abaixo, pode-se ver as macro etapas de um processo de

construção de uma solução na área de dados.

Figura 7 - Processo macro de soluções de dados.

Fonte: o autor.

12
 Dentro do processo macro de planejamento, implantação e
gerenciamento de soluções de dados mostrado acima, pode-se perceber a
necessidade da participação dos seguintes perfis de profissionais de dados:

• Arquiteto de Soluções (Solutions Architect)

– Visão holística de toda a solução;

– Integração das soluções;

– Recursos, capacidade e custos da solução;

– Estratégias de backup, monitoramento;

– Disponibilidade e escalabilidade da solução;

– Plano de Continuidade de Negócio (PCN) etc.

• Arquiteto de Dados (Data Architect)

– Estruturas de armazenamento dos dados;

– Modelos de dados;

– Administração de dados corporativos;

– Backup de dados de negócio.

• Administrador de Banco de Dados (Database Administrator - DBA)

– Instalação / aprovisionamento / disponibilidade de sistemas

gerenciadores de bancos de dados, plataformas de
armazenamento de dados etc.;

– Aspectos operacionais;

– Ajustes finos (tunning) e troubleshooting (resolução de

problemas);

13
 – Segurança de acesso.

• Engenheiro de Dados (Data Engineer)

– Projeto do Pipeline (fluxo) de Dados: extração de dados,

transformação de dados e ingestão (carga) de dados;

– Implementação e gerenciamento do fluxo de dados

estruturados e não estruturados de diversas origens (fontes
de dados).

• Analista de Dados (Data Analyst)

– Projetar e construir modelos de dados analíticos;

– Transformar dados em informações analíticas com valor

comercial;

– Planejamento e gerenciamento de dashboards.

• Cientista de Dados (Data Scientist)

– Análise avançada para ajudar a gerar valor a partir dos dados;

– Análise Descritiva: Análise Exploratória de Dados (EDA);

– Análises Preditivas: com aprendizagem de máquina

(Machine Learning);

– Suporte a decisões orientadas a dados (Data-Driven

Decision).

• Engenheiro de Inteligência Artificial

– Arquitetar e implementar soluções de IA: serviços

cognitivos, Machine Learning, mineração de conhecimento
etc.;

14
 – Suporte a soluções de processamento de linguagem natural,
reconhecimento de voz e imagem;

– Bots e agentes virtuais.

Figura 8 – Papéis no processo macro de soluções de dados.

Arquiteto de Soluções Adm. Banco de Dados Engenheiro Analista de Dados

Arquiteto de Dados Adm. Big Data de Dados Cientista de Dados
Engenheiro de IA

Projetar a solução Implantar a infraestrutura Implantar o Análise de Dados

para a solução processo Ciência de Dados
(pipeline) de Aprendizado de
dados Máquina
Etc.

Fonte: o autor.

Escalabilidade e Elasticidade
Escalabilidade é a capacidade de escalar um ambiente, ou seja, de
adicionar mais recursos computacionais a ele, tais como:

✓ Poder de processamento (CPU)

✓ Cache (memória RAM)

✓ Capacidade de armazenamento (disco)

✓ Velocidade de transmissão (network)

✓ Nós de processamento (worker node)

✓ Nós de armazenamento (data node)

A escalabilidade pode ser feita de forma transparente (sem

indisponibilidade / degradação do ambiente) ou não. Com relação à forma, a
escalabilidade pode ser vertical ou horizontal.

15
 Na escalabilidade vertical, adiciona-se mais recursos (CPU, RAM etc.)
aos integrantes do ambiente, sem alterar a quantidade de integrantes do
ambiente. Ela é também chamada de scale up.

Figura 9 – Escalabilidade vertical.

Fonte: Microsoft.

Já na escalabilidade horizontal, a estratégia é adicionar novos

integrantes ao ambiente, ou seja, há uma alteração (para mais) na
quantidade de integrantes do ambiente.

Figura 10 – Escalabilidade horizontal.

Fonte: Microsoft.

Outro conceito importante, relacionado com a escalabilidade, é a

elasticidade. Ela representa a capacidade de aumentar e reduzir
rapidamente os recursos computacionais de um ambiente, sendo que para
isso requer a escalabilidade vertical ou a horizontal.

Com a elasticidade, foi introduzido o conceito de computação

elástica, que é a capacidade de aumentar ou reduzir rapidamente os
recursos de armazenamento, memória e processamento do computador
para atender às exigências dinâmicas sem se preocupar tanto com a
assertividade no planejamento de capacidade de recursos para os picos de

16
uso. Normalmente controlada por ferramentas de monitoramento de
sistema, a computação elástica utiliza-se do conceito de auto scalling para
ajustar a quantidade de recursos alocados à quantidade de recursos
realmente necessários, sem interromper as operações.

Figura 11 – Exigências dinâmicas de capacidade.

Fonte: AWS.

Tipos de Workloads de Dados

Workload ou carga de trabalho é a quantidade de processamento
que determinados recursos computacionais recebem para ser executado em
um determinado momento. Pode ser um simples despertador ou aplicativo
de contato em execução em um smartphone, ou um aplicativo corporativo
complexo hospedado em um ou mais servidores com milhares de sistemas
cliente (usuário) conectados e interagindo com os servidores de aplicativos
em uma rede geográfica.

As cargas de trabalho são definidas por três propriedades:

• Tempo de Resposta: o tempo entre uma solicitação e uma resposta;

• Taxa de Transferência: quanto trabalho é realizado durante um

período de tempo;

• Tipo de Workload: forma e frequência como a carga de trabalho é

executada.

Existem várias classificações de tipos de workload, mas na área de

dados, a mais comum é:

17
 • TRANSACIONAL: baseado em transações (unidade de trabalho
pequena e discreta) e também conhecido como OLTP (Online
Transactional Processing);

• ANALÍTICO: voltado para cenários de análises de dados oriundos de

diversas fontes e também conhecido OLAP (Online Analytical
Processing).

Figura 12 – Típico workload OLAP.

Fonte: Microsoft.

O workload OLAP pode acontecer de duas formas: BATCH e

STREAMING.

• BATCH: dados são coletados em um grupo, e todo o grupo é então

processado em um momento futuro como um lote.

✓ Grandes volumes de dados podem ser processados em um

momento conveniente;

✓ Ele pode ser programado para ser executado em um momento

em que os computadores ou sistemas possam estar ociosos,
como durante a noite ou fora do horário de pico.

18
 Um exemplo de uso eficaz do processamento em lote seria uma
conexão com um sistema mainframe. Grandes quantidades de dados
precisam ser transferidas para um sistema de análise de dados e os dados
não são em tempo real. Um exemplo de processamento em lote ineficaz
seria transferir pequenas quantidades de dados em tempo real, como um
ticker financeiro.

Figura 13 – Workload batch.

Fonte: Microsoft.

As desvantagens do processamento batch (em lote) incluem:

✓ O atraso de tempo entre a ingestão dos dados e a obtenção dos

resultados;

✓ Todos os dados de entrada de uma tarefa em lote devem estar

prontos antes que um lote possa ser processado. Isso significa
que os dados devem ser verificados cuidadosamente. Problemas
com dados, erros e travamentos do programa que ocorrem durante
as tarefas em lote interrompem todo o processo.

• STREAMING: cada novo dado é processado quando chega.

O streaming lida com dados em tempo real. Ao contrário do

processamento em lote, não há espera até o próximo intervalo de
processamento em lote e os dados são processados como peças individuais,
em vez de serem processados em um lote de cada vez. O processamento de
dados de streaming é benéfico na maioria dos cenários em que dados novos
e dinâmicos são gerados continuamente.

19
 Figura 14 – Workload de streaming.

Fonte: Microsoft.

O processamento de fluxo é ideal para operações de tempo crítico

que requerem uma resposta instantânea em tempo real. Por exemplo, um
sistema que monitora a fumaça e o calor de um prédio, que precisa disparar
alarmes e destrancar portas para permitir que os residentes escapem
imediatamente em caso de incêndio.

Para distinguir os worloads OLAP (Batch x Streaming), há quatro

aspectos marcantes em cada um deles:

• Escopo dos dados:

– Batch: pode processar todos os dados do conjunto de

dados.

– Streaming: normalmente só tem acesso aos dados

mais recentes recebidos, ou dentro de uma janela de
tempo (os últimos 30 segundos, por exemplo).

• Tamanho dos dados:

– Batch: lida com grandes conjuntos de dados de forma

eficiente.

– Streaming: destinado a registros individuais ou micro

lotes compostos de poucos registros.

20
 • Desempenho:

– Batch: a latência é normalmente de algumas horas.

– Streaming: o processamento normalmente ocorre

imediatamente, com latência da ordem de segundos ou
milissegundos.

• Análise:

– Batch: análises complexas.

– Streaming: respostas simples, agregações ou cálculos,

como média e desvio padrão.

Com relação à escalabilidade, para os workloads BATCH ela pode ser

programada, uma vez que esse tipo de carga é costumeiramente executado
em janelas previamente disponíveis. Já para os workloads STREAMING e
OLTP, a escalabilidade acontece sobre demanda, sendo imprescindível o
emprego da elasticidade.

Figura 15 – Escalabilidade em workloads batch.

Fonte: o autor.

21
 Figura 16 – Escalabilidade em workloads OLTP / STREAMING.

Fonte: o autor.

Olhando para a escalabilidade vertical, temos um cenário mais

centralizado e circunscrito às tecnologias de hardware / software para
alcançar o objetivo: adicionar mais poder de processamento aos
componentes do ambiente. Entretanto, quando nos deparamos com a
necessidade de escalar horizontalmente, é preciso combinar outras técnicas
e conceitos, como a de sistemas distribuídos, para que o objetivo seja
alcançado: adicionar mais integrantes ao ambiente.

22
2
Capítulo 2. Introdução a Banco de Dados
Conceitos Básicos de Banco de Dados - Parte I
Recapitulando que um dado é algo que qualifica ou é qualificado,
quantifica ou é quantificado, que pode ser registrado, que contém um fato
com significado implícito, sendo uma característica, elemento ou
quantidade conhecida.

Nesse sentido, um banco de dados é definido como “uma coleção de

dados inter-relacionados, representando informações sobre um domínio
específico” (KORTH, 1994, p.1) ou simplesmente “uma coleção de dados
relacionados” (ELMASRI; NAVATHE, 2011, p.4).

Dessa forma, podemos encontrar duas categorias de bancos de

dados:

• Bancos de dados manuais: não possuem tecnologia de automação

para inclusão, exclusão e manutenção dos dados, sendo essas
atividades feitas manualmente.

• Banco de dados computacional: possui programas que realizam as

tarefas de inclusão, exclusão e manutenção dos dados, sendo esses
programas chamados de Sistema Gerenciador de Banco de Dados
(SGBD).

Assim sendo, um SGBD é uma coleção de programas, ou seja, um

software, que permite aos usuários criar e manter um banco de dados. De
uma forma mais detalhada, é “um sistema de software de propósito geral
que facilita os processos de definição, construção, manipulação e
compartilhamento de bancos de dados entre vários usuários e aplicações”
(ELMASRI; NAVATHE, 2011, p.4).

24
 Os SGBDs podem ser de variados tipos, sendo os mais conhecidos os
relacionais e os não relacionais (NOSQL).

Já um Sistema de Banco de Dados faz referência ao ecossistema

formado pelo SGBD, o(s) banco(s) de dados, todos os dados manipulados e
armazenados, além das aplicações que usam o banco de dados para inserir,
alterar, excluir ou consultar dados.

Figura 17 – Sistema de Banco de Dados.

Fonte: o autor.

Quando se fala de Instância de Banco de Dados está se fazendo

referência ao processo do mecanismo de banco de dados (SGBD) executado
como um serviço do sistema operacional. Cada instância pode gerenciar um
ou mais bancos de dados dos aplicativos. Nesse sentido, primeiramente
instala-se o software do sistema gerenciador de banco de dados no servidor
e cada execução desse software (binário) será uma instância consumindo
recursos (memória, CPU e disco) do servidor. Para além disso, cada servidor
pode executar várias instâncias e os aplicativos se conectam à instância
para executar trabalhos em um banco de dados gerenciado pela instância.

25
 Figura 18 – Processos de duas instâncias rodando em um servidor.

Fonte: o autor.

Fonte: o autor.

Conceitos Básicos de Banco de Dados - Parte II

Dentro de cada banco de dados, para se armazenar os dados, é usada
uma estrutura de armazenamento. Como exemplo, temos a tabela para
armazenar dados em um banco de dados de um sistema gerenciador de
banco de dados relacional.

Figura 19 – Listagem de tabelas no SQL Server.

Fonte: o autor.

Cada tipo de SGBD fornece estruturas de armazenamento

adequadas para cada tipo de dado. Dessa forma, os bancos de dados
relacionais disponibilizam as tabelas para armazenar dados estruturados.

26
 Figura 20 – Dados estruturados em uma tabela no SQL Server.

Fonte: o autor.

Para a especificação da forma de como o banco de dados deve ser

estruturado e as regras que deve seguir, é necessário primeiramente definir
seu esquema de dados, como no exemplo mostrado abaixo.

➢ Funcionario (nome, sexo, endereço)

✓ Nome ➔ string de 100 caracteres;

✓ Sexo ➔ string de 1 caractere;

✓ Endereço ➔ string de 200 caracteres.

Ao criar o esquema de dados em um SGBD específico, está se

fazendo a definição do esquema físico. O esquema físico representa o
esquema de dados com os tipos de dados, propriedades e regras aplicáveis
ao SGBD em questão.

27
 Figura 21 – Amostra de parte de um esquema físico no SQL Server.

Fonte: o autor.

Para interagir com o banco de dados, seu esquema físico e os dados

propriamente ditos, os SGBDs fornecem uma Linguagem de Consulta.
Falando-se de bancos de dados relacionais, encontraremos em cada banco
de dados uma implementação da linguagem SQL (Structured Query
Language / Linguagem de Consulta Estruturada).

Figura 22 – Query escrita na linguagem SQL no SQL Server.

Fonte: o autor.

Para o planejamento do esquema de dados, de quais dados

precisarão ser armazenados, o relacionamento entre eles e a especificação
do esquema físico, é utilizado um modelo de dados. Como definido por

28
Paulo Cougo (1997), um modelo de dados é uma “representação abstrata e
simplificada dos dados de um sistema real, com a qual se pode explicar ou
testar o seu comportamento, em seu todo ou em partes”.

Figura 23 – Exemplo de modelo de dados.

Fonte: o autor.

Data Warehouse, Data Lake e Big Data

Um outro conceito importantíssimo de se conhecer é o de Data
Warehouse. Ao pé da letra, é traduzido como sendo um armazém de dados,
consistindo em um “depósito de dados orientado por assunto, integrado,
não volátil, variável com o tempo, para apoiar as decisões gerenciais” (Date,
2004).

Um data warehouse centraliza e consolida dados de várias fontes,

contém grandes quantidades de dados históricos e geralmente inclui os
seguintes elementos:

✓ Banco de dados relacional para armazenar e gerenciar dados

(estruturados);

✓ Uma solução de extração, carregamento e transformação (ELT)

para preparar os dados para análise;

29
 ✓ Análise estatística, relatórios e recursos de mineração de
dados;

✓ Ferramentas de análise de clientes para visualizar e apresentar

dados aos usuários de negócios.

Figura 24 – Exemplo de modelo de dados.

Fonte: www.astera.com.

Em plena era da Internet das Coisas (IOT), o crescimento do

armazenamento e processamento de dados não estruturados e a utilização
de soluções de Big Data são cada vez mais uma vertente exponencial e sem
volta.

Figura 25 – Crescimento anual do volume de dados produzido pela humanidade.

Fonte: Seagate.

30
 O Gartner define Big Data como “ativos de informações de grande
volume, alta velocidade e/ou alta variedade que exigem formas inovadoras e
de baixo custo de processamento de informações, que permitem uma visão
aprimorada, tomada de decisão e automação de processos”:

Termo adotado pelo mercado para descrever problemas no

gerenciamento e processamento de informações extremas, as
quais excedem a capacidade das tecnologias de informações
tradicionais ao longo de uma ou várias dimensões. (Gartner
Group)

Big Data está focado principalmente em questões de volume

de conjunto de dados extremamente grandes gerados a partir
de práticas tecnológicas, tais como mídia social, tecnologias
operacionais, acessos à Internet e fontes de informações
distribuídas. Big Data é essencialmente uma prática que
apresenta novas oportunidades de negócios. (Gartner Group)

Tendo como gatilho a intensa utilização de redes sociais on-line, de

dispositivos móveis para conexão à Internet, transações e conteúdos
digitais, e também o crescente uso da computação em nuvem, Big Data, em
resumo, pode ser visto como um imenso “conjunto de dados cujo
crescimento é exponencial e cuja dimensão está além das habilidades das
ferramentas típicas de capturar, gerenciar e analisar dados” (McKinsey
Global Institute, 2011):

A intensa utilização de redes sociais online, de dispositivos

móveis para conexão à Internet, transações e conteúdos
digitais, e também o crescente uso de computação em nuvem
tem gerado quantidades incalculáveis de dados. O termo Big
Data refere-se à este conjunto de dados cujo crescimento é
exponencial e cuja dimensão está além da habilidade das
ferramentas típicas de capturar, gerenciar e analisar dados.
(McKinsey Global Institute)

31
 Em sumo, Big Data é um campo ou área que trata de maneiras de
analisar, extrair sistematicamente informações ou, de outra forma, lidar com
conjuntos de dados que são muito grandes ou complexos para serem
tratados por softwares de aplicativos de processamento de dados
tradicionais. Big Data é mais que um produto de software ou hardware. É um
conjunto de tecnologias, processos e práticas que permitem às empresas
analisarem dados que antes não tinham acesso e tomar decisões, ou mesmo
gerenciar atividades de forma muito mais eficiente.

Os principais fundamentos de Big Data podem ser resumidos, de

forma bem macro, no que o mercado chama de “7 Vs”:

✓ VOLUME: a quantidade de dados gerados, que costumava ser

medida em Gigabytes agora é medida em Zettabytes (ZB),
caminhando para Yottabytes (YB).

✓ VELOCIDADE: velocidade em que os dados são gerados e se tornam

acessíveis.

✓ VARIEDADE: de formatos, de tipos (estruturado, não estruturado e

semiestruturado), e da natureza (numérica, data, caractere etc.).

✓ VARIABILIDADE: mesma combinação de dados cujo significado

muda constantemente.

✓ VERACIDADE: garantir que os dados sejam precisos, verdadeiros,

fidedignos.

✓ VISUALIZAÇÃO: formas mais aderentes para visualizar grandes

quantidades de dados complexos.

✓ VALOR: transformar dados em valor, vantagem competitiva ou

otimização operacional.

32
 Figura 26 – Os 7Vs do Big Data.

Fonte: Khan et al. (2017). Adaptação Vinicios (2019).

Com essa enorme variedade de dados, volume e diversidade de

origem, surgiu o conceito de Data Lake para designar um repositório
centralizado projetado para armazenar, processar e proteger grandes
quantidades de dados estruturados, semiestruturados e não estruturados.

Figura 27 – Data Lake.

Fonte: Diego Mota (www.medium.com).

33
 Usando-se serviços de nuvem, as tecnologias e conceitos de data
warehouse e data lake ganharam uma amplitude e atualmente temos o
conceito de Data Warehouse Moderno (MDW). Nesse viés, um MDW utiliza
recursos em nuvem para reunir facilmente, e em tempo mais ágil, todos os
dados em qualquer escala, sejam estruturados, não estruturados ou
semiestruturados. Com isso, traz agilidade, escalabilidade, facilidade, mais
performance e redução expressiva de custos operacionais, além de permitir
insights para tomada de decisões de negócios mais rápidas.

Figura 28 – Arquitetura de referência de um MDW no Azure.

Fonte: Microsoft.

Projeto de Banco de Dados

Voltando na questão da Pirâmide do Conhecimento, mais
especificamente nos seus dois níveis da base (dado e informação), percebe-
se nitidamente a importância de um modelo de dados que seja capaz de
prever todos os dados brutos necessários, além de explicar os
relacionamentos e inferências entre eles, para que seja possível prover
insumos consistentes para a geração de conhecimento e sabedoria.

34
 E como começar a construir um modelo de dados? Entendendo quais
etapas são necessárias para um projeto de banco de dados e quais os
insumos e produto final de cada uma delas. Nesse ínterim, o ponto chave, e
de partida, é iniciar o processo de modelagem de dados. De uma forma
geral, o processo de modelagem de dados pode ser pensado em quatro
grandes etapas:

i. Descrição do minimundo;

ii. Modelagem Conceitual;

iii. Modelagem Lógica;

iv. Modelagem Física.

Para iniciar uma modelagem de dados é fundamental a definição do

minimundo, ou seja, a porção da realidade a ser analisada, seus requisitos e
regras de funcionamento, suas interações internas e interações com o
mundo externo.

Figura 29 – Etapas tradicionais de um projeto de banco de dados.

Fonte: o autor.

35
 Na prática, essa definição é feita com uma entrevista e coleta de
informações. O resultado, ou seja, o minimundo, nada mais é do que uma
descrição textual ou gráfica acerca do entendimento das regras do seu
funcionamento e dos dados fundamentais.

Se estamos diante, por exemplo, da modelagem de dados para um

sistema de atendimento em um consultório de Dermatologia, o minimundo
a ser observado vai desde o fluxo da marcação / remarcação de consultas,
passando pelo dia a dia das secretárias, médicos, até o arquivamento quando
da conclusão do tratamento do paciente.

Dessa forma, de maneira macro, a descrição do minimundo do

exemplo em questão seria algo como:

Na clínica de Dermatologia ‘NewDermo’, as consultas são marcadas pelo site ou pelo

0800 com as secretárias, podendo ser remarcadas com até 24 horas de antecedência.
O paciente deve fazer um cadastro prévio com seus dados básicos (nome completo,
data nascimento, endereço, CPF, telefone e e-mail), para que o sistema gere seu login
e senha de acesso (tanto pelo 0800 ou pelo site), o que permitirá a consulta de todas
as informações do seu tratamento de forma on-line. A clínica realiza atendimentos
particulares e através de convênios médicos, previamente cadastrados. Para realizar
a marcação da consulta, o paciente precisa informar se a consulta será particular ou
via convênio. Dois dias antes da data e hora da consulta, o sistema envia um lembrete
para o paciente, via e-mail e SMS. O paciente, ao chegar na clínica, faz o seu check-in
com a secretária, fornecendo a documentação necessária para a consulta, seja ela
particular ou via convênio. A tolerância máxima de atraso para o check-in é de 10
minutos após o horário marcado. Consultas emergenciais (sem agendamento) só são
possíveis se houver horário livre na agenda dos médicos. Se o paciente ainda não tiver
ficha na clínica, a secretária fará o seu cadastro na hora. O sistema chama os
pacientes automaticamente no painel da clínica, após o médico concluir o
atendimento anterior e acionar o botão de chamar próximo paciente. Todas as
informações da consulta são registradas no sistema e contém detalhes do
atendimento, como relato inicial do paciente, diagnóstico, receita de remédios,
tratamento, retorno, fotos do antes, durante e depois do tratamento etc.

36
 Na etapa de descrição do minimundo, já vimos que o objetivo é
entender essa porção da realidade, seus requisitos e regras de
funcionamento, suas interações internas e interações com o mundo externo.
Essa etapa é a que possui o maior grau de abstração, não se preocupando
com os detalhes de modelagem (se é relacional, não-relacional etc.),
armazenamento (estruturado, não estrutura etc.) ou da tecnologia a ser
usada (SQL Server, MongoDB, Oracle, Hadoop, Fileshare etc.).

Nas etapas seguintes, o nível de abstração é inversamente

proporcional ao nível de detalhes, ou seja, quanto mais se aumenta o nível
de detalhes dos dados, dos relacionamentos e das regras, menos se tem
abstração.

Figura 30 – Níveis de Abstração x Níveis de Detalhes.

Fonte: o autor.

37
3
Capítulo 3. Sistemas Gerenciadores de Bancos de Dados
Antepassados dos SGBDs
Um dos principais antepassados dos SGBDs é o Sistema de Cartão
Perfurado. Um cartão perfurado é um pedaço de papel rígido que contém
dados digitais representados pela presença ou ausência de furos em
posições pré-definidas;

Figura 31 – Cartão perfurado.

Fonte: Museu do Computador & Futuro da Tecnologia.

O sistema de cartão perfurado foi inventado por Herman Hollerith,

no final de 1800, tendo desenvolvido, na sequência, a tecnologia de
processamento de dados de cartão perfurado para o Censo dos EUA de 1890.

Apesar de todos os benefícios na época, o sistema de cartão

perfurado tinha vários problemas e limitações, como por exemplo:

✓ Armazenamento de dados mais simples e em menor volume;

✓ Durabilidade do meio físico de armazenamento;

✓ Tempo de processamento etc.

39
 Um dos principais sucessores do sistema de cartão perfurados é o
Sistema de Arquivos. Um arquivo de computador é um recurso para
armazenamento de dados, que está disponível a um programa de
computador e é normalmente baseado em algum tipo de armazenamento
durável.

Figura 32 – Exemplo de arquivo texto aberto no Bloco de Notas do Windows.

Fonte: o autor.

Dessa forma, o sistema de arquivos é um sistema utilizado para

armazenar, organizar e acessar dados em um computador de forma efetiva.
Os dispositivos que utilizam sistemas de arquivos são discos rígidos, mídias
ópticas como CDs e DVDs, cartões de memória e pendrives (flash drives) e
discos flexíveis (disquetes), dentre outros. De uma forma geral, ele permite
o armazenamento organizado de arquivos, agregando características a cada
arquivo como um nome e permissões de acesso.

Apesar de todos os avanços em relação ao sistema de cartão

perfurado, o sistema de arquivos também tinha problemas e limitações,
como por exemplo:

✓ Redundância de dados: mesma informação repetida em arquivos

diferentes;

✓ Inconsistência de dados: as várias cópias dos dados podem divergir

ao longo do tempo;

40
 ✓ Dificuldade de acesso aos dados: acesso sequencial;

✓ Isolamento de dados: dados espalhados em diversos arquivos e

dificuldade para fazer cruzamento de dados;

✓ Desperdício de espaço de armazenamento;

✓ Problemas de integridade: como garantir que determinados valores

dos campos satisfaçam certas restrições?

✓ Problemas de atomicidade: uma operação atômica deve ocorrer por

completo ou não ocorrer;

✓ Problemas no acesso concorrente: a interação entre atualizações

concorrentes pode resultar em inconsistência dos dados;

✓ Linguagem de consulta não amigável;

✓ Problemas de segurança: como garantir o controle de acesso aos

dados via permissões aos usuários?

Nesse cenário temos a invenção dos sistemas gerenciadores de

bancos de dados na tentativa de endereçar todos esses problemas e trazer
novas facilidades para os desenvolvedores e profissionais da área de dados.

Características Gerais dos SGBDs

Recapitulando que um SGBD é uma coleção de programas, ou seja,
um software, que permite aos usuários criar e manter um banco de dados,
pode-se listar que esse software deve possuir os seguintes propósitos:

✓ Armazenar os dados de forma protegida contra acessos indevidos e

contra danos ou perdas;

✓ Disponibilizar os dados de forma fácil e rápida;

✓ Isolar os usuários dos detalhes mais internos do banco de dados;

41
✓ Prover independência de dados (lógica e física) para as aplicações;

✓ Reduzir / eliminar redundância e inconsistência de dados;

✓ Reduzir a perda de espaço de armazenamento;

✓ Garantir a integridade dos dados;

✓ Possibilitar rapidez no acesso / manipulação do dado através de uma

linguagem de consulta;

✓ Reduzir esforço humano no desenvolvimento / utilização dos dados;

✓ Fazer o controle de acesso / atualizações concorrentes;

✓ Possibilitar implementações de restrições de segurança e

padronização.

Como características gerais, os SGBDs devem possuir:

✓ Natureza autodescritiva: definição completa ou descrição da

estrutura do banco de dados e suas restrições, armazenadas no
catálogo do SGBD (Dicionário de Dados). Alcançada com os
Metadados, suas informações como a estrutura de cada registro, o
tipo e o formato de armazenamento de cada item de dado e várias
restrições sobre os dados.

✓ Isolamento entre os programas e dados: no armazenamento

usando sistema de arquivos, a estrutura do arquivo de dados está
embutida no programa da aplicação. Com isso, qualquer mudança na
estrutura de dados / arquivo pode exigir alterações em todos os
programas que acessam o arquivo. No SGBD, o isolamento para isso
é garantido com a abstração de dados, fornecendo-se uma
representação conceitual de dados que não inclui grandes /
profundos detalhes de como ou onde o dado é armazenado, ou como

42
 as operações de busca dos dados no disco é feita. A estrutura
detalhada e a organização de cada estrutura de armazenamento são
armazenadas no catálogo (dicionário de dados do banco de dados).

✓ Compartilhamento de dados e processamento de transação

multiusuários: um SGBD multiusuário deve permitir que diversos
usuários acessem o banco de dados ao mesmo tempo. O SGBD deve
incluir um software de controle de concorrência para garantir que
diversos usuários, ao tentarem atualizar o mesmo dado, o façam de
um modo controlado, de forma a assegurar que os resultados das
atualizações sejam corretos. Para isso, utiliza o recurso de transação
(um programa em execução ou processo que inclui um ou mais
acessos ao banco de dados, como a leitura ou a atualização de
registros). A propriedade de isolamento garante que cada transação
possa ser efetuada de forma isolada de outras transações, mesmo
quando centenas de transações estiverem sendo executadas
simultaneamente. A propriedade de atomicidade garante que todas
as operações em um banco de dados, dentro de uma transação,
sejam executadas totalmente ou nenhuma delas.

✓ Suporte para múltiplas visões dos dados: cada usuário pode ter ou
solicitar diferentes perspectivas ou visões do banco de dados. Visões
podem ser um subconjunto de um banco de dados (algumas tabelas,
por exemplo) ou uma visão virtual dos dados (por exemplo, com
algumas colunas apenas da tabela ou parte dos dados).

Arquitetura ANSI/SPARC e Independência de dados

A Arquitetura ANSI/SPARC tem o objetivo de separar o usuário da
aplicação do banco de dados físico. É com ela que o SGBD provê as
características de abstração de dados e as múltiplas visões dos dados.

É Também chamada de Arquitetura de Três Esquemas, por possuir

os três níveis a seguir de abstração:

43
 ✓ Nível Interno ou Físico: descreve como os dados estão de fato
armazenados no banco de dados.

✓ Nível Conceitual ou Lógico: descreve quais dados estão

armazenados no banco de dados e quais os relacionamentos entre
eles.

✓ Nível Externo ou de Visão: descreve apenas parte do banco de

dados. Pode-se ter mais de uma visão do mesmo banco de dados.

Exemplo: Type Funcionario = record

codigo : number;

nome : string;

sexo : string;

endereço : string;

end;

➢ Nível Interno: dado em um bloco consecutivo de

memória (bytes);

➢ Nível Conceitual: instância dos dados, como no

exemplo;

➢ Nível Externo: Programa de Cadastro de Funcionários

(programa do exemplo que esconde os detalhes dos
tipos de dados).

Já a Independência de Dados “é a capacidade de modificar a

definição dos esquemas em um determinado nível, sem afetar o esquema do
nível superior” (Korth, Henry,1999). Ela pode ser física ou lógica.

44
 ✓ Independência de Dados Física: capacidade de modificar o
esquema físico sem precisar alterar a programação de acesso aos
dados. Por exemplo, modificações para melhorar o desempenho.

✓ Independência de Dados Lógica: capacidade de modificar o

esquema lógico sem precisar alterar a programação de acesso aos
dados. Por exemplo, quando novas unidades de medida são inseridas
no sistema de uma fábrica de roupas.

Tipos de SGBDs
Ao longo da história e atualmente, pode-se encontrar os seguintes
tipos de Sistemas Gerenciadores de Bancos de Dados:

➢ SGBD Hierárquico: conecta registros numa estrutura de dados em

árvore através de ligações, de tal modo que cada tipo de registro
tenha apenas um possuidor. Registros eram armazenados com
ponteiros entre eles.

Figura 33 – Estratégia de armazenamento em um SGBD Hierárquico.

Fonte: o autor.

Nesse tipo de SGBD, as queries tinham que processar uma tupla por
vez, percorrendo a estrutura hierárquica.

45
Figura 34 – Sequência de processamento de uma query em um SGBD
Hierárquico.

Fonte: o autor.

Não havia independência entre os esquemas lógico e físico, exigindo

muito esforço de programação para usar banco de dados
hierárquico.

Exemplo: IMS (Information Management System) da IBM.

➢ SGBD de Rede: organização semelhante à dos SGBDs hierárquicos,

mas eliminando o conceito de hierarquia, de forma a permitir que um
mesmo registro esteja envolvido em várias associações, ou seja, um
registro filho pode ser ligado a mais de um registro pai, criando
conexões bastante complexas.

Figura 35 – SGBD de Rede.

Fonte: o autor.

46
 Bastante utilizado em sistemas para computadores de grande porte
(mainframe). A estrutura de armazenamento é formada de entidade
(registros), atributos (itens de dados), tipo de registro e ocorrência
do registro. Assim como no hierárquico, as aplicações devem ser
construídas para atravessar um conjunto de registros interligados
previamente.

Exemplos:

CODASYL (Comitee for Data Systems Language)

ADABAS (Adaptable DAta BAse System) da Software AG

RDM (Raima Database Manager) / db_VISTA

➢ SGBD Orientado a Objetos: dados são armazenados na forma de

objetos, ou seja, utilizando a estrutura de dados denominada
orientação a objetos, a qual permeia as linguagens modernas de
programação. Referenciado por OODBMS (Object-Oriented Database
Management System) ou SGBDOO.

Figura 36 – Modelo de Dados em um SGBDOO.

Fonte: o autor.

Dados só podem ser manipulados pelos métodos definidos pela

classe de que estes objetos pertencem. Os objetos são organizados
numa hierarquia de tipos e subtipos que recebem as características
de seus supertipos (herança). Os objetos podem conter referências

47
 para outros objetos, e as aplicações acessam os dados usando
navegação de programação. Exemplos: ORION, GemStone e Caché.

➢ SGBD Relacional: surgiu com a Teoria Relacional de Edgar Frank

Codd, que se baseou na Teoria de Conjuntos e Álgebra Relacional.
Registros armazenados de forma tabular, possuindo uma linguagem
de alto nível (declarativa), alta independência de esquemas e queries
independentes do meio físico. Regras de negócio podendo estar no
banco de dados.

Exemplos: MySQL, Oracle, SQL Server, Sybase, PostgreSQL, DB2 etc.

➢ SGBD Não Relacional (Not Only SQL – NOSQL): propósito de gravar

e recuperar grande volume de dados de forma mais rápida (Filosofia
da Agregação Atômica). Regras de negócio voltam para a camada de
aplicação. Altamente escaláveis horizontalmente (além de
verticalmente). Dados semiestruturados e esquema de dados
flexível.

Quatro principais famílias de SGBDs NOSQL: chave-valor (key-value),

colunar (column-family), de grafo (graph) e orientados a documento
(document).

Figura 37 – Modelo de dados em um SGBDOO.

Fonte: www.geeksforgeeks.org.

48
 Exemplos: Cassandra, MongoDB, CouchDB, DynamoDB, Hbase,
MemcacheDB, Redis, Neo4j, OrientDB etc.

➢ SGBD NewSQL: SGBD distribuído e relacional que procura fornecer

o mesmo desempenho escalável de um SGBD NOSQL.

Exemplos: Amazon Aurora, CockroachDB, CosmosDB, novas engines

otimizadas (MySQL NDB Cluster, SQL Server Column Store etc).

Tipos de Arquiteturas de SGBDs

➢ Arquitetura Monolítica: banco de dados e aplicação no mesmo
servidor. Acesso do usuário final centralizado nesse servidor único.

Figura 38 – Arquitetura de SGBD Monolítica.

Fonte: Microsoft.

➢ Arquitetura Cliente-Servidor: camada de banco de dados separada

da camada da aplicação.

Figura 39 – Arquitetura de SGBD Cliente-Servidor.

Fonte: Microsoft.

49
➢ Arquitetura Centralizada: camada de banco de dados sem
redundância, estando os dados centralizados em um único sistema
de armazenamento. Processamento centralizado de consultas e
transações. Pode usar componentes físicos únicos (topologia stand
alone) ou compartilhados (topologia cluster com alta disponibilidade
do servidor / SGBD).

Figura 40 – Arquitetura de SGBD Centralizada em Cluster.

Fonte: Microsoft.

➢ Arquitetura Distribuída: utiliza conceitos e técnicas de sistemas

distribuídos, na camada do banco de dados. “Um sistema constituído
por um conjunto de computadores independentes, visto pelos
utilizadores do sistema como sendo um sistema coerente e único”
(Tanenbaum - Sistemas Distribuídos: Princípios e Paradigmas).

Figura 41 – Arquitetura de SGBD Distribuída.

Fonte: Microsoft, adaptado pelo autor.

50
 Fornece alta disponibilidade na camada de banco de dados,
escalabilidade horizontal e vertical mais fácil de se implementar e
tolerância a falhas na camada de armazenamento de dados, devido
à utilização de distribuição de dados (replicação / particionamento).

Figura 42 – Tolerância a falhas em um SGBD Distribuído.

Fonte: MongoDB.

Componentes e Funcionamento de um SGBD

Figura 43 – Principais componentes de um SGBD.

Fonte: o autor.

➢ Arquivos de Dados: conjunto de arquivos (os dados em si).

51
➢ Dicionário / Catálogo de Dados: metadados do SGBD e bancos de
dados.

➢ Gerenciador de Arquivos: gerencia a alocação do espaço necessário

para a armazenagem do arquivo no disco e as estruturas de dados
utilizadas para representar a informação armazenada.

➢ Gerenciador de Banco de Dados

− Fornece a interface entre os dados armazenados, os

programas de aplicação e as solicitações submetidas ao
sistema;

− Interage com o Gerenciador de Arquivos;

− Responsável pelo controle de segurança, controle de

concorrência, integridade, cópias de segurança e
recuperação.

➢ Processador de Consultas: traduz comandos numa linguagem de

consulta em instruções de baixo nível, que são reconhecidas pelo
Gerenciador de Banco de Dados.

➢ Pré-Compilador DML

− Converte comandos DML embutidos em um aplicativo para

chamadas na linguagem hospedeira;

− Interage com o Processador de Consulta para gerar o código

apropriado.

➢ Compilador DDL: Converte comandos DDL em um conjunto de

tabelas contendo Metadados, que são armazenados no Catálogo de
Dados;

52
 ➢ Índices: usados para performance e otimização nas operações com
os dados.

De forma macro, o funcionamento de um SGBD se dá da seguinte

forma, quando da requisição de um dado por um usuário / aplicação:

i. O programa de aplicação chama o SGBD para ler um registro lógico,

fornecendo critérios para a pesquisa;

ii. O SGBD verifica se o que o usuário quer ler existe e se ele tem
autorização para isso;

iii. O SGBD verifica na visão lógica quais os tipos de dados lógicos

necessários;

iv. O SGBD examina a descrição física e determina quais os registros

físicos a serem lidos;

v. O SGBD emite uma ordem ao sistema operacional para que ele faça
a leitura dos registros solicitados;

vi. O sistema operacional interage com o meio físico onde os dados

estão armazenados;

vii. Os dados são transferidos para um buffer do sistema;

viii. O SGBD compara o sub-esquema (visão do usuário) com o esquema

(visão global), extraindo dos dados do buffer o registro lógico
solicitado;

ix. O SGBD transfere os dados do buffer para a área de comunicação no

programa de aplicação;

x. O SGBD fornece um código de status ao programa, informando o

resultado da operação, inclusive se houve algum erro;

53
 xi. O programa de aplicação reassume o controle, podendo operar com
os dados na área de comunicação.

Figura 44 – Funcionamento macro de um SGBD em uma operação de consulta.

Fonte: o autor.

54
4
Capítulo 4. Introdução a Banco de Dados Relacional
Teoria de Banco de Dados Relacional
O Modelo de Dados Relacional foi criado por Edgar Frank Codd, em
junho de 1970, quando da publicação do seu artigo A Relational Model of
Data for Large Shared Data Banks. Nesse artigo, Codd propôs um modelo
onde a representação dos dados é independente de como eles são
organizados e armazenados internamente nos servidores.

O grande sucesso da proposta de Codd está no fato dele ter se

baseado na álgebra relacional e teoria de conjuntos, trazendo para a
comunidade um conceito simplificado e mais trivial para o raciocínio lógico
de desenvolvedores e projetistas de bancos de dados: dados vistos como
um conjunto de tabelas, dispostos em linhas e colunas.

Figura 45 – Estrutura tabular.

Fonte: o autor.

Com um determinado registro (dados inter-relacionados) sendo

visto como uma tupla (linha formada por uma lista ordenada de colunas), a
representação tabular trouxe grande facilidade para manipular e visualizar
dados, em detrimento dos modelos hierárquicos e de rede, em voga na
época, contribuindo enormemente para o “boom” dos bancos de dados
relacionais.

56
 Figura 46 – Exemplo de armazenamento tabular.

COD_CLIENTE NOM_CLIENTE NUM_TEL_CLIENTE IND_SEXO_CLIENTE

1 JOÃO 33333333 M
2 MARIA 99999999 F
3 JOSÉ 88888888 M
4 TIAGO 66666666 M
5 PEDRO 44444444 M
6 MATEUS 11111111 M
7 ANA 77777777 F
8 TEREZA 55555555 F
9 CLLODDOVILL 90000000 D
Fonte: o autor.

Junto com a teoria da representação tabular dos dados, Codd

apresentou os conceitos e recursos a serem usados na modelagem
relacional, descritos a seguir:

• TABELA: objeto correspondente à entidade do modelo conceitual,

constituindo a estrutura onde os dados serão armazenados no
modelo físico do banco de dados.

• DOMÍNIO: natureza dos valores permitidos para um determinado

conjunto de dados. Exemplos:

CODIGO CLIENTE ➔ NUMBER

NOME CLIENTE ➔ STRING
DATA NASCIMENTO ➔ DATE

• COLUNA: correspondente ao conceito de atributo do modelo

conceitual, acrescido do domínio do dado que será armazenado na
coluna. Comumente chamado de campo.

• CHAVE PRIMÁRIA (“PRIMARY KEY” / “PK”): coluna (campo) ou

conjunto de colunas (chave primária composta) que identificam
unicamente a tupla (linha) em uma tabela. Exemplo: NÚMERO DO
CPF.

57
• CHAVE CANDIDATA: que não repetem valor em uma tabela e que
são candidatas à chave primária. Exemplos: NÚMERO DO TÍTULO DO
ELEITOR, NÚMERO DO RG, NÚMERO DO CPF.

• CHAVE ESTRANGEIRA (“FOREIGN KEY” / “FK”): são o elo de

ligação entre duas tabelas, se constituindo na(s) coluna(s) da chave
primária da tabela estrangeira relacionada com a tabela em questão.

Figura 47 – Exemplo de Chave Estrangeira (FK).

Fonte: o autor.

• RELACIONAMENTO: aplica-se o mesmo princípio do modelo

conceitual para o mapeamento das relações entre as tabelas, sendo
que alguns relacionamentos podem gerar novas tabelas.

• CARDINALIDADE: no modelo lógico relacional, assume uma

importância ainda maior, pois além de representar a quantidade de
elementos de uma entidade A que podem ser associados a
elementos de uma entidade B e vice-versa, indicam também as
restrições de nulidade das chaves estrangeiras.

No modelo lógico, uma das notações mais usadas para a

cardinalidade de relacionamentos é a Information Engineering (IE),
mostrada a seguir.

Figura 48 – Notação IE.

Fonte: o autor.

58
 Essa notação, no tocante à chave estrangeira, indica a nulidade
dessa coluna, ou seja, se ela sempre estará associada a um registro
da outra tabela, ou se a chave estrangeira aceitará um valor nulo.
Cardinalidades 0,1 e 0,N implicam em chaves estrangeiras que
aceitam valores nulos, como mostrado no exemplo abaixo:

Figura 49 – Exemplo de relacionamento 0,1:0,N.

Fonte: o autor.

Já as cardinalidades 1:0,N e 1:0,1 garantem que as chaves

estrangeiras não aceitem nulo e estejam sempre associadas com um
registro da tabela estrangeira, como mostrado no exemplo a seguir.

Figura 50 – Exemplo de relacionamento 1:0,N.

Fonte: o autor.

• RESTRIÇÕES DE INTEGRIDADE: regra que garante a consistência

dos dados em um relacionamento entre duas tabelas. São de três
tipos:

✓ Cascade (C): ao deletar um registro, deleta registro da chave

estrangeira também (deleção em cascata).

✓ Restricit (R): não deleta um registro que seja chave

estrangeira.

✓ Set Null (S): deleta registro e seta chave estrangeira para

nulo.

59
 A representação da restrição de integridade é sempre feita no
sentido tabela com a chave primária e tabela com a chave estrangeira, como
mostrado nos exemplos abaixo.

Figura 51 – Exemplos de restrições de integridade.

Fonte: o autor.

Para definir corretamente as restrições de integridade, pode-se usar

o algoritmo a seguir como regra geral:

Posso Eliminar Chave Primária (registro pai)?

Se não puder é RESTRICT
Se puder:
Preciso Manter os Filhos (registros na tabela da FK)?
Se precisar é SET NULL
Se não precisar é CASCADE

As 12 Regras de Codd
Além de todo esse trabalho espetacular de lançamento do modelo
relacional, no ano de 1981, Codd publicou um conjunto de 12 regras, as
famosas 12 Regras de Codd (disponível em
https://computing.derby.ac.uk/c/codds-twelve-rules), com o propósito de

60
definir o que seria necessário para um sistema de gerenciamento de bancos
de dados ser considerado relacional. Codd publicou essas regras como parte
de uma empreitada pessoal, na tentativa de impedir que sua visão e seu
trabalho acerca de bancos de dados relacionais fossem deturpados ou
diluídos, dados os constantes esforços de fornecedores de bancos de dados
em ajustar ou relançar os produtos existentes na época (sistemas
gerenciadores de bancos de dados hierárquicos, de rede etc.) com um viés
relacional.

Essas regras são numeradas de 1 a 12, mas Codd definiu também

uma regra base, na qual todas as doze regras foram baseadas, a Regra 0:
“Para qualquer sistema que seja anunciado como ou reivindicado a ser um
sistema de gerenciamento de banco de dados relacional, esse sistema deve
ser capaz de gerenciar bancos de dados inteiramente por meio de suas
capacidades relacionais.”

Regra 1: A Regra da Informação

“Todas as informações em uma base de dados relacional são

representadas explicitamente no nível lógico e por apenas uma maneira:
valores em tabelas.”

Com essa regra, Codd quis garantir que até as informações de

catálogo, como nomes das tabelas e colunas, e objetos de sistema,
estivessem armazenados em tabelas. Além disso, procurou tornar a tarefa
do administrador de manter a base de dados em um estado de integridade
geral mais simples e mais eficaz.

Regra 2: Regra de Garantia de Acesso

“Todo e qualquer dado (valor atômico) em uma base de dados

relacional tem a garantia de ser logicamente acessível, recorrendo a uma
combinação do nome da tabela, valor da chave primária e nome da coluna.”

61
 Com essa regra, Codd definitivamente abandona as necessidades
dos SGBDs não relacionais da época, onde havia-se a necessidade de saber
a forma como os dados estavam armazenados internamente, ou seja, do
usual endereçamento orientado a computador.

Regra 3: Tratamento Sistemático de Valores Nulos

“Valores nulos (distintos da cadeia de caracteres vazia ou uma

cadeia de caracteres em branco e distintos de zero ou
qualquer outro número) são suportados no sistema
gerenciador de banco de dados totalmente relacional, para
representar informações ausentes e informações inaplicáveis
de maneira sistemática, independentemente do tipo de
dados.”

Técnicas anteriores exigiam a definição de um valor especial

(peculiar a cada coluna ou campo) para representar informações ausentes.
Codd quis eliminar essa premissa, pois acreditava que diminuiria a
produtividade do usuário.

Regra 4: Catálogo Online e Dinâmico Baseado no Modelo

Relacional

“A descrição da base de dados (dicionário de dados – grifo nosso) é

representada no nível lógico da mesma forma que os dados ordinários, de
modo que os usuários autorizados possam aplicar a mesma linguagem
relacional à sua query que se aplicam aos dados regulares.”

Regra 5: Regra da Linguagem de Dados Compreensiva

“Um sistema relacional pode suportar várias linguagens e

vários modos de uso de terminal. No entanto, deve haver pelo
menos uma linguagem cujas declarações sejam expressas,
por alguma sintaxe bem definida, como cadeias de caracteres,
e abrangente em suporte a todos os itens a seguir:

62
 ✓ Definição de dados e de visões;

✓ Manipulação de dados (interativo e por programa);

✓ Restrições de integridade;

✓ Autorização;

✓ Controle de transação (begin, commit e rollback).”

Regra 6: Regra da Atualização de Visões

“Todas as visualizações que são teoricamente atualizáveis também

são atualizáveis pelo sistema.”

Com essa regra, Codd alerta para o tratamento das atualizações das
visões de dados (views).

Regra 7: Inserções, Atualizações e Deleções de Alto Nível

“A capacidade de lidar com uma relação base ou uma relação

derivada como um único operando aplica-se não apenas à recuperação de
dados, mas também à inserção, atualização e exclusão de dados.”

Nesse requerimento, Cood procura proporcionar aos sistemas

gerenciadores de bancos de dados um escopo maior para otimizar as ações
(tarefas) em tempo de execução e, ao mesmo tempo, fornecer uma
experiência mais rápida para o usuário.

Regra 8: Independência Física dos Dados

“Os programas de aplicativos e as atividades do terminal

permanecem logicamente inalterados sempre que forem feitas alterações
nas representações de armazenamento ou nos métodos de acesso.”

63
 Regra 9: Independência Lógica dos Dados

“Os programas de aplicativos e atividades de terminal permanecem

logicamente inalterados quando mudanças que preservem a informação são
feitas a essas tabelas.”

Essa regra garante que os comandos de manipulação dos dados

permaneçam inalteradas quando de alterações de estruturas das tabelas,
desde que os dados originais delas sejam preservados.

Regra 10: Independência de Integridade

“Restrições de integridade, específicas de uma determinada base de

dados relacionais, devem ser definidas na linguagem do banco de dados e
armazenadas no catálogo, não nos programas de aplicação.”

Com essa regra Codd procura simplificar o desenvolvimento,

deixando a cargo do banco de dados a garantia da integridade dos dados.

Regra 11: Independência de Distribuição

“Um sistema gerenciador de banco de dados relacional tem

independência de distribuição.”

Por independência de distribuição, Codd quis dizer que o SGBD

relacional precisa ter uma linguagem que permita aos programas ficarem
inalterados quando uma distribuição de dados for introduzida no banco de
dados ou quando os dados forem redistribuídos.

Regra 12: Regra de Não Subversão

“Se um sistema relacional tiver uma linguagem de baixo nível, esse

nível não poderá ser usado para subverter ou ignorar as regras de
integridade e restrições expressas na linguagem relacional de nível
superior.”

64
 Essa regra expressa a preocupação de Codd com os fornecedores de
SGBDs que estavam recodificando seus produtos como relacionais, mas que
haviam nascido com suporte a uma interface abaixo da interface de restrição
relacional, o que torna muito fácil burlar várias regras colocadas por ele,
principalmente as de restrição de integridade. Com essa subversão de baixo
nível, o banco de dados poderia passar para um status não íntegro, com por
exemplo, registros filhos órfãos, mesmo havendo as restrições de
integridade definidas nas tabelas do banco de dados.

As Propriedades ACID
As características que mais contribuíram para o respaldo, robustez e
integridade dos sistemas gerenciadores de bancos de dados relacionais
foram as suas propriedades ACID. Essas propriedades referem-se, em
grande parte, às transações que são executadas no SGBD, que nada mais
são do que uma sequência de instruções SQL.

Essas propriedades funcionam como regras para as transações

executadas em um SGBD relacional, tendo o seguinte significado:

ATOMICIDADE: requer que as transações sejam “tudo ou nada” (“all

or nothing”), ou seja, se uma parte da transação falhar, a transação inteira
deve falhar, e o estado do banco de dados permanecer inalterado. Em outras
palavras, a transação será executada totalmente ou não será executada,
garantindo assim que as transações sejam atômicas.

CONSISTÊNCIA: garante que qualquer transação levará o banco de

dados de um estado válido a outro. Em caso de sucesso, a transação cria um
novo estado válido dos dados ou, em caso de falha, retorna todos os dados
ao estado imediatamente anterior ao início da transação.

ISOLAMENTO: garante que execuções concorrentes (em paralelo)

de transações resultem em um estado do banco de dados que seria obtido
caso as transações fossem executadas serialmente. Isso ocasiona que uma

65
transação em andamento, mas ainda não validada, permanece isolada de
qualquer outra operação, garantindo que a transação não sofra interferência
de nenhuma outra transação concorrente.

DURABILIDADE: garante que, uma vez que uma transação tenha

sido confirmada, ela permanecerá assim, mesmo no caso de um reinício do
sistema, crash, falta de energia ou erros posteriores.

Figura 52 – Propriedades ACID.

Fonte: o autor.

A Linguagem SQL
Quando Codd publicou a teoria do Modelo de Dados Relacional, em
1970, ele era então um pesquisador no laboratório da IBM, em San José.
Entretanto, com o intuito de preservar o faturamento gerado pelos produtos
“pré-relacionais”, como por exemplo o SGBD hierárquico IMS, a IBM optou
inicialmente por não implementar as ideias relacionais de Codd.

Descontente com essa situação e acreditando no salto evolutivo que

o modelo de dados relacional poderia trazer para os sistemas gerenciadores
de bancos de dados e para a história da computação, Codd procurou grandes
clientes da IBM para mostrar-lhes as novas potencialidades e benefícios da
implementação do modelo relacional. A pressão desses clientes sobre a IBM
forçou-a a incluir, no seu projeto Future Systems (FS), em andamento no

66
Centro de Pesquisas de Almaden (Almaden Research Center, na época San
Jose Research), em San José, Califórnia, o subprojeto System R.

O projeto Future Systems foi um projeto de pesquisa e

desenvolvimento realizado na IBM no início dos anos 70, com o objetivo de
desenvolver uma linha revolucionária de produtos de informática, incluindo
novos modelos de software que simplificariam o desenvolvimento de
software, explorando hardwares poderosos e modernos. Em 1974, então,
dentro do projeto Future System, iniciava-se a construção do System R, um
sistema de banco de dados experimental com o propósito de demonstrar
que as vantagens de usabilidade do modelo de dados relacional poderiam
ser implementadas em um sistema com suas funcionalidades completas e
com alto desempenho, quesitos altamente requeridos no uso cotidiano de
ambientes de produção.

Um dos resultados mais expressivos do projeto System R foi a

criação da linguagem para consulta e manipulação de dados, chamada
inicialmente de SEQUEL (pronunciada como "síquel"), um acrônimo para
Structured English Query Language (Linguagem de Consulta Estruturada,
em inglês). Os progenitores dessa linguagem, Donald Chamberlin e Ray
Boyce, a partir do modelo estabelecido por Codd em seu artigo A Relational
Model of Data for Large Shared Data Banks, desenvolveram e lançaram a
linguagem de programação em seu próprio artigo SEQUEL: A Structured
English Query Language. Eles pegaram as linguagens de Codd com o
objetivo de projetar uma linguagem relacional que fosse mais acessível aos
usuários sem um treinamento formal em matemática ou ciência da
computação.

Essa versão original da linguagem, que continha um conjunto de

comandos que permitiam definir a estrutura de dados, inserir, atualizar,
excluir e manipular dados, foi usada inicialmente nos sistemas de bancos de
dados relacionais originais da IBM, os "System R".

67
 Entretanto, como SEQUEL era uma marca registrada pela empresa
de aeronaves Hawker Siddeley, a linguagem SEQUEL, através da eliminação
das vogais, foi renomeada para SQL (Structured Query Language -
Linguagem de Consulta Estruturada). Devido a isso, até hoje ouvimos
comumente a sigla, em inglês, ser pronunciada como "síquel" (SEQUEL) ao
invés de "és-kiú-él" (SQL), letra a letra. No entanto, em português, a
pronúncia mais comum é letra a letra: S (“esse”) - Q (“quê”) - L (“éle").

Nos anos seguintes, a SQL não se tornou disponível publicamente,

como vemos nos dias de hoje. No entanto, em 1979, a Oracle, então
conhecida como Relational Software, criou sua própria versão da linguagem
SQL chamada Oracle V2, que foi lançada comercialmente. É importante
observar que a SQL não foi a primeira linguagem de programação para
bancos de dados, mas o crescimento em larga escala da sua utilização foi
em grande parte devido à sua intuição e facilidade de uso. As linguagens de
consulta até então eram na maioria linguagens procedurais, o que requeria
que o usuário especificasse o caminho (navegação, posição etc.) para se
chegar ao resultado, como mostrado no pseudocódigo abaixo:

Repita para cada linha de dados:

Se a cidade for São Paulo, retorne a linha; caso contrário, não faça nada.
Mova para a próxima linha.
Final do Loop.

Já a linguagem SQL, sendo uma linguagem declarativa, requeria

apenas especificar a forma (conteúdo desejado) do resultado e não o
caminho para se chegar a ele, como mostrado no pseudocódigo abaixo:

Retorne todos os clientes cuja cidade é São Paulo.

68
 De certa forma, essa peculiaridade reduziu o ciclo de aprendizado
dos desenvolvedores e administradores de bancos de dados, fazendo com
que a Linguagem SQL caísse no “gosto” rapidamente da comunidade.

Outro fator que contribuiu para a popularização da linguagem SQL,

no sentido de prover respaldo e coerência, foi a grande confiabilidade pelo
fato de Codd ter se baseado na Álgebra Relacional, e consequentemente na
Teoria de Conjuntos, para sustentar sua fundamentação teórica acerca dos
modelos de dados relacionais. Utilizando-se das já conhecidas operações da
Álgebra Relacional, como seleção, projeção e junção, e das operações da
teoria de conjuntos como união, interseção, diferença e produto
cartesiano, Codd quase levou a comunidade ao “êxtase” ao propor uma
forma mais abstrata e natural para o armazenamento dos dados e uma
maneira de manipulá-los mais próxima das relações humanas, baseadas em
relacionamentos e correlações.

Figura 53 – Operações da Álgebra Relacional.

Fonte: Marta Mattoso.

Usando-se dos operadores de Álgebra Relacional, Codd conseguiu

fundamentar a viabilidade e usabilidade do modelo relacional e seu
armazenamento de dados no formato tabular, em tuplas. A título
informacional, pois não é o objetivo dessa disciplina aprofundar em álgebra
relacional, os operadores usados por Codd em sua teoria estão relacionados
na figura abaixo, e a seguir, alguns exemplos de utilização deles.

69
 Figura 54 – Operações/Operadores em Álgebra Relacional.

Fonte: Júnior Galvão.

• Restrição (σ): retornar somente as tuplas que satisfaçam a uma

condição. Exemplo: retornar os dados dos empregados que estão
com salário menor que 2.000.

Figura 55 – Seleção na Álgebra Relacional.

Fonte: Vania Bogorny.

• Projeção (π): retornar um ou mais atributos desejados. Exemplo:

retornar o nome e a idade dos empregados.

70
 Figura 56 – Projeção na Álgebra Relacional.

Fonte: Vania Bogorny.

• Interseção (∩): retornar tuplas comuns entre duas entidades

(tabelas). Exemplo: retornar o nome e o CPF dos funcionários que
estão internados como pacientes.

π nome,CPF (FUNCIONARIO) ∩ π nome,CPF (PACIENTE)

• União (υ): retornar a união das tuplas de duas entidades (tabelas).

Exemplo: retornar o nome e o CPF dos médicos e pacientes
cadastrados no hospital.

π nome,CPF (MEDICO) υ π nome,CPF (PACIENTE)

• Diferença (-): retornar um conjunto de tuplas, que é o conjunto de

tuplas da primeira entidade menos as tuplas existentes na segunda
entidade. Exemplo: retornar o código dos ambulatórios onde
nenhum médico dá atendimento.

π codigoA (AMBULATORIO) - π codigoA (MEDICO)

• Produto Cartesiano (X): retornar todas as combinações possíveis de

tuplas de duas entidades. Exemplo: retornar o nome dos médicos e
os estados onde eles podem trabalhar.

π medico,uf (MEDICO X ESTADO)

71
 No entanto, o sucesso prolongado da SQL não pode ser atribuído
apenas às suas qualidades. Os padrões, assunto que trataremos no próximo
capítulo, não apenas ajudou a SQL a se aproximar de um uso quase que
universal na comunidade de banco de dados, mas também acrescentou
atributos-chave que floresceram em suas especificações posteriores. Tudo
isso começou quando o American National Standards Institute (ANSI),
que é o Instituto Americano Nacional de Padrões, se envolveu.

Padronização da Linguagem SQL, Classes de Instruções SQL e Dialetos

O American National Standards Institute (ANSI) é uma organização
particular estadounidense sem fins lucrativos que atua, há mais de 100
anos, como administrador e coordenador do sistema norte-americano de
normas e conformidades voluntários. Fundado em 1918 por cinco
sociedades de engenharia e três agências governamentais, o Instituto
continua sendo uma organização privada sem fins lucrativos, apoiada por
um grupo diversificado de organizações do setor público e privado.

Ao longo de sua história, o ANSI manteve como meta principal a

melhoria da competitividade global das empresas americanas e a qualidade
de vida nos Estados Unidos, promovendo e facilitando padrões consensuais
voluntários e sistemas de avaliação de conformidade e promovendo sua
integridade. Um desses padrões, talvez o mais conhecido mundialmente
pela comunidade da computação, é o padrão publicado para a Linguagem
SQL.

Embora a SQL tenha sido originalmente criada pela IBM, após a sua
publicação, rapidamente surgiram várias linguagens desenvolvidas pelos
fornecedores de SGBDs relacionais, cada uma com suas adaptações à
Linguagem SQL original. Como exemplo, podemos citar o dialeto PL/SQL da
Oracle. Essa expansão levou à necessidade de ser criado e adaptado um
padrão para a Linguagem SQL. Esta tarefa foi realizada, pioneiramente, pela
American National Standards Institute, em 1986, com a publicação do

72
padrão ANSI X3.135-1986. Este foi o começo do que as pessoas chamam
erroneamente de padrão ANSI para SQL. Na verdade, não existem padrões
ANSI, apenas padrões desenvolvidos por comitês aprovados pela ANSI,
muitos deles operando de acordo com os Requisitos Essenciais da ANSI.

Após alguns meses ao lançamento do ANSI X3.135-1986, a

International Organization for Standardization (ISO) publicou um padrão
tecnicamente idêntico, o ISO 9075-1987, para o cenário internacional. Na
época da publicação inicial desses padrões, especificações mais detalhadas
sobre a linguagem SQL se faziam necessárias, mas o ANSI X3.135-1986
ajudou a definir as bases para alguns recursos importantes para a linguagem
de codificação. Esse padrão, por exemplo, deu a capacidade de invocar
recursos de SQL de quatro linguagens de programação: COBOL, FORTRAN,
Pascal e PL / I.

Esses padrões foram revisados em conjunto, primeiramente em

1989 (ANSI X3.135-1989 e ISO / IEC 9075: 1989) e novamente em 1992
(ANSI X3.135-1992 e ISO / IEC 9075: 1992). A edição de 1989 incluía
suporte para duas linguagens de programação adicionais, Ada e C. Essas
edições se tornaram coloquialmente conhecidas como SQL-86, SQL-89 e
SQL-92. Portanto, se você ouvir esses nomes em referência a um formato
SQL, lembre-se que ele está se referindo às várias edições desse padrão. O
padrão foi revisado novamente em 1999 (SQL3), 2003, 2008, 2011 e 2016,
que continua sendo a edição atual (ISO / IEC 9075: 2016). A norma
internacional ISO / IEC 9075 para SQL é desenvolvida pelo ISO/IEC Joint
Technical Committee (JTC) 1 for Information Technology e desde a edição
de 2003 foi subdividida em 9 partes, cada uma cobrindo um aspecto do
padrão geral, sob o título Tecnologia da Informação – Linguagens de
Banco de Dados – SQL.

Mesmo com todos esses esforços e publicações para se ter um

padrão único da Linguagem SQL, os fornecedores de SGBDs continuaram

73
fazendo suas próprias implementações, baseadas nos padrões da
Linguagem SQL, mas com pequenas adaptações ou personalizações. Dentre
as mais conhecidas, além da já citada PL/SQL da Oracle, temos também a T-
SQL da Microsoft (usada no SQL Server) e a SQL PL da IBM.

Devido a isso, é comum encontrar algumas pequenas diferenças na

sintaxe de implementação para um mesmo tipo de comando SQL nos
diversos sistemas gerenciadores de bancos de dados relacionais
(comumente referidos pela comunidade como dialetos). Para exemplificar,
tomemos como base uma simples query SQL para retornar os N registros de
uma tabela com a cláusula TOP:

Sintaxe de uso no SGBD (dialeto) SQL Server:

SELECT TOP [QTDE DE REGISTROS] [COLUNA(S)] FROM [TABELA]

Sintaxe de uso nos SGBDs (dialeto) MySQL e PostgreSQL:

SELECT [COLUNA(S)] FROM [TABELA] LIMIT [QTDE DE REGISTROS]

Sintaxe de uso no SGBD (dialeto) Oracle:

SELECT [COLUNA(S)] FROM [TABELA] WHERE ROWNUM < [QTDE

REGISTROS]

Sintaxe de uso no SGBD (dialeto) Firebird:

SELECT FIRST [QTDE DE REGISTROS] [COLUNA(S)] FROM [TABELA]

Dentro do padrão ISO SQL, encontramos quatro classes (conjuntos)

de comandos da Linguagem SQL, cada uma delas com um propósito bem
definido na etapa de construção do modelo de dados físico do banco de
dados:

• Linguagem de Definição de Dados (DDL – Data Definition

Language): comandos para a criação do banco de dados e dos

74
 objetos no banco de dados, como tabelas, índices, constraints etc., e
para alteração e exclusão de objetos.

• Linguagem de Manipulação de Dados (DML – Data Manipulation

Language): comandos para inserir, atualizar, deletar e consultar
dados.

• Linguagem de Controle de Dados (DCL – Data Control Language):

comandos para gerenciar permissões de acesso para usuários e
objetos, ou seja, permissões para executar comandos DDL, DML, DCL
e TCL.

• Linguagem de Controle de Transação (TCL – Transaction Control

Language): comandos para realizar controle das transações de
dados no banco de dados.

Figura 57 – Classes de comandos SQL.

Fonte: www.learnhowtocode.info.

Uma “Sopa de Letrinhas”

Siglas sempre fizeram e farão parte do cotidiano de um profissional
de TI, principalmente daqueles que se propõem a trabalhar com banco de
dados. Algumas delas já foram apresentadas nos capítulos anteriores, mas

75
se faz necessário apresentar algumas novas e reforçar na diferenciação de
algumas delas.

Primeiramente, é preciso estar bem clara a diferenciação entre a SQL

e o SQL. Quando se diz “a SQL”, está se fazendo menção à Linguagem SQL.
Já no segundo caso, quando se diz “o SQL”, está se fazendo menção ao SQL
Server, sistema gerenciador de banco de dados relacional desenvolvido pela
Microsoft. Adicionalmente, encontramos também o nome de outros SGBDs
fazendo menção à Linguagem SQL, de forma a indicar que são relacionais:
MySQL fornecido pela Oracle (www.mysql.com), PostgreSQL desenvolvido
pela PostgreSQL Global Development Group e de código aberto
(www.postgresql.org), SQLite desenvolvido por Richard Hipp, sendo um banco
de dados portátil e de código aberto (www.sqlite.org) etc.

Outra sigla, uma das mais faladas atualmente, “NOSQL” pode se

referenciar a duas tecnologias diferentes, mas nenhuma delas relacionadas
diretamente à Linguagem SQL. A diferença entre essas duas tecnologias é
feita na grafia: NoSQL versus NOSQL.

O termo NoSQL surgiu em 1998, quando Carlo Strozzi usou-o para

batizar um banco de dados relacional que havia desenvolvido e que não
fornecia nenhuma forma da linguagem SQL para consulta. Seu nome era
pronunciado como “nosequel”, e ele era relacional, rápido, portátil, de código
aberto, e que executava e interagia com o sistema operacional UNIX. Para
manipulação dos dados, ele disponibilizava "operadores" que executavam
uma única função, e o fluxo de dados era fornecido pelo próprio mecanismo
de redirecionamento de entrada / saída do UNIX. Dessa forma, cada
operador processava alguns dados e os transmitia ao próximo operador por
meio da função pipe do UNIX. Os dados do NoSQL eram armazenados em
arquivos ASCII UNIX e, portanto, podiam ser manipulados por utilitários
UNIX comuns, como por exemplo, ls, mv, cp e editores como o 'vi'. Essa forma
alternativa para manipulação dos dados, sem a Linguagem SQL, foi o

76
motivador do nome dado para esse banco, NoSQL (“non SQL”), no sentido de
realmente não ser um banco de dados SQL. Entretanto, pelo fato do formato
dos arquivos ser baseado em uma relação ou tabela, com linhas e colunas,
era considerado um SGBD relacional.

Figura 58 – Logo do NoSQL de Carlo Strozzi.

Fonte: Kyle Hart.

Strozzi afirmava categoricamente que seu produto “nada tinha a ver

com o recém-nascido Movimento NOSQL”, e que:

enquanto o primeiro é um pacote de software bem definido, é

um banco de dados relacional para todos os efeitos e apenas
intencionalmente não usa SQL como uma linguagem de
consulta, o recém-chegado (NOSQL) é principalmente um
conceito (e de nenhuma maneira novo), que se afasta do
modelo relacional e, portanto, deveria ter sido chamado mais
apropriadamente de ‘NoREL’, ou algo nesse sentido, já que
não ser baseado em SQL é apenas uma consequência óbvia de
não ser relacional, e não o contrário. (STROZZI, c2010)

Apesar de toda a ênfase de Strozzi, Johan Oskarsson, então um

desenvolvedor na Last.fm, reintroduziu o termo NOSQL, no início de 2009,
quando organizou um evento para discutir "bancos de dados distribuídos,
não relacionais e de código aberto". O termo tentava rotular o surgimento
de um número crescente de repositórios de dados distribuídos, não
relacionais, incluindo clones de código aberto do Google
Bigtable/MapReduce e do DynamoDB da Amazon. Desde então, o termo
NOSQL tem sido atribuído aos sistemas gerenciadores de bancos de dados
não relacionais (e não somente mais não SQL), que fornecem um

77
mecanismo de armazenamento de dados que não é baseado no formato
tabular (linhas x colunas).

Figura 59 – Logo dos SGBDs NOSQL mais usados.

Fonte: Arte dos Dados.

Nessa abordagem, o termo NoSQL passou a ser escrito como NOSQL

(reparem a grafia maiúscula da letra ‘o’), para fazer menção aos SGBDs não
relacionais, “Não Apenas SQL” (‘Not Only SQL’), e objetivando enfatizar que
esses SGBDs podiam suportar outras linguagens de consulta, que não a SQL.

Figura 60 – Logo do Movimento NOSQL.

Fonte: Ylanite.

Outra sigla que precisa ser diferencia é a UnSQL, criada em 29 de

julho de 2011, quando o fundador da Couchbase e inventor do sistema
gerenciador de banco de dados CouchDB (NOSQL), Damien Katz,
juntamente com Richard Hipp, inventor do SQLite, publicaram um artigo
(‘UNQL QUERY LANGUAGE UNVEILED BY COUCHBASE AND SQLITE ’
disponível em https://www.couchbase.com/press-releases/unql-query-language)
para anunciar o trabalho em conjunto acerca da criação de uma linguagem
de consulta padrão NOSQL, a UnQL (Unstructured Query Language). Com
pronúncia “Uncle”, o objetivo era que essa linguagem se popularizasse da
mesma forma como a linguagem SQL do movimento relacional havia se

78
popularizado. Foi criado até um site para o projeto
(http://unql.sqlite.org/index.html/wiki?name=UnQL), mas até o momento ela não
se popularizou e não virou um padrão ISO como a SQL.

Por fim, é preciso mencionar a sigla NewSQL, que ao contrário do

que parece, não é uma nova versão da Linguagem SQL. Trata-se de uma nova
geração de sistemas gerenciadores de bancos de dados relacionais
distribuídos, que procura fornecer o mesmo desempenho escalável de um
SGBD NOSQL distribuído, ao mesmo tempo que tenta garantir todas as
propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade)
de transações de dados dos SGBDs relacionais. Dentro dessa geração
encontramos novos players (Amazon Aurora, CockroachDB, CosmosDB,
Google Spanner, VoltDB etc.) e SGBDs já conhecidos, mas com a engine
reformulada (MySQL Cluster, SQL Server Column Store etc.).

79
5
Capítulo 5. Introdução ao Microsoft SQL Server
Introdução ao SQL Server
Para aplicarmos na prática os conceitos e instruções da Linguagem
SQL que serão expostos nesta disciplina, utilizaremos um banco de dados
SQL Server. O Microsoft SQL Server é um sistema gerenciador de banco de
dados relacional, desenvolvido pela Microsoft, cuja primeira versão (1.0) foi
lançada em 1989. A versão atual é a 2019 (https://www.microsoft.com/pt-
br/sql-server/sql-server-2019) e será usada nesse curso, no sistema
operacional Windows. A Microsoft já disponibilizou a versão 2022 preliminar
para testes da comunidade, mas o lançamento da versão final deve ocorrer
somente no final de 2022.

Figura 61 – Versões do SQL Server.

Fonte: o autor.

A título de conhecimento, além da engine de banco de dados

relacional, na família de produtos SQL Server existem outros três produtos:

✓ Microsoft Analysis Services (SSAS): engine analítica (OLAP) que

permite a criação de cubos e dimensões.

81
 ✓ Microsoft Reporting Services (SSRS): engine de exibição de dados,
que permite a criação de relatórios e dashboards.

✓ Microsoft Integration Services (SSIS): engine para extração,

transformação e carga de dados (ETL).

Conceitos Básicos do SQL Server

Em linhas gerais, a macro arquitetura desses produtos pode ser
resumida como uma instância (binário) existente em um servidor, que
contém os recursos (banco de dados / pasta SSRS / catálogo SSIS), em que
as estruturas (tabelas / cubos / relatórios / pacotes SSIS) para
armazenamento, processamento e exibição dos dados são criadas, como
ilustrado abaixo.

Figura 62 – Macroarquitetura de Produtos da Família SQL.

Fonte: o autor.

Instalação do SQL Server

Para instalar o SQL Server 2019, de forma que você possa reproduzir
os exemplos expostos, realizar os exercícios e praticar, baixe o instalador
abaixo, assista à respectiva aula deste capítulo e reproduza em seu
computador.

*SQL Server 2019 Developer Edition:

https://go.microsoft.com/fwlink/?linkid=866662.

82
6
Capítulo 6. Ferramentas Client
Ferramentas Client
A implementação da Microsoft, no SQL Server, da Linguagem SQL
padrão ISO / IEC 9075, é chamada Transact SQL (T-SQL). A T-SQL é uma
linguagem declarativa, possui todas as opções e instruções existentes no
padrão ISO, como variáveis, loop, controle de fluxo e decisões, funções etc.,
além de possuir algumas instruções que não estão no padrão ISO e
instruções com sintaxe ligeiramente diferente do padrão.

Para executar queries SQL no SQL Server, podemos utilizar uma

ferramenta com interface gráfica (Generical User Interface - GUI),
chamada de client, que permite se conectar no banco de dados e realizar
atividades como criar bancos de dados, tabelas, usuários, bem como
manipular dados e realizar tarefas administrativas.

A ferramenta client oficial da Microsoft, para o SQL Server, é o

Microsoft SQL Server Management Studio (SSMS), disponível para sistema
operacional Windows (https://docs.microsoft.com/en-us/sql/ssms/sql-
server-management-studio-ssms?view=sql-server-2019).

Figura 63 – SQL Server Management Studio (SSMS) 18.5.

Fonte: o autor.

84
 Para executar os comandos T-SQL no SQL Server, primeiramente é
necessário conectar-se ao banco de dados. No escopo deste curso e tendo
seguido os procedimentos de instalação exibidos nas aulas, para se conectar
ao SQL Server usando o SSMS, basta clicar no botão Connect como
mostrado na figura abaixo.

Figura 64 – Tela de Conexão do Management Studio 18.5.

Fonte: o autor.

Clicando no botão New Query destacado abaixo, abrirá uma nova

área, onde é possível digitar os comandos que se deseja executar.

Figura 65 – Botão para Abrir Tela de Query no SSMS 18.5.

Figura 66 – Tela para Escrever e Executar Query no SSMS 18.

Fonte: o autor.

85
 Para executar a query, basta selecionar o bloco de instruções que
deseja executar (caso contrário, executará todos os comandos existentes na
janela) e clicar no botão Execute (ou usar a tecla de atalho F5).

Figura 67 – Botão para Executar Query no SSMS 18.5.

Fonte: o autor.

Importante saber também que os comandos T-SQL podem ser

salvos em um arquivo texto, chamado script, normalmente com a extensão
“.sql”. No SSMS, isso é feito no menu File ou nos botões de salvar da barra
de ferramentas.

Figura 68 – Salvando um Script no SSMS 18.5.

Fonte: o autor.

86
 Por fim, faz-se importante mencionar os recursos que o SSMS
fornece para trabalhar com um projeto de banco de dados, no tocante à
organização dos scripts SQL. O SSMS fornece o recurso Solução (Solution),
dentro do qual pode ser criado um ou mais Projetos de Scripts SQL Server.

Figura 69 – Tela para criar Nova Solução e Projeto no SSMS 18.5.

Fonte: o autor.

Esses recursos são visualizados na janela Solution Explorer do

SSMS.

Figura 70 – Janela Solution Explorer no SSMS 18.5.

Fonte: o autor.

87
 Figura 71 – Adicionando um Projeto à Solução.

Fonte: o autor.

Dentro de cada projeto, pode-se adicionar um ou mais scripts que já

estejam salvos em arquivos .sql, as conexões aos bancos de dados usados
por eles, ou até mesmo criar um script ou conexão, já adicionando-os ao
projeto.

Figura 72 – Adicionando Itens ao Projeto.

Fonte: o autor.

88
 Figura 73 – Exemplo de Projetos e seus Itens.

Fonte: o autor.

Outra opção de client fornecida pela Microsoft é o Azure Data Studio

(ADS). Com ele também é possível administrar o SQL Server e os bancos de
dados e executar queries. Entretanto, possui bem menos Wizards que o
SSMS e não possui construtor de modelos de dados (diagramas). O ADS
trabalha com o conceito de Jupyter Notebooks, possibilitando executar
comandos em outras linguagens que não a T-SQL (Python, por exemplo),
tendo como foco a usabilidade para cientistas de dados.

Figura 74 – Interface do ADS com um Notebook.

Fonte: o autor.

89
Instalação e Overview do SQL Server Management Studio
Para instalar o client do SQL Server 2019, de forma que você possa
reproduzir os exemplos demonstrados, realizar os exercícios e praticar, baixe
o instalador no link https://aka.ms/ssmsfullsetup, assista à respectiva aula
deste capítulo e reproduza em seu computador.

Instalação e Overview do Azure Data Studio

Para instalar o ADS, baixe o instalador no link
https://go.microsoft.com/fwlink/?linkid=2135512, assista à respectiva aula
e reproduza em seu computador.

Instalação e Overview do Banco de Dados de Exemplo AdventureWorks

Para demonstrar os conceitos e recursos de distribuição de dados,
usaremos como banco de dados de exemplo o tradicional Adventure Works
da Microsoft (https://github.com/Microsoft/sql-server-
samples/releases/tag/adventureworks), que já vem populado com dados
fictícios. Usaremos neste curso o banco de dados AdventureWorks2019,
cujo link direto para download do backup deste banco é
https://github.com/Microsoft/sql-server-
samples/releases/download/adventureworks/AdventureWorks2019.bak.

O modelo de dados para este banco de dados pode ser encontrado

em https://improveandrepeat.com/2019/02/use-the-adventureworks-
sample-database-for-your-examples.

Para fazer o restore (“instalar”) do banco de dados de exemplo, de

forma que você possa reproduzir os exemplos expostos, realizar os
exercícios e praticar, siga os passos a seguir:

i. Baixar o backup do banco (arquivo AdventureWorks2019.bak),

salvando-o em algum local onde se tenha acesso a partir do servidor
onde o SQL Server foi instalado;

90
 ii. Feito isso, deve-se conectar no SQL Server usando o SQL Server
Management Studio e clicar no botão New Query;

iii. Após isso copie e cole o script abaixo, substituindo o caminho

C:\Downloads pelo caminho onde foi salvo o arquivo de backup do
banco (no passo 1) e o caminho D:\SQLData, pelo local onde deseja
que os arquivos do banco de dados sejam armazenados (necessários
400 MB).

USE [master]

GO

RESTORE DATABASE [AdventureWorks2019]

FROM DISK = N'C:\Downloads\AdventureWorks2019.bak'

WITH FILE = 1,

MOVE N'AdventureWorks2017' TO N'

D:\SQLData\AdventureWorks2019.mdf',

MOVE N'AdventureWorks2017_log' TO N'

D:\SQLData\AdventureWorks2019_log.ldf',

NOUNLOAD, STATS = 5

GO

iv. Ao término do restore, em caso de sucesso, deve ser exibido um log

de processamento como o mostrado a seguir;

91
 Figura 75 – Resultado restore do banco AdventureWorks2019.

Fonte: o autor.

v. Para comprovar a existência do banco restaurado, basta executar o

comando abaixo e constatar a existência do nome do banco nos
resultados retornados.

SELECT * FROM master..sysdatabases

GO

Figura 76 – Listagem de bancos.

Fonte: o autor.

92
7
Capítulo 7. Utilização Básica do SQL Server
A Linguagem de Definição de Dados, mais comumente mencionada
como DDL (abreviação de Data Definition Language), é uma classe da
Linguagem SQL com comandos que permitem criar, alterar e excluir objetos
de banco de dados.

Dentro de um Projeto de Banco de Dados, essa classe é utilizada,

principalmente na etapa de geração do esquema físico no banco de dados,
com base no modelo de dados físico elaborado.

Figura 77 – Etapas para construção e implementação de um esquema físico.

Fonte: o autor.

A maioria dos SGBDs fornece interface gráfica para implementação

do modelo de dados físico, mas a utilização de scripts SQL é bem útil para
questões de versionamento e validações.

Grande parte das ferramentas CASE de modelagem de dados

também fornece recursos para a geração dos scripts DDL a partir de um
determinado modelo físico, como no exemplo a seguir de um script DDL,
gerado pela ferramenta ERWin para um modelo de dados físico no SGBD
Oracle.

94
 Figura 78 – Script DDL em Oracle.

Fonte: o autor.

Criação de Estruturas de Dados

A criação de estruturas ou objetos, no banco de dados, é feita através
da instrução SQL CREATE. Através desse comando consegue-se criar o
banco de dados, as tabelas, os índices, visões, chaves estrangeiras,
constraints, sinônimos, sequences etc.

Para criar um banco de dados, a sintaxe do comando SQL é:

CREATE DATABASE <Nome_do_Banco_de_Dados>;

Executando o comando SQL dessa forma, sem passar parâmetros

adicionais (como tamanho, conjunto de caracteres de idioma etc.), o banco
de dados será criado com as opções default da instância em questão.

Para exemplificar, se desejamos criar o banco de dados de nome

BDTESTE, devemos executar CREATE DATABASE BDTESTE;.

Importante ressaltar que, apesar da instrução CREATE DATABASE

pertencer ao padrão ISO da Linguagem SQL, cada SGBD implementa os
parâmetros adicionais necessários e específicos da sua plataforma no

95
comando de criação de um banco de dados, como mostrado no exemplo
abaixo entre o comando no SQL Server versus no Oracle:

Figura 79 – Create Database SQL Server x Oracle.

Fonte: o autor.

Para criar as tabelas, que são as estruturas onde os dados são

inseridos, consultados e manipulados, usa-se o comando SQL CREATE
TABLE. No SQL Server, sua sintaxe básica é:

CREATE TABLE <Nome_da_Tabela>

(
column1 datatype [ NULL | NOT NULL ],
column2 datatype [ NULL | NOT NULL ], …..
);
Um exemplo de código para criar uma tabela de nome ALUNO seria:

CREATE TABLE ALUNO

(
COD_ALUNO int NOT NULL,
NOM_ALUNO varchar(100) NOT NULL
);
Outro tipo de objeto muito comum, criado com o comando CREATE
da classe DDL da Linguagem SQL, é o sinônimo. Um objeto desse tipo

96
fornece um nome alternativo para outro objeto (tabela, view, função etc.) do
banco de dados. No SQL Server sua sintaxe básica é:

CREATE SYNONYM <Nome_do_Sinônimo> FOR <Nome_do_Objeto>;

Um exemplo de código para criar um sinônimo de nome

TB_ALUNO_NEW para a tabela de nome ALUNO seria:

CREATE SYNONYM TB_ALUNO_NEW FOR ALUNO;

Existem várias outras possibilidades de utilização da instrução

CREATE, bem como outros comandos SQL da classe DDL que ao longo do
curso serão mostrados, à medida que formos aprofundando na Linguagem
SQL.

Demonstração: Criação de Estruturas de Dados

Vide aula 7.2. Demonstração: Criação de Estruturas de Dados.

Alteração de Estruturas de Dados

É normal que, após a criação das estruturas de dados, surjam
necessidades de alteração das mesmas. Na maioria das vezes, não é
necessário recriá-las para aplicar essa alteração, uma vez que a Linguagem
SQL fornece o comando ALTER para esse tipo de situação. Com esse tipo de
comando, é possível por exemplo, desde que não viole as regras de
unicidade, adicionar uma chave primária a uma tabela já criada, como
demonstrado na sintaxe a seguir:

ALTER TABLE ALUNO

ADD CONSTRAINT PK_ALUNO PRIMARY KEY CLUSTERED
( COD_ALUNO );

Com o comando ALTER, é possível também adicionar uma nova

coluna a uma tabela que já esteja criada, como mostrado no exemplo abaixo:

--Adicionar Coluna COD_CURSO_FK na tabela ALUNO

97
 ALTER TABLE ALUNO ADD COD_CURSO_FK int NULL;

Da mesma forma, desde que os dados existentes na tabela não

violem as regras de nulidade e de tipos de dados, é possível também alterar
algumas definições e propriedades de colunas já existentes em uma tabela,
como mostrado nos comandos de exemplo abaixo:

--Alterar Coluna COD_CURSO_FK Para Não Nula

ALTER TABLE ALUNO ALTER COLUMN COD_CURSO_FK int NOT NULL;

--Alterar Tamanho da Coluna NOM_CURSO

ALTER TABLE CURSO

ALTER COLUMN NOM_CURSO varchar(200) NOT NULL;

Outra possibilidade com o comando ALTER, desde que as regras de

integridade referencial dos dados não sejam violadas, é adicionar uma chave
estrangeira entre duas tabelas que já estejam criadas, como no exemplo
abaixo:

--Adicionar Chave Estrangeira COD_CURSO_FK na Tabela ALUNO

ALTER TABLE ALUNO
ADD CONSTRAINT FK_ALUNO_CURSO FOREIGN KEY
( COD_CURSO_FK ) REFERENCES CURSO
( COD_CURSO )
ON UPDATE NO ACTION
ON DELETE NO ACTION;

Existem várias outras possibilidades de utilização da instrução

ALTER, e algumas delas serão utilizadas nos capítulos seguintes, à medida
que formos aprofundando na Linguagem SQL.

Remoção de Estruturas de Dados

Um comando muito útil da linguagem SQL, também pertencente à
classe DDL, é o DROP. Com ele é possível remover as estruturas de dados e

98
demais objetos de um banco de dados, devendo ser usado com muita
cautela e atenção para não remover objetos por engano.

Usando o DROP pode-se remover banco de dados, tabelas, views,

funções, índices etc., como mostrado nos exemplos a seguir.

--Remover Sinônimo

DROP SYNONYM TB_ALUNO_NEW;

--Remover Banco de Dados

DROP DATABASE BDTESTE_DROP;

--Remover Tabela (Com FK)

DROP TABLE ALUNO;

Uma observação importante é quanto à remoção de alguns recursos

que não são considerados objetos independentes, como por exemplo,
colunas de uma tabela. Nesse caso, deve-se usar o comando ALTER, uma vez
que o objeto a ser alterado é a tabela onde a coluna se encontra, em conjunto
com o comando DROP, como demonstrado abaixo.

--Remover Coluna NOM_ALUNO da tabela ALUNO

ALTER TABLE ALUNO DROP COLUMN NOM_ALUNO;

Selecionando Dados
Sem sombra de dúvidas, os comandos da linguagem SQL para
manipulação de dados, pertencentes à classe DML (Data Manipulation
Language), são os comandos mais usados em sistemas de bancos de dados
relacionais.

Inicialmente, vamos falar do comando SELECT, usado para

selecionar dados de forma a exibi-los ao usuário. Apesar de alguns
atribuírem o comando SELECT à classe DQL (Data Query Language), no

99
padrão ISO / IEC 9075: 2016 ele pertence à classe DML. A classe DQL
pertence a um outro padrão, menos conhecido da Linguagem SQL, chamado
ODMG, que não é o foco deste curso.

Como introduzido acima, na Linguagem SQL a instrução utilizada

para retornar (consultar) os dados armazenados no banco de dados é o
SELECT. Essa instrução, baseada na operação de projeção da Álgebra
Relacional, retorna as colunas e seus respectivos dados, no formato tabular.
Em sua estrutura mais simples (forma mínima), é composto de duas
cláusulas:

i. SELECT <relação de colunas ou * >: declaração informando que o

comando se trata de uma consulta, seguida da relação de colunas
que se deseja exibir no resultado. Caso se utilize o * (asterisco) no
lugar da lista de colunas, serão retornadas todas as colunas que
existirem no objeto em questão (especificado na cláusula FROM), no
momento da execução do comando.

ii. FROM: origem dos dados, ou seja, o nome do(s) objeto(s) onde estão
os dados que serão selecionados.

Para exemplificar as duas opções existentes para formar a lista com

a relação de colunas a serem exibidas, pode-se executar no banco de dados
de exemplo AdventureWorks2019 usado neste curso, os seguintes
comandos:

--Selecionar todas as linhas das colunas Name e ProductNumber da

tabela Product

SELECT Name, ProductNumber

FROM Production.Product;

--Selecionar todas as linhas de todas as colunas da tabela Product

100
 SELECT *

FROM Production.Product;

Um recurso muito interessante e útil, que pode ser usado tanto para
nomes de colunas quanto de tabelas, é o alias. Com ele é possível criar um
nome alternativo (apelido), existente apenas em tempo de execução, para
cada coluna / tabela em um comando SQL.

No caso de alias de colunas, é criado usando-se a cláusula AS após

o nome da coluna, colocando-se o alias desejado em seguida, como
mostrado abaixo:

SELECT Name AS Nome_do_Produto, ProductNumber AS

Número_Produto

FROM Production.Product;

O efeito prático da utilização de alias para colunas é modificar o

cabeçalho (label) da coluna que é exibido no resultado da query, como no
exemplo abaixo:

Figura 80 – Alias de Coluna.

Fonte: o autor.

Para alias de tabelas, o uso é bem mais amplo, permitindo que o alias
seja usado em outras cláusulas da instrução SELECT, como por exemplo, nas

101
cláusulas WHERE, GROUP BY, ORDER BY etc., que serão vistas mais à frente.
Além disso, a utilização de alias é muito útil nas situações em que existem
colunas com o mesmo nome em tabelas diferentes participando do mesmo
comando SQL, sendo necessário distinguir cada coluna (veremos isso mais
a frente quando falarmos de junção de tabelas).

Para se criar um alias para tabela, pode-se usar, na cláusula FROM,

a cláusula AS após o nome da tabela seguido do alias desejado, ou
simplesmente omitir a cláusula AS e colocar o alias após o nome da tabela,
como mostrado nos exemplos abaixo.

--Alias de Tabela Criado com a Cláusula AS

SELECT Name, ProductNumber FROM Production.Product AS P;

--Alias de Tabela Criado sem a Cláusula AS

SELECT Name, ProductNumber FROM Production.Product P;

Uma vez definido o alias para uma tabela, ele pode ser referenciado
na relação de colunas da cláusula SELECT, como exemplificado abaixo.

--Alias de Tabela nas Colunas

SELECT P.Name, P.ProductNumber FROM Production.Product P;

OBS.: ao se definir alias de tabelas, não é obrigatório usá-los na

relação de colunas, desde que não haja ambiguidade nos nomes das colunas.

Alias de tabela pode ser usado em conjunto com alias de colunas,

como mostrado no exemplo abaixo:

--Alias de Tabela + Alias de Coluna

SELECT P.Name AS Nome_do_Produto, P.ProductNumber AS

Número_Produto

102
 FROM Production.Product P;

Um outro recurso muito útil, que pode ser utilizado na instrução

SELECT, é a expressão CASE. Esse tipo de expressão compara um valor de
entrada a uma lista de possíveis valores correspondentes, funcionando da
seguinte maneira:

• Se uma correspondência for encontrada, o primeiro valor

correspondente será retornado como resultado da expressão CASE.
Dessa forma, múltiplas correspondências não são permitidas;

• Se nenhuma correspondência for encontrada, a expressão CASE

retorna o valor encontrado em uma cláusula ELSE, se existir;

• Se nenhuma correspondência for encontrada e nenhuma cláusula

ELSE existir, a expressão CASE retornará NULL.

No exemplo a seguir está sendo usada a expressão CASE na coluna

ProductSubcategoryID¸ de forma que retorne o valor ‘Mountain Bikes’ se o
valor da coluna for igual a 1, 'Road Bikes' se for igual a 2, ‘Touring Bikes’ se
for igual a 3, e 'Unknown Category' caso não seja nenhum dos três valores.

SELECT ProductID, Name, ProductSubcategoryID,

CASE ProductSubcategoryID
WHEN 1 THEN 'Mountain Bikes'
WHEN 2 THEN 'Road Bikes'
WHEN 3 THEN 'Touring Bikes'
ELSE 'Unknown Category'
END AS SubCategoryName
FROM Production.Product;

103
 Figura 81 – Resultado da Expressão Case acima.

Fonte: o autor.

Demonstração: Selecionando Dados

Vide aula 7.6. Demonstração: Selecionando Dados.

Ordenando Dados
Além das cláusulas SELECT e FROM, uma instrução SELECT pode ter
também a cláusula ORDER BY. Essa cláusula é opcional, e é utilizada para
ordenar os dados retornados pela instrução SELECT.

Com relação à sintaxe, ela é a última cláusula em uma instrução

SELECT e, por default, ao utilizá-la, a ordenação é feita de forma ascendente
(A a Z, 0 a 9). Entretanto, pode-se usar as opções ASC (ascendente) ou DESC
(descendente, de Z a A, 9 a 0) para personalizar a ordem de exibição dos
dados.

--Classificando Ascendentemente pelo Primeiro Nome

SELECT FirstName, MiddleName, LastName

FROM Person.Person Similar a
ORDER BY FirstName; ORDER BY FirstName ASC;

--Classificando Descendentemente pelo Primeiro Nome

SELECT FirstName, MiddleName, LastName

104
 FROM Person.Person
ORDER BY FirstName DESC;

Figura 82 – ORDER BY ASC x ORDER BY DESC.

Fonte: o autor.

Outra possibilidade da cláusula ORDER BY é usar mais de uma

coluna para ordenar o resultado, cada uma deles com sua ordem desejada
(ascendente ou descendente).

--Classificando Ascendentemente pelo Primeiro Nome e

Descendentemente pelo Último Nome

SELECT FirstName, MiddleName, LastName

FROM Person.Person
Ordenação descendente pela
ORDER BY FirstName ASC, LastName DESC; coluna LastName

Figura 83 – ORDER BY ASC x ORDER BY DESC.

Fonte: o autor.

105
 Uma flexibilidade muito interessante dessa cláusula é que a(s)
coluna(s) usada(s) no ORDER BY não necessariamente precisam estar na
lista de colunas da cláusula SELECT, como mostrado no exemplo a seguir.

--Ordenando por uma Coluna que não Está na Lista de Colunas do

SELECT

SELECT FirstName, MiddleName, LastName

FROM Person.Person

ORDER BY ModifiedDate ASC;

Para além disso, uma outra possibilidade que existe na cláusula

ORDER BY é usar alias de coluna para determinar a ordenação, ao invés de
usar o nome das colunas, como mostrado a seguir.

--Usando Alias de Coluna no ORDER BY

SELECT Name AS Nome_do_Produto,

ProductNumber AS Número_do_Produto
FROM Production.Product
ORDER BY Nome_do_Produto ASC;

Demonstração: Ordenando Dados

Vide aula 7.8. Demonstração: Ordenando Dados.

Filtrando Dados
Além da operação de projeção da Álgebra Relacional vista até agora
(especificação das colunas a serem retornadas), a Linguagem SQL também
possui cláusulas para realizar a operação de seleção (restrição). Com essas
cláusulas é possível restringir as tuplas (linhas/dados) retornados pela
operação de projeção (cláusula SELECT).

106
 A primeira delas, e a mais conhecida de todas, é a cláusula WHERE.
Em termos de sintaxe, ela é usada após a cláusula FROM e utiliza-se dos
operadores lógicos ou de comparação para filtrar os resultados retornados.

No exemplo a seguir, a cláusula WHERE está sendo usada para

retornar as colunas com o nome e a cor, somente dos produtos que sejam
da cor preta:

--Listar Produtos da Cor Preta (Black)

SELECT Name, Color

FROM Production.Product
WHERE Color = 'Black'
ORDER BY Name;

Em termos de operadores, cada SGBD procura manter o respectivo

caractere indicado no padrão ISO, mas nada impede que existam outros
operadores ou operadores representados por caracteres diferentes em
alguns SGBDs.

No SQL Server, os operadores de comparação existentes são:

Operador de Significado
Comparação
= Igual a
> Maior que
< Menor que
>= Maior que ou igual a
<= Menor que ou igual a
<> Diferente de
!= Diferente de (não é padrão ISO)
!> Não é maior que (não é padrão ISO)
!< Não é menor que (não é padrão ISO)

107
 Na cláusula WHERE, em conjunto com os operadores de
comparação, pode-se utilizar também os operadores lógicos, permitindo
que mais de uma condição (filtro) possa ser realizada na operação de
restrição da instrução SELECT.

No exemplo a seguir, o operador lógico OR (ou) está sendo utilizado

junto à cláusula WHERE para retornar as informações de nome e cor,
somente dos produtos que sejam da cor preta ou da cor prata:

--Listar Produtos da Cor Preta (Black) ou Prata (Silver)

SELECT Name, Color

FROM Production.Product
WHERE Color = 'Black'
OR Color = 'Silver'
ORDER BY Name;

Na prática, os operadores lógicos testam a verdade de alguma

condição, retornando um tipo de dado booleano com o valor TRUE, FALSE
ou UNKNOWN. No SQL Server, os operadores lógico existentes são:

Operador Significado

ALL TRUE se todas as comparações forem verdadeiras

AND TRUE se ambas as expressões booleanas forem verdadeiras

ANY TRUE se qualquer um de um conjunto de comparações for verdadeiro

BETWEEN TRUE se o operando/expressão estiver dentro de um intervalo

EXISTS TRUE se uma subconsulta contiver quaisquer linhas

IN TRUE se o operando for igual a um de uma lista de valores/expressões

LIKE TRUE se o operando corresponder a um padrão

NOT Inverte o valor de qualquer outro operador booleano

OR TRUE se qualquer expressão booleana for TRUE

SOME TRUE se algumas das comparações forem verdadeiras

108
 Nas aulas gravadas, são mostrados mais exemplos acerca da
utilização dos operadores lógicos, mas por ora é preciso acrescentar que
assim como os operadores aritméticos, os operadores lógicos e de
comparação também podem ser usados em conjunto. Dessa forma, é preciso
se atentar também à ordem de avaliação de cada um deles pelo SGBD em
questão.

No SQL Server, os operadores lógicos e de comparação são

avaliados após os operadores aritméticos e de concatenação. Entre si, os
operadores lógicos e de comparação são avaliados na seguinte ordem
(sequência):

1º ➔ =, >, <, <=, <, !=, !, !<, !> (operadores de comparação)

2º ➔ NOT

3º ➔AND

4º ➔ ALL, ANY, BETWEEN, IN, LIKE, OR, SOME

Dessa forma, para que o operador OR, por exemplo, seja avaliado
antes do operador AND, deve-se usar parênteses, como no exemplo abaixo.
Sem os parênteses, a avaliação da expressão lógica AND seria feita primeiro,
para depois avaliar-se a expressão com o operador OR:

-- Produtos com Nome que Iniciam com 'Chain' e que Sejam da Cor
Preta ou Prata

SELECT Name,Color
FROM Production.Product
WHERE Name LIKE 'Chain%'
AND (Color = 'Black' OR Color = 'Silver')
ORDER BY Name;

109
 --Produtos com Nome que Iniciam com 'Chain' e que Sejam da Cor
Preta, ou Todos os Produtos da Cor Prata

SELECT Name,Color FROM Production.Product

WHERE Name LIKE 'Chain%'
AND Color = 'Black' OR Color = 'Silver'
ORDER BY Color;
Com relação à utilização de alias de coluna, ao contrário do que
ocorre na cláusula ORDER BY onde é possível utilizá-lo, na cláusula WHERE
não. Isso ocorre devido ao fato da cláusula WHERE ser processada antes da
cláusula SELECT, de forma que o alias ainda não está definido quando o filtro
é aplicado.

Figura 84 – Erro ao Usar Alias na Cláusula WHERE.

Fonte: o autor.

Demonstração: Filtrando Dados

Vide aula 7.10. Demonstração: Filtrando Dados.

Inserindo Dados
Para inserir uma ou mais linhas em uma tabela, ação essa também
referida como persistir dados, é usado o comando INSERT. Apesar de
existirem outras formas de inserir dados em uma tabela, como por exemplo
usando-se os comandos de carga massiva de dados (operações de bulkload),
o comando INSERT é o mais usado.

110
 Sua sintaxe mais simples é mostrada abaixo, sendo que a lista de
colunas é opcional, mas ao informá-las, o código fica mais autoexplicativo e
seguro, diminuindo o risco de inserção de valores de uma coluna em outra,
e sendo possível também definir a ordem de inserção dos valores das
colunas na tabela. Ao não informar a lista de colunas, é preciso inserir os
valores para as colunas na ordem em que as colunas estão criadas na tabela.

INSERT [INTO] <Tabela ou visão> [lista_de_colunas]

VALUES (Valor | Expressão | NULL | DEFAULT)

Supondo que exista uma tabela de nome TAB1, com as colunas COL1
e COL2, ambas do tipo de dados numérico, o comando para inserir uma linha
nessa tabela ficaria algo como:

INSERT INTO TAB1 (COL1, COL2)

VALUES (100, 500);

Omitindo a lista de colunas, ficaria como mostrado abaixo, indicando

que o valor 100 seria inserido na primeira coluna da tabela TAB1 e o valor
500 na segunda coluna.

INSERT INTO TAB1

VALUES (100, 500);

Supondo agora que COL2 fosse do tipo de dados string, o valor ou

expressão a ser inserida precisa ser colocado entre aspas simples (‘ ’), como
demonstrado abaixo:

INSERT INTO TAB1 (COL1, COL2)

VALUES (100, ‘Valor não numérico’);

111
 Para as situações em que a coluna aceita valores nulos e deseja-se
omitir o valor a ser inserido, deve especificar NULL na lista de valores a
serem inseridos:

INSERT INTO TAB1 (COL1, COL2)

VALUES (100, NULL);

Nos casos em que a coluna foi criada com um valor default e deseja-
se inserir esse valor, deve especificar DEFAULT na lista de valores a serem
inseridos, como mostrado no exemplo a seguir:

Figura 85 – INSERT com DEFAULT.

Fonte: o autor.

Usando apenas um comando INSERT, é possível inserir mais de

uma linha de uma só vez, bastando separar as várias cláusulas VALUES com
vírgula. No nosso exemplo anterior, se desejássemos inserir 3 linhas, o
comando ficaria como:

INSERT INTO TAB1 (COL1, COL2)

VALUES (100, ‘Valor não numérico’) ,
(200, ‘Valor não numérico 2’) ,
(300, ‘Valor não numérico 3’);

Uma possibilidade muito interessante do comando INSERT é

utilizar uma consulta SELECT em outra tabela ou conjunto de tabelas para
retornar os valores a serem inseridos na tabela em questão. No nosso

112
exemplo, supondo que tivéssemos também a tabela TAB2 com as colunas
COL3 (numérica), COL4 (numérica) e COL5 (string), e desejássemos inserir
na TAB1 todos os valores da COL4 e COL5 da tabela TAB2, o comando ficaria
como mostrado abaixo.

INSERT INTO TAB1 (COL1, COL2)

SELECT COL4, COL5 FROM TAB2;

Outra possibilidade de inserir dados em uma tabela é usando a

cláusula SELECT INTO. Essa cláusula é similar à INSERT INTO SELECT, com
a exceção de que a tabela destino dos dados não pode estar criada, visto que
a cláusula SELECT INTO criará a tabela em tempo de execução.

Essa nova tabela é criada com a estrutura física definida pela lista de
colunas na cláusula SELECT. Cada coluna na nova tabela terá o mesmo
nome, tipo de dados e anulabilidade da coluna correspondente (ou
expressão) da lista de colunas na cláusula SELECT. Entretanto, índices e
constraints não são criados na nova tabela. A sintaxe para essa opção é
mostrada abaixo.

SELECT coluna1, coluna2, …

INTO Nova_Tabela FROM Tabela_Origem;

Figura 86 – SELECT INTO.

Fonte: o autor.

113
Atualizando Dados
Para alterar dados existentes em uma tabela ou visão, a Linguagem
SQL fornece a instrução UPDATE. Essa instrução opera em um conjunto de
linhas definido por uma condição em uma cláusula WHERE ou join, que
possui a mesma estrutura que uma cláusula WHERE em uma instrução
SELECT e pode-se valer dos mesmos recursos. Para atribuir o novo valor à
coluna, é usada a cláusula SET, que permite também a atualização dos
valores de uma ou mais colunas, separadas por vírgulas.

Dessa forma, a sintaxe da instrução UPDATE, em linhas gerais, é:

UPDATE <Nome_Tabela>

SET <Coluna1> = { valor | expressão | DEFAULT | NULL },

<Coluna2> = { valor | expressão | DEFAULT | NULL },

<ColunaN> {…n}

WHERE <Condição>;

Considerando os valores da tabela TAB2 do exemplo mostrado na

figura 86, se quiséssemos atualizar os valores da coluna COL3 para 500, de
todas as linhas onde o valor da coluna COL1 fossem iguais a 10, o comando
SQL ficaria algo como:

UPDATE TAB2
SET COL3 = 500
WHERE COL1 = 10;

Importante destacar que se não for especificada a cláusula WHERE,

a atualização será feita para todas as linhas da tabela. Dessa forma, omitindo
a cláusula WHERE no exemplo anterior, não mais atualizaríamos apenas as
linhas onde o valor da coluna COL1 fossem iguais a 10 e sim todas as linhas
da tabela.

UPDATE TAB2 SET COL3 = 500;

114
 Como informado inicialmente, é perfeitamente possível atualizar
mais de uma coluna de uma vez, bastando separá-las por vírgula. Dessa
forma, se no exemplo, quiséssemos atualizar os valores da coluna COL3 para
500 e da coluna COL1 para 600, de todas as linhas onde o valor da coluna
COL1 fosse igual a 10, o comando SQL ficaria algo como:

UPDATE TAB2
SET COL3 = 500, COL1 = 600
WHERE COL1 = 10;

Excluindo Dados
Para excluir dados existentes em uma tabela ou visão, a Linguagem
SQL fornece a instrução DELETE. Essa instrução, assim como a cláusula
UPDATE, opera em um conjunto de linhas definido por uma condição em
uma cláusula WHERE ou join, que possui a mesma estrutura que uma
cláusula WHERE em uma instrução SELECT e pode-se valer dos mesmos
recursos. Sua sintaxe na forma mais simples é:

DELETE FROM <Nome_Tabela>

WHERE <Condição>;

Considerando os valores da tabela TAB2 do exemplo mostrado na

figura 86, se quiséssemos excluir as linhas onde o valor da coluna COL1
fossem iguais a 10, o comando SQL ficaria algo como:

DELETE FROM TAB2

WHERE COL1 = 10;

Importante destacar que se não for especificada a cláusula

WHERE, todas as linhas da tabela serão excluídas. Dessa forma, omitindo
a cláusula WHERE no exemplo anterior, não mais excluiríamos apenas as
linhas onde o valor da coluna COL1 fossem iguais a 10 e sim todas as linhas
da tabela.

DELETE FROM TAB2;

115
 Para as situações em que se deseja excluir todos os dados de uma
tabela, por questões de performance é preferível usar o comando
TRUNCATE da classe DDL da Linguagem SQL. Esse comando remove todas
as linhas de uma tabela sem registrar as exclusões de linhas
individualmente, consumindo menos recursos do servidor de banco de
dados e executando mais rápido que o DELETE sem a cláusula WHERE. Sua
sintaxe é TRUNCATE TABLE <Nome_da_Tabela>.

Assim como no comando UPDATE, é possível utilizar uma

subconsulta ou JOIN para retornar / obter os valores para as condições de
exclusão, como mostrado nos exemplos abaixo, retirados da documentação
da Microsoft:

--Usando subconsulta

DELETE FROM Sales.SalesPersonQuotaHistory

WHERE BusinessEntityID IN (
SELECT BusinessEntityID
FROM Sales.SalesPerson
WHERE SalesYTD > 2500000
)
Para além disso, e contemplando as necessidades de certas
operações no banco de dados onde é preciso atualizar, inserir ou excluir
linhas de uma tabela, existe o comando MERGE. Com essa instrução é
possível inserir, atualizar e até excluir linhas de uma tabela, com base em
um join com um conjunto de dados de origem, tudo em uma única
instrução.

O comando MERGE atua nos dados de uma tabela destino, com base
em uma ou mais condições de decisão mostradas abaixo, acerca de qual
operação (INSERT/UPDATE/DELETE) será executada:

116
 • Quando os dados de origem correspondem aos dados no destino,
ocorre a atualização dos dados.

• Quando os dados de origem não têm correspondência no destino,

ocorre a inserção desses dados.

• Quando os dados de destino não têm correspondência no conjunto

de dados de origem, ocorre a exclusão dos dados na tabela de
destino.

A sintaxe do comando MERGE na sua forma mais simples é:

MERGE
[ INTO ] <Tabela_Destino>
USING <Conjunto de Dados de Origem>
ON <Condição de Comparação para o Merge >
[WHEN MATCHED
THEN <Operação Quando Há Correspondência>]
[WHEN NOT MATCHED BY TARGET
THEN < Operação Quando Não Há Correspondência no Destino>]
[ WHEN NOT MATCHED BY SOURCE
THEN < Operação Quando Não Há Correspondência na Origem>]

Para exemplificar, na query abaixo deseja-se atualizar os campos

Data_Venda e Valor quando a venda já existir na tabela, e inserir a linha
(colunas Id_Venda, Origem.Data_Venda, Origem.Produto, Origem.Qtde e
Origem.Valor) quando a venda ainda não existir:

MERGE TAB_Venda_Destino AS Destino

USING TAB_Venda_Origem AS Origem ON (Origem.Id_Venda =
Destino.Id_Venda)
WHEN MATCHED THEN -- Registro existe nas 2 tabelas
UPDATE SET

117
 Destino.Data_Venda = Origem.Data_Venda,
Destino.Valor = Origem.Valor
WHEN NOT MATCHED THEN --Registro não existe no destino e deve ser
inserido
INSERT
VALUES (Origem.Id_Venda, Origem.Data_Venda, Origem.Produto,
Origem.Qtde, Origem.Valor);

118
8
Capítulo 8. Segurança no SQL Server
Introdução à Segurança no SQL Server
Uma preocupação constante, principalmente na era da informação
que nos encontramos, é com relação a proteção dos dados armazenados. Na
camada de banco de dados. Essa proteção deve ser feita externamente ao
SGBD (proteção do servidor, firewall, segmentação de rede, mecanismos
para evitar invasões e ataques de negação de serviço etc.), bem como
internamente.

Dentro do SGBD, a proteção aos objetos e dados, em termos de

permissão de acesso ou permissão para executar uma ação (comando), é
configurada através da Linguagem de Controle de Acesso a Dados (Data
Control Language - DCL), uma classe da Linguagem SQL também. Dentro
dessa linguagem, os comandos mais conhecidos e utilizados são:

✓ GRANT: comando DCL usado para conceder permissões em objetos

ou permissões para executar algum comando.

✓ REVOKE: comando DCL usado para remover permissões em objetos

ou permissões para executar algum comando.

Com relação aos objetos que podem ser protegidos, os mecanismos

e a granularidade de proteção, cada SGBD disponibiliza sua gama de
recursos e comandos para habilitar, configurar e gerenciar seu framework de
segurança. A título de exemplo, o SQL Server fornece os componentes
abaixo para controlar quais usuários podem fazer logon no SQL Server, quais
dados eles podem acessar e quais operações eles podem executar:

✓ PERMISSION (Privilégio): permissão para executar alguma ação, ou

seja, executar algum comando SQL.

120
✓ ROLE (Papel): conjunto de privilégios que pode ser concedido a
usuários ou a outras roles. São criadas com o comando CREATE
ROLE da classe DDL da Linguagem SQL.

✓ PRINCIPALS (Entidades): usuários, grupos ou processos com

acesso concedido a uma instância do SQL Server, no nível do servidor
ou do banco de dados. As entidades no nível do servidor incluem
logins e roles de servidor (server roles). As entidades no nível do
banco de dados incluem usuários e roles de banco de dados
(database roles). Também são criados usando-se o comando
CREATE da classe DDL.

--Exemplo de comando para criar uma PRINCIPAL do tipo login:

CREATE LOGIN UsrXPE

WITH PASSWORD = 'Pa55w.rd',

DEFAULT_DATABASE = [BDXPE];

✓ SECURABLES: objetos, no nível do servidor ou do banco de dados,

nos quais são concedidas as permissões para os principals.

Figura 87 – Principals, Permissions e Securables.

Fonte: Microsoft.

121
 Figura 88 – Principals e Securables.

Fonte: Microsoft.

Concessão e Revogação de Privilégios

As permissões em bancos de dados relacionais são gerenciadas
usando-se as instruções GRANT e REVOKE da classe DCL da Linguagem
SQL. As permissões que se aplicam a tabelas ou a views, para acessar ou
manipular dados, são SELECT, INSERT, UPDATE e DELETE.

No exemplo abaixo, está sendo concedida a permissão de SELECT na

tabela Address do schema (owner) Person, para o usuário
UsrAdventureSystem.

GRANT SELECT ON [Person].[Address] TO UsrAdventureSystem;

122
 Já no exemplo abaixo, estão sendo concedidas as permissões de
SELECT, INSERT, DELETE e UPDATE na tabela Product do schema (owner)
Production, para o usuário UsrAdventureSystem.

GRANT SELECT, INSERT, DELETE, UPDATE ON [Production].[Product]

TO UsrAdventureSystem;

Uma opção bem útil na instrução GRANT é permitir que o usuário

que recebeu uma permissão possa concedê-la para outro usuário. Essa
possibilidade é feita com a cláusula WITH GRANT OPTION. No exemplo
abaixo, está sendo concedida a permissão de DELETE na tabela
DatabaseLog para o usuário UsrAdventureSystem, e permitindo que ele
possa conceder essa permissão para outro usuário.

GRANT DELETE ON DatabaseLog

TO UsrAdventureSystem WITH GRANT OPTION;

Da mesma forma que as permissões para permitir a execução de

comandos DML, estão disponíveis as permissões para permitir a execução
de comandos DDL. No exemplo abaixo, está sendo concedida a permissão de
criar tabela para o usuário UsrAdventureSystem.

GRANT CREATE TABLE TO UsrAdventureSystem;

Por outro lado, para se remover uma permissão, usa-se a cláusula

REVOKE, cuja sintaxe pode ser observada no exemplo abaixo, em que está
sendo removida a permissão de DELETE na tabela DatabaseLog, do usuário
UsrAdventureSystem.

REVOKE DELETE ON DatabaseLog FROM UsrAdventureSystem;

Muitas outras permissões e opções de segurança podem ser

configuradas no SGBD, mas para efeitos do padrão ISO da Linguagem SQL,
as instruções GRANT e REVOKE são suficientes para entender a
funcionalidade da classe DCL.

123
9
Capítulo 9. Backup no SQL Server
Conceitos Básicos de Backup

• Periodicidade: qual a frequência de execução do backup. Diária,

mensal, semanal, de hora em hora etc.

• Retenção: quanto tempo cada backup que foi realizado é guardado,

ou seja, durante quanto tempo estará disponível.

• Tipos de Backup

– FULL: backup completo do banco de dados (estruturas, dados,

código, usuários, privilégios no banco de dados etc.).

– DIFERENCIAL (DIFF): backup das alterações ocorridas desde

o último backup full executado.

– LOG: backup de logs de transações que inclui todos os

registros de log dos quais não foi feito backup em um backup
de log anterior. Possibilita o recovery-point-in-time (restore
até um horário específico).

• Recovery Time Objective (RTO): tempo dentro do qual um processo

de negócios deve ser restaurado, após um desastre, para evitar
consequências inaceitáveis associadas a uma interrupção na
continuidade do serviço. Tempo que se leva para restaurar o banco
de dados.

• Recovery Point Objective: quantidade máxima aceitável de perda de

dados após um incidente de perda de dados não planejado, expresso
como uma quantidade de tempo.

125
 • Política de Backup: conjunto de regras e procedimentos que
descrevem a estratégia da empresa ao fazer cópias de segurança dos
dados para fins de segurança. Periodicidade + Retenção + Tipo(s) de
Backup(s) + RTO + RPO + Ferramenta + Infraestrutura + Processos.

Fazendo Backup no SQL Server

Para fazer backup de banco de dados no SQL Server, utiliza-se os
comandos da Linguagem T-SQL, que possuem a seguinte sintaxe:

--Backup FULL / DIFF

BACKUP DATABASE { database_name }

TO <backup_device>

[ WITH { DIFFERENTIAL | <general_WITH_options> [ ,...n ] } ]

--Backup de LOG

BACKUP LOG { database_name}

TO <backup_device>

[ WITH { <general_WITH_options> | \<log-specific_optionspec> } [

,...n ] ]

A documentação completa com todas as opções e possibilidades de

backup, no SQL Server, podem ser encontradas na documentação oficial do
produto, disponível em https://learn.microsoft.com/en-us/sql/t-
sql/statements/backup-transact-sql.

Outra opção bem interessante e fácil de se utilizar para a execução

de um backup no SQL Server são as interfaces gráficas como a do SQL Server
Management Studio.

126
Figura 89 – Interface Gráfica do SSMS para Backup no SQL Server.

Fonte: Microsoft.

127
Referências
AMERICAN National Standards Institute. The SQL Standard – ISO/IEC
9075:2016. Out. 2018. Disponível em: <https://blog.ansi.org/2018/10/sql-
standard-iso-iec-9075-2016-ansi-x3-135/>. Último acesso: 04, Abr 2020.

CHAMBERLIN, Donald D. et al. A History and Evaluation of System R. v. 24,

n. 10. San Jose, California: Communications of the ACM, IBM, out. 1981.
Disponível em:
<https://people.eecs.berkeley.edu/~brewer/cs262/SystemR.pdf>. Último
acesso: 04, Abr 2020.

CHAMBERLIN, Donald D.; BOYCE, Raymond F. SEQUEL: A Structured English

Query Language. San Jose, California: IBM Research Laboratory. Disponível
em: <http://www.joakimdalby.dk/HTM/sequel.pdf>. Último acesso: 04, Abr
2020.

CHEN, Peter. Modelagem de Dados. São Paulo: McGraw-Hill, Makron, 1990.

CHEN, Peter. Peter Chen Home Page at Louisiana State University (LSU).
Disponível em: <https://www.csc.lsu.edu/~chen>. Último acesso: 01, Mai
2020.

CHEN, Peter. The Entity-Relationship Model - Toward a Unified View of

Data. Massachusetts: Center for Information Systems Research, mar. 1977.
Disponível em:
<https://dspace.mit.edu/bitstream/handle/1721.1/47432/entityrelationshx
00chen.pdf>. Último acesso em 01, Ma1 2020.

CODD, Edgar F. A Relational Model of Data for Large Shared Data Banks.
GitHub, jan. 2017Disponível em
<https://github.com/dmvaldman/library/blob/master/computer%20science
/Codd%20-

128
%20A%20Relational%20Model%20of%20Data%20for%20Large%20Shar
ed%20Data%20Banks.pdf>. Último acesso em 03, Mar 2020.

CODD, Edgar F. The Relational Model for Database Management: Version

2. EUA: Addison Wesley Publishing Company, 1990.

CODD’s Twelve Rules. Disponível em:

<https://computing.derby.ac.uk/c/codds-twelve-rules>. Último acesso: 09,
Mar. 2020.

COUGO, Paulo. Modelagem Conceitual e Projeto de Banco de Dados. 14ª

reimpressão. Rio de Janeiro: Elsevier, 1997.

GARTNER Glossary. Disponível em

<https://www.gartner.com/en/information-technology/glossary/big-data>.
Último acesso: 02 de Maio 2021.

HILLS, Ted. NOSQL and SQL Data Modeling: Bringing Together Data,
Semantics, and Software. Technics Publications, 2016.

KIM, JAMES. UnQL Query Language Unveiled by Couchbase and SQLite.

Couchbase, jul. 2011. Disponível em <https://www.couchbase.com/press-
releases/unql-query-language>. Último acesso: 11, Mar. 2019.

KORTH, Henry F. Sistema de bancos de dados. 3. ed. São Paulo: McGraw-Hill,

1999.

MACHADO, Felipe Nery Rodrigues; ABREU, Maurício Pereira de. Projeto de

Banco de Dados: uma visão prática. 13. ed. São Paulo: Érica, 1996.

MANYIKA, James et al. Big data: The next frontier for innovation,
competition, and productivity. McKinsey Global Institute, mai. 2011.
Disponível em <https://www.mckinsey.com/business-functions/mckinsey-
digital/our-insights/big-data-the-next-frontier-for-innovation>. Último
acesso: 02 de Maio 2021.

129
MICHAELIS. Dicionário da Língua Portuguesa Brasileira. Disponível em:
<https://michaelis.uol.com.br/moderno-portugues>. Último acesso:
05/04/2019.

MICROSOFT SQL Documentation. Disponível em

<https://docs.microsoft.com/en-us/sql/?view=sql-server-2019>. Último
acesso: 14, Out. 2022.

MICROSOFT SQL Server 2019. Disponível em

<https://www.microsoft.com/pt-br/sql-server/sql-server-2019>. Último
acesso: 14, Out. 2022.

MONGODB. Site Oficial do Fabricante. Disponível em

<https://www.mongodb.com>. Último acesso: 17, Out. 2020.

MONNAPA, Avantika. The Rise of NoSQL and Why it Should Matter to You.
SimpliLearn, nov. 2021. Disponível em <https://www.simplilearn.com/rise-
of-nosql-and-why-it-should-matter-to-you-article>. Último acesso: 26, Out.
2022.

MONQUEIRO, Julio Cesar Bessa. Programação Orientada a Objetos: uma

introdução. Hardware.com.br, out. 2007. Disponível em
<https://www.hardware.com.br/artigos/programacao-orientada-objetos>.
Último acesso: 05, Mar. 2019.

MONTEIRO, Leandro Pinho. Dados Estruturados e Não Estruturados.

Universidade da Tecnologia, 2019. Disponível em
<https://universidadedatecnologia.com.br/dados-estruturados-e-nao-
estruturados>. Último acesso: 02, Maio 2021.

NAVATHE, Shamkant B.; ELSMARI, Ramez. Sistemas de Banco de Dados. 4.

edição. São Paulo: Pearson Addison Wesley, 2005.

NOSQL Database Org. Disponível em: <http://nosql-database.org/>. Último

acesso: 15, Mar. 2019.

130
PAT RESEARCH. Top 9 Object Databases. Disponível em
<https://www.predictiveanalyticstoday.com/top-object-databases>. Último
acesso: 05, Mar. 2020.

STROZZI, Carlo. NoSQL: A non-SQL RDBMS. c2010. Disponível em

<http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/nosql/Home%20Page>.
Último acesso: 11, Mar. 2019.

TAYLOR, Christiane. Structured vs. Unstructured Data. Datamation, mai.

2021. Disponível em: <https://www.datamation.com/big-data/structured-vs-
unstructured-data.html>. Último acesso: 04 de Maio 2021.

UNSQL Org. Disponível em

<http://unql.sqlite.org/index.html/wiki?name=UnQL>. Último acesso: 11,
Mar. 2019.

131