Evolução dos Bancos de Dados

Prévia do material em texto

MODELAGEM E 
DESENVOLVIMENTO 
DE BANCO DE DADOS 
Fabrício Felipe Meleto Barboza
Evolução dos bancos 
de dados
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Identificar a evolução dos bancos de dados.
 � Reconhecer a ordem cronológica dos bancos de dados.
 � Explicar as origens dos bancos de dados.
Introdução
Um banco de dados é um conjunto de valores e arquivos que se relacio-
nam entre si e demonstram um cadastro de pessoas, vendas, produtos, 
agendas, etc. Por exemplo, uma planilha ou uma ficha cadastral podem ser 
exemplos de cadastros. O banco de dados guarda todos esses cadastros 
em formato virtual e os disponibiliza para as aplicações consultarem e 
emitirem relatórios, realizarem vendas, etc.
Neste capítulo, você vai estudar sobre a evolução dos bancos de 
dados decorrente das necessidades impostas por seus utilizadores e 
para solucionar problemas da sociedade. Adicionalmente, você verá, em 
uma escala de tempo, os principais marcos da história dos bancos de 
dados com suas características e particularidades. Por fim, irá conhecer 
o início de tudo, isto é, o que deu origem aos bancos de dados como 
são conhecidos hoje em dia.
A evolução dos bancos de dados
A evolução dos bancos de dados foi e continua sendo de constante melhoria, 
trazendo mais segurança e rapidez para as informações ou dados nele salvas. 
Para Korth, Silberschatz e Sudarshan (2012), um banco de dados “[...] é uma 
coleção de dados inter-relacionados, representando informações sobre um 
domínio específico”.
Pense em uma situação hipotética em que você tenha uma loja de sapa-
tos em um shopping. Você está verificando a implantação de um sistema 
para controlar todas as suas vendas e também as compras de reposição de 
estoque, de maneira que todas as informações da sua loja estarão salvas 
em um sistema no computador da loja que, obviamente, utiliza um banco 
de dados.
Agora imagine se o vendedor do sistema pedisse pra você escolher 
entre 1) um sistema rápido, que tira relatórios gigantescos em menos de um 
segundo, processa vendas também em menos de um segundo do relógio, 
mas, por outro lado, não garante que a informação está íntegra e consis-
tente, e 2) um banco de dados que garante a integridade e a consistência 
das informações, mas demora dez segundos para processar alguma venda 
ou um minuto para criar o relatório complexo solicitado. Qual você, dono 
da loja, escolheria?
Lembre-se de que a evolução em sistemas de tecnologia da informação é importante, 
mas a segurança sempre deve vir em primeiro lugar para que, depois, possamos pensar 
em estabilidade, funcionalidade e velocidade.
Uma tendência da evolução comum é sempre mirar e colocar o foco e as 
metas em realizar a ação com mais e mais rapidez, cada vez provendo maior 
velocidade e resultados instantâneos para o usuário do sistema. Porém, ao 
decidir pela evolução de um sistema de banco de dados, é necessário pensar 
em outros fatores além da velocidade. Com toda a certeza, a velocidade é 
importante e sempre levada em consideração, mas os outros pilares precisam 
ser garantidos para toda transação de um banco de dados. Esses pilares são:
 � Atomicidade;
 � Isolamento;
 � Consistência;
 � Durabilidade.
Evolução dos bancos de dados2
Essas quatro características são garantidas para cada transação realizada 
no banco de dados, independentemente de quem realizou o comando: o próprio 
sistema, o usuário final ou ainda alguma rotina automática.
Mas o que seria uma transação em um sistema de banco de dados? Uma 
transação para um sistema de gerenciamento de banco de dados (SGBD) é 
toda e qualquer atividade que o próprio sistema de gerenciamento de banco 
de dados executa após o usuário ter uma interação com o banco.
Assim, qualquer atividade provocada pelo usuário via interface do sistema 
dispara uma transação ou uma cadeia de transações no banco de dados que 
precisam estar garantidas e ter aderência a esses pilares. Consequentemente, 
essa é a regra de ouro dos bancos de dados.
A regra de ouro dos sistemas de gerenciamento de bancos de dados é a garantia de 
que todos os pilares das transações sejam assegurados e respeitados em cada uma 
de suas transações internas.
Sabendo disso, agora, é necessário entender o que cada um desses pilares 
representa, defende e significa para os bancos de dados.
Atomicidade
Para entender o pilar da atomicidade, fazemos uma analogia à expressão “08 
ou 80”, ou seja, ou finaliza com sucesso ou tudo é abortado. Portanto, ou o 
SGBD conclui todas as ações em cascata para uma transação (commit) ou ele 
retorna ao estado anterior da transação (rollback). 
Assim, a atomicidade é a responsável por garantir que ou uma transação 
é gravada com sucesso e garantida ou é realizado o rollback de toda a transa-
ção para que o banco de dados retorne ao estado anterior daquela transação. 
Nunca um sistema de gerenciamento de banco de dados pode permitir que 
uma transação seja executada pela metade e fique sem rollback, pois isso faz 
a consistência do banco de dados ficar quebrada.
3Evolução dos bancos de dados
Atomicidade é a regra do “ou tudo ou nada”. Ou toda a transação é salva com sucesso 
no banco ou toda a transação é descartada.
Isolamento
Este pilar representa a independência de cada transação no sistema de geren-
ciamento de banco de dados. Cada transação é única e independente, o que 
faz com que duas transações que alterem o mesmo valor de uma tabela não 
entrem em conflito. Toda transação é uma engrenagem no sistema maior, que 
seria o SGBD.
Conforme o sistema tem mais usuários trabalhando nele, mais esta regra 
se torna verdadeira e necessária. Imagine um e-commerce que realiza venda 
de enfeites natalinos. Quando chegar a época de procura por esses enfeites, o 
fluxo de pessoas utilizando o sistema irá aumentar consideravelmente. Agora 
imagine que existe apenas um item de Papai Noel em estoque e dois clientes 
realizam a compra desse item no mesmo segundo; como resolver? O pilar de 
isolamento garante que a transação que for processada em primeiro lugar pelo 
sistema de gerenciamento de banco de dados leve a compra e que a segunda 
pessoa receba um alerta de que o produto ficou fora de estoque.
No exemplo, duas transações estavam tentando inserir dados referentes ao 
mesmo valor único, que seria a quantidade de estoque do produto. Por tratar-se 
de duas transações isoladas e independentes, o sistema de gerenciamento de 
banco de dados rapidamente resolve essa questão, de modo que tal responsa-
bilidade não fica para a equipe de desenvolvimento.
Isolamento é a garantia de que as transações não terão disputa para edição ou escrita 
em um determinado dado ou valor.
Evolução dos bancos de dados4
Consistência
As regras, em sua totalidade, sempre devem ser respeitadas para que o sistema 
de gerenciamento de banco de dados tenha atendido suas características de 
base. Isso inclui, por exemplo, que o tipo de valor inserido seja correto em 
relação ao tipo do seu atributo (VARCHAR, INT, DATE, etc.).
Assim, em face da consistência, um campo do tipo Integer nunca poderá 
receber caracteres alfabéticos. Essa separação se dá para a criação de buscas e 
resultados mais rápidos em campos do tipo numérico. Computadores só sabem 
interpretar números, de modo que campos não numéricos por natureza exigem 
mais processamento do computador, que precisa transformar a informação 
alfabética salva em códigos e linguagem de máquinas que são representados 
por números para conseguir trabalhar.
Consistência é ter o dado certo no local esperado. Um campo do tipo Integer sempre 
deverá conter um valor de número inteiro.
Durabilidade
Quando uma transação é finalizada, seus dados estão a salvo de qualquer 
modificação. Somente outra transação pode modificar os dados. Assim, os 
dados ficam protegidos!
Imagine que a sua compra foi finalizada com sucesso e, quando você vai 
buscar seu histórico de compras, ela não aparece. Ruim, correto? A durabi-
lidade garanteque a informação de sua compra só seja modificada por outra 
transação e, dessa forma, consegue-se rastrear as requisições e buscar o que 
ou quem fez tal atividade.
O próprio sistema de gerenciamento de banco de dados não realiza nenhuma 
modificação após a conclusão de todas as transações pendentes. Portanto, 
qualquer modificação de um valor do banco de dados será de origem do 
usuário ou do sistema.
5Evolução dos bancos de dados
Durabilidade é a proteção dos dados contra qualquer coisa que não seja uma nova 
transação do banco de dados.
Cronologia dos bancos de dados
Há divergência na ordem cronológica do surgimento das versões dos bancos 
de dados, exceto as versões mais comumente utilizadas. Observe a Figura 1, 
que representa as etapas mais importantes da evolução dos bancos de dados.
Figura 1. Cronograma de evolução dos BDs.
Evolução dos bancos de dados6
Com base na Figura 1, percebe-se grande concentração de lançamentos e 
popularização dos bancos de dados no período compreendido entre os anos 
1980 até os 2000. Essa intensa movimentação se deu em virtude da infor-
matização das empresas, que aconteceu ao longo desses anos. Cada empresa 
precisou incrementar seu parque tecnológico para que atendesse seus objetivos 
internos, como redução de custo, melhora do valor da entrega ao cliente, ou 
também objetivos externos, como estar de acordo com uma nova lei, receber 
auditoria de órgãos competentes ou, ainda, pela concorrência, que está em 
franca evolução e em busca por melhores resultados a todo custo.
Antes da década de 1980, temos o estágio embrionário dos bancos de dados. 
Sua evolução estava ocorrendo, mas era centralizada em forma de pesquisas 
e experimentos. Até porque, quando fossem apresentados para as empresas e 
para o público geral, era necessário confiar no produto oferecido ao custo de 
milhões de dólares em pesquisas.
Após os anos 2000, a evolução continua até os dias atuais, mas de forma 
menos acelerada, já que o foco, atualmente, é em estabilidade e segurança 
cada vez maiores. Partindo desse princípio, temos o surgimento de bancos 
de dados NoSQL, que fazem frente aos tradicionais bancos de dados rela-
cionais SQL.
Retome a Figura 1 e atente-se para o quadrante “Anos 2000”, no qual você 
verá que foi nesse período que surgiu o MongoDB, banco de dados NoSQL (Not 
only SQL) e com grande poder de processamento. Aí você pode se perguntar: 
“mas se ele é melhor, por que todos não migram pra ele?”. A resposta é direta: 
custo e foco do projeto.
O banco de dados NoSQL não veio para matar os bancos de dados relacio-
nais como muitos imaginavam em seu lançamento, mas para complementar 
e oferecer uma opção a mais para as empresas e desenvolvedores segundo 
Guedes (2017).
Dessa forma, podemos exemplificar o uso de cada um dos tipos de bancos 
de dados de forma mais didática: caso a aplicação tenha relacionamentos entre 
as entidades e o volume de informações não for gigantesco, os bancos de dados 
relacionais tradicionais atenderão muito bem a sua demanda por um sistema.
Agora, caso você tenha um sistema de bancos de dados grandioso, com 
muitos valores sendo escritos e lidos ao mesmo tempo, a indicação é um banco 
de dados do tipo NoSQL para que o seu sistema ganhe em desempenho e não 
frustre os usuários com telas de “carregando”, erros de timeout de conexão 
ou ainda a negação de serviço por falta de recursos ao processar uma consulta 
gigante do gerente que trabalha remoto, impedindo de abrir a agenda de 
reuniões de outro funcionário.
7Evolução dos bancos de dados
Lembre-se também de que, por ser uma tecnologia mais nova, o custo 
para manter um banco de dados NoSQL é grande, até pela escassez de mão 
de obra qualificada no mercado de trabalho. Portanto, mensure esse custo ao 
tomar uma decisão sobre qual tipo de sistema de gerenciamento de bancos 
de dados utilizar no projeto.
Origens dos bancos de dados
Antigamente, as empresas produziam e mantinham cadastros de tudo que 
fosse necessário em fichas e papéis armazenados em um ou vários arquivos 
dentro de uma ou várias salas. Portanto, cliente, fornecedor, colabora-
dor, agendas de compromisso, agendas telefônicas, inventário, controle 
de estoque, etc. estavam em um papel, em algum lugar dentro de algum 
arquivo. 
Obviamente, organizar e manter tudo atualizado era uma tarefa complexa 
demais, pois envolvia um esforço muito grande para buscar informações 
básicas e que deveriam estar acessíveis para qualquer colaborador de forma 
instantânea.
Imagine que é necessário buscar todos os registros de ponto de entrada 
e saída de um colaborador que ficou durante vinte anos na empresa pois ele 
entrou com uma ação trabalhista, por exemplo. Agora imagine essa mesma 
situação e com um prazo de cinco dias para entregar toda essa informação ao 
Ministério do Trabalho. Impossível, certo?
Além disso, as informações contidas nesses papéis ficavam facilmente ob-
soletas em virtude da demora em atualizar o registro. Portanto, nada confiável.
Imagine a probabilidade de um desastre na sala de arquivos, como um cano 
de água rompido que encharque todos os registros da empresa. Com certeza, 
a empresa em questão teria sérios problemas ou, em um caso mais extremo, 
mas não descartado, até mesmo fecharia as portas se algo dessa magnitude 
acontecesse. 
Pode-se ir mais a fundo e imaginar que algum funcionário espião ou insa-
tisfeito com a empresa roube a informação de um projeto que iria ser lançado 
no próximo ano e a venda para a concorrência. Todo o esforço empregado na 
pesquisa e no desenvolvimento daquele projeto foi praticamente em vão, pois 
o elemento surpresa, para pegar o mercado no ponto certo e os concorrentes 
ficarem desequilibrados, foi perdido.
Evolução dos bancos de dados8
Sempre que um problema é detectado, ele deve ser resolvido logo por meio do 
fomento de ideias para o seu contorno ou para a criação de solução definitiva.
Pense que os bancos de dados só foram inventados porque existiu uma necessidade 
latente de diminuir despesas e melhorar a confiança nas informações salvas pela 
empresa com o passar dos anos.
Dessa forma, havia um problema grande e generalizado em todas as cor-
porações em que registros eram feitos em papéis e armazenados em um lugar 
qualquer, muitas vezes sem a devida importância para o dado, para o registro 
ali contido. Como grandes problemas sugerem soluções altamente lucrativas, 
iniciou-se pesquisas que apresentassem uma solução para todo esse caos vi-
venciado em cada pequeno, médio ou grande escritório ou empresa no mundo.
Na década de 1960, surge uma solução para esse caos: o banco de dados. 
Vários modelos foram apresentados à IBM, financiadora do projeto, e, entre 
os modelos propostos, estavam o hierárquico e o de rede.
Apesar disso, nada muito usual ou com uma viabilidade de escala foi 
apresentado, o que fez os projetos serem engavetados.
Segundo Alves (2013), já na década de 1970, mais precisamente no mês 
de junho, o então pesquisador da IBM Edgar Frank “Ted” Codd apresentou 
um artigo que mudaria a história dos modelos de bancos de dados para 
sempre – ele estava propondo o modelo relacional de bancos de dados. 
Em seu artigo Relational Model of Data for Large Shared Data Banks, 
Ted descrevia como usuários leigos conseguiriam extrair os dados que 
lhes eram importantes.
No raciocínio de Alves (2013), vemos que, já no fim da década de 1970, surge 
o Sistema R, um sistema baseado nas ideias de Ted. Junto ao lançamento do 
Sistema R, veio a linguagem SQL, acrônimo para Structured Query Language, 
a linguagem que dominou o mercado. O Sistema R não foi bem comercialmente 
e acabou sendo abandonado, mas serviu, com toda a certeza, de inspiração e 
base para muitos dos bancos de dados que temos nos dias de hoje.
Finalizando seu pensamento, Alves (2013) diz que, na década de 1980, 
ocorrem dois marcos importantes na linha cronológica dos bancos de dados: 
o lançamento do Oracle 2 pela própria Oracle e, também, o lançamento do 
SQL/DS pela IBM, conhecidopor DB2 atualmente.
9Evolução dos bancos de dados
Portanto, temos aí a origem dos bancos de dados. Com o passar de mais 
anos e décadas, os sistemas de gerenciamento de bancos de dados foram 
evoluindo segundo a necessidade dos clientes, no caso de sistemas pagos, ou 
pela produção da comunidade, no caso de sistemas opensource. 
Aliás, uma curiosidade que também permeia este cenário de evolução: 
sempre que a comunidade dos sistemas de bancos de dados opensource lança 
algo inovador, as empresas que têm bancos de dados licenciados correm atrás e 
vice-versa. Com isso, muitas funcionalidades que estão presentes em sistemas 
de bancos de dados opensource também se tornam presentes nos sistemas 
proprietários, assim como o inverso.
A aplicação de cada sistema de banco de dados se dará pela escolha cru-
cial de quem irá desenvolver baseado no orçamento e conhecimento daquela 
tecnologia de banco de dados específica para otimizar o tempo do projeto e 
também o seu custo.
Lembre-se de quem fez a pesquisa para obter os bancos de dados relacionais que 
conhecemos hoje: Edgar Frank “Ted” Codd, pesquisador da IBM na época e que lançou o 
artigo intitulado Relational Model of Data for Large Shared Data Banks. Ted é considerado 
o pai dos bancos de dados relacionais.
ALVES, G. F. O. A história dos bancos de dados. 01 abr. 2013. Disponível em: <https://dicas-
deprogramacao.com.br/a-historia-dos-bancos-de-dados/>. Acesso em: 21 maio 2018.
GUEDES, M. SQL vs NoSQL, qual usar? 19 jul. 2017. Disponível em: <https://www.treina-
web.com.br/blog/sql-vs-nosql-qual-usar/>. Acesso em: 21 maio 2018.
KORTH, H. F.; SILBERSCHATZ, A.; SUDARSHAN, S. Sistema de banco de dados. 6. ed. Rio 
de Janeiro: Campus, 2012.Leituras recomendadas
CODD, E. F. A Relational Model of Data for Large Shared Data Banks. Communications 
of the ACM, v. 13, n. 06, June 1970.
REZENDE, R. Conceitos fundamentais de banco de dados. 2017. Disponível em: <https://
www.devmedia.com.br/conceitos-fundamentais-de-banco-de-dados/1649>. Acesso 
em: 21 maio 2018.
Evolução dos bancos de dados10
MODELAGEM E 
DESENVOLVIMENTO 
DE BANCO DE DADOS 
Fabrício Felipe Meleto Barboza
Tipos de bancos de dados
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Identificar os vários tipos de bancos de dados.
 � Reconhecer os tipos de bancos de dados pela sua sintaxe.
 � Relacionar os bancos de dados com os vários tipos existentes.
Introdução
Neste capítulo, você vai estudar sobre como identificar e reconhecer os 
diversos tipos de bancos de dados pela sua sintaxe. Assim, será capaz de 
reconhecer os padrões de cada sintaxe e identificar o banco de dados 
associado. Você verá exemplos de uso e os diferentes padrões em cada 
um dos bancos de dados: PostgreSQL, Microsoft SQL Server, MySQL/
MariaDB e Oracle. Adicionalmente, verá como relacionar os bancos de 
dados em função dos vários tipos existentes atualmente.
Os vários tipos de bancos de dados
Vamos relembrar o conceito de bancos de dados? Segundo Korth, Silbers-
chatz e Sudarshan (2012), banco de dados “[...] é uma coleção de dados inter-
-relacionados, representando informações sobre um domínio específico”.
Dessa forma, estudaremos, neste capítulo, os diversos tipos de bancos de 
dados mais comumente utilizados e conhecidos atualmente, limitando-nos às 
quatro primeiras posições desse mesmo ranking de utilização.
Usualmente, as empresas utilizam um dos quatro bancos de dados a seguir 
em suas aplicações, sistemas ou projetos:
 � MySQL/MariaDB;
 � Oracle;
 � Microsoft SQL Server;
 � PostgreSQL.
Analisaremos cada um desses bancos de dados, abordando sua origem, 
plataforma compatível, características únicas e escopo de trabalho.
MySQL/MariaDB
O MySQL foi inserido junto ao MariaDB em virtude deste segundo ser 
um fork do primeiro, tendo estrutura e comandos bem semelhantes e de 
funcionamento idêntico. O MySQL era um banco de dados opensource 
até a sua compra pela Oracle em 2009. Esse paralelismo é tão grande e 
forte que os próprios administradores de bancos de dados do MySQL 
conseguem, de forma bem fácil, gerenciar um banco de dados do tipo 
MariaDB e vice-versa.
Fork significa uma bifurcação. Portanto, o MariaDB ser um fork do MySQL quer dizer 
que o MySQL teve uma bifurcação em sua história que originou o MariaDB. 
A instalação de um banco de dados do tipo MySQL ou MariaDB pode 
ser realizada tanto em sistema operacional Linux nas distribuições CentOS, 
RedHat, Ubuntu, Debian ou Fedora quanto no Windows.
Lembre-se que o banco de dados MySQL é quase que totalmente compatível com 
o MariaDB exatamente porque o MariaDB é um fork do MySQL. Um dos criadores 
originais do MySQL desenvolveu o MariaDB.
Até mesmo a forma de abrir e realizar uma conexão ao banco de dados 
é semelhante entre o MySQL e o MariaDB. Outra característica curiosa é a 
semelhança entre os dois logotipos que representam cada um destes bancos 
de dados (Figura 1).
Tipos de bancos de dados2
Figura 1. Logos do MySQL (a) e do MariaDB.
Fonte: MySQL (2018, documento on-line) e MariaDB
Repare que ambos os animais presentes nos logotipos fazem parte do 
ambiente marinho: um golfinho para o MySQL e uma foca para o MariaDB. O 
licenciamento do MySQL é pago e o MariaDB veio para suprir a comunidade 
opensource e, assim, não ter custo pelo licenciamento do banco de dados.
Sua grande disseminação se dá em virtude de diversos sistemas e linguagens 
de programação terem uma fácil e rápida conexão com ele. Como linguagens, 
destacam-se o PHP e Python. Já para os sistemas, temos Wordpress e Magento.
Oracle
A gigante de tecnologia Oracle possui um banco de dados de mesmo nome e 
que é um dos bancos de dados mais utilizados do mundo. 
Um dos maiores salários dos profissionais de tecnologia da informação é o dos admi-
nistradores do banco de dados Oracle.
Seu lançamento ocorreu em 1980 e ele domina o mercado desde então. É 
um banco de dados do tipo relacional, tem uma base confiável e robusta, e é 
muito utilizado para projetos muito grandes, com várias transações ocorrendo 
em um mesmo segundo, tanto de leitura quanto de escrita, além de uma 
incrível performance.
3Tipos de bancos de dados
Como seu licenciamento é pago e a cifra gira em um valor muito alto, 
na casa de cinco ou seis dígitos, as empresas que o utilizam são de porte 
médio para grande em função do alto custo — além do já mencionado custo 
diferenciado pelo profissional que o administra.
A Oracle, exatamente por saber de seu diferencial competitivo no mercado, 
lançou diversas certificações para capacitar o profissional que irá trabalhar 
com o seu sistema de banco de dados. Essas certificações também atestam, 
para a empresa contratante, o conhecimento e a experiência do profissional 
em questão. Conforme lembra Almeida (2018), os demais sistemas de bancos 
de dados também possuem certificação, mas a trilha de certificação da Oracle 
é a mais estruturada e reconhecida no mercado de trabalho exatamente pela 
importância do banco de dados em questão. O banco de dados Oracle é ins-
talado em sistemas operacionais Linux e também em sistemas operacionais 
Microsoft Windows.
Microsoft SQL Server
A gigante de Redmond lançou o seu banco de dados em 1989 e vem evoluindo 
esse banco desde então. Um limitador do sucesso do Microsoft SQL Server é 
que, até pouco tempo atrás, só era possível instalá-lo em sistema operacional 
Windows, deixando toda a comunidade que trabalha com opensource Linux 
sem a possibilidade de usá-lo. Eis que a Microsoft, em 2017, lançou uma versão 
do banco de dados para Linux de forma a reverter a situação e alavancar seu uso.
Como o Oracle, o Microsoft SQL Server tem o seu licenciamento na mo-
dalidade paga. O grande trunfo do Microsoft SQL Server é a sua aproximação 
da linguagem .NET e, também, seus desenvolvedores.
PostgreSQL
Outro banco de dados de licenciamento livre é o PostgreSQL. Ele é do tipo 
relacional e foi lançado em 1989 pela PostgreSQL Global Development Group.
O PostgreSQL,assim como o MySQL e o MariaDB, tem forte apelo para 
aplicações WEB de pequeno e médio porte. Grande parte dos sites e sistemas 
do tipo WEB utilizam um banco de dados PostgreSQL para armazenamento 
dos dados.
Diversos sistemas operacionais são suportados pelo PostgreSQL (Figura 2), 
sendo tanto Linux quanto o Microsoft Windows. Dessa forma, seu concorrente 
no mundo dos bancos de dados acaba sendo, por eliminação e proximidade, 
o MariaDB.
Tipos de bancos de dados4
Seu logo é composto pela representação da cabeça de um elefante, reme-
tendo à lendária ideia de que um elefante nunca se esquece do que ou quem 
ele visualizou.
Figura 2. Logo do PostgreSQL.
Fonte: PostgreSQL (2018, documento on-line).
Os tipos de bancos de dados e sua sintaxe
Para facilitar o seu entendimento, serão disponibilizados exemplos de inser-
ção, edição e deleção de um dado. Esses comandos podem ser utilizados em 
qualquer um dos bancos de dados MySQL, MariaDB, Oracle, Microsoft SQL 
Server ou PostgreSQL.
Como complemento e para diferenciar os bancos, também serão de-
monstrados os comandos particulares de cada banco de dados para exibir 
todos os databases e o comando para mostrar todas as tabelas de um 
database. Esses comandos serão exemplificados nos quatro bancos de 
dados descritos no parágrafo anterior. Para a inserção de dados, é utilizada 
a sintaxe a seguir.
Exemplificando em um insert na tabela “cliente” o cadastro de José da 
Silva, podemos usar algo semelhante a:
5Tipos de bancos de dados
Já para a edição de dados, é utilizada a sintaxe a seguir:
Exemplificando em uma edição da tabela “cliente” e no cadastro de José da 
Silva, modificando seu número de telefone, podemos usar algo semelhante a:
Para a exclusão de dados, é utilizada a sintaxe a seguir:
Exemplificando a deleção com o cadastro de José da Silva da tabela 
“cliente”, podemos usar algo semelhante a:
Tipos de bancos de dados6
Portanto, os comandos apresentados anteriormente podem ser utilizados 
em qualquer um dos quatro bancos de dados estudados aqui: MySQL ou 
MariaDB, Oracle, Microsoft SQL Server ou, por último, mas não menos 
importante, o PostgreSQL.
Os comandos de exibir os databases ou exibir as tabelas são particulares 
para cada banco de dados e, dessa forma, foram separados. A seguir, são 
apresentados cada um deles.
MySQL/MariaDB
A sintaxe do MySQL é praticamente idêntica ao MariaDB exatamente pelo 
fato deste segundo ser um fork do primeiro. 
Para exibir todas os databases no MySQL ou no MariaDB, utiliza-se:
O retorno do comando será o nome de todos os databases contidas no banco 
de dados independentemente de ter, ou não, tabelas, um database por linha.
Já para exibir todas as tabelas de um database, primeiro é necessário fazer 
a seleção do database desejada:
Após a seleção do database, pode-se realizar a consulta das tabelas com 
o comando:
O retorno desse comando será uma listagem de todas as tabelas daquele 
database selecionada previamente, uma tabela por linha.
Oracle
Para o Oracle, os comandos de exibição são diferentes do MySQL ou do 
MariaDB. Caso precise exibir todos os databases, você pode usar o comando:
7Tipos de bancos de dados
Novamente, o retorno do comando será o nome de todos os databases 
contidos no banco de dados independentemente de ter ou não tabelas, um 
database por linha. Se a necessidade é exibir todas as tabelas de um database, 
antes de executar o comando necessário para conseguir o resultado esperado, 
é preciso selecionar o schema desejado:
Após isso, rode o comando a seguir para exibir as tabelas:
Microsoft SQL Server
Para que o Microsoft SQL Server liste os databases, é necessário fazer a 
consulta de forma um pouco diferente dos demais bancos:
Caso não queria que o retorno inclua os databases do sistema, ou seja, 
que exiba somente os databases que foram criados, pode-se usar o comando:
Já para listar as tabelas de um database, é necessário escolher um database 
com o comando:
Tipos de bancos de dados8
Após o comando de escolha do database, execute o comando para realizar 
a consulta de todas as tabelas daquele database:
Perceba que o Microsoft SQL Server é menos preparado para trazer esse 
tipo de informação de database ou tabela se comparado aos demais bancos 
de dados.
PostgreSQL
Exibir todos os databases no PostgreSQL é bem simples. Basta digitar:
O retorno do comando será o nome de todos os databases contidos no 
banco de dados independentemente de ter, ou não, tabelas, um database por 
linha. Já para exibir todas as tabelas de um database, primeiro é necessário 
fazer a seleção do database desejada com o comando:
Após a seleção do database, pode-se realizar a consulta das tabelas com 
o comando: 
O retorno desse comando será uma listagem de todas as tabelas daquele 
database selecionado previamente, uma tabela por linha.
Relação entre os bancos de dados
A relação entre os bancos de dados que utilizam a linguagem SQL para con-
sultas é idêntica para o trabalho de manipulação dos dados envolvidos, seja o 
comando de INSERT, UPDATE ou até mesmo o DELETE.
Partindo dessa premissa e também pelo que explica Gomes (2018), a di-
ferenciação entre os bancos de dados, mesmo os que utilizam a linguagem 
SQL, ocorre no âmbito de gerenciamento desses bancos, seja na consulta aos 
nomes de databases que o mesmo possui ou ainda na listagem do nome das 
tabelas (Quadro 1).
9Tipos de bancos de dados
Banco de dados Tipo Exibir os databases
MySQL / MariaDB SQL Show databases;
Microsoft SQL 
Server
SQL SELECT [name] FROM master.
dbo.sysdatabases;
Oracle SQL/NoSQL SELECT NAME FROM v$database;
PostgreSQL SQL \list
MongoDB NoSQL show dbs;
Quadro 1. Relação de banco de dados que utilizam a linguagem SQL
Lembre-se de que os bancos de dados que utilizam a linguagem SQL para realizar a 
manipulação dos dados têm a mesma sintaxe para esse fim.
Edgar Frank “Ted” Codd, pesquisador da IBM na época e que lançou o artigo intitulado 
Relational Model of Data for Large Shared Data Banks, foi considerado o pai dos bancos 
de dados relacionais.
Tipos de bancos de dados10
ALMEIDA, R. Certificação Oracle. 2018. Disponível em: <www.linhadecodigo.com.br/
artigo/451/certificacao-oracle.aspx>. Acesso em: 04 jun. 2018.
GOMES, E. H. Linguagem SQL: linguagem de manipulação, consulta e controle de 
dados. 2018. Disponível em: <ehgomes.com.br/disciplinas/bdd/sql.php>. Acesso 
em: 04 jun. 2018.
KORTH, H. F.; SILBERSHATZ, A.; SUDARSHAN, S. Sistema de banco de dados. 6. ed. Rio 
de Janeiro: Campus, 2012.
MARIADB. 2018. Disponível em: <http://mariadb.org/>. Acesso em: 04 jun. 2018.
MYSQL. 2018. Disponível em: <https://www.mysql.com/>. Acesso em: 04 jun. 2018.
POSTGRESQL. 2018. Disponível em: < https://www.postgresql.org/>. Acesso em: 04 
jun. 2018.
Leituras recomendadas
MIRANDA, W. Certificações Oracle: diferença entre o desenvolvedor e o DBA. 2018. 
Disponível em: <aprendaplsql.com/oracle/certificacao/certificacoes-oracle-diferenca-
-entre-o-desenvolvedor-e-o-dba/>. Acesso em: 04 jun. 2018.
REZENDE, R. Conceitos fundamentais de banco de dados. 2006. Disponível em: <https://
www.devmedia.com.br/conceitos-fundamentais-de-banco-de-dados/1649>. Acesso 
em: 04 jun. 2018.
11Tipos de bancos de dados
Conteúdo:
MODELAGEM E 
DESENVOLVIMENTO 
DE BANCO DE DADOS
Fabrício Felipe 
Meleto Barboza
Revisão técnica:
Izabelly Soares de Morais
Graduada em Licenciatura em Ciência da Computação
Mestre em Ciência da Computação
Catalogação na publicação: Karin Lorien Menoncin – CRB 10/2147
B238m Barboza, Fabrício Felipe Meleto.
Modelagem e desenvolvimento de banco de dados 
[recurso eletrônico] / Fabrício Felipe Meleto Barboza, Pedro 
Henrique Chagas Freitas ; [revisão técnica: Izabelly Soares de 
Morais] – Porto Alegre: SAGAH, 2018. 
ISBN 978-85-9502-517-2
1. Ciência da computação. 2. Banco de dados. I. Freitas, 
Pedro Henrique Chagas.
CDU 004.65
Sistemas de gerenciamento 
de banco de dados
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintesaprendizados:
 � Identificar os sistemas de gerenciamento de banco de dados (SGBD).
 � Criar dicionário de dados.
 � Diferenciar os sistemas de gerenciamento de banco de dados.
Introdução
Neste capítulo, você vai aprender a identificar e reconhecer os diversos 
tipos de sistemas de gerenciamento de bancos de dados. Assim, será 
capaz de discernir os padrões de cada um deles. Além disso, você verá 
para que serve um dicionário de dados e como criá-lo. Por fim, você vai 
saber diferenciar os sistemas de gerenciamento de banco de dados de 
forma natural e rápida.
Os sistemas de gerenciamento de banco 
de dados (SGBDs)
Para realizar o acesso a um banco de dados, é imprescindível utilizar um sistema 
de gerenciamento de banco de dados (SGBD). Aí surge a grande dúvida de 
qual é a diferença entre um banco de dados e um SGBD. Para facilitar o seu 
entendimento, vamos relembrar o conceito de bancos de dados, mencionado 
por Korth, Silberschatz e Sudarshan (2012), que definem que banco de dados 
é uma coleção de dados inter-relacionados, representando informações sobre 
um domínio específico. O SGDB, por sua vez, é definido por Macêdo (2012, 
documento on-line) como “[...] uma coleção de programas que permitem ao 
usuário definir, construir e manipular bases de dados para as mais diversas 
finalidades”.
De forma mais simples e para resumir esses conceitos, você deve considerar 
que bancos de dados são a porção que representa os dados efetivamente salvos, 
e o SGBD é a ferramenta que fica encarregada de salvar, editar, deletar ou ainda 
garantir que esses dados estejam disponíveis quando a aplicação ou o usuário 
requisitar.
Para visualizar essa discussão, veja, a seguir, a Figura 1, que mostra um 
fluxo de trabalho baseado em um relatório solicitado pelo usuário em um 
sistema qualquer e as etapas necessárias para que o resultado seja exibido na 
tela do sistema:
Figura 1. Fluxo de trabalho.
Sistemas de gerenciamento de banco de dados48
Ao observar a Figura 1, vemos que o fluxo de trabalho é dividido entre 
alguns degraus até chegar à informação: sistema, SGBD e o dado necessário 
dentro do banco de dados. Entenda que o sistema não irá acessar diretamente 
o valor desejado, e sim pedir que SGBD o faça.
Novamente surge outra grande dúvida: “mas por que colocar mais com-
plexidade ao pedir que o SGBD execute a busca e retorne com os valores 
desejados e não o sistema final?”.
Antigamente, quando não existiam os SGBDs, a própria aplicação final (ou 
sistema final) deveria fazer essa busca e esse tratamento. O problema disso 
é o aumento da complexidade do código por parte do desenvolvedor, além 
do fato de que a manipulação de dados é algo muito específico. O resultado 
eram sistemas com erros diversos e genéricos, com grande carga de trabalho 
para a correção; quando chegavam a ela, percebiam que era uma exceção que 
o banco de dados havia retornado e que não havia sido tratada.
Com o surgimento dos SGBDs, esses problemas acabaram. A aplicação 
final deve se preocupar em chamar o SGBD conforme sua necessidade, passar 
os valores de busca ou edição desejados e aguardar o retorno. 
Esses SGBDs foram e são desenvolvidos com o único propósito de gerenciar 
e manipular os dados e as variáveis dos bancos de dados, maximizando o 
foco dos desenvolvedores de aplicações naquilo que elas se propõem a fazer 
e entregar valor, em vez de manipular dados.
Um exemplo dessa complexidade maior ao não utilizar um SGBD é a con-
corrência. Imagine que um usuário solicita a edição de um cadastro e salva os 
novos valores no mesmo segundo que outro usuário também salva a informa-
ção desse mesmo cadastro. Como deve proceder a validação? Quem deve ter 
prioridade de tarefa? Qual será a forma de resolver esse impasse? Tudo isso 
deveria estar dentro do código da aplicação final, caso não utilize um SGBD.
Para garantir que um SGBD esteja devidamente cumprindo seu papel, 
Macêdo (2012) menciona que é importante que ele atenda a algumas caracte-
rísticas básicas de trabalho. Estas características elementares são:
 � controle de redundâncias;
 � compartilhamento de dados;
 � controle de acesso;
 � interfaceamento;
 � esquematização;
 � controle de integridade;
 � backups.
49Sistemas de gerenciamento de banco de dados
Likah
Likah
Likah
Likah
A seguir, você verá o conceito que cada uma dessas características engloba 
e exemplos para melhor absorção do conteúdo.
Controle de redundâncias
Os valores de um banco de dados estão armazenados única e exclusivamente 
em um local, evitando problemas com inconsistência devido a valores dife-
rentes. Caso o SGBD tenha replicação de dados, ela ocorrerá após o banco 
de dados máster (principal) ter salvo totalmente os dados, garantindo a 
integridade.
Imagine que uma planilha é enviada por e-mail para várias pessoas e cada uma delas 
faz a edição conforme sua necessidade. Não será mais possível saber quais são os 
valores corretos de cada campo, pois não existe um ponto único de guarda. 
Compartilhamento de dados
O SGBD deve garantir que a concorrência por um mesmo valor de dados 
ocorra sem problemas.
Vários acessos a um mesmo valor e ao mesmo tempo devem retornar igualmente 
para todos, sem problema de valores travados ou ocupados.
Controle de acesso
Deve ser assegurado o controle de acesso ao banco de dados pelo SGBD. 
Para controlar este tipo de atividade, o SGBD utiliza a relação de usuários e 
permissões. 
Sistemas de gerenciamento de banco de dados50
Usuário administrador que possui todos os privilégios, usuário somente para leitura, 
usuário somente para escrita e leitura, etc.
Interfaceamento
Como o SGBD é o único responsável pelo acesso aos dados efetivamente 
guardados, deverá disponibilizar interface de acesso aos dados presentes no 
banco de dados, não podendo ser uma “caixa-preta” de informações.
Consulta por meio de linguagem SQL, interface gráfica, etc.
Esquematização
A existência de uma forma de relacionamento dos dados, presentes nas mais 
diversas tabelas, deve ser clara e precisa.
Chave privada ou estrangeira.
Controle de integridade
Um SGBD deve impedir a todo custo o comprometimento do banco de dados. 
Uma atividade de leitura, escrita, edição, deleção ou qualquer outra manipu-
lação ou é concluída 100% dentro das regras ou é descartada totalmente. Não 
existe manipulação de dados incompleta ou quase completa.
51Sistemas de gerenciamento de banco de dados
Tentativa de gravar um valor do tipo varchar em um campo do tipo numérico resultará 
em erro e não processamento.
Backups
O SGBD deve ser autônomo e conseguir recuperar-se de falhas de software 
e hardware sem a intervenção do pessoal técnico ou ser minimamente de-
pendente deste pessoal.
Ao estar salvando um determinado valor, o servidor do banco de dados sofre algum 
problema e reinicia. Quando o SGBD iniciar novamente, ele irá descartar aquela tran-
sação, retornando ao estado imediatamente anterior àquele job.
Dicionários de dados
Agora que você já tem conhecimento sobre as articulações dos bancos de 
dados e seus sistemas de gerenciamento, como podemos padronizar as infor-
mações? Isso é importante para garantir a integridade dos dados e também 
sua consistência, fatores importantes e totalmente determinantes para a saúde 
do banco de dados.
O dicionário de dados vem para realizar esta padronização básica e ex-
tremamente importante, pois, à medida que o banco de dados cresce e mais 
desenvolvedores são escalados para trabalhar no projeto, mais fora de padrão 
pode ficar o banco de dados como um todo.
De exemplo inicial, imagine que o campo celular, por definição do escopo 
inicial do projeto, deverá ser do tipo varchar e comportar a máscara “(DDD) 
xxxxx-xxxx”. 
Bem, tomando por base essa definição de escopo inicial, foi criada a tabela 
“clientes”, na qual um dos atributos é o campo “celular”, que obedece a essas 
Sistemas de gerenciamento de banco de dados52
regras. Todo o sistema da aplicação foi construído e finalizado, a implantação 
no cliente finalrealizada e, por isso, o banco de dados também foi finalizado 
com sucesso e aderente às regras.
Então, surge uma necessidade de upgrade de funcionalidade exigida 
pelo cliente, o qual deseja que, no cadastro de fornecedores, coloque-se um 
campo de celular de contato com esses fornecedores. Como passou muito 
tempo desde o início do projeto, esqueceu-se que aquela regra do campo de 
celular foi elaborada e é feito este segundo campo sem a opção de DDD ou, 
ainda, em vez de utilizar o separador “-” como pede a regra, foi utilizado 
o separador “.”.
Veja que o banco de dados começa a ficar confuso e sem padrão, fazendo 
com que a função de chamada de cadastro apresente erro ou, ainda, que 
precise ser feita de forma diferente para quando chamar o cadastro de cliente 
em relação a quando chamar o cadastro de fornecedor.
Vamos além? Imagine que exista mais uma tabela que contenha o campo 
celular: a tabela de cadastro de colaboradores. Ela pode ter sido desenvolvida 
por outro programador e, assim, recebeu outra validação de tipo e máscara.
Extrapolando esse exemplo, pense em um sistema de aplicação gigante, 
como um sistema bancário. Como garantir que todos os desenvolvedores 
respeitem as mesmas regras de escopo de campos durante todo o projeto?!
A resposta para essas situações é o dicionário de dados!
No dicionário de dados, também estará a relação de usuários e permissões, 
a estrutura geral e a alocação de espaço.
Assim, definindo a regra do número de celular no dicionário de dados, 
todas as tabelas do sistema devem respeitar o dicionário de dados, criando um 
padrão fácil de ser entendido e respeitado por todos que manipulam o sistema, 
incluindo, aqui, desenvolvedores diferentes.
Um dicionário de dados é, em essência, composto por tabelas que servem de consulta 
para a construção de todas as outras tabelas do SGBD.
O dicionário de dados deve ter regras e valores para cada campo das 
tabelas, de modo que é natural que ocorram situações de opcionalidade de 
um caractere, por exemplo.
53Sistemas de gerenciamento de banco de dados
Para sanar essa situação, você verá, no Quadro 1, um exemplo de tabela 
de símbolo utilizada em um dicionário de dados qualquer:
Fonte: Dicionário de Dados (2017, documento on-line).
Símbolo Significado
= é composto de
( ) opcional
{ } cavalar
[ ] escolha entre uma das alternativas
** comentário
@ chave
/ separa opções alternativas
Quadro 1. Operadores no dicionário de dados
Observe, na Figura 2, um exemplo simples de um dicionário de dados para 
a construção das tabelas cidade, cliente e vendas.
Sistemas de gerenciamento de banco de dados54
Likah
Figura 2. Dicionário de dados.
Fonte: IDCODEX (2014, documento on-line).
Os diferentes Sistemas de Gerenciamento 
de Bancos de Dados 
Cada SGBD, seja ele MySQL, MariaDB, Oracle, Microsoft SQL Server ou 
PostgreSQL, garante a base de administração e manipulação de dados estudada 
e, além disso, apresenta características que o tornam ímpar.
A escolha pelo melhor SGBD se dará em virtude de qual é a aplicação a 
ser desenvolvida, o fluxo de acesso, o tipo de dados a serem guardados e a 
necessidade de profissionais no mercado.
55Sistemas de gerenciamento de banco de dados
Caso sua aplicação seja web, com acessos moderados e tamanho de pequeno 
a médio, poderá optar pelo MySQL, MariaDB ou, ainda, pelo PostgreSQL.
Se a necessidade for a de suportar uma aplicação grande, com vários acessos 
simultâneos, cruzamento de dados intenso e grande granularidade de perfis, 
prefira o Oracle ou o Microsoft SQL Server.
Por fim, se a necessidade de performance estiver acima de qualquer ou-
tra frente, será necessária a utilização de bancos de dados NoSQL, como o 
MongoDB, por exemplo.
Sintaxes
De forma resumida, veja, no Quadro 2, as diferentes sintaxes para exibir as 
databases, selecionar uma database e também exibir as suas tabelas nos mais 
diversos SGBDs.
SGBD
Exibir 
databases
Selecionar 
database
Exibir 
tabelas
MySQL/
MariaDB
Show databases; Use nomeDataBase; Show tables;
Oracle Select NAME from 
v$database;
Connect 
nomeDataBase;
Select table_name 
from user_tables;
Microsoft 
SQL Server
Select [name] 
from master.dbo.
sysdatabases;
Use nomeDataBase; Select * from 
sys.Tables;
PostgreSQL \list \connect 
nomeDataBase;
\dt
Quadro 2. Relação de sintaxes nos SGBDs
Lembre-se que cada tipo de SGBD serve para um propósito. Portanto, é necessário 
entender o ambiente da aplicação para, aí sim, tomar a melhor decisão de escolha 
do sistema.
Sistemas de gerenciamento de banco de dados56
DICIONÁRIO DE DADOS. Wikipédia, 2017. Disponível em: <https://pt.wikipedia.org/
wiki/Dicion%C3%A1rio_de_dados>. Acesso em: 02 jul. 2018.
IDCODEX. Trabalhando com o banco de dados MYSQL (intermediário). 19 mar. 2014. 
Disponível em: <http://idcodex.id3design.com.br/?p=372>. Acesso em: 02 jul. 2018.
KORTH, H. F.; SILBERSCHATZ, A.; SUDARSHAN, S. Sistema de banco de dados. 6. ed. Rio 
de Janeiro: Campus, 2012.
MACÊDO, D. SGBD - Sistema de Gerenciamento de Banco de Dados. 15 jan. 2012. Disponível 
em: <www.diegomacedo.com.br/sgbd-sistema-de-gerenciamento-de-banco-de-
-dados/>. Acesso em: 02 jul. 2018.
Leituras recomendadas
GOMES, E. H. Linguagem SQL: linguagem de manipulação, consulta e controle de 
dados. 2018. Disponível em: <ehgomes.com.br/disciplinas/bdd/sql.php>. Acesso 
em: 02 jul. 2018.
REZENDE, R. Conceitos fundamentais de banco de dados. 2006. Disponível em: <https://
www.devmedia.com.br/conceitos-fundamentais-de-banco-de-dados/1649>. Acesso 
em: 02 jul. 2018.
57Sistemas de gerenciamento de banco de dados
Encerra aqui o trecho do livro disponibilizado para 
esta Unidade de Aprendizagem. Na Biblioteca Virtual 
da Instituição, você encontra a obra na íntegra.
Esta obra é resultado da experiência do autor, adquirida em aulas ministradas em cursos de graduação e pós-
graduação. O texto apresenta a base para entender a tecnologia de banco de dados que oferece suporte aos 
problemas de computação corporativa.
O autor parte do princípio de que o iniciante no estudo de gerenciamento de banco de dados precisa entender os 
conceitos fundamentais sobre o assunto, assim como o modelo de dados relacionais. Com inúmeros exemplos e bancos 
de dados de amostra, o texto permite ao aluno adquirir capacidade para resolver, de forma sistemática, problemas 
básicos e avançados em formulação de consultas, modelagem de dados, normalização, gerenciamento de dados de 
aplicação e customização de aplicações de banco de dados.
T Ó P I C O S I M P O R TA N T E S
• Abordagem abrangente do Oracle 10g e SQL 2003, as aplicações mais recentes de banco de dados.
• Informações novas sobre modelagem de dados e requisitos de sistema.
• Material atualizado sobre normalização.
• Enfoque especial em otimização de banco de dados físico.
• Tendências mais atuais em data warehousing e data mining.
• Abordagem profunda de computação distribuída.
• Questões e problemas no final dos capítulos, além de resumo da sintaxe do SQL:2003.
• Utilização do ER Assistant, uma ferramenta fácil de usar que oferece uma interface simples para criar e con-
verter os diagramas entidade-relacionamento apresentados no livro.
Projeto, Desenvolvimento de Aplicações e Administração de Banco de Dados apresenta as tecnologias 
fundamentais de banco de dados para cada ambiente de processamento e discute o relacionamento de cada 
tecnologia com os avanços do comércio eletrônico e da computação corporativa. Essas características fazem deste 
livro-texto uma ferramenta essencial para aquele que pretende tornar-se especialista em projeto e desenvolvimento 
de aplicações de banco de dados.
Aplicações: Livro-texto para os cursos da área de Computação, como Engenharia de Computação, Ciência da Computação e 
Sistemas de Informação, nas disciplinas específicas de Banco de Dados e outras relacionadas a Desenvolvimento de Sistemas. 
Interessa também aos tecnólogos e aos profissionais que atuam na área de Desenvolvimento de Software utilizando as mais 
recentese avançadas tecnologias de bancos de dados. Ideal para estudantes e profissionais que precisam desenvolver e man-
ter aplicações baseadas em banco de dados.
CRIE UMA BASE SÓLIDA PARA 
GERENCIAMENTO DE BANCO DE DADOS
PROJETO, DESENVOLVIMENTO DE APLICAÇÕES
& ADMINISTRAÇÃO DE BANCO DE DADOS 
PRO
JETO
, D
ESEN
VO
LVIM
EN
TO
 D
E A
PLIC
A
Ç
Õ
ES
&
 A
D
M
IN
ISTRA
Ç
Ã
O
 D
E BA
N
C
O
 D
E D
A
D
O
S 
M
annino
T E R C E I R A E D I Ç Ã O
TRADUÇÃO DA
TERCEIRA
EDIÇÃO
Michael V. ManninoVisite nosso site:
www.mcgraw-hill.com.br9 2 6 0 2 0 1
ISBN 978-85-7726-020-1
7 8 8 5 7 7
TRADUÇÃO DA
M284p Mannino, Michael V.
 Projeto, desenvolvimento de aplicações e administração
 de banco de dados [recurso eletrônico] / Michael V.
 Mannino ; tradução: Beth Honorato ... [et al.] ; revisão
 técnica: Antônio Fernandes Nunes Guardado, Sidney da
 Silva Viana. – 3. ed. – Dados eletrônicos. – Porto Alegre:
 AMGH, 2014.
 Editado também como livro impresso em 2008.
 ISBN 978-85-8055-363-5
 1. Banco de dados – Gerenciamento – Programas de
 computador. 2. Projeto de banco de dados. 3. Software de
 aplicativos – Desenvolvimento. I. Título. 
 CDD 005.74
 CDU 004.658
Catalogação na publicação: Ana Paula M. Magnus – CRB 10/2052
481
Capítulo 14
Administração de Dados
e de Banco de Dados
Objetivos de Aprendizagem
Este capítulo oferece uma visão geral das responsabilidades e ferramentas dos especialistas em
banco de dados conhecidos por administradores de dados e administradores de banco de
dados. No final deste capítulo, o estudante deverá ter adquirido os seguintes conhecimentos
e habilidades:
• Comparar e contrastar as responsabilidades dos administradores de banco de dados e 
administradores de dados.
• Controlar bancos de dados usando instruções SQL em prol da segurança e integridade.
• Gerenciar gatilhos e procedimentos armazenados.
• Compreender os papéis das tabelas dos dicionários de dados e o dicionário de recursos 
de informação.
• Descrever o processo de planejamento de dados.
• Compreender o processo para escolher e avaliar SGBDs.
• Adquirir uma visão sobre os ambientes de processamento nos quais a tecnologia de banco
de dados é utilizada.
Visão Geral
Utilizando o conhecimento e as habilidades das partes 1 a 6, você provavelmente terá capaci-
dade para desenvolver bancos de dados e implementar aplicações que usam banco de dados.
Você obteve informações sobre modelagem conceitual de dados, projeto de banco de dados re-
lacional, formulação de consultas, desenvolvimento de aplicações com visões, procedimentos 
armazenados, gatilhos e desenvolvimento de banco de dados usando requisitos representados
como visões. A Parte 7 complementa essas áreas de conhecimento e habilidade explorando
questões e habilidades concernentes ao gerenciamento de banco de dados em diferentes ambi-
entes de processamento. Este capítulo descreve as responsabilidades e as ferramentas dos es-
pecialistas em dados (administradores de dados e administradores de bancos de dados) e
fornece uma introdução aos diferentes ambientes de processamento de banco de dados.
Antes de conhecer os detalhes dos ambientes de processamento, você precisa com-
preender o contexto organizacional no qual os bancos de dados se encontram e conhecer as
ferramentas e os processos para gerenciá-los. Este capítulo primeiramente examina um con-
texto organizacional para banco de dados. Você obterá informações sobre o suporte do banco
de dados para o gerenciamento da tomada de decisão, os objetivos do gerenciamento de 
14manCap14.qxd 24.10.07 11:51 Page 481
482 Parte Sete Gerenciamento de Ambientes de Banco de Dados
recursos de informação e as responsabilidades dos administradores de dados e de banco de
dados. Após a explanação do contexto organizacional, este capítulo apresenta novos proces-
sos e ferramentas para o gerenciamento de banco de dados. Você aprenderá instruções SQL
para segurança e integridade, gerenciamento de gatilhos e procedimentos armazenados e
manipulação do dicionário de dados, bem como processos para o planejamento de dados e
seleção de SGBDs. Este capítulo é finalizado com uma introdução aos diferentes ambientes
de processamento, os quais serão apresentados mais detalhadamente nos outros capítulos da
Parte 7.
banco de dados 
operacional
um banco de dados para 
dar suporte às funções diárias 
de uma organização.
Hierarquia gerencial
Alta
(estratégia)
Fontes de dados externos e dados resumidos,
bancos de dados táticos
Bancos de dados operacionais
resumidos e integrados
Bancos de dados
operacionais individuais
Bancos de dados operacionais
Média
(tática)
Baixa
(operacional)
FIGURA 14.1 Apoio do Banco de Dados para os Níveis de Gerência
14.1 Contexto Organizacional para o Gerenciamento de Banco de Dados
Esta seção revisa os níveis de tomada de decisão gerencial e discute o suporte do banco de
dados para a tomada de decisão em todos os níveis. Após essa ambientação, esta seção des-
creve a função do gerenciamento de recursos de informação e as responsabilidades dos espe-
cialistas em dados no gerenciamento desses recursos.
14.1.1 Utilização do Banco de Dados como Suporte para a Tomada
de Decisão Gerencial
Os bancos de dados fornecem suporte às operações de negócio e à tomada de decisão geren-
cial em vários níveis. As grandes organizações, em sua maioria, desenvolveram vários ban-
cos de dados operacionais para ajudar a conduzir seus negócios com eficácia. Os bancos de
dados operacionais oferecem assistência direta às principais funções organizacionais, como
processamento de pedidos, manufatura, contas a pagar e distribuição de produtos. Os fatores
que justificam o investimento em um banco de dados operacional em geral são: maior ve-
locidade de processamento, maior volume de negócios e menores custos com pessoal.
À medida que as organizações conseguem aprimorar suas operações, elas começam a
perceber o potencial para tomada de decisão de seus bancos de dados. Os bancos de dados
operacionais oferecem a matéria-prima para a tomada de decisão gerencial, como descrito na
Figura 14.1. Os níveis inferiores de gerência podem obter relatórios sobre exceções e proble-
mas diretamente dos bancos de dados operacionais. Entretanto, maior valor deve ser adi-
cionado para alavancar os bancos de dados operacionais para a alta e média gerência. Os ban-
cos de dados operacionais devem ser limpos e organizados, integrados e resumidos para
proporcionar valor para a tomada de decisão tática e estratégica. A integração é necessária
porque os bancos de dados operacionais em geral são desenvolvidos isoladamente, sem levar
em consideração as necessidades de informação da tomada de decisão tática e estratégica.
14manCap14.qxd 24.10.07 11:51 Page 482
Capítulo 14 Administração de Dados e de Banco de Dados 483
A Tabela 14.1 fornece exemplos de gerenciamento de decisões e requisitos de dados. A
baixa gerência lida com problemas de curto prazo relacionados com transações individuais.
Os resumos periódicos dos bancos de dados operacionais e os relatórios de exceção ajudam o
gerenciamento operacional. A média gerência, que se vale dos dados resumidos que são inte-
grados nos bancos de dados operacionais, pode querer integrar os dados dos diferentes de-
partamentos, fábricas e lojas de varejo. A alta gerência, que se vale dos resultados da análise
da média gerência e das fontes externas de informação, necessita integrar os dados de modo
que os clientes, os produtos, os fornecedores e outras entidades importantes possam ser lo-
calizados em toda a organização. Além disso, os dados externos devem ser resumidos e inte-
grados com os dados internos.
14.1.2 Gerenciamento de Recursos de Informação para o 
Gerenciamento do Conhecimento
Em resposta aos desafios de alavancar bancos de dados operacionais e tecnologia da infor-
mação para a tomadade decisão gerencial, ganhou corpo a filosofia do gerenciamento de re-
cursos de informação. O gerenciamento de recursos de informação abrange o processamento,
a distribuição e a integração de informações em toda a organização. Um dos elementos prin-
cipais do gerenciamento de recursos de informação é o controle dos ciclos de vida da infor-
mação (Figura 14.2). Cada nível de tomada de decisão gerencial e de operações de negócio
tem seu próprio ciclo de vida da informação. Para que a tomada de decisão seja eficaz, os ci-
clos de vida devem ser integrados para fornecer informações oportuna e consistentemente.
Por exemplo, os ciclos de vida da informação das operações oferecem informações aos ciclos
de vida da tomada de decisão gerencial.
ciclo de vida 
da informação
os estágios da transformação 
da informação em uma
organização. O ciclo de vida 
da informação é exclusivo para
cada entidade e deve ser
gerenciado e integrado com 
os ciclos de vida em outras
entidades.
Armazenamento
Aquisição
Uso
Disseminação
Formatação
Processamento
Proteção
FIGURA 14.2
Estágios Típicos do Ciclo 
de Vida da Informação
TABELA 14.1
Exemplos de Tomada 
de Decisão Gerencial
Nível Gerencial Exemplos de Decisão Requisitos de Dados
Alto Identificar novos mercados e produtos; Previsões econômicas e tecnológicas;
planejar o crescimento; realocar resumo de notícias; relatórios industriais;
recursos nas divisões. relatórios de desempenho de médio prazo.
Médio Selecionar fornecedores; fazer a previsão Tendências históricas; desempenho do 
de vendas, de estoque e de caixa; examinar fornecedor; análise do caminho crítico;
os níveis de pessoal; preparar orçamentos. planos de curto e médio prazo.
Baixo Montar escala de funcionários; corrigir Relatórios sobre problemas; relatórios de
atrasos nos pedidos; identificar gargalos na exceções; escala de funcionários; resultados
produção; monitorar o uso de recursos. da produção diária; níveis de estoque.
14manCap14.qxd 24.10.07 11:51 Page 483
484 Parte Sete Gerenciamento de Ambientes de Banco de Dados
A qualidade dos dados é um fator especial do gerenciamento de recursos de informação
em virtude de seu impacto sobre a tomada de decisão gerencial. Como discutido no Capítulo
2, a qualidade dos dados está relacionada a inúmeras dimensões, como correção, oportu-
nidade, consistência, completude e confiabilidade. Normalmente, o nível de qualidade dos
dados suficiente para as operações de negócio pode ser insuficiente para a tomada de decisão
nos níveis de gerência superiores. Esse conflito é especialmente verdadeiro para a dimensão
consistência. Por exemplo, a inconsistência na identificação de um cliente nos bancos de
dados operacionais pode prejudicar a tomada de decisão no nível de gerência superior. O
gerenciamento de recursos de informação enfatiza um ponto de vista sobre qualidade de
dados de longo prazo para a organização como um todo com vistas a apoiar a tomada de deci-
são gerencial.
Nos últimos anos, tem havido um movimento para estender o gerenciamento de recursos
de informação para o gerenciamento do conhecimento. Tradicionalmente, o gerenciamento
de recursos de informação tem enfatizado a tecnologia no sentido de apoiar receitas pre-
definidas para a tomada de decisão, em vez de a capacidade para reagir a um ambiente de
negócios em constante mudança. Para ter êxito no atual ambiente de negócios, as organiza-
ções devem enfatizar a reação e adaptação rápidas, em vez de planejamento. Para enfrentar
esse desafio, o Dr. Yogesh Malhotra, famoso consultor gerencial, defende que as organizações
devem desenvolver sistemas que facilitem a criação de conhecimento, em vez de o gerencia-
mento da informação. Para a criação de conhecimento, ele é defensor de uma maior ênfase
sobre o processamento de informações humanas e a dinâmica da organização para equilibrar
a ênfase sobre a tecnologia, como mostrado na Figura 14.3.
Essa visão do gerenciamento do conhecimento oferece um contexto para o uso da tecnolo-
gia da informação para solucionar problemas corporativos. Não basta ter a melhor tecnologia da
informação, é preciso alinhá-la com os elementos humanos e da organização. A tecnologia da in-
formação deve ampliar a capacidade intelectual do indivíduo, compensar as limitações do
processamento humano e apoiar a dinâmica organizacional positiva.
14.1.3 Responsabilidades dos Administradores de Dados e dos
Administradores de Banco de Dados
Novas responsabilidades gerenciais surgiram como parte do controle de recursos de infor-
mação. Administrador de dados (DA, data administrator) é uma posição da média ou alta
gerência que tem amplas responsabilidades pelo gerenciamento de recursos de informação. O
administrador de banco de dados (DBA, database administrador) desempenha uma função de
suporte cujas responsabilidades estão relacionadas aos bancos de dados individuais e aos
SGBDs. A Tabela 14.2 compara as responsabilidades de ambas as funções. O administrador
de dados vê os recursos de informação em um contexto mais amplo que o administrador de
banco de dados. O primeiro considera todos os tipos de dados, estejam eles armazenados 
em bancos de dados relacionais, arquivos, páginas Web ou fontes externas. O segundo nor-
malmente considera apenas os dados armazenados nos bancos de dados.
gerenciamento 
do conhecimento
aplicar a tecnologia da
informação com as capacidades
humanas de processamento de
informações e os processos da
organização para suportar uma
rápida adaptação à mudança.
Tecnologia
Dinâmica da
organização
Processamento de
informações humanas
FIGURA 14.3
Três Pilares do
Gerenciamento do
Conhecimento
14manCap14.qxd 24.10.07 11:51 Page 484
Likah
Likah
Likah
Likah
Capítulo 14 Administração de Dados e de Banco de Dados 485
O desenvolvimento de um modelo de dados corporativo é uma das responsabilidades
mais importantes do administrador de dados. Ele oferece um modelo integrado de todos os
bancos de dados da organização. Por causa de seu escopo, ele é menos detalhado que os ban-
cos de dados individuais que ele engloba. Esse modelo concentra-se nos principais assuntos
dos bancos de dados operacionais, e não no detalhamento completo, e pode ser desenvolvido
para o planejamento de dados (que banco de dados desenvolver) ou como suporte à tomada
de decisão (como integrar e resumir os bancos de dados existentes). A Seção 14.3 descreve
em detalhes o planejamento de dados, ao passo que o Capítulo 16 descreve em detalhes o 
desenvolvimento de um modelo de dados corporativo como suporte à tomada de decisão. O ad-
ministrador de dados em geral participa significativamente de ambos esses empreendimentos.
As grandes organizações podem oferecer especialização em administração de dados e de
banco de dados. No primeiro caso, a especialização pode ocorrer por tarefa e ambiente. Em
relação à tarefa, os administradores de dados podem especializar-se em planejamento em
contraste com o estabelecimento de políticas. Em relação ao ambiente, eles podem espe-
cializar-se em ambientes como apoio a decisões e processamento de transações e em dados
não tradicionais como imagens, textos e vídeo. No caso do administrador de banco de dados, a
especialização pode ocorrer por SGBD, tarefa e ambiente. Por causa da complexidade da
aprendizagem de SGDBs, os administradores de banco de dados normalmente se especia-
lizam em um ou em poucos produtos. No que diz respeito à tarefa, a especialização em geral
se divide entre modelagem de dados e avaliação de desempenho. Com respeito ao ambiente,
a especialização em geral se divide entre processamento de transações e datawarehouses.
Nas pequenas organizações, a fronteira entre a administração de dados e a administração
de banco de dados é flexível. É provável que não haja posições distintas para administradores de
dados e de banco de dados. A mesma pessoa pode desempenhar ambas as funções. À medida
que as organizações evoluem, a especialização normalmente se desenvolve de modo que se
criem funções distintas.
TABELA 14.2
Responsabilidadesdos
Administradores de Dados 
e dos Administradores de
Bancos de Dados
Posição Responsabilidades
Administrador de dados Desenvolve um modelo de dados corporativo.
Estabelece padrões e políticas entre bancos de dados com
relação à nomeação, ao compartilhamento de dados e à
propriedade dos dados.
Negocia prazos contratuais com os fornecedores de tecnologia
da informação.
Desenvolve planos de longo prazo de tecnologia da informação.
Administrador de banco de dados Desenvolve conhecimento detalhado dos SGBDs individuais.
Procura informações sobre o desenvolvimento de aplicações.
Realiza a modelagem de dados e o projeto lógico de banco 
de dados.
Faz cumprir os padrões de administração de dados.
Monitora o desempenho do banco de dados.
Realiza a avaliação técnica dos SGBDs.
Cria instruções de segurança, integridade e processamento 
de regras.
Concebe padrões e políticas relacionadas aos bancos de dados 
e SGBDs individuais.
modelo de dados 
corporativo
um modelo conceitual de dados
de uma organização. Um
modelo de dados corporativo
pode ser usado para o
planejamento de dados e o
suporte à tomada de decisão.
14.2 Ferramentas de Administração de Banco de Dados
Para cumprir as responsabilidades mencionadas na seção anterior, os administradores de banco
de dados usam uma variedade de ferramentas. Você já obteve informações sobre ferramentas
para modelagem de dados, projeto lógico de banco de dados, projeto físico de banco de dados,
gatilhos e procedimentos armazenados. Algumas das ferramentas são instruções SQL (CREA-
TE VIEW e CREATE INDEX), ao passo que outras fazem parte das ferramentas CASE para o
desenvolvimento de banco de dados. Esta seção apresenta outras ferramentas para segurança,
integridade e acesso a dicionários de dados, e examina o gerenciamento de gatilhos e procedi-
mentos armazenados.
14manCap14.qxd 24.10.07 11:51 Page 485
486 Parte Sete Gerenciamento de Ambientes de Banco de Dados
14.2.1 Segurança
A segurança está relacionada à proteção de um banco de dados contra acesso não autorizado
e ações mal-intencionadas de devastação. Por causa do valor dos dados nos bancos de dados
corporativos, há grande motivação por parte dos usuários não autorizados a ganhar acesso
não autorizado a esses bancos. Os concorrentes se sentem muito motivados a acessar infor-
mações confidenciais sobre planos de desenvolvimento de produtos, iniciativas de economia
de custos e perfil de clientes. O desejo dos criminosos à espreita é furtar informações ainda
não divulgadas sobre resultados financeiros e transações de negócio e dados confidenciais
sobre clientes, como número de cartão de crédito. Os transgressores sociais e terroristas
podem causar problemas e prejuízos significativos destruindo intencionalmente os registros
de um banco de dados. Dado o uso crescente da Internet para a condução de negócios, con-
correntes, criminosos e transgressores sociais têm cada vez mais oportunidade de compro-
meter a segurança dos bancos de dados.
Segurança é um tema amplo que envolve várias áreas. Existem os aspectos éticos e
legais sobre quem pode acessar os dados e quando os dados podem ser divulgados. Existem
redes, hardware, sistemas operacionais e controles físicos que aumentam os controles ofere-
cidos pelos SGBDs. Existem ainda problemas operacionais relacionados com senhas, dis-
positivos de autenticação e cumprimento da privacidade. Essas questões não são tratadas em
maior profundidade porque estão além do escopo dos especialistas em SGBDs e bancos de
dados. O restante desta subseção enfatiza as abordagens de controle de acesso e as instruções
SQL para regras de autorização.
Para o controle de acesso, os SGBDs ajudam a criação e a armazenagem de regras de au-
torização e o cumprimento dessas regras quando os usuários tentam acessar o banco de
dados. A Figura 14.4 mostra a interação desses elementos. Os administradores de banco 
de dados criam regras de autorização que definem quem pode acessar que parte de um banco de
dados e para qual operação. O cumprimento das regras de autorização requer a autenticação do
usuário e assegura que as referidas regras não foram violadas pelas solicitações de acesso (re-
cuperação e modificação de informações do banco de dados). A autenticação ocorre quando um
usuário se conecta pela primeira vez ao SGBD. As regras de autorização devem ser verificadas
para cada solicitação de acesso.
A abordagem mais comum de regras de autorização é conhecida por controle de acesso
discricionário. Nesse tipo de controle, os usuários recebem direitos ou privilégios de acesso a
partes específicas de um banco de dados. Para exercer um controle preciso, os privilégios em
geral são especificados para visões, e não para tabelas ou campos. Os usuários podem receber
permissão para ler, atualizar, inserir e excluir partes específicas de um banco de dados. Para
simplificar a manutenção das regras de autorização, é possível conceder privilégios a grupos ou
papéis, em vez de a usuários individuais. Pelo fato de os papéis serem mais estáveis que usuários
segurança do banco 
de dados
proteger bancos de dados contra
acessos não autorizados e
destruição mal-intencionada.
regras de autorização
definem usuários autorizados,
operações permissíveis e partes
acessíveis do banco de dados. 
O sistema de segurança do
banco de dados armazena regras
de autorização e as aplica para
cada acesso ao banco de dados.
controle de acesso 
discricionário
os usuários recebem direitos ou
privilégios de acesso a partes
específicas de um banco de
dados. O controle de acesso
discricionário é o tipo mais
comum de controle de 
segurança suportado por 
SGBDs comerciais.
DBA
Usuários
Dicionário de dados
 Sistema de segurança
do banco de dados
Regras de autorização
Autenticação,
requisições de acesso
FIGURA 14.4
Sistema de Segurança 
de um Banco de Dados
14manCap14.qxd 24.10.07 11:51 Page 486
Capítulo 14 Administração de Dados e de Banco de Dados 487
individuais, as regras de autorização que fazem referência a papéis exigem menor manutenção
que as regras que fazem referência a usuários individuais. Os usuários são designados a papéis e
recebem senhas. Durante o processo de login em um banco de dados, o sistema de segurança do
banco de dados autentica os usuários e menciona os papéis aos quais eles pertencem.
Os controles de acesso obrigatório são menos flexíveis que os controles de acesso dis-
cricionários. Nas abordagens de controle obrigatório, a cada objeto é atribuído um nível de
classificação e a cada usuário é atribuído um nível de autorização. Um usuário pode acessar
um objeto se o seu nível de autorização oferecer acesso ao nível de classificação do objeto em
questão. Os níveis comuns de autorização e classificação são confidencial, secreto e ultra-se-
creto. As abordagens de controle de acesso obrigatório foram originalmente aplicadas em
bancos de dados altamente sensíveis e estáticos para defesa nacional e coleta de informações
secretas. Em virtude da limitada flexibilidade dos controles de acesso obrigatórios, apenas 
alguns SGBDs os aceitam. Entretanto, os SGBDs que são usados na defesa nacional e coleta
de informações secretas devem aceitar controles obrigatórios.
Além dos controles de acesso, os SGBDs aceitam encriptação de dados. A encriptação
envolve a codificação de dados para obscurecer seu significado. Um algoritmo de encriptação
modifica os dados originais (conhecidos por texto puro ou plaintext). Para decifrar os dados,
o usuário fornece uma chave de encriptação para restaurar os dados encriptados (conhecidos
por texto cifrado ou ciphertext) para o seu formato original (texto puro). Dois entre os algo-
ritmos de encriptação mais comuns são o padrão de encriptação de dados e encriptação de
chave pública. Pelo fato de o padrão de encriptação de dados poder ser quebrado por um
poder computacional gigantesco, o algoritmo de encriptação de chave pública tornou-se a
abordagem preferida.
Instruções de Segurança do SQL:2003
O SQL:2003 oferece suporte a regras de autorização discricionária usandoas instruções
CREATE/DROP ROLE e as instruções GRANT/REVOKE. Quando se cria o papel, o SGBD
concede o papel tanto ao usuário atual quanto ao papel atual. No Exemplo 14.1, os papéis Pro-
fessorSI e ConsultorSI são concedidos ao usuário atual, enquanto o papel AdministradorSI é
concedido ao papel do usuário atual. A cláusula WITH ADMIN significa que um usuário ao
qual foi atribuído o papel pode atribuir o papel a outros usuários. A opção WITH ADMIN
deve ser usada moderadamente porque oferece ampla liberdade de ação ao papel. Um papel pode
ser suspenso com a instrução DROP ROLE.
controle de acesso 
obrigatório
uma abordagem de segurança de
banco de dados para bancos 
de dados altamente sensíveis e
estáticos. Um usuário pode
acessar um elemento do banco
de dados se o nível de
autorização do usuário permite o
acesso ao nível de classificação
do elemento.
EXEMPLO 14.1 Exemplos da Instrução CREATE ROLE
(SQL:2003) CREATE ROLE ProfessorSI;
CREATE ROLE AdministradorSI WITH ADMIN CURRENT_ROLE;
CREATE ROLE ConsultorSI;
Na instrução GRANT, você especifica os privilégios (consulte a Tabela 14.3), o objeto
(tabela, coluna ou visão) e a lista de usuários autorizados (ou papéis). No Exemplo 14.2, o
acesso SELECT é atribuído a três papéis (ProfessorSI, ConsultorSI, AdministradorSI), ao
passo que o acesso UPDATE é dado apenas a AdministradorSI. Aos usuários individuais
devem ser atribuídos papéis para que possam acessar a visão MediaGeralAlunoSI.
TABELA 14.3
Explicação sobre os
Privilégios Comuns do
SQL:2003
Privilégio Explicação
SELECT Consulta o objeto; pode ser especificado para colunas individuais
UPDATE Modifica o valor; pode ser especificado para colunas individuais
INSERT Adiciona uma nova linha; pode ser especificado para colunas individuais
DELETE Exclui uma linha; não pode ser especificado para colunas individuais
TRIGGER Cria um gatilho em uma tabela estipulada
REFERENCES Menciona as colunas de uma determinada tabela nas restrições de integridade
EXECUTE Executa o procedimento armazenado
14manCap14.qxd 24.10.07 11:51 Page 487
Likah
488 Parte Sete Gerenciamento de Ambientes de Banco de Dados
A instrução GRANT pode também ser usada para designar usuários aos papéis, como
mostrado nas três últimas instruções GRANT no Exemplo 14.2. Além de conceder os privi-
légios da Tabela 14.3, um usuário pode ser autorizado a passar privilégios a outros usuários
por meio da palavra-chave WITH GRANT OPTION. Na última instrução GRANT do Exem-
plo 14.2, o usuário Smith pode conferir o papel AdministradorSI a outros usuários. A opção
WITH GRANT deve ser usada com moderação porque oferece ampla liberdade de ação ao
usuário.
Para remover um privilégio de acesso, é usada a instrução REVOKE. Na última ins-
trução do Exemplo 14.2, o privilégio SELECT é removido de ProfessorSI. A cláusula RES-
TRICT significa que o privilégio é revogado apenas se ele não tiver sido concedido por mais
de um usuário ao papel especificado.
Segurança no Oracle e no Access
O Oracle 10g estende as instruções de segurança do SQL:2003 com a instrução CREATE
USER, papéis predefinidos e privilégios adicionais. No SQL:2003, a criação de usuário é
tratada como implementação. Visto que o Oracle não depende do sistema operacional para a
criação de usuário, ele oferece a instrução CREATE USER. O Oracle fornece papéis pre-
definidos para usuários altamente privilegiados, incluindo o papel CONNECT, para a criação
de tabelas em um esquema, o papel RESOURCE, para a criação de tabelas e objetos de apli-
cação – por exemplo, procedimentos armazenados –, e o papel DBA, para o gerenciamento
do banco de dados. Em relação aos privilégios, o Oracle faz distinção entre privilégios de sis-
tema (independentes do objeto) e privilégios de objeto. A concessão de privilégios de sistema
normalmente está reservada aos papéis altamente seguros em virtude das amplas conseqüên-
cias que os privilégios de sistema podem causar, como mostrado na Tabela 14.4. Os privilé-
gios de objeto do Oracle são semelhantes aos do SQL:2003, exceto que o Oracle fornece mais
objetos que o SQL:2003, como mostrado na Tabela 14.5.
Os SGBDs, em sua maioria, permitem restrições de autorização por objetos de apli-
cação, como formulários e relatórios, além dos objetos de banco de dados permissíveis na
instrução GRANT. Essas outras restrições de segurança geralmente são especificadas em in-
terfaces proprietárias ou em ferramentas de desenvolvimento de aplicações, em vez de no
SQL. Por exemplo, o Microsoft Access 2003 permite que se definam regras de autorização
por meio da janela Permissões para Usuário e Grupo, como exibido na Figura 14.5. As per-
missões para os objetos de banco de dados (tabelas e consultas armazenadas), bem como para
os objetos de aplicação (formulários e relatórios), podem ser especificadas por meio dessa
janela. Além disso, o SQL aceita as instruções GRANT/REVOKE semelhantes às instruções
do SQL:2003, assim como as instruções CREATE/DROP para usuários e grupos.
EXEMPLO 14.2 Definição de Visão e Instruções GRANT e REVOKE
(SQL:2003) CREATE VIEW MediaGeralAlunoSI AS
SELECT CPFAluno, NomeAluno, SobrenomeAluno, MediaAluno
FROM Aluno
WHERE Especializacao = ‘SI’:
-- Concede privilégios aos papéis
GRANT SELECT ON MediaGeralAlunoSI
TO ProfessorSI, ConsultorSI, AdministradorSI
GRANT UPDATE ON MediaGeralAlunoSI.MediaAluno TO AdministradorSI;
-- Designa usuários aos papéis
GRANT ProfessorSI TO Mannino;
GRANT ConsultorSI TO Olson;
GRANT AdministradorSI TO Smith WITH GRANT OPTION;
REVOKE SELECT ON MediaGeralAlunoSI FROM ProfessorSI RESTRICT;
14manCap14.qxd 24.10.07 11:51 Page 488
Capítulo 14 Administração de Dados e de Banco de Dados 489
TABELA 14.4
Explicação sobre os
Privilégios de Sistema
Comuns do Oracle
Privilégio de Sistema Explanação
CREATE X, CREATE ANY X Cria objetos do tipo X no esquema de alguém; CREATE ANY
permite que se criem objetos em outros esquemas1
ALTER X, ALTER ANY X Altera objetos do tipo X no esquema de alguém; ALTER ANY X
permite que se alterem objetos em outros esquemas.
INSERT ANY, DELETE ANY, Insere, exclui, atualiza e seleciona em uma tabela de qualquer 
UPDATE ANY, SELECT ANY esquema
DROP X, DROP ANY X Exclui objetos do tipo X no esquema de alguém. DROP ANY
permite que se excluam objetos em outros esquemas
ALTER SYSTEM, ALTER Emite comandos ALTER SYSTEM, comandos ALTER DATABASE 
DATABASE, ALTER SESSION e comandos ALTER SESSION
ANALYZE ANY Analisa qualquer tabela, índice ou grupo
TABELA 14.5
Mapeamento entre
Privilégios e Objetos
Comuns do Oracle
Procedimento, Função,
Privilégio/ Pacote, Biblioteca, Visão
Objeto Tabela Visão Seqüência2 Operador, Tipo de Índice Materializada3
ALTER X X
DELETE X X X
EXECUTE X
INDEX X
INSERT X X X
REFERENCES X X
SELECT X X X X
UPDATE X X X
1 Esquema é um conjunto de tabelas relacionadas e outros objetos Oracle que são tratados como uma
unidade.
2 Seqüência é um conjunto de valores mantido pelo Oracle. As seqüências normalmente são usadas para
chaves primárias geradas pelo sistema.
3 A visão materializada é armazenada, em vez de derivada. As visões materializadas são úteis em
datawarehouses, como descrito no Capítulo 16.
FIGURA 14.5
Janela Permissões para
Usuário e Grupo no
Microsoft Access 2003
14manCap14.qxd 24.10.07 11:51 Page 489
Encerra aqui o trecho do livro disponibilizado para 
esta Unidade de Aprendizagem. Na Biblioteca Virtual 
da Instituição, você encontra a obra na íntegra.
 
BANCO DE 
DADOS
Edinilson da Silva Vida
Projeto de banco de dados: 
modelos conceitual, 
lógico e físico
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Definir os modelos conceitual, físico e lógico.
 � Converter modelos de banco de dados conceitual, lógico e físico.
 � Ilustrar a modelagem de banco de dados relacional com SQL.
Introdução
O conhecimento acerca dos modelos entidade-relacionamento (MERs) 
possibilita a criação de pequenos e grandes projetos lógicos de bancos 
de dados e de modelagens de alta qualidade, propiciando o sucesso dos