Aula 2 - Sistema Gerenciador de Banco de Dados

Prévia do material em texto

CCDD – Centro de Criação e Desenvolvimento Dialógico 
 
1 
Sistema Gerenciador de Banco de Dados 
 
 
 
 
 
 
 
 
Aula 02 
 
 
 
 
 
 
 
Prof. Martin José Fagonde Morães 
 
CCDD – Centro de Criação e Desenvolvimento Dialógico 
 
2 
Conversa inicial 
Segurança em Sistemas de Gerenciamento de Banco de Dados (SGDB) 
é assunto amplo e contínuo. Nesta aula, vamos discutir as principais ameaças 
a uma base de dados, a responsabilidade do DBA, controle de acesso como 
medida de segurança imprescindível, considerações pós-sinistro e o processo 
de auditoria. 
Veja o vídeo do professor Martin em que ele comenta mais o que vamos 
estudar nesta aula. Acompanhe na rota! 
Contextualizando 
É um tema amplo considerando o vasto mateiral e situações a serem 
consideradas e é um tema contínuo por que a todo instante surgem novas 
tecnologias, possibilidades, riscos etc. 
A segurança de uma base de dado tem de ser tratada com diversas 
visões. 
Decidir como projetar considerações de privacidade na tecnologia 
para o futuro incluem dimensões filosóficas, legais e práticas. Existe 
uma sobreposição considerável entre questões relacionadas ao 
acesso a recursos (segurança) e questões relacionadas ao uso 
apropriado da informação (privacidade). (ELMASRI; NAVATHE; 
VIEIRA; SERAPHIM; SERAPHIM, 2011, p. 566) 
 
A segurança não está desassociada da privacidade e vice-versa. No 
documentário “Sujeito a Termos e Condições” do diretor Cullen Hoback 
(HOBACK, 2013), percebe-se o impacto de uma sobre a outra. 
As causas das ameaças a uma base de dados são muito variadas, 
podendo ser decorrentes de desastres como tsunami, rompimento de 
barragens, desmoronamentos etc. e também podem ser decorrentes de ações 
intencionais de danificar, induzir ao erro, causar prejuízo, apropriar-se de 
informações etc., como também podem ser decorrentes do inadvertido de 
comandos, operações etc. 
As bases de dados são fundamentais para a continuidade das 
 
CCDD – Centro de Criação e Desenvolvimento Dialógico 
 
3 
operações das organizações. As operações das organizações estão fortemente 
embasadas nas bases de dados, de tal forma que a indisponibilidade das 
mesmas, invariavelmente, impossibilitará vários processos. 
Neste estudo, entre outras questões, trabalharemos nas seguintes 
questões: Quais os recursos e melhores práticas para proteger a base de 
dados? O SGDB dá conta sozinho? Qual o papel do DBA? 
Antes de prosseguir, assista ao vídeo do professor Martin em que ele 
contextualiza o assunto desta aula. Confira! 
Pesquise 
Tema 01: Ameaças ao Banco de Dados 
Navathe et al. (2011, p. 563) ressalta que “as ameaças aos bancos de 
dados podem resultar na perda ou degradação de alguns ou de todos os 
objetivos de segurança comumente aceitos: integridade, disponibilidade e 
confidencialidade”. Em outras palavras, um banco de dados seguro 
disponibiliza dados íntegros garantindo confidencialidade. Vamos entender 
melhor. 
Confidencialidade 
Podemos pensar em confidencialidade de forma ampla como tratado por 
Navathe et al. (2011): 
Perda de confidencialidade. A confidencialidade do banco de dados 
refere-se à proteção dos dados contra exposição não autorizada. O 
impacto da exposição não autorizada de informações confidenciais 
pode variar desde a violação do Data Privacy Act até o 
comprometimento da segurança nacional. A exposição não 
autorizada, não antecipada ou não intencional poderia resultar em 
perda de confiança pública, constrangimento ou ação legal contra a 
organização. (ELMASRI; NAVATHE; VIEIRA; SERAPHIM; 
SERAPHIM, 2011, p. 563) 
 
O Data Privacy Act é equivalente a nossa Lei n.º 12.965, o marco civil 
da Internet. A confidencialidade está relacionada ao sigilo e à privacidade. 
Quanto ao sigilo, no Artigo 7º do marco civil da Internet, encontramos que aos 
 
CCDD – Centro de Criação e Desenvolvimento Dialógico 
 
4 
usuários estão assegurados alguns direitos quanto aos seus dados. 
Art. 7º O acesso à internet é essencial ao exercício da cidadania, e ao 
usuário são assegurados os seguintes direitos: 
I - inviolabilidade da intimidade e da vida privada, sua proteção e 
indenização pelo dano material ou moral decorrente de sua violação; 
II - inviolabilidade e sigilo do fluxo de suas comunicações pela 
internet, salvo por ordem judicial, na forma da lei; 
III - inviolabilidade e sigilo de suas comunicações privadas 
armazenadas, salvo por ordem judicial; (BRASIL, 2014) 
 
Quanto à privacidade o artigo 8º do marco civil da Internet diz: “A 
garantia do direito à privacidade e à liberdade de expressão nas comunicações 
é condição para o pleno exercício do direito de acesso à Internet.” (BRASIL, 
2014). 
A exposição de dados não autorizados, ou seja, a perda de 
confiabilidade impacta, entre outros, os fornecedores, clientes, funcionários e a 
própria organização. 
Saiba mais: Para reforçar este aspecto, veja a matéria sobre o vazamento de 
dados da Sony, clicando no link a seguir: 
http://exame.abril.com.br/tecnologia/noticias/10-celebridades-afetadas-pelo-
vazamento-de-dados-da-sony 
Disponibilidade 
A perda de disponibilidade implica na interrupção de uma ou mais 
atividades por não poder acessar algum dado vital na atividade. Navathe et al. 
(2011, p. 563) trata deste conceito da seguinte forma. 
Perda de disponibilidade. A disponibilidade do banco de dados 
refere-se a tornar os objetos disponíveis a um usuário humano ou a 
um programa ao qual eles têm um direito legítimo. (ELMASRI; 
NAVATHE; VIEIRA; SERAPHIM; SERAPHIM, 2011, p. 563) 
 
A indisponibilidade interrompe a continuidade do processo, implica 
degradação na qualidade do serviço prestado. 
Integridade 
A integridade implica que os dados disponibilizados estão correto, ou 
seja, não foram adulterados. Navathe, et al. (2011, p. 563) definiu da seguinte 
 
CCDD – Centro de Criação e Desenvolvimento Dialógico 
 
5 
forma. 
Perda de integridade. A integridade do banco de dados refere-se ao 
requisito de que a informação seja protegida contra modificação 
imprópria. A modificação de dados inclui criação, inserção, 
atualização, mudança do status dos dados e exclusão. A integridade 
é perdida se mudanças não autorizadas forem feitas nos dados por 
atos intencionais ou acidentais. Se a perda da integridade do sistema 
ou dos dados não for corrigida, o uso continuado do sistema 
contaminado ou de dados adulterados poderia resultar em decisões 
imprecisas, fraudulentas ou errôneas. (ELMASRI; NAVATHE; VIEIRA; 
SERAPHIM; SERAPHIM, 2011, p. 563) 
 Vamos aprender mais com o professor Martin, assista ao vídeo em que 
ele explica mais detalhes sobre as ameaças ao banco de dados. 
Tema 02: Responsabilidades 
Garantir confidencialidade, disponibilidade e integridade em uma base 
de dados é uma tarefa constante e, conforme Navate, et al. (2011, p. 566), “é 
responsabilidade do administrador de banco de dados e do administrado de 
segurança impor coletivamente as políticas de segurança de uma 
organização”. 
As políticas de segurança devem ser criadas e trabalhadas por um 
comitê, envolvendo os diversos setores e níveis da organização, envolve 
decisões em que os gestores devem estar envolvidos e as quais devem 
aprovar. Uma política de segurança deve ser implementada para que aja 
processos, critérios e legalidade nas ações adotadas. 
Uma das medidas imprecindíveis, segundo Navate, et al. (2011, p. 
566), diz que o “acesso deve ser permitido a certo atributo do banco de dados 
(também conhecido como coluna da tabela ou um elemento de dados) ou não 
para usuários individuais ou para categorias de usuários”, eles resaltam que: 
As responsabilidades do administradordo banco de dados (DBA) 
incluem conceder privilégios aos usuários que precisam usar o 
sistema e classificar os usuários e dados de acordo com a política da 
organização. 
O DBA tem uma conta de DBA no SGDB, também conhecida como 
conta do sistema ou conta de superusuário, que oferece capacidade 
poderosas que não estão disponíveis às contas e usuários comuns 
do banco de dados. (ELMASRI; NAVATHE; VIEIRA; SERAPHIM; 
SERAPHIM, 2011, p. 564). 
 
CCDD – Centro de Criação e Desenvolvimento Dialógico 
 
6 
O controle de acesso neste ponto está tratando do acesso lógico, ou 
seja, aos dados propriamente dito. Embora seja evidente a responsabilidade do 
DBA, outros personagens da organização também devem ser envolvidos e 
responsabilizados. O DBA tem responsabilidades em implementar as restrições 
de acesso, seguindo as deifnições das políticas de segurança da organização. 
O controle de acesso lógico envolve o coordenador de recursos 
humanos (RH), os diretores e encarregados de cada área, pois nos processos 
estão envolvidos os dados, os sistemas, os colaboradores. 
Todo o trabalho de controle de acesso lógico é perdido se não tiver 
controle do acesso físico e outras medidas que discutiremos mais adiante. 
Agora, o professro Martin vai comentar mais sobre as 
responsabilidades da segurança do banco de dados. 
Tema 03: Controle de Acesso 
O controle de acesso consiste em conceder ou revogar privilégios, 
classificar e/ou definir um grupo de permissões. Pode-se começar definindo o 
pressuposto do controle de acesso, ou seja: 
 No acesso é tudo permitido exceto se for expressamente proibido. 
 No acesso é tudo proibido exceto se for expressamente permitido. 
Em “tudo permitido” a implementação é menos trabalhosa, 
recomendado para um grupo pequeno de colaboradores, e em “tudo proibido” é 
mais recomendado para grupos com muitos colaboradores ou com dados mais 
sensíveis. 
O controle de acesso pode ser implementado por diversas estratégias, 
vamos analisar as estratégias discricionário, view, obrigatório e baseado 
em papéis. 
Discricionário 
Do inglês “discretionary access control” (DAC), controle de acesso 
discricionário, é bastante comum e bases de dados com poucos colaboradores. 
 
CCDD – Centro de Criação e Desenvolvimento Dialógico 
 
7 
Nesta estratégia de “controle de acesso trata-se de conceder, revogar 
e propagar privilégios de acesso aos dados por campos (colunas), registros 
(tuplas), tabelas, views etc.” (ELMASRI; NAVATHE; VIEIRA; SERAPHIM; 
SERAPHIM, 2011, p. 568). 
O método típico para impor o controle de acesso discricionário em um 
sistema de banco de dados é baseado na concessão e revogação de 
privilégios. A ideia principal é incluir declarações na linguagem de 
consulta que peritam que o DBA e usuários selecionados concedam e 
revoguem privilégios. (ELMASRI; NAVATHE; VIEIRA; SERAPHIM; 
SERAPHIM, 2011, p. 567) 
 
Navathe (2011, p. 567) refere-se a dois níveis discricionário “dois níveis 
para atribuição de privilégios na utilização do sistema de banco de dados: 
Nível de conta; Nível de relação (ou tabela)”. 
Considera-se importante aplicar os dois níveis discricionários em uma 
base de dados. 
Nível de conta 
Este nível de controle de acesso discricionário está voltado às 
permissões de utilizar os comandos DDL (linguagem de definição de dados) do 
SQL. Navathe (2011, p. 567) os descreve assim: “no nível de conta se aplicam 
às capacidades fornecidas à própria conta e podem incluir o privilégio de 
CREATE SCHEMA ou CREATE TABLE... ALTER... DROP... MODIFY... 
SELECT”. 
É importante ressaltar que este nível de controle não está definido no 
SQL2. “Os privilégios em nível de conta não são definidos como parte da 
SQL2; eles são deixados para os implementadores de SGDB definirem.” 
(ELMASRI; NAVATHE; VIEIRA; SERAPHIM; SERAPHIM, 2011, p. 567). Sendo 
assim, esta é uma parte fundamental a ser incluída na hora de definir o SGDB. 
Nível de relação 
Faz parte do SQL2 os recursos para implementar o controle de acesso 
por nível de relação. 
Devemos entender por relação, nas próprias palavra de Navathe (2011, 
 
CCDD – Centro de Criação e Desenvolvimento Dialógico 
 
8 
p. 567): “relação pode se referir a uma relação da base ou a uma visão” 
(ELMASRI; NAVATHE; VIEIRA; SERAPHIM; SERAPHIM, 2011, p. 567), 
exemplificando tabelas, registros, colunas, views e outros. 
Efetivamente, neste nível de controle de acesso, é dado ou não 
permissão de leitura, gravação, exclusão ou alteração sobre um dado ou um 
conjunto de dado. Uma tabela ou uma view são exemplos de conjuntos de 
dados. Navathe (2011, p. 568) refere-se a este assunto dizendo “os tipos de 
privilégios podem ser de recuperação ou leitura (SELECT), privilégios de 
modificação das tuplas (UPDATE, DELETE e INSERT)” (ELMASRI; NAVATHE; 
VIEIRA; SERAPHIM; SERAPHIM, 2011, p. 568). 
Sendo assim, se um usuário receber somente permissão de leitura em 
uma tabela, ele não conseguirá inserir ou alterar dados. 
Navathe (2011, p. 567) explica este mecanismo dizendo: 
A concessão e a revogação de privilégios costuma seguir um modelo 
de autorização para privilégios discricionários conhecido como 
modelo de matriz de acesso, no qual as linhas de uma matriz M 
representam sujeitos (usuários, contas, programas) e as colunas 
representam objetos (relações, registros, colunas, visões, operações). 
Cada posição M(i,j) na matriz representa os tipos de privilégios 
(leitura, gravação, atualização) que o sujeito i mantém sobre o objeto 
j. (ELMASRI; NAVATHE; VIEIRA; SERAPHIM; SERAPHIM, 2011, p. 
567) 
 
Destaca-se o fato de que “o proprietário de uma relação recebe todos 
os privilégios sobre essa relação” (ELMASRI; NAVATHE; VIEIRA; SERAPHIM; 
SERAPHIM, 2011, p. 568). 
View 
As views podem ser utilizadas como mecanismos de segurança. 
Navathe (2011, p. 568) apoia este mecanismo ao dizer: “O mecanismo de 
visões (views) é um importante mecanismo de autorização discricionário por si 
só”. 
A view, por sua natureza, não permite inserção, alteração ou exclusão 
de dados, garantindo, assim, integridade nos dados, e a confidencialidade pode 
 
CCDD – Centro de Criação e Desenvolvimento Dialógico 
 
9 
ser implementada com a seleção somente das colunas e registro que são 
permitidos aos que têm permissão de leitura na view. 
Obrigatório 
Os recursos para implementar esta técnica não são nativos no SQL2. 
Podem ser implementados por pacotes adicionais aos SGDB ou por meio de 
programação (trigger, procedure etc.), no SGDB. 
Esta técnica é recomendada para dados altamente sensíveis, ou seja, 
dados que têm muitas variações de permissões. 
A técnica conhecida como controle de acesso obrigatório, do inglês 
mandatory Access Control (MAC), apresenta classificação para os dados e 
para os colaboradores, seguindo uma classe de segurança (ELMASRI; 
NAVATHE; VIEIRA; SERAPHIM; SERAPHIM, 2011, p. 570). 
Típicas classes de segurança são: 
 Altamente confidencial ou top secret – TS; 
 Secreta ou secret – S; 
 Confidencial ou confidential – C e 
 Não classificada ou unclassified – U. 
Os dados ou objetos são registros, colunas, tabelas, views etc. 
Os usuários/colaboradores e os objetos são classificados com uma das 
classes de segurança, Navathe (2011, p. 570) exclarece. 
O modelo normalmente utilizado para segurança multinível, 
conhecido como modelo de Bell-LaPadula, classifica cada sujeito 
(usuário, conta, programa) e objeto (relação, tupla, coluna, visão, 
operação) em uma das classificações de segurança. 
 
Com os objetos e os colaboradores classificados, são aplicadas regras 
ao controle de acesso, Navathe (2011, p. 570) exemplifica: 
Duas restrições são impostas no acesso aos dadoscom base nas 
classificações de sujeito/objeto: 
1. Um sujeito S não tem permissão para acesso de leitura a um 
objeto O a menos que classe(S) >= classe(O). Isso é conhecido como 
propriedade de segurança simples. 
2. Um sujeito S não tem permissão para gravar um objeto O a menos 
 
CCDD – Centro de Criação e Desenvolvimento Dialógico 
 
10 
que classe(S) <= classe(O). Isso é conhecido como propriedade 
estrela (ou propriedade *). 
Baseado em papéis 
Controle de acesso baseado em papéis é o mais comum, Navathe 
(2011, p. 572) diz: “os privilégios e outras permissões são associados a papéis 
organizacionais, em vez de a usuários individuais. Tais usuários recebem então 
os papéis apropriados”. 
Exemplificando, cria-se um grupo denominado “programador”, a este 
grupo atribui-se as permissões conforme visto na técnica discricionário. Todos 
os colaboradores que devam ter as permissões de acesso de um 
“programador” devem receber a permissão “programador”. 
No SQL2, conforme Navathe (2011, p. 572), os comandos são: “os 
papéis podem ser criados usando os comandos CREATE ROLE e DESTROY 
ROLE. Os comandos GRANT e REVOKE... podem, então, ser utilzados para 
atribuir e revogar privilégios dos papéis, bem como para usuários individuais, 
quando necessário”. 
Para esclarecer e se aprofundar um pouco mais no assunto, leia o tópico 
“24.3 Controle de acesso obrigatório e controle de acesso baseado em papel 
para segurança multinível.” Navathe (2011, p. 570). 
Assista ao vídeo do professor Martin em que ele fala mais sobre a 
classificação dos controles de acesso. Acompanhe na rota! 
Tema 04: Outras Medidas 
Para proteger os bancos de dados, é necessário implementar diversos 
mecanismos de segurança buscando proteger a confidencialidade, a 
disponibilidade e a integridade. Deve-se avaliar se existe a necessidade de 
implementar o controle de fluxo, a criptografia, o log de operações, o controle 
de acesso físico e outros. Vamos entender cada uma delas. 
Controle de fluxo 
O controle de fluxo trata de garantir que o destino de um dado atenda as 
 
CCDD – Centro de Criação e Desenvolvimento Dialógico 
 
11 
regras implementadas de proteção. Veja as considerações de Navathe (2011, 
p. 579) a seguir: 
O controle de fluxo regula a distribuição ou fluxo de informações entre 
objetos acessíveis. Um fluxo entre o objeto X e o objeto Y ocorre 
quando um programa lê valores de X e grava valores em Y. Os 
controles de fluxo verificam que a informação contida em alguns 
objetos não flui explícita ou implicitamente para objetos menos 
protegidos. [...] a transferência de informações de um emissor para 
um receptor só é permitida se a classe de segurança do receptor for 
pelo menos tão privilegiada quanto a do emissor. 
Criptografia 
A criptografia pode ser aplicada tanto no dado que está armazenado na 
base de dados quanto na transmissão do mesmo. Veja as considerações de 
Navathe: 
A criptografia é a conversão de dados para um formato, chamado 
texto cifrado, que não pode ser facilmente entendido por pessoas não 
autorizadas. Ela melhora a segurança e a privacidade, pois em casos 
de perda ou roubo de dados, aqueles criptografados não podem ser 
facilmente entendidos por pessoas não autorizadas. (ELMASRI; 
NAVATHE; VIEIRA; SERAPHIM; SERAPHIM, 2011, p. 580) 
Log de operações 
Os logs são os registros das operações realizadas contendo, entre 
outras informações, a data, a hora, o colaborador, o processo de origem e 
outras informações úteis. Veja as considerações de Navathe: 
Podemos expandir as entradas de log de modo que também incluam 
o número de conta do usuário e o computador on-line ou ID de 
dispositivo que aplicou cada operação registrada no log. 
(ELMASRI; NAVATHE; VIEIRA; SERAPHIM; SERAPHIM, 2011, p. 
565) 
 
Os logs não implementam medidas de segurança, eles são úteis para 
identificar a origem de uma falha na segurança. Isso possibilitará uma análise 
para implementar uma medida de segurança. 
Controle de acesso físico 
É fundamental que alguns locais sejam de acesso restrito. Alguns 
desses locais podem estar ao longo do caminho da rede de dados, da rede 
elétrica, dos servidores, dos nobreaks etc. 
 
CCDD – Centro de Criação e Desenvolvimento Dialógico 
 
12 
Determinar o nível de restrição do acesso físico a alguns locais implica 
determinar o grau do risco quanto à confidencialidade, disponibilidade e 
integridade. 
Backup 
Os backups, ou cópias de segurança, são fundamentais no processo de 
implementar segurança na base de dados. É a principal fonte de restauração 
após um desastre. 
São variadas as propostas de backups de base de dados. Essas 
propostas são inerentes ao SGDB adotado, os SGDB oferecem ferramentas 
diferenciadas para fazer os backups. 
Em geral, todos os SGDB fornecem a possibilidade de fazer os backups 
de toda a base, só dos dados ou só da estrutura. As principais questões nas 
rotinas de backups são a frequência e o armazenamento. 
Para determinar a frequência dos backups é de se considerar o volume 
de operações realizadas, a interrupção dos serviços e o tempo de backup. 
Ao determinar o armazenamento, deve ser considerado o local e a 
mídia, para que o backup também esteja protegido das ameaças quanto à 
confidencialidade, disponibilidade e integridade. 
Vamos ver o que mais o professor Martin fala sobre outras medidas a 
serem tomadas para o controle de acesso e de fluxo ao banco de dados. 
Tema 05: Ocorrência 
Uma breve ponderação sobre necessidades na eventual ocorrência de 
uma violação da segurança. 
Auditoria 
As auditorias, nas medidas de segurança, devem ser realizadas 
periodicamente atendendo as políticas de segurança que foram adotadas. É 
recomendado que auditorias sejam realizadas toda vez que houver suspeita de 
violação da integridade dos dados. Veja as considerações de Navathe: 
 
CCDD – Centro de Criação e Desenvolvimento Dialógico 
 
13 
Se houver suspeita de qualquer adulteração no banco de dados, é 
realizada uma auditoria do banco de dados, que consiste em rever o 
log para examinar todos os acessos e operações aplicadas ao banco 
de dados durante certo período. (ELMASRI; NAVATHE; VIEIRA; 
SERAPHIM; SERAPHIM, 2011, p. 565) 
Recuperação 
Na ocorrência de uma indisponibilidade, é válido considerar as 
sugestões de Navathe: 
Os sistemas de banco de dados precisam operar e continuar suas 
funções, mesmo com capacidades reduzidas [...] além de realizar 
todos os esforços para impedir um ataque e detectar um, caso ocorra, 
deve ser capaz de fazer o seguinte: 
Confinamento. Tomar ação imediata para eliminar o acesso do 
atacante ao sistema e isolar ou conter o problema para impedir que 
se espalhe mais. 
Avaliação de danos. Determina a extensão do problema, incluindo 
funções que falharam e dados adulterados. 
Reconfiguração. Reconfigurar para permitir que a operação continue 
em um modo reduzido enquanto a recuperação prossegue. 
Reparo. Recuperar dados adulterados ou perdidos e reparar ou 
reinstalar funções do sistema que falharam, para restabelecer um 
nível de operação normal. 
Tratamento de falha. Ao máximo possível, identificar os pontos 
fracos explorados no ataque e tomar medidas para impedir uma nova 
ocorrência. (ELMASRI; NAVATHE; VIEIRA; SERAPHIM; SERAPHIM, 
2011, p. 583–584) 
 
Veja o vídeo em que o professor Martin comenta a ocorrência de uma 
situação indesejada. 
 
 
CCDD – Centro de Criação e Desenvolvimento Dialógico 
 
14 
Trocando ideias 
Quais são o(s) aspecto(s) que você considera relevante para 
implementar a segurança em uma base de dados? Reflita! 
Síntese 
Propiciar segurança a uma base de dados é não se descuidar em 
garantir confidencialidade, disponibilidade e integridade.São necessárias 
várias técnicas e diferentes métodos para mitigar os riscos. 
O controle de acesso é uma das medidas para implementar segurança 
na base de dados, mas só o controle de acesso não é suficiente, outras 
medidas de segurança são necessárias para garantir a disponibilidade e a 
confidencialidade. 
O DBA é o principal responsável pela segurança a base de dados, mas 
não o único envolvido nas definições das políticas de segurança. 
Só os recursos fornecidos pelos SGDB não são suficientes para garantir 
segurança a base de dados. Ao considerar outras técnicas, é necessário 
agregar ao processo outras ferramentas e recursos. 
Assista ao último vídeo do professor Martin em que ele faz uma síntese 
do que estudamos nesta aula. 
 
 
CCDD – Centro de Criação e Desenvolvimento Dialógico 
 
15 
Referências 
BRASIL. Lei nº 12.965, de 23 abril de 2014. Estabelece princípios, garantias, 
direitos e deveres para o uso da Internet no Brasil. Disponível em: 
<http://www.planalto.gov.br/ccivil_03/_ato2011-2014/2014/lei/l12965.htm>. 
Acesso em: 21 jan. 2016. 
 
ELMASRI, Ramez; NAVATHE, Shamkant B.; VIEIRA, Daniel; SERAPHIM, 
Enzo; SERAPHIM, Thatyana de Faria Piola (Orgs.). Sistemas de banco de 
dados. 6. ed. São Paulo: Pearson Education do Brasil, 2011.xviii, 788 p. 
 
HOBACK, Cullen. Sujeito a Termos e Condições: Terms and Conditions May 
Apply. Estados Unidos, 2013.