Livro-Texto BANCO DE DADOS

Prévia do material em texto

Autores: Profa. Gisele Lopes Batista Pinto
 Prof. Luiz Fernando de Lima Santos
Colaboradores: Prof. Roberto Macias
Profa. Elisângela Mônaco de Moraes
Prof. Emanuel Augusto Severino de Matos
Administração de
Banco de Dados
Professores conteudistas: Gisele Lopes Batista Pinto / Luiz Fernando de Lima Santos
Gisele Lopes Batista Pinto
É licenciada em Matemática pelo Instituto de Matemática e Estatística da Universidade de São Paulo, com 
especialização em Automação e Informática Industrial pela Escola Politécnica da USP.
Depois de um instigante e divertido período lecionando Matemática no Ensino Médio e para cursos de 
Magistério em uma escola pública no Estado de São Paulo, voltou-se para a Tecnologia da Informação. Durante 
onze anos, foi Administradora de Bancos de Dados (DBA) no Departamento de Informática da Reitoria da USP e há 
cinco anos integra o Grupo de Projetos Institucionais do mesmo Departamento, atuando nas áreas de Mídias Sociais 
e Inteligência Corporativa.
Luiz Fernando de Lima Santos
É formado em Ciências da Computação pela Uninove e pós-graduado em Tecnologia da Informação pela UNIP. 
Atua há mais de 10 anos na área de Banco de Dados e Business Intelligence, com passagem por empresas como 
Unilever e Johnson & Johnson, e com experiência nos maiores bancos do mercado como Microsoft SQL Server e Oracle. 
É professor de Banco de Dados na UNIP nas modalidades presencial e a distancia (EaD).
© Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida por qualquer forma e/ou 
quaisquer meios (eletrônico, incluindo fotocópia e gravação) ou arquivada em qualquer sistema ou banco de dados sem 
permissão escrita da Universidade Paulista.
Dados Internacionais de Catalogação na Publicação (CIP)
P659a Pinto, Gisele Lopes Batista 
Administração de banco de dados / Gisele Lopes Batista Pinto; 
Luiz Fernando Lima dos Santos. São Paulo: Editora Sol, 2020
108 p., il.
Nota: este volume está publicado nos Cadernos de Estudos e 
Pesquisas da UNIP, Série Didática, ISSN 1517-9230.
1. Informática. 2. Banco de dados. 3. Administração. I. Santos 
dos, Luiz Fernando Lima. II. Título.
CDU 004.65
U504.48 – 20
Prof. Dr. João Carlos Di Genio
Reitor
Prof. Fábio Romeu de Carvalho
Vice-Reitor de Planejamento, Administração e Finanças
Profa. Melânia Dalla Torre
Vice-Reitora de Unidades Universitárias
Prof. Dr. Yugo Okida
Vice-Reitor de Pós-Graduação e Pesquisa
Profa. Dra. Marília Ancona-Lopez
Vice-Reitora de Graduação
Unip Interativa – EaD
Profa. Elisabete Brihy 
Prof. Marcelo Souza
Prof. Dr. Luiz Felipe Scabar
Prof. Ivan Daliberto Frugoli
 Material Didático – EaD
 Comissão editorial: 
 Dra. Angélica L. Carlini (UNIP)
 Dra. Divane Alves da Silva (UNIP)
 Dr. Ivan Dias da Motta (CESUMAR)
 Dra. Kátia Mosorov Alonso (UFMT)
 Dra. Valéria de Carvalho (UNIP)
 Apoio:
 Profa. Cláudia Regina Baptista – EaD
 Profa. Betisa Malaman – Comissão de Qualificação e Avaliação de Cursos
 Projeto gráfico:
 Prof. Alexandre Ponzetto
 Revisão:
 Andréia Andrade
 Michel Apt
 Sueli Brianezi Carvalho
Sumário
Administração de Banco de Dados
APRESENTAÇÃO ......................................................................................................................................................9
INTRODUÇÃO ...........................................................................................................................................................9
Unidade I
1 INTRODUÇÃO A BANCO DE DADOS ..........................................................................................................11
1.1 Histórico ................................................................................................................................................... 12
1.1.1 Modelo hierárquico ................................................................................................................................ 14
1.1.2 Modelo em rede ...................................................................................................................................... 15
1.2 Definição de banco de dados .......................................................................................................... 16
1.3 Tipos de bancos de dados ................................................................................................................. 17
1.3.1 Bancos de dados relacionais .............................................................................................................. 17
1.3.2 Bancos de dados não relacionais ..................................................................................................... 18
1.3.3 Bancos de dados orientados a objeto ............................................................................................ 18
1.4 Sistemas de Gerenciamento de Banco de Dados (SGBD) .................................................... 19
1.5 Funções básicas de um SGBD .......................................................................................................... 21
1.5.1 Método de acesso ................................................................................................................................... 21
1.5.2 Restrições de Integridade (RI) ........................................................................................................... 22
1.5.3 Segurança .................................................................................................................................................. 22
1.5.4 Controle de concorrência .................................................................................................................... 23
1.5.5 Independência dos dados .................................................................................................................... 23
1.6 Arquitetura básica de um SGBD ..................................................................................................... 23
1.6.1 Nível físico ................................................................................................................................................. 23
1.6.2 Nível conceitual ....................................................................................................................................... 23
1.6.3 Nível de visão ........................................................................................................................................... 24
1.7 Como os dados são armazenados ................................................................................................. 24
1.7.1 Diferença entre dado e informação ................................................................................................ 25
1.7.2 Dicionário de Dados (DD) .................................................................................................................... 25
2 AGENTES DE INTERAÇÃO COM O SGBD ................................................................................................. 25
2.1 DBA – Data Base Administrator ..................................................................................................... 26
2.1.1 AD – Administrador de dados ............................................................................................................ 26
2.1.2 Desenvolvedor de banco de dados .................................................................................................. 26
2.1.3 Programador ............................................................................................................................................. 26
2.2 Certificações ........................................................................................................................................... 27
2.2.1 Certificação Microsoft .......................................................................................................................... 27
2.2.2 Certificação Oracle .................................................................................................................................27
Unidade II
3 DIAGRAMA ENTIDADE-RELACIONAMENTO (E-R) .............................................................................. 33
3.1 Entidades do DER ................................................................................................................................. 33
3.2 Relacionamentos do DER .................................................................................................................. 33
3.2.1 Relacionamentos binários ................................................................................................................... 33
3.2.2 Relacionamentos reflexivos ................................................................................................................ 34
3.2.3 Relacionamentos ternários ................................................................................................................. 34
3.3 Atributos do DER .................................................................................................................................. 34
3.3.1 Atributos opcionais ................................................................................................................................ 35
3.3.2 Atributos compostos ............................................................................................................................. 35
3.3.3 Atributos multivalorados ..................................................................................................................... 35
3.4 Entidades fracas .................................................................................................................................... 35
3.5 Especialização ........................................................................................................................................ 35
3.5.1 Especialização com ou sem exclusão mútua .............................................................................. 35
3.5.2 Especialização com ou sem obrigatoriedade .............................................................................. 36
3.6 Agregação ................................................................................................................................................ 36
4 MODELO ENTIDADE RELACIONAMENTO (MER)................................................................................... 36
4.1 Domínio .................................................................................................................................................... 37
4.2 Atributo do MER ................................................................................................................................... 37
4.3 Tupla .......................................................................................................................................................... 38
4.4 Relação ..................................................................................................................................................... 38
4.5 Chave ......................................................................................................................................................... 38
4.5.1 Chave primária (PK) – primary key .................................................................................................. 38
4.5.2 Chave estrangeira (FK) – foreign key .............................................................................................. 39
4.5.3 Chave artificial ou delegada (SK) – surrogate key .................................................................... 39
4.6 Restrições de integridades básicas ................................................................................................ 40
4.6.1 Regra de integridade de entidade ................................................................................................... 40
4.6.2 Regra de integridade referencial ...................................................................................................... 40
4.7 Tipos de relacionamento ................................................................................................................... 43
4.8 Normalização ......................................................................................................................................... 44
4.8.1 Primeira Forma Normal (1FN) ............................................................................................................ 44
4.8.2 Segunda Forma Normal (2FN) ........................................................................................................... 46
4.8.3 Terceira Forma Normal (3FN) ............................................................................................................. 47
Unidade III
5 PROJETO DE BANCO DE DADOS ................................................................................................................ 52
5.1 Linguagens de banco de dados ...................................................................................................... 52
5.2 Tipos de linguagem SQL .................................................................................................................... 53
5.2.1 Data Definition Language (DDL) ....................................................................................................... 53
5.2.2 Data Manipulation Language (DML) ............................................................................................... 54
5.2.3 Data Control Language (DCL) ............................................................................................................ 55
5.2.4 Data Transaction Language (DTL) ..................................................................................................... 57
5.2.5 Data Query Language (DQL) ............................................................................................................... 58
5.3 Módulos de funcionamento do SGBD ......................................................................................... 63
5.4 Etapas do projeto de banco de dados .......................................................................................... 64
5.4.1 Levantamento de requisitos ............................................................................................................... 65
5.4.2 Projeto conceitual .................................................................................................................................. 65
5.4.3 Projeto lógico ........................................................................................................................................... 65
5.4.4 Projeto físico ............................................................................................................................................. 66
5.4.5 Criação do banco de dados ................................................................................................................ 66
5.4.6 Exemplo de projeto de banco de dados ........................................................................................ 66
6 TIPOS DE DADOS (DATA TYPES) ................................................................................................................. 68
6.1 Elementos de dados ............................................................................................................................ 69
6.1.1 Estrutura de dados ................................................................................................................................. 69
6.1.2 Unidades de medidas ............................................................................................................................ 71
Unidade IV
7 ADMINISTRAÇÃO DE BANCO DE DADOS ............................................................................................... 77
7.1 Backup ......................................................................................................................................................78
7.1.1 Recuperação e concorrência .............................................................................................................. 78
7.1.2 Pontos de sincronização ...................................................................................................................... 79
7.2 Meios de recuperação (restore) ...................................................................................................... 80
7.2.1 Falhas do sistema .................................................................................................................................... 80
7.2.2 Falhas dos meios físicos ....................................................................................................................... 81
7.3 Concorrência .......................................................................................................................................... 81
7.4 Bloqueio (Lock) ...................................................................................................................................... 82
7.5 Arquitetura básica do ambiente de banco de dados ............................................................. 84
7.5.1 Cluster de alto desempenho .............................................................................................................. 84
7.5.2 Cluster de alta disponibilidade .......................................................................................................... 84
7.5.3 Cluster para balanceamento de carga ........................................................................................... 84
7.6 Replicação ............................................................................................................................................... 85
7.6.1 Replicação síncrona (eager)................................................................................................................ 85
7.6.2 Replicação assíncrona (lazy) ............................................................................................................... 85
7.6.3 Replicação unidirecional (master-slave) ....................................................................................... 86
7.6.4 Replicação multidirecional (multi-master) .................................................................................. 86
7.6.5 Exemplo de funcionamento de um cluster com replicação .................................................. 86
8 MODELO DIMENSIONAL ............................................................................................................................... 87
8.1 Fatos .......................................................................................................................................................... 88
8.2 Dimensão ................................................................................................................................................. 89
8.2.1 Chave artificial (surrogate key) ......................................................................................................... 90
8.3 Medidas .................................................................................................................................................... 90
8.4 Granularidade ........................................................................................................................................ 90
8.5 Agregados ................................................................................................................................................ 91
8.6 Passos do projeto de DW ................................................................................................................... 92
8.7 Data mart (DM) ..................................................................................................................................... 94
8.8 Ferramentas de acesso aos dados ................................................................................................. 94
9
APRESENTAÇÃO
O conceito de banco de dados é importante porque auxilia no desenvolvimento das aplicações para 
os sistemas de informação, comunicação e processos de automação. Por meio deste curso, você será 
capaz de avaliar as tecnologias e arquiteturas disponíveis no mercado e fazer a escolha mais adequada. 
Além disso, você poderá entender os assuntos referentes à modelagem de dados e identificar os aspectos 
que impactam no desempenho e na segurança dos dados da empresa.
Todo o controle sobre o armazenamento e a manipulação de dados no que diz respeito ao acesso, 
à integridade física e lógica, à segurança, à redundância, concorrência entre as diversas aplicações, 
autorização para as diversas operações etc., são de responsabilidade de um software denominado de 
Sistema Gerenciador de Banco de Dados, isto é, o SGBD. Esses softwares são capazes de gerenciar 
diversos bancos de dados em um único sistema.
INTRODUÇÃO
O surgimento da tecnologia de banco de dados ocorreu no momento em que os especialistas 
no desenvolvimento de sistemas computacionais perceberam que, para a informatização de 
grandes organizações, várias questões relacionadas com o gerenciamento de dados necessitavam 
ser resolvidas de forma mais eficiente, por exemplo, o acesso aos dados de diferentes setores 
de uma mesma empresa, por aplicações diferentes, de forma compartilhada e consistente, 
evitando a falta de padronização e problemas de segurança dos dados. A manutenção de uma 
base de dados consistente, sem o auxílio das técnicas e ferramentas que envolvem os bancos 
de dados, torna-se um trabalho insano. A maior dificuldade em construir sistemas corporativos 
em uma organização ocorre quando os dados são armazenados de forma não integrada com 
um projeto global da empresa. Se cada setor mantiver uma base de dados local e independente, 
fica extremamente difícil a integração das aplicações e a construção de um sistema de apoio 
gerencial para a organização.
A reflexão que devemos fazer é a seguinte: a empresa pode não ter a certeza de qual é a verdade 
referente à informação, mas ela deve ser única em todos os setores da organização. Se o relatório do setor 
de pessoal mostrar que a empresa tem 500 funcionários, significa que todos os relatórios dos demais 
setores devem ter o mesmo resultado. E isso só é possível se a fonte dessa informação for única em todos 
os setores, ou seja, estão cadastradas no mesmo banco de dados da empresa e não mais em 
arquivos locais de cada setor. O banco de dados passa a ser o repositório único dos dados, com 
controle eficiente das operações realizadas sobre os dados armazenados, sem falar na segurança.
Portanto, inicialmente, apresentaremos o conceito e um breve histórico sobre o surgimento dos 
bancos de dados. Mostraremos os diversos tipos de bancos de dados e falaremos um pouco sobre 
a carreira de um administrador de banco de dados. Depois, discutiremos os conceitos baseados na 
modelagem física e na lógica dos dados e as técnicas de desenvolvimento de um projeto de banco de 
dados e suas aplicações. Também apresentaremos a linguagem de programação usada para tratar os 
dados que estão e serão armazenados nas estruturas de banco de dados. Por fim, falaremos sobre a 
importância e as técnicas para salvar ou restaurar com segurança os dados armazenados.
11
ADMINISTRAÇÃO DE BANCO DE DADOS
Unidade I
1 INTRODUÇÃO A BANCO DE DADOS
O desenvolvimento de um sistema de informação envolve a análise e o projeto de dois componentes: 
os dados e os processos.
O projeto de dados é considerado a parte estática do sistema, uma vez que diz respeito a um universo 
persistente de características que dificilmente sofre modificações após a sua definição.
O projeto de processos, por sua vez, é chamado de parte dinâmica, uma vez que as tarefas a serem 
realizadas sobre os dados podem variar, conforme ocorre a evolução do sistema.
Considera-se projeto de um banco de dados a análise, o projeto e a implementação dos dados persistentesde uma aplicação, levando em conta a determinação da sua semântica (abstração dos dados de uma realidade) 
e, posteriormente, o modelo de dados e o Sistema Gerenciador de Banco de Dados (SGBD) a serem adotados.
O projeto de um banco de dados é composto das seguintes etapas:
Descrição de requisito
Etapa em que são coletadas informações sobre os dados de interesse da aplicação, seu uso, ou seja, 
as operações de manipulação sobre elas e suas relações.
Para a realização dessa etapa, são necessárias tarefas como entrevistas com os futuros usuários do 
sistema, análise de documentações disponíveis, arquivos, relatórios etc. O resultado normalmente é uma 
descrição dos requisitos da aplicação mais detalhada e clara possível.
Caso nenhuma metodologia de engenharia de software esteja sendo empregada, essa descrição de 
requisitos é uma descrição informal, na forma de um texto, que contém as informações necessárias para 
o entendimento da aplicação.
Projeto conceitual
Pode ser considerada a fase de análise dos dados ou requisitos capturados na etapa anterior.
Nessa etapa, é realizado o que chamamos de modelagem conceitual: são analisados os fatos de 
interesse, isto é, as entidades ou conjunto de ocorrências de dados e seus relacionamentos, juntamente 
com seus atributos e propriedades ou características, e construída uma notação gráfica para facilitar o 
entendimento dos dados e suas relações, tanto para os analistas quanto para os futuros usuários.
12
Unidade I
Essa etapa resulta em um modelo conceitual, em que a semântica da realidade deve estar correta. A 
ferramenta mais usada nessa etapa é o Diagrama Entidade-Relacionamento (ER).
Projeto lógico
Considerada a fase de projeto dos dados. Nessa etapa, o desenvolvimento do banco de dados começa 
a se voltar para o ambiente de implementação, uma vez que é feita a conversão do modelo conceitual 
para um modelo de dados de um banco de dados (modelo lógico). Esse modelo de dados pode ser 
relacional, orientado a objetos ou dimensional, por exemplo.
Essa etapa se baseia no uso de regras de mapeamento de um tipo de diagrama de acordo com 
o modelo de dados definido. Pode ser um diagrama E-R ou um diagrama de classes, entre outros. O 
resultado é uma estrutura lógica, como um conjunto de tabelas relacionadas.
Projeto físico
Esta última etapa realiza a adequação do modelo lógico gerado na etapa anterior ao formato de 
representação de dados do Sistema Gerenciador de Banco de Dados escolhido para a implementação.
Para a realização dessa etapa, deve-se conhecer os elementos e o funcionamento do SGBD, para a 
criação da estrutura lógica definida no modelo. O resultado é a especificação do esquema da aplicação 
e na implementação das restrições de integridade.
1.1 Histórico
Podemos afirmar que a história dos bancos de dados se inicia na década de 1950, no momento em 
que surge a necessidade de armazenar os dados gerados nos computadores. Nessa época, os recursos 
disponíveis eram bem inferiores em relação aos existentes hoje em dia. Antigamente, os dados eram 
armazenados em fitas magnéticas ou em cartões perfurados, e eram lidos e gravados de forma sequencial.
Na década de 1960, apareceram os primeiros discos rígidos, e com isso os dados não precisaram mais 
ser gravados de forma sequencial. Surgiu, então, um dos primeiros modelos, conhecido como Modelo 
Hierárquico, que organizava dados em uma estrutura em árvore. Os SGBD mais conhecidos, nessa época, 
foram o IMS e o System 2000.
No final da década de 1960 e durante a década de 1970, surgiu o Modelo de Redes, que organizava 
os dados em uma estrutura formada por várias listas, que definia uma intrincada rede de ligações. Nessa 
época, os SGBD mais conhecidos foram o IDMS e o Total.
O Modelo Relacional é o modelo de dados dominante no mercado ainda hoje e surgiu na década 
de 1970. Ele foi proposto por Edgar Frank Codd e se tornou um marco em como pensar em banco de 
dados. Codd desconectou a estrutura lógica do banco de dados do método de armazenamento físico, 
organizando os dados em um conjunto de relações. Essas relações são denominadas de tabelas.
13
ADMINISTRAÇÃO DE BANCO DE DADOS
Em cima da teoria de Codd, foram criados dois protótipos de sistemas relacionais, que depois foram 
sendo aperfeiçoados com o tempo. O primeiro foi o Ingress, desenvolvido pela UCB, que serviu como 
base para os sistemas Ingres Corp., Sybase, MS-SQL Server, Britton-Lee, Wang PACE (que utilizava QUEL 
como linguagem de consulta). O outro, o System-R, foi desenvolvido pela IBM San Jose e serviu de base 
para o IBM SQL/DS, IBM DB2, Oracle, todos os bancos de dados da HP e o Tandem’s Non-Stop SQL, que 
utilizava SEQUEL como linguagem de consulta. O termo Sistema de Gerenciamento de Banco de Dados 
Relacional (SGBDR ou RDBMS em inglês) foi definido durante esse período.
Figura 1 – Dr. Peter Chen
O doutor Peter Chen propõe o modelo Entidade-Relacionamento (ER) para projetos de banco de 
dados, dando uma nova e importante percepção dos conceitos de modelos de dados. Assim como as 
linguagens de alto nível, a modelagem ER possibilita ao projetista concentrar-se apenas na utilização 
dos dados, sem se preocupar com a estrutura lógica de tabelas.
A partir da década de 1980, com o advento da computação pessoal, novos modelos começaram a 
ser definidos, visando atender às necessidades de aplicações ditas não convencionais, ou seja, aplicações 
cujas entidades apresentam uma estrutura que não de adéqua bem com a organização relacional 
de dados.
A Linguagem Estruturada de Consultas (SQL) se torna a linguagem padrão mundial para os Sistemas 
Gerenciadores de Banco de Dados. Nessa década, surge também o modelo cliente-servidor, que muda a 
forma como os sistemas seriam concebidos.
A internet chega aos lares ainda um pouco rudimentar se compararmos com a de hoje, mas funcional 
o suficiente para que as pessoas se comuniquem. E, desde então, a pesquisa científica na área procura 
evoluir no sentido de definir e encontrar modelos que representem da melhor maneira possível os dados 
14
Unidade I
de uma realidade, ou seja, que os organizem de forma mais próxima à maneira como estes são vistos e 
manipulados pelas pessoas no mundo real.
A grande maioria dos bancos de dados conhecidos hoje comercialmente foi criada nessa época. Com 
a evolução, começaram a surgir conceitos que são utilizados até os dias de hoje, como:
• OLTP – Online Transaction Process (Processos de Transação em Tempo Real)
• OLAP – Online Analytical Process (Processos Analíticos em Tempo Real)
• Open Source – software livre, que são os que mudariam o conceito de posse de um software. Os 
sistemas open source se baseiam em quatro leis, ou quatro liberdades, que são:
– Liberdade nº 0: a liberdade de executar o programa, para qualquer propósito.
– Liberdade nº 1: a liberdade de estudar como o programa funciona e adaptá-lo para suas 
necessidades. Acesso ao código-fonte é um pré-requisito para essa liberdade.
– Liberdade nº 2: a liberdade de redistribuir cópias de modo que você possa ajudar ao seu próximo.
– Liberdade nº 3: a liberdade de aperfeiçoar o programa e liberar seus aperfeiçoamentos, de 
modo que toda a comunidade se beneficie. Acesso ao código-fonte é um pré-requisito para 
essa liberdade.
1.1.1 Modelo hierárquico
O modelo hierárquico foi definido com base na observação de que muitas entidades do 
mundo real são organizadas hierarquicamente. Nesse modelo, os dados são organizados 
em um conjunto de tipos de registros (entidades), interconectados por meio de ligações 
(relacionamentos).
Uma ligação representa uma relação entre exatamente dois tipos de registros: pai e filho. 
Assim, tanto o esquema quanto os dados (ocorrências) são visualizados por meio de uma 
estrutura em árvore, em que um ou vários tipos de registros filhos podem estar vinculados a um 
tipo de registro pai.
Um esquema no modelo hierárquico é chamado de diagrama de estrutura em árvore, conforme 
podemos ver na Figura 3.
O sentido de acesso é sempre unidirecional,ou seja, sempre do pai para o filho (parte sempre da raiz 
e percorre os níveis inferiores).
15
ADMINISTRAÇÃO DE BANCO DE DADOS
Cecília
5657-3 3584-7 2576-5 4876-2 800,00100,68576,80300,00
Lauro Elaine Guarujá 257-1376Mauá 257-6425Taubaté 526-7890
Figura 2 – Diagrama de estrutura em árvore
 Observação
O modelo hierárquico não suporta relacionamentos com cardinalidade 
N:N em decorrência da organização em árvore, que permite apenas 
cardinalidade 1:1 e 1:N, ou seja, um tipo de registro filho sempre está 
relacionado a um único tipo de registro pai. E um pai, por sua vez, pode se 
relacionar com vários filhos.
Os casos de cardinalidade N:N devem, então, ser modelados como uma relação 1:N, por meio da 
escolha de qual registro será tratado como pai. A indicação é escolher aquele registro que apresentar um 
maior valor médio de cardinalidade para ser o tipo de registro pai. A redundância de dados é inevitável, 
caso uma ocorrência de um tipo de registro filho se relacionar com mais de uma ocorrência de um tipo 
de registro pai. No modelo hierárquico, não há acesso direto a ocorrências de tipos de registros filho.
1.1.2 Modelo em rede
Esse modelo é muitas vezes denominado de Modelo DBTG-CODASYL (Data Base Task Group – 
subgrupo da Conference on Data Systems and Language), uma organização existente na década de 
1970 responsável pela padronização de linguagens de programação de sistemas.
Similar ao modelo hierárquico, os dados no modelo de redes são organizados em tipos e ligações 
entre dois tipos de registros. Não existe restrição hierárquica, ou seja, quaisquer dois tipos de registros 
podem se relacionar. Assim, tanto o esquema quanto as ocorrências de dados são visualizados como um 
grafo direcionado. Um esquema no modelo de redes é chamado de diagrama de estrutura de dados, de 
acordo com a Figura 3.
Nome_Cli Cidade_Cli Tel_Cli #_CC Saldo
ContaCliente
Figura 3 – Diagrama de estrutura de dado
16
Unidade I
Toda vez que existe um relacionamento com cardinalidade 1:1 ou 1:N, define-se um set, ou seja, o tipo 
de registro com cardinalidade fixa igual a 1 é chamado de owner e o outro, de member. Uma ocorrência de 
um set equivale a uma lista encadeada que parte do owner e encadeia todos os members relacionados a ele.
Quando existe um relacionamento com cardinalidade M:N, define-se o que se chama de conector: 
um tipo de registro adicional que estabelece uma ligação entre dois tipos de registro, ou seja, dois sets 
são definidos, transformando um relacionamento M:N em dois relacionamentos 1:N. Esse conector pode 
ou não ter atributos.
 Observação
No modelo em rede, cada relacionamento presente gera listas encadeadas 
e, com isso, as consultas que percorrem por muitos relacionamentos têm 
seu desempenho (performance) comprometido.
1.2 Definição de banco de dados
Um banco de dados pode ser definido como sendo uma coleção de dados operacionais 
inter-relacionados. Esses dados são armazenados de forma independente dos programas que os utilizam, 
servindo assim a múltiplas aplicações de uma organização.
Além disso, o banco de dados deve ser o repositório único de armazenamento dos dados, pois, com 
isso, diminuímos a redundância e eliminamos redefinições de dados semelhantes de diversas fontes. O 
acesso ao banco de dados é realizado por meio de linguagens de alto nível para manipulação de dados. 
Em outras palavras, um banco de dados é um sistema de manutenção de registros. O seu objetivo 
principal é manter as informações para, quando solicitadas, serem disponibilizadas ao usuário.
Existem diversas plataformas de banco de dados, e a escolha depende do orçamento e de políticas 
de investimento em TI nas organizações. Houve um tempo em que apenas as plataformas proprietárias 
ofereciam produtos de qualidade e segurança, e somente empresas com elevado capital tinham 
condições de adquirir esses produtos. Mas, com o amadurecimento das plataformas open source, as 
pequenas empresas também podem desenvolver seu projeto de banco de dados de forma tão eficiente 
e segura quanto as empresas de grande porte.
Dentre as empresas fornecedoras de plataformas proprietárias de banco de dados, destacamos as seguintes:
• Oracle – <www.oracle.com>
• Microsoft – <www.microsoft.com>
• Sybase (SAP) – <www.sybase.com>
• IBM – <www.ibm.com>
17
ADMINISTRAÇÃO DE BANCO DE DADOS
Apesar de oferecerem plataformas pagas, elas costumam disponibilizar uma versão gratuita do 
banco de dados. Mas essas versões gratuitas não são recomendadas para projetos em sistemas de 
produção, porque possuem limitações se comparadas com a versão paga. No site dos fornecedores, há 
as recomendações e restrições para o uso dessas versões.
Normalmente, elas são usadas na fase inicial do projeto, para ajudar na escolha da plataforma definitiva que 
será posteriormente adquirida. Funcionam como um teste drive, em que podemos conhecer o produto sem custos.
As soluções chamadas open source mais conhecidas são:
• MySQL – <www.mysql.com>
• PostgreSQL – <www.postgresql.org>
• Cassandra – <cassandra.apache.org>
• SQLite – <www.sqlite.org>
 Saiba mais
Para saber mais e se manter atualizado(a) com os novos projetos e 
eventos sobre software livre, recomendamos os sites: <http://softwarelivre.
org> e <http://www.softwarelivre.gov.br>.
1.3 Tipos de bancos de dados
Existem diferentes tipos de bancos de dados, os mais conhecidos são:
• relacionais;
• não relacionais;
• orientados a objeto.
1.3.1 Bancos de dados relacionais
Bancos relacionais são os bancos derivados das primeiras pesquisas, realizadas em meados da década 
de 1970. São o tipo de banco mais utilizado no mundo. Os dados são separados em entidades, conforme 
cada assunto, e gravados como atributos dessas entidades. Permitem que essas entidades se relacionem 
entre si e proporcionam uma forma rápida e segura de armazenar e recuperar os dados.
Os mais conhecidos são:
• SQL Server Microsoft – <www.microsoft.com/sqlserver>
18
Unidade I
• MySQL – <www.mysql.com>
• PostgreSQL – <www.postgresql.org>
• Informix – <www-01.ibm.com/software/data/Informix>
• DB2 – <www-01.ibm.com/software/data/db2>
• Sybase – <www.sybase.com>
• Oracle – <www.oracle.com>
1.3.2 Bancos de dados não relacionais
Um banco de dados é dito não relacional quando não suporta instruções e operações de junção 
na linguagem SQL. São muito utilizados em sistemas para a internet, por causa da velocidade e da 
escalabilidade maior em relação aos bancos relacionais. As primeiras pesquisas surgiram em 1998, mas 
o termo NoSQL (not only sql) como conhecemos hoje surgiu em 2009.
Os mais conhecidos são:
• Hadoop – <hadoop.apache.org>
• Cassandra – <cassandra.apache.org>
• Hypertable – <hypertable.org>
• Amazon Simple DB – <aws.amazon.com/pt/simpledb>
• CloudData – <www.cloudata.org>
 Saiba mais
Para mais informações sobre os bancos não relacionais, recomendamos 
o site <http://nosql-database.org>.
1.3.3 Bancos de dados orientados a objeto
Dizemos que um banco de dados é orientado a objetos quando cada informação é armazenada na 
forma de objetos, ou seja, utiliza a estrutura de dados chamada de orientação a objetos.
Os mais conhecidos são:
• db4objects – <www.db4o.com>
• GemStone – <www.gemstone.com>
19
ADMINISTRAÇÃO DE BANCO DE DADOS
• Caché – <www.intersystems.com.br>
• Zope – <zope.org>
1.4 Sistemas de Gerenciamento de Banco de Dados (SGBD)
Um SGBD é um sistema cujo objetivo principal é gerenciar o acesso e a correta manutenção dos 
dados armazenados em um ou mais bancos de dados. O acesso aos dados é disponibilizado por meio de 
uma interface que permite a comunicação com a aplicação desenvolvida.
Em outras palavras, um SGBD é um software que serve de interface entre o usuário e o banco de 
dados em si.
Software para
processar consultas
Software para
acessar dados armazenados
Programas de
Aplicação/consultasUsuários
SGBD
Software
SGBD
Meta-dados
armazenados
Base de dados
armazenados
Figura 4 – Esquema de um SGBD
Os SGBD têm interfaces bem parecidas. Todospossuem o que chamamos de Object Explorer no lado 
esquerdo, onde é exibida a estrutura do banco de dados.
Eles utilizam um formato análogo ao do Windows Explorer, permitindo a navegação entre os objetos 
do banco de dados. Do lado direito, temos uma tela dividida em suas partes na vertical. Normalmente, a 
parte de cima é onde se digitam os comandos SQL, e a parte de baixo é onde se visualizam os resultados.
A seguir, alguns exemplos de interface utilizados pelo administrador de banco de dados para 
gerenciar os bancos de dados.
20
Unidade I
Figura 5 – SQL Server Management Studio
Figura 6 – Oracle PL-SQL Developer
21
ADMINISTRAÇÃO DE BANCO DE DADOS
Figura 7 – PHPMyAdmin
 Observação
Você pode testar o Sistema Gerenciador do Banco de Dados MySQL, 
conhecido como phpMyAdmin, pelo link:
<http://demo.phpmyadmin.net/master-config>.
1.5 Funções básicas de um SGBD
Com base na definição, as seguintes funções básicas são encontradas:
1.5.1 Método de acesso
Duas categorias de linguagem, conhecidas como DDL (Data Definition Language) e DML (Data 
Manipulation Language), devem ser suportadas.
A DDL permite a especificação do esquema da organização, ou seja, entidades com seus atributos e 
tipos de dados associados, os relacionamentos entre essas entidades e os índices de acesso associados 
aos atributos. Por esquema, entende-se uma organização lógica dos dados de uma realidade, adequados 
ao modelo de dados do SGBD.
A DML permite as operações de manipulação de dados, executadas pelas aplicações inclusão, 
alteração, exclusão e consulta. As consultas devem ser executadas de maneira eficaz, procurando 
minimizar o número de acessos ao meio de armazenamento secundário, assim como o volume de dados 
gerados nos resultados intermediários do processamento da consulta. Para tanto, a antecipação da 
22
Unidade I
aplicação de filtros e a busca apenas de dados relevantes para os relacionamentos, em uma certa etapa 
do processamento, são exemplos de estratégias que são consideradas.
1.5.2 Restrições de Integridade (RI)
Integridade está associada à ideia de dados corretos, consistentes no banco de dados. As restrições 
de integridade preocupam-se em manter dados sempre coerentes, verdadeiros com a realidade em 
questão.
Devem garantir os estados possíveis de serem assumidos pelos dados, por exemplo, alterações no 
valor do salário não podem diminuir o valor existente. A manutenção dos relacionamentos válidos entre 
os dados devem ser mantidas, isto é, se existe uma regra que diz que uma turma de alunos, por exemplo, 
não pode estar vinculada a mais de uma disciplina, então deve existir uma restrição de integridade que 
garanta essa regra de negócio. Para tanto, o SGBD deve disponibilizar uma linguagem para especificação 
de restrições de integridade, chamada de DCL (Data Constraint Language), e por meio dessa linguagem 
é possível programar testes e ações.
1.5.3 Segurança
Esse controle evita a violação dos dados por agentes e/ou situações não previstas, ou seja, as falhas.
Políticas de autorização de acesso devem permitir que apenas agentes autorizados sejam usuários 
ou aplicações, realizem certas operações sobre certos dados. Para tanto, faz-se necessário manter uma 
matriz de autorização, que especifica, para cada agente e cada dado, as operações autorizadas. Por dado, 
entende-se alguma porção do banco de dados, como um ou mais registros, um arquivo completo ou 
vários, alguns campos de um registro etc. O mecanismo de visões permite especificar a porção do banco 
de dados que um agente tem direito a acesso.
A recuperação de falhas deve possibilitar o retorno do banco de dados a um estado consistente 
de seus dados após a ocorrência de uma falha. Para tanto, o SGBD deve manter arquivos históricos 
(log), que cadastram todas as alterações realizadas no banco de dados por transações. Entende-se por 
transação um conjunto de operações de manipulação de dados que é submetido ao banco de dados, 
sendo que todas essas operações devem ser efetivadas ou, na ocorrência de uma falha, nada deve ser 
efetivado, para preservar a consistência dos dados.
Os arquivos históricos (log) devem registrar, dentre outras coisas, a identificação das transações, 
os arquivos manipulados, os registros atualizados, a operação feita e os valores atual e antigo. No 
caso de falhas de transação ou de sistema, o arquivo histórico (log) deve ser consultado e as ações 
realizadas por transações inacabadas devem ser desfeitas. Caso todas as modificações da transação 
estejam registradas, é possível refazê-la. Já para falhas de meio de armazenamento, que tornam 
inoperantes as unidades de disco onde se encontra o banco de dados, deve-se restaurar o banco de 
dados a partir do último backup realizado e consultar o log para refazer ou desfazer as transações 
cadastradas após esse backup.
23
ADMINISTRAÇÃO DE BANCO DE DADOS
1.5.4 Controle de concorrência
Esse controle evita conflitos de acesso simultâneo a um dado por mais de uma transação.
Se esse controle não existisse, os dados consultados por uma transação poderiam se tornar inválidos 
caso fossem atualizados por outra transação. Esse controle geralmente é feito pelo uso de estratégias 
de bloqueio (lock), que garantem que apenas uma transação manipule um dado, durante o espaço de 
tempo que necessitar, sem que ocorra interferência de outras transações.
1.5.5 Independência dos dados
Essa funcionalidade do SGBD é uma decorrência direta das vantagens trazidas pelo uso de um banco 
de dados. Independência de dados significa transparência de gerenciamento e armazenamento, assim 
como do esquema global da organização, para as aplicações.
O primeiro caso é chamado de independência física, ou seja, a aplicação não se preocupa com 
detalhes de localização física dos dados ou controles de integridade e segurança. A independência 
lógica garante, pelo mecanismo de visões, que uma aplicação tenha condições de especificar a porção 
do banco de dados que deseja ter acesso, não precisando ter conhecimento do esquema global.
1.6 Arquitetura básica de um SGBD
Um SGBD geralmente interage com diversas aplicações de uma organização, assim como com os 
meios de armazenamento de dados. No primeiro caso, a aplicação se vale de comandos DML embutidos 
no seu código. No segundo caso, geralmente existe uma interface com o sistema operacional do 
equipamento, para leitura e gravação de dados.
Assim, um SGBD lida com diversos níveis de visão de um mesmo dado, de maneira a abstrair detalhes 
da organização dos dados.
1.6.1 Nível físico
Nível mesmo abstrato, em que se sabem detalhes físicos da organização de um dado, ou seja, o 
esquema físico. É uma estruturação de baixo nível, em que é descrito como os dados estão armazenados 
em termos de bytes. O módulo de gerenciamento de arquivos lida com esse nível de visão dos dados, 
uma vez que localiza, lê e grava registros.
1.6.2 Nível conceitual
Nível intermediário, que suporta uma descrição de mais alto nível em relação ao nível físico, em 
que a preocupação está em descrever quais dados são significativos para uma organização, isto é, têm 
semântica, são relevantes para o dia a dia da organização. Nesse caso, trabalha-se com os dados em 
nível de entidades e relacionamentos, tais quais estão definidos no esquema. É similar, por analogia, 
à descrição de um registro em uma linguagem de programação, ou seja, trabalha-se com nomes 
24
Unidade I
de arquivos e campos e não com sequências de bytes. Os usuários que lidam nesse nível devem ter 
conhecimento completo de todo o esquema da organização, como o administrador do banco de dados 
ou o usuário especializado.
1.6.3 Nível de visão
Nível mais alto de abstração, sendo particular de cada aplicação que manipula dados do banco de 
dados. Nesse caso, cada aplicação pode determinar o universo de dados que deseja ter acesso. Esse 
universo de dados pode ser uma porção do esquema global da organização. Assim sendo, cada aplicação 
abstrai detalhes irrelevantes, desnecessários paraseu processamento. Os usuários desse nível são os 
programas de aplicação.
1.7 Como os dados são armazenados
Os dados são armazenados em áreas chamadas páginas. O tamanho dessas páginas pode variar de 
banco para banco. Nelas, são armazenados os dados e os metadados (são os dados dos dados).
Figura 8 – Exemplo de uma página de dados
Os elementos de uma página são:
a) PAGE HEADER DATA: armazena as informações, como a última atualização dos dados, a posição 
do próximo dado a ser gravado etc.;
b) ITEM POINTER DATA: grava as informações sobre os índices dos dados;
c) ITENS: são os dados e metadados, propriamente ditos.
25
ADMINISTRAÇÃO DE BANCO DE DADOS
1.7.1 Diferença entre dado e informação
Para simplificar, podemos dizer que tudo o que é armazenado pode ser considerado como dado. Por 
exemplo: um nome de uma pessoa, um nome de um produto, uma data, um local, um endereço, um 
número de telefone etc.
A informação surge quando agregamos dois ou mais dados e, a partir deles, inferimos uma conclusão. 
Por exemplo, vamos considerar os seguintes dados registrados:
• Estado = São Paulo
• Data = 28 de agosto de 1978
• Nome = Luiz Fernando
Nesse caso, temos os seguintes dados, que isoladamente não têm nenhum significado, ou seja, 
temos uma cidade ou um Estado, temos uma data e um nome de uma pessoa. Mas, dependendo do 
contexto em que esses dados aparecem, podemos chegar a algumas conclusões, como: a pessoa é 
paulista, se essa data se refere à data de nascimento, podemos afirmar que ela tem 32 anos e é do 
signo de virgem.
1.7.2 Dicionário de Dados (DD)
É o catálogo responsável pela manutenção dos metadados que dizem respeito à estrutura do 
esquema, à integridade, às configurações do SGBD para efeitos de controle, segurança e desempenho 
(performance), às estimativas de acesso e estimativas sobre os dados. É constantemente consultado 
durante a realização de várias das suas tarefas, como processamento de consultas, pré-compilação de 
comandos DML, verificação de integridade em operações de atualização etc.
O administrador do banco de dados tem acesso às suas informações por meio de ferramentas 
especiais.
 Lembrete
Estrutura de esquema se refere às entidades (com atributos e tipos de 
dados associados) e relacionamentos.
2 AGENTES DE INTERAÇÃO COM O SGBD
Um SGBD deve se comunicar com vários agentes (usuários ou programas), com o objetivo de atender 
às necessidades de dados de diversas aplicações, permitir o desenvolvimento de aplicações que utilizam 
um banco de dados, assim como possibilitar que aspectos de performance possam ser otimizados, 
conforme a demanda de acesso a dados pelas aplicações.
26
Unidade I
Os sistemas gerenciadores de banco de dados são projetos com muitos recursos visuais e aplicações 
internas que servem como verdadeiros assistentes. Ainda assim, eles não se autoadministram, ou seja, 
não eliminam a necessidade dos profissionais especializados, apenas agilizam tarefas trabalhosas, como 
escrever scripts.
2.1 DBA – Data Base Administrator
Especialista no SGBD adotado pela organização, o DBA (Administrador de Banco de Dados) 
é o profissional que controla diversos aspectos funcionais, como definição e modificação do 
esquema, das autorizações de acesso e das regras de integridade. Além disso, tem o controle 
dos procedimentos de segurança, execução de backups e recuperação de falhas de meio de 
armazenamento, assim como monitoração de performance de acesso de dados e tomada de 
decisões para melhorias no SGBD.
Lembrete: o backup parece simples, mas, na verdade, precisa ser bem planejado. Surge a questão: 
fazer o backup completo, que armazena todos os registros do banco de dados, várias vezes ao dia, 
prejudicando a performance do sistema, ou fazer backups incrementais, que só armazenam a lista dos 
registros que foram alterados e que complicam uma eventual restauração?
2.1.1 AD – Administrador de dados
É o profissional responsável pelos dados armazenados, especializado em Projeto de Banco de Dados. 
É de sua responsabilidade o desenvolvimento de relatórios gerenciais e a distribuição da informação 
dentro da empresa em todos os níveis. Interage com os usuários da aplicação a ser desenvolvida, com 
o objetivo de definir os requisitos de dados e especificar o esquema do banco de dados. Deve ser um 
especialista em desenvolvimento de sistemas.
2.1.2 Desenvolvedor de banco de dados
É o profissional responsável pelo desenvolvimento de programas de aplicação dentro do banco de 
dados. Esses programas interagem com o SGBD por meio de comandos de manipulação de dados (DML) 
embutidos no seu código. São desenvolvidos usando a linguagem padrão do banco de dados, como 
Oracle PL-SQL, Microsoft T-SQL, Transact SQL da Sybase, entre outros, e podem ser rotinas que são 
executadas sob outras aplicações ou mesmo em conjunto com elas.
2.1.3 Programador
É o profissional que desenvolve aplicações utilizando ferramentas compatíveis com o 
SGBD. Essas ferramentas podem ser compiladores de linguagens de programação tradicionais 
que permitem a integração de comandos da linguagem da DML no seu código, programas que 
usam alguma linguagem de programação (C#, PHP, VB.NET, DELPHI, JAVA etc.), programação de 
sistemas e aplicativos de manipulação de dados, geradores de interfaces gráficas, geradores de 
relatórios etc.
27
ADMINISTRAÇÃO DE BANCO DE DADOS
2.2 Certificações
Dentro do mercado de tecnologia como um todo, além do tempo de atuação na área e a experiência, 
outra forma de se comprovar o domínio de um profissional sobre uma determinada tecnologia é por 
meio de certificações.
Essas certificações são criadas e mantidas pelos fornecedores das soluções de tecnologia e as provas 
aplicadas e gerenciadas por parceiros globais. A seguir, veremos as certificações mais importantes dentro 
da área de banco de dados.
2.2.1 Certificação Microsoft
• MCTS – Microsoft Certified Technology Specialist (primeiro nível)
• MCITP – Microsoft Certified IT Professional (segundo nível)
 MCM – Microsoft Certified Master (top)
• Divide-se em três caminhos:
– Database Administrator
– Database Developer
– BI Developer
 Saiba mais
Para obter informações sobre as carreiras e certificações da Microsoft, 
recomendamos consultar o site <www.microsoft.com/learning>.
2.2.2 Certificação Oracle
• Oracle Certified Associate (primeiro nível)
• Oracle Certified Professional (segundo nível)
• Oracle Certified Master (terceiro nível)
– Duas provas por nível
– Necessidade de cursos presenciais
28
Unidade I
 Saiba mais
Para informações sobre as certificações nos produtos da Oracle, 
recomendamos consultar o site <education.oracle.com>.
 Observação
Apesar de as provas serem mantidas pelas empresas fornecedoras 
da tecnologia, existe uma agência externa que as aplica. Trata-se da 
Prometric, no site <www.prometric.com>, você encontra informações 
sobre certificações, por exemplo, o preço de cada prova.
 Resumo
Nesta unidade, você aprendeu que um banco de dados é um conjunto 
de registros dispostos em uma estrutura regular, possibilitando sua 
reorganização e a produção de informação.
O surgimento da tecnologia de banco de dados ocorreu no momento 
em que os especialistas no desenvolvimento de sistemas computacionais 
perceberam que, para a informatização de grandes organizações, várias 
questões relacionadas com o gerenciamento de dados necessitavam ser 
resolvidas de forma mais eficiente.
Problemas como redundância, manutenção dos dados, atualizações, 
correções, falta de padronização, segurança, entre outros, com o uso dos 
bancos de dados são resolvidos. Os dados passam a ser armazenados em 
um único local, ao invés de serem arquivados em diversos formatos e 
aplicações locais, sem nenhuma gerência e segurança.
Todo o cuidado com os dados, no que diz respeito ao acesso, à 
integridade, à segurança, concorrência, autorização de uso etc., é 
incumbência de um software de gerenciamento de banco de dados, 
totalmente projetado para isso. Além disso, você pode ter umaideia 
sobre a carreira profissional nessa área e como obter certificação nas 
diferentes plataformas.
Na área de Tecnologia da Informação, existe um profissional que só é 
lembrado nos momentos críticos: o DBA. Sua função maior é assegurar 
que o banco de dados esteja funcionando e acessível todo o tempo que o 
29
ADMINISTRAÇÃO DE BANCO DE DADOS
sistema necessitar, com rapidez e confiabilidade. Ou seja, quando o sistema 
está “redondo”, ninguém se lembra de que existe um DBA que trabalha 
arduamente para isso. Porém, se o banco de dados ficar off-line por alguns 
minutos, você receberá uma dezena de telefonemas de reclamações. Dentre 
as funções administrativas que devem ser executadas em um banco de dados, 
estão backup periódico, verificação de consistência e otimização (tuning).
O profissional que atua como DBA precisa ter grande conhecimento da 
modelagem dos dados, para saber em que implicam as alterações. Esta é 
uma das razões pelas quais o perfil do DBA fica cada vez mais amplo. Sua 
participação na fase de modelagem de dados é muito importante, pois seus 
conhecimentos de performance e otimização em muito contribuem para 
a definição de dados. Outro conhecimento que pode agregar valor a um 
DBA é o de processos administrativos e de negócios, para que ele entenda 
o “porquê” do banco de dados que administra e qual a importância de cada 
tabela, o que pode fazer diferença em uma otimização.
 Exercícios
Questão 1. Ao se pesquisar sobre Bancos de Dados encontram-se diversas definições ou diversos 
conceitos que de alguma forma afirmam que os BDs são coleções de dados que se relacionam de 
forma a criar um sentido dentro de um determinado contexto (empresarial, científico e social). 
São considerados de vital importância para empresas, já que por meio dos Sistemas de Informação 
todos os dados fundamentais são armazenados, relacionados e acessados em todos os níveis da 
corporação. Com os Banco de Dados e os SIs os processos são executados, controlados e as tomadas 
de decisão se dão a partir dos resultados das informações recuperadas e organizadas nos BDs da 
empresa. Desde a década de 1960, eles se tornaram a principal peça dos sistemas de informação. Os 
Bancos de Dados são gerenciados ou operados pelos Sistemas Gerenciadores de Bancos de Dados 
(SGBD), que surgiram na década de 1970 e vêm evoluindo tanto na sua estrutura quanto no seu 
poderio de armazenamento. Os Bancos de Dados são utilizados em todos os tipos de aplicação, 
mas na atualidade suas principais aplicações se dão no controle de operações empresariais e no 
gerenciamento de informações científicas, tais como os Bancos de Dados Geográficos e os Banco 
de Dados Sociais.
Considerando os conceitos sobre Banco de Dados, examine as afirmações a seguir e indique a 
alternativa incorreta:
A) O projeto de dados é considerado a parte estática de um sistema de informação e as funcionalidades 
são consideradas como a parte dinâmica do SI.
B) Dentro de um ciclo de desenvolvimento de um SI, logo no início do ciclo, são determinados os 
requisitos do sistema ou aplicação; nessa etapa são coletadas informações sobre os dados de 
interesse da aplicação, fundamentais para um bom projeto de Banco de Dados.
30
Unidade I
C) O Modelo Relacional proposto por Edgar Frank Codd se tornou um marco em como pensar em 
banco de dados, já que a estrutura lógica do banco de dados organiza os dados muito próximos 
do armazenamento físico dos discos magnéticos, trazendo grandes vantagens sobre os outros 
modelos com relação ao espaço de armazenamento e ao tempo de acesso.
D) Pode-se afirmar que na atualidade não seria possível construir aplicações multiusuárias sem o 
uso de Banco de Dados e dos Sistemas Gerenciadores de Bancos de Dados (SGBDs).
E) Como os Bancos de Dados, na atualidade, são utilizados para armazenar todos os tipos de 
informações, que vão de pessoas até empresariais, a segurança do BD se tornou crítica e exige do 
gerenciador do banco de dados mecanismos que garantam a integridade, a disponibilidade e a 
confidencialidade das informações armazenadas.
Resposta correta: alternativa C.
Análise das alternativas
A modelagem de banco de dados relacional de Codd tornou-se um marco na tecnologia de BD 
devido à desconexão da estrutura lógica do banco de dados com os métodos de armazenamento físico 
vigente na década de 1970. Toda a modelagem do Banco de Dados está associada à teoria matemática 
das relações ou conjuntos, o que traz a organização dos dados de uma aplicação para mais próximo 
do pensamento humano. Os dados passam a ser vistos como conjuntos matemáticos que podem ser 
manipulados pela teoria das relações.
A) Alternativa correta. 
Justificativa: os dados em um sistema de informação representam as propriedades de uma determinada 
entidade que devem ser persistidas durante o tempo e garantidas quanto à suas integridades. Devido 
a essa propriedade eles são considerados como a parte estática do sistema de informação. Os dados 
de um cliente de uma empresa em um sistema de compras tem que ser armazenados e garantidos ao 
longo de todas as suas operações realizadas nos SIs da empresa. Os dados ou características básicas 
desse cliente (nome, CPF, telefone, endereço, RG etc.) raramente são alteradas, mas os dados de suas 
operações comerciais são constantemente modificadas.
B) Alternativa correta. 
Justificativa: os requisitos de um sistema determinam o escopo a ser desenvolvido, isto é, o conjunto 
de necessidades dos clientes ou usuários que utilizarão o sistema em suas tarefas do dia-a-dia. Por 
meio de reuniões, entrevistas, documentos existentes dos processos organizacionais são determinadas 
as funcionalidades, a usabilidade e os dados necessários para a execução das tarefas operacionais 
envolvidas no sistema.
C) Alternativa incorreta. 
31
ADMINISTRAÇÃO DE BANCO DE DADOS
Justificativa: o Modelo Relacional foi proposto por Edgar Frank Codd e se tornou um marco em como 
pensar em banco de dados porque Codd desconectou a estrutura lógica do banco de dados do método 
de armazenamento físico, organizando os dados em um conjunto de relações denominadas de tabelas.
D) Alternativa correta. 
Justificativa: aplicações multiusuárias são complexas, já que diversas operações podem ser realizadas e 
que manipulam coleções de dados operacionais inter-relacionados. Esses dados devem ser corretamente 
armazenados, relacionados e garantidos quanto às suas integridades, exigindo um grande esforço de 
programação dos dispositivos de armazenamento. Dessa forma, o uso de estruturas de Banco de Dados 
e dos monitores de BDs (SGBDs) é fundamental no sucesso dos sistemas de informação.
E) Alternativa correta. 
Justificativa: existem diversos mecanismos dos gerenciadores de banco de dados para suporte às 
aplicações na guarda e manuseio dos dados existentes nos Banco de Dados. Como diversas aplicações 
acessam e manipulam os mesmos dados durante suas tarefas, se torna fundamental que o SGBSs 
garantam a integridade, a disponibilidade e a confidencialidade dos dados contidos em seus arquivos.
Questão 2. Como todo sistema de computador, um sistema de gerenciamento de banco de dados 
(SGBD) é um conjunto de componentes de software que permitem armazenar, modificar e extrair 
informações de um Banco de Dados. Atualmente existem muitos tipos diferentes de SGBDs, desde 
os considerados pequenos sistemas que funcionam em computadores pessoais, celulares, tablets até 
sistemas extremamente grandes que residem em grandes computadores das grandes organizações ou 
em servidores (plataforma baixa) ou nas máquinas denominadas de mainframes (ou plataforma alta). 
Para a execução de todas as atividades envolvidas em um SGBD existem basicamente três componentes: 
a) a linguagem de definição de dados que especifica os conteúdos, a estrutura da base de dados e define 
os elementos de dados; b) a linguagem de manipulação de dados para obter e alterar os dados no banco 
de dados; c) um dicionário de dados onde estão as definições de elementosde dados e respectivas 
características que descreve os dados, quem os acede etc. Apesar de todos esses recursos, os SGBDs não 
se autoadministram e exigem profissionais especializados para sua administração e controle.
Considerando os conceitos sobre os SGBDs, examine as afirmações a seguir e indique a alternativa incorreta:
A) Os SGBDs modernos são projetados e construídos com muitos recursos internos que praticamente 
eliminam a necessidade de uma organização possuir uma estrutura de pessoas especializadas 
para sua organização e administração.
B) O backup dos bancos de dados de uma empresa precisa ser bem planejado já que diversos aspectos 
operacionais devem ser considerados nesta atividade: Quando efetuar um backup total ou como 
se fazer backups parciais sem perder a integridade dos dados? Que aplicações podem, ou não 
ser executadas nos momentos de backups dos bancos de dados? Outras considerações também 
podem ser necessárias.
32
Unidade I
C) O mercado preocupa-se muito com os profissionais que manipulam os Sistemas de Banco 
de Dados nas empresas e as certificações profissionais são uma forma de comprovação do 
conhecimento de pessoas em uma determinada tecnologia. Isso acontece com os profissionais 
denominados de DBAs.
D) Diversos autores afirmam que a utilização de um SGBD traz enormes vantagens que podem 
ser resumidas em: controle da redundância, restrição a acessos não autorizados, permitir um 
armazenamento persistente para os objetos dos programas e estruturas de dados, permitir a 
inferência em ações seguindo regras, permitir múltiplas interfaces para os utilizadores, permite 
representar relacionamentos complexos entre os dados, reforçar as restrições de integridade e a 
recuperação de dados em caso de pane.
E) Um modelo de banco de dados para ser considerado relacional deve seguir as denominadas “Doze 
regras” de Codd, que foram criadas para impedir que os fornecedores de banco de dados não 
utilizassem somente o nome relacional, mas que seus produtos implementassem a teoria das 
relações matemáticas do modelo.
Resolução desta questão na plataforma.
33
ADMINISTRAÇÃO DE BANCO DE DADOS
Unidade II
3 DIAGRAMA ENTIDADE-RELACIONAMENTO (E-R)
O diagrama E-R é uma ferramenta para modelagem conceitual de banco de dados amplamente 
utilizada no projeto de banco de dados, sendo considerada praticamente um padrão para modelagem 
conceitual. É aconselhado como padrão por ser de fácil compreensão e apresenta poucos conceitos.
Um diagrama E-R é uma representação gráfica, na forma de um diagrama, no qual são utilizados 
apenas três conceitos: entidades, relacionamentos e atributos, que serão descritos a seguir.
3.1 Entidades do DER
Representam categorias de fatos do mundo real, sejam eles concretos ou abstratos, como empregados, 
departamentos, despesas etc. São representados por retângulos nomeados por substantivos, que indicam 
um conjunto de ocorrências da entidade. Sugerem-se nomes no plural.
3.2 Relacionamentos do DER
Representam associações entre entidades, sendo que, em cada associação, são indicadas as 
cardinalidades, ou seja, o número de ocorrências de uma entidade que se relaciona com uma ocorrência 
de outra entidade.
Por exemplo, como representado na Figura 9.
Empregados Departamentos
(1, N) (1, 1)
Figura 9 – cardinalidade de um relacionamento
• Indica que 1 empregado trabalha no mínimo em 1 departamento e no máximo em 1 departamento.
• Indica que em 1 departamento trabalha no mínimo 1 empregado e no máximo N empregados.
3.2.1 Relacionamentos binários
Representam uma associação entre duas entidades, representada por um losango nomeado com 
linhas para as duas entidades envolvidas. Um relacionamento indica uma função cumprida pelas duas 
entidades envolvidas. Sugere-se que esse nome seja um substantivo no plural, uma vez que o uso de 
verbos limita mais a criatividade para a determinação de nomes.
34
Unidade II
Quando se define um relacionamento, deve-se definir também a cardinalidade dessa associação, 
por meio de dois pares de valores, no qual o valor da esquerda indica o número mínimo esperado 
de ocorrências de uma entidade que se relaciona com a entidade questionada, e o valor da direita 
o número máximo. Esses valores de máximo e mínimo podem ser constantes, quando se souber 
exatamente esses valores.
3.2.2 Relacionamentos reflexivos
É um tipo de associação que envolve ocorrências de uma mesma entidade (parte e chega da 
mesma entidade). Nesse caso, recomenda-se a indicação explícita do papel assumido por cada lado da 
associação, para tornar mais clara a interpretação do relacionamento. Por exemplo, em uma relação de 
chefia entre um empregado e outro, é interessante a indicação dos papéis de superior e subordinado.
Alguns controles de integridade, não expressos no diagrama E-R, podem ser necessários, como a 
proibição de um empregado ser chefiado por ele mesmo (valores iguais no relacionamento) ou uma 
hierarquia de gerência com ciclos. É interessante que esses controles, se desejados, sejam explicitamente 
comentados como um anexo ao diagrama E-R.
3.2.3 Relacionamentos ternários
Relacionam três ocorrências de entidades. Só é interessante utilizar esse tipo de relacionamento 
quando realmente é obrigatório associar, ao mesmo tempo, um par de entidades com uma terceira. Por 
exemplo, um empregado que trabalha num projeto necessariamente realiza alguma tarefa nesse trabalho. 
Esses três fatos estão sempre relacionados. Quando não ocorre essa obrigatoriedade, recomenda-se o 
uso da agregação.
A determinação da cardinalidade de um relacionamento ternário é feita questionando um par em 
relação à terceira entidade envolvida. Por exemplo, um empregado trabalhando em um projeto temos 
o par empregado-projeto que realiza de 1 a N tarefas. Logo, a cardinalidade (1,N) é colocada ao lado da 
entidade TAREFAS.
Outros relacionamentos acima de ternários podem ocorrer em um diagrama E-R, porém são raros 
e deve-se avaliar cuidadosamente se serão necessários. A determinação da cardinalidade é semelhante 
ao comentado para ternários, ou seja, questiona-se um conjunto de entidades associadas em relação 
àquela que se deseja determinar a cardinalidade.
3.3 Atributos do DER
Representam uma propriedade de uma entidade ou de um relacionamento, como salário de um 
empregado ou o tempo que um empregado estará alocado em um projeto.
São representados por círculos nomeados, ligados por linhas a uma entidade ou relacionamento. 
Atributos identificadores de entidades, ou que sejam necessários na identificação de relacionamentos, 
são indicados por um círculo preenchido ou pelo nome sublinhado.
35
ADMINISTRAÇÃO DE BANCO DE DADOS
3.3.1 Atributos opcionais
Atributos com propriedades que podem assumir NULL. São indicados por um traço que corta a linha que liga 
o atributo à entidade ou relacionamento.
3.3.2 Atributos compostos
Representam uma abstração de outros atributos, como um endereço que abstrai (agrega) outros 
dados como rua, CEP, cidade etc. É representado por uma eclipse, com ligações (linhas) para os atributos 
componentes (convencionais).
3.3.3 Atributos multivalorados
Atributos com propriedades que podem assumir mais de um valor, como os números de telefone de 
um departamento. São representados por uma cardinalidade mínima e máxima que é colocada ao lado 
do nome do atributo, indicando as quantidades de valores mínimos e máximos permitidos.
3.4 Entidades fracas
Entidades cujas existências dependem da existência de outra entidade, dita fork. É representada 
por um retângulo duplo, podendo, opcionalmente, ser indicada uma seta que parte dela e chega à sua 
entidade forte, para tornar mais clara a dependência.
A cardinalidade de uma ocorrência de uma entidade fraca com a forte é sempre (1,1), indicando que 
ela sempre depende de uma ocorrência da entidade forte.
3.5 Especialização
Salienta que algumas ocorrências de uma entidade assumem papéis específicos, ou seja, são 
especializações, como o fato de um empregado ser um motorista ousecretário, inclusive com a 
possibilidade de terem atributos específicos. São classificadas em dois tipos, descritos a seguir.
3.5.1 Especialização com ou sem exclusão mútua
Indica se uma ocorrência de uma entidade genérica pode assumir apenas uma ou várias 
especializações, respectivamente.
No primeiro caso, representa-se por meio de um único triângulo que recebe uma linha da entidade 
genérica, sendo que da sua base partem linhas para várias entidades especializadas, dando a ideia de 
uma escolha que deve ser feita.
No segundo caso, desenha-se um triângulo para cada ligação entre a entidade genérica e uma especialização.
36
Unidade II
3.5.2 Especialização com ou sem obrigatoriedade
Indica se uma especialização é obrigatória ou não. Em caso negativo, diz-se que a especialização é 
parcial. A parcialidade é indicada pelo uso da letra P colocada ao lado do triângulo.
3.6 Agregação
Um agregado representa uma porção de um diagrama E-R que envolve um relacionamento entre 
várias entidades. É utilizado para indicar situações em que entidades relacionadas podem ainda se 
relacionar com outras entidades. Essas entidades relacionadas são consideradas uma entidade de alto 
nível, chamada agregado, e são recomendadas para representar situações em que existe parcialidade na 
relação entre três ou mais ocorrências de entidade. Por exemplo, uma pessoa que tem a posse de um 
automóvel e que pode ou não ter contratado seguro para o carro. Um agregado possível é representado 
pelo conjunto de pessoas que tem automóvel com seguro.
Uma agregação é representada por um polígono fechado que envolve as entidades e o relacionamento 
entre elas, determinando a entidade agregada. Essa entidade agregada é considerada, então, uma 
entidade normal do diagrama E-R, que pode se relacionar com outras entidades.
4 MODELO ENTIDADE RELACIONAMENTO (MER)
É um modelo abstrato desenvolvido pelo Prof. Peter Chen, a fim de representar as estruturas de 
dados de forma mais natural e mais próxima do mundo real dos negócios. Seus aspectos estruturais 
formalizam matematicamente a maneira como os dados estão organizados no modelo relacional. A 
seguir, serão descritos os conceitos básicos de um modelo relacional.
É composto por entidades, que são caracterizadas por atributos e que se relacionam entre si. Dentro 
do MER, utilizamos algumas formas geométricas para a representação das entidades, seus atributos e 
seus relacionamentos, conforme apresentados a seguir.
Pessoa
Retângulos representam as entidades
TEL
Elipses representam os atributos de uma entidade
37
ADMINISTRAÇÃO DE BANCO DE DADOS
Possui
Losangos representam as relações entre as entidades
Figura 10
4.1 Domínio
O domínio define o universo de valores permitidos para certo item de dado. Por exemplo, o domínio 
para o item de dado salário pode ser o conjunto dos números reais; o domínio do item de dado idade 
pode ser o conjunto dos números inteiros no intervalo [0,150]; o domínio do item sexo pode ser o 
conjunto limitado (masculino, feminino).
Um domínio compreende um tipo de dado predefinido mais um conjunto de restrições de integridade 
que limitam os valores permitidos para esse tipo de dado.
Domínios podem ser simples, ou seja, possuem um único valor, como um inteiro ou compostos, 
quando possuem vários valores, como uma data. Os valores dos itens de dados que apresentam domínios 
compostos são abstraídos e tratados como um único valor. Uma data poderia ser manipulada como uma 
string, por exemplo.
 Observação
A noção de domínio de um item de dados assemelha-se à noção de 
domínio de um conjunto na matemática.
 Lembrete
MER é o modelo teórico inventado para transportar estruturas 
existentes no mundo real para o banco de dados. DER é a representação 
gráfica do MER.
4.2 Atributo do MER
Um atributo é um nome dado a um domínio utilizado para representar um item de dado. 
Matematicamente falando, um atributo é o nome de um conjunto.
38
Unidade II
Em uma tabela, representa uma coluna. Um atributo pode apresentar um valor condizente com o 
domínio associado a ele ou NULL, que indica a ausência de valor ou valor desconhecido.
Um atributo pode conter apenas um valor atômico, ou seja, um valor indivisível.
4.3 Tupla
É um conjunto de pares (atributo – valor) que define uma linha da tabela, ou seja, uma ocorrência 
de uma entidade ou relacionamento. Se imaginarmos em uma tabela como sendo um conjunto, uma 
tupla seria um elemento desse conjunto.
4.4 Relação
Pode ser definida como um subconjunto do produto cartesiano dos domínios (d1, d2, d3,...., dn) que 
correspondem aos atributos (a1, a2, a3,..,an) de uma tabela. O produto cartesiano gera (d1 x d2 x d3 x....x 
dn) tuplas e a relação mantém apenas aquelas tuplas que contêm valores de atributos relacionados que 
estão presentes na realidade.
Uma relação, portanto, é um subconjunto. É vista como uma tabela no modelo relacional, composta 
por um cabeçalho e um corpo. O cabeçalho é formado por um conjunto fixo de atributos que possuem 
nomes distintos, para evitar ambiguidade na localização de um item de dado. O grau de uma relação 
significa o número de atributos da mesma.
O corpo de uma relação é formado por um número variável de tuplas, em que a ordem das mesmas 
não é significativa, ou seja, dada uma relação R1 com três tuplas, nesta ordem: t1, t2 e t3, e uma relação 
R2 com três tuplas nesta ordem: t2, t3 e t1, teremos R1 igual a R2. A cardinalidade de uma relação 
significa o número de tuplas da relação.
O conceito de relação é ligeiramente diferente do conceito de tabela. Relação equivale à noção de 
conjunto, ou seja, um agrupamento de elementos sem repetição. Tabela equivale à noção de coleção, 
ou seja, um agrupamento de elementos em que é permitida a repetição. Os Sistemas Gerenciadores de 
Banco de Dados, na prática, lidam com o conceito de tabela.
4.5 Chave
O conceito de chave é fundamental no modelo para garantir a identificação de tuplas e estabelecer 
relacionamentos entre relações.
4.5.1 Chave primária (PK) – primary key
Atributo ou grupo de atributos que permite a identificação única de uma tupla em uma 
relação, ou seja, o valor da PK (primary key) de uma tupla nunca se repetirá nas demais tuplas 
da mesma relação.
39
ADMINISTRAÇÃO DE BANCO DE DADOS
Uma PK é escolhida dentre várias chaves candidatas, que podem estar presentes na relação. As 
chaves candidatas não selecionadas são ditas chaves alternativas. A cada chave alternativa deve ser 
associada uma Relação de Integridade (RI) que garanta que seus valores sejam únicos.
 Observação
Quando a chave primária tem um atributo, dizemos que é uma chave 
primária simples, e, quando ela tem dois ou mais atributos, dizemos que é 
uma chave primária composta.
Utilizamos uma chave primária simples para armazenar o ESTADO (UF) porque eles são únicos.
UF
PK SIGLA UF
NOME_UF
Figura 11 – Exemplo de chave primária simples
Utilizamos uma chave composta para CIDADE porque posso ter mais de uma cidade com o mesmo 
nome, por isso temos que associar o nome da cidade com o Estado ao qual ela pertence, para poder 
garantir a unicidade da tupla.
Cidade
PK UFCIDADE_NOME
Figura 12 – Exemplo de chave primária composta
4.5.2 Chave estrangeira (FK) – foreign key
Atributo ou grupo de atributos de uma relação R1 que estabelece um relacionamento de equivalência, 
por valor, com uma PK (primary key) de uma relação R2.
O domínio da FK (foreign key) de R1 deve ser compatível com o domínio da PK (primary key) de R2. 
Nada impede que R1 e R2 sejam a mesma relação.
4.5.3 Chave artificial ou delegada (SK) – surrogate key
Serve para substituir a chave original da tabela. Normalmente composta de números sequenciais, é 
muito utilizada em Modelos Multidimensionais, em que o processo de dimensionamento associa a chave 
natural do modelo relacional, que vão ser apenas atributos da dimensão, e para garantir a unicidade é 
criada a chave delegada (surrogate key).
40
Unidade II
 Saiba mais
Para aprofundar os estudos sobre o ModeloMultidimensional, 
recomendamos a leitura dos livros de Ralph Kimball. E não deixe de visitar 
frequentemente este site: <www.kimballgroup.com>, se quiser entrar na 
área de Inteligência Corporativa e aprender mais sobre a tecnologia de 
Datawarehouse.
4.6 Restrições de integridades básicas
Os aspectos de integridade do modelo relacional estão associados aos conceitos de chave primária 
e chave estrangeira. Garantir a integridade de um esquema relacional significa assegurar o acesso 
individualizado a todas as tuplas de uma relação, assim como relacionamentos válidos e condizentes 
com a realidade.
O modelo relacional é regido por duas regras de integridade básicas: a de integridade de entidade e 
a de entidade referencial, descritas a seguir.
4.6.1 Regra de integridade de entidade
Diz respeito à chave primária de uma relação. Ela diz que nenhum atributo que faz parte da chave 
primária pode ter NULL em alguma tupla. A manutenção dessa regra garante que toda tupla possa ser 
identificada unicamente.
4.6.2 Regra de integridade referencial
Diz respeito às chaves estrangeiras de uma relação. Ela diz que o valor de um atributo que faz parte 
de uma chave estrangeira pode assumir NULL desde que o mesmo não faça parte da chave primária. 
Ainda, esse mesmo atributo pode assumir um valor qualquer, condizente com o seu domínio, desde que 
esse mesmo valor exista na chave primária de uma tupla da relação referida por ele. Com isso, nunca 
existirão relacionamentos incorretos entre dados.
Para que essas regras sejam sempre respeitadas, o SGBD deve implementar rotinas de verificações 
automáticas. Isso implica testes e ações a serem realizados pelo SGBD toda vez que uma operação de 
atualização for submetida ao mesmo.
No caso da regra de integridade de entidade, o seguinte algoritmo deve ser executado toda vez que 
for incluída uma nova tupla em uma relação ou for alterado um valor de um atributo de uma tupla que 
faz parte da chave primária de uma relação:
SE a chave primária da tupla for NULL
41
ADMINISTRAÇÃO DE BANCO DE DADOS
OU existir tupla com o mesmo valor da chave primária
ENTÃO impedir a efetivação da operação
SENÃO efetivar a operação
Já para o caso da regra de integridade referencial, três alternativas de ações são geralmente tomadas 
pelo SGBD quando se percebe que uma violação irá ocorrer:
• Impedimento a operação não é efetivada.
• Cascata para o caso de exclusões de tuplas ou alterações de chave primária na relação referida, 
realizar a mesma operação em todas as tuplas que se referem a ela.
• Anulação para o caso de exclusões de tuplas ou alterações de chave primária na relação 
referida, altera-se para NULL o(s) atributo(s) que compõe(m) a chave estrangeira que estabelece 
o relacionamento com essa relação. Uma variante dessa alternativa é anular apenas a chave 
estrangeira de uma única tupla.
A aplicação dessas ações depende da operação de atualização submetida e da relação que sofre a 
operação (a referida ou a que possui uma referência). Se uma operação de atualização é submetida à 
relação que possui a referência (possui a chave estrangeira), o seguinte algoritmo deve ser executado 
toda vez que for incluída uma nova tupla ou for alterado o valor de um atributo que faz parte da chave 
estrangeira:
SE a chave estrangeira da tupla for NULL
 ENTÃO
 SE a chave estrangeira fizer parte da chave primária
 ENTÃO impedir a efetivação da operação
 SENÃO efetivar a operação
SENÃO SE não existir uma tupla na relação referida com valor de chave primária igual ao valor 
da chave estrangeira desta tupla
 ENTÃO SE a chave estrangeira fizer parte da chave primária
 ENTÃO aplicar impedimento
 SENÃO aplicar impedimento
 OU aplicar anulação
SENÃO efetivar a operação
42
Unidade II
Se uma operação de atualização é submetida à relação referida (possui a chave primária), o seguinte 
algoritmo deve ser executado toda vez que for excluída uma tupla ou for alterado o valor de um 
atributo que faz parte da chave primária:
SE a chave estrangeira fizer parte da chave primária
ENTÃO aplicar impedimento
 OU aplicar cascata
SENÃO aplicar impedimento
 OU aplicar cascata
 OU aplicar anulação
 Lembrete
Entidades, do original entity type, servem para representar objetos, 
coisas, pessoas que existem na realidade. No MER, os relacionamentos são 
identificados com um verbo, conforme pode ser observado na figura 13.
Uma pessoa possui um automóvel.
PossuiPessoa Automóvel
1 1
1 1
Um automóvel pertence a uma pessoa.
Figura 13 – Exemplo de um relacionamento 1:1
Dentro de um modelo relacional, temos que ver como as entidades se relacionam entre si, ou seja, 
ver como a entidade Pessoa se relaciona com a entidade Automóvel e como a entidade Automóvel se 
relaciona com a entidade Pessoa, e podemos concluir que:
43
ADMINISTRAÇÃO DE BANCO DE DADOS
Uma pessoa possui vários automóveis.
PossuiPessoa Automóvel
1 N
1 1
Vários automóveis pertencem a uma pessoa.
Figura 14 – Exemplo de relacionamento 1:N
Aqui fazemos os mesmos passos para a obtenção da cardinalidade, verificamos o relacionamento de 
Pessoa com Automóvel e de Automóvel com Pessoa.
• 1 Pessoa possui N (vários) automóveis.
• 1 Automóvel que pertence a 1 Pessoa.
Um aluno possui vários professores.
PossuiAluno Professor
1 N
N 1
Um professor possui vários alunos.
Figura 15 – Exemplo de relacionamento N:N
No exemplo da Figura 15, temos a seguinte definição: 1 aluno possui N (vários) professores e 1 
professor possui N (vários) alunos.
Para obter a cardinalidade final, devemos usar a multiplicação. Em cada um dos lados, pegamos os 
dois números, que estão em destaque ao lado da entidade. Nesse caso, em aluno temos 1 e N, 1 x N = 
N (qualquer número multiplicado por 1 é ele mesmo). Já em professor, temos N e 1. N x 1 = N. Assim, 
obtemos um relacionamento de N para N.
4.7 Tipos de relacionamento
Quando fazemos o relacionamento entre duas ou mais tabelas, esse relacionamento pode ser 
classificado de duas formas:
44
Unidade II
Identificado: também conhecido como relacionamento forte. Identifica que a chave estrangeira da 
tabela “pai” faz parte da chave da tabela “filha”.
Não identificado: também conhecido como relacionamento fraco. Identifica que a chave estrangeira 
da tabela “pai” não faz parte da chave primária da tabela filha, sendo esse apenas mais um atributo.
A seguir, mostramos a representação desses tipos de relacionamento, com exemplos, nas figuras 16 
e 17.
UF Cidade
PK UF-SIGLA PKPK, FK1
CID_NOME
UF-SIGLA
UF_NOME
Figura 16 – Exemplo de relacionamento forte
Cor Carro Motor
PK COR PK CHASSI PK MOTOR
COR_NOME FK1
FK2
MODELO
COR
MOTOR
MOTOR_NOME
Figura 17 – Exemplo de relacionamento fraco
4.8 Normalização
Normalização de dados é o processo formal passo a passo que examina os atributos de uma entidade, 
com o objetivo de evitar redundâncias e anomalias observadas na inclusão, na exclusão e na alteração 
de registros.
4.8.1 Primeira Forma Normal (1FN)
Uma relação estará na Primeira Forma Normal 1FN se, e somente se, todos os domínios básicos 
contiverem somente valores atômicos (não contiver grupos repetitivos).
Procedimentos:
• identificar a chave primária da entidade;
• identificar o grupo repetitivo e removê-lo da entidade;
• criar uma nova entidade com a chave primária da entidade anterior e o grupo repetitivo;
• a chave primária da nova entidade será obtida pela concatenação da chave primária da entidade 
inicial e a do grupo repetitivo.
45
ADMINISTRAÇÃO DE BANCO DE DADOS
Exemplo:
ID Nome Telefone Endereço 
1 João (11)1234-5678(11)2345-6789 
Rua Seis, 85
Morumbi
12536-965 
2 Maria (11)3456-7890(11)4567-8901 
Rua Onze, 64
Moema
65985-963 
3 José (11)5678-9012(11)6789-0123 
Praça Ramos
Liberdade
68858-456 
Figura 18
Aqui temos os mesmos grupos de dados agrupados para todas as linhas.
ID Nome Telefone Rua Bairro CEP 
1 João (11)1234-5678(11)2345-6789 Rua Seis, 85 Morumbi 12536-9652 Maria (11)3456-7890(11)4567-8901 Rua Onze, 64 Moema 65985-963 
3 José 
(11)5678-9012
(11)6789-0123
(11)7890-1234 
Praça Ramos Liberdade 68858-456 
Figura 19
Foi resolvido o problema do endereço, quebrando a informação em três colunas; porém, ainda 
persiste o problema da coluna telefone e, diferente da anterior, não tem a mesma repetição do outro 
grupo.
Para resolvermos esse caso, teremos que quebrar essa tabela em duas.
ID Nome Rua Bairro CEP 
1 João Rua Seis, 85 Morumbi 12536-965 
2 Maria Rua Onze, 64 Moema 65985-963 
3 José Praça Ramos Liberdade 68858-456 
Figura 20
A primeira, sem a informação de telefone.
Telefone ID
(11)1234-5678 1 
(11)2345-6789 1 
(11)3456-7890 2 
(11)4567-8901 2 
(11)5678-9012 3 
46
Unidade II
Telefone ID
(11)6789-0123 3 
(11)7890-1234 3 
Figura 21
A segunda, apenas com a informação de telefone, associada com a primeira pelo código do cliente.
4.8.2 Segunda Forma Normal (2FN)
Uma relação estará na Segunda Forma Normal 2FN se já estiver na 1FN e não existir nenhum atributo 
que não seja dependente de todo da chave da tabela.
Procedimentos:
• identificar os atributos que não são funcionalmente dependentes de toda a chave primária;
• remover da entidade todos esses atributos identificados e criar uma nova entidade com eles.
Exemplo:
C_Produto N_Produto Qtd Vl_Unitário Subtotal 
1 1234 Impressora Matricial 4 100,00 400,00 
2 2345 Impressora Jato de Tinta 3 200,00 600,00 
3 3456 Impressora Laser 2 1000,00 2000,00 
4 5678 Impressora Multifuncional 1 350,00 350,00 
Figura 22
Não está na Segunda Forma Normal porque temos atributos que não dependem da chave primária.
N_Pedido C_Produto Qtd Vl_Unitário Subtotal 
1 1234 4 100,00 400,00 
2 2345 3 200,00 600,00 
3 3456 2 1000,00 2000,00 
4 5678 1 350,00 350,00 
Figura 23
Para resolver, separamos a informação em duas tabelas.
47
ADMINISTRAÇÃO DE BANCO DE DADOS
C_Produto N_Produto 
1234 Impressora Matricial 
2345 Impressora Jato de Tinta 
3456 Impressora Laser
5678 Impressora Multifuncional 
Figura 24
Da tabela de pedidos, foi retirada a descrição do produto, porque o atributo é dependente apenas do 
código do produto. Foi criada uma nova tabela chamada de Produto, composta por Código do Produto 
e Nome do Produto. Foi mantido o Código do Produto na tabela de Pedido para o relacionamento.
4.8.3 Terceira Forma Normal (3FN)
Uma tabela está na Terceira Forma Normal 3FN se estiver na 2FN e se nenhuma coluna não chave 
depender de outra coluna não chave.
Procedimentos:
• identificar todos os atributos que são funcionalmente dependentes de outros atributos não chave 
e removê-los;
• a chave primária da nova entidade será o atributo do qual os atributos removidos são 
funcionalmente dependentes.
N_Pedido C_Produto Qtd Vl_Unitário Subtotal 
1 1234 4 100,00 400,00 
2 2345 3 200,00 600,00 
3 3456 2 1000,00 2000,00 
4 5678 1 350,00 350,00 
Figura 25
Ainda existe um atributo que está relacionado a outro atributo não chave.
O atributo SUBTOTAL é derivado do cálculo da quantidade que multiplica o valor unitário.
N_Pedido C_Produto Qtd Vl_Unitário 
1 1234 4 100,00 
2 2345 3 200,00 
3 3456 2 1000,00 
4 5678 1 350,00 
Figura 26
48
Unidade II
Nesse caso, removemos a coluna, já que, entre outras coisas, ela era derivada de um cálculo.
 Saiba mais
Na internet, existe muita informação sobre o fascinante mundo do DBA. 
Para começar a navegar nesse mundo, sugerimos alguns sites. Boa viagem!
<http://certificacaobd.com.br>
<http://silasmendes.com/dba>
<http://www.mcdbabrasil.com.br>
<http://www.sybase.com/resources/blogs>
<http://dbaforums.org/oracle>
 Resumo
Nesta unidade, apresentamos o modelo relacional, que foi formalmente 
definido por E. Codd, no laboratório da IBM em San José, na Califórnia, em 
1970. O projeto inicial foi denominado de Sistema R e definia a organização 
dos dados e linguagem e linguagens formais para a sua manipulação. Com 
base nessas linguagens formais, a primeira versão da linguagem SQL foi 
definida. Essa linguagem é, atualmente, um padrão para gerenciamento de 
dados em um SGBD relacional.
Entidades e relacionamentos são representados nesse modelo por 
relações que equivalem ao conceito matemático de conjunto, ou seja, um 
agrupamento de elementos sem repetição.
Uma relação é vista como uma tabela, em que as colunas indicam os 
campos e as linhas, as ocorrências (valores). Relacionamentos entre relações 
são estabelecidos por igualdade de valor de campos. Relacionamentos M:N 
são modelados como relações que mantêm os campos que identificam as 
duas relações envolvidas mais os dados pertinentes ao relacionamento, 
caso existam.
Uma das vantagens em adotar o modelo relacional é a representação 
uniforme das entidades e dos relacionamentos. É um conceito único e 
simples para a organização de dados. Um esquema no modelo relacional 
é dito um esquema do mais alto nível, pois abstrai uma estrutura de 
49
ADMINISTRAÇÃO DE BANCO DE DADOS
implementação, como estruturas em árvore ou grafos, em que o usuário 
deve se preocupar em percorrer apontadores adequadamente.
O modelo relacional é o primeiro modelo de dados que oferece 
linguagens de manipulação de dados cujos comandos podem ser 
executados independentes da aplicação, pois não estão obrigatoriamente 
vinculados ao código da aplicação. São, ainda, linguagens de alto nível, ou 
seja, um pequeno comando de manipulação equivale a um procedimento 
de acesso a dados, se comparado com os modelos anteriores. Linguagens 
com essa característica são ditas declarativas, ou seja, o usuário 
preocupa-se em dizer o que eles desejam obter do banco de dados e não 
como ele deseja obter.
A normalização é uma metodologia para projeto de banco de dados 
relacionais, uma vez que sugere uma organização de dados em tabelas. Assim 
sendo, a normalização é uma ferramenta para projeto lógico de banco de 
dados relacionais. O objetivo dessa técnica é evitar problemas de redundância 
e anomalias de atualização, que podem estar presentes em uma relação. A 
solução para resolver esses problemas é a decomposição de uma relação em 
uma ou mais relações, com base na aplicação de certas regras de normalização 
(formas normais). Essa proliferação de relações nem sempre é ideal do ponto 
de vista de performance, devendo ser balanceadas vantagens e desvantagens 
antes da efetivação dos resultados de uma forma normal.
 Exercícios
Questão 1. Um banco de dados é um componente fundamental para o êxito dos sistemas de 
informação (SI) na atualidade. Todavia, para ter um banco de dados consistente, torna-se necessário o 
projeto do banco de dados, que é uma atividade essencial na fase de implementação de um SI. Projetar 
bancos de dados tem se tornado uma atividade importante e que exige profissionais especializados, 
principalmente quando os sistemas manipulam grandes quantidades de dados. Frequentemente, quando 
não há uma abordagem adequada para o projeto de um banco de dados pode-se incorrer em resultados 
indesejáveis e até em grandes prejuízos financeiros para as empresas. Os autores indicam que a ausência 
de um projeto do banco de dados acarreta em uma falta de clareza para entender a natureza exata dos 
dados em um nível conceitual (abstrato). As atividades do projeto de um banco de dados incluem: o 
projeto conceitual; o projeto lógico e o projeto físico. 
Considerando os conceitos sobre Banco de Dados e Projetos de Banco de Dados, examine as 
afirmações a seguir e indique a alternativa incorreta:
A) O projeto conceitual de um banco de dados é uma atividade do projeto de banco de dados que 
usa como base a especificação dos requisitos de um projeto de SI, produzindo como resultado o 
esquema conceitual do banco de dados. 
50
Unidade II
B) Um esquema conceitual é uma descrição em alto nível da estrutura do banco de dados, independente 
do Sistema de Gerenciamento de Banco de Dados (SGBD) adotado para implementá-lo. 
C) O propósito do projeto conceitual de um banco de dados é descrever o conteúdo de informaçãodobanco de dados ao invés das estruturas de armazenamento que serão necessárias paragerenciar 
essa informação.
D) O projeto lógico de um banco de dados tem por objetivo avaliar o esquema conceitual frente 
às necessidades de uso do banco de dados pelos usuários e/ou aplicações, realizando possíveis 
refinamentos para alcançar maior desempenho das operações sobre o banco de dados.
E) O projeto físico de um banco de dados não toma como base o projeto lógico para construir o 
esquema físico do banco de dados. 
Resposta correta: alternativa E.
Análise das alternativas
De acordo com a teoria de projeto de banco de dados, as atividades de projeto de BD envolvem em 
ordem sequencial: o projeto conceitual, o projeto lógico e o projeto físico do banco de dados. Dessa 
forma, o projeto físico utiliza o esquema lógico gerado durante o projeto lógico para construção das 
estruturas físicas do banco de dados.
A) Alternativa correta. 
Justificativa: projeto conceitual de dados é uma atividade que tem como ponto de partida os 
requisitos de informação e as regras de negócio inerentes a um determinado problema ou necessidades 
de automação de uma área de negócio.
B) Alternativa correta. 
Justificativa: o esquema conceitual de dados é constituído de: a) Diagrama de Entidade e 
Relacionamento (DER), que modela o aspecto estrutural do mundo real; b) Regras de Restrição de 
Integridade (RI) e c) um conjunto de Regras de Derivação (RD) que modelam o aspecto comportamental 
do mundo real. 
C) Alternativa correta. 
Justificativa: durante o projeto conceitual é gerado o esquema conceitual do banco de dados e 
através dele que se descrevem as características dos dados ou informações que estarão contidas no 
banco de dados. 
D) Alternativa correta. 
Justificativa: a atividade do projeto lógico de banco de dados tem como objetivo transformar o 
modelo conceitual obtido durante o projeto conceitual de dados em um modelo lógico. O modelo lógico 
51
ADMINISTRAÇÃO DE BANCO DE DADOS
define como o banco de dados será implementado em um SGBD específico, tal como o Oracle, o DB2, 
o MySQL etc.
E) Alternativa incorreta. 
Justificativa: o Projeto Físico do banco de dados toma por base o esquema lógico para construir o 
esquema físico. Um esquema físico é uma descrição da implementação do banco de dados em memória 
disco magnético ou memória secundária; ele descreve as estruturas de armazenamento e métodos de 
acesso usados para efetivamente realizar o acesso aos dados. O projeto físico é direcionado para um 
SGBD específico (por exemplo: Oracle, Sybase, OpenIngres, Access).
Questão 2. O modelo de banco de dados relacional apresenta o banco de dados como uma coleção 
de tabelas. O conceito de tabela, embora seja simples e intuitivo, apresenta uma forte correspondência 
com o conceito matemático de uma relação. Dessa forma, um banco de dados relacional consiste em 
uma coleção de relações (tabelas), cada qual associada a um nome único (identificação da relação 
ou tabela). Para a manipulação das tabelas e dos Bancos de Dados Relacionais utiliza-se a linguagem 
SQL (Structured Query Language – Linguagem de consulta estruturada), que é uma linguagem usada 
para a consulta, atualização, criação e gerenciamento de banco de dados relacionais. É um método 
para selecionar determinados registros de um banco de dados, seguindo um critério especificado pelo 
usuário ou por uma aplicação. A SQL é considerada uma linguagem padrão para o gerenciamento de 
banco de dados relacionais. 
Considerando os conceitos sobre Banco de Dados Relacionais e linguagens de manipulação de BD, 
examine as afirmações a seguir e indique a alternativa incorreta:
A) A linguagem SQL é considerada a linguagem padrão ANSI (American National Standards Institute 
- Instituto Nacional de Padronização Americano) para a operação em bancos de dados relacionais. 
B) A linguagem SQL realmente tornou-se um padrão na indústria de Banco de Dados relacionais e 
os fornecedores (empresas desenvolvedores de BD relacionais) garantem esse padrão ao longo do 
tempo.
C) Pode-se afirmar que SQL não é a mesma coisa que SQL Server, pois SQL é a denominação universal 
para a linguagem de manipulação de BD relacional e SQL Server é o nome de um SGBD específico 
de um determinado fornecedor de Banco de Dados.
D) A linguagem SQL possui dois tipos de comandos fundamentais para que o usuário ou uma determinada 
aplicação faça uso do BD relacional, os comandos DDL e os comandos chamados de DML. 
E) Na linguagem SQL, o comando SELECT é o comando mais utilizado, pois é através dele que o BD 
retorna os dados de uma ou mais tabelas. Como ele não gera nenhuma modificação nos dados 
é utilizado para a busca de informações de uma tabela ou de um conjunto de tabelas de acordo 
com as necessidades do usuário ou de uma funcionalidade de uma aplicação.
Resolução desta questão na plataforma.
52
Unidade III
Unidade III
5 PROJETO DE BANCO DE DADOS
Antes de iniciar um projeto de banco de dados, você precisa conhecer como ele funciona e qual a 
linguagem de comunicação. De modo geral, os Sistemas Gerenciadores de Banco de Dados (SGBD) são 
compostos de diversos módulos e cada um deles é responsável por um conjunto de funcionalidades. 
Como existem muitos sistemas, cada um com suas particularidades, é muito raro um profissional 
dominar o funcionamento de todos. Normalmente, encontramos nas empresas um especialista que 
conhece profundamente o SGBD que a organização comprou. Por ser um profissional altamente 
qualificado, somente as grandes organizações costumam mantê-lo como um funcionário de carreira. 
As pequenas empresas têm o hábito de contratar esses especialistas somente na etapa de concepção e 
implementação do projeto e manter um contrato de consultoria para os momentos críticos, ou quando 
necessita de atualização e otimização do ambiente.
5.1 Linguagens de banco de dados
A linguagem para acessar um banco de dados depende do tipo de banco de dados. Aqueles do tipo 
relacional usam a linguagem SQL (Structured Query Language).
Essa linguagem originalmente foi criada pela IBM, e de forma muito rápida começaram a surgir 
diversas variações criadas por outros fabricantes. Para solucionar esse problema, houve a necessidade 
de se criar uma linguagem-padrão, mantida pela American National Standards Institute (ANSI) desde 
1986; aqui no Brasil, pela ISO desde 1987, sendo ambos os órgãos governamentais que cuidam das 
normas e padrões.
Em 1992, o SQL foi revisto e surgiu o SQL-92. Com a revisão em 1999, foi criado o SQL-99 (SQL3) e 
depois, em 2003, com nova revisão, surgiu o SQL:2003. No entanto, mesmo com a padronização da ANSI 
e do ISO, o SQL possui muitas variações e extensões produzidas pelos fabricantes de SGBD.
A maioria das instruções no SQL funciona da mesma forma nos diversos bancos de dados, mas nem 
todas as funções têm a mesma característica e forma de escrita. Por exemplo, o comando SELECT funciona 
igual para todos. Se você executar: SELECT * FROM PRODUTO, esse comando retornará todos os dados de 
todos os atributos da tabela produto, independentemente se o seu banco de dados é SQL Server, Sybase, 
MySQL ou Oracle. Mas, se você executar o comando SELECT GETDATE() no banco de dados Oracle, ele não 
vai funcionar, por se tratar de um comando do SQL Server, que também funciona no Sybase. Para obter a 
data corrente no Oracle, você deverá executar o comando SELECT SYSDATE FROM DUAL.
No caso de banco de dados multidimensionais, a linguagem mais apropriada é a MDX (Multidimensional 
Expressions), que é semelhante à sintaxe do SQL. O MDX não é uma extensão do SQL. Para criar expressões 
53
ADMINISTRAÇÃO DE BANCO DE DADOS
MDX usadas para desenhar ou projetar cubos, ou para criar consultas para retornar e formatar dados 
multidimensionais, você precisa entender os conceitos básicos de modelagem dimensional, pois essa 
linguagem tem elementos de sintaxe, operadores, instruções e funções próprias diferentes do SQL.
5.2 Tipos de linguagem SQL
A linguagem SQL podeser dividida em tipos de acordo com a sua funcionalidade. Os tipos usados 
nos sistemas gerenciadores de banco de dados são definidos a seguir.
5.2.1 Data Definition Language (DDL)
É o tipo de linguagem que interage com os objetos do banco de dados: tabelas, procedures, functions, 
views, triggers, entre outros. Cada SGBD tem seus manuais técnicos com a lista completa de comandos 
DDL e suas respectivas sintaxes completas.
São exemplos de comandos DDL:
• CREATE
• ALTER
• DROP
Para criar uma tabela para armazenar o registro do aluno (RA) e o nome do aluno, a sintaxe do comando é:
create table ALUNO ( RA char(7), NOME varchar(100) )
Para incluir uma nova coluna na tabela aluno, que será usada para armazenar a data de nascimento, 
precisamos alterar a tabela criada anteriormente por meio do comando ALTER TABLE:
alter table ALUNO add DATA_NASCIMENTO date
Caso você precise alterar a propriedade do campo RA para NULL, o comando a ser executado é:
alter table ALUNO alter column RA char(7) NULL
 Observação
Alguns SGBD, quando não informamos a nulidade do atributo, o padrão 
do gerenciador é considerar como nulo. Recomendamos ler os manuais de 
referência do SGBD com que você for trabalhar.
Importante: é altamente recomendado que você conheça o SGBD de que você está cuidando, 
pois, no caso de criar um atributo nulo, mas depois precisar alterá-lo para não nulo, nem todos os 
54
Unidade III
gerenciadores permitem esse tipo de alteração sem a definição de um valor default de preenchimento 
do atributo na execução do comando ALTER TABLE. Caso não exista um valor-padrão para todas as 
linhas, você não conseguirá executar o comando e terá que recriar a tabela novamente.
Para definir, isto é, criar a chave primária na tabela aluno, caso você não tenha usado o comando 
completo do CREATE TABLE, você pode fazer uma nova alteração na tabela, por meio do comando:
alter table ALUNO add constraint PK_ALUNO primary key(RA)
Se você precisar excluir a tabela aluno do seu banco de dados, basta executar o comando:
drop table ALUNO
Para excluir apenas uma coluna da tabela, o comando é:
alter table ALUNO drop column DT_NASCIMENTO
5.2.2 Data Manipulation Language (DML)
É o tipo de linguagem que interage com os dados armazenados dentro das tabelas do banco de 
dados. São comandos DML:
• INSERT
• UPDATE
• DELETE
• TRUNCATE
Depois de criar a tabela aluno, precisamos cadastrar os dados dos alunos, ou seja, inserir dados na 
tabela por meio do comando INSERT:
insert into ALUNO (RA, 
 NOME, 
 DT_NASCIMENTO)
 values (‘1234567’,
 ’LUIZ FERNANDO’,
 ’1978-08-28’)
Caso você precise alterar algum dado na tabela, o comando a ser executado é o UPDATE:
update ALUNO set NOME = ‘LUIS FERNANDO’ where RA = ‘1234567’
O comando update ALUNO set NOME = ‘LUIS FERNANDO’ sem a informação da cláusula where RA 
= ‘12345671’ fará a alteração do nome de todos os alunos cadastrados na tabela para “LUIS FERNANDO”.
55
ADMINISTRAÇÃO DE BANCO DE DADOS
 Lembrete
Para realizar alterações nos dados da tabela, você precisa realizar a 
operação de UPDATE com muita atenção e cautela. Se você não informar 
a chave primária na cláusula where do comando, a alteração será realizada 
para todos os registros da tabela.
Para excluir dados de uma tabela, o comando utilizado é:
delete from ALUNO where RA = ‘1234567’
Se você quiser excluir todos os dados de uma tabela, é só executar o comando delete from ALUNO.
O comando DELETE deve ser usado com atenção, pois, se você não informar o valor da chave 
primária na cláusula where, todos os dados da tabela serão excluídos.
Para efetuar alterações e exclusões em dados, no caso de as tabelas se relacionarem com outras, 
você só poderá efetuar as alterações respeitando a hierarquia desses relacionamentos. Portanto, antes 
de executar os comandos de DML, você deve conhecer o modelo de dados que está implementado.
Para excluir todos os dados, você também pode usar o comando TRUNCATE. A diferença entre ele e 
o comando DELETE é que a ação de truncate não é gravada no log de transações.
truncate table ALUNO
 Observação
Como a ação de truncate não é uma transação gravada no log do 
banco de dados, ela não é recomendada para ser usada nas aplicações. 
Por questões de segurança, as transações que modificam os dados (insert, 
delete e update) são auditadas, ou seja, o administrador de banco de dados 
consegue identificar e rastrear essas ações. Mas se a transação de exclusão 
de dados for executada por meio do comando TRUNCATE, não deixará 
nenhum rastro.
5.2.3 Data Control Language (DCL)
É o tipo de linguagem que interage com a parte de segurança do banco de dados. Baseado na política 
de segurança definida para o sistema desenvolvido, é com esses comandos que podemos garantir quais 
dados serão acessados, que tipo de ações poderão ser realizadas por uma pessoa ou um grupo de 
pessoas. São comandos DCL:
56
Unidade III
• GRANT (select, insert, delete, update)
• GRANT EXECUTE
• REVOKE (select, insert, delete, update)
• REVOKE EXECUTE
O comando para permissão de execução em todas as procedures do banco de dados é:
grant execute to usuario
 Lembrete
A sintaxe sempre vai depender do SGBD que você está usando. No 
caso de um SGBD da Sybase, por exemplo, não é possível executar o 
GRANT EXECUTE para todas as procedures num único comando. Você 
terá que escrever um script contendo o GRANT EXECUTE para cada uma 
delas e depois executar esse script, que fará a execução do comando 
linha a linha.
Para garantir a permissão de execução da procedure SPalterarMeuNome para uma determinada 
pessoa, o comando é:
grant execute on SPalterarMeuNome to usuario
Para dar permissão de execução na procedure para um grupo de pessoas, o comando é:
grant execute on SPalterarMeuNome to grupoRH
Quando criamos as tabelas no banco de dados, precisamos aplicar as permissões adequadas para os 
tipos de operações que a tabela pode sofrer. Por exemplo, os dados da tabela aluno podem ser vistos 
por todos os alunos e funcionários da Seção de Alunos, mas somente alguns funcionários dela e o 
próprio aluno poderão alterar os dados da tabela. Para garantir essas ações, usamos o comando GRANT, 
conforme sintaxe a seguir:
grant select on ALUNO to grupo_alunos
grant select on ALUNO to secao-alunos
grant update on ALUNO to aluno
grant delete on ALUNO to funcionário
57
ADMINISTRAÇÃO DE BANCO DE DADOS
 Observação
Podemos aplicar todas as permissões (select, insert, delete, update) em 
uma tabela com a execução do comando grant all on TABELA to usuário.
No caso de necessitar retirar a permissão de algum objeto do banco de dados, você deve executar 
o comando REVOKE. Por exemplo, para remover a permissão de execução em todas as procedures do 
banco de dados, você deve executar o comando:
revoke execute to usuário
Para remover a permissão de execução de apenas uma procedure de um determinado usuário ou 
grupo de usuários, o comando é:
revoke execute on SPminhaProcedure to usuario
Como você pode ter notado, o comando REVOKE é o oposto do comando de GRANT, e as 
mesmas recomendações e observações feitas para o comando de GRANT se aplicam para o 
comando REVOKE.
5.2.4 Data Transaction Language (DTL)
É o tipo de linguagem que controla as transações que são executadas em um banco de dados. 
Transação é uma unidade de execução de programa que acessa e atualiza os dados.
A transação consiste em todas as operações executadas entre o começo (BEGIN TRANSACTION) e 
o fim (END TRANSACTION) da transação.
Quando executamos qualquer um dos comandos DML (INSERT, DELETE, UPDATE) ou de DDL 
(CREATE, ALTER, DROP), também estamos realizando uma transação dentro do banco de dados.
Durante o tempo em que a transação estiver em aberto, os comandos DML estão sendo 
realizados em memória. Assim que a transação for confirmada pela instrução denominada commit, 
todas as operações serão efetuadas fisicamente no banco de dados. No caso de falha de alguma das 
operações, a transação será desfeita pela instruçãode rollback, e nenhuma operação será realizada 
no banco de dados.
O comando COMMIT efetiva todas as alterações realizadas no banco de dados. A operação de commit 
aplica-se a todos os comandos SQL, incluindo comandos DDL. As transações que estão bloqueadas 
(lock), aguardando o término de uma transação, são sempre liberadas depois do commit na transação 
que está causando o bloqueio.
58
Unidade III
O comando ROLLBACK finaliza uma transação atual. Quando ele é executado, o SQL aborta a 
transação atual. Isso restaura o banco de dados ou até o estado em que ele estava antes do último 
commit ou rollback.
 Lembrete
Enquanto nenhuma das instruções, seja de commit ou de rollback, não 
for processada, as alterações ficam esperando e consumindo recursos de 
memória, por exemplo.
Os comandos DTL são normalmente utilizados dentro de procedimentos (procedures) ou triggers, 
pois esses objetos costumam ter diversas ações de alterações nos bancos de dados.
Os comandos da DTL são os seguintes:
• BEGIN TRANSACTION
• COMMIT TRANSACTION
• ROLLBACK TRANSACTION
• END TRANSACTION
5.2.5 Data Query Language (DQL)
É o tipo de linguagem que cuida da parte de queries (consultas) aos dados. Apesar de interagir com 
os dados como a DML, ela não produz alterações neles, serve apenas para consulta.
O formato-padrão para consulta é:
SELECT atributo FROM relação WHERE condição
 Observação
Relação pode ser uma tabela física no banco ou várias tabelas 
relacionadas. Atributo é a coluna da tabela.
Em algumas bibliografias, o comando SQL está dentro de DML.
Exemplos de instrução DQL:
Consideramos a seguinte relação (tabela) Aluno e seus respectivos atributos, assim definidos:
59
ADMINISTRAÇÃO DE BANCO DE DADOS
• Aluno (nome, idade, curso, ra_aluno)
Para obter a lista de todos os atributos de todos os alunos da tabela aluno, você deve executar o 
comando:
SELECT * FROM aluno
ou
SELECT nome, idade, curso, ra_aluno FROM aluno
Quando usamos asterisco (*), queremos dizer que todas as colunas da tabela devem ser retornadas.
Para obter todas as informações do aluno cujo RA é 1234567, o comando é:
SELECT * FROM aluno
WHERE ra_aluno = ‘1234567’
Para selecionar o nome dos alunos que cursam Gestão de Tecnologia da Informação, o comando é:
SELECT nome FROM aluno
WHERE curso = ‘Gestão de Tecnologia da Informação’
Para saber quais os alunos que têm mais de 25 anos:
SELECT nome FROM aluno
WHERE idade > 25
O comando SELECT é o mais utilizado dentro de um banco de dados. Ele serve para retornar dados 
de uma ou mais tabelas. Como ele não gera nenhuma modificação nos dados, você pode usá-lo antes 
de fazer a alteração. Por exemplo, suponha que você fosse alterar alguma informação do aluno cujo RA 
é 1234567. Antes de executar o comando UPDATE, você deve executar o comando SELECT e analisar o 
resultado. Isso evita o risco de realizar alterações indevidas.
Para retornar dados de mais de uma tabela, utilizamos o conceito de join. É extremamente 
importante conhecer o modelo de dados e como as tabelas estão relacionadas, para obter 
resultados corretos.
O comando JOIN ou junção é baseado na teoria dos conjuntos. Considere as tabelas como um 
conjunto de dados sobre um determinado assunto.
60
Unidade III
 Observação
A sintaxe do comando JOIN entre duas ou mais tabelas relacionadas 
é diferente entre os diversos dialetos do SQL. Para escrever o comando 
corretamente, você deverá consultar o manual do gerenciador de banco 
de dados.
Os exemplos de JOIN que serão mostrados a seguir estão usando a sintaxe do SQL padrão ANSI. Caso 
você queira testar os comandos em um banco de dados, você precisa estar atento se ele é compatível 
com o SQL ANSI, pois a sintaxe do JOIN difere muito.
Exemplo de sintaxe do comando SELECT com mais de uma tabela. Por exemplo, vamos considerar 
as tabelas:
• Turma (id_turma, nome, sala, disciplina)
• Disciplina (disciplina, sigla, créditos)
Queremos a lista das salas de cada turma, indicando o nome da turma e a sigla de cada disciplina 
correspondente. O comando SELECT ficará assim:
SQL padrão ANSI:
SELECT sala, nome, sigla FROM Turma, Disciplina
INNER JOIN Disciplina
ON Turma.disciplina = Disciplina.disciplina
ou
Transact-SQL:
SELECT sala, nome, sigla FROM Turma, Disciplina
WHERE Turma.disciplina = Disciplina.disciplina
Para entender como esse JOIN funciona, com base na teoria dos conjuntos, vamos considerar as 
tabelas como conjuntos da seguinte forma: o conjunto das turmas será denominado conjunto A; o 
conjunto das disciplinas será o conjunto B, conforme a figura seguinte.
61
ADMINISTRAÇÃO DE BANCO DE DADOS
Conjunto/Tabela A Conjunto/Tabela B
Figura 27 – Tabelas como diagramas de conjuntos
INNER JOIN – é o tipo de JOIN mais usado. Retorna apenas os dados que existem em comum nas 
duas tabelas. Com base na teoria dos conjuntos, podemos dizer que é a intersecção entre os conjuntos, 
conforme representado na figura a seguir.
Conjunto/Tabela A
Conjunto/Tabela B
Figura 28 – Representação gráfica do INNER JOIN
Sintaxe do INNER JOIN usando o SQL padrão ANSI:
select * from A
 inner join B on A.atributo_chave = B.atributo_chave
E agora utilizando o Transact-SQL:
select * from A, B
 where A.atributo_chave = B.atributo_chave
LEFT JOIN – usado quando é necessário retornar todos os dados de uma tabela, mesmo que não 
exista na outra tabela. O LEFT JOIN retorna os dados da tabela da esquerda, conforme a figura a seguir.
62
Unidade III
Conjunto/Tabela A
Conjunto/Tabela B
Figura 29 – Representação gráfica do LEFT JOIN
Sintaxe do LEFT JOIN usando o SQL padrão ANSI:
select * from A
 left join B on A.atributo_chave = B.atributo_chave
Agora, utilizando o Transact-SQL:
select * from A, B
 where A.atributo_chave *= B.atributo_chave
RIGHT JOIN – assim como o LEFT JOIN, é usado quando é necessário retornar todos os dados de 
uma tabela, mesmo que não existam na outra tabela. O RIGHT JOIN retorna os dados da tabela da 
direita, conforme a figura a seguir.
Conjunto/Tabela A
Conjunto/Tabela B
Figura 30 – Representação gráfica do RIGHT JOIN
Sintaxe do RIGHT JOIN usando o SQL padrão ANSI:
63
ADMINISTRAÇÃO DE BANCO DE DADOS
select * from A
 right join B on A.atributo_chave = B.atributo_chave
Agora, utilizando o Transact-SQL:
select * from A, B
 where A.atributo_chave =* B.atributo_chave
5.3 Módulos de funcionamento do SGBD
O núcleo de um SGBD é composto pelo módulo central, que é o módulo gerenciador do banco 
de dados, responsável pela transparência do acesso físico aos dados armazenados, seja para 
aplicações, seja para os usuários especializados e o DBA. O SGBD apenas solicita os dados a esse 
módulo, que se encarrega de localizar os registros fisicamente em disco e transferi-los para as 
estruturas de dados.
Esse módulo realiza a comunicação com o sistema operacional do equipamento onde se encontram 
os dados, por meio do mapeamento de registros em memória para as páginas de disco onde se encontram, 
ou vice-versa.
Em outras palavras, esse módulo é responsável pelo atendimento das requisições de dados e 
metadados feitas pelos módulos que interagem com os agentes. Atende também às solicitações de 
operações sobre dados enviados pelo código objeto das aplicações. Retornam dados e/ou status que 
indicam situações como execução realizada com sucesso, erros de acesso, violações de integridade ou 
permissão etc.
É o único módulo que se comunica com o módulo gerenciador de arquivos. Os controles de segurança 
e concorrência são de responsabilidade desse módulo central.
O módulo gerenciador de arquivos gerencia o acesso aos dispositivos de armazenamento. Recebe 
e realiza requisições para leitura e gravação de dados, metadados e dados de segurança do módulo 
gerenciador do banco de dados.
Responsável pela tradução de comandos DML, temos o módulo compilador DML. No caso em que os 
comandos DML são embutidos em um programa de aplicação, esse módulo realiza a pré-compilação e 
a geração do código objeto para esses comandos, criandoum programa pré-compilado que é remetido 
para o compilador do ambiente de desenvolvimento utilizado pelo programador. Já no caso em que os 
comandos DML são enviados de forma ad hoc por usuários especializados, o módulo traduz e já executa 
o comando, caso esteja correto.
Em ambos os casos, o módulo compilador DML solicita metadados ao módulo gerenciador do banco 
de dados, para poder traduzir os comandos; caso a solicitação seja uma consulta, ele a remete ao 
módulo processador de consultas, recebendo-a modificada.
64
Unidade III
O módulo processador de consultas recebe um comando de consulta do módulo pré-compilador 
DML e define a melhor estratégia de acesso para processá-la. Para tanto, esse módulo necessita solicitar 
metadados ao módulo gerenciador do bando de dados, com o objetivo de analisar o tamanho dos 
arquivos envolvidos na consulta, os relacionamentos existentes, a estimativa de valores distintos de 
atributos, visando determinar um procedimento que processe a consulta mais rapidamente. Esse 
procedimento, uma vez determinado, é enviado ao módulo compilador DML para ser traduzido.
Para traduzir o programa-fonte da aplicação, escrito em alguma das linguagens de programação 
suportadas pelo SGBD, temos o módulo compilador do utilitário. Esse módulo retorna um código de 
status à ferramenta de desenvolvimento e gera, no caso de uma tradução bem-sucedida, o código 
objeto da aplicação.
Já o módulo compilador DDL traduz comandos DDL e gera os esquemas conceitual e físico, ou seja, 
solicita a criação do banco de dados da aplicação para o módulo gerenciador do banco de dados, que 
por sua vez solicita ao módulo gerenciador de arquivos a criação de arquivos de dados e metadados.
O módulo compilador DCL e de autorização gera procedimentos para verificação de integridade e 
permissão de acesso. Esses procedimentos são remetidos ao módulo gerenciador do banco de dados, 
que por sua vez solicita ao módulo gerenciador de arquivos o armazenamento deles no dicionário de 
dados.
Os procedimentos para monitoramento de performance e configuração do banco de dados, e 
também recuperação de falhas, são funcionalidades do módulo de administração. A primeira classe de 
procedimentos solicita e/ou modifica dados de configuração e solicita estimativas sobre performance 
ao módulo gerenciador do banco de dados, que os obtém no dicionário de dados e/ou nos dispositivos 
que mantêm dados de segurança. A segunda classe de procedimentos solicita dados ao banco de dados 
de recovery para restaurar os dados do banco de dados na ocorrência de uma falha.
5.4 Etapas do projeto de banco de dados
O desenvolvimento de um sistema de informação envolve a análise e o projeto de dois componentes 
importantes: os dados e os processos.
O projeto de dados é considerado a parte estática do sistema, uma vez que diz respeito a um universo 
persistente de características que dificilmente sofre modificações após a sua definição.
O projeto de processos, por sua vez, é chamado de parte dinâmica, uma vez que as tarefas a serem 
realizadas sobre os dados podem variar, conforme ocorre a evolução do sistema.
Consideram-se projeto de um banco de dados a análise, o projeto e a implementação dos dados 
persistentes de uma aplicação, levando em conta a determinação da sua semântica (abstração dos 
dados de uma realidade) e, posteriormente, o modelo de dados e o SGBD a serem adotados.
O projeto de um banco de dados é composto de quatro etapas, descritas a seguir.
65
ADMINISTRAÇÃO DE BANCO DE DADOS
5.4.1 Levantamento de requisitos
É a fase principal de todo o projeto de banco de dados, em que é necessário entender do que 
o usuário realmente necessita. Nessa etapa, são coletadas informações sobre os dados de interesse 
da aplicação, o seu uso e as suas operações de manipulação sobre os dados, e suas relações. Para a 
realização dessa etapa, são necessárias tarefas como:
• entrevistas com os futuros usuários do sistema;
• análise de documentações disponíveis (arquivos, relatórios etc.).
O resultado dessa etapa normalmente é uma descrição dos requisitos da aplicação, o mais detalhado 
e claro possível. Caso nenhuma metodologia de engenharia de software esteja sendo empregada, essa 
descrição de requisitos é informal, no formato de um texto, por exemplo, que narra as informações 
comentadas anteriormente.
5.4.2 Projeto conceitual
Pode ser considerada a fase de análise dos dados e dos requisitos capturados na etapa anterior. 
Nessa etapa, é realizado o que se chama de desenho da solução ou modelagem conceitual, momento 
em que são analisados os fatos (entidades ou conjunto de ocorrências de dados) de interesse e seus 
relacionamentos, juntamente com seus atributos (propriedades ou características), e é construída uma 
notação gráfica (abstrata, uma representação de alto nível) para facilitar o entendimento dos dados e 
suas relações, tanto para os analistas quanto para os futuros usuários.
Essa etapa resulta em um modelo conceitual, em que a semântica da realidade deve estar correta. 
A ferramenta mais empregada nessa etapa é o Diagrama Entidade-Relacionamento (DER). Ainda nessa 
fase, as reuniões com o usuário são constantes, para mais entendimentos sobre o projeto e validação do 
modelo conceitual.
5.4.3 Projeto lógico
Nessa etapa, o desenvolvimento do banco de dados começa a se voltar para o ambiente de 
implementação, uma vez que é feita a conversão do modelo de dados de um banco de dados (modelo 
lógico). Esse modelo de dados pode ser o modelo relacional, orientado a objetos, multidimensional etc.
Essa etapa se baseia no uso de regras de mapeamento de um DER para o modelo de dados escolhido. 
O resultado é uma estrutura lógica, como um conjunto de tabelas relacionadas, caso o modelo de dados 
escolhido seja o relacional. Aqui, definimos efetivamente a chave primária, bem como refinamos os 
relacionamentos que vêm do diagrama construído na etapa anterior.
Nessa etapa, realizamos o processo de normalização das tabelas, a fim de remover as redundâncias 
e inconsistências.
66
Unidade III
5.4.4 Projeto físico
Essa última etapa realiza a adequação do modelo lógico gerado na etapa anterior ao formato de 
representação de dados do SGBD escolhido para a implementação.
Para a realização dessa etapa, devem-se conhecer a DDL e a DCL do SGBD, para realizar a descrição do 
modelo lógico. O resultado é a especificação do esquema da aplicação, juntamente com a implementação 
de restrições de integridade e visões.
 Observação
Nessa etapa do projeto, criamos um “mapa” do banco de dados, da 
forma como ele será criado em SQL. Aqui, definimos os tipos de dados de 
cada atributo e, quando necessário, alteremos os nomes dos campos e das 
tabelas para que se ajustem ao padrão da organização.
5.4.5 Criação do banco de dados
Essa é a etapa da programação propriamente dita. Aqui, seguindo o que foi definido no modelo 
físico, serão criados todos os objetos dentro do banco de dados, utilizando a linguagem SQL.
5.4.6 Exemplo de projeto de banco de dados
1ª. etapa: levantamento de requisitos
Seu usuário pede que você crie um cadastro de pessoas. Durante a entrevista, você fará diversas 
perguntas para saber o que ele pretende com esse cadastro de pessoas. Além do nome e do CPF, ele quer 
ter o cadastro do telefone. No final dessa etapa, você terá um documento descrevendo da forma mais 
detalhada possível todas as operações que envolvem esse cadastro de pessoas.
2ª. etapa: projeto conceitual
Nessa etapa, você criará o modelo conceitual, identificando e analisando os fatos ou as entidades, e construirá 
uma representação gráfica para facilitar o entendimento do usuário, conforme por ser visto na figura a seguir.
CPF
NOME
TEL
PESSOA
Figura 31 – Representação gráfica do modelo conceitual
67
ADMINISTRAÇÃO DE BANCO DE DADOS
3ª. etapa: projeto lógico
Nessa etapa, com o modelo conceitual analisado e aprovado pelo usuário, você começará a fazer a 
conversão para um modelo de dados adequado com as especificações realizadasnas etapas anteriores. 
Em nosso exemplo, podemos usar o modelo relacional, pois, no caso de o usuário querer incluir no 
seu cadastro de pessoas outra informação – como dados do endereço residencial, dados sobre as 
características dessa pessoa dentro do sistema –, você terá que alterar o seu modelo e incluir mais tabelas 
e seus respectivos relacionamentos. Por enquanto, a estrutura lógica que temos está representada na 
figura a seguir. Até aqui, sabemos que já temos uma tabela denominada pessoa, com os atributos CPF, 
nome e tel, e o atributo que irá garantir a identificação de uma única pessoa será o CPF, ou seja, o 
atributo candidato a ser considerado como chave primária já está definido.
Pessoa
PK CPF
NOME
TEL
Figura 32 – Modelo lógico de uma entidade
4ª. etapa: projeto físico
Nessa etapa, estamos prontos para criar a tabela no banco de dados, e, se já existir um arquivo com 
os dados, também poderemos providenciar a carga da primeira massa de dados. Tudo será realizado no 
banco de dados escolhido e com a utilização dos comandos DDL e DCL.
Para facilitar o trabalho, podermos gerar um arquivo (script) com a sequência dos comandos de 
criação da tabela, os comandos de permissão de acesso e manipulação e também os comandos para 
inserir a primeira massa de dados.
Pessoa
PK CPF CHAR(11)
NOME
TEL
VARCHAR(100)
CHAR(10)
Figura 33 – Modelo físico de uma entidade
Exemplo do arquivo (script) de criação dos objetos de banco de dados:
create table PESSOA ( CPF char(11) not null,
 NOME varchar(100) not null,
 TEL char(10) null,
constraint PK_PESSOA primary key (CPF) )
grant select on PESSOA to grupo_usario
grant insert on PESSOA to usuario1
grant update on PESSOA to usuario1
68
Unidade III
grant delete on PESSOA to usuario1
BEGIN TRANSACTION
insert to PESSOA (CPF, NOME, TEL)
values (‘13515794-22’, ‘João da Silva’, ‘(011) 2244-56789’
insert to PESSOA (CPF, NOME, TEL)
values (‘9995794-22’, ‘Pedro Toledo, ‘(011) 7644-53789’
insert to PESSOA (CPF, NOME, TEL)
values (‘5691800-09, ‘Clara Nunes’, ‘(011) 3450-9900’
insert to PESSOA (CPF, NOME, TEL)
values (‘09873456-35’, ‘Luis Alves, null)
COMMIT TRANSACTION
insert to PESSOA (CPF, NOME, TEL)
values (‘19565797-02’, ‘Paulo da Silva’)
insert to PESSOA (CPF, NOME, TEL)
values (‘4569579-12’, ‘Carlos Manuel, ‘(011) 9084-13689’
insert to PESSOA (CPF, NOME, TEL)
values (‘7891800-49, ‘Maria Oliveira’, ‘(011) 3400-9000’
insert to PESSOA (CPF, NOME, TEL)
values (‘09803454-36’, ‘Ricardo Veiga, null)
COMMIT TRANSACTION
END TRANSACTION
6 TIPOS DE DADOS (DATA TYPES)
Um banco de dados existe para armazenar dados de forma efetiva para posteriormente recuperá-los. 
Para auxiliar nessa tarefa, existem tipos diferentes de dados para melhor armazená-los.
Os bancos de dados possuem vários tipos e subtipos de dados. Recomendados a leitura do manual do 
banco de dados fornecido pelo fabricante para você conhecer os tipos de dados. É muito comum fazer 
algumas conversões de um tipo de dados para outro durante uma consulta dos dados armazenados no 
banco de dados.
69
ADMINISTRAÇÃO DE BANCO DE DADOS
Alguns gerenciadores de bancos de dados consegue fazer essas conversões diretamente, sem 
a necessidade de explicitar por meio de funções próprias de conversão. Os elementos de dados 
básicos e as estruturas de dados mais comuns, utilizadas em diversas linguagens e bancos de 
dados, estão a seguir.
6.1 Elementos de dados
• Byte, Integer: números inteiros positivos, negativos ou o zero.
• Real: números inteiros positivos ou negativos compostos por uma parte inteira e outra fracionada. 
Exemplo: 8,2.
• Char: caractere alfanumérico como letras, algarismos ou símbolos especiais ocupando uma única 
posição de memória. Na verdade, esse elemento armazena um numero da tabela ASCII.
• Boolean: armazena estados de uma operação lógica, podendo receber valores de verdadeiro ou 
falso, armazenando o bit 0 ou 1 dependendo do resultado.
Quando os dados estão organizados de forma coerente, temos uma estrutura de dados. As estruturas 
também são chamadas tipos de dados compostos e podem ser:
• Homogêneos: conjunto de dados formado pelo mesmo elemento de dado.
• Heterogêneos: conjunto de dados formado por mais de um elemento de dado.
Alguns bancos de dados, além de ter uma vasta coleção de elementos de dados, permitem a 
criação de novos elementos, por exemplo, o PostgreSQL, que permite a criação por meio do comando 
CREATE TYPE.
Existem elementos de dados nativos de um banco de dados que não existem em outros bancos de dados.
6.1.1 Estrutura de dados
As mais comuns serão descritas a seguir. Lembrando que nem todas as estruturas existem nos 
diferentes bancos de dados. Por exemplo, a estrutura de dados conhecida como vetor não existe no 
bando de dados Sybase, mas por meio do conceito de cursor podemos lidar com os dados com a mesma 
funcionalidade dos vetores.
• Vetores
Também conhecidos como array, são uma estrutura de dados simples linear e estática que mantém 
uma série finita de elementos de dados do mesmo tamanho e tipo.
70
Unidade III
• Lista
Cada elemento de dados referencia o seu sucessor. Os tipos de lista são:
• Lista encadeada
Os elementos são armazenados em sequência, não tendo como acessar um segundo elemento sem 
acessar o primeiro.
• Lista ordenada
Os elementos são armazenados seguindo algum critério de ordenação.
• Fila
Estruturas que se comportam como filas tradicionais e têm como política de funcionamento o FIFO 
(First in, first out – primeiro que entra, primeiro que sai). As inserções são realizadas no final, e a remoção 
no início.
Existem duas operações nas filas, que são:
– Enqueue: adiciona um elemento ao final da fila.
– Dequeue: remove um elemento do início da fila.
5 3 7 1 4
Começo Fim
Figura 34 – Exemplo de estrutura de dados em fila
• Pilha
É baseada no princípio LIFO (Last in, first out – último que entra, primeiro que sai). O topo é o único 
local possível de inserir elementos e a remoção da pilha só ocorre nas extremidades do topo, isto é, os 
elementos são removidos na ordem inversa da inserção.
As funções que se aplicam a pilhas são:
– PUSH: insere um dado no topo da pilha.
– POP: remove o item no topo da pilha.
– TOP: retorna o elemento no topo.
71
ADMINISTRAÇÃO DE BANCO DE DADOS
• Árvores
Os dados estão dispostos de forma hierárquica, tendo seu elemento principal chamado de raiz, que 
possui ligação com os outros elementos denominados ramos. Uma árvore binária é aquela em que cada 
ramo possui mais dois ramos, como na figura a seguir.
Figura 35 – Exemplo de estrutura de dados em árvore
 Saiba mais
Para se aprofundar no assunto, recomendamos alguns livros de estrutura 
de dados, que estão relacionados na bibliografia ao final do livro-texto.
6.1.2 Unidades de medidas
Os computadores “entendem” impulsos elétricos, positivos ou negativos, que são representados por 
1 ou 0. A cada impulso elétrico, damos o nome de bit (BInary digiT). Um conjunto de 8 bits reunidos 
como uma única unidade forma um byte. A seguir, apresentamos algumas conversões de medidas.
1 byte = 8 bits
1 kilobyte (KB ou Kbytes) = 1024 bytes
1 megabyte (MB ou Mbytes) = 1024 kilobytes
1 gigabyte (GB ou Gbytes) = 1024 megabytes
1 terabyte (TB ou Tbytes) = 1024 gigabytes
1 petabyte (PB ou Pbytes) = 1024 terabytes
1 exabyte (EB ou Ebytes) = 1024 petabytes
72
Unidade III
1 zettabyte (ZB ou Zbytes) = 1024 exabytes
1 yottabyte (YB ou Ybytes) = 1024 zettabytes
É também por meio dos bytes que se determina o comprimento da palavra de um computador, ou 
seja, a quantidade de bits que o dispositivo utiliza na composição das instruções internas, por exemplo:
8 bits palavra de 1 byte
16 bits palavra de 2 bytes
32 bits palavra de 4 bytes
Na transmissão de dados entre dispositivos, geralmente, usam-se medições relacionadas a bits e não 
a bytes. Assim, há também os seguintes termos:
1 kilobit (Kb ou Kbit) = 1024 bits
1 megabit (Mb ou Mbit) = 1024 kilobits
1 gigabit (Gb ou Gbit) = 1024 megabits
1 terabit(Tb ou Tbit) = 1024 gigabits
 Observação
Quando a medição é baseada em bytes, a letra “b” da sigla é maiúscula 
(como em GB). Quando a medição é feita em bits, o “b” da sigla fica em 
minúsculo (como em Gb).
Como já dito, a utilização de medições em bits é comum para informar o volume de dados em 
transmissões. Geralmente, indica-se a quantidade de bits transmitidos por segundo. Assim, quando 
queremos dizer que um determinado dispositivo é capaz de trabalhar, por exemplo, com 54 megabits 
por segundo, usa-se a expressão 54 Mb/s:
1 Kb/s = 1 kilobit por segundo
1 Mb/s = 1 megabit por segundo
1 Gb/s = 1 gigabit por segundo
73
ADMINISTRAÇÃO DE BANCO DE DADOS
 Resumo
Vimos nesta unidade que a etapa de projeto conceitual de um banco 
de dados consiste na elaboração de um modelo conceitual, ou seja, um 
modelo de representação de categorias de fatos do mundo real (entidades) 
e os relacionamentos existentes entre eles.
É dito um modelo de alto nível, pois não está vinculado a nenhum 
modelo de banco de dados. Sua intenção é facilitar a real compreensão dos 
fatos de uma realidade (semântica da realidade).
A etapa de projeto conceitual é uma das mais importantes do projeto 
do banco de dados, pois, se for mal definida, irá gerar uma estruturação de 
dados ineficiente no esquema implementado em um banco de dados.
As principais vantagens da confecção de um modelo conceitual são:
• melhor compreensão do modelo por parte de um usuário leigo;
• independência de detalhes de implementação, podendo ser 
facilmente modificado sem comprometer as outras etapas;
• tradução para qualquer modelo de dados (relacional, orientado a 
objetos, multidimensional);
• ferramenta indispensável para o processo de engenharia reversa de 
um banco de dados (isto é, obter o modelo conceitual a partir do 
modelo lógico de um banco de dados);
• maior estabilidade diante das mudanças de implementação;
• mais adequado para o exercício da criatividade durante a interpretação 
da realidade para ser traduzida para o modelo.
 Exercícios
Questão 1. O Modelo Entidade Relacionamento (MER) é baseado na percepção do mundo real. O 
modelo representa a visão das entidades de dados envolvidas no problema analisado. Pode-se afirmar 
que ele consiste em um conjunto de objetos básicos chamados entidades e nos relacionamentos entre 
esses objetos. O objetivo do MER é facilitar o projeto de banco de dados, possibilitando a especificação 
da estrutura lógica geral do banco de dados. No modelo desenha-se um diagrama chamado de DER 
(Diagrama Entidade-Relacionamento) que mostra a estrutura lógica geral de um banco de dados. Ele 
74
Unidade III
serve para checar se todos os pedidos dos usuários estão sendo atendidos e se não há conflitos entre 
eles. Não há preocupação com armazenamento físico. 
Considerando os conceitos sobre Projeto de Banco de Dados, examine as afirmações a seguir e 
indique a alternativa incorreta:
A) O modelo de dados é a representação abstrata e simplificada de uma realidade, com o qual se 
pode explicar ou testar o seu comportamento.
B) O modelo de dados é uma coleção de conceitos que podem ser usados para descrever a estrutura 
de um banco de dados (tipos de dados, relacionamento e restrições entre os mesmos).
C) Os modelos de dados não permitem a compreensão da estrutura dos dados armazenados e a 
sua manipulação. 
D) Os modelos de dados, para efeito de organização foram dividos em: modelo conceitual (projeto 
conceitual), modelo de implementação ou baseados em registros (projeto lógico), e modelo físico 
(projeto físico).
E) O modelo conceitual é usado na descrição do banco de dados, sendo independente de 
implementação e do monitor de banco de dados (SGBD).
Resposta correta: alternativa C.
Análise das alternativas
O modelo de dados (MER) é uma abordagem que foi criada por Peter Chen em 1976 e que permitiu 
a análise dos dados a serem armazenados independentes da solução de banco de dados oferecidos pelos 
fornecedores. É até hoje considerada como um padrão para a modelagem conceitual.
A) Alternativa correta. 
Justificativa: o modelo de dados (MER) tem por base que o mundo real é formado por um conjunto 
de objetos chamados de entidades e pelo conjunto dos relacionamentos entre esses objetos.
B) Alternativa correta. 
Justificativa: o objetivo do MER é representar a estrutura lógica do banco de dados de uma empresa, 
especificando o esquema da empresa, quais as entidades e como elas serelacionam entre si.
C) Alternativa incorreta. 
Justificativa: os autores definem que modelos são mentais e que são pressupostos profundamente 
arraigados, generalizações ou mesmo imagens que influenciam a forma de ver o mundo e de nele agir. 
75
ADMINISTRAÇÃO DE BANCO DE DADOS
Muitas vezes, não estamos conscientes de nossos modelos mentais ou de seus efeitos sobre nosso 
comportamento. Essa definição na Engenharia de Software cobre todos os modelos previstos, inclusive 
a modelagem dos dados de um Sistema de Informação.
D) Alternativa correta.
Justificativa: a abordagem da modelagem de dados é uma visão do assunto que normalmente 
atende a três perspectivas: modelagem conceitual, modelagem lógica e modelagem física. A primeira é 
usada como representação de alto nível e considera exclusivamente o ponto de vista do usuário criador 
do dado ou proprietário, a segunda já agrega alguns detalhes de implementação e a terceira demonstra 
como os dados são fisicamente armazenados.
E) Alternativa correta. 
Justificativa: o modelo conceitual é uma descrição mais abstrata do banco de dados e é o ponto de 
partida para o projeto do banco de dados.
Questão 2. Durante o projeto de um banco de dados é fundamental o estudo e aplicação da 
normalização de dados. A normalização é um conjunto de passos que são aplicados e que permitem 
um armazenamento consistente e um eficiente acesso aos dados em bancos de dados relacionais. 
Esses passos reduzem a redundância de dados e as chances de se tornarem inconsistentes. No entanto, 
muitos monitores de banco de dados relacionais (SGBDs) não permitem uma abstração suficiente 
entre o projeto lógico da base de dados e a implementação física do banco de dados, e isso tem como 
consequência um desempenho fraco nas consultas mais complexas efetuadas no banco de dados. 
Nestes casos, usa-se por vezes a desnormalização para melhorar o desempenho, com o custo de 
menores garantias de consistência. 
Considerando os conceitos sobre projeto de banco de dados, examine as afirmações a seguir e 
indique a alternativa incorreta:
A) Na normalização de um banco de dados relacional, a primeira Forma Normal (ou 1FN) requer que 
todos os valores de colunas em uma tabela sejam atômicos.
B) Na normalização de um banco de dados relacional, a segunda Forma Normal (ou 2FN) requer que 
não haja dependência funcional não trivial de um atributo que não seja a chave, em parte da 
chave candidata.
C) Na normalização de um banco de dados relacional, a terceira Forma Normal (ou 3FN) requer não 
haver dependências funcionais não triviais de atributos que não sejam chave, em qualquer coisa 
exceto um superconjunto de uma chave candidata.
D) Existem outras formas de normalização de banco de dados relacional, mas que raramente são 
aplicados a banco de dados comerciais e nem sempre os SGBDs dão suporte a elas, como a quarta 
e quinta forma normal.
76
Unidade III
E) Os bancos de dados hierárquicos e em redes também necessitam que os dados sejam normalizados 
com o uso de chaves primárias e chaves estrangeiras.
Resolução desta questão na plataforma.
77
ADMINISTRAÇÃO DE BANCO DE DADOS
Unidade IV
7 ADMINISTRAÇÃO DE BANCO DE DADOS
Nas unidades anteriores, apresentamos os conceitos fundamentais necessários para o entendimento 
e a criação de um banco de dados. Na fase de concepção e criação, o administrador de banco de dados 
está mais próximo do administrador de dados. Após a implementação física do projeto de banco de dados, 
isso não significa que o trabalho acabou, muito pelo contrário, é agoraque as habilidades e experiência do 
DBA serão colocadas em prática, pois o trabalho de ajustes de desempenho (tuning) e a manutenção e a 
garantia de que tudo funcione da maneira desejada vão depender de ações contínuas desse profissional.
Os conceitos descritos a seguir serão apresentados de forma genérica, pois o ideal é seguir as recomendações 
oferecidas pelos fornecedores de banco de dados. Parece estranho, mas não é. Não adianta você comprar uma 
Ferrari, por exemplo, e estudar o manual do Gol. Se você quer tirar o máximo de proveito de todas as funcionalidades 
da Ferrari, terá que se tornar um especialista. A analogia parece absurda, mas funciona para banco de dados.
De modo geral, os SGBD costumam armazenar os dados e as estruturas de bancos de dados em 
locais e arquivos diferentes de onde são armazenadas as informações sobre as operações efetuadas 
sobre os dados e as estruturas.
Por exemplo, o SGBD Microsoft SQL Server armazena os dados em dois arquivos distintos:
• Um arquivo com a extensão mdf
– Arquivo principal do banco de dados.
– Nesse arquivo são gravados os dados e a estrutura do banco de dados.
• Um arquivo com a extenção ldf
– Arquivo de log do banco de dados.
Grava todas as operações realizadas dentro do banco de dados.
Funciona como um diário de tudo o que acontece lá dentro.
 Observação
Os fornecedores de banco de dados oferecem cursos específicos para 
capacitar os profissionais de administração de banco de dados. Nem sempre 
é uma tarefa trivial, em que basta ler um manual e seguir.
78
Unidade IV
A escolha do banco de dados da empresa é uma decisão muito delicada, na medida em que está irá 
acarretar troca de aplicativos e de hardware. Os investimentos diretamente aplicados no banco de dados 
costumam ser infinitamente menores do que aqueles a serem aplicados na empresa, visando sua perfeita 
adequação ao novo SGBD. Essa decisão, sempre que possível, deve ser tomada por especialistas em 
banco de dados, com profundos conhecimentos de análise de sistemas, de banco de dados e de software 
de gerenciamento de banco de dados, de forma a evitar que a empresa escolha um banco de dados 
inadequado aos seus propósitos e, pouco tempo depois, seja obrigada a perder todos os investimentos 
realizados em software e hardware.
7.1 Backup
O backup é considerado como uma das atividades mais importantes e críticas de administração de 
banco de dados. Consiste em fazer uma cópia de segurança (dump) dos dados e da estrutura do banco 
de dados, e das operações realizadas na linha do tempo, entre uma cópia e outra.
O backup em tempo de execução é uma característica sempre disponível em todos os tipos de SGBD, 
porém temos aplicações que invariavelmente são comprometidas por falhas de hardware e outras cujo 
mesmo tipo de falha não causa perda alguma de dados ou de integridade.
Novamente, cada SGBD tem essa característica melhor ou pior implementada, cabendo ao 
administrador de banco de dados escolher aquele que lhe oferecer mais segurança.
Normalmente, as falhas podem ser de dois tipos: soft crach e hard crash. A primeira são falhas do 
sistema (por exemplo, queda de energia) que afetam todas as transações em curso no momento, mas 
não danificam fisicamente o banco de dados. A segunda são falhas da mídia (por exemplo, queda da 
cabeça de gravação sobre o disco) que causam danos ao banco de dados ou a uma parte dele e afetam 
pelo menos todas as transações que, no momento, estão usando essa parte.
7.1.1 Recuperação e concorrência
Os problemas de recuperação e concorrência de dados estão ligados a processamento de transação.
 Lembrete
Transação é uma unidade de trabalho lógica, ou seja, é uma sequência 
de operações que transforma um estado consistente de banco de dados em 
outro estado consistente, sem que os pontos de consistência intermediários 
sejam preservados.
O sistema não deve permitir que transações sejam executadas em parte (ou seja, o programa pode 
terminar de forma anormal durante as atualizações), pois isso levaria o banco a um estado inconsistente. 
Por isso, sistemas que suportam o processamento de transação têm uma melhor forma de segurança.
79
ADMINISTRAÇÃO DE BANCO DE DADOS
Essa segurança é resumida em quatro tópicos, a saber:
• Atomicidade: ter a certeza de que uma transação foi totalmente executada ou totalmente 
cancelada. Nunca uma execução pode ficar pela metade.
• Consistência: não permanecer com estágio intermediário, deve ir de um estágio consistente a outro.
• Isolamento: uma transação, quando executada, tem que ser executada independente de outra. 
Não importa se elas estejam sendo processadas separadas ou de forma concorrente, o resultado 
terá que ser o mesmo. Existe um sistema gerenciador de transação que permite isso.
• Durabilidade: garantir que todas as transações não realizadas permaneçam no banco e sejam 
realizadas assim que o computador for reinicializado. Se, por algum problema, o computador 
desligar e o disco não for danificado, a durabilidade tem que estar funcionando.
 Observação
A atomicidade é proporcionada por meio das operações COMMIT 
e ROLLBACK.
7.1.2 Pontos de sincronização
O ponto de sincronização representa a ligação entre duas transações consecutivas, mostrando onde 
o banco de dados está (ou deveria estar) em estado de consistência. As únicas operações que apresentam 
este ponto são COMMIT e ROLLBACK.
• COMMIT: garante que a transação foi finalizada com êxito. O banco de dados (depois do término da 
transação) encontra-se em estado de consistência, e todas as suas atualizações são permanentes.
• ROLLBACK: assinala que a transação foi malsucedida. O sistema informa que algo saiu errado e 
que todas as atualizações devem ser refeitas, ou seja, elimina vestígios do que foi feito.
 Observação
As operações COMMIT e ROLLBACK terminam a transação e não o programa.
Todas as transações são acumuladas em um buffer, que, de tempo em tempo, atualiza o banco; 
caso ocorra uma queda de energia, as operações efetuadas até então são perdidas. Assim, para melhor 
segurança, é necessário que esteja presente sempre um arquivo de log.
A finalidade desse arquivo é registrar cronologicamente todas as transações realizadas, assim, 
quando houver uma falha, é possível fazer recuperação. O log, por sua vez, não pode ficar no buffer, já 
que assim que é desligado o computador, tudo o que está na memória é perdido.
80
Unidade IV
7.2 Meios de recuperação (restore)
O sistema deve ser preparado para se recuperar não só das falhas locais (danos causados apenas 
na área em que estas ocorreram), mas também das falhas globais (danos em diversas áreas, havendo 
implicações expressivas no sistema). Há duas categorias de falhas, descritas a seguir.
7.2.1 Falhas do sistema
Normalmente, são causadas por queda de energia ou desligamento do computador sem finalização 
correta, que não danificam fisicamente o banco de dados. Assim, não se terá mais conhecimento do 
momento exato da transação que estava processando, consequentemente, ela será desfeita.
Ainda há as transações que foram realizadas com sucesso, mas que não tiveram tempo de ser 
transferidas da memória intermediária do banco de dados para o banco de dados físico.
Uma maneira de se controlar é utilizando um método conhecido como check point (ponto de 
controle), de tempo em tempo o sistema faz as anotações cronológicas. Tem como objetivo:
• passar fisicamente o conteúdo das memórias intermediárias do banco de dados para o banco de 
dados físico;
• passar fisicamente o registro especial do ponto de controle para outra parte que não a anotação 
cronológica física.
Ponto de checagem
(Tempo, tc)
Falha no sistema
(Tempo, tf)
Tempo
T5
T4
T3
T2
I1
tftc
Figura 36 – Linha do tempo de uma transação RED
Nesse exemplo da figura 36, o ponto de checagem foi feito quando as transações T1 e T5 já tinham 
começado e a transação T4 já tinha acabado. A T3 começou e terminou depois do ponto de checagem, 
e a T2 começou depois e não terminou a sua execução. Neste caso,algumas terão que ser refeitas e 
outras desfeitas.
81
ADMINISTRAÇÃO DE BANCO DE DADOS
Tabela 1
Refeitas Desfeitas
T3 T1
T5 T2
As transações T3 e T5 terão que ser refeitas, pois, antes de acontecer a falha do sistema, elas já 
tinham sido finalizadas. Então, o conteúdo concluído até o ponto de checagem precisa ser confirmado 
e, assim, finalizar de forma correta a transação.
Já T1 e T2 precisam ser desfeitas, pois, quando a falha ocorreu, a sua execução não havia terminado. 
É necessário que apague tudo o que foi feito, ou seja, desfazer, para que seja reiniciada a transação.
7.2.2 Falhas dos meios físicos
São as falhas que ocorrem danificando o disco rígido, ou seja, certa parte dos dados é destruída. 
Exemplo: colapso de uma cabeça de disco ou falha no controlador de disco. É importante sempre ter 
cópia do banco (backup), pois, em uma falha dos meios, se podem perder inúmeras informações, o que 
irá trazer prejuízo ou danos ao usuário.
Nesse caso, o sistema precisa ser recriado em outra máquina. Para que o impacto dessas ações 
de reconstrução do ambiente seja o menor possível, na visão do usuário, existem diversas soluções 
que envolvem não só a substituição do disco danificado, mas todo um projeto de contingência e alta 
disponibilidade do seu ambiente como um todo.
A arquitetura do seu ambiente deve ser projetada em conjunto com a equipe de analistas de 
suporte e de redes. Projetos desse tipo costumam envolver a alta administração da organização, pois o 
investimento é alto e às vezes significa a contração de serviços de data center especializados. Tudo vai 
depender do valor dos dados da empresa e de quanto vale o risco de perder os dados.
7.3 Concorrência
Em um sistema em que existe a possibilidade de se ter inúmeras transações ocorrendo ao mesmo 
tempo, há a necessidade de um mecanismo de controle de concorrência, que assegure que uma 
transação não interfira em outra. Alguns problemas que podem surgir com a ausência deste mecanismo 
são: perda de atualização, dependência de uma transação não confirmada, análise inconsistente. Para 
evitar tamanho transtorno, é utilizado um mecanismo chamado bloqueio (lock), que permite segurança 
e consistência no banco de dados.
Para entender melhor o que significa a perda de atualizações, vamos considerar a seguinte situação: 
duas pessoas editam o mesmo registro, uma altera o telefone e outra, o endereço; ao confirmarem, 
será gravada a última atualização. Isso ocorre por não haver nenhum tipo de controle no banco, mas 
essa situação pode ser contornada configurando-se o sistema para que não libere o registro quando ele 
estiver sendo usado por outro usuário.
82
Unidade IV
O problema da dependência de uma transação não confirmada é que isso pode retornar para o 
usuário informações erradas, comprometendo muito a utilização do banco. Suponha que ocorra a 
seguinte situação: uma transação A faz um update, logo em seguida, uma transação B faz uma leitura 
no mesmo dado. Se, por algum motivo, houver um rollback na transação A, a transação B terá visto 
um dado que não mais existe, ou seja, o rollback desfez tudo da transação A, e a transação B fica 
desatualizada, oferecendo ao usuário informações inconsistentes.
No exemplo a seguir, fica clara essa situação: a transação A teve sua alteração e, antes mesmo de ela 
ser confirmada, houve um rollback, resultando na desatualização dos dados fornecidos na transação B.
Tabela 2
Transação A Tempo Transação B
UPDATE T1 -
- T2 READ
ROLLBACK T3 -
O problema da análise inconsistente: consideremos a seguinte situação em uma conta bancária:
Tabela 3
Transação A Tempo Transação B
Soma 50 T1 -
Soma 20 T2 -
- T3 READ
- T4 Transferência 
(20)
- T5 COMMIT
Total 70 T6 -
Como pode ser observado, as transações A e B estão utilizando a mesma conta bancária. A primeira 
faz a soma, e a segunda realiza uma transferência de dinheiro. O total da transação A retornará um 
resultado inconsistente, pois os dados alterados pela transação B não foram atualizados, e como ocorreu 
o commit (confirmação da transferência), a conta não teve o devido débito.
7.4 Bloqueio (Lock)
Havendo duas transações, com ambas precisando do mesmo dado, elas deverão ser executadas uma 
após a outra; isso é possível quando se utiliza a técnica do bloqueio.
Existem dois tipos de bloqueios:
• Bloqueio compartilhado: pode haver inúmeras pessoas utilizando o mesmo dado. Quando uma 
transação B solicita um dado que está sendo utilizado pela transação A, B fica em estado de 
espera até que A libere o bloqueio.
83
ADMINISTRAÇÃO DE BANCO DE DADOS
• Bloqueio exclusivo: ninguém mais tem acesso àquele dado.
Todas as operações de banco de dados geram bloqueios, até mesma a leitura.
 Observação
Não pode haver dois bloqueios exclusivos nem um compartilhado e 
exclusivo, senão não é exclusivo.
A técnica do bloqueio pode resolver os problemas encontrados na concorrência. Como foi visto, se 
um mesmo registro estiver sendo utilizado ao mesmo tempo por usuários diferentes, e estes, por sua 
vez, fizerem alterações nele, permanecerá a última mudança feita. Com o bloqueio, as transações A e 
B podem utilizar o mesmo registro, sendo que o último a solicitar os dados permanece em estado de 
espera, embora haja desta forma um conflito entre os bloqueios gerado pelas transações.
Por razões análogas, a transação que primeiro utilizava o registro entra em estado de espera, e a 
outra transação é executada. E assim temos um problema que o bloqueio traz: o impasse, em que as 
duas transações são incapazes de prosseguir, eliminando desta forma a perda de atualização.
Outro cenário possível é quando a transação B solicita um registro que está sendo utilizado pela 
transação A, nesse caso, a transação B entra em estado de espera. Enquanto A não alcançar o ponto 
de sincronismo (ROLLBACK ou COMMIT), B não é liberado para prosseguir. Assim que A terminar sua 
execução, B é liberado e, neste ponto, ele já pode obter um valor confirmado pela transação anterior, 
seja por ROLLBACK ou por COMMIT, mas, de qualquer maneira, B não dependerá de uma atualização 
não confirmada.
Se uma transação A está em bloqueio compartilhado, e B solicita implicitamente um bloqueio 
exclusivo no mesmo registro, B fica em estado de espera até que A libere. Assim que liberado, a 
transação A não consegue mais ser executada, pois a solicitação implícita de bloqueio compartilhado 
entra em conflito com o bloqueio exclusivo feito por B, forçando um impasse no qual ambos ficam 
na espera.
 Observação
Impasse é uma situação em que as transações ficam paradas à espera da 
outra para liberar bloqueio. Isso pode acontecer com várias transações, não 
necessariamente com duas. Quando houver um impasse, é necessário que 
o sistema detecte, liberando os bloqueios, permitindo assim que continue a 
transação. A maneira como será feito isso, o programador resolverá, mas é 
importante que o usuário não tenha conhecimento disso.
84
Unidade IV
7.5 Arquitetura básica do ambiente de banco de dados
Você pode ter um ambiente de alta disponibilidade e desempenho por meio da arquitetura de hardware 
combinada com os recursos de software. As técnicas básicas envolvem dois conceitos: cluster e replicação.
Cluster é nome dado a um conjunto de computadores ligados em rede que funcionam como se 
fossem um único computador, compartilhando recursos de memória, armazenamento e processamento. 
Essa técnica faz parte do plano de contingência e alta disponibilidade, pois você pode desenvolver o seu 
projeto de banco de dados distribuídos.
7.5.1 Cluster de alto desempenho
Também conhecido como cluster de alta performance, ele funciona permitindo que ocorra uma 
grande carga de processamento com um volume alto de gigaflops em computadores comuns.
7.5.2 Cluster de alta disponibilidade
São clusters cujos sistemas conseguem permanecer ativos por um longo período de tempo e em 
plena condição de uso. Pode-se dizer que eles nunca param seu funcionamento, além disso, conseguem 
detectar erros,protegendo-se de possíveis falhas.
7.5.3 Cluster para balanceamento de carga
Esse tipo de cluster tem como função controlar a distribuição equilibrada do processamento. Requer 
um monitoramento constante na sua comunicação e em seus mecanismos de redundância, pois, se 
ocorrer alguma falha, haverá uma interrupção no seu funcionamento.
Figura 37 – Exemplo de esquema de um cluster
85
ADMINISTRAÇÃO DE BANCO DE DADOS
7.6 Replicação
Replicação de banco de dados é a cópia dos dados do banco de dados original para outro banco de 
dados. São vantagens da replicação em banco de dados:
• sistema menos sensível a falhas, por causa da redundância;
• trabalho com balanceamento da carga;
• backup on-line dos dados.
A replicação de banco de dados também pode ser usada para garantir a integração e a integridade 
entre os bancos de dados de sistemas com modelo de dados relacional distribuídos. Nesse caso, o 
sistema gerenciador de replicação de dados precisa ser capaz de replicar as transações em tempo real. 
Geralmente, os servidores de replicação só conseguem replicar uma imagem do banco (snapshot), 
portanto, não dá para implementar uma arquitetura desse tipo.
 Saiba mais
Para conhecer essa solução, recomendamos a leitura do case de sucesso 
da USP, que está disponível no site da Sybase por meio do link <http://
www.sybase.com.br/files/Success_Stories/USP_Replication_Server.pdf>. 
Acesso em: 14 jun. 2012.
7.6.1 Replicação síncrona (eager)
A transação só é concluída após todos os servidores fazerem commit. É conhecida como phase 2 
commit, ou seja, o commit é realizado em duas fases. Apesar de garantir consistência de transação entre 
servidores, é de baixa escalabilidade. Outra característica dessa arquiteta é a indisponibilidade em caso 
de queda de rede. Foi muito pesquisada nos últimos dez anos, várias implementações foram realizadas, 
mas é considerada impraticável para a maioria dos ambientes de produção por ser de altíssimo custo e 
de difícil manutenção.
7.6.2 Replicação assíncrona (lazy)
A transação é concluída localmente e depois replicada, portanto, com alta escalabilidade. 
Não garante consistência de transação direta entre os servidores. Para ter essa consistência, a 
implementação deve ser modelada e implementada de tal forma que garanta essa consistência. 
É de baixo custo e resistente a quedas de rede. Esse tipo de replicação foi implementado na USP 
e é usado até hoje.
86
Unidade IV
7.6.3 Replicação unidirecional (master-slave)
A replicação é realizada sempre no mesmo e único sentido, de um banco de dados A para um banco 
de dados B. É usado normalmente para hot-backup de servidores de banco de dados e também utilizado 
para melhoria de desempenho de consultas em sites remotos. Apenas a base master recebe atualizações. 
Pouco sujeito a inconsistências, mesmo no modelo lazy.
7.6.4 Replicação multidirecional (multi-master)
A replicação é realizada em vários sentidos. Usada para garantir alta disponibilidade e garantir melhor 
desempenho tanto em consultas quanto em atualizações. Todas as bases podem receber atualizações. 
Sujeito a inconsistências no modelo lazy.
7.6.5 Exemplo de funcionamento de um cluster com replicação
Na figura a seguir, temos uma estrutura em cluster de alta disponibilidade, em que os servidores de 
banco de dados estão em uma estrutura de replicação master-slave.
Aplicação
Leitura e 
gravação
Replicação
Master_db Slave_db
Figura 38 – Estrutura de cluster
Suponha que o servidor principal (master) de banco de dados apresente alguma falha e o torne 
indisponível. Existem diversos softwares por meio dos quais você consegue configurar o monitoramento 
da comunicação entre os servidores. Assim que for detectada a falha de comunicação, ela deve ser 
redirecionada automaticamente para conectar com o servidor replicado; em alguns minutos, a aplicação 
começará a funcionar a partir do servidor (slave).
Leitura e gravação
Aplicação
Replicação
Master_db Slave_db
Figura 39
87
ADMINISTRAÇÃO DE BANCO DE DADOS
8 MODELO DIMENSIONAL
A modelagem dimensional é uma técnica voltada especialmente para a implementação de um 
modelo que permita a visualização de dados de forma intuitiva e com altos índices de performance na 
extração de dados. É a técnica de projeto mais utilizada para a construção de data warehouses (DW), que 
busca um padrão de apresentação dos dados de fácil visualização pelo usuário final e bom desempenho 
para consultas.
O modelo dimensional, ou multidimensional, detecta os relacionamentos inerentes aos dados para 
armazená-los em matrizes multidimensionais conhecidas como cubo de dados ou hipercubo, caso o 
cubo possua mais de três dimensões, conforme a figura a seguir:
Figura 40 – Representação gráfica de um cubo de dados
Permite que os dados sejam consultados diretamente em qualquer combinação de dimensões, sem 
a necessidade de consultas complexas no banco de dados.
Ferramentas próprias proporcionam a visualização dos dados de acordo com as dimensões escolhidas 
pelo usuário.
88
Unidade IV
O modelo dimensional é composto por uma tabela dominante, com múltiplas junções, chamada de 
tabela de fatos, e de um conjunto de tabelas conhecidas como tabelas de dimensão.
Tipos de esquema do modelo dimendisional:
• Esquema estrela (star schema): é um dos mais usados na modelagem dimensional e consiste 
em uma tabela de fatos central e uma tabela para cada dimensão.
• Esquema floco de neve (snowflake): é uma variação do esquema estrela em que algumas 
tabelas de dimensão são normalizadas, criando-se uma tabela de dimensão secundária cuja chave 
se torna estrangeira na tabela de dimensão primária. Essa técnica interfere no entendimento dos 
dados pelo usuário e na performance de algumas consultas, portanto, não deve ser usada como 
regra geral, embora às vezes possa ser interessante ou até necessária.
8.1 Fatos
Os fatos são os atributos do comportamento. São medidas de ações que ocorrem entre diferentes 
objetos ou dimensões. Em geral, são numéricos ou aditivos (podem ser somados) e raramente textuais.
A tabela de fatos é a tabela principal de um modelo dimensional. É formada por uma chave, 
composta pelas chaves das dimensões relacionadas e de um ou mais fatos mensuráveis, ou medidas, em 
geral numéricas, para cada conjunto das dimensões. Observe-se que muitas vezes não existe um valor 
associado para um cruzamento de dimensões.
O fato representa uma medição do negócio, isto é, fato é tudo aquilo que pode ser medido. A lista 
de dimensões define a granularidade da tabela de fatos (qual é o escopo da medição).
As características básicas de um fato são:
• variam ao longo do tempo;
• tem valores numéricos;
• seu histórico cresce com o passar do tempo.
Uma linha da tabela de fato corresponde a uma medição. Uma medição é uma linha da tabela de 
fatos. Todas as tabelas de fatos estão alinhadas com a mesma granularidade. As medições dos fatos 
devem ser numéricas e aditivas. As tabelas de fato representam relações N:N. As medidas podem ser 
classificadas em:
• Valores aditivos: medidas em que podem ser aplicados os operadores, tais como soma, porcentagem 
etc. Faz sentido adicioná-los continuamente e sobre todas as dimensões, por exemplo, vendas em 
R$ e vendas em unidades.
89
ADMINISTRAÇÃO DE BANCO DE DADOS
• Valores não aditivos: medidas que não podem ser manipuladas livremente, como porcentagtem 
ou valores relativos, tais como temperatura e condição do tempo.
8.2 Dimensão
As dimensões descrevem pessoas, lugares e coisas relacionadas a um negócio. As tabelas de dimensão são 
formadas por uma chave primária e por atributos que a descrevem. Quanto maior o tempo dedicado à descrição 
dos atributos, ao preenchimento dos seus valores e à garantia da qualidade dos dados, melhor será o DW.
Cada dimensão tem sua própria granularidade, que não pode ser menor que da tabela de fatos, mas 
pode ser maior.
Dimensões determinam o contexto em que ocorreram os fatos. No modelo dimensional, cada 
dimensão está associada a um oumais fatos, sendo estas usualmente mapeadas em entidades não 
numéricas e informativas. As dimensões contêm descritores textuais da empresa.
As tabelas de dimensão são pontos de entrada para a tabela de fatos. Atributos de dimensões eficazes 
produzem recursos analíticos eficientes. As dimensões implementam a interface de usuário para o DW.
• maioria dos fatos envolve pelo menos quatro dimensões básicas: onde, quando, quem e o quê:
• dimensão onde determina o local em que o fato ocorreu (local geográfico, filial);
• dimensão quando é a própria dimensão tempo;
• dimensão quem determina quais entidades participaram do fato (cliente, fornecedor, funcionário);
• dimensão o quê determina qual é o objeto do fato (produto, serviço).
 Observação
Existem casos em que algumas dimensões podem conter milhões de 
entradas, por exemplo, a dimensão cliente em uma companhia telefônica; 
neste caso, a navegação por essa dimensão pode tornar-se demorada. Pode-
se, neste caso, utilizar índices nos atributos que sejam objetos de navegação.
Frequentemente, os campos mais utilizados em uma dimensão grande possuem um domínio pequeno, 
ou seja, assumem uma pequena quantidade de valores. Em uma dimensão cliente, esses atributos podem 
ser atributos demográficos, como sexo, faixa etária e classe social. Neste caso, pode-se optar pela criação 
de uma minidimensão separada da dimensão cliente para aumentar a eficiência da navegação.
Atributos como o número da nota fiscal de venda, aparentemente, deveriam fazer parte da tabela de 
fatos. Em um banco de dados relacional, ele seria o atributo determinante do cabeçalho da nota fiscal. 
Em um banco de dados dimensional, normalmente todos os atributos determinados pelo número da nota 
90
Unidade IV
foram armazenados em dimensões próprias e fariam parte da chave primária dos itens da nota. Ainda 
assim, pode-se utilizar esse atributo para agrupar os fatos pelo documento original. Atributos desse tipo 
são representados como dimensões degeneradas (descaracterizadas), isto é, chaves de dimensão sem 
uma dimensão correspondente.
8.2.1 Chave artificial (surrogate key)
Utilizar uma chave candidata como chave primária de uma dimensão pode causar problemas caso esta 
chave não seja absolutamente estável ao longo do tempo. Uma modificação em uma chave de uma dimensão 
pode ocasionar um grande volume de mudanças nas tabelas de fato relacionadas a essa dimensão.
A solução para esse problema é utilizar chaves artificiais absolutamente estáveis ao longo do tempo. 
Uma chave artificial é um campo inteiro e autoincremental, que aumenta a cada novo registro incluído 
na tabela de dimensão.
8.3 Medidas
Medidas são atributos que quantificam um determinado fato, representando o desempenho de um 
indicador em relação às dimensões que fazem parte do fato. O contexto de uma medida é determinado 
em função das dimensões do fato (MACHADO, 2000).
8.4 Granularidade
A granularidade é o nível de detalhe de um banco de dados dimensional. É um dos pontos mais 
importantes no projeto de um DW porque:
• refere-se ao nível de detalhe em que serão armazenados os dados no DW, quanto maior o 
detalhamento, mais baixo o nível de granularidade;
• afeta o volume de dados do DW e, portanto, a performance na extração de informações.
Um DW pode ser implementado em níveis duais de granularidade ao longo do tempo. É possível 
manter as informações mais recentes em um baixo nível de granularidade, aumentando assim as 
possibilidades de extração de informações. À medida que os dados vão ficando obsoletos, é possível 
resumi-los em um alto nível de granularidade de forma a manter a performance.
 Observação
A granularidade define o nível de detalhe dos dados existentes no DW. 
Quanto maior o nível de detalhes, mais baixo o nível de granularidade e 
vice-versa. Ela determina o volume de dados do DW e o tipo de consulta 
que pode ser atendida.
91
ADMINISTRAÇÃO DE BANCO DE DADOS
Granularidade alta:
• Economia de espaço em disco.
• Redução na capacidade de atender consultas.
Granularidade baixa:
• Grande quantidade de espaço em disco.
• Aumento na capacidade de responder a qualquer questão.
Quadro 1
Fatos Dimensões Medidas
Representam um item, transação ou 
evento de negócio.
Determinam o contexto de um assunto 
de negócios, como uma análise de 
vendas de produtos.
São os atributos numéricos 
que representam um fato e são 
determinadas pela combinação das 
dimensões que participam dele.
Refletem a evolução dos negócios. São os balizadores de análise de dados.
Representam o desempenho de um 
indicador de negócios relativo às 
dimensões que participam de um fato.
São representados por conjuntos 
de valores numéricos (medidas) que 
variam ao longo do tempo.
Normalmente não possuem atributos 
numéricos, pois são somente 
descritivas e classificatórias dos 
elementos que participam de um fato.
Podem possuir uma hierarquia de 
composição de seu valor.
8.5 Agregados
Agregados são resumos construídos a partir de fatos individuais, inicialmente por questões de 
performance, ou quando o ambiente dos fatos é inexpressivo na menor granularidade. Agregados 
permitem que as aplicações antecipem os resultados a serem pesquisados pelo usuário, eliminando a 
necessidade de se repetirem cálculos comumente realizados.
Múltiplos agregados podem ser construídos, representando os agrupamentos mais comuns dentro 
das dimensões do DW a fim de aumentar a performance. A contrapartida ao aumento da performance 
é a elevação do consumo de espaço de armazenamento.
 Observação
Resumos armazenados com o objetivo de melhorar o desempenho 
de consultas, o agregado é composto por registros na tabela de fatos 
que representam o resumo do registro de nível básico da tabela de fatos, 
associados a registros agregados das dimensões.
92
Unidade IV
8.6 Passos do projeto de DW
1) Decidir qual(is) processo(s) do negócio devemos modelar, por meio da combinação do conhecimento 
do negócio com o conhecimento dos dados que estão disponíveis.
2) Definir o grão do processo do negócio. O grão é o nível fundamental atômico de dados que 
representará o processo na tabela de fatos.
3) Escolher as dimensões que serão aplicadas a cada registro da tabela de fatos. Para cada dimensão 
escolhida, descrever todos os diferentes atributos de dimensão (campos) que preencham cada 
tabela dimensional.
4) Escolher os fatos mensuráveis que irão popular cada registro da tabela de fatos. Fatos mensuráveis 
são quantidades numéricas aditivas, como quantidade vendida e vendas (em espécie).
Funcionalmente, o processo de data warehousing engloba três etapas:
• extração dos dados operacionais de diversas fontes (banco de dados, planilhas, arquivos 
convencionais etc.);
• organização e integração dos dados em um banco de dados, o DW;
• acesso aos dados integrados de forma eficiente e flexível pelo usuário final.
Fontes de dados: dados extraídos, em geral, do ambiente operacional da empresa para o 
ambiente de tomada de decisões. Podem estar armazenados em bancos de dados de vários modelos, 
planilhas eletrônicas (Excel, por exemplo), arquivos convencionais ou até em documentos e textos. 
Podem ser inclusive externos à organização, por exemplo, indicadores econômicos.
Área de transporte de dados (data staging area): representa a área intermediária de 
armazenamento entre as fontes de dados e o DW, onde é implementado o processo de ETL (Extract, 
Transform and Load – extração, transformação e carga/atualização).
Os dados são extraídos do ambiente operacional para a área de transporte. São 
transformados quando necessário, para uniformizar formatos e conteúdos como: dados 
iguais com nomes diferentes, duplicação de dados, codificações distintas para o mesmo 
dado etc. A transformação inclui o processo de limpeza, que elimina erros nos dados. Em 
seguida, são carregados no DW. Existem ferramentas ETL (back-end) para implementar esses 
processos, tanto gratuitas quanto pagas.
93
ADMINISTRAÇÃO DE BANCO DE DADOS
Figura 41 – Ferramentade ETL Pentaho
 Saiba mais
Para conhecer mais sobre a ferramenta Open Source Pentaho, 
recomendamos os sites:
<www.pentaho.com>
<kettle.pentaho.com>
<community.pentaho.com/projects/bi_platform>
<softwarelivre.org/pentaho>
<pentahobrasil.org>
Servidor de apresentação: máquina física de destino onde os dados do DW são organizados e 
armazenados para acesso direto pelos usuários finais, geradores de relatório e outras aplicações.
Três sistemas bem distintos são necessários para o funcionamento de um DW: o sistema fonte, a 
área de transporte de dados e o servidor de apresentação.
Se esse servidor for um banco de dados relacional, as tabelas serão organizadas em esquemas 
estrela. Como a maioria das grandes implementações tem sido em bancos relacionais, a maior parte das 
discussões específicas do servidor de apresentação é direcionada nesse sentido.
Processo de negócio: conjunto coerente de atividades de negócio que fazem sentido aos usuários 
dos nossos DW. Essa definição é propositalmente um pouco vaga. Neste contexto, assumimos que um 
94
Unidade IV
processo de negócio é um agrupamento útil de recursos de informação com um tema coerente. Em 
muitos casos, implementaremos um ou mais datamarts para cada processo de negócio.
Armazenamento de dados operacionais – ODS (Operational Data Store): esse conceito tem 
tido muitas definições para ser útil. Essencialmente, pode representar um sistema operacional separado 
servindo como ponto de integração entre diversos sistemas operacionais ou contendo dados integrados 
em nível detalhado, que seria na verdade parte do DW.
Olap (On-line Analytic Processing): processamento analítico on-line é um conjunto de princípios 
vagamente definidos que fornecem uma estrutura dimensional de suporte à tomada de decisões 
(consulta e apresentação de textos e dados numéricos). O termo OLAP também é usado para definir um 
grupo de fornecedores que oferecem produtos de bancos de dados multidimensionais e não relacionais 
orientados ao suporte à tomada de decisões.
 Saiba mais
Rolap: Relational-Olap (implementada em banco de dados relacional).
Molap: Multidimensional-Olap (implementada sem depender de banco 
de dados relacional).
Dolap: Desktop-Olap (utiliza os recursos da máquina cliente, portanto, 
é extremamente limitada).
8.7 Data mart (DM)
O data mart é uma parte do DW. Dentro de uma empresa, enquanto o DW armazena os dados da 
empresa inteira, o DM armazena os dados de um único departamento, por exemplo.
É um subconjunto lógico de um DW. Tem escopo limitado, para atender a uma determinada área ou 
processo do negócio. Representa um projeto que pode vir a ser completado e não um empreendimento 
galático. Um DW é composto pela união de todos os seus DM.
Estabelecemos certos requisitos específicos para cada DM: deve ser representado por um modelo 
dimensional e dentro de um mesmo DW. Todos esses DM devem ser construídos a partir de dimensões 
e fatos conformes, que têm o mesmo significado em todas as tabelas.
8.8 Ferramentas de acesso aos dados
Possibilitam a exploração do DW pelo usuário final. Variam de simples ferramentas de consultas ad 
hoc e geradores de relatórios, aplicações para usuários finais que acessem os dados do DW, a ferramentas 
de análises sofisticadas para Olap e mineração de dados.
95
ADMINISTRAÇÃO DE BANCO DE DADOS
Ferramentas de consultas ad hoc permitem ao usuário formular suas próprias consultas, manipulando 
diretamente os dados cadastrados.
EIS – Executive Information Systems: sistemas que examinam uma perspectiva ampla dos dados 
e oferecem informações comparativas e claras para tomada de decisões.
Mineração de dados (data mining): técnicas e ferramentas de análise de dados com a função de 
descobrir e entender tendências, comportamentos, anomalias e outras relações entre os dados.
Olap – On-line Analytical Processing: é uma “categoria da tecnologia de software que permite 
que os analistas, gerentes e executivos obtenham, de maneira rápida, consistente e interativa, o acesso 
a uma variedade de visualizações possíveis da informação” (INMOM et al., 2005).
Key performance: indicador-chave de desempenho. Serve para acompanhar o desempenho de uma 
métrica. Para isso, necessita de outra métrica para servir de base, por exemplo, meta VS realizado. São 
exibidos para os usuários na forma de semáforos, conta-giros, termômetros ou figuras que sirvam para 
chamar bem a atenção, conforme a figura a seguir.
Figura 42
Dashboard é uma página que combina diversas informações a respeito de um mesmo tema. Essas 
informações são apresentadas de formas diferentes. Em um mesmo dashboard, podem coexistir 
relatórios, gráficos e KPis.
A seguir, um exemplo de dashboard.
96
Unidade IV
Figura 43
Esse dashboard, para quem gosta de acompanhar a Champions League, o campeonato de futebol 
europeu, fornece, além de resultados de jogos, classificação de times e várias outras estatisticas sobre 
os times e seus jogadores.
 Resumo
A importância dos sistemas de bancos de dados nas organizações 
é vista pela crescente valorização dos bancos de dados e dos sistemas 
gerenciadores de bancos de dados, o que gera consequentes investimentos 
em técnicas de gerenciamento, monitoramento, backup e restauração 
de dados e em todo o processo que envolve a importância financeira 
de manter a integridade dos bancos de dados. Um problema muito real 
refere-se ao gerenciamento de todas as contas bancárias em sistemas de 
arquivos permanentes de um determinado banco. Esse sistema possui 
uma série de programas aplicativos necessários para a manipulação por 
parte dos usuários, que permitem:
• débito e crédito em outra conta;
• um programa para adicionar uma nova conta;
• fazer pagamentos e depósitos;
• calcular aplicações;
• inserir novas alíquotas.
97
ADMINISTRAÇÃO DE BANCO DE DADOS
Esses aplicativos só foram desenvolvidos porque surgiram problemas e 
necessidades da organização bancária, e isso significa um processo contínuo, 
pois as aplicações são desenvolvidas conforme vão surgindo as necessidades.
O ambiente de data warehouses (DW) integra informações provenientes 
de uma grande variedade de bancos de dados operacionais em um único 
banco de dados lógico, que pode ser visto como um repositório central 
desenvolvido para facilitar o processo de suporte à decisão. Segundo 
Inmom et al. (2005), DW é uma coleção de dados orientados por assuntos, 
integrados, não voláteis e variáveis com o tempo, para suporte ao processo 
gerencial de tomada de decisão.
Como se trata de uma implementação estratégica, o DW deve utilizar 
equipamentos de tecnologia aberta, para não deixar a empresa atrelada a 
um único fornecedor, isso para não criar uma dependência tanto no caso 
de implementação tecnológica como na manutenção e suporte.
Um DW corporativo constitui a modalidade mais robusta. São 
soluções geralmente adotadas por grandes corporações que justifiquem 
o porte desse tipo de solução (maiores que 100 Gb), dois a três anos para 
a implementação e investimentos na ordem de seis a sete milhões de 
dólares. Atualmente, esse custo pode ser reduzido de forma substancial 
com a adoção de soluções open source. A escolha da modalidade de DW 
deve considerar outros aspectos, como: custo, tempo de desenvolvimento, 
ferramenta e consultoria.
 Exercícios
Questão 1. A Administração de Banco de Dados é um conjunto de atividades responsáveis pela 
manutenção e gerenciamento de um banco de dados. O profissional que executa essas atividades é 
chamado de DBA (DataBase Administrator). O DBA é responsável também pela criação de backups, que 
servem para a recuperação de dados, caso ocorram problemas no hardware ou nos sistemas SGBDs. Todos 
os arquivos que contêm os bancos de dados são de responsabilidade do DBA que, além de guardar os 
arquivos, visa zelar pelas condições dos mesmos, pela segurança dos dados, acessibilidade, desempenho 
das máquinas e processos e no desenvolvimento de equipe de testes de todo o planejamento de banco 
de dados. Na prática,busca a melhor maneira de organizar, selecionar e armazenar todos os dados, 
avaliando não somente a parte técnica, mas as pessoas que irão utilizá-los. 
Considerando os conceitos sobre a Administração de Banco de Dados, examine as afirmações a 
seguir e indique a alternativa incorreta:
A) O DBA altera e testa todos os procedimentos antes de abrir acesso dos dados aos seus usuários ou 
aplicativos, bem como gerenciar o direito de acesso de cada setor e pessoa.
98
Unidade IV
B) O banco de dados deve ser simples e eficaz, para isso é necessário o trabalho de um administrador 
de dados que saiba projetar, instalar, atualizar, modificar, proteger e consertar erros na plataforma 
e nos bancos de dados. 
C) Na Administração de Banco de Dados há o trabalho de personalização e suporte de todo conteúdo 
de um determinado banco de dados.
D) Na área comercial, institucional e social há grande demanda por profissionais de Banco de Dados 
que atuam em sistemas de lojas, catálogos, serviços de comunicação, finanças, educacional e 
demais áreas.
E) As áreas de TI mais modernas utilizam ferramentas de automação em BD e vêm eliminando a 
necessidade de pessoas especializadas em Banco de Dados, tal como os profissionais denominados 
de DBAs.
Resposta correta: alternativa E.
Análise das alternativas
De acordo com os autores e especialistas em TI, nos dias de hoje, é praticamente impossível imaginar 
um cenário no qual uma aplicação ou sistema de aplicações não precise em ao menos uma de suas 
etapas consultar, manipular ou armazenar as informações resultantes dos seus processos lógicos. 
De nada adiantaria todo o poder de processamento dos computadores atuais, as redes de altíssima 
velocidade e os softwares desenvolvidos com tecnologia de ponta se não fosse possível armazenar os 
dados de forma eficiente e segura. Os dados precisam estar disponíveis, consistentes, íntegros, definidos, 
confiáveis, compartilhados e em segurança para que as decisões gerenciais sejam ágeis, precisas e 
oportunas. Dentro desse contexto é que entra o Administrador de Banco de Dados.
A) Alternativa correta. 
Justificativa: o DBA é responsável por auxiliar na modelagem de dados, na validação dos modelos de 
dados e na integração dos modelos com modelos corporativos.
B) Alternativa correta. 
Justificativa: o DBA é responsável por definir e manter padrões e normas de segurança, instalar e 
manter SGBDs e criar e manter instâncias de banco de dados.
C) Alternativa correta.
Justificativa: na Administração de Banco de Dados é necessário que o DBA acompanhe os tempos 
das consultas e administre os backups e espaços utilizados pelas aplicações usuárias do Banco de Dados 
da empresa.
99
ADMINISTRAÇÃO DE BANCO DE DADOS
D) Alternativa correta. 
Justificativa: como as bases de dados corporativas estão crescendo intensamente e tornando-se 
cada vez mais importantes como fontes de informações necessárias à operacionalização das empresas 
e também como fontes de informações para o processo de tomada de decisão, torna-se necessário o 
papel do Administrador de Banco de Dados, que deve ser um profissional especialista, capacitado para 
entender e prestar suporte técnico em cada SGBD utilizado pela organização.
E) Alternativa incorreta. 
Justificativa: o DBA é o responsável pela “saúde física” dos dados, isto é, pela manutenção e 
refinamento dos bancos de dados corporativos. Não existe, na atualidade, sistemas de Banco de Dados 
que prescidem de um Administrador de Banco de Dados.
Questão 2. Gerentes e executivos das organizações nacionais e internacionais necessitam de 
recursos computacionais que forneçam subsídios para apoio ao processo de decisão, sobretudo nos 
níveis tático e estratégico das organizações. A tecnologia Data Warehouse (DW) surgiu em meio às 
dificuldades que as organizações passaram a sentir pela quantidade de dados que suas aplicações 
estavam gerando e à dificuldade de reunir estes dados de forma organizada e consolidada para uma 
análise mais eficiente. A idéia do DW é reunir em um único local somente os dados considerados úteis 
para as tomadas de decisão. Diante desta necessidade, empresas têm utilizado os DWs para auxiliar nos 
processos corporativos de tomada de decisão. 
Considerando os conceitos sobre DWe, examine as afirmações a seguir e indique a alternativa incorreta:
A) Conceitualmente, um DW é um conjunto de dados baseado em assuntos, integrado, não volátil, 
variável em relação ao tempo, e destinado a auxiliar em decisões de negócios.
B) Um DW, quando é orientado a um assunto, aliado ao aspecto de integração permite reunir dados 
corporativos em um mesmo ambiente de forma a consolidar e apresentar informações sobre um 
determinado tema.
C) Cada conjunto de dados, ao ser carregado em um DW, fica vinculado a um rótulo temporal que o 
identifica dentre os demais.
D) Na medida em que um DW vai sendo carregado com as visões sumarizadas dos dados operacionais 
em um determinado período, podem-se realizar análises de tendências a partir dos dados.
E) As diferenças entre um DW e bases de dados operacionais está no fato de que uma base de dados 
operacional é um banco de dados clássico que contém informações detalhadas e consolidadas a 
respeito do negócio em nível transacional.
Resolução desta questão na plataforma.
100
FIGURAS E ILUSTRAÇÕES
Figura 1
PETERCHEN.JPG. Disponível em: <http://www.csc.lsu.edu/~chen/>. Acesso em: 5 jul. 2012.
Figura 43
DASHBOARD.JSP. Disponível em: <http://www.tablerochampions.com/site/champions/dashboard.jsp>. 
Acesso em: 15 jul. 2012.
REFERÊNCIAS
Textuais
BEAULIEU, A. Aprendendo SQL. 1. ed. São Paulo: Novatec, 2010.
BOOCH, G.; RUMBAUGH, J. JACOBSON, I. UML – Guia do usuário. 13. ed. Rio de Janeiro: Elsevier, 2000.
CHU, S. Y. Banco de dados: organização, sistemas e administração. São Paulo: Atlas, 1983.
DATE, C. J. Introdução a sistemas de bancos de dados. Tradução da 7. ed. americana de Vandenberg 
Dantas de Souza. Rio de Janeiro: Campus, 2000.
ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados: fundamentos e aplicações. 4. ed. São Paulo: 
Pearson, 2005.
HERRENO, E. Balanced scorecard e a gestão estratégica: uma abordagem prática. Rio de Janeiro: 
Elsevier, 2005.
HUBBARD, D. W. Como mensurar qualquer coisa encontrando o valor do que é intangível nos 
negócios. Tradução de Ebréia de Castro Alves. Rio de Janeiro: Qualitymark, 2008.
INMON, W. Building the DataWarehouse, 4. ed. New Jersey, USA: John Wiley and Sons, 2005.
KIMBALL, R.; CASERTA, J. The Datawarehouse ETL toolkit. Boulder Creek, USA: Kimball Group, 2004.
KIMBALL, R.; ROSS, M. The DataWarehouse Toolkit. New Jersey, USA: John Wiley and Sons, 2002.
LEME FILHO, T. BI – Business Intelligence no Excel. Rio de Janeiro: Novaterra, 2012.
MACHADO, F. N. R. Projeto de Data Warehouse. São Paulo: Érica, 2000.
___. Banco de dados: projeto e implementação. São Paulo: Érica, 2004.
101
ROLDÁN, M. C. Pentaho 3.2 Data Integration Beginner´s Guide. Birmingham, UK: Packt Publishing, 
2010.
SILBERSCHATZHENRY, A.; KORTHS, H. F.; SUDARSHAN, S. Sistema de banco de dados. 5. ed. Rio de 
Janeiro: Campus, 2006.
SIMCSIK, T.; POLLONI, E. G. F. Tecnologia da informação automatizada. São Paulo: Berkeley, 2002.
Sites
<http://certificacaobd.com.br>
<http://silasmendes.com/dba>
<http://www.mcdbabrasil.com.br>
<http://www.sybase.com/resources/blogs>
<http://dbaforums.org/oracle>
<www.kimballgroup.com>
<education.oracle.com>
<www.prometric.com>
<www.microsoft.com/learning>
<http://demo.phpmyadmin.net/master-config>
<http://nosql-database.org>
<http://softwarelivre.org>
<http://www.softwarelivre.gov.br>
102
103
104
105
106
107
108
Informações:
www.sepi.unip.br ou 0800 010 9000