Planejamento-e-Elaboracao-de-Bases-de-Dados-LIVRO (1)

Prévia do material em texto

Curso de Bacharelado em 
Biblioteconomia na Modalidade 
a Distância
José Simão de Paula Pinto
Planejamento e Elaboração 
de Bases de Dados
C
u
rso
 d
e B
ach
arelad
o
 em
 B
ib
lio
teco
n
o
m
ia
n
a M
o
d
alid
ad
e a D
istân
cia
Plan
ejam
en
to
 e Elab
o
ração
 
d
e B
ases d
e D
ad
o
s
José Sim
ão de Paula Pinto
Se
m
e
stre
8
Semestre
8
José Simão de Paula Pinto
Curso de Bacharelado em Biblioteconomia 
na Modalidade a Distância
Planejamento e Elaboração 
de Bases de Dados
2018
Brasília, DF Rio de Janeiro
Faculdade de Administração 
e Ciências Contábeis
Departamento 
de Biblioteconomia
Semestre
8
Permite que outros remixem, adaptem e criem a partir do seu trabalho para fins não 
comerciais, desde que atribuam o devido crédito ao autor e que licenciem as novas 
criações sob termos idênticos.
Presidência da República
Ministério da Educação
Coordenação de Aperfeiçoamento de Pessoal de Nível 
Superior (CAPES)
Diretoria de Educação a Distância (DED)
Sistema Universidade Aberta do Brasil (UAB)
Universidade Federal do Rio de Janeiro (UFRJ)
Núcleo de Educação a Distância (NEAD)
Faculdade de Administração e Ciências Contábeis (FACC)
Departamento de Biblioteconomia
Leitor
Leobino Nascimento Sampaio
Comissão Técnica
Célia Regina Simonetti Barbalho 
Helen Beatriz Frota Rozados
Henriette Ferreira Gomes
Marta Lígia Pomim Valentim
Comissão de Gerenciamento
Mariza Russo (in memoriam)
Ana Maria Ferreira de Carvalho 
Maria José Veloso da Costa Santos
Nadir Ferreira Alves
Nysia Oliveira de Sá
Equipe de Apoio
Eliana Taborda Garcia Santos
José Antonio Gameiro Salles 
Maria Cristina Paiva
Miriam Ferreira Freire Dias
Rômulo Magnus de Melo
Solange de Souza Alves da Silva
Coordenação de 
Desenvolvimento Instrucional
Cristine Costa Barreto
Desenvolvimento Instrucional
Fernanda Felix 
Diagramação
André Guimarães de Souza
Revisão de Língua Portuguesa
Patrícia Sotello
Projeto Gráfico e Capa
André Guimarães de Souza
Patricia Seabra
Normalização
Lamas Consultoria
P659p Pinto, José Simão de Paula.
Planejamento e elaboração de bases de dados / José Simão de Paula Pinto; 
[leitor] Leobino Nascimento Sampaio. – Brasília, DF : CAPES : UAB ; Rio de Janeiro, 
RJ : Departamento de Biblioteconomia, FACC/UFRJ, 2018.
164 p. : il.
Inclui bibliografia.
ISBN 978-85-85229-77-1 (brochura)
ISBN 978-85-85229-69-6 (e-book)
1. Bases de dados. 2. Bases de dados em rede. I. Sampaio, Leobino 
Nascimento. II. Título.
CDD 020.92
CDU 023.4
Catalogação na publicação por: Miriam Dias CRB-7 / 6995
Caro leitor,
A licença CC-BY-NC-AS, adotada pela UAB para os materiais 
didáticos do Projeto BibEaD, permite que outros remixem, adaptem e 
criem a partir desses materiais para fins não comerciais, desde que lhes 
atribuam o devido crédito e que licenciem as novas criações sob termos 
idênticos. No interesse da excelência dos materiais didáticos que compõem 
o Curso Nacional de Biblioteconomia na modalidade a distância, foram 
empreendidos esforços de dezenas de autores de todas as regiões do 
Brasil, além de outros profissionais especialistas, a fim de minimizar 
inconsistências e possíveis incorreções. Nesse sentido, asseguramos que 
serão bem recebidas sugestões de ajustes, de correções e de atualizações, 
caso seja identificada a necessidade destes pelos usuários do material ora 
apresentado. 
LISTA DE FIGURAS
Figura 1 - Esquema comparativo entre o funcionamento do 
sistema de arquivos e o sistema de gerenciamento de 
banco de dados ............................................................ 22
Figura 2 - Os SGBDs permitem que façamos compras e 
investimentos on-line ................................................... 23
Figura 3 - Assim como apenas guardar as notas fiscais não vai 
ajudar uma pessoa a gerenciar suas finanças ................ 29
Figura 4 - Uma base de dados pode ser composta por vários 
bancos de dados .......................................................... 30
Figura 5 - A usabilidade e a performance de um SGBD 
interferem na sua percepção de uso de um 
determinado sistema .................................................... 30
Figura 6 - Níveis de abstração na arquitetura de bancos de dados 
ANSI-SPARC ................................................................. 34
Figura 7 - Exemplo de tabela de banco de dados relacionais ......... 36
Figura 8 - Ao fazer uma compra via internet, você certamente 
estará interagindo com um banco de dados ................. 37
Figura 9 - Síntese dos conceitos apresentados .............................. 38
Figura 10 - Representação da comunicação pela rede no ambiente 
cliente x servidor .......................................................... 42
Figura 11 - O par login/identificador (user name) e senha 
(password), após o usuário fazer a digitação das 
informações nos respectivos campos ............................ 43
Figura 12 - Ciclo de vida de um sistema de informação para 
modelagem de negócios, de acordo com Martin e 
Filkelstein (1984) .......................................................... 46
Figura 13 - Antes de planejar modelar um banco de dados, é 
preciso conhecer os seus futuros usuários. No caso de 
uma biblioteca de uma universidade ............................. 49
Figura 14 - É importante observar a rotina do usuário, seu modo 
de buscar informações e os tipos de informações 
pesquisadas .................................................................. 50
Figura 15 - Exemplo de diagrama de casos de uso .......................... 51
Figura 16 - A identificação dos usuários padrão e sua colaboração 
são fundamentais para a elaboração da modelagem 
do banco de dados ....................................................... 54
Figura 17 - A participação do usuário é central no processo, 
desde a concepção, passando pelo desenho, pela 
implementação e pela validação de um 
banco de dados ............................................................ 56
Figura 18 - Representação da sequência de projeto de 
bancos de dados .......................................................... 58
Figura 19 - Criação de um modelo conceitual a partir dos 
requisitos do usuário .................................................... 58
Figura 20 - Representação gráfica genérica do Modelo Entidade x 
Relacionamento (MER) ................................................. 68
Figura 21 - Representação de uma entidade e seus tipos de 
atributos ...................................................................... 71
Figura 22 - Exemplo de representação MER no programa Ferret ..... 72
Figura 23 - Exemplo de generalização e especialização ................... 73
Figura 24 - Exemplo de modelagem com especialização ................. 74
Figura 25 - Modelagem de associações entre as entidades 
pessoa e livro ................................................................ 75
Figura 26 - British Museum Library e Magee Public Library. 
Modelar significa entender as necessidades de cada 
instituição e modelar os dados ..................................... 76
Figura 27 - Exemplos de autorrelacionamento entre as entidades ... 76
Figura 28 - Exemplos de entidade .................................................. 77
Figura 29 - Exemplos de relacionamento ........................................ 77
Figura 30 - Exemplo de MER contendo relacionamento quaternário ... 78
Figura 31 - Exemplo de possível solução para o estudo de caso 1 ... 81
Figura 32 - Exemplo de mapeamento entre os modelos ER e 
Relacional ..................................................................... 91
Figura 33 - Exemplo de MER com aspectos físicos .......................... 97
Figura 34 - Exemplo de criação de BD ............................................ 98
Figura 35 - Exemplo do comando USE para indicar qual BD será 
usado para os próximos comandos ............................... 99
Figura 36 - Exemplo do comando CREATE TABLE para criar as 
tabelas no BD em uso .................................................102
Figura 37 - Exemplo do comando SHOW TABLES para mostrar as 
tabelas no BD em uso ................................................. 103
Figura 38 - Exemplo do comando DESC para mostrar 
a estrututra de uma tabela no BD em uso ................... 103
Figura 39 - Exemplo do comando DESC para mostrar 
a estrututra de uma tabela no BD em uso ................... 104
Figura 40 - Exemplo do comando INSERT INTO para mostrar a 
inserção de dados em uma tabela no BD em uso, 
no caso, a Tabela Autores ........................................... 106
Figura 41 - Exemplo do comando INSERT INTO usado para tentar 
inserir novamente dados já cadastrados na tabela 
autores no BD em uso ................................................ 106
Figura 42 - Exemplo do comando INSERT INTO usado para inserir 
dados na tabela Usuarios no BD em uso ..................... 107
Figura 43 - Exemplo do comando INSERT INTO usado para inserir 
dados na tabela Livros no BD em uso .......................... 109
Figura 44 - Exemplo do comando INSERT INTO usado para inserir 
dados na tabela Livro-autores no BD em uso .............. 110
Figura 45 - Exemplo do comando INSERT INTO usado para inserir 
dados na tabela Livro-autores no BD em uso .............. 110
Figura 46 - Exemplo do comando INSERT INTO usado para inserir 
dados na tabela Livro-autores no BD em uso .............. 111
Figura 47 - Exemplo do comando INSERT INTO usado para inserir 
dados na tabela Empréstimos no BD em uso ............... 113
Figura 48 - Exemplo do comando UPDATE usado para inserir 
dados de devolução na tabela Empréstimos do BD ..... 114
Figura 49 - Exemplo do comando SELECT usado para selecionar e 
exibir dados da tabela Livros do BD em uso ................ 116
Figura 50 - Exemplo de resultado de lista de dados da 
tabela Livros do BD em uso ......................................... 116
Figura 51 - Exemplo de resultado de lista de dados da tabela 
Livros do BD em uso, selecionando por ISBN ............... 117
Figura 52 - Exemplo de resultado de lista de dados da tabela 
Livros do BD em uso, selecionando por Título ............. 117
Figura 53 - Exemplo de resultado de lista de dados da tabela 
Livros do BD em uso, selecionando por Título, em 
ordem alfabética ........................................................ 118
Figura 54 - Exemplo de resultado de lista de dados da 
tabela Livros do BD em uso, selecionando por Título, 
em ordem descendente .............................................. 118
Figura 55 - Exemplo de resultado de lista de dados da tabela 
Livros do BD em uso, selecionando por ISBN ............... 119
Figura 56 - Exemplo de resultado de lista de dados 
da tabela Livros do BD em uso .................................... 119
Figura 57 - Exemplo de resultado de lista de dados da tabela Livros 
do BD em uso ............................................................ 120
Figura 58 - Exemplo de resultado de lista de dados da tabela Livros 
do BD em uso ............................................................ 121
Figura 59 - Exemplo de resultado de lista de dados da tabela 
Livros do BD em uso ................................................... 121
Figura 60 - Exemplo de resultado de lista de dados da tabela 
Livros do BD em uso ................................................... 121
Figura 61 - Exemplo de resultado de lista de dados da tabela 
Livros do BD em uso ................................................... 122
Figura 62 - Exemplo de resultado usando o comando WHERE ...... 122
Figura 63 - Exemplo de resultado sem usar o comando WHERE .... 123
Figura 64 - Exemplo de resultado usando o comando Select 
para filtrar por CPF ..................................................... 124
Figura 65 - Exemplo de resultado sem usar o comando WHERE 
buscando o nome dos usuários .................................. 124
Figura 66 - Exemplo de resultado usando o comando 
SELECT DISTINCT e WHERE buscando o nome dos 
usuários com base no CPF aplicando NOT IN .............. 125
Figura 67 - Exemplo de resultado usando o comando SELECT 
DISTINCT e WHERE buscando o nome dos usuários 
com base no CPF aplicando NOT IN ............................ 125
Figura 68 - Exemplo de resultado usando o comando DATE_
FORMAT ..................................................................... 126
Figura 69 - Exemplo de resultado usando o comando DATEDIFF ... 126
Figura 70 - Exemplo de resultado usando o comando CURDATE ... 126
Figura 71 - Exemplo de resultado usando o comando 
CURDATE na tabela Empréstimos ................................ 127
Figura 72 - Exemplo de resultado usando o comando 
Componentes ............................................................ 128
Figura 73 - Exemplo de resultado usando o comando SELECT ....... 129
Figura 74 - Exemplo de resultado usando o comando ALTER TABLE ... 129
Figura 75 - Exemplo de resultado usando o comando 
DELETE para dados menores que 100 ......................... 130
Figura 76 - Exemplo de resultado usando o comando DELETE 
para dados maiores que 99 ........................................ 130
Figura 77 - Exemplo de resultado usando o comando 
INSERT INTO para verificar se os dados foram 
totalmente apagados do BD ....................................... 131
Figura A.1 - Tela inicial da ferramenta brMODELO ......................... 142
Figura A.2 - Utilização da ferramenta brMODELO para criação 
 de uma nova entidade pessoa ................................... 143
Figura A.3 - Utilização da ferramenta brMODELO para 
 criação de atributos na entidade pessoa .................... 144
Figura A.4 - Utilização da ferramenta brMODELO para ajuste 
 do atributo composto endereço na entidade pessoa .... 144
Figura A.5 - Utilização da ferramenta brMODELO para ajuste 
 de características dos atributos conforme o 
 dicionário de dados do modelo ................................. 145
Figura A.6 - Criação do modelo lógico a partir do modelo 
 conceitual ................................................................. 145
Figura A.7 - Criação do modelo lógico a partir do modelo 
 conceitual: outras opções .......................................... 146
Figura A.8 - Utilização da ferramenta brMODELO para gerar 
 modelo lógico: cardinalidade ajustada ....................... 147
Figura A.9 - Utilização da ferramenta brMODELO para gerar o 
 esquema físico .......................................................... 147
Figura B.1 - Execução de comandos no MySQL em interface 
 texto por meio do terminal no sistema Ubuntu .......... 153
Figura B.2 - Criação de conexão com o MySQL dentro 
do workshop .............................................................. 154
Figura B.3 - Fornecer senha e confirmar conexão com o MySQL .... 155
Figura B.4 - Visão da tela do MySQL Worbench após logado ........ 155
Figura B.5 - Auxílio sensível ao contexto ....................................... 156
Figura B.6 - Barras de ferramentas do MySQL Worbench e 
 seus ícones ................................................................ 156
Figura B.7 - Principais comandos presentes no quadro 
 de navegação e gerenciamento ................................. 160
Figura B.8 - Edição de diagramas no Workbench .......................... 161
Figura B.9 - Aspecto da tela de edição de diagramas .................... 161
Figura B.10 - Criação de tabelas ................................................... 161
Figura B.11 - Tela de inserção de dados na tabela criada ............... 162
Figura B.12 - Criação de relacionamentos entre as tabelas 
 no editor de diagramas ............................................ 162
LISTA DE QUADROS
Quadro 1 – Exemplo de aplicação de banco de dados baseada em 
sistema de arquivos ...................................................... 20
Quadro 2 - Exemplo de diferenciação entre dado e metadado 
usando o contexto de informações de obras em uma 
biblioteca .....................................................................25
Quadro 3 - Tipos de dados usuais em bancos de dados relacionais ... 27
Quadro 4 - Tipos de integridade de dados em SGBDs ..................... 40
Quadro 5 - Tipos de entidades e suas descrições ............................. 69
Quadro 6 - Sugestões de implementações de tabelas a partir 
da Modelagem ER ........................................................ 92
Quadro 7 - Exemplo de dicionário de dados .................................... 94
Quadro A.1 - Dicionário de dados ................................................. 144
Quadro A.2 - Funções dos ícones da barra de ferramentas 
 básicas do software brMODELO............................... 148
Quadro A.3 - Funções dos ícones da barra de ferramentas para 
 modelagem conceitual do software brMODELO....... 149
Quadro A.4 - Funções dos ícones da barra de ferramentas para 
 modelagem lógica da ferramenta brMODELO .......... 150
Quadro B.1 - Funções dos ícones da barra de ferramentas 
 de assistentes .......................................................... 157
Quadro B.2 - Funções dos ícones da barra de ferramentas 
 do editor de comandos ............................................ 158
SUMÁRIO
 APRESENTAÇÃO ........................................................................................ 15
1 UNIDADE 1: CONCEITOS RELATIVOS A BANCOS DE DADOS ....................... 17
1.1 OBJETIVO GERAL ..................................................................................... 17
1.2 OBJETIVOS ESPECÍFICOS .......................................................................... 17
1.3 PRÉ-REQUISITOS ...................................................................................... 17
1.4 A IMPORTÂNCIA DA ESTRUTURAÇÃO DAS BASES DE DADOS 
 E A BIBLIOTECONOMIA ........................................................................... 19
1.4.1 Das aplicações de bancos de dados ao sistema gerenciador 
 de bancos de dados ................................................................................ 20
1.4.2 Conceitos ................................................................................................. 24
1.4.2.1 Dados, metadados, informação e conhecimento .................................. 24
1.4.2.2 Bancos de dados e bases de dados ......................................................... 29
1.4.2.3 Atividade ................................................................................................. 33
1.4.2.4 Níveis de abstração em bancos de dados .............................................. 33
1.4.2.5 Tarefas do sistema gerenciador de bancos de dados ............................ 36
1.4.2.6 Ambiente de rede e segurança .............................................................. 42
1.4.3 Desenvolvimento de sistemas e bancos de dados ............................... 44
1.4.3.1 Levantamento de dados e requisitos do sistema .................................. 48
1.4.3.2 Participação do usuário .......................................................................... 54
1.4.3.3 Breves considerações a respeito da tecnologia ..................................... 56
1.4.4 Os níveis de abstração e a modelagem do banco de dados ................ 57
1.4.5 Atividade ................................................................................................. 59
 CONCLUSÃO .............................................................................................. 61
 RESUMO .................................................................................................... 62
2 UNIDADE 2: PLANEJAMENTO E DESENHO DE BANCOS DE DADOS 
 POR MEIO DE MODELAGEM CONCEITUAL ................................................. 65
2.1 OBJETIVO GERAL ..................................................................................... 65
2.2 OBJETIVOS ESPECÍFICOS .......................................................................... 65
2.3 PRÉ-REQUISITOS ...................................................................................... 65
2.4 A MODELAGEM COMO UM MODO DE VER A REALIDADE .................. 67
2.5 MODELO ENTIDADE RELACIONAMENTO – MER ................................... 67
2.5.1 Entidades ................................................................................................. 69
2.5.2 Atributos .................................................................................................. 70
2.5.3 Relacionamentos ..................................................................................... 72
2.5.4 Formas de modelagem MER – Relacionamentos .................................. 73
2.6 DESENHO DE BANCOS DE DADOS BASEADO NO MODELO 
 ENTIDADE RELACIONAMENTO (MER) .................................................... 79
2.6.1 Atividade ................................................................................................. 79
2.6.2 Estudo de caso 1: modelagem de uma situação de compra e venda ...... 80
2.6.3 Atividade ................................................................................................. 81
2.6.4 Estudo de caso 2: ampliando o modelo de compra e 
 venda com a inclusão dos fornecedores ............................................... 82
2.6.5 Atividade ................................................................................................. 82
2.6.6 Atividade ................................................................................................. 83
 CONCLUSÃO .............................................................................................. 85
 RESUMO .................................................................................................... 86
3 UNIDADE 3: MANIPULAÇÃO DE BANCOS DE DADOS ................................. 89
3.1 OBJETIVO GERAL ..................................................................................... 89
3.2 OBJETIVOS ESPECÍFICOS .......................................................................... 89
3.3 PRÉ-REQUISITOS ...................................................................................... 89
3.4 INTRODUÇÃO ......................................................................................... 91
3.5 INTRODUÇÃO À SQL ............................................................................... 95
3.6 PRÁTICA DE DECLARAÇÕES SQL............................................................. 96
3.6.1 Criar o banco de dados ........................................................................... 98
3.6.2 Criar as tabelas necessárias para implementar o modelo .................. 100
3.6.3 Criar constraints de integridade: chaves primárias e estrangeiras ...... 104
3.6.4 Inserir dados de teste ........................................................................... 105
3.6.4.1 Dados para a tabela Autores ................................................................ 105
3.6.4.2 Dados para a tabela Usuarios ............................................................... 107
3.6.4.3 Dados para a tabela Livros ................................................................... 108
3.6.4.4 Dados para a tabela livro_autores ....................................................... 109
3.6.4.5 Dados para a tabela emprestimos ........................................................ 112
3.6.5 Atualizar dados ..................................................................................... 114
3.6.6 Praticar recuperação de dados e pesquisas no banco de dados ........ 115
3.6.6.1 Ver informações dos livros cadastrados ............................................... 115
3.6.6.2 Ver informações dos livros cadastrados, ordenados pelo título do livro .. 118
3.6.6.3 Ver informações dos livros cadastrados, ordenados pelo 
 título do livro em ordem descendente ................................................ 118
3.6.6.4 Determinar quantos livros estão cadastrados ..................................... 119
3.6.6.5 Determinar quantos livros estão cadastrados, fornecendo o nome 
 de Quantidade para a colunaque conterá a resposta ....................... 120
3.6.6.6 Listar livros cujos títulos comecem com a palavra Modelagem ......... 120
3.6.6.7 Uso da cláusula WHERE para unir dados de tabelas diferentes ......... 122
3.6.6.7.1 Atividade ................................................................................................ 123
3.6.6.8 Aninhamento de consultas ................................................................... 124
3.6.6.9 Trabalhar formatação de datas no comando select ............................ 125
3.6.7 Campos de numeração automática ..................................................... 127
3.6.8 Apagar dados e destruir objetos ......................................................... 129
3.6.8.1 Apagar dados da tabela Componentes ............................................... 130
3.6.8.2 Apagar um objeto do banco de dados ................................................ 131
3.6.8.3 Atividade ............................................................................................... 132
 CONCLUSÃO ............................................................................................ 136
 RESUMO .................................................................................................. 136
 SUGESTÃO DE LEITURA ........................................................................... 138
 REFERÊNCIAS .......................................................................................... 138
 APÊNDICE A............................................................................................. 141
 APRESENTAÇÃO DA FERRAMENTA BR MODELO PARA 
 MODELAGEM ENTIDADE VERSUS RELACIONAMENTO ............................. 141
 APÊNDICE B ............................................................................................. 151
 APRESENTAÇÃO DA FERRAMENTA MYSQL WORKSHOP PARA 
 TRABALHO COM SQL E BANCOS DE DADOS RELACIONAIS MYSQL .......... 151
2.1 CRIAR CONEXÃO NO MYSQL WORKSHOP .......................................... 154
2.2 TRABALHAR NO MYSQL WORKBENCH ................................................ 155
2.3 CRIAR DIAGRAMAS NO MYSQL WORKBENCH .................................... 160
15Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
APRESENTAÇÃO
A disciplina Planejamento e elaboração de bases de dados faz parte do eixo de 
Tecnologias da Informação e da Comunicação (TIC) na formação do bibliotecário. Guar-
da relação com as disciplinas do referido eixo, em especial Introdução às Tecnologias da 
Informação e da Comunicação.
Oferece conhecimentos que visam a capacitar tecnicamente o bibliotecário para 
participar de projetos de bancos de dados, atentando para questões humanísticas, po-
rém, com maior concentração na técnica.
Além de atender à necessidade de formação básica do conhecimento necessário 
ao planejamento de bancos de dados nas organizações, esta disciplina pode também 
atender às necessidades específicas na execução da disciplina futura de Desenvolvimento 
do Trabalho de Conclusão de Curso (TCC), além de possibilitar a criação de um pequeno 
serviço de informações baseado em banco de dados e de bibliotecas digitais.
Em alguns momentos, poderá ser necessário o conhecimento prévio de conceitos 
e técnicas abordados em outras disciplinas, cabendo revisão destas, se necessário, em es-
pecial: Gestão da Informação e do Conhecimento; Políticas de Informação; Instrumentos 
de Representação Descritiva da Informação; Organização, Sistemas e Métodos Aplicados 
a Ambientes de Informação; e, Ambientes, Serviços e Sistemas Informacionais.
Quanto ao conteúdo, este foi dividido em três unidades e aborda conceitos de 
bancos de dados, focando no modelo relacional.
A primeira delas apresenta alguns conceitos importantes e abordagens relativas ao 
planejamento e ao projeto de bancos de dados, discutindo implicações de sua utilização 
em ambiente de rede e levantamento de requisitos.
A segunda unidade discute os aspectos de modelagem de bancos de dados, fo-
cando o Modelo Entidade Relacionamento (MER) e algumas formas de levantamento 
de requisitos. Também apresenta e discute dois casos de modelagem, para que o aluno 
possa praticá-la.
A parte final destina-se a uma introdução à linguagem Structured Query Language 
(SQL) e à modelagem e à implementação de bancos de dados. Por meio de um exemplo, 
todos os comandos são apresentados passo a passo para maior clareza e facilidade de 
estudo a distância.
Os exemplos adotados, contrariamente à prática usual e a exemplos em outras 
obras do autor, não são os finais, os perfeitos. Propositalmente, os modelos são imper-
feitos, tal qual geralmente ocorre no primeiro pensamento do projetista. Dessa forma, 
podem ser sentidos e discutidos os problemas advindos de uma modelagem superficial 
e as dificuldades em melhorá-la posteriormente ao início da implementação (ou, até, 
quando já em produção).
No decorrer da disciplina, há exemplos e atividades de modelagem (Unidade 2) e 
implementação de bancos de dados (Unidade 3). É importante que os exemplos sejam 
reproduzidos e as atividades realizadas, para facilitar sua aprendizagem. Os conteúdos 
da Unidade 2 podem ser realizados com lápis e papel, embora, preferencialmente, de-
vam ser realizados com apoio de algum software. Para o caso da Unidade 3, o uso de 
um software é essencial.
16 Planejamento e Elaboração de Bases de Dados
Ao final, dois apêndices apresentam, de forma rápida, porém suficiente para o pro-
pósito desta disciplina, duas ferramentas úteis: uma para modelagem conceitual, outra 
para implementação e uso de um banco de dados.
Após a leitura, o aluno possuirá conhecimentos para elaboração de modelos de 
dados e sua implementação em um banco de dados relacionais, servindo a aplicações 
desde pequena até média complexidade, em ambientes controlados pelo próprio aluno 
ou disponibilizados em pequenas redes.
Deu-se preferência a ferramentas ditas de software livre para a execução dos 
exemplos. Boa leitura, boas práticas e boas soluções. Sucesso! 
UNIDADE 1
CONCEITOS RELATIVOS 
A BANCOS DE DADOS
1.1 OBJETIVO GERAL
Apresentar os conceitos relacionados a bancos de dados e ao seu projeto.
1.2 OBJETIVOS ESPECÍFICOS
Espera-se que, ao final desta unidade, você seja capaz de:
a) conceituar dado, metadado, tipos de dados, informação e conhecimento no contexto de bases 
de dados;
b) compreender a organização de bancos de dados, em especial do modelo relacional;
c) compreender os diferentes níveis de abstração e visão no projeto de bancos de dados;
d) reconhecer a importância de uma boa modelagem de dados com participação ativa dos usuários.
1.3 PRÉ-REQUISITOS
Noções de tecnologia da informação e de conceitos de dado, informação e seu ciclo. 
19Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
1.4 A IMPORTÂNCIA DA 
ESTRUTURAÇÃO DAS 
BASES DE DADOS E A 
BIBLIOTECONOMIA
Você já passou pela situação de guardar um documento em qualquer 
lugar e, quando precisou dele, não sabia onde estava? Pode ser a certidão 
de nascimento, o título de eleitor, um certificado de conclusão de curso 
ou uma conta de luz, por exemplo. Talvez já tenha vivenciado o contrário, 
ou seja, de guardar tão bem um documento que depois não sabia onde 
o havia guardado.
É muito comum isso acontecer quando não temos um sistema de ges-
tão de nossos dados organizados de modo que facilite a nossa consulta 
e a busca pela informação desejada, quer seja em pastas, quer seja em 
um fichário.
Assim como a organização pessoal facilita o armazenamento e a lo-
calização de um dado documento quando precisamos, o mesmo pensa-
mento se aplica às informações armazenadas em bancos de dados.
Dentre os problemas típicos que temos com a informação e sua ges-
tão, encontram-se o “como” selecionar e o “onde” conseguir a informa-
ção desejada.
Uma das formas adotadas para auxiliar na solução desse problema é 
o armazenamento sistemático das informações ou dos dados que nos 
propiciam obtê-las.
Vamos ver um exemplo?
Podemosdestacar a área da saúde, que:
a) já em 1867, John Billings, por meio da National Library of Medicine 
(NLM), inicia o Index Medicus;
b) em 1958, a NLM introduz o computador;
c) em 1989, passa a produzir o MEDLINE CD-ROM, que cresce a cada 
ano com a inclusão de centenas de milhares de artigos de milhares 
de revistas indexadas;
d) atualmente, possui várias bases de dados em saúde, as quais, tem 
por finalidade concentrar as informações importantes e oferecer 
um mecanismo de busca e recuperação dos conteúdos desejados. 
Exemplos: BIREME, Lilacs, PubMed.
De forma geral, todas as áreas do conhecimento possuem essa 
mesma necessidade sentida pela área da saúde, dando origem às bases 
eletrônicas de dados, nas quais, obviamente, o computador é uma 
poderosa ferramenta de auxílio.
Agora, reflita sobre a seguinte questão: como você vê a importância 
das bases de dados em sua área de atuação?
Base de dados
O termo “banco de dados” é 
normalmente utilizado para 
categorizar um conjunto de dados 
específicos ou relacionados, 
enquanto o termo “bases de 
dados” pode ser utilizado para o 
conjunto de bancos de dados. Por 
exemplo, podemos ter uma base 
de dados em saúde contendo os 
bancos de dados de farmacologia 
e anatomia.
20 Planejamento e Elaboração de Bases de Dados
Para a Biblioteconomia, as bases de dados são fundamentais, pois fa-
cilitam o “como fazer” a busca das informações e localizá-las! Por isso, 
é importante conhecermos o histórico de sua evolução, como chegamos 
aos modelos que usamos atualmente, e também os principais conceitos 
a elas relacionados.
Então, mãos à obra e bons estudos!
1.4.1 Das aplicações de bancos de dados ao sistema 
gerenciador de bancos de dados
Em uma visão histórica, nos primórdios da computação, as aplicações 
de bancos de dados eram implementadas em sistemas de arquivos. Isso 
ocorreu, principalmente, entre os anos 1950 a 1970 – embora o processo 
ainda possa ser utilizado hoje em dia.
Usar sistemas de arquivos corresponde a escrever programas de acesso 
aos dados para cada nova operação necessária (busca, inclusão, alteração 
etc.). Modernamente, os sistemas gerenciadores de bancos de dados, 
que veremos nesta disciplina, são os responsáveis pela realização dessas 
operações, por meio de comandos SQL, que veremos na sequência.
Um exemplo hipotético de arquivo pode ser visto na imagem 
(Quadro 1) a seguir. Nele, temos números de International Standard Book 
Number (ISBN), nomes de obras e de autores, separados pelo caracter | 
(que não pode fazer parte dos nomes de obras nem de seus autores, por 
ser um separador). Note que é necessário saber de antemão a sequência 
e a posição dos conteúdos para localizá-los, o que exige a elaboração de 
um programa, como comentado.
Quadro 1 – Exemplo de aplicação de banco de dados baseada em sistema de arquivos
ISBN nomes de obras nomes de autores
…
8508028121 Teoria da informação Isaac Epstein
007460575 Modelagem de dados Peter Chen
978857605923
Sistemas de informação ge-
renciais
Jane P. Laudon-Kenneth C. Laudon
9788586846588 Microsoft SQL Server José Simão de Paula Pinto
...
Fonte: Produção do próprio autor
O quadro poderia também ser escrito do seguinte modo:
...|8508028121|Teoria da informação|Isaac Epstein|0074605755| 
Modelagem de dados|Peter Chen|9788576059233|Sistemas de infor-
mação gerenciais|Jane P. Laudon-Kenneth C. Laudon|9788586846588| 
Microsoft SQL Server|José Simão de Paula Pinto|...
21Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Observe que foi utilizada uma separação (com -) para os nomes dos 
autores de um dos livros (Sistemas de informação, do casal Laudon e 
Laudon); isso tem que ser previsto na modelagem e impede que o carac-
tere escolhido para separação (-) seja utilizado nos nomes.
Tal técnica funcionou e foi utilizada durante muito tempo, mas trazia 
as seguintes desvantagens:
a) redundância de dados e inconsistência;
b) múltiplos formatos de arquivos;
c) duplicação da informação em arquivos diferentes;
d) dificuldades no acesso aos dados;
e) necessidade de reescrever um novo programa para atender cada 
nova tarefa;
f) isolação dos dados, devido aos múltiplos arquivos e formatos;
g) problemas de integridade e constraints (ou regras) de integridade 
fazendo parte dos códigos dos programas, trazendo dificuldades 
para adicionar novas regras ou modificar as já existentes.
Se você já trabalhou em ambientes assim, deve ter sentido a neces-
sidade de possuir um mecanismo melhor para tratar desses problemas. 
Como exemplo, podemos citar os sistemas antigos de gestão, incluindo 
as bibliotecas, que eram muitas vezes baseados em conjuntos de arqui-
vos, os quais tinham de ser mantidos e reindexados frequentemente e 
dependiam de alterações na programação para a inclusão de pequenas 
novas funcionalidades.
Uma solução é o Sistema Gerenciador de Bancos de Dados (SGDB), 
que permite a criação de bancos de dados diversos e seu gerenciamento, 
cuidando da localização física dos dados, da segurança do acesso e da 
integridade do conteúdo (PINTO, 2000, p. 6).
Nesta disciplina, estudaremos os SGBDs do tipo relacionais, que têm 
seu funcionamento baseado no modelo proposto por Cood no início da 
década de 1970 e teve seu primeiro modelo comercial (o Oracle) comer-
cializado a partir do final da mesma década. Veremos esse modelo mais 
adiante.
Agora que você já teve uma breve introdução sobre o sistema baseado 
em arquivos e o SGBD, que tal fazermos uma comparação entre eles para 
melhor observarmos as suas formas de funcionamento?
Um comparativo entre um sistema baseado em arquivos e gerenciador 
de bancos de dados pode ser visto na imagem (Figura 1) que segue.
Inconsistência – ocorre quando 
os dados cadastrados possuem 
valores diferentes de acordo com 
a fonte de leitura; por exemplo, 
numa mesma biblioteca existem 
dois cadastros de usuários, 
no qual um tem endereço de 
correspondência atualizado e 
outro não.
Múltiplos formatos de 
arquivos – ocorre quando dife-
rentes programadores utilizam 
diferentes sequências de dados 
ou formas de compactação para 
cadastrar os dados. Por exemplo, 
se, no Quadro 1, um progra-
mador gravar na sequência do 
nome da obra o nome do autor, 
quando forem recuperadas 
as informações, elas estarão 
incorretas.
Isolação dos dados – a 
alteração de um não pode forçar 
a alteração de outro. Por exemplo: 
trocar em um arquivo uma 
sequência numérica para cadastro 
de ISBNs por uma alfanumérica 
(para permitir cadastrar o caractere 
X), não pode afetar outros 
arquivos.
Problemas de integridade – 
uma situação facilmente resolvida 
nos modernos gerenciadores 
por meio de chaves e que pode 
causar situações confusas quando 
trabalhamos com arquivos 
isolados. Imagine um cadastro 
de depoendentes, no qual o 
responsável não foi cadastrado ou 
foi removido um cadastro e seus 
dependentes não. Modernamente, 
as constraints impedem que 
esse erro ocorra, desde que, 
obviamente, tenham sido bem 
projetadas e implementadas.
22 Planejamento e Elaboração de Bases de Dados
Figura 1 - Esquema comparativo entre o funcionamento do sistema de arquivos 
e o sistema de gerenciamento de banco de dados
Fonte: Produção do próprio autor
Devemos reforçar uma grande vantagem a favor dos gerenciadores: a 
possibilidade de realização das consultas ad hoc, ou seja, aquelas que são 
realizadas, em certo momento, para atender a uma necessidade especí-
fica e talvez nem sejam mais úteis posteriormente, sem a elaboração de 
um novo programa.
Por exemplo: imagine que foi solicitado a você um levantamento de 
quantos livros de certo autor foram emprestados pela manhã e devolvi-
dos à tarde.
Evidentemente, nesse exemplo, presumimos que o modelo utilizado 
deve ter previsto armazenar os horários de empréstimo e devolução para 
que isso possa ser executado.
Evidencia-se, assim, a necessidade de um bom modelo.
Cabe aos SGBDs, ainda, cuidar da consistência ou atomicidade das 
atualizações (os termos serão explicados adiante). Por exemplo,cuidar 
para que em uma transferência de fundos ocorra, conjuntamente, um 
débito em uma conta e um crédito em outra. Gerenciar o acesso concor-
rente (simultâneo) aos recursos do banco de dados e seu desempenho 
são exemplos de outras tarefas importantes executadas pelos SGBDs.
23Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Figura 2 - Os SGBDs permitem que façamos compras e investimentos on-line, 
por exemplo, de modo que as transações possam ocorrer simultaneamente e com 
confiabilidade entre o comprador e o vendedor ou investidor e bolsa de valores
Fonte: Flickr1
Podemos compreender o SGBD como sendo um programa que, a 
partir de scripts, permite a criação e o gerenciamento de bancos de 
dados. Posteriormente, por meio de linguagens de acesso, permite a 
manipulação dos dados e objetos armazenados.
Um exemplo disso, em linguagem de consulta estruturada, SQL (a qual 
estudaremos na Unidade 3), poderia ser:
SELECT titulo FROM obras WHERE ISBN = 8508028121;
No exemplo, estamos solicitando o título do livro, cujo ISBN é 
8508028121, e que está cadastrado na tabela obras. O ponto e vírgula 
é o terminador desse comando, e é obrigatório. O gerenciador irá pes-
quisar em suas tabelas e fornecer o resultado (o título é Teoria da Infor-
mação, para o exemplo dado). Note que, embora não seja necessária a 
elaboração de um programa, será necessária a elaboração da consulta 
em SQL; mas, isso é bem mais fácil e, ainda, existem muitos gerenciado-
res que oferecem formas gráficas de elaboração de consultas, gerando o 
SQL automaticamente.
Para fins de comparação, volte ao Quadro 1 e imagine como o nome 
do autor poderia ser obtido a partir de um arquivo como o da Figura 1.
Uma outra característica importante dos SGBDs é que a complexidade 
das operações e manipulações de dados e arquivos fica escondida do usu-
ário, ou seja, não precisamos manipular bits para criar bancos de dados.
É interessante que você compreenda que, se o banco de dados pos-
sui uma interface gráfica, como o bastante difundido Microsoft Access, 
aquela interface permite uma interação com o usuário, facilitada; mas, 
internamente, aquilo que você selecionar na interface será executado por 
meio de um script, ou seja, as tarefas ficarão escondidas, e a complexida-
de de operação será menor. E, para alguns casos, a flexibilidade também.
1 FLICKR. Rapid City Public Library. Disponível em: https://www.flickr.com/photos/rcpl/4385363391/
in/photostream/. Acesso em: 21 dez. 2018.
Script é um conjunto de 
instruções que são executadas 
sequencialmente para atingir certo 
objetivo, por exemplo, localizar 
todos os livros que pertencem a 
uma coleção, em um banco de 
dados de uma biblioteca.
https://www.flickr.com/photos/rcpl/4385363391/in/photostream/
https://www.flickr.com/photos/rcpl/4385363391/in/photostream/
24 Planejamento e Elaboração de Bases de Dados
Nesta disciplina, estudaremos como criar e utilizar bancos de dados 
usando como exemplo prático um SGBD com arquitetura relacional, 
também conhecido como SGBD-R (em inglês, Relational Database 
Management System – RDBMS), iniciando com a explicação dos 
conceitos, a modelagem conceitual e evoluindo para a prática de 
bancos de dados.
Embora os exemplos sejam fornecidos em um SGBD-R específico, você 
poderá utilizar qualquer outro que seja capaz de executar as atividades 
propostas.
Para que possamos criar nossas próprias bases de dados, estudaremos, 
nesta unidade, conceitos e técnicas de planejamento e elaboração das 
mesmas.
Para a finalidade desta disciplina, e dada a ampla difusão dos bancos 
de dados relacionais, ao nos referirmos a SGBD, estaremos falando de 
SGBD-R, ok?
Então, vamos em frente!
1.4.2 Conceitos
Para início de nossos estudos, vamos resgatar e introduzir alguns con-
ceitos para que possamos trabalhar com eles do ponto de vista de bancos 
de dados.
1.4.2.1 Dados, metadados, informação e conhecimento
Para garantir a qualidade dos dados, precisamos resgatar alguns con-
ceitos já vistos em disciplinas precedentes e nos atermos à sua importân-
cia no contexto dos bancos de dados.
Conforme você já viu em outras disciplinas do curso, dado é o conteú-
do mais básico, também conhecido como informação sem processamen-
to. Em um banco de dados, é o elemento primário, aquilo que queremos 
armazenar para consulta ou transformação futura.
Explicativo
O ruído em um banco de dados
Ressaltamos aqui que, quando pesquisamos dados em uma or-
ganização, sempre haverá um subtipo de dado classificado como 
ruído, que corresponde aos dados incompletos, desatualizados, ine-
xistentes ou aos desnecessários no contexto de interesse. Por exem-
plo, em uma biblioteca, cadastrar um livro com ano incorreto ou com 
título incompleto, esse dado pode ser considerado um ruído.
Meta é um prefixo que, na maioria das aplicações tecnológicas, signi-
fica uma definição ou descrição de algo. Então, metadados são a descri-
ção ou a definição dos dados.
25Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Em uma biblioteca, poderíamos ter, como exemplo de metadados, o 
ISBN de uma obra, seu título e seu autor. Os dados correpondentes se-
riam a combinação de valores para cada caso, desta forma:
Quadro 2 - Exemplo de diferenciação entre dado e metadado usando o contexto de 
informações de obras em uma biblioteca
Metadado Dado
ISBN 8508028121
Título Teoria da informação
Autor Isaac Epstein
Fonte: Produção do próprio autor
Multimídia
Metadados úteis a bibliotecas e coleções
Para saber mais a respeito de metadados úteis a 
bibliotecas e coleções, pesquise na internet sobre o 
Padrão Dublin Core e o formato Machine Readable 
Cataloging (MARC).
Já a metalinguagem é uma definição ou descrição de uma linguagem.
Em seu sentido geral, refere-se a tornar mais compreensivo ou funda-
mental um conjunto de regras. Um exemplo, seria tomarmos o conjunto 
de regras formado por uma gramática e um dicionário, que poderiam 
ser utilizados para definir e descrever as formas de falar e escrever um 
determinado idioma. Isso se refere à metalinguagem, ou seja, a uma lin-
guagem utilizada para explicar outra.
A linguagem tipicamente utilizada para descrever as estruturas de um 
banco de dados relacional (e, posteriormente, realizar as consultas ao seu 
conteúdo) é a linguagem de consulta estruturada (SQL): ela é utilizada 
para traduzir os conceitos do mundo real para a linguagem falada pelo 
gerenciador de bancos de dados.
Em bancos de dados, metadado refere-se à descrição do dado: des-
creve a estrutura e o conteúdo do dado, assim como seu formato em 
termos de tipo de dado.
Vamos ver um exemplo?
26 Planejamento e Elaboração de Bases de Dados
Poderíamos ter em uma biblioteca a descrição do nome do autor de 
uma obra com a especificação para que sejam aceitos até 40 caracteres 
alfanuméricos, de tal forma que, em bancos de dados, seria:
NOME_AUTOR CHAR(40);
Assim, temos NOME_AUTOR como o metadado que identifica o nome 
do autor da obra; CHAR, o representativo para caracteres alfanuméricos; 
e, 40, o tamanho máximo, ou a quantidade de caracteres.
Em muitos casos, também estará associado ao conjunto de metada-
dos, o domínio de valores, ou seja, a faixa de valores que o dado pode 
assumir, ou os valores possíveis, caso sejam enumeráveis, e, ainda, a sua 
unidade. Veja, a seguir, dois exemplos de domínio de valores:
a) a temperatura com valor numérico real, com uma casa decimal, 
variando de – 10 a + 50 graus centígrados;
b) os valores das siglas possíveis para estados da região sul, 
necessariamente a escolher somente um do conjunto {PR, SC, RS}.
Nos exemplos acima, os domínios para temperatura são os valores nu-
méricos entre – 10 e + 50 e, para as siglas da região sul, o conjunto dado 
(PR, SC, RS); assim, quaisquer outros valores não fazem parte do domínio 
e não podem ser aceitos.
Em uma biblioteca, poderíamos ter um metadado que descreve o 
ISBN, por exemplo, aceitando 11 números, somente inteiros. Poderia ha-
ver uma regra que determinariaque não pode ser aceito o número zero.
E onde essas informações relativas a metadados, formatos e tipos de 
dados ficam armazenadas?
Toda a informação para gerenciamento do banco de dados, arma-
zenada no chamado catálogo, é um conteúdo referente aos metadados 
de interesse do SGBD (ELMASRI; NAVATHE, 2011, p. 26). O catálogo em 
questão é uma tabela ou um conjunto delas, mantida pelo sistema ge-
renciador, que possui as informações dos metadados, dados e arquivos 
físicos que compõem o banco de dados.
Foi mencionado anteriormente que os dados podem ser classificados 
em vários tipos diferentes. Vamos conhecê-los?
O computador armazena tudo em forma binária (bits 0 e 1). Então, 
para distinguir como as sequências de bits serão interpretadas, devemos 
informar qual tipo de dado queremos naquela posição, por exemplo, 
um número inteiro, um número decimal ou caracteres alfanuméricos.
Veja, a seguir, alguns tipos de dados usuais (os valores mínimos, máxi-
mos e limites em geral devem ser consultados para cada produto, já que 
variam de um SGBD para outro):
27Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Quadro 3 - Tipos de dados usuais em bancos de dados relacionais
TIPOS DE DADOS USUAIS EM BANCOS DE DADOS RELACIONAIS
Tipo Descrição
CHAR(tamanho)
Para armazenamento de caracteres em geral (letras, 
números, símbolos). O tamanho (número inteiro) refere-
se à quantidade de caracteres que será utilizada, e é o 
máximo, ou seja, o dado poderá ter um tamanho menor. 
O tamanho declarado será sempre ocupado no banco 
de dados como espaço de armazenamento, ou seja, 
se declararmos CHAR(100), estaremos reservando 100 
posições de armazenamento, quer existam ou não dados 
a armazenar.
Exemplo: nome CHAR(40) - isto faria com que, para 
o cadastro dos dados referentes ao nome, pudessem 
ser utilizados até 40 caracteres alfanuméricos e sempre 
seriam utilizadas as 40 posições no armazenamento, 
mesmo que o nome fosse menor.
VARCHAR(tamanho)
Igual ao CHAR, porém somente serão armazenados os 
caracteres efetivamente ocupados, e não o tamanho total. 
Por exemplo, se declararmos VARCHAR(100) e o dado 
contiver somente 50 caracteres, o tamanho total não será 
utilizado. Esse armazenamento consome um pouco mais 
de processamento.
Exemplo: nome VARCHAR(40) - isso faria com que, para 
o cadastro dos dados referentes ao nome, pudessem ser 
utilizados até 40 caracteres alfanuméricos, utilizando o 
espaço de armazenamento de acordo com o tamanho do 
conteúdo.
INTEGER
Para o armazenamento de números inteiros.
Exemplo: codigo INTEGER - isto faria com que, para o 
cadastro dos dados referentes ao código, pudessem ser 
utilizados somente números inteiros (o limite dos números 
depende de cada gerenciador).
DECIMAL
Para o armazenamento de números não inteiros, que 
possuem a parte decimal. Podemos especificar o tamanho 
da parte inteira e o da parte decimal, por exemplo, DECIMAL 
(10,2), com 10 casas para a parte inteira e 2 casas decimais.
Exemplo: valor DECIMAL (10,2) - isto faria com que, para 
o cadastro dos dados referentes ao valor, pudessem ser 
utilizados números com parte inteira de 10 dígitos e duas 
casas decimais.
BLOB ou BINARY
Para armazenamento de sequências de bits, que podem ser 
arquivos digitais, em geral para texto, imagens, sons, vídeos.
Exemplo: imagem BLOB - isso permitiria cadastrar uma 
sequência longa tal como uma imagem.
Fonte: Produção do próprio autor
Em síntese, o tipo de dado define o que podemos armazenar e, em 
alguns casos, o como será armazenado.
28 Planejamento e Elaboração de Bases de Dados
Com relação à informação: esse termo se refere aos dados após terem 
sido agregados a algum contexto, utilidade ou processamento. Por exem-
plo, podemos considerar um código de usuário em uma biblioteca como 
sendo um dado e o conjunto de códigos, ou seja, quantos são, como sendo 
a informação do número de usuários cadastrados na biblioteca.
Explicativo
A importância dos usuários e do conhecimento do 
negócio para a modelagem de um banco de dados
No projeto de bancos de dados, a modelagem conceitual ini-
cia-se a partir da coleta das informações pertinentes àquilo que se 
está modelando; nesse caso, os códigos de usuário. Prosseguiria 
modelando-se informações que se quer obter a partir dos dados; 
para o exemplo, o número de usuários. Notar a importância do 
conhecimento do negócio que está sob análise.
Já o conhecimento refere-se àquilo que é obtido a partir da contex-
tualização e da utilização dos dados e informações e, para fins de bancos 
de dados, àquilo que será agregado como sistema de informação em 
uma organização.
Note que modelar o total de usuários (ou o período do ano em que 
ocorrem mais empréstimos para poder, com isso, estimar atendentes, se 
fosse o caso) tem muito mais a ver com a contextualização do uso do 
sistema do que com o sistema em si: é necessário saber o que e como o 
negócio, nesse caso uma biblioteca, utilizará as informações para gestão. 
Essa característica refere-se ao conhecimento, e não está intrinsicamente 
ligada aos dados ou aos metadados (ou às informações que possam ser 
geradas a partir deles), mas ao seu uso.
Portanto, o banco de dados pode ser uma fonte do conhecimento em-
presarial, enquanto o sistema de informações que o utiliza, ou que nele 
é baseado, corresponde à sistematização do conhecimento de uma or-
ganização. O uso que se fará desse conhecimento liga-se ao conceito de 
inteligência empresarial, ou de negócios, que transcende esta disciplina.
29Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Figura 3 - Assim como apenas guardar as notas fiscais não vai ajudar uma pessoa a 
gerenciar suas finanças se ela não fizer uma análise delas, o mesmo acontece com os 
dados em um SGDB. Se não servirem de subsídios para o conhecimento, ficarão apenas 
armazenados para consulta
Fonte: Produção do próprio autor
Atenção
Lembre-se: o banco de dados não é um depósito de dados a esmo! 
Não estamos querendo um arquivo morto sem planejamento, no 
qual jogaremos dados somente para guardá-los. Pelo contrário, de-
sejamos projetar como e para que serão recuperados os dados, de 
forma a ter o melhor armazenamento possível que atenda a essas 
necessidades. Caso contrário, teremos um grande arquivo no qual, 
quando necessitamos de algo, não conseguimos encontrar...
1.4.2.2 Bancos de dados e bases de dados
O termo banco de dados é, normalmente, utilizado para categorizar 
um conjunto de dados específicos ou relacionados, enquanto o termo 
bases de dados pode ser utilizado para o conjunto de bancos de dados. 
Por exemplo, podemos ter, em uma base de dados em saúde, os bancos 
de dados de farmacologia e anatomia.
Reflita: que bancos de dados você utiliza em seus afazeres diários? 
Como eles são organizados, atualizados e disponibilizados?
Pensando um pouco, você verá que são vários os exemplos, que vão 
de sua agenda de telefones e de compromissos a dados bancários, in-
cluindo-se o histórico escolar do curso de Biblioteconomia, na modalida-
de à distância, que você está cursando!
30 Planejamento e Elaboração de Bases de Dados
Figura 4 - Uma base de dados pode ser composta por vários bancos de dados. Por 
exemplo, a área de Educação pode conter dados de Filosofia e Psicologia. 
As bases de dados analógicas eram consultadas nas estantes das bibliotecas, 
atualmente elas são digitais
Fonte: Flickr2
Vamos ver um exemplo?
Você certamente já utilizou um caixa eletrônico para fazer transações 
bancárias. Já aconteceu de você acessar a sua conta em um caixa ele-
trônico de seu banco e, de repente, você perceber que a interface está 
toda diferente? Que já não sabe onde estão as opções que você sempre 
utilizava e você tem a impressão de que ficou mais difícil usá-lo? Essa si-
tuação de facilidade e uso intuitivo de uma interface de um sistema está 
relacionada à usabilidade.
Figura 5 - A usabilidade e a performance de um SGBD interferem 
na sua percepção de uso de um determinado sistemaFonte: Flickr3
2 FLICKR. Philippe Boivin. Disponível em: https://www.flickr.com/photos/
philippeboivin/4789456531/. Acesso em: 21 dez. 2018.
3 FLICKR. Sascha Kohlmann. Disponível em: https://www.flickr.com/photos/
skohlmann/15540194507/. Acesso em: 21 dez. 2018.
https://www.flickr.com/photos/philippeboivin/4789456531/
https://www.flickr.com/photos/philippeboivin/4789456531/
https://www.flickr.com/photos/skohlmann/15540194507/
https://www.flickr.com/photos/skohlmann/15540194507/
31Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Uma situação envolvendo a performance poderia ser a de quando 
você solicita, nesse mesmo caixa eletrônico, a consulta ao seu extrato 
do mês anterior e ele, rapidamente, carrega as informações. Nesse caso, 
poderemos dizer que o sistema apresentou uma alta performance no pro-
cessamento da sua solicitação.
O mesmo pode ocorrer em um sistema de uma biblioteca. Ele pode 
ser fácil e intuitivo de ser usado por alunos, professores e bibliotecários, 
cada um com sua visão do sistema ou ser extremamente complexo. Pode 
carregar rapidamente o resultado de buscas por livros e periódicos e dar 
baixas em materiais, assim como ser extremamente trabalhoso ou va-
garoso. Evidentemente, a usabilidade e a performance dependerão de 
como o sistema foi concebido e desenvolvido.
Agora, vamos conhecer um pouco mais sobre a estruturação de um 
banco de dados.
Os SGBDs possuem mais de uma forma de organização interna. Ela 
define a forma de trabalhar com os SGBDs e também algumas de suas 
características, como a performance e a usabilidade.
Assim, ao longo dos anos de desenvolvimento e pesquisas na área, 
surgiram modelos de organização interna, como:
a) organização hierárquica dos componentes internos, como 
Adaptable Data Base System (Adabas) e IP Multimedia Subsystem 
(IMS) (e, quando em arquivos, Extensible Markup Language (XML));
b) organização em rede, como o Integrated Database Management 
System (CAIDMS), baseado no modelo da Conference on 
Data Systems Languages (CODASYL);
c) orientados a relações, muito difundidos no mercado hoje, como 
o My-SQL, que usaremos nesta disciplina, o SQL Server e o 
MS-Access;
d) orientados a objetos, como Parallel Object-Oriented Environment 
and Toolkit (POET) e ObjectDB;
e) aqueles que misturam essas duas últimas possibilidades, os objeto-
relacionais, como DB-2, PostgreSQL e versões atuais do Oracle.
Os modelos orientados a objetos visam a atender, em especial, às lin-
guagens de programação orientadas a objetos, porém, não possuem uma 
álgebra universal (capaz de descrever o SGBD lógica ou matematicamen-
te, como a álgebra relacional dos SGBD-R), o que dá origem a diversas 
implementações diferentes entre si. Não são grandemente difundidos no 
mercado e muitas de suas aplicações são experimentais.
Já os modelos orientados a objeto-relacionais procuram associar o mo-
derno mundo da orientação a objetos com os tradicionais e largamente 
utilizados SGBDs relacionais, ou SGDB-R, oferecendo uma interface de 
objetos para as tabelas do banco de dados. Dessa forma, compreender 
os bancos de dados relacionais é útil também para essas aplicações. Mo-
delos relacionais baseiam-se em relações; você verá mais sobre eles mais 
adiante na disciplina.
Ao longo dos anos, as práticas comerciais voltaram-se à grande ex-
pansão de modelos hierárquicos nos ambientes de mainframe, seguidos 
por enorme expansão do uso de bancos de dados relacionais. Um dos 
aspectos que apoiou o crescimento dos SGBD-R é a existência de uma 
Performance – ou desempenho, 
relaciona-se, em bancos de dados, 
com a capacidade de atender 
os vários usuários simultâneos 
rapidamente.
Usabilidade – nesse contexto, 
tem a ver com a facilidade de 
implementação e/ou uso do 
sistema. Também pode referir-se 
ao ambiente necessário ao seu 
pleno funcionamento (funciona 
na web? E em equipamentos 
móveis?), ou, ainda, mas não 
menos importante, ao uso 
do sistema por pessoas com 
problemas de visão/de cognição/
de audição, quando for o caso de 
sistemas com resposta audível.
Mainframe – termo utilizado 
na informática para referir-se a 
computadores de grande porte.
32 Planejamento e Elaboração de Bases de Dados
álgebra relacional que fornece uma base sólida a seu funcionamento e 
uso: os conjuntos de relações e suas manipulações seguem uma estrutura 
formal bem definida, o que possibilita garantia de integridade ao usuário 
do sistema.
Do ponto de vista de software, é comum a referência a nomes como 
MySQL, Oracle, SQL Server, como sendo bancos de dados. Tecnicamente, 
são SGDBs. Como implementam o modelo relacional, podem ser referen-
ciados como sendo SGBD-R. Esses sistemas permitem construir, catalogar 
e manter grandes coleções de dados, sob a forma de arquivos binários 
armazenados.
Neste curso, utilizaremos os bancos de dados relacionais. Devemos 
citar, porém, que os arquivos XML, de utilização cada vez maior nos apli-
cativos atuais, em especial, naqueles voltados a dispositivos móveis, são 
baseados em modelos hierárquicos e muito se assemelham aos bancos 
de dados hierárquicos.
Veja, a seguir, um exemplo de conteúdo de arquivo XML:
<?xml version = “1.0”>
<obras>
<isbn>”8508028121”</isbn><titulo>”Teoria da 
informação”</titulo><autor>”Isaac Epstein”</autor>
<isbn>”0074605755”</isbn><titulo>”Modelagem de 
dados”</titulo><autor>”Peter Chen”</autor>
<isbn>”9788576059233”</isbn><titulo>”Sistemas de 
informação gerenciais”</titulo><autor>”Jane P. Laudon” 
</autor><autor>”Kenneth C. Laudon”</autor>
<isbn>”9788586846588”</isbn><titulo>”Microsoft SQL 
Server”</titulo><autor>” José Simão de Paula Pinto “ 
</autor>
</obras>
No exemplo, o conteúdo exibido fornece informações de um conjunto 
de obras (identificado pela marcação, ou tag, <obras>, ou seja, o 
metadado). As obras estão listadas entre os marcadores <obras> e 
</obras> (sendo que este segundo, precedido de /, indica o final do 
conteúdo). Cada obra é identificada por meio das marcações <isbn>, 
<titulo> e <autor> (e seus terminadores </isbn>, </titulo> e </autor>); o 
conteúdo entre aspas entre os terminadores, por exemplo 8508028121 
(para o caso de <isbn> e </isbn>), corresponde aos dados. Esse tipo 
de arquivo tem sido bastante utilizado para troca de dados, integração 
de sistemas e em aplicações na internet (por exemplo, as notas fiscais 
eletrônicas ou NF-es).
Álgebra relacional – simbolismo 
utilizado para representar as 
operações matemáticas que 
podem ser realizadas com 
conjuntos de relações (em nosso 
caso, tabelas). É a base para o 
funcionamento dos SGBD-R.
Arquivos binários – são os 
arquivos que armazenam os dados 
na forma de sequências de zeros e 
uns (0, 1).
33Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Do ponto de vista de uso, não deve ser levado ao usuário o conheci-
mento de questões relativas à organização interna do banco de dados. 
O utilizador deve possuir apenas uma boa interface para interação com 
as funcionalidades de que necessita. Porém, podemos concluir com a 
visão de que bancos de dados orientados a objetos e objeto-relacionais 
são mais próximos das metodologias de desenvolvimento orientadas a 
objetos; o modelo relacional é o mais tradicional no mercado e utilizado 
igualmente em aplicações orientadas a objetos e estruturadas. O modelo 
hierárquico possui alta performance, porém, exige programação específi-
ca para cada nova rota de acesso.
1.4.2.3 Atividade
Pesquise na internet dois SGBD-R pagos e dois gratuitos.
Resposta comentada
Exemplos de SGBD-R pagos, entre outros, são o Microsoft SQL 
Server, o IBM DB2 e o Oracle; entre os gratuitos destacam-se o 
MySQL e o PostgreSQL.
1.4.2.4 Níveis de abstração em bancos de dados
Quando falamos do desenho de um banco de dados, ou de outros 
sistemas de computação, devemos ter em mente que existem vários ní-
veis de pensamento, ou abstração, envolvidos: a tela de consultas que o 
usuário vai utilizar, os dados que serão armazenados e seus tipos (núme-
ros, letras) e comoserá armazenado fisicamente o arquivo que contém o 
banco, por exemplo.
A arquitetura sugerida pelo American National Standards Institute 
(ANSI) e Standard Planning and Requirements Comitee (SPARC) prevê di-
ferentes níveis de abstração. Veja de forma mais detalhada, a seguir:
Abstração – processo mental 
por intermédio do qual nos 
concentramos nos aspectos 
relevantes de um conjunto de 
objetos, desconsiderando suas 
diferenças.
Arquitetura – no contexto dos 
sistemas gerenciadores de bancos 
de dados, refere-se à forma de 
organização de suas estruturas 
internas e àquelas acessíveis aos 
usuários.
34 Planejamento e Elaboração de Bases de Dados
Figura 6 - Níveis de abstração na arquitetura de bancos de dados ANSI-SPARC
Fonte: Adaptado de Elmasri; Navathe (2004, p. 22)
Na representação dos níveis de abstração apresentada, notamos a 
existência de diferentes esquemas (ou modelos) em cada nível.
A imagem (Figura 6) é utilizada para dar uma visão geral da estrutura 
(ou arquitetura), sendo que as setas representam os fluxos de dados; os 
pequenos cilindros na base correspondem à forma usual de representa-
ção de conjuntos de dados.
Que tal vermos agora uma descrição de cada elemento?
Então, vamos lá:
a) Nível físico ou interno - descreve como um registro é armazenado 
(ex.: cliente). Neste nível, teremos as informações de localização 
do arquivo (ou arquivos) que compõe nosso banco de dados, seu 
tamanho etc. Um exemplo de nível físico é quando você guarda um 
arquivo no disco e precisa saber seu nome e local de armazenamento 
para acessá-lo: c:\windows\planilha.xls;
b) Nível lógico ou conceitual - descreve os dados armazenados em 
um banco de dados e relacionamentos entre os dados. Por exemplo, 
em uma linguagem de programação, poderíamos ter a definição de 
um tipo de dado para cliente declarado da seguinte maneira:
type cliente = record
nome : string;
rua : string;
numero : integer;
end;
Na representação, temos a palavra type que representa um novo tipo 
de registro (record) de dados, e essa definição termina com a palavra end. 
35Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
O ponto e vírgula é o terminador desse comando e é obrigatório. Os ter-
mos “nome”, “rua” e “numero” são os metadados, e as palavras string e 
integer representam os tipos de dados: a primeira indica que o conteúdo 
poderá ser formado por números e letras; a segunda, que somente são 
aceitos números inteiros;
c) Nível de visão ou externo - programas de aplicação escondem 
detalhes dos tipos de dados e também informação, para propósitos 
de segurança e facilidade de utilização (ex.: por lei, a informação 
sobre o valor do salário de um funcionário não é visível para todos 
os usuários, mas apenas aqueles que precisam dessa informação; já 
o nome é uma informação que pode ficar visível, mas seu tipo de 
dado e codificação no banco não).
Devemos notar que uma das finalidades dessa arquitetura é oferecer 
níveis crescentes de abstração e facilidade de uso. As camadas mais bai-
xas (no nível físico) devem trabalhar com a complexidade da manipulação 
dos bits/bytes dentro da máquina, algoritmos, programas; as mais exter-
nas (visão de usuários) somente utilizam os dados, sem se preocupar com 
como e onde estão armazenados.
Atenção
Nesta disciplina, vamos trabalhar, essencialmente, com o mode-
lo (ou esquema) conceitual. Note que, ao longo deste texto, mos-
traremos os sinônimos dos conceitos e daremos preferência a um 
deles. A existência de vários termos semelhantes deve-se às dife-
rentes nomenclaturas e interpretações de autores diversos, assim 
como às traduções. Não se preocupe, trabalharemos os mais usuais 
e, até o final desta disciplina, você conhecerá o necessário.
Por fim, os gerenciadores dos bancos de dados relacionais trabalham 
com relações, que seguem conceitos da teoria de conjuntos. Mas, na 
prática, as relações são chamadas de tabelas.
As tabelas são uma espécie de planilha, na qual as colunas corres-
pondem aos atributos da relação, ou seja, o conteúdo, os dados. Na 
prática, os atributos, as colunas de nossa planilha exemplo, são chama-
das de campos.
Na nomenclatura de bancos de dados relacionais, as linhas de nossa 
hipotética planilha são chamadas de tuplas, e correspondem a um con-
junto de todas as colunas que guardam relação entre si. São comumente 
chamadas de linhas.
36 Planejamento e Elaboração de Bases de Dados
Observe a imagem a seguir.
Figura 7 - Exemplo de tabela de banco de dados relacionais
Fonte: Produção do próprio autor
Dessa forma, ao trabalharmos com bancos de dados relacionais traba-
lharemos com tabelas compostas de colunas, que possuem muitas linhas 
de dados cadastrados. A tabela e as linhas compõem as informações, en-
quanto os campos representam os metadados. Por exemplo, poderíamos 
ter uma tabela de livros, com os metadados (colunas) autor, título, editora 
e ano. Cada linha dessa tabela corresponde ao conjunto de dados que 
fornece informações a respeito de um único livro.
Note na imagem (Figura 7) que o conteúdo cadastrado nas linhas 
(ou tuplas) 2 a 6 corresponde aos dados, contidos na tabela (ou relação) 
LIVROS, cujos metadados estão descritos no cabeçalho das colunas 
(chamadas em bancos de dados de atributos ou campos) da linha 1. Note 
também que as linhas 4 e 5 correspondem a algo que chamamos de 
redundância: para podermos ter mais de um autor, no modelo de planilha 
utilizado (e seria semelhante no desenho de um arquivo), optou-se por 
repetir as informações de ISBN e título. Uma alternativa seria pensar em 
termos de primeiro autor, segundo autor etc., em colunas separadas; mas, 
essa abordagem traria o incoveniente de termos várias colunas em branco 
para o caso de obras de um único autor, consistindo em desperdício.
A modelagem deverá levar em conta esse tipo de situação (veremos 
isso na Unidade 2). A solução adequada é termos uma tabela com 
os títulos de livros e outra com os nomes de autores, ligando-os por 
meio de um atributo comum, nesse caso, o ISBN. A arte desse tipo 
de desenho desenvolve-se por meio da normalização, mas não será 
abordada nesta disciplina, que é destinada a estudos introdutórios, 
dentro de 30h. Por fim, fechando os conceitos vistos, na planilha, 
cada célula pode ter uma formatação quanto aos tipos de dados 
que aceitará. Em um banco de dados, a primeira linha, que possui 
os metadados, e os tipos de dados aceitos em cada célula, estariam 
contidos no catálogo, conforme já explicado.
1.4.2.5 Tarefas do sistema gerenciador de bancos de dados
Já aconteceu de você estar fazendo uma transação via internet, como 
uma compra on-line e, de repente, a internet cair ou acabar a luz no meio 
da compra?
O que aconteceu em seguida?
37Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Você provavelmente ficou preocupado se a compra foi realmente rea-
lizada, se o valor foi corretamente debitado da sua conta ou se a compra 
não foi efetivada em virtude desse contratempo.
É justamente essa a tarefa de um gerenciador de banco de dados! 
Vamos conhecê-la melhor?
Figura 8 - Ao fazer uma compra via internet, você certamente estará interagindo com um 
banco de dados que estará gerenciando essa transação visando a assegurar a integridade 
lógica e física dos dados
Fonte: Flickr4
A garantia de integridade dos dados, lógica e física, é uma das res-
ponsabilidades do gerenciador de bancos de dados. A integridade lógica 
refere-se à modelagem correta e à manutenção dela por meio da imple-
mentação (por exemplo, as chaves); a física refere-se à integridade do 
conteúdo, dos dados. Considerando-se que, atualmente, os bancos de 
dados são um dos pilares das aplicações comerciais e, em diversas áreas 
do conhecimento, como a Biblioteconomia, essa característica torna-se 
primordial. Estima-se que mais de 90% das aplicações comerciais moder-
nas utilizem bancos de dados.
Nos bancos de dados relacionais, teremos a integridade garantida por 
meio de constraints, que são regras parao funcionamento do sistema. 
Entre elas, destacamos:
a) campos que não podem ter valor nulo ou campos cujo preenchimento 
é obrigatório;
b) limites de valores;
c) campos de valor único (que não podem ser duplicados na mesma 
tabela, como o CPF), que podem ser campos identificadores ou 
chaves, primárias e estrangeiras (às vezes, chamadas de secundárias).
4 FLICKR. Barn Images. Disponível em: https://www.flickr.com/photos/barnimages/21796692282/. 
Acesso em: 21 dez. 2018.
https://www.flickr.com/photos/barnimages/21796692282/
38 Planejamento e Elaboração de Bases de Dados
Observe a imagem (Figura 9) que segue.
Figura 9 - Síntese dos conceitos apresentados
Fonte: Produção do próprio autor
A partir da imagem (Figura 9), podemos revisar alguns conceitos apre-
sentados. A entidade (do mundo real) correspondente a um título de livro 
foi modelada a partir da relação (ou tabela) TITULOS, a qual possui os 
atributos ISBN (que é uma chave primária, Primary Key = PK) e TITULO.
Sempre que representarmos uma obra, ela será formada pelo con-
junto (tupla) de seus dois atributos (correspondendo a uma entidade do 
mundo real).
Como o ISBN é uma chave, ele não poderá ser duplicado nem suprimi-
do, nem poderá ser nulo (pois é um identificador, uma chave de acesso a 
uma certa tupla, um certo conjunto de dados, uma entidade).
O mesmo conceito ocorre com a relação correspondente aos AUTO-
RES, sendo, naquele caso, a chave primária o atributo CODIGO.
Já a relação Titulos_Autores só será formada no momento em que 
tivermos os títulos e os autores cadastrados; seus atributos, ambos cha-
ves estrangeiras (Foreign Key = FK), têm seus valores advindos de outras 
relações (TITULOS e AUTORES).
Dessa forma, é impossível cadastrar, por exemplo, um código de autor 
com valor zero, pois ele não foi cadastrado na relação de autores. Mas, 
por não ser uma chave primária, um mesmo valor pode ser repetido, uti-
lizado mais de uma vez (note na figura o caso do livro Sistemas de infor-
mação gerencial, ISBN = 9788576059233, que tem mais de um autor).
Da mesma forma, temos uma garantia de integridade no conjunto 
de dados, pois não podemos, por exemplo, apagar um autor ou um 
título, caso ele esteja em uso na relação que faz sua junção (tal opera-
ção poderia disparar um gatilho – trigger – informando que a operação 
39Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
não é possível em função da existência de valores em outra relação). 
Esse tipo de modelagem permite que se garanta a integridade e a não 
redundância da base.
Note que podemos cadastrar (inserir na relação ou tabela) os títulos e 
os autores de forma independente e em qualquer ordem, e descartá-los 
antes que sejam usados. Porém, no momento em que relacionarmos au-
tores e livros, o sistema garantirá que sempre exista esse relacionamento.
Por fim, observe que sempre haverá uma dupla metadado/dado (por 
exemplo ISBN e 9788576059233); o valor do dado terá sua integridade 
também garantida pelo tipo atribuído (por exemplo, somente números 
inteiros, caracteres etc.), não sendo permitido o cadastramento de dados 
incorretos. Na Unidade 2, estudaremos um pouco mais a respeito, mode-
lando entidades e seus relacionamentos.
Explicativo
Bancos de dados utilizam-se de constraints, que são restrições 
ou regras às quais o modelo é submetido para garantir sua integri-
dade. Por exemplo, ao informarmos que certo campo não pode re-
ceber valores nulos (not null) ou que seus valores devem ser únicos 
(unique), estamos utilizando esse conceito.
Na modelagem de bancos de dados, com frequência aparecem 
duas restrições que são parte essencial do relacionamento entre as 
tabelas, as chaves primárias e estrangeiras.
Definimos a chave primária (primary key) como sendo o atributo 
ou conjunto de atributos que permitem identificar unicamente uma 
relação (tabela). Nesse caso, não podem existir para esse atributo 
(esta coluna) dois valores iguais em tuplas (linhas) diferentes.
A chave estrangeira (foreign key) é a chave primária de uma 
relação exportada para outra. Por se tratar de uma representação 
de relacionamento entre relações, considerando uma repetição de 
relacionamento, ocorrerá uma repetição do valor desse atributo em 
tuplas diferentes. Às vezes, a chave estrangeira é chamada de se-
cundária, em oposição à primária.
Uma das atribuições da etapa de desenho lógico de um banco de 
dados é a criação de chaves primárias e secundárias de acesso aos dados. 
Essas chaves serão utilizadas não somente para auxílio na recuperação, 
mas também na garantia de integridade e na indexação. Por meio delas, 
o SGBD poderá manter as integridades: das entidades, de domínio, refe-
rencial e aquelas definidas pelo usuário. A imagem (Quadro 4), a seguir, 
resume alguns tipos de integridade garantidos pelas chaves (também co-
nhecidas como constraints e/ou keys).
Desenho lógico – é o desenho 
que representa logicamente as 
relações existentes entre os dados 
que estão sendo modelados. 
Por exemplo, uma entidade 
Editora ligada com todos os seus 
Autores e suas Obras (veremos 
detalhadamente na Unidade 2).
Indexação – corresponde a 
colocar em ordem os conteúdos 
dos atributos definidos em uma 
relação. Em sistemas de bancos de 
dados, podemos ter vários índices 
diferentes para uma mesma tabela, 
facilitando a recuperação dos 
dados (embora com implicação 
no momento da inserção, pois os 
índices devem ser atualizados). Por 
exemplo, podemos, em uma tabela 
de livros, ter índices para ISBN por 
ordem crescente e decrescente, 
por títulos em ordem alfabética ou 
alfabética inversa.
40 Planejamento e Elaboração de Bases de Dados
Quadro 4 - Tipos de integridade de dados em SGBDs
TIPOS DE INTEGRIDADE DE DADOS EM SGBDs
Tipo de integridade 
de dados
Garantida por 
meio de:
Descrição
Entidade
(Entity)
Chave primária
(Primary key)
Identificador único
(Unique constraint)
Atributo identidade
(Indentity attribute)
Define cada tupla (linha) em uma relação (tabela) como 
sendo única. A integridade de entidades é garantida 
(enforced) pela criação de atributos (colunas) identificadores 
em uma relação (tabela) e garantindo que os valores desses 
atributos (colunas) serão únicos por meio de uma chave 
primária (primary key), um identificador único (unique 
constraint) ou um atributo identidade (identity attribute).
Domínio
(Domain)
Tipos de dados
(Data type)
Nulabilidade
(Nullability)
Chave estrangeira
(Foreign key)
Valor padrão
(Default constraint)
Regra
(Check constraint)
A integridade de domínio visa a garantir que os dados de 
entrada em um atributo sejam validados pela limitação dos 
valores que podem assumir. Os tipos de dados que podem 
ser armazenados em um atributo é restrito pelos tipos de 
dados desse atributo. O formato dos dados é definido pelos 
valores das regras. A faixa de valores permitida para um 
atributo é especificada por meio de chaves estrangeiras, 
regras e constraints default.
Referencial
(Referential)
Chave estrangeira
(Foreign key)
A integridade referencial mantém a integridade dos dados 
por meio de ligação entre as relações (tabelas), testando-as 
quando tuplas (registros, linhas) são inseridas, apagadas ou 
modificadas. As ligações são definidas no projeto por meio 
das chaves primárias e estrangeiras.
Definidas pelo usuário
(User defined)
Regras
(Check constraints)
Gatilhos
(Triggers)
As regras definidas pelo usuário são baseadas nas regras de 
negócio específicas de cada banco de dados.
Fonte: Adaptado de Elmasri; Navathe (2006, p. 44-64)
Entre as tarefas a serem exercidas pelo SGBD, devemos também res-
saltar o aspecto transação, que corresponde a uma coleção de ope-
rações que realizam uma função lógica simples, em uma aplicação de 
bancos de dados.
O SGBD possui propriedades que visam a garantir a integridade 
dos dados durante uma transação, geralmente conhecidas como 
ACID: ATOMICIDADE; CONSISTÊNCIA; ISOLAMENTO; DURABILIDADE.
Os significados desses termos são:
a) Atomicidade éa característica de conclusão única (atômica) de 
todas as atividades dentro de uma transação. Por exemplo, se for 
necessário debitar uma conta e creditar outra, as duas operações 
farão parte de uma transação atômica: se uma não for realizada, a 
outra também não será, ou, se já foi, será desfeita;
41Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
b) Consistência é a obediência às regras estabelecidas, às constraints 
do banco. Por exemplo, se um campo for definido como UNIQUE 
(valor único), digamos para o CPF de uma pessoa, esse valor não 
poderá ser duplicado;
c) Isolamento quer dizer que as transações ocorrem sem se 
misturarem, cada uma independente da outra. Durante a execução 
de uma transação, os dados em uso ficarão travados para outras 
transações de forma a garantir que valores intermediários ou 
incorretos não venham a ser utilizados em outros processos;
d) Durabilidade é o propósito final da sequência de operações e 
refere-se ao fato de que, uma vez executada, a transação gera 
resultados definitivos e estáveis, os quais somente poderão ser 
alterados por uma outra transação.
Atenção
Lembre-se: o termo ACID refere-se às características necessárias 
a uma transação e correspondem ao principal objetivo do uso de 
SGBDs: Atomicidade; Consistência; Isolamento; Durabilidade.
Vejamos um exemplo. As informações de uma obra (por exemplo 
ISBN, título e autor) são obtidas a partir de uma tela única de cadastro 
(digamos uma página de entrada de dados na internet). Mas, devem ser 
gravadas em relações (tabelas) separadas, conforme exemplificamos an-
teriormente. Nesse caso, poderíamos realizar a inclusão da obra a partir 
de uma sequência de operações:
Início da transação;
Cadastrar o ISBN e título;
Cadastrar o codigo e autor;
Cadastrar a relação do título ao autor usando o ISBN e o código
do autor;
Fim da transação.
Então, a execução de uma transação garantiria o cadastramento 
completo da obra na base: o título, o autor e o relacionamento. Para o 
exemplo proposto, as três operações (cadastro do livro, do autor e do 
relacionamento) seriam executadas entre o início (BEGIN TRANSACTION) 
e o final da transação. Ou seja, atomicidade garantida. Mas, e se após 
cadastrar o ISBN e o título, ou em qualquer outro momento a conexão 
falhasse? Nesse caso, todas as operações realizadas durante a transação 
(entre o início e o fim) seriam desfeitas (ROLLBACK TRANSACTION), 
voltando o banco de dados à situação anterior, garantindo sua 
consistência (a qual também seria garantida pelos mecanismos de 
integridade do gerenciador, já que, por exemplo, não seria possível 
cadastrar um relacionamento de um título com um autor inexistente). 
42 Planejamento e Elaboração de Bases de Dados
Durante a execução dessa transação fictícia, outras com o mesmo acesso 
aos dados não seriam permitidas, evitando que os dados e/ou comandos 
se misturassem, nem seriam afetadas outras transações já realizadas, isto 
é, o isolamento. Por fim, se todas as operações da transação ocorrerem 
normalmente, ela será gravada definitivamente (COMMIT TRANSACTION) 
e as alterações realizadas permanecerão gravadas e disponíveis enquanto 
necessárias – durabilidade.
O SGBD é o responsável pela gerência de transações, por meio de 
seu gerenciador de transações, que é o componente que garante que 
o banco de dados permaneça consistente (correto) apesar de eventuais 
falhas de sistema (ex.: falta de energia, falhas no sistema operacional) e 
da execução de suas transações.
O gerenciador de controle de concorrência controla a utilização simul-
tânea de recursos, a concorrência entre diferentes transações do sistema, 
garantindo a consistência, enquanto o gerenciamento de armazenamen-
to é um módulo que provê interface entre os dados em baixo nível arma-
zenados pelo banco de dados e os programas de aplicação e consultas. É 
responsável pelas seguintes tarefas: interação com o gerente de arquivos; 
armazenagem eficiente para recuperação e atualização de dados.
1.4.2.6 Ambiente de rede e segurança
Consideraremos aqui que as operações realizadas com o SGBD serão 
executadas em um ambiente tipo Cliente/Servidor, no qual um programa, 
chamado cliente, envia requisições para outro programa, chamado ser-
vidor, localizado em um computador remoto, por meio de uma rede de 
comunicação. Observe a imagem, a seguir.
Figura 10 - Representação da comunicação pela rede no ambiente cliente x servidor
Fonte: Adaptado de Silberschatz, Korth e Sudarshan (2006, p.18)
Esse é o modelo básico utilizado na internet, no qual o cliente é o na-
vegador (browser) e o servidor é o programa que atende às requisições, 
por exemplo, um servidor de páginas HTML, como o Apache (PINTO, 
2001). Para o caso dos SGBDs, o servidor poderia ser um MySQL, um 
PostgreSQL, um Oracle, um DB2, um MS-SQL Server, entre tantos outros.
43Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Esse modelo também é adotado por quaisquer aplicativos que 
façam o uso do padrão Common Gateway Interface (CGI) para utilização 
de bancos de dados por meio da internet. Corresponde a um padrão de 
comunicação e troca de mensagens e formatos padronizados, os quais 
permitem que um navegador (por exemplo o Firefox) execute uma aplica-
ção em um servidor (por exemplo, um usuário consultando seus emprés-
timos em uma biblioteca), e receba os resultados (PINTO, 2001).
Devemos observar que as transações ocorrem em um ambiente de 
rede e, portanto, podem ser monitoradas. Isso implica pensar em aspec-
tos de segurança, como a utilização de criptografia e a identificação 
segura de usuários, além, obviamente, de uma boa política de senhas. 
Lembre-se de que o profisisonal de Biblioteconomia é um profissional de 
informação, e é responsável pela segurança e pela integridade desta.
Do ponto de vista do banco de dados, teremos sempre uma comuni-
cação com um cliente identificado. No início da conexão, será fornecida 
uma identificação e uma senha correspondente (para este, usualmente, 
chamado de login).
Figura 11 - O par login/identificador (user name) e senha (password), após o usuário 
fazer a digitação das informações nos respectivos campos e clicar no botão enviar 
(submit), estabelece a comunicação do cliente identificado com o servidor do banco de 
dados. Se uma das informações for digitada incorretamente pelo usuário, a conexão não 
será concretizada
Fonte: Flickr5
Após a conexão ser efetivada com sucesso, podemos armazenar todas 
as transações realizadas pelo usuário/cliente, o que inclui registrar quem 
realizou, em qual momento (data/hora) e o que fez. Isso é chamado de 
LOG.
Se o LOG será ou não armazenado e, se for, por quanto tempo são 
decisões que transcendem o projeto do banco de dados e enquadram-se 
nas normas e objetivos das políticas de informação da organização. 
Do ponto de vista funcional, devemos observar que armazenar todas as 
transações realizadas gera uma sobrecarga de trabalho para o gerencia-
dor e, evidentemente, um consumo de espaço de armazenamento e uma 
necessidade de cópias.
O cálculo foge ao escopo desta disciplina e do objetivo desta unidade, 
mas podemos estimar, a partir do número de transações e do número de 
usuários do sistema a quantidade de espaço que será ocupada – embora 
o armazenamento seja de forma compactada. E como o sistema tende 
a continuar a ser utilizado ao longo do tempo, essa quantidade tenderá 
a crescer indefinidamente, forçando o administrador do sistema a limpar 
os arquivos de tempos em tempos, eventualmente guardando cópias do 
que foi apagado – o que também se relaciona diretamente às políticas de 
segurança da organização.
5 FLICKR. Paul O’Rear. Disponível em: https://bit.ly/2LrxaWz. Acesso em: 21 dez. 2018.
Criptografia – é a operação 
de trocar os dados por outros 
seguindo uma chave secreta, 
de forma a impedir que sejam 
compreendidos. É bastante 
utilizada para a proteção de 
senhas e outras informações 
sensíveis.
Identificação segura de 
usuários – corresponde aoconjunto de mecanismos 
(incluindo-se hardware e software) 
utilizados para garantir que o 
usuário do sistema realmente seja 
o usuário cadastrado. A forma 
mais comum é o conjunto de login 
formado pelo par de identificação 
de usuário e senha, podendo ser 
ampliado por meio do uso de um 
token (uma espécie de pen drive 
que possui uma chave secreta para 
criptografia).
https://bit.ly/2LrxaWz
44 Planejamento e Elaboração de Bases de Dados
Quanto ao assunto cópias de segurança, esta é outra preocupação 
que o projetista do sistema deverá ter. Como e onde serão armazenadas e 
com que frequência serão realizadas as cópias e atualizadas são as razões 
de preocupação, porque, em caso de falha no sistema (de software, de 
hardware, por causa de ataques cibernéticos) deve haver uma forma de 
recuperar os conteúdos.
Será que os usuários devem ser responsáveis pela execução e pelo ar-
mazenamento das cópias de segurança dos bancos de dados?
Uma reflexão que ajuda a responder essa questão é a seguinte: você 
já perdeu algum arquivo por ter esquecido de fazer backup? De repente, 
aquele trabalho que você tinha de entregar para o seu chefe ou para a 
faculdade e, na hora da entrega, o arquivo estava corrompido ou com 
vírus... Se você tivesse feito uma cópia de segurança do arquivo em bom 
estado, isso provavelmente poderia ter sido evitado.
O mesmo acontece com os dados de um banco de dados. Não é 
aconselhável deixar nas mãos do usuário um procedimento tão crítico, 
melhor é deixar as atividades para um sistema automatizado ou para o 
pessoal técnico.
Nos ambientes organizacionais, o profissional responsável pela 
gerência dos sistemas de bancos de dados é conhecido como Data Base 
Administrator (DBA), ou administrator de bancos de dados.
Esse profissional coordena todas as atividades do sistema de bancos de 
dados e possui um bom entendimento sobre os recursos e necessidades de 
informação da empresa. Seus serviços incluem: a definição do esquema, 
a definição da estrutura de armazenamento e acesso, a modificação da 
organização do esquema físico, a delegação de autoridade de acesso ao 
banco de dados, a especificação de constraints de integridade, a atuação 
com os usuários, o monitoramento da performance e o atendimento 
às necessidades de melhoria (SILBERSCHATZ; KORTH; SUDARSHAN, 
2011, p. 18).
1.4.3 Desenvolvimento de sistemas e bancos de dados
Desenvolver sistemas de informação é uma arte e inúmeros são os 
problemas a ela relacionados. Bancos de dados incluem-se nessa situa-
ção, seja como parte de um sistema de informações, seja representando 
o próprio sistema.
Com o passar dos anos, diversos pesquisadores têm proposto 
soluções para resolver ou atenuar alguns dos problemas continuamente 
pesquisados e relatados e, para facilitar o desenvolvimento dos sistemas, 
como não atender os requisitos do negócio ou dos usuários e no tocante 
à documentação atualizada. Entre os tópicos comuns, estão o bom senso 
e a forte presença de técnicas de documentação (STAIR, 1998, p. 34; 
LAUDON; LAUDON, 1999, p. 43-44).
Uma das técnicas de documentação surgidas é a engenharia da infor-
mação, que procura ligar os conceitos de sistema de informação com as 
necessidades estratégicas de informação das organizações (MACHADO; 
ABREU, 2004, p. 8-9).
45Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Surgida nos anos 1980, essa técnica alinha-se às soluções atuais 
de modelagem de negócios descritas no Data Management Body Of 
Knowledge (DMBOK), no TOGAF, no Archimate, nas quais a participação 
das tecnologias da informação está fortemente ligada à estratégia da 
organização e à atenção ao usuário.
Explicativo
O termo DMBOK refere-se ao corpo do conhecimento em 
administração de dados, que para o livro é sinônimo de gestão da 
informação. O DMBOK apresenta dez funções a serem realizadas 
para garantir a governança da informação nas organizações. 
Entre essas funções, destacam-se a de gestão de dados mestres, 
metadados e de dados.
O TOGAF e o Archimate são modelos destinados à modelagem 
da arquitetura de informações das organizações com base em seu 
negócio principal, possuem objetivos semelhantes e apresentam 
estruturas (framewoks) para levantamento, conhecimento e gestão 
dos processos informacionais da organização, sendo que a ligação 
com a estratégia está sempre presente. Ou seja, não há implemen-
tação de soluções sem que exista um bom motivo estratégico, um 
objetivo, uma meta para a existência delas.
Em todos os casos é importante notar que existem usuários en-
volvidos no processo, seja para fornecer informações a respeito de 
um processo ou controle, seja como consumidores dos serviços que 
serão criados.
Já a engenharia da informação, segundo James Martin, citado por 
Nascimento (1993, p. 54) é o:
[...] conjunto de técnicas formais pelas quais os 
modelos de negócios, modelo de dados e modelo 
de processo são construídos em uma base de 
conhecimento compreensível e são usadas para 
desenvolver e manter sistemas de processamento de 
dados (NASCIMENTO, 1993, p. 54).
Assim como a informação tem um ciclo de vida, que vai de sua obten-
ção ao descarte ou armazenamento final, os sistemas possuem igualmen-
te um ciclo de vida. Em algum momento eles deverão ser substituídos, 
em geral, porque o negócio a que atendem mudou e sua implementação 
não é mais compatível, ou porque houve uma evolução tecnológica que 
deve ser incorporada.
Modelo de dados – descreve 
quais são os dados importantes 
para uma organização incluindo 
as entidades; os metadados; os 
tipos de dados; os proprietários 
e a origem dos dados; e, a 
temporalidade de atualização e o 
armazenamento.
46 Planejamento e Elaboração de Bases de Dados
Figura 12 - Ciclo de vida de um sistema de informação para modelagem de negócios, de 
acordo com Martin e Filkelstein (1984)
Fonte: Produção do próprio autor
Para Martin e Filkelstein (1984, p. 56-63), as fases do ciclo de vida de 
um sistema de informação são:
a) planejamento estratégico da informação – aqui se definem a 
missão e os objetivos da instituição, por meio de análise dos planos 
de negócios, objetivos e seus fatores críticos de sucesso, durante 
um período de tempo de (por exemplo) 3 a 5 anos. O resultado é o 
modelo de dados e o modelo funcional da organização. Entre as 
atividades requeridas encontram-se organizar e controlar o projeto 
de planejamento de sistemas de informação, definir as estratégias, 
desenvolver o modelo inicial de informações e o modelo detalhado, 
o perfil dos sistemas de informação existentes e criar os relatórios 
de necessidade de informação (em caso de dúvidas, retorne ao 
conteúdo da disciplina de Organização, Sistemas e Métodos).
Entre os produtos dessa fase, temos: o relatório de necessidade de 
informações, o modelo de informações institucionais, o relatório de perfis 
de sistemas de informação (levantamento de sistemas existentes, dados e 
outros recursos) e o plano de sistema de informação (definição de proje-
tos prioritários, com escalonamento de desenvolvimento).
b) análise das áreas de negócio – área de negócio é uma parte 
conceitual da organização responsável pela execução de um 
conjunto de atividades que produz resultados bem definidos. Para 
cada área de negócio encontrada no planejamento estratégico 
das informações, um modelo lógico é desenvolvido, descrevendo 
um fluxo de dados, conteúdo e política de negócios e projetos 
alternativos.
Modelo funcional – conforme 
visto na disciplina de OSM, 
descreve como a organização está 
estruturada, o seu organograma.
Necessidade de informação 
– corresponde a um estudo de 
usuários e suas necessidades de 
informação, tendo foco no modelo 
de dados, no funcional e nos 
sistemas de informação existentes.
Perfil dos sistemas de 
informação – em conjunto com 
o modelo de dados, descreve 
quais os sistemas de informação 
que a organização possui e suas 
finalidades.
47Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
É selecionada uma estratégiade implementação. Entre as atividades 
dessa etapa estão: organizar e controlar o projeto da análise das áreas de 
negócio; a definição da área de negócios e a divisão das áreas de negó-
cios, modelos existentes e modelos futuros; e, os requisitos de técnicas de 
documentação e abordagem de implementação.
Os produtos gerados nessa fase são: o modelo de informações para a 
área de negócios, os requisitos para a área de negócios, os relatórios de 
requisitos técnicos na área de negócios, a análise de lucros empresariais 
(se houver necessidade) e a abordagem da implementação na área de 
negócios (projeto inicial de sistema de alto nível).
A preocupação em como será implantado aquilo que foi definido na 
fase de análise. Os requisitos definidos pela análise das áreas de negócios 
são utilizados para produzir uma especificação detalhada de sistema. A 
participação do usuário é forte, assim como a utilização de protótipos. 
Uso de Linguagens de Quarta Geração (L4Gs).
c) projeto do sistema – refere-se ao planejamento do projeto, e 
ao projeto em si. As atividades necessárias são: organizar e controlar 
o anteprojeto de projeto do sistema, determinar a(s) tecnologia(s) 
de apoio, projetar as mudanças culturais, projetar os bancos de 
dados, projetar os sistemas de conversão, projetar os testes de 
sistema e projetar os programas de treinamento.
Os produtos dessa fase são: detalhar o projeto do sistema, a referência 
de usuário (protótipo de interfaces, procedimentos manuais, mudanças 
organizacionais), o projeto de sistema de conversão, o projeto de teste de 
sistema e o projeto de programa de treinamento.
d) construção do sistema – nessa fase, são gerados ou escritos 
códigos-fonte (ou L4G), testes, implantação de bases de dados, 
procedimentos de conversão de bases de dados, assim como o 
treinamento dos usuários e a implementação do sistema.
Suas atividades são: organização e controle do projeto e da 
construção, preparar a construção e testar o ambiente, implementar as 
especificações do projeto, implementar o desenvolvimento do produto, 
implementar o pacote de aplicação, compilar a documentação com o 
projeto de banco de dados e do repositório, desenvolver e conduzir 
o programa de treinamento, testar e instalar o sistema e passar para 
os usuários.
Essa fase gera os seguintes produtos: pacote de documentação de sis-
temas, banco de dados operacional, sistema operacional instalado, pro-
cedimentos de operação do sistema e programa de treinamento.
Em todas as etapas, a presença do usuário final é considerada 
fundamental, para que suas necessidades e requisitos sejam per-
feitamente compreendidos e atendidos.
Para que todos sejam envolvidos, deveremos:
a) determinar quais são os interessados (em inglês, stakeholders), 
selecionando os usuários mais experientes na área de negócio que 
será atendida e verificando quais são suas prioridades;
Sistemas de conversão – são 
utilizados para a conversão de 
tipos e estruturas de dados de um 
sistema para outro, por exemplo, 
na aquisição de um novo software.
Programas de treinamento – 
são as ações do RH em conjunto 
com a TI para garantir que tanto o 
pessoal técnico quanto os usuários 
saibam operar um sistema de 
informações.
Códigos-fonte – são as listas/
arquivos contendo os códigos dos 
programas e scripts gerados para 
a implementação de um programa 
ou de um sistema de informação. 
Modernamente são escritos em 
uma linguagem de programação 
tal como C ou JAVA (em caso de 
dúvidas, retorne ao conteúdo da 
disciplina de software livre).
48 Planejamento e Elaboração de Bases de Dados
b) verificar o organograma, o modelo de dados da organização e as 
políticas de segurança e de informação, mapeando as necessidades 
de informação e os requisitos de segurança;
c) verificar com os usuários selecionados quais são as implicações para 
suas áreas de negócio: o que poderia melhorar, quais problemas 
poderiam acontecer (mapear os riscos);
d) determinar se existem alternativas e documentar todas as 
informações obtidas e as decisões tomadas;
e) determinar com os usuários do sistema as reais necessidades de 
dados e informações a serem armazenados e obtidos do sistema 
(pode ser feito por meio de entrevistas, observações, análise de 
documentos, produção de casos de uso etc. — ver adiante neste 
material);
f) produzir uma visão integrada das entidades do mundo real 
envolvidas no processo e seus relacionamentos, originando um 
modelo que demonstre o que será armazenado em banco de dados 
(isso será abordado na Unidade 2);
g) analisar a necessidade de treinamento da equipe e produzir um 
plano para supri-lo, se for o caso.
Além da questão usuário, você notou que o primeiro passo descrito 
prevê o alinhamento estratégico da solução a ser implementada com as 
necessidades da organização?
A análise deve ser voltada às necessidades do negócio, de forma que 
as ferramentas e os processos de análise e modelagem de negócios, como 
Business Analysis Body of Knowledge (BABOK) e Business Process Model 
and Notation (BPMN), por exemplo, poderão ser fortes aliados. Qualquer 
que seja a ferramenta, porém, estará sujeita ao efetivo levantamento e 
compreensão dos dados e informações pertinentes.
1.4.3.1 Levantamento de dados e requisitos do sistema
Para modelar um banco de dados, deveremos levantar os requisitos 
necessários ao nosso modelo. Com nosso modelo queremos dizer o 
modelo que atenda às necessidades da instituição e, consequentemente, 
dos nossos usuários. Esse modelo é único para cada organização, existin-
do diferenças de dados e sua organização mesmo que os objetos sejam 
semelhantes: por exemplo, o modelo de uma universidade não é neces-
sariamente único, igual ao de outras universidades, apesar de todas tra-
balharem com alunos, professores e seus relacionamentos.
BABOK – corpo do conhecimento 
em análise de negócios: reúne 
as melhores práticas para 
descrever e analisar ambientes de 
negócio, registrando documentos 
e desenhos de entrada, 
ferramentas e técnicas, elementos 
e documentos de saídas. É 
uma boa fonte de informações 
para compreender os dados 
organizacionais e seus fluxos.
BPMN – notação para modelagem 
de processos de negócio: 
trata-se de uma técnica e um 
diagrama correlato que permite 
o desenho dos processos de 
negócio da organização segundo 
procedimentos padronizados, o 
que permite uma visão clara de 
como a organização efetivamente 
funciona e de quais são os dados e 
fluxos envolvidos.
49Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Figura 13 - Antes de planejar modelar um banco de dados, é preciso conhecer os seus 
futuros usuários. No caso de uma biblioteca de uma universidade, por exemplo, significa 
saber quem são as pessoas que a utilizam, para que fins e quais as suas necessidades, 
para entender de que modo o banco de dados poderia contribuir para facilitá-las
Fonte: Flickr6
Considerando que o levantamento de requisitos, também conhecido 
como elicitação de requisitos, é a etapa inicial de um projeto de sistemas, 
devemos ter em mente que o objetivo desse levantamento é a determi-
nação dos requisitos de negócio que a solução irá atender e quais neces-
sidades tem o usuário (ou usuários) do sistema.
No projeto do banco de dados, levantar requisitos significa 
determinar: quais saídas (consultas, relatórios) o banco de dados 
deverá atender; o que deve ser armazenado e o que deverá ser 
calculado (e como calcular) para atender às saídas necessárias; a 
forma de armazenar os dados e suas associações; e, os tipos de 
dados necessários e/ou compatíveis com a realidade em estudo.
Para tal, devemos definir: quem é ou quem são os usuários e quais os 
seus papéis.
O levantamento dos dados necessários à implementação de um siste-
ma de informação, do qual o banco de dados é uma das partes consti-
tuintes, passa pela análise de necessidades e requisitos dos usuários.
Independentemente da tecnologia ou da metodologia a ser utilizada, 
entra em cena o caráter científicodo levantamento de dados, por exem-
plo, com pesquisas documentais, análises de documentos e técnicas de 
coleta de dados.
Destacamos aqui a observação participante das rotinas dos usuários:
Situação de pesquisa onde observador e observado 
encontram-se face a face, e onde o processo de co-
leta de dados se dá no próprio ambiente natural de 
vida dos observados, que passam a ser vistos não mais 
como objetos de pesquisa, mas como sujeitos que in-
teragem em dado projeto de estudos (SERVA; JAIME, 
1995, p. 69).
6 FLICKR. Universidad de Salamanca. Disponível em: https://www.flickr.com/photos/
universidaddesalamanca/16717060027/. Acesso em: 21 dez 2018.
https://www.flickr.com/photos/universidaddesalamanca/16717060027/
https://www.flickr.com/photos/universidaddesalamanca/16717060027/
50 Planejamento e Elaboração de Bases de Dados
E, também, a pesquisa-ação, dada a necessidade de “[...] orientação 
para o futuro, facilitando a criação de soluções voltadas para um futuro 
desejável pelos interessados” e “[...] colaboração entre pesquisadores e 
clientes” (SUSMAN; EVERED, 1978, p. 589-590).
Figura 14 - É importante observar a rotina do usuário, seu modo de buscar informações 
e os tipos de informações pesquisadas, pensando em suprir as suas necessidades atuais, 
mas também orientadas para o futuro, pois os modos e as necessidades também são 
passíveis de mudanças com o passar do tempo
Fonte: Flickr7
Devemos ter em mente que o projeto de um banco de dados deverá 
levar em conta o que o casal Laudon e Laudon (1999, p. 149) chama de 
“[...] projeto de procedimentos e controle: especificar como cada aplica-
ção deve ser executada, bem como o que deve ser feito para reduzir a 
possibilidade de crimes e fraudes”. Tais especificações incluem auditoria, 
cópias de segurança e distribuição de saídas (o que se obtém e para quem 
será entregue), quem pode consultar, inserir, alterar e apagar os dados, 
assim como defirnir a quais dados cada um tem acesso.
Isso tem a ver com os processos e as políticas de informação da orga-
nização, que são as fontes de consulta para esses requisitos. Por exem-
plo, poderia estar definido para o caso de uma biblioteca: a consulta ao 
acervo é disponível para todos os usuários, porém sua manutenção (inser-
ção, alteração e exclusão, se for o caso) somente pode ser realizada pela 
bibliotecária. Da mesma forma poderia estar definido que todo usuário 
pode consultar seu histórico de empréstimos, porém somente a gestora 
da biblioteca poderá consultar os históricos de todos os usuários.
a) metodologia de casos de uso
Metodologias modernas, como a Unified Modeling Language 
(UML), consagram o papel do usuário iniciando a modelagem 
por meio dos chamados casos de uso (use cases) e a descrição de 
cenários, nos quais o sistema é visto sob a ótica de seu utilizador.
7 FLICKR. Videa. Biblioteca Nacional da Espanha. Disponível em: https://www.flickr.com/photos/
bibliotecabne/6573937711/. Acesso em: 21 dez. 2018.
A UML, linguagem de modelagem 
unificada, é formada por uma 
metodologia e um conjunto 
de diagramas que permitem 
documentar necessidades de 
informações a partir da visão do 
ambiente como sendo formado 
por objetos. A partir da visão e dos 
documentos oferecidos, fornece 
subsídios à implementação de 
sistemas de informação.
https://www.flickr.com/photos/bibliotecabne/6573937711/
https://www.flickr.com/photos/bibliotecabne/6573937711/
51Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Mas, onde estão essas informações? As fontes a serem utilizadas para 
o levantamento de requisitos incluem: desenhos e descrições de proces-
sos de negócio, fluxogramas, diagramas de blocos, documentos da or-
ganização, entrevistas com usuários, observação de seu trabalho e docu-
mentos utilizados e observação das rotinas.
Um diagrama cuja descrição é uma boa fonte de informações é o caso 
de uso, da notação UML (Figura 3). Os diagramas de casos de uso são 
bastante utilizados atualmente para a modelagem de sistemas, e um de 
seus méritos é possibilitar o envolvimento dos usuários no processo 
de modelagem: na definição de entidades, de dados, de necessidades, de 
formatos, de responsabilidades e direitos sobre os dados e informações 
gerados e armazenados.
Vamos ver um exemplo?
Observe a imagem (Figura 15) a seguir.
Figura 15 - Exemplo de diagrama de casos de uso
Fonte: Produção do próprio autor8
A imagem (Figura 15) representa um diagrama de casos de uso de um 
sistema de biblioteca hipotético. No diagrama, os atores que participam 
da interação com o sistema são representados pelos bonecos, os quais 
estão ligados aos usos que fazem do sistema (os casos de uso, represen-
tados por elipses) por meio de linhas.
De forma resumida, a construção de diagramas de caso de uso passa 
pelo desenho do contexto e sua posterior documentação (conforme vis-
to no exemplo em páginas anteriores). Para isso, primeiro determinam-
-se quais são os atores: quem vai interagir com o sistema? Seus usuá-
rios e seus administradores. No exemplo anteriormente apresentado, os 
atores foram resumidos em bibliotecário e usuário, que são duas classes 
diferentes de atuação, e também têm a ver com as citadas políticas de 
informação da organização. Depois são determinadas as ações princi-
pais a serem realizadas; no exemplo anterior, foram: cadastrar usuário, 
livro e autor, e emprestar e devolver livros; esses são os casos de uso do 
sistema (a figura, então, corresponde a um diagrama de casos de uso).
8 Produção do próprio autor utilizando o programa Umbrello.
52 Planejamento e Elaboração de Bases de Dados
A seguir, são ligados os casos (representados por elipses) aos atores 
correspondentes (representados por bonecos). Note que nem todos os 
atores possuem acesso a todos os casos de uso, implicando a imple-
mentação das políticas de informação e de segurança da informação. 
Finalizado o desenho, cada caso de uso será explicado (o que poderá 
levar à revisão do desenho e da descrição).
Quando utilizamos a metodologia de elaboração de casos de uso, é 
possível (e altamente recomendável) envolver os usuários do sistema, tan-
to para o desenho da usabilidade de pretendem ter quanto para termos 
noção da descrição de como gostariam de utilizar o sistema. Dessa forma, 
nenhuma funcionalidade desejada será esquecida.
Após o desenho, cada caso de uso será descrito em forma textual, 
no tocante às suas particularidades. Uma estrutura possível para essa 
descrição é: identificação do caso de uso; descrição resumida de sua 
finalidade; pré-condições, ou seja, o que deve ocorrer antes de o caso 
de uso ser utilizado ou executado; fluxo principal, contendo a sequência 
de operações a serem realizadas; fluxo alternativo, correspondendo, se 
for o caso, às ações a serem realizadas, caso o fluxo principal não possa 
ser executado; fluxo de exceção, o qual mostra as ações em caso de 
problemas; e, as pós-condições, ou seja, como ficará o sistema após a 
execução do caso de uso. Do texto descritivo do caso de uso, retiram-se 
as informações de modelagem.
Veja a seguir um possível descritivo de um dos casos de uso.
Caso de uso: Devolve livro
Descrição resumida: o usuário do sistema de biblioteca devolve 
o livro previamente emprestado e o controle de empréstimos é 
atualizado, juntamente com o de livros à disposição.
Pré-condições: pelo menos um livro emprestado
Fluxo principal:
a) o usuário devolve o livro ao bibliotecário;
b) o bibliotecário escaneia o código de barras do livro devolvido;
c) o bibliotecário confirma a devolução.
Fluxo alternativo:
a) o bibliotecário digita o código do livro devolvido.
Fluxo de exceção:
a) o sistema informa que o código informado não existe.
Pós-condições: as tabelas de empréstimo e disponibilidade são 
atualizadas pelo sistema.
Note que a descrição desse exemplo é bastante resumida, mas ofere-
ce uma estrutura para pesquisa dos dados necessários à implementação 
do sistema. Nesse caso, sabemos que devemos trabalhar, minimamente, 
com ocódigo do livro; que haverá operação de devolução (que pressupõe 
a de empréstimo prévio), de usuários e operadores do sistema previamen-
te cadastrados e identificados, de atualização de tabelas em bancos de 
dados para efetivar as transações.
53Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Segundo Larman (2004, p. 23-24), a partir de uma descrição textual, 
podemos extrair informação útil à modelagem por meio da seguinte téc-
nica (por exemplo, a partir da análise do descritivo de um caso de uso):
a) sublinhar substantivos para identificar conceitos no domínio do 
problema;
b) usar os substantivos sublinhados para criar conceitos no modelo 
conceitual;
c) poderão ser utilizados alguns dos substantivos, se eles identificarem 
tipos de dados simples, para criar os atributos dos conceitos, assim 
como os adjetivos;
d) criar associações entre os conceitos.
Ao utilizarmos essa técnica, surgirão naturalmente os verbos nas fra-
ses analisadas. Já que os mesmos correspondem a ações, sua aparição 
dá origem a processos, funções ou métodos, conforme a metodolo-
gia em uso. Em bancos de dados, representam as operações a serem 
realizadas com os dados e podem dar origem a procedimentos armaze-
nados (stored procedures).
Por exemplo, vejamos o seguinte texto: O usuário toma empresta-
dos livros da biblioteca; os livros são identificados por seu ISBN, que é 
único, e pela combinação de título e autor, podendo ainda possuírem 
diferentes edições.
Desse texto, podemos verificar que temos identificados o livro e o 
usuário, os quais relacionam-se por meio do empréstimo. Já na descrição 
do livro, temos seu ISBN, seu título, seu autor, sua edição, que são cara-
terísticas importantes da entidade livro.
Exemplificando, vamos imaginar uma situação comum, uma compra 
de mercadorias. Vamos a um supermercado e escolhemos alguns itens 
nas prateleiras. Depois, no caixa, ao passarem as mercadorias pelos leito-
res de códigos de barras, os códigos e descrições dos produtos podem ser 
impressos no cupom fiscal. Também no cupom será impressa a quantida-
de de itens e, em função dela, será calculado o preço daquele conjunto 
de itens, em função do preço unitário deles. Por último, o terminal Ponto 
de Vendas (PDV) calcula os totais e os impostos envolvidos na transação. 
Tudo rápido, automático e transparente para o cliente. Mas, de onde vem 
isso tudo? De um banco de dados, ou de mais de um, claro. Analisando 
o breve enunciado (descrição do procedimento), vemos que apareceu a 
palavra calcular.
Nem tudo o que teremos de apresentar em uma saída, por exemplo, o 
preço total de um conjunto de itens adquiridos, deverá necessariamente 
ser ou estar armazenado. Há muitas situações nas quais, para economizar 
espaço em disco, não iremos armazenar os dados, mas sim obtê-los a 
partir de outros dados. Por exemplo, armazenamos as parcelas e calcu-
lamos o total em uma venda, ou armazenamos as obras e calculamos o 
total de obras emprestadas.
Há situações intermediárias entre desempenho e dados de históricos, 
que geram grande número de consultas, nas quais poderemos ter uma 
tabela que especificamente traga dados calculados ou sumarizados 
a partir de outras tabelas. Essa condição é mais comumente utilizada 
quando temos dados históricos de consulta frequente, por exemplo, 
54 Planejamento e Elaboração de Bases de Dados
quantos livros foram emprestados por mês no ano anterior? Nesse caso, 
é melhor calcular os valores para cada mês e para cada ano anterior, e 
armazená-los, já que não mudarão.
Lembre-se de que o seu projeto do banco de dados deverá levantar 
essas situações e documentar os conteúdos utilizados para a tomada de 
decisões no projeto e a situação final.
Definir o que será armazenado e o que será calculado é uma decisão 
que você tomará ao longo do projeto de seu banco de dados.
1.4.3.2 Participação do usuário
A partir do final da década de 1960 e do início até o meio da década de 
1970, surgiu a discussão referente à chamada crise do software, relativa 
aos projetos de sistemas que apresentavam problemas de orçamentos e 
prazos não cumpridos e de qualidade baixa no produto entregue, em 
especial por, muitas vezes, não atender aos requisitos necessários.
Muitos estudos foram realizados e surgiu, como possível resposta, a 
disciplina e as técnicas da engenharia de software. Foram desenvolvidas 
e/ou aprimoradas diversas metodologias e processos para atender ao ci-
clo de vida do software, do levantamento inicial de requisitos, passan-
do por modelagem, projeto, implementação, instalação e manutenção. 
Cada vez mais, os estudos mostraram que a participação do usuário era 
essencial para a garantia da qualidade do produto final.
Dentro dessa evolução de pensamento, as metodologias passam a não 
somente dar cada vez mais importância à participação do usuário, mas tam-
bém passam a tentar garantir essa participação ao longo de todo o processo.
Ao desenvolvermos um novo sistema, então, deveremos 
primeiramente selecionar um usuário, ou um grupo deles, para 
colaborar no processo. Nessa escolha, definiremos o que podemos 
chamar de usuário padrão: aquele que conhece bem o negócio que 
estamos informatizando, que será seu principal usuário.
Figura 16 - A identificação dos usuários padrão e sua colaboração são fundamentais 
para a elaboração da modelagem do banco de dados
Fonte: Flickr9
9 FLICKR. Bibliotecas Redondela. Disponível em: https://www.flickr.com/photos/
bibliotecasredondela/11212147513/in/photostream/. Acesso em: 21 dez. 2018.
https://www.flickr.com/photos/bibliotecasredondela/11212147513/in/photostream/
https://www.flickr.com/photos/bibliotecasredondela/11212147513/in/photostream/
55Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Selecionados os colaboradores, verificaremos como será a interação 
com eles: entrevistas, reuniões, elaboração conjunta de modelos, utiliza-
ção comum de ambientes virtuais para troca de informações, análise de 
documentos, observação. A combinação das técnicas varia de organiza-
ção para organização e conforme o andamento do projeto.
Uma boa forma de começar o envolvimento é pedir ao seu usuário 
que descreva, da forma mais exata possível, o que ele precisa e como 
ele vê a solução que o atende. O usuário será auxiliado nessa tarefa pelo 
modelo de documentação de sistemas adotado na organização. Para fa-
cilitar, a UML, por exemplo, utiliza os casos de uso, de forma que se possa 
deixar que o próprio usuário retrate, no momento inicial, como ele vê o 
sistema a ser desenvolvido.
Mas, há outras formas:
a) solicite ao seu usuário que desenhe um relatório (saída) ou o 
resultado de uma consulta que deseja que o sistema ofereça. 
Analisando os dados de saída, você poderá detectar o que será 
necessário como entrada, seja para armazenar, seja para calcular. 
Por exemplo, dados de entrada poderiam ser os ISBNs dos livros 
emprestados; e, os dados de saída, os 10 títulos mais emprestados 
em ordem decrescente;
b) peça ao usuário que esboce a cópia de uma tela de entrada de dados 
ou um formulário. Nesse caso, ele estará fornecendo os dados e 
entidades que lhe são importantes. A partir dele, pode ser efetuada 
a modelagem conceitual, que também pode ser confirmada com o 
usuário (isso será visto na próxima unidade);
c) converse com o usuário pedindo que ele lhe explique o que ele 
faz e que informações ele utiliza. O que ele precisa fazer com 
essas informações? Organizá-las, tabular, contar, gerar outras? A 
conversa pode ser uma entrevista estruturada ou não estruturada, 
desde que sejam registrados os pontos principais;
d) seu usuário já possui um sistema não informatizado que ele 
utiliza para controle de seus afazeres? Nesse caso, deverá haver 
documentos que podem ser analisados para a verificação dos 
conteúdos a serem informatizados;
e) podemos utilizar a observação dos processos realizados pelos seus 
usuários, com acompanhamento e registro das rotinas e dados 
necessários para realizá-las;
f) outra formaé a observação participante, na qual você fará o papel 
do usuário do serviço e tentará identificar e registrar os pontos 
importantes. Colocar-se no lugar do outro pode esclarecer muitas 
coisas; porém, você deverá ter algum domínio das rotinas/processos 
a realizar. Nesse caso, é bom contar com o apoio de um usuário 
padrão e com uma boa revisão.
Uma vez levantados os dados, você deverá tomar cuidado para não 
cometer um erro clássico: não informatize o que não é o melhor; se há 
falhas percebidas ou melhorias a executar, faça isso antes de colocar a 
situação em um sistema ou banco de dados.
Outra situação a evitar é não se ater ao presente: hoje funciona as-
sim, portanto, vamos informatizar assim que o negócio será atendido. 
Não, nem sempre. Alguns sistemas levam tempo considerável para serem 
56 Planejamento e Elaboração de Bases de Dados
entregues, e os negócios são dinâmicos. Procure sempre enxergar o 
futuro: como gostaríamos que fosse essa solução?
Após a realização do modelo, virá sua implantação. Nas unidades se-
guintes, serão dados exemplos de desenho e implementação de bancos 
de dados.
Nessas duas fases, a participação do usuário continua a ser importan-
tíssima, pois teremos primeiro o modelo, o roteiro a ser seguido para a 
implementação do sistema, que deve ser validado.
Figura 17 - A participação do usuário é central no processo, desde a concepção, 
passando pelo desenho, pela implementação e pela validação de um banco de dados
Fonte: Flickr10
Quando o banco de dados for efetivamente criado, poderemos ainda 
lançar mão da metodologia de prototipagem: um modelo funcional será 
entregue ao usuário que realizará críticas e testes sob acompanhamento, 
garantindo que, uma vez instalado, ele efetivamente cumprirá o papel 
para o qual foi concebido.
1.4.3.3 Breves considerações a respeito da tecnologia
Por fim, uma vez determinado que é necessário um banco de dados, 
assim como o que será armazenado nele e as operações necessárias, de-
vemos realizar um estudo da sua viabilidade tecnológica, relativa às con-
dições necessárias para a implantação e a manutenção da solução ao 
longo do tempo. Esta última garante a disponibilidade e a continuidade 
do negócio, do processo e das informações que serão requeridas do sis-
tema ao longo do tempo.
10 FLICKR. Jisc infoNet. Disponível em: https://www.flickr.com/photos/jiscinfonet/287757737/. 
Acesso em: 21 dez. 2018.
https://www.flickr.com/photos/jiscinfonet/287757737/
57Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Essa análise é importante, pois devemos ter em mente que a implan-
tação de um sistema em geral não é tarefa rápida; uma solução não pode 
ser substituída de pronto por outra, sempre há um estágio de planeja-
mento, implantação e adaptação. Assim, é importante fundamentar as 
escolhas de forma a garantir que aquilo que for escolhido continue fun-
cionando sob condições originalmente previstas por algum tempo (em 
geral, 2 a 5 anos).
Algumas das perguntas a serem feitas, e respondidas, são:
a) Já existe uma solução pronta?
b) Quanto custa?
c) Vale mais a pena comprar ou desenvolver?
d) Qual é a complexidade envolvida?
e) Dominamos a tecnologia?
Independentemente de a solução ser comprada ou desenvolvida, de-
vemos considerar que tipos de equipamentos são necessários, qual siste-
ma operacional deve ser usado, qual é a competência das pessoas envol-
vidas, se há a necessidade de treinamento e de suporte e, claro, qual é o 
custo de tudo isso.
As decisões passarão pela questão da tecnologia proprietária x livre, 
que o aluno já teve em outra disciplina deste curso. Mas não custa lem-
brar que “livre” não significa “sem custos”, e que “pago” não significa 
necessariamente “continuidade de negócio”, nem que o valor pago ini-
cialmente cobrirá todas as manutenções futuras.
1.4.4 Os níveis de abstração e a modelagem do banco 
de dados
Ao trabalharmos com bancos de dados, termos de lidar com o nível de 
abstração a ser utilizado, referente às diferentes visões que um mesmo 
projeto de banco de dados pode apresentar. Essas visões referem-se aos 
níveis conceitual, lógico e físico, e correspondem às visões dos diferentes 
interessados envolvidos no processo, usuários de níveis diferentes:
a) analistas de negócio;
b) clientes e fornecedores;
c) programadores;
d) administrador de bancos de dados.
Cada uma dessas visões dará origem a esquemas (ou diagramas) di-
ferentes, os quais simbolizam, em síntese, a mesma realidade. Veja na 
imagem (Figura 18) a seguir.
58 Planejamento e Elaboração de Bases de Dados
Figura 18 - Representação da sequência de projeto de bancos de dados
Fonte: Adaptado de Elmasri e Navathe (2011, p. 132)
Na imagem (Figura 18), vemos que o banco de dados depende de 
seu projeto físico, que corresponde às estruturas dos dados que serão 
armazenados. O projeto físico, por sua vez, depende da visão de relacio-
namentos lógicos que são abstraídas a partir da visão conceitual. Desta-
caremos aqui o projeto conceitual.
O modelo conceitual corresponde ao ponto de vista do projetista, e 
do usuário, e facilita o entendimento do modelo da organização, tornan-
do o projeto final mais estável. Esse modelo independe do SGBD, o que 
facilita modificações.
Por possibilitar uma visão comum entre projetista e usuário, um mo-
delo facilita a comunicação e, consequentemente, o entendimento para 
obter o produto desejado, além de auxiliar no controle do projeto.
A modelagem visa a resolver questões relativas à necessidade de in-
formação da organização, tais como: quantos funcionários trabalham na 
seção de vendas, ou quantos não tiraram férias em janeiro, ou que tipo 
de produtos os clientes compram nos meses de inverno?
A imagem (Figura 19) a seguir, representa a ligação entre as infor-
mações disponíveis na organização e sua representação em modelagem 
conceitual. Note que a origem do modelo vem da modelagem das infor-
mações importantes ao usuário/organização.
Figura 19 - Criação de um modelo conceitual a partir dos requisitos do usuário
Fonte: Adaptado de Machado e Abreu (2004, p. 24)
59Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Enfim, a modelagem conceitual atua na identificação da funcionalida-
de e dos dados necessários para um sistema, e na determinação da me-
lhor forma de agrupamento dos dados. Essas atividades não dependem 
de um sistema gerenciador de bancos de dados específico! São atividades 
que geram um modelo, uma representação, aplicável a quaisquer siste-
mas de processamento de dados e informações (incluindo os não infor-
matizados). Observe que a modelagem é o processo que leva ao modelo 
conceitual, e ela tem como entrada o conjunto de informações fornecido 
pelos usuários do sistema. Para a modelagem de um sistema de bibliote-
cas, devemos pensar em quais serão seus usuários, entrevistá-los, obter 
informações de sistemas já existentes (incluindo não informatizados) e, a 
partir daí, esboçar o modelo e submetê-lo a críticas/validação.
Trata-se de um processo de modelagem de dados que tem por es-
sência transformar um universo infinito de informações em um universo 
finito e relacionado de entidades. Atua capturando a visão estática de um 
problema ou situação.
Explicativo
Modelagem de dados é o “processo de estruturar as infor-
mações do mundo real segundo um modelo de dados” e tem por 
objetivo obter um bom modelo, que garanta transações corretas e 
eficientes. Transação é a “execução de um programa que acessa ou 
modifica o conteúdo de um banco de dados”.
1.4.5 Atividade
Imagine que você, como bibliotecário, foi solicitado a 
acompanhar o projeto de desenvolvimento de um SGBD para a 
sua biblioteca. Na etapa inicial do projeto, você, como usuário, 
foi convidado a desenhar a tela inicial do sistema envolvendo o 
empréstimo e devolução de livros.
Desenhe no espaço a seguir a tela de como você imagina a 
sequência de empréstimo e devolução de livros.
60 Planejamento e Elaboração de Bases de Dados
A partir do seu desenho,responda às seguintes questões:
Qual é a importância de você, como bibliotecário, fazer parte da 
equipe de desenvolvimento de um novo SGBD para uma biblioteca?
A partir do seu desenho, identifique o que seria um dado, um 
metadado e um tipo de dado.
Nesta etapa, o seu desenho representa que tipo de visão do 
banco de dados? Justifique.
Resposta comentada
Com relação à questão (a), a sua participação no desenvolvi-
mento de um SGBD para a sua biblioteca seria fundamental, consi-
derando que vimos que uma etapa do projeto é justamente envol-
ver os diversos tipos de usuário para que identifiquem o processo 
e suas respectivas necessidades para que o sistema possa melhor 
atender às demandas. Em resposta à questão (b), fizemos um dese-
nho genérico apenas para ilustrar como você poderia ter desenha-
do. Em nosso desenho, os metadados seriam o código do usuário 
e o ISBN do livro, os dados seriam o código do usuário e o número 
do ISBN, e os tipos de dados seriam números inteiros para ISBN e 
61Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
o mesmo (ou caracteres alfanuméricos) para o código do usuário 
(isso pode variar, de acordo com a organização em estudo). Um 
bom identificador para o usuário poderia ser seu CPF, formado por 
11 números inteiros. Por fim, na questão (c), o tipo de visão que o 
seu desenho representa é a das informações que serão utilizadas 
para a elaboração do modelo lógico, porque identificam os me-
tadados de algumas das entidades que participarão do processo 
de empréstimo e de devolução, que constituirão uma entidade de 
relacionamento entre as anteriores. Note que o desenho de telas 
somente fornece informações, não o modelo lógico que será utili-
zado por trás, o qual será construído a partir dessas informações.
Observação: ao desenhar a tela, você está indiretamente intera-
gindo com pelo menos três entidades do banco de dados: a entida-
de usuário, que representa as pessoas; a entidade livro ou obra, que 
representa o objeto físico à disposição do usuário; e, o relaciona-
mento que você quer dar a eles: empréstimo ou devolução. Embora 
a concepção da tela seja simples, na verdade, o banco de dados, ao 
receber os dados relativos ao código do usuário e ao ISBN deverá:
a) testar primeiramente para verificar se ambos existem, retor-
nando um erro se um dos dois ou ambos estiverem incorre-
tos;
b) verificar se é um empréstimo; e, nesse caso, armazenar as 
informações de qual usuário tomou emprestada qual obra;
c) se for devolução, pesquisar na tabela de empréstimos a 
combinação usuário e ISBN e marcar como devolvido. Isso 
sem contar que pode haver uma tabela de reserva a ser con-
sultada antes, para verificar se a obra de fato está disponível.
De qualquer forma, desenhos de tela são úteis para envolver os 
usuários no processo. Um MER capaz de representar parcialmente 
o que foi aqui apresentado poderia ser:
CONCLUSÃO
O enorme conjunto de funcionalidades e características pertinentes 
aos SGBDs é que lhes dá a amplitude de aplicações que hoje possuem. 
Em especial, note que a complexidade referente à execução das tarefas 
de controle e garantia dos bancos de dados por eles gerenciados não fica 
visível aos usuários, os quais, em contrapartida, não precisam ter profun-
62 Planejamento e Elaboração de Bases de Dados
dos conhecimentos de ciência da computação para utilizá-los. Basta saber 
informar o modelo e executar as consultas. Isso será visto na sequência 
desta disciplina. Mas, para chegarmos às consultas e, antes, no modelo, 
precisamos levantar as informações necessárias, e documentá-las bem.
Nas unidades seguintes desta disciplina, criaremos modelos e os trans-
formaremos em um banco de dados funcional, ou seja, naquele pronto 
para uso pelos usuários, cujo modelo foi validado e está pronto para 
utilização. O início da modelagem, porém, depende dos conceitos vistos 
nesta unidade, para o levantamento dos dados necessários à estratégia 
de negócios.
Por isso, lembre-se de que suas fontes de informação principais serão 
a documentação do negócio e seus processos e os usuários que fazem 
parte destes, seja no papel de alimentadores de dados e informações, 
seja no papel de consumidores ou clientes finais.
RESUMO
Bancos de dados fazem parte das aplicações que nos prestam serviço 
em nosso dia a dia. São controlados por sistemas gerenciadores, resultan-
do na sigla SGBD. Os mais utilizados atualmente são os relacionais, e seus 
gerenciadores são chamados SGBD-R.
Os SGBDs trabalham basicamente armazenando, transformando e re-
cuperando dados, parte básica e com significado limitado, definidos pe-
los metadados, que descrevem os atributos e tipos, tais como numéricos 
ou caracteres. Essas operações visam à obtenção e ao gerenciamento de 
informações, coleções ou interpretações dos dados, agora ligados a um 
significado útil em certo contexto.
Nos bancos de dados relacionais (SGBD-R), as entidades de negócio 
serão representadas por tabelas, as quais possuem colunas, que definem 
os metadados de interesse. As linhas das tabelas conterão dados, que, 
em conjunto, são chamados também de informações (por exemplo, uma 
linha em uma tabela de pessoas representa o conjunto de informações de 
uma pessoa específica).
O gerenciamento das informações leva à formalização dos conheci-
mentos organizacionais, que, se introduzidos nos ambientes informacio-
nais, nos sistemas de informação, garantem um bom ciclo de vida aos 
dados de interesse.
Na implementação de bancos de dados serão utilizadas restrições 
(constraints) para garantir sua operação íntegra dentro do modelo pro-
posto. Entre os exemplos de restrições comumente utilizadas, temos de-
clarações para impedir que sejam cadastrados valores nulos, ou seja, que 
deixemos certo campo essencial sem preenchimento, para garantir unici-
dade de valores e das chamadas chaves: a chave primária, que identifica 
unicamente uma entidade, e a chave estrangeira, utilizada para o rela-
cionamento entre as diversas entidades do sistema (as entidades serão 
implementadas na forma de tabelas).
63Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Na modelagem de bancos de dados, com frequência aparecem duas 
restrições que são parte essencial do relacionamento entre as tabelas, as 
chaves primárias e estrangeiras. Definimos a chave primária (primary key) 
como sendo o atributo ou conjunto de atributos que permitem identificar 
unicamente uma relação (tabela). Nesse caso, não podem existir para esse 
atributo (essa coluna) dois valores iguais em tuplas (linhas) diferentes. A 
chave estrangeira (foreign key) é a chave primária de uma relação expor-
tada para outra. Por se tratar de uma representação de relacionamento 
entre relações, considerando uma repetição de relacionamento, ocorrerá 
uma repetição do valor desse atributo em tuplas diferentes.
Os gerenciadores trabalham garantindo o controle de transações, que 
são as operações submetidas aos SGBDs que devem ser processadas e de-
volvidas. Por funcionarem em ambiente de rede, atualmente em especial 
na internet, devemos ter um bom projeto de segurança ao implementá-
-los, pois informações essenciais à organização poderão estar envolvidas.
As transações devem atender aos preceitos do termo ACID: respeitar 
a Atomicidade (conclusão única ou atômica de todas as atividades dentro 
de uma transação), a Consistência (obediência às regras estabelecidas 
para o banco), o Isolamento (cada transação ocorre em seu espaço sem 
misturar-se a outras) e a Durabilidade (o propósito final, gerar resultados 
estáveis ao final da sequência de operações). Essas garantias são imple-
mentadas pelo SGBD.
Os bancos de dados são implementados a partir de um modelo con-
ceitual, o qual analisa os metadados, os dados e as informações da orga-
nização, para depois sugerir suas associações. Como visam a atender à 
organização e todos os seus usuários, a participação destes é fundamen-
tal.
Outro ponto importante a ser considerado é no tocante ao domínioda 
tecnologia que será utilizada e no seu custo, tanto de aquisição quanto 
de manutenção. Uma vez que dados da organização tenham sido inseri-
dos em um SGBD, ele terá que ser mantido.
Vale lembrar que a participação do usuário é muito importante para a 
modelagem de um banco de dados, desde a concepção, passando pelo 
desenho até a implementação e o teste do sistema.
UNIDADE 2
PLANEJAMENTO E DESENHO DE 
BANCOS DE DADOS POR MEIO DE 
MODELAGEM CONCEITUAL
2.1 OBJETIVO GERAL
Apresentar conceitos e técnicas de planejamento e desenho de bancos de dados por meio da MER, 
realizando exercícios de levantamento e desenho de MER para que o aluno possa colocar em prática 
seus conhecimentos.
2.2 OBJETIVOS ESPECÍFICOS
Espera-se que, ao final desta unidade, você seja capaz de:
a) compreender o modelo entidade versus relacionamento, MER, e sua importância;
b) elaborar um MER;
c) avaliar as implicações de um modelo incompleto.
2.3 PRÉ-REQUISITOS
Antes de iniciar, é recomendável que você leia o Apêndice A, para que possa obter orientações sobre 
como instalar e utilizar um programa de modelagem, de modo que sua leitura possa ser mais produtiva.
67Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
2.4 A MODELAGEM COMO 
UM MODO DE VER A 
REALIDADE
Você já parou para pensar no planejamento de sua vida? O que espe-
ra estar fazendo daqui a cinco anos? Planeja se casar, ter filhos, exercer 
a profissão de bibliotecário, fazer concurso, ser professor, trabalhar em 
uma grande empresa?
Isso significa que você tomou um modelo como padrão para seguir e 
adotar na sua vida, ou seja, traçou um plano e estratégias para alcançar 
os seus objetivos e obter resultados esperados, de acordo com as suas 
necessidades profissionais e pessoais.
O mesmo raciocínio pode ser aplicado quando pensamos em termos 
de modelagem de banco de dados.
Mas o que significa modelar? Segundo o dicionário Michaelis, modelar 
é “fazer o modelo ou o molde de algo, tomar como modelo” (DICIONÁRIO 
MICHAELIS, 2009).
Assim, podemos modelar praticamente todas as situações! O 
interessante desse processo é que, ao modelar, você começa a perceber 
as relações entre as coisas, o tipo de relação, as prioridades e como se 
encaixam para construir a realidade de acordo com os parâmetros que 
você estabeleceu.
Em praticamente tudo podemos aplicar o modo de ver pautado na 
modelagem de dados, por exemplo, as ações do cotidiano como fazer 
compras no mercado, o planejamento de um casamento e as atividades 
profissionais, entre outras.
E então, está curioso para saber mais sobre modelagem?
Nesta unidade, veremos conceitos e técnicas de modelagem concei-
tual, com foco no modelo entidade versus relacionamento.
2.5 MODELO ENTIDADE 
RELACIONAMENTO – 
MER
Largamente utilizado no projeto de sistemas de informação, o Modelo 
Entidade Relacionamento (MER) foi introduzido por Peter Chen em 1976 
(MACHADO; ABREU, 2004) e acabou por tornar-se um padrão de fato 
para modelagem conceitual (o projeto conceitual de BDs). Portanto, o 
MER é um modelo para a representação do modelo de dados que será 
implementado em um banco de dados.
68 Planejamento e Elaboração de Bases de Dados
Ele é independente de aspectos de implementação e não representa 
procedimentos ou fluxos de dados existentes. Trata-se de uma visão está-
tica na análise de sistemas de informação.
Não depender de aspectos de implementação quer dizer que serve 
para qualquer banco de dados em qualquer sistema. Por não represen-
tar os fluxos de dados, e sim o relacionamento entre eles, dá uma visão 
estática não importando no modelo o que ocorre antes ou depois. Por 
exemplo, devemos cadastrar antes o autor ou antes o livro? Isso é uma 
situação a ser respondida pelo processo de negócio.
Para começar, que tal vermos uma representação gráfica do que seria 
um MER? Então, observe a imagem a seguir.
Figura 20 - Representação gráfica genérica do Modelo Entidade x Relacionamento (MER)
Fonte: Adaptado de Heuser (2009, p. 8-9)
Na imagem (Figura 20), as formas geométricas representam as partes 
que constituem o modelo do MER.
A representação gráfica do modelo muda ligeiramente de uma ferra-
menta de desenho para outra ou entre autores, mas sempre há uma for-
ma de representar seus componentes principais. Um modelo é composto 
basicamente de:
a) entidades, que são representadas por retângulos;
b) atributos, que são representados por elipses ou pequenos círculos;
c) relacionamentos, que são representados por losangos.
Também podem ser representadas Restrições sobre relacionamentos, 
como Cardinalidade (1 e n, na Figura 20), Participação e Persistência (ou 
seja, ficar gravado). Por exemplo, uma restrição poderia ser: uma editora 
pode editar vários livros, mas um livro só pode ser editado por uma edito-
ra (caracterizando a participação de 1 para n, 1 editora para vários livros 
e vários livros para 1 editora).
Note que você pode desenhar à mão um modelo de SGBD, mas é pre-
ferível contar com uma ferramenta para auxílio e documentação.
Para a implementação de um bom banco de dados é necessário um 
bom projeto. Nosso projeto inicia-se com o modelo de entidades que 
fazem parte do problema sob modelagem, e de seus relacionamentos, 
conjunto representado pelo MER. Portanto, é muito importante que você 
saiba representar o MER relativo à situação que você está modelando, por 
69Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
exemplo, sua biblioteca. Por fim, observe que o MER às vezes é chamado 
também de modelo ER (substituindo-se o M pela palavra modelo por 
extenso e mantendo o ER ao final).
2.5.1 Entidades
As Entidades que compõem o MER são as coisas que existem no 
negócio, ou descrevem o negócio, e que, sobre as quais, queremos 
guardar informações. Representam uma classe de dados do negócio 
(concreta ou abstrata).
O retângulo é utilizado para referência a um objeto em particular, uma 
instância ou ocorrência da entidade que pretendemos representar. Exem-
plos: funcionários, departamentos, alunos, contas, livros.
Entidades podem ser classificadas como fortes, fracas ou associativas. 
Veja a descrição de cada uma delas na imagem (Quadro 5), a seguir.
Quadro 5 - Tipos de entidades e suas descrições
Tipos de Entidades
Forte Fraca Associativa
Tem ocorrência forte 
quando podemos 
identificar a entidade 
por meio de um atributo 
dito chave.
É aquela que possui 
um alto grau de 
independência 
no tocante à sua 
identificação e existência 
em relação às demais.
A entidade é chamada 
de fraca quando o 
conjunto de entidades 
não possui atributos 
suficientes para formar 
a chave primária de 
identificação, ou 
quando possui grande 
dependência de uma 
entidade forte, sem a 
qual não pode existir.
Ela não consegue 
manter-se sozinha, 
mesmo possuindo um 
identificador.
As entidades associativas 
são aquelas decorrentes 
da existência de duas 
ou mais entidades e, 
como sugere o nome, 
são destinadas a 
associar dados de outras 
entidades.
Esta entidade 
tipicamente existe em 
função de duas os 
mais outras entidades, 
e corresponde a um 
relacionamento entre 
elas.
Exemplo:
O atributo CPF é 
capaz de identificar 
unicamente (distinguir) 
uma entidade pessoa 
dentro de um conjunto 
de entidades pessoa 
(podemos utilizar um 
conjunto de atributos 
para formar a chave, 
se for necessário. Por 
exemplo: nome-e-
sobrenome + data-
nascimento + nome-da-
mãe).
Exemplo:
Embora cada ingresso 
em um cinema seja 
único, não podemos 
identificá-los unicamente 
(novamente, podemos 
combinar atributos para 
formar um identificador, 
caso necessário; e, 
também pode ser 
utilizado um atributo 
advindo de outra 
entidade).
Exemplo:
A entidade turma, que 
relaciona dados de 
uma disciplina com os 
alunos que a cursam 
em uma modelagem de 
processos acadêmicos.
Fonte: Produção do próprio autor
70 Planejamento e Elaboração de Bases de Dados
2.5.2 Atributos
Os Atributos são as características ou propriedades das entidadesou 
dos seus relacionamentos. Correspondem a características ou qualidades 
que descrevem as entidades. Para a entidade Funcionário, por exemplo, 
os atributos poderiam ser:
a) matrícula;
b) nome;
c) endereço;
d) data de admissão;
e) salário.
Atributos podem ou não ser determinantes (identificadores) ou 
Chaves: quando determinam unicamente a ocorrência de uma entidade. 
Por exemplo, o ISBN identifica (ou determina) um livro unicamente: 
não existem dois livros com o mesmo ISBN e cada ISBN identifica (ou 
determina) um e somente um livro.
Em relação à Atomicidade, um atributo poderá ser:
a) atributo simples ou atômico, por exemplo, o nome da pessoa;
b) atributo composto ou complexo (pode ser uma hierarquia), por 
exemplo, um endereço, que é composto de logradouro, número, 
cidade etc.
Em relação a seus Valores (ou conteúdo), um atributo poderá ser:
a) atributo monovalorado (de valor único), por exemplo, o gênero 
(femino/masculino);
b) atributo multivalorado (que pode assumir mais de um valor válido), 
por exemplo, o número de telefone (mais de um comercial, 
residencial, mais de um celular).
No momento em que trabalharmos com o banco de dados (na Unidade 
3 desta disciplina) vamos nos deter em um valor especial possível aos 
atributos, o valor NULO (em inglês, null), que corresponde à ausência 
daquele dado.
Em relação ao seu Armazenamento, um atributo poderá ser:
a) atributo armazenado, tal como o nome da mãe de uma pessoa;
b) atributo derivado, ou calculado, tal como o total de um pedido, 
uma vez fornecidos os valores unitários dos itens que o compõem.
Conforme sugere o nome, um atributo derivado é obtido a partir de 
outros atributos existentes no banco de dados e, portanto, deve ser pla-
nejado de antemão, não somente quanto à sua existência, mas também 
quanto à forma de cálculo. Por exemplo, se tivermos armazenadas as da-
tas de empréstimo e de devolução de um item na biblioteca, poderíamos 
ter, se necessário, o atributo a ser calculado dias_em_atraso; e, sua fór-
mula de cálculo poderia ser: fazer a diferença entre a data de devolução 
e a data de empréstimo, calculando-a em dias.
Atributos derivados podem ser omitidos de um modelo ER (o mesmo 
que MER), porém, podem ser úteis para melhorar a eficiência do banco 
71Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
de dados. Exemplo: idade (calculado a partir da data atual — data de 
nascimento); número de empregados (calculado contando-se quantos 
registros ativos há no banco). Em geral, a decisão de mantê-los no es-
quema físico do SGBD ocorre após a fase de normalização (que não 
será abordada nesta disciplina).
Figura 21 - Representação de uma entidade e seus tipos de atributos
Fonte: Adaptado de Heuser (2009, p. 38)
E como saberemos quais são as entidades necessárias e seus atributos? 
Aqui é vital a participação do usuário (releia o tópico 1.3.3.2, na Unidade 
1): ele será o principal utilizador e conhece o negócio e suas regras. Dessa 
forma, use-o como fonte de informações e também para tirar dúvidas.
Explicativo
Modos de representação
Há mais uma questão para você prestar atenção: embora exis-
tam normas, a representação gráfica dos diferentes modelos de 
um banco de dados, executada por diversas ferramentas de mode-
lagem, não segue um padrão: há pequenas ou grandes diferenças 
entre elas. Para complicar, existe confusão entre os próprios mo-
delos. Nesta disciplina serão apresentados alguns exemplos, com 
seleção de alguns para elaboração das explicações.
Normalização – trata-se de uma 
sequência de passo usada para 
reduzir a redundância e melhorar 
a consistência do armazenamento 
de dados no banco. Por exemplo, 
em vez do armazenamento de um 
endereço com rua e número no 
mesmo atributo, pode ser utilizado 
o atributo CEP para definir a rua (e 
a cidade e o estado), e o número 
pode ser um outro atributo.
72 Planejamento e Elaboração de Bases de Dados
2.5.3 Relacionamentos
Vamos ver outra maneira de representar o esquema?
A imagem (Figura 22) a seguir apresenta uma forma de representação 
MER mais voltada à compreensão física das entidades, pois já trabalha 
com os tipos de dados a serem utilizados.
Figura 22 - Exemplo de representação MER no programa Ferret
Fonte: Produção do próprio autor11
Na imagem (Figura 22), as abreviaturas E correspondem a Entidades 
enquanto os R são Relacionamentos. Na prática, implica na diferenciação 
prévia entre entidades fortes e fracas, ou seja, dão uma ideia da indepen-
dência (ou não) das relações exibidas: usuário e livro são independentes, 
não precisam de outra entidade para existirem; já a relação empresta só 
existe no momento em que um usuário tomar um livro emprestado.
Que modelo você deverá utilizar? Que norma seguir?
Não há uma resposta, pois cada organização tem a liberdade de 
adotar o seu modelo ou norma (pense no caso das normas ABNT para 
apresentação de trabalhos e suas adaptações em cada instituição, por 
exemplo). Procure o padrão de documentação de sistemas de sua or-
ganização. Se não existir, é uma ótima oportunidade de criá-lo, não é 
mesmo? Por exemplo, podem ser utilizados documentos da UML, ou 
diagramas que representem os MER. Veja na disciplina Organização, 
Sistemas e Métodos o tópico relativo a manuais.
Qualquer que seja o modelo criado para representar a situação real ao 
qual o banco de dados atenderá, ele deverá ser livre de redundâncias e 
não dúbio. Isso significa que:
a) aspectos temporais relativos aos dados devem ser pensados e 
estar presentes na modelagem: por exemplo, é necessário guardar 
o histórico de uma certa situação ou somente o aspecto atual/o 
último interessa?
b) haverá necessidade de tomada de decisões, as quais impactarão no 
modelo criado e em sua utilização e utilidade futuras. Infelizmente 
não há uma regra geral que permita atender a todas as variações, de 
forma que, a escolha, por exemplo, por um relacionamento versus 
uma entidade ou por um atributo em vez de uma especialização, 
serão decisões de cada um. Somente a experiência irá mostrar a 
melhor alternativa. Mas, lembre-se: documente.
11 Elaborado pelo autor no programa Ferret.
73Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
De forma geral, pensando-se exclusivamente em bancos de dados re-
lacionais, uma boa prática é tentar evitar a utilização de atributos opcio-
nais, os que possam ser calculados, e multivalorados quando possível, 
pois facilita a normalização e melhora o desempenho.
A seguir, veremos alguns exemplos com vistas a melhor ilustrar esses 
conteúdos. Então, vamos lá!
2.5.4 Formas de modelagem MER – Relacionamentos
A imagem (Figura 23), a seguir, representa um conceito importante, 
relativo à especialização/generalização de uma entidade. A especialização 
ocorre quando uma entidade possui tipos, como a Pessoa do exemplo, 
que pode ser tanto uma pessoa física quanto uma pessoa jurídica. A ge-
neralização é a leitura inversa, ou seja, dado que existem pessoas físicas 
e jurídicas, foi criado uma pessoa genérica que representa os dois tipos. 
A especialização ocorre na leitura de cima para baixo, a generalização na 
leitura de baixo para cima.
Figura 23 - Exemplo de generalização e especialização
Fonte: Produção do próprio autor
Na imagem (Figura 23), a entidade Pessoa foi especializada em Usuário 
e Autor (assim como em outro caso poderia tê-lo sido em Física e Jurídica).
Observe que a entidade Pessoa possui:
a) os atributos:
i. CPF (que é um atributo do tipo identificador). Veja como ele está 
destacado no diagrama. Outra forma usual de destacar a chave 
é sublinhando-a);
ii. Nome.
b) as duas especializações: 
i. Usuario (que possui o atributo matrícula);
ii. Autor (que possui o atributo nacionalidade).
74 Planejamento e Elaboração de Bases de Dados
Esse tipo de modelagem, na qual ocorre a generalização (Pessoa) e a 
especialização (Usuario e Autor), é bastante utilizada no mundo da pro-
gramação orientada a objetos. Assumimos que, já que a Pessoa possui 
um nome,automaticamente, tanto autores quanto usuários também o 
possuem. Vamos continuar essa modelagem e verificar o que pode acon-
tecer na sequência. Veja a imagem (Figura 24), a seguir:
Figura 24 - Exemplo de modelagem com especialização
Fonte: Produção do próprio autor
Agora temos, em nossa imagem (Figura 24), a representação de duas 
associações: Empréstimo e Autoria.
Também surgiu uma nova entidade: Livro, identificada pelo ISBN, e 
com o atributo título.
Note que nossa modelagem permite que um usuário tome empres-
tado de nenhum a muitos livros (notação 0,n no diagrama, próximo à 
entidade Livro, significando desde nenhum -0-, até muitos -n-), que um 
livro esteja emprestado para nenhum ou um usuário (notação 0,1 no dia-
grama, próximo à entidade Usuario).
Da mesma forma, um livro poderá ter sido da autoria de um ou mais 
de um autor (1,n), ao mesmo tempo que um autor poderá ter a autoria 
de nenhum a muitos livros. Nenhum? Pois é, nesse modelo admitimos 
que poderemos cadastrar autores que não possuem livros... se isso não 
for necessário, ou se estiver incorreto em nosso modelo, deveremos 
alterá-lo. Esses números e letras entre parênteses referem-se ao concei-
to de cardinalidade.
Cardinalidade é a forma pela 
qual expressamos as relações de 
quantidades que podem existir 
entre as entidades modeladas. 
Por exemplo: se em nosso modelo 
de negócios um usuário pode 
tomar emprestado até 3 livros na 
biblioteca, então a cardinalidade 
existente entre usuário e 
empréstimo será 0..3.
Isso significa que, em qualquer 
momento, o usuário poderá 
ter tomado emprestado desde 
nenhum até, no máximo, 3 livros.
As relações da cardinalidade não 
são aleatórias, elas são definidas 
pelos requisitos de negócio/dos 
usuários.
75Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Ainda com atenção à imagem (Figura 24), no que se refere ao emprés-
timo do livro em si, poderemos:
a) descobrir qual livro está emprestado para qual usuário;
b) atualizar a tabela correspondente aos empréstimos e modificar 
a pessoa que está com o livro, ou deixá-la em branco, de forma 
a registrar que o livro não está emprestado e, portanto, está 
disponível.
Mas, e se quisermos ver um histórico de todos os empréstimos que 
um usuário realizou, ou dos empréstimos que um livro teve? Essas situa-
ções, o nosso modelo não atende, pois não há uma forma de registrar o 
histórico dos fatos.
Façamos agora uma discussão. No modelo da Figura 24 não parece 
haver situações problema em relação à autoria dos livros, porém, pode-
remos ter uma situação a administrar quando um autor for também um 
usuário. Em princípio, o modelo permite que tanto autores sejam usuários 
quanto usuários possam transformar-se em autores. As informações bási-
cas (CPF, nome e outras que queiramos incluir) podem ser incluídas como 
atributos das entidades. Mas, existiria uma forma diferente de realizar a 
modelagem aqui proposta? Vamos ver na imagem (Figura 25), a seguir.
Figura 25 - Modelagem de associações entre as entidades pessoa e livro
Fonte: Produção do próprio autor
Na imagem (Figura 25), as especializações da entidade Pessoa foram 
eliminadas. O que define se a pessoa em questão é um autor de livro 
ou um usuário de empréstimo é a existência do relacionamento autoria 
ou do relacionamento empresta, sendo que ambos podem ocorrer 
simultaneamente.
Note que, dessa vez, o relacionamento de empréstimo possui um atri-
buto data, que foi definido como identificador, fazendo com que, em 
uma mesma data, o livro somente possa ter um empréstimo (será que isso 
atende ao seu modelo?).
Da mesma forma, o relacionamento de autoria recebeu o atributo 
ordem, podendo-se definir, no caso de mais de um autor, a ordem de 
autoria do livro. Poderia, ainda, haver um atributo para identificar a 
Pessoa como autor, como usuário ou como ambos.
76 Planejamento e Elaboração de Bases de Dados
Observe que a Figura 24 e a Figura 25 referem-se à modelagem 
da mesma situação geral (embora alguns atributos tenham sido 
propositalmente adicionados para serem introduzidos no estudo). 
Modelagens diferentes darão origens a bancos de dados 
diferentes, obviamente; mas isso não significa que uma atenderá 
às necessidades de negócio e outra não; trata-se, apenas, de formas 
diferentes de ver a mesma realidade.
Figura 26 - British Museum Library e Magee Public Library. Modelar significa entender as necessidades de cada instituição e 
modelar os dados de acordo com as necessidades dessa instituição e de seus usuários, que podem ser muito diferentes de uma 
organização para outra
Fonte: Flickr12
Quando trabalhamos em grupos ou equipes é comum que surjam tais 
discrepâncias, afinal, as idiossincrasias das pessoas diferem. Para solucio-
nar entraves entre uma visão e outra, recomenda-se que sejam verifica-
dos, primeiramente, se os modelos atendem às necessidades do negócio 
e de seus usuários e, posteriormente, adotar um consenso, e segui-lo.
As entidades podem também relacionar-se com elas mesmas, dado 
que existem situações no mundo real em que isso ocorre. Isso é chamado 
de autorrelacionamento. Veja a próxima imagem (Figura 27).
Figura 27 - Exemplos de autorrelacionamento entre as entidades
Fonte: Produção do próprio autor
12 FLICKR. Luzabass. Disponível em: https://www.flickr.com/photos/luzabass/4581347305/. Acesso em: 21 dez. 2018.
 FLICKR. PROCMRLS Photos. Disponível em: https://www.flickr.com/photos/cmrlsphoto/8676200892/. Acesso em: 21 dez. 2018.
https://www.flickr.com/photos/cmrlsphoto/8676200892/
77Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Na imagem (Figura 27), temos os seguintes exemplos:
a) a entidade Pessoa possui o relacionamento de Casamento com 
outra entidade Pessoa (poderíamos especificar, ainda, se é de 
esposo ou esposa);
b) a entidade Pessoa possui um relacionamento é chefe de com a 
própria entidade Pessoa, cuja cardinalidade é de 0,n, ou seja, uma 
pessoa poderá ser chefe de nenhuma até várias pessoas;
c) a entidade Livro possui um relacionamento com ela mesma por 
meio da associação Coleção, sendo que o livro pode participar de 
nenhuma ou de uma coleção (0,1), e uma coleção poderá ter desde 
1 até muitos livros (1,n).
A diferença que existe entre uma representação e outra será refletida 
na implementação: poderá ser realizada como sendo um campo na tabe-
la que representa a entidade (exemplo é chefe de, na entidade Pessoa) 
ou como uma nova tabela (Casamento, Coleção).
Como campo (atributo), poderia ser assim:
Figura 28 - Exemplos de entidade
Fonte: Produção do próprio autor
Note que a tabela teria previsões de campos para cadastrar os possí-
veis relacionamentos (CPF da esposa, do esposo, do chefe), os quais fica-
riam em branco no caso de eles não ocorrerem (pessoas solteiras, pessoas 
que são o chefe mas não possuem nenhum chefe).
No caso de tabelas separadas, teríamos algo como:
Figura 29 - Exemplos de relacionamento
Fonte: Produção do próprio autor
Note que aqui somente serão cadastradas na tabela de chefia aqueles 
que possuem chefes (e para o caso de casamentos teríamos outra tabela).
A tabela completa do primeiro caso tem a vantagem de produzir al-
gumas consultas mais simples, porém contendo vários campos que talvez 
não sejam utilizados. A segunda opção é mais usual, porém exigirá uma 
consulta mais elaborada com grande utilização das, já vistas, chaves pri-
mária e estrangeira.
78 Planejamento e Elaboração de Bases de Dados
Até este ponto, vimos exemplos de relacionamentos binários, ou 
seja, entre duas entidades. Mas, não é impossível que existam relaciona-
mentos entre mais de duas entidades, configurando, por exemplo, rela-
cionamentos ternários, quaternários ou n-ários.
Vamos supor a seguinte situação: na modelagem de um congresso 
científico, um artigo submetido poderá ter vários autores, porém, cada 
autor somente poderá submeter um artigo. Desejamos saber a ordem 
de autoria. O artigo deve estar ligado a um dos temas do congresso, que 
possui um editorcapaz de distribuir os artigos para avaliação. Cada ava-
liador deverá realizar a avaliação de um ou mais artigos, e os artigos serão 
avaliados por um ou mais avaliadores. O avaliador poderá ser o próprio 
editor ou um dos autores de artigos. As datas de distribuição da avaliação 
e da sua realização devem ser conhecidas. A imagem (Figura 30) a seguir 
apresenta uma modelagem dessa situação.
Figura 30 - Exemplo de MER contendo relacionamento quaternário
Fonte: Produção do próprio autor
Note que, na imagem (Figura 30), surgiu uma entidade associativa, 
Avaliação, que possui um relacionamento quaternário. Essa entidade 
deverá primeiramente registrar os artigos e seus temas e, posteriormente, 
a distribuição dos avaliadores efetuada pelo editor. Como esse exemplo 
pretende demonstrar somente a entidade associativa, não foram apre-
sentados no diagrama os demais atributos, para maior clareza.
Pense: você conseguiria melhorar essa representação? O que você 
mudaria? Por exemplo, você poderia pensar em transformar a entidade 
avaliador em um atributo (tipo sim/não, é/não é para as entidades autor 
e editor.
79Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
2.6 DESENHO DE 
BANCOS DE DADOS 
BASEADO NO 
MODELO ENTIDADE 
RELACIONAMENTO 
(MER)
Agora vamos praticar a modelagem Entidade Relacionamento (ER).
É importante que os dados a serem armazenados no banco sejam 
detalhados, pois, caso contrário, poderão ocorrer situações dúbias ou in-
completas, que não atenderão às necessidades dos usuários.
Vejamos um exemplo.
A descrição, a seguir, corresponde às necessidades parciais de negó-
cio: deverá haver uma forma de cadastrar o consumidor e seus dados 
básicos, a compra efetuada contendo descrição e seu valor e a forma de 
pagamento.
O que, exatamente, significa dados básicos? Como será realizada a 
descrição do que foi comprado? Quais são as formas de pagamento pos-
síveis? Vamos detalhar melhor essa situação no estudo de caso 1, a seguir.
Multimídia
Para saber mais sobre modelagem de banco de dados, você 
poderá visitar o link indicado e conhecer uma ferramenta freeware 
voltada para o ensino de modelagem em banco de dados relacional 
com base na metodologia defendida por Carlos A. Heuser no livro 
Projeto de bando de dados, no seguinte endereço: http://sis4.com/
brModelo.
2.6.1 Atividade
Imagine que você faz parte da equipe de projeto do banco de 
dados de uma nova editora. A necessidade do momento é criar um 
MER que represente a relação entre os autores e suas obras. Para 
http://sis4.com/brModelo
http://sis4.com/brModelo
80 Planejamento e Elaboração de Bases de Dados
isso, crie um MER no qual estejam representadas as entidades autor 
e obra, sendo que o relacionamento deverá armazenar o ano da 
edição. Apresente o atributo chave e pelo menos mais um atributo 
que represente uma caracaterística que você acha importante para 
as entidades autor e obra.
Resposta comentada
Cada pessoa deverá ter um pensamento ligeiramente diferen-
te da outra, não existe uma solução única. Uma possível solução 
seria pensar na entidade Autor com o identificador sendo o CPF 
e como um atributo essencial o nome; na entidade Obra teríamos 
como identificador o ISBN e como atributo essencial o título. Uma 
entidade que relaciona as duas poderia ser a autor_obra (que te-
ria como chave estrangeira o CPF e o ISBN) e teria como atributo 
próprio o ano da edição. O desenho do MER ficaria assim:
Note que os atributos identificadores (CPF e ISBN) estão subli-
nhados, para destaque.
2.6.2 Estudo de caso 1: modelagem de uma situação de 
compra e venda
A partir da análise de documentos e de conversas com o gerente, le-
vantou-se a situação hipotética, apresentada a seguir.
Um consumidor será cadastrado no banco de dados com seu nome 
completo; endereço composto por logradouro, número, complemento, 
CEP, cidade e estado; seu CPF, que será o identificador; seus telefones 
celular, residencial e comercial, todos com DDD; seu e-mail; uma identifi-
cação para uso do sistema, contendo o par login+senha.
Os produtos terão um código, uma descrição textual e um valor unitá-
rio. As formas de pagamento possíveis, contendo um código e a descri-
ção. A compra efetuada, identificando-se qual foi o consumidor, o que foi 
comprado em que quantidade e qual foi o valor total da compra.
A partir dessa descrição, deve ser produzido um MER. Na imagem (Fi-
gura 31) a seguir, você verá uma solução não definitiva (que será criticada 
adiante).
Como atividade, pratique em uma ferramenta de modelagem a imple-
mentação dessa solução (veja no Apêndice A um exemplo de ferramenta, 
na qual foi criado esse modelo).
81Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Figura 31 - Exemplo de possível solução para o estudo de caso 1
Fonte: Produção do próprio autor
Uma crítica que pode ser realizada no modelo apresentado na imagem 
(Figura 31) de exemplo de possível solução para o estudo de caso 1 é a 
criação de atributos que não existem nas entidades do mundo real, tal 
como o código da forma de pagamento. Outra, é o aumento da comple-
xidade por meio de modelagem de relacionamento terciário (a associação 
Compras). Podemos também ver que o modelo apresentado constitui a 
visão do consumidor, pois a associação que representa a operação está 
definida como Compras, e não Vendas, que seria a visão da empresa. 
Também poderíamos ter todas as entidades no singular. Além disso, não 
aparece no modelo a quantidade comprada nem o total da compra! Tam-
bém não saberemos quando a compra foi realizada.
Atenção
Você deverá notar que a modelagem é um processo iterativo. 
A primeira versão obtida dificilmente será a definitiva. 
Deverá passar por críticas e melhorias até que se tenha um modelo 
que atenda a todas as necessidades de negócio e, ainda, de 
normalização existentes na organização (e, se não existirem, terá 
que ser criado um padrão).
2.6.3 Atividade
Para praticar, modifique a modelagem apresentada na imagem 
(Figura 31) anterior, da seguinte forma: transforme a associação 
Compras em Venda; transforme a forma de pagamento em atri-
buto de Venda, somente com a descrição, eliminando o código. 
Apresente na modelagem o campo de quantidade comprada e o 
total, além da data da compra. Você poderá fazer com papel e lápis 
ou utilizando o mesmo software que usou para criar o seu modelo.
82 Planejamento e Elaboração de Bases de Dados
Resposta comentada
Em relação à modelagem anterior, veja que foi modificada a visão principal: passamos de uma 
modelagem de compras (visão do cliente) para uma modelagem de vendas (visão da empresa, da 
organização). Note, ainda, que adicionamos atributos no relacionamento Venda: a quantidade (re-
presentada abreviadamente por qtdade, o total e a data). Ainda, as entidades estão todas represen-
tadas no singular, homogeneizando a representação. A partir dessa representação, podemos ampliar 
o modelo de compra e venda, incluindo a modelagem do fornecedor de cada produto, o que será 
realizado a seguir.
2.6.4 Estudo de caso 2: ampliando o modelo de compra 
e venda com a inclusão dos fornecedores
Por tratar-se de uma abordagem didática, começamos nosso modelo 
com poucas entidades e poucos atributos para iniciar a aprendizagem, 
e naturalmente podemos ampliar a modelagem para praticar. Mas, para 
contextualizar, suponha agora que desejamos expandir nosso modelo 
para atender mais funcionalidades desejadas pela organização. Ou, ainda, 
que, ao apresentarmos a primeira versão, as expectativas do usuário não 
foram totalmente supridas e faltou algo. Vamos ampliar a modelagem?
2.6.5 Atividade
Para praticar, vamos agora ampliar nosso modelo, incluindo 
nele uma forma de identificar os fornecedores (CNPJ, razão social, 
nome fantasia, endereço composto como na entidade Consumidor, 
telefone comercial e contato).
Também deverá ser incluído um relacionamento de Fornecimen-
to, o qual terá um atributo data, a quantidade de cada item e o to-
tal da transação. Cada fornecedorpoderá fornecer muitos produ-
tos e um produto poderá ser fornecido por mais de um fornecedor.
Você poderá fazer com papel e lápis ou utilizando o mesmo 
software que usou para criar o seu modelo.
Resposta comentada
Na solução apresentada, a seguir, a entidade relativa ao for-
necedor foi modelada de acordo com os metadados de interesse, 
83Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
e com aqueles citados no enunciado. Após, foi ligado ao produto por meio de um relacionamento 
Fornecimento, que possui atributos próprios.
2.6.6 Atividade
Você deve organizar um banco de dados par atender ao registro 
de palestras que serão realizadas dentro de um workshop em sua 
organização.
Para elaborá-lo, você conversou com os interessados e, após as 
reuniões, levantou as seguintes informações:
a) as palestras serão únicas em cada data e deverão possuir um 
registro de seu título e de sua duração;
b) as palestras serão realizadas por um único palestrante;
c) cada palestrante realizará uma única palestra e deverá ser 
identificado pelo seu número de RG. É necessário guardar 
o nome do Palestrante, o qual atende em uma determinada 
área de conhecimento;
d) as áreas de conhecimento deverão ser cadastradas e identifi-
cadas unicamente por meio de suas siglas, mas deverá haver 
uma descrição da área para aqueles que não conhecem a 
sigla;
e) uma área de conhecimento pode ter vários temas, os quais 
pertencem exclusivamente a uma área do conhecimento;
f) cada tema será identificado por um código, que será extraí-
do a partir de consulta ao catálogo do CNPq. Além do códi-
go, haverá uma descrição;
g) é importante para a organização poder atribuir um grau de 
dificuldade a cada tema;
h) para contato com o palestrante será utilizado um telefone 
ou um e-mail ou ambos;
84 Planejamento e Elaboração de Bases de Dados
i) as palestras deverão ter um número sequencial único que as 
identifique;
j) cada palestra pertence exclusivamente a um tema, muito 
embora cada tema possa ter mais de uma palestra.
Sua tarefa é a de desenhar um MER que atenda aos requisitos 
apresentados, para que posteriormente esse banco de dados possa 
ser implementado.
Resposta comentada
Primeiramente, note que os requisitos não estão nem em ordem 
nem agrupados, o que não é incomum quando se efetua esse le-
vantamento.
Temos palestras, palestrantes, temas, áreas de conhecimento, e 
cada uma dessas entidades possui características informadas: pa-
lestras possuem título, duração e uma data de realização e, por 
serem únicas naquela data, isso poderia ser uma primeira opção de 
identificador.
Mas, existe a informação de que deverão ter:
a) um número de sequência único, o que é um identificador 
melhor;
b) palestrantes são identificados por RG e possuem nome, além 
do que devem ter um telefone e um e-mail de contato, en-
tão já temos seus atributos e a chave;
c) áreas de conhecimento têm uma sigla, que, por ser única, 
poderá ser a chave, e uma descrição;
d) temas possuem uma descrição e um código, que pode ser 
a chave;
e) também possuem um grau de dificuldade.
Com essas informações organizadas, podemos iniciar o dese-
nho das entidades que participarão do nosso MER.
As informações restantes referem-se a relacionamentos entre 
as entidades, e também fornecem indicativos de cardinalidade. Por 
exemplo, um palestrante somente fará uma palestra, a qual terá 
um único palestrante, indicando que existe um relacionamento en-
tre as entidades palestra e palestrante na razão de 1 para 1. O mes-
mo ocorre com o palestrante em relação às áreas de conhecimento.
Note que a informação de que o código do tema será extraído 
de um suposto catálogo do CNPq é irrelevante para a modelagem, 
a não ser, claro, pela existência de um código. Ou seja, o catálogo 
é externo à nossa modelagem, faz parte de outro processo ou, 
nesse caso, de outra organização. Está além da fronteira de nossa 
modelagem.
Um modelo que pode representar essa situação está exibido na 
figura a seguir. Estude-o e critique-o.
85Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
CONCLUSÃO
No campo da engenharia de software, a qualidade é conhecida por 
meio da sigla Software Quality Assurance (SQA), garantia da qualidade 
de software. No mundo real, cuidar da qualidade dos dados passa primei-
ro pela modelagem e posteriormente por sua inserção e manutenção, e 
é uma tarefa que transcende os sistemas, muito embora os mesmos pos-
sam auxiliar. Atente-se para a importância de seu papel nessa situação, 
na condição de gestor das informações. A criação de um bom banco de 
dados faz parte dessas tarefas.
Para a elaboração de um banco de dados, faremos uso de metadados, 
os quais ligam-se ao modelo conceitual e são definidos quando da aná-
lise das necessidades de negócio e de usuários. Perguntar-se como serão 
atendidos os relatórios ou as consultas desejadas é uma boa forma de 
verificar se o desenho lógico e a posterior criação física das tabelas aten-
derão às necessidades.
O objetivo de qualquer sistema é o de atender seus usuários e, para 
a organização, ter assegurada a garantia de continuidade do negócio. 
Implica atender aos requisitos planejados. Uma forma simples, mas 
eficaz, de garantia ao atendimento aos requisitos é um cheklist para 
mapeamento planejado x fornecido, em conjunto com a documentação 
de acompanhamento e o controle de evolução do projeto e do 
acompanhamento de necessidades dos usuários.
Embora a modelagem conceitual deva abster-se de preocupações 
com a implementação, não é incomum que pensemos as coisas mais ou 
menos em conjunto, e que, na equipe, exista uma pessoa que efetuará 
o desenvolvimento. Nesses casos, poderá ser forçada a opção por um 
modelo que facilite a implementação no SGBD ou na linguagem de 
programação que será adotada pelo desenvolvimento.
86 Planejamento e Elaboração de Bases de Dados
Conhecer uma nomenclatura e praticá-la em uma ferramenta é es-
sencial, e devemos ter em mente que a modelagem será um processo 
iterativo e interativo: será repetido várias vezes com a participação de 
várias pessoas.
Por fim, note que, em nenhum momento da modelagem, comenta-
mos sobre a segurança. Esse é um item que não aparece diretamente, 
mas que também pode ser modelado no tocante aos papéis e responsa-
bilidades dos envolvidos, e liga-se diretamente às políticas de informação 
da organização.
RESUMO
Os bancos de dados atendem a situações reais de uma organização 
ou necessidade de informação pessoal e são representados por modelos, 
que podem ser conceituais, lógicos ou físicos.
O modelo conceitual visa a atender ao domínio da aplicação e corres-
ponde ao mapeamento das principais entidades, por exemplo, alunos, 
professores e disciplinas em um sistema acadêmico ou livros e usuários 
em um sistema de bibliotecas. O modelo lógico representa as ligações 
das entidades por meio de relacionamentos entre elas, apresentando os 
atributos que as compõem e as identificam, estes últimos chamados de 
chaves. O modelo físico corresponde à organização física dos dados no 
ambiente do SGBD, constando de arquivos, tabelas e seus campos.
Uma forma de modelagem conceitual é chamada de MER. Nesse mo-
delo, as entidades representam coisas úteis ao contexto, presentes no 
mundo real, enquanto os relacionamentos são entidades que dependem 
de outras entidades e correspondem a associações entre elas. Por exem-
plo, empréstimo depende do relacionamento entre usuário e obra. A en-
tidade empréstimo não tem sentido sem as outras duas.
As entidades podem ser classificadas em fortes (quando existem e po-
dem ser identificadas independentemente de outras), fracas (quando sua 
existência depende de outra) e associativas (quando se prestam ao rela-
cionamento de outras entidades entre si).
O grau de participação de uma entidade no relacionamento com outra 
é chamado de cardinalidade.
Entidades e relacionamentos podem possuir atributos, os quais podem 
ou não ser identificadores únicos (chaves).
Quando oatributo é uma chave de identificação, por exemplo, o CPF, 
no caso de uma pessoa (único para cada pessoa e, portanto, capaz de 
identificá-la), é chamado de chave primária.
Quando essa chave é exportada para o relacionamento com outra en-
tidade, por exemplo, o CPF da pessoa é utilizado para identificá-la em 
uma relação de empréstimos de livros, a chave passa a ser conhecida 
como estrangeira. Uma relação poderá ter várias chaves estrangeiras, po-
rém, somente uma primária. Por fim, as chaves podem ser simples (por 
exemplo, o CPF) ou compostas (por exemplo, nome + sobrenome da mãe 
+ data de nascimento).
87Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Já os atributos, elementos que caracterizam uma relação (por exem-
plo, o nome e a altura em uma pessoa), podem ser simples ou comple-
xos, mono ou multivalorados, armazenados ou derivados. Um exemplo 
de atributo simples é o nome de uma pessoa, composto de um conjun-
to único de caracteres. Já um atributo complexo típico (ou composto) 
típico é o endereço, por exemplo, formado pelos atributos simples lo-
gradouro, número, CEP, cidade, estado. Um atributo monovalorado é 
aquele que possui valor único, por exemplo, um número de CPF. Já um 
multivalorado pode ser o telefone, o atributo é único (telefone), mas 
pode assumir mais de um valor.
De forma geral, a maioria dos atributos de interesse serão armazena-
dos no banco e, portanto, estarão à disposição para recuperação futura. 
Mas, há atributos que não necessariamente serão armazenados, impor-
tantes na modelagem, mas que serão obtidos por meio de uma operação 
nos dados armazenados: por exemplo, podemos armazenar os livros que 
foram emprestados a um usuário em certa data e depois calcular quantos 
livros foram emprestados. Esse total é um atributo derivado dos demais.
Existem ferramentas de software que permitem realizar a modelagem 
das situações reais, mas, para isso, é necessário que os requisitos sejam 
previamente levantados.
No processo de modelagem, que é iterativo, é essencial a participação 
dos futuros usuários da aplicação, que fornecerão suas necessidades e 
darão preciosas informações do negócio e da segurança requerida.
Os conceitos resumidos aqui podem ser muito melhor aprendidos se 
você praticar as modelagens sugeridas, em vez de somente ler a respeito 
delas. Pratique!
UNIDADE 3
MANIPULAÇÃO DE BANCOS DE 
DADOS
3.1 OBJETIVO GERAL
Apresentar a transformação do modelo conceitual em tabelas e possibilitar a aprendizagem e a 
prática de comandos SQL para criação e manipulação de bancos de dados relacionais.
3.2 OBJETIVOS ESPECÍFICOS
Espera-se que, ao final desta unidade, você seja capaz de:
a) transformar um modelo conceitual em declarações SQL;
b) compreender comandos SQL;
c) realizar a criação e a manipulação de um banco de dados utilizando comandos SQL;
d) avaliar as influências de um modelo incompleto no projeto de um banco de dados.
3.3 PRÉ-REQUISITOS
Capacidade de obter da internet, instalar e utilizar um programa de modelagem. Lógica básica. Com-
preensão de declarações com sintaxe em língua inglesa. Será necessária a utilização de uma ferramenta 
que permita enviar comandos a um SGBD, o qual evidentemente também deverá estar disponível. Se 
você não conhece isso ou não tem à sua disposição, consulte antes (ou concomitantemente a esta uni-
dade) o Apêndice B.
91Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
3.4 INTRODUÇÃO 
O MER é usualmente utilizado para a modelagem conceitual do ban-
co de dados, o qual, posteriormente, será implementado por meio de 
um gerenciador. Esse modelo poderá ser hierárquico, em rede, relacio-
nal, orientado a objetos ou objeto-relacional. Nesta disciplina, vamos nos 
concentrar nos relacionais, portanto, nosso modelo conceitual deverá ser 
transformado em um modelo relacional.
O modelo relacional é a representação das entidades por meio de re-
lações, mais conhecidas como tabelas. Os atributos das relações são cha-
mados de campos. Finalmente, as linhas que correspondem a um conjun-
to de informações podem ser chamadas de tuplas. A imagem (Figura 32), 
a seguir, apresenta um exemplo.
Figura 32 - Exemplo de mapeamento entre os modelos ER e Relacional
Fonte: Adaptado de Silberchatz; Korth e Sudarschan (2006, p. 8, 11-12)
A representação relacional poderá ser dada na forma Cliente {Cod_
Cli, Nome}, na qual o atributo em destaque (Cod_Cli) corresponde ao 
identificador ou à chave da relação. A nomenclatura Cod_Cli é uma abre-
viatura para Código_Do_Cliente, o código que é utilizado na organização 
para sua identificação (poderia ser um número de usuário em uma biblio-
teca, por exemplo). A grafia depende das normas de cada organização, 
não há uma regra para abreviar. Mas, há uma regra para o sublinhado: 
somente são sublinhados os identificadores, as chaves.
Atributos compostos (complexos) são separados nos seus atributos 
componentes, de forma que eles sejam atômicos. Exemplo: se o endereço 
é composto por rua e número, então existirão os atributos endereço-
rua e endereço-número. Atômico, no caso, significa que não é mais 
divisível (não dá para dividir a rua ou o número em algo menor). A divisão 
ocorre por questões de normalização e para melhorar a consistência: por 
exemplo, se usarmos o número do CEP para identificar o estado, a cidade 
e a rua, não será necessário redigitar (talvez com erros) a rua a cada 
cadastro; somente será necessário o número.
92 Planejamento e Elaboração de Bases de Dados
Note que não é usual utilizar acentuação no banco de dados, 
embora neste texto, e em algumas figuras, a acentuação esteja 
sendo utilizada, para melhor clareza e/ou correção ortográfica.
Para representarmos atributos multivalorados, podemos utilizar duas 
tabelas: uma para a entidade principal; outra para seus valores de atribu-
tos (por exemplo, uma para pessoa, outra para os filhos da pessoa).
Para uma entidade E, um atributo multivalorado M é representado por 
uma tabela separada EM. A tabela EM possui atributos correspondentes à 
chave primária de E e um atributo correspondente ao valor multivalorado 
M. Exemplo: o atributo multivalorado nome-filho de um empregado pode 
ser representado pela tabela empregado-nome-filho (empregado-CPF, 
filho-nome). Cada valor de um atributo multivalorado estará presente em 
uma linha diferente da tabela EM.
Uma vez selecionada uma forma de modelagem que atenda às neces-
sidades do negócio que você estiver modelando, e da equipe que participa 
de seu desenvolvimento, Heuser (2009) nos oferece um quadro compara-
tivo entre as alternativas que poderão ser seguidas na implementação do 
modelo de tabelas a serem utilizadas. Veja a imagem (Quadro 6).
Quadro 6 - Sugestões de implementações de tabelas a partir da Modelagem ER
Fonte: Adaptado de Heuser (2009, p. 97)
93Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Para entender as alternativas propostas na tabela, vejamos o que sig-
nificam as colunas de opções de regras de implementação:
a) tabela própria é utilizada quando, em vez de criarmos mais um 
campo em uma tabela existente, criamos outra tabela. Por 
exemplo, para relacionar quais livros estão emprestados para quais 
usuários, criamos uma tabela de empréstimos (própria da relação 
empréstimo). Esse caso é especialmente indicado para a situação 
de relacionamentos de muitos para muitos (n:n na representação): 
por exemplo, muitos livros são emprestados para muitos usuários e 
muitos usuários podem tomar emprestados muitos livros;
b) a adição de colunas será utilizada quando precisamos inserir um 
atributo novo para representar uma associação com outra entidade. 
Por exemplo, temos uma tabela de usuários e foi decidido que 
passaremos a ter uma tabela de dependentes de usuários, pois foi 
criada uma nova funcionalidade de empréstimo aos dependentes. 
Um usuário pode ter de nenhum a muitos dependentes (0,n na 
representação). Nesse caso, colocamos na tabela de dependentes 
uma nova coluna indicando qualé o identificador do usuário 
responsável. Essa condição é tipicamente presente quando temos 
a relação de um para muitos (1,n na representação) entre as 
entidades participantes da modelagem. Por exemplo, um estado 
possui muitas cidades;
c) por fim, temos o caso de fusão de tabelas, a ser mais utilizada 
nos casos de relacionamento de um para exatamente um (1:1 
na representação). Essa situação poderá surgir naturalmente 
na modelagem quando forem desenhadas duas entidades com 
características próximas em momentos diferentes ou no caso de 
integração de bancos de dados e sistemas, seja entre novos e 
antigos, seja de fornecedores diferentes. Vamos imaginar a seguinte 
situação: foi modelado um usuário, o qual tem relacionamento de 
empréstimo com as obras da biblioteca; ele foi identificado pelo 
CPF e foram adicionados os atributos nome, telefone de contato 
e e-mail. Mas, o usuário também é um aluno do colégio ao qual 
a biblioteca pertence, em cujo sistema são utilizados metadados 
semelhantes, acrescido de alguns de interesse financeiro. Nesse 
caso, seria melhor unir as duas tabelas em uma só.
A partir da escolha das alternativas, passa-se à implementação pro-
priamente dita. Em nosso caso, ela será realizada por meio de comandos 
da linguagem de consulta estruturada SQL.
Na descrição física do banco de dados, as relações e os relacionamen-
tos serão transformados em tabelas, para as quais é comum a elaboração 
de um Dicionário de Dados (DD). O objetivo do DD é o levantamento de 
características dos atributos, que serão transformados em campos, e sua 
documentação para consulta posterior e auxílio à elaboração de decla-
rações de consulta, ou seja, os comandos em linguagem SQL, os quais 
serão vistos na sequência. A imagem (Quadro 7) mostra um exemplo de 
dicionário de dados.
No quadro em questão, temos a descrição detalhada dos atributos 
correspondentes a uma modelagem de cliente de uma organização qual-
quer (exibido parcialmente). Podemos notar, para cada campo exibido 
(Nome, Saldo), uma breve descrição de sua finalidade, o tipo de dados 
que utilizará, o tamanho, se for o caso, os valores mínimo e máximo, se 
94 Planejamento e Elaboração de Bases de Dados
aplicáveis, se é um identifcador (chave), se pode ficar em branco ou não 
(pode ser nulo?), se será armazenado na tabela (A) ou se será calculado 
a partir de dados existentes (seria um C, mas não aparece no exemplo), 
qual é o proprietário dos dados (no caso representado por MKT, de de-
partamento de marketing), qual transação comercial originou o dado (no 
caso, uma venda) e outras observações. O Dicionário de Dados, para ser 
útil à modelagem, deverá conter minimamente informações de nome do 
campo, tipo de dado, se é ou não chave, se aceita ou não nulos e se é ou 
não chave; outras características dependem dos modelos de documenta-
ção adotados em cada organização.
Quadro 7 - Exemplo de dicionário de dados
C
am
p
o
D
es
cr
iç
ão
Ti
p
o
 d
e 
d
ad
o
Ta
m
an
h
o
V
al
o
r 
m
ín
im
o
V
al
o
r 
m
áx
im
o
É 
id
en
ti
fi
ca
d
o
r?
Po
d
e 
se
r 
n
u
lo
?
A
rm
az
en
ad
o
/G
er
ad
o
?
Pr
o
p
ri
et
ár
io
O
ri
g
em
O
b
se
rv
aç
õ
es
Nome
Nome 
do 
cliente
Texto 50
Não 
possui
Não 
possui
Não Não A MKT Vendas ...
Saldo
Saldo 
da 
conta
Valor Zero S/ limite Não Não A MKT Vendas
Calcu_
lado 
cfme 
doc 2
...
Fonte: Produção do próprio autor
O DD deverá ser criado para cada tabela e fará parte da documenta-
ção do sistema.
De onde vêm as informações? Do levantamento de requisitos, da aná-
lise de documentos e processos, das entrevistas com os usuários e outras 
formas comentadas na Unidade 1.
Qual é a sua utilidade? Servirá para que as definições dos tipos de 
dados e suas constraints sejam precisas e adequadas. Ademais, contém 
informações de segurança: quem é o proprietário dos dados e qual o lo-
cal e/ou operação que o gerou. Também pode remeter a uma fórmula ou 
a um outro documento que especifica como deve ser tratado, calculado, 
gerado etc.
No exemplo mostrado de Dicionário de Dados, a organização optou 
por inserir informações de proprietário e de transação de origem na do-
cumentação. Isso permitirá que mais tarde sejam atribuídas autorizaçãoes 
para a inserção de dados na tabela somente ao pessoal do marketing, 
assim como seja controlado que somente poderá ocorrer uma inserção 
durante uma transação de vendas (eventualmente uma atualização). 
Quaisquer tentativas de outros usuários inserirem dados na tabela ou 
sua modificação em outras transações, poderiam gerar um alerta de alte-
ração indevida, ou poderiam ser, simplesmente, ignoradas.
95Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
3.5 INTRODUÇÃO À SQL
A SQL foi criada para a manipulação dos elementos do banco de da-
dos. Suas características mais importantes são:
a) é padronizada para os bancos de dados relacionais;
b) cada comando é uma descrição do que se deseja obter;
c) quem executa o comando é o gerenciador do banco de dados.
Para nossos estudos, podemos dividir a SQL em três partes: Data 
Definition Language ou Linguagem de Definição de Dados (DDL), 
Data Manipulation Language (DML) e Data Control Language (DCL).
A DDL é composta pelo conjunto de comandos que são utilizados para 
a definição do esquema. Por exemplo:
CREATE TABLE pessoa {
 nome char(40),
 CPF integer);
}
Essa sequência de comandos deverá ser enviada ao SGBD por meio de 
programação ou digitada na interface de consulta ou linha de comando 
do aplicativo que faz acesso ao banco. Na sequência, veremos como fa-
zê-lo passo a passo.
No exemplo (veremos detalhadamente a sintaxe dos comandos mais 
adiante), será criada uma tabela identificada como pessoa, composta 
por dois campos: nome e CPF. O primeiro campo aceitará até 40 dados 
do tipo caractere, e o segundo aceitará um número inteiro. O ; (ponto e 
vírgula) ao final é utilizado para terminar a declaração, faz parte da lin-
guagem e é obrigatório.
A DML corresponde ao conjunto de comandos utilizados para acessar 
e manipular os dados organizados pelo modelo de dados apropriado.
Também é conhecida como query language, linguagem de consulta 
(para um banco de dados, inserir um conteúdo ou alterá-lo é uma 
consulta, query, em inglês). Por exemplo, o comando SELECT nome 
FROM pessoa; retorna todos os valores do campo (ou atributo) nome da 
tabela (ou relação) pessoa; ou seja, retorna uma LISTA com os nomes das 
pessoas cadastradas na tabela pessoa. Note que foi ressaltada a palavra 
lista, pois esta é a forma usual de retorno do comando SELECT e dos 
resultados de consultas executados por meio de comandos SQL.
Por fim, a DCL agrega o conjunto de comandos utilizados para garan-
tir ou bloquear acesso a dados ou conjuntos de dados no banco. Portan-
to, permite a administração da segurança de acesso aos dados.
Por exemplo, o comando REVOKE DELETE ON pessoa TO simao; 
retira (REVOKE) do usuário simao a possibilidade de apagar (DELETE) 
conteúdos na (ON) tabela pessoa.
96 Planejamento e Elaboração de Bases de Dados
Nesta disciplina, vamos trabalhar com alguns comandos da DDL (cria-
ção de bancos de dados e de tabelas) e da DML (inserir, alterar, consultar 
e apagar dados); não entraremos em detalhes da DCL.
Explicativo
Em bancos de dados, chamamos a execução de comandos de 
CONSULTA. Lembre-se de que estamos trabalhando com SQL, 
abreviatura de linguagem de consulta estruturada (structured 
QUERY language, sendo QUERY = consulta). Assim, o que faremos 
na prática é realizar consultas ao sistema gerenciador de bancos 
de dados, mesmo quando solicitando a execução de comandos 
para a criação de objetos, inserção, modificação ou apagamento 
de dados.
3.6 PRÁTICA DE 
DECLARAÇÕES SQL
Existem muitas ferramentas para a criação e a manipulação de bancos 
de dados no mercado, pagas e gratuitas. Grande parte das ferramentas 
disponíveis são capazes de realizar a modelagem do banco, conectarem-
-se ao SGBD e realizarem a criaçãodaquilo que foi criado. Há interfaces 
disponíveis para a inserção de dados que se assemelham a planilhas, fa-
cilitando a utilização.
Neste ponto, daremos preferência às operações manuais, de forma a 
introduzirmos e explicarmos os comandos necessários e permitir que você 
perceba a importância da sintaxe e da estrutura das declarações.
A ferramenta escolhida para este momento foi a MySQL Workbench, 
disponível para ambientes Linux e MS-Windows. Consulte o Apêndice B 
para verificar informações quanto à instalação e rápido guia de uso desse 
produto se quiser utilizá-lo.
Vamos utilizar como referência o diagrama exibido na imagem (Figura 
33), a seguir. O diagrama é hipotético, está sendo apresentado aqui com 
finalidade didática e, em um caso real, teria sido criado a partir de uma 
análise de requisitos, atendendo, possivelmente, à seguinte situação: um 
livro pode ter de no mínimo um até vários autores, e vários autores cadas-
trados podem ter autorado no mínimo um até vários livros. Após existir, 
esse livro poderia ter sido emprestado de nenhum a muitos usuários; e, 
quando cadastrados, os usuários poderiam ter tomado emprestado de 
nenhum a muitos livros.
97Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Figura 33 - Exemplo de MER com aspectos físicos
Fonte: Produção do próprio autor13
Observe que temos, no diagrama, três entidades representadas 
por E (Livros, Autores e Usuários) e dois relacionamentos entre elas 
representadas por R (empréstimos e livro_autores). É uma representação 
MER, porém, apresentando alguns aspectos físicos, como os tipos de 
dados envolvidos.
Não estamos, propositalmente, utilizando a melhor modelagem. 
O objetivo é que surjam novas necessidades ao longo da prática de 
comandos de forma a podermos ligar os aspectos práticos com a 
importância da boa modelagem.
Para implementar a representação da imagem (Figura 34), a seguir 
serão demonstrados comandos básicos para a criação e a manipulação de 
bancos de dados por meio de SQL.
Os exemplos foram executados em MySQL Workbench, conectado a 
um SGBD MySQL 5.6, em ambiente Linux e foram igualmente testados 
em ambiente MS-Windows. Os comandos em si funcionarão em 
outros SGBDs, mas as cópias de tela, obviamente, são específicas das 
ferramentas utilizadas.
Atenção
Considere todos os comandos do item 3.4.1 como uma grande 
atividade.
Você deverá executar os comandos dos exemplos em seu am-
biente, de forma a treiná-los e verificar os resultados, para poder 
acompanhar as reflexões. Compare o resultado que você obteve 
com a cópia de tela que sucede o comando e, no caso de discre-
pância, revise cuidadosamente a linha digitada, prestando atenção, 
em especial, ao ponto e vírgula, às vírgulas, aspas e palavras em 
língua inglesa.
13 Elaborado pelo autor na ferramenta Ferret.
98 Planejamento e Elaboração de Bases de Dados
3.6.1 Criar o banco de dados
Lembre-se: para a execução dos comandos, o servidor deve 
estar iniciado, e o cliente conectado (veja o apêndice B)!
Primeiramente, criaremos e colocaremos em uso um banco de dados 
chamado de pratica1.
Para isso, utilizamos os comandos CREATE DATABASE, que cria o ban-
co de dados, e USE, que instrui o gerenciador a executar os próximos 
comandos no banco de dados informado.
A finalidade do uso do comando create database é a criação do banco 
de dados dentro do gerenciador. É o primeiro passo para a elaboração de 
um banco de dados funcional; o passo seguinte corresponderá à criação 
de seu metaconteúdo (as tabelas, suas descrições e relacionamentos) e, 
finalmente, da inclusão de seu conteúdo: os dados. Veremos tais passos 
na sequência de nossos estudos.
Cada SGBD possui algumas características próprias, as quais devem 
ser pesquisadas nos ambientes de auxílio ou na internet, de forma a ob-
terem-se opções para esses comandos.
Vamos ver o passo a passo?
Passo 1: Abra o SGBD escolhido por você. Digite o comando a seguir 
e veja na imagem logo após um exemplo da tela com a ação.
CREATE DATABASE pratica1;
Figura 34 - Exemplo de criação de BD
Fonte: Produção do próprio autor14
14 Elaborado pelo autor na ferramenta MySQL.
99Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Passo 2: Digite o comando a seguir e veja na imagem logo após um 
exemplo da tela com a ação. Observe na imagem que o comando ante-
rior ficou registrado no painel Action output.
ATENÇÃO: TODOS OS COMANDOS DEVERÃO SER DIGITADOS NA 
ABA DE EDIÇÃO DE COMANDOS (identificada com Query 1 na figura 
que segue).
USE pratica1;
Figura 35 - Exemplo do comando USE para indicar qual BD será usado para os próximos comandos
Fonte: Produção do próprio autor
Você deverá notar que solicitou a criação e o uso de um banco de da-
dos, e todas as tarefas necessárias para isso foram efetuadas pelo SGBD. 
É importante ressaltar que, do ponto de vista de segurança, o usuário 
utilizado por você para acesso ao SGBD deverá ter permissão para criação 
de bancos de dados, caso contrário, o comando não será executado. Em 
caso de problemas, consulte a equipe de TI responsável pelo atendimento 
do laboratório ou seus tutores, presencialmente ou a distância.
Explicativo
Nesta disciplina, os exemplos foram executados no MySQL, mas 
o SQL é padronizado e deve funcionar em quaisquer SGBD-R, even-
tualmente com pequenos ajustes.
100 Planejamento e Elaboração de Bases de Dados
Os comandos foram digitados em maiúsculo somente para 
destaque, mas podem ser digitados em minúsculo sem nenhum 
problema.
Dica: evite utilizar acentuação nos nomes dos objetos criados (ban-
co de dados, tabelas, campos).
A sintaxe (para MySQL) do comando CREATE DATABASE é a declara-
ção do comando seguida do nome do banco de dados. Para o comando 
USE, igualmente é o nome do comando seguido do nome do banco de 
dados ao qual queremos nos conectar (se tivermos autorização para isso, 
como já observado).
Como a linha de comandos poderá ser maior do que a linha a ser 
exibida na tela, o SGBD somente vai considerar que o comando termi-
nou quando encontrar a informação de que ele foi encerrado, quando 
encontrar o terminador do comando. No SQL os comandos são encer-
rados por meio do uso do sinal ; (ponto e vírgula) ao final da lista de 
comandos a executar.
Explicativo
As ferramentas de modelagem costumam gerar o código SQL 
para os modelos criados. Dessa forma, se você criar um modelo 
conceitual na ferramenta, poderá exportar o código SQL para um 
arquivo e abri-lo no ambiente de trabalho. Algumas ferramentas de 
modelagem executam diretamente o modelo criado em um SGBD 
ao qual estiverem conectadas.
3.6.2 Criar as tabelas necessárias para implementar o 
modelo
Depois da criação do banco de dados, os comandos que seguem cria-
rão as tabelas que receberão os dados de livros, usuários e autores de li-
vros (lembre-se de que estamos trabalhando com o modelo representado 
na Figura 34).
Note que poderíamos ter criado uma tabela de pessoas, as quais po-
deriam ser usuários ou autores. Da forma que fizemos, se uma pessoa 
for ao mesmo tempo autora de um livro e usuária da biblioteca, haverá 
duplicidade de cadastro. Nesse caso, o que mudou foi somente o papel 
desempenhado pela pessoa, não a pessoa em si. Mas, por enquanto, 
deixaremos assim.
Observamos novamente a necessidade de autorização para a criação 
de tabelas por parte do usuário que você está utilizando na comunica-
ção com o SGBD. As seguintes declarações criarão as tabelas necessárias 
ao exemplo:
101Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
As tabelas a serem criadas, a seguir, correspondem ao modelo apre-
sentado na imagem (Figura 34), que é um exemplo hipotético de mo-
delagem de biblioteca utilizado nesta disciplina com finalidade didática. 
Serão utilizadas para a prática dos comandos de manipulação de dados 
descritos na sequência.
Passo 3: Digite os comandos a seguir e veja na imagem logo após um 
exemplo da tela com a ação realizada.
ATENÇÃO: TODOS OS COMANDOS DEVERÃO SER DIGITADOS NAABA DE EDIÇÃO DE COMANDOS (identificada com Query 1 na figura 
que segue).
CREATE TABLE Livros ( 
 ISBN varchar(13) NOT NULL,
 titulo varchar(255),
 primary key (ISBN)
);
CREATE TABLE Autores (
 nome varchar(50) NOT NULL,
 primary key (nome)
);
CREATE TABLE Usuarios (
 CPF char(11) NOT NULL,
 nome varchar(50),
 primary key (CPF)
);
CREATE TABLE livro_autores (
 ISBN varchar(13) NOT NULL,
 nome varchar(50) NOT NULL,
 primary key (ISBN,nome)
);
CREATE TABLE emprestimos (
 ISBN varchar(13) NOT NULL,
 CPF char(11) NOT NULL,
 data_emprestimo date,
 data_devolucao date
);
102 Planejamento e Elaboração de Bases de Dados
Figura 36 - Exemplo do comando CREATE TABLE para criar as tabelas no BD em uso
Fonte: Produção do próprio autor
A Sintaxe do comando para a criação das tabelas é CREATE 
TABLE seguido do nome da tabela; após o nome, haverá abertura 
de parênteses para a criação dos campos que compõem a tabela 
seguida do fechamento dos parênteses e do sinal ; que encerra 
o comando.
Dentro da estrutura das tabelas, temos a declaração de seus 
campos, os quais são declarados com a sequência mínima de 
nome_do_campo seguido de tipo_de_dados (e tamanho, quando 
for o caso). Podem ocorrer mais declarações, a depender da neces-
sidade e do tipo de SGBD adotado, por exemplo, as declarações 
NOT NULL em alguns casos. Note que essa declaração implementa 
uma regra de integridade, garantindo que certos dados não sejam 
nulos, ou seja, que os mesmos sejam de cadastramento obrigató-
rio. Os campos são separados por , (vírgula).
Não é necessário digitar cada declaração em uma linha separada 
e tabular de forma a alinhar as declarações. Isso só é realizado para 
fins didáticos e de melhoria da visualização. Se você digitar tudo 
em uma única linha, o efeito será o mesmo, desde que a sintaxe 
esteja correta.
As tabelas também tiveram a atribuição de chaves primárias. 
Para isso, foi incluída a informação primary key em sua declaração. 
Relembrando, o objetivo é a criação de constraints para garantir a 
integridade de nosso banco de dados.
Algumas chaves são simples, contendo somente um campo, mas 
também podemos formar chaves compostas. Por exemplo, pode-
ríamos criar uma chave formada pelo nome da pessoa, o nome 
da mãe e a data de nascimento. O objetivo da criação de chaves, 
103Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
relembrando, é o de garantir unicidade, identificação única e ca-
dastro único de certos dados (isso deve ser definido no modelo 
conceitual, conforme já estudado).
Quer ver as tabelas de seu banco de dados? Execute: SHOW 
TABLES;
Passo 4: Digite o comando a seguir para exibir as tabelas criadas 
por você.
SHOW TABLES;
Figura 37 - Exemplo do comando SHOW TABLES para mostrar as tabelas no BD em uso
Fonte: Produção do próprio autor
O comando SHOW é o comando para mostrar ou exibir; nesse caso, 
as tabelas.
Quer ver a estrutura de uma tabela? Execute: DESC Livros;
Passo 5: Digite o comando a seguir para exibir as tabelas criadas por você.
DESC Livros; (você também pode usar a forma completa, DESCRIBE 
Livros;)
Figura 38 - Exemplo do comando DESC para mostrar a estrututra de uma tabela no BD em uso
Fonte: Produção do próprio autor
104 Planejamento e Elaboração de Bases de Dados
O comando DESC é a abreviatura de describe (descreva). Ao ser execu-
tado seguido do nome da tabela desejada, ele mostra sua estrutura. Note 
na apresentação a informação de que o campo ISBN é chave primária 
(Key = PRI) e que o campo titulo pode ser nulo (Null = Yes).
3.6.3 Criar constraints de integridade: chaves primárias 
e estrangeiras
A declaração das chaves poderá ser realizada também por meio do 
comando de alteração da tabela, que usaremos para criar as chaves 
estrangeiras:
Passo 6: Digite os comandos a seguir para fazer a declaração das cha-
ves e veja o resultado na imagem logo após.
ALTER TABLE livro_autores ADD FOREIGN KEY (ISBN) 
REFERENCES Livros (ISBN);
ALTER TABLE livro_autores ADD FOREIGN KEY (nome) 
REFERENCES Autores (nome);
ALTER TABLE emprestimos ADD FOREIGN KEY (ISBN) 
REFERENCES Livros (ISBN);
ALTER TABLE emprestimos ADD FOREIGN KEY (CPF) 
REFERENCES Usuarios (CPF);
Figura 39 - Exemplo do comando DESC para mostrar a estrututra de uma tabela no BD em uso
Fonte: Produção do próprio autor
No comando ALTER TABLE livro_autores ADD FOREIGN KEY 
(ISBN) REFERENCES Livros (ISBN); estamos alterando (ALTER) a tabela 
livro_autores, com a adição (ADD) ou inclusão de uma chave estrangeira 
105Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
(FOREIGN KEY) no campo ISBN, a qual referencia a tabela Livros no cam-
po ISBN. Com isso, estamos impedindo que seja ligado um autor a um 
livro inexistente (testaremos mais adiante).
3.6.4 Inserir dados de teste
A sintaxe inicial que será utilizada é INSERT INTO nome_da_tabela 
VALUES (valores_dos_dados).
Os valores serão representados entre parênteses, separados por vír-
gula, com caracteres entre aspas, na sequência dos campos da estrutura 
da tabela. Lembre-se de que o terminador de um comando é o ponto 
e vírgula, e ele deverá vir após o fechamento dos parênteses, antes da 
próxima declaração.
Atenção
NOTA: os exemplos de seleção e exibição que serão trabalhos na 
sequência somente apresentarão os resultados como apresentados 
se os dados que seguem estiverem cadastrados de acordo com o 
sugerido nos exemplos.
3.6.4.1 Dados para a tabela Autores
INSERT INTO Autores VALUES(“Isaac Epstein”);
Esse comando significa insira na tabela Autores os valores indicados 
na cláusula VALUES. O conteúdo corresponde aos campos da tabela. 
Nossa tabela de Autores foi criada com somente um campo, o nome. 
Então, estamos inserindo o nome do autor na tabela correspondente. 
Mais adiante, trabalharemos com mais de um campo e mudando a 
ordem dos campos. Os comandos que seguem têm a mesma explicação, 
mudando somente os valores dos dados.
Passo 7: Digite os comandos a seguir para inserir os dados na tabela 
Autores e veja o resultado na imagem logo após.
INSERT INTO Autores VALUES(“Peter Chen”);
INSERT INTO Autores VALUES(“Jane P. Laudon”);
INSERT INTO Autores VALUES(“Kenneth C. Laudon”);
INSERT INTO Autores VALUES(“José Simão de Paula Pinto”);
INSERT INTO Autores VALUES(“Adilson da Silva Lima”);
INSERT INTO Autores VALUES(“Carlos Alberto Heuser”);
INSERT INTO Autores VALUES(“Paul Kahn”);
INSERT INTO Autores VALUES(“Krzysztof Lenk”);
106 Planejamento e Elaboração de Bases de Dados
Figura 40 - Exemplo do comando INSERT INTO para mostrar a inserção de dados em uma tabela no BD em uso, no caso, a 
Tabela Autores
Fonte: Produção do próprio autor
Tente executar novamente o cadastro de um dos autores.
Passo 8: Digite o comando a seguir para tentar reinserir o dado Peter 
Chen na tabela Autores e veja o resultado na imagem logo após.
INSERT INTO Autores VALUES(“Peter Chen”);
Figura 41 - Exemplo do comando INSERT INTO usado para tentar inserir novamente dados já cadastrados na tabela 
autores no BD em uso
Fonte: Produção do próprio autor
107Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Observe que aconteceu um erro. O campo nome foi definido como 
chave, e já existe um autor Peter Chen cadastrado. Dessa forma, o SGBD 
indica que não pode realizar a operação. Isso corresponde ao conceito 
anteriormente estudado de manter a integridade do banco de dados.
Agora, para pensar: e se existirem autores homônimos, como iremos dife-
renciá-los se estamos cadastrando somente seus nomes no banco de dados?
Resposta: o modelo é insuficiente para essa questão e teria de ser re-
visto. Isso remete à importância do correto levantamento de requisitos e 
aspectos de negócio e necessidades dos usuários.
3.6.4.2 Dados para a tabela Usuarios
INSERT INTO Usuarios VALUES(98302543055,”Antônio Calisto”);
Esse comando significa insira na tabelaUsuarios os valores 
indicados na cláusula VALUES. O conteúdo corresponde aos campos 
da tabela. Nossa tabela de Usuarios foi criada com os campos CPF e 
nome, nessa ordem, portanto, foram informados nessa ordem.
Note que os valores correspondentes a caracteres estão entre aspas, 
enquanto os números não estão. Note que os valores são separados por 
, (vírgula). Os valores são fictícios.
Passo 9: Digite os comandos a seguir para inserir dados na tabela 
Usuarios e veja o resultado na imagem logo após.
INSERT INTO Usuarios VALUES(32377183352,”Diana Bettocchi”);
INSERT INTO Usuarios VALUES(85638141170,”Gisela Sarado”);
INSERT INTO Usuarios VALUES(31053735510,”Gabi Amorim Calisto”);
INSERT INTO Usuarios VALUES(65955322205,”Tobias José Cretton”);
Figura 42 - Exemplo do comando INSERT INTO usado para inserir dados na tabela Usuarios no BD em uso
Fonte: Produção do próprio autor
108 Planejamento e Elaboração de Bases de Dados
Multimídia
Para obter CPFs e CNPJs fictícios, porém válidos em função do 
algoritmo de validação, assim como nomes de pessoas e de empre-
sas fictícias, exclusivamente para finalidade de teste de software, 
experimente o http://www.geradorCPFcnpj.com/ (há vários outros 
geradores; pesquise e escolha o melhor para você).
3.6.4.3 Dados para a tabela Livros
INSERT INTO Livros VALUES(“8508028121”,”Teoria da informação”);
Note que agora a modelagem da tabela foi com dois campos de 
caracteres, motivo pelo qual os dois valores informados estão entre 
aspas.
Passo 10: Digite os comandos a seguir para inserir dados na tabela 
Livros e veja o resultado na imagem logo após.
INSERT INTO Livros VALUES(“0074605755”,”Modelagem de 
dados”);
INSERT INTO Livros VALUES(“9788576059233”,”Sistemas de 
informação gerenciais”);
INSERT INTO Livros VALUES(“9788586846588”,”Microsoft SQL 
Server”);
INSERT INTO Livros VALUES(“9788571948839”,”Modelagem de 
dados”);
INSERT INTO Livros VALUES(“9798577803828”,”Projeto de banco 
de dados”);
INSERT INTO Livros VALUES(“9782880464646”,”Mapping Web 
Sites”);
http://www.geradorCPFcnpj.com/
109Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Figura 43 - Exemplo do comando INSERT INTO usado para inserir dados na tabela Livros no BD em uso
Fonte: Produção do próprio autor
3.6.4.4 Dados para a tabela livro_autores
Passo 11: Digite os comandos a seguir para inserir dados na tabela 
livro_autores e veja o resultado na imagem logo após.
Note que o comando está inserindo dados correspondentes aos cam-
pos da tabela, na ordem: número de ISBN e autor do livro.
INSERT INTO livro_autores VALUES(“8508028121”,”Isaac Epstein”);
INSERT INTO livro_autores VALUES(“0074605755”,”Peter Chen”);
INSERT INTO livro_autores VALUES(“9788576059233”,”Jane P. 
Laudon”);
INSERT INTO livro_autores VALUES(“9788576059233”,”Kenneth C. 
Laudon”);
INSERT INTO livro_autores VALUES(“9788586846588”,”José Simão 
de Paula Pinto”);
INSERT INTO livro_autores VALUES(“9788571948839”,”Adilson da 
Silva Lima”);
INSERT INTO livro_autores VALUES(“9798577803828”,”Carlos 
Alberto Heuser”);
INSERT INTO livro_autores VALUES(“9782880464646”,”Paul 
Kahn”);
110 Planejamento e Elaboração de Bases de Dados
Figura 44 - Exemplo do comando INSERT INTO usado para inserir dados na tabela Livro-autores no BD em uso
Fonte: Produção do próprio autor
Passo 12: Digite os comandos a seguir para inserir dados na tabela 
livro_autores e veja o resultado na imagem logo após.
Note que o comando está inserindo na tabela que relaciona livros e 
autores os conteúdos do nome e do ISBN.
INSERT INTO livro_autores(nome,ISBN) VALUES(“Krzysztof 
Lenk”,”9782880464646”);
Figura 45 - Exemplo do comando INSERT INTO usado para inserir dados na tabela Livro-autores no BD em uso
Fonte: Produção do próprio autor
111Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Perceba que agora houve uma mudança no comando. Vamos analisar: 
até aqui, sempre que inserimos um conteúdo, informamos a tabela e os 
valores, na ordem exata dos campos. Neste último comando invertemos 
a ordem em que os dados foram informados; para isso, foi passada no 
comando a ordem em que os campos aparecem na cláusula VALUES, e 
quais são os campos. Isso permite que os dados sejam informados em 
quaisquer ordens necessárias à conveniência do usuário, por exemplo, caso 
venham em um arquivo e estejam em ordem diferente daquela da tabela.
Também possibilita que sejam fornecidas informações incompletas, 
por exemplo, quando não temos o valor de um dos campos, bastando 
omiti-lo da sequência (desde que não seja uma chave) e, evidentemente, 
não informar um valor para ele.
Continuando com o teste de integridade, experimente agora executar 
outro comando.
Passo 13: Digite os comandos a seguir para inserir dados na tabela 
livro_autores e veja o resultado na imagem logo após.
INSERT INTO livro_autores VALUES(“9798577803828”,”Isto não vai 
dar certo”);
Figura 46 - Exemplo do comando INSERT INTO usado para inserir dados na tabela Livro-autores no BD em uso
Fonte: Produção do próprio autor
O problema é de integridade referencial, ou seja, tentamos inserir um 
livro que existe associado a um autor que não existe. Veja os pontos gri-
fados da mensagem de erro:
“Error Code: 1452. Cannot add or update a child row: a foreign 
key constraint fails (‘pratica1’.livro_autores’, CONSTRAINT ‘livro_
autores_ibfk1’ FOREIGN KEY(‘ISBN’) REFERENCES... )”.
112 Planejamento e Elaboração de Bases de Dados
Perceba a importância da boa modelagem e da correta estruturação 
das tabelas e suas constraints: uma vez que esteja bem formulado, o 
SGBD cuidará para que tudo seja respeitado, garantindo a integridade 
dos dados e a qualidade do banco de dados.
Explicativo
Metadados
É necessário, neste ponto do curso, que você perceba a impor-
tância entre os aspectos teóricos relativos a metadados e o que está 
acontecendo agora no banco de dados criado. O SGBD utiliza e ge-
rencia os metadados relativos ao banco de dados e tabelas criados, 
assim como os tipos de dados escolhidos, sejam estruturais, sejam 
de domínio, para gerenciar os dados e garantir sua integridade.
3.6.4.5 Dados para a tabela emprestimos
O que acontecerá se digitarmos o comando a seguir? Você tem algum 
palpite?
INSERT INTO emprestimos VALUES (“9782880464646”, “6595532
2205”,”2014/11/20”,NULL);
A novidade nessa linha de comando é que um dos valores passados 
é nulo. Nesse caso, porque a data de devolução ainda não é conhecida.
Outra forma que poderia ter sido utilizada para esse comando seria 
declarar INSERT INTO emprestimos (ISBN,CPF, data_emprestimo) 
VALUES (“___”,”___”,”___”) e passar somente os três valores; informan-
do explicitamente os campos a cadastrar e ignorando o outro, o SGBD 
assume que seu valor é nulo automaticamente (ou, se estiver progra-
mado para isso, coloca um valor padrão: default). Claro que, para essa 
opção funcionar, a estrutura da tabela deve ter sido declarada com o 
campo em questão aceitando valores nulos.
Note, ainda, que a data está sendo informada segundo a norma in-
glesa, isto é, ANO-MÊS-DIA. Mais adiante veremos como formatar sua 
exibição para o nosso formato usual, DIA-MÊS-ANO.
Passo 14: Digite os comandos a seguir para inserir dados na tabela 
emprestimos e veja o resultado na imagem logo após.
INSERT INTO emprestimos VALUES (“9798577803828”, “6595532
2205”,”2014/11/20”,NULL);
INSERT INTO emprestimos VALUES (“9782880464646”, “3237718
3352”,”2014/11/20”,NULL);
INSERT INTO emprestimos VALUES (“8508028121”, “9830254305
5”,”2014/11/21”,NULL);
113Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
INSERT INTO emprestimos VALUES (“9788571948839”, “3105373
5510”,”2014/11/21”,NULL);
INSERT INTO emprestimos VALUES (“0074605755”, “6595532220
5”,”2014/11/21”,NULL);
Figura 47 - Exemplo do comando INSERT INTO usado para inserir dados na tabela Empréstimos no BD em uso
Fonte: Produção do próprio autor
Note que essa tabela (emprestimos) é uma tabela de relacionamen-
to, totalmente dependente das demais,pois ela somente pode existir se 
houver usuários e livros previamente cadastrados. Além disso, trata-se, 
para esse exemplo, de uma tabela que sofrerá inserções e atualizações 
constantes, pois ela implementa a regra de negócio empréstimo e 
devolução de livros.
Explicativo
É usual em SGBDs, e na informática em geral, o uso de datas no for-
mato inglês (ANO-MÊS-DIA). Esse formato é mantido não somente por 
razões históricas ou de origem do sistema, mas também por ser extrema-
mente útil para o cálculo de datas: é mais fácil para subtrair uma data de 
outra e ter o resultado diretamente em dias.
114 Planejamento e Elaboração de Bases de Dados
3.6.5 Atualizar dados
Como vimos na inserção de dados de empréstimos, será necessário, 
em dado momento, informar a data de devolução da obra. Para isso, se 
for utilizado o comando INSERT novamente teremos um problema, pois 
estaremos criando uma nova linha na tabela, e não atualizando a linha já 
criada. Para esse caso, devemos utilizar o comando UPDATE.
UPDATE emprestimos SET data_devolucao = “2014/11/28” WHERE 
ISBN = “8508028121” AND CPF = “98302543055”;
O comando passado ao SGBD aqui é: atualize (UPDATE) a tabela 
emprestimos, estabeleça (SET) para o campo data_devolucao o valor 
2014/11/28 quando (WHERE) o valor do ISBN for 8508028121 e (AND) 
o valor do CPF for 98302543055. Ou seja, especificamente para o 
usuário cujo CPF foi informado, e para o livro cujo ISBN foi fornecido, 
estamos informando agora a sua data de devolução. Caso não tivésse-
mos informado o CPF, somente o ISBN, todos os livros com aquele ISBN 
teriam sua data de devolução alterada. Por outro lado, se informás-
semos somente o CPF e não o ISBN, todos os livros emprestados para 
aquele usuário teriam sua data de devolução alterada. Portanto, cuida-
do na execução dos comandos; se ele for válido, o SGBD vai executá-lo. 
E não há como desfazê-lo.
Passo 15: Digite os comandos a seguir para inserir dados de devolu-
ção na tabela emprestimos e veja o resultado na imagem logo após.
UPDATE emprestimos SET data_devolucao = “2014/11/26” WHERE 
ISBN = “0074605755” AND CPF = “98302543055”; 
UPDATE emprestimos SET data_devolucao = “2014/11/29” WHERE 
ISBN = “9782880464646” AND CPF = “65955322205”;
Figura 48 - Exemplo do comando UPDATE usado para inserir dados de devolução na tabela Empréstimos do BD em uso
Fonte: Produção do próprio autor
115Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Neste momento, cabe mais uma crítica ao nosso modelo de dados: o 
que aconteceria se o mesmo usuário tivesse tomado emprestado o mes-
mo livro (e já devolvido) há um ano atrás? Resposta: o registro também 
teria sido alterado! Os dados ficariam com a qualidade contestável. Tal 
situação não foi prevista na modelagem.
Por fim, mais um pequeno teste, vamos tentar atualizar um emprésti-
mo que não existe. Execute:
UPDATE emprestimos SET data_devolucao = “2014/11/28” WHERE 
ISBN = “8508028121” AND CPF = “65955322205”; 
A resposta do SGBD será: 0 row(s) affected Rows matched: 0 Changed: 
0. Isso significa que nenhuma linha da tabela foi modificada (0 row(s) 
affected), pois nenhuma corresponde aos critérios de busca dados pela 
cláusula WHERE (Rows matched: 0).
Note que não houve erro: o comando foi executado com perfeição, 
porém nada foi afetado, pois nada atendeu ao critério fornecido. Se, em 
vez de AND tivéssemos optado por OR (ou) na formulação do comando, 
duas linhas seriam, erroneamente, afetadas, o que demonstra, novamen-
te, a necessidade de atenção à lógica da declaração formulada.
3.6.6 Praticar recuperação de dados e pesquisas no 
banco de dados
Agora vamos praticar comandos de seleção. O comando SELECT é 
extremamente utilizado e é capaz de realizar duas operações fundamen-
tais conjuntamente: selecionar e exibir dados. A sintaxe completa des-
se comando é complexa e costuma ser enorme em todos os SGBDs, já 
que possui muitas variações nas declarações e comandos que podem ser 
agregados. Veremos alguns deles.
De forma geral, a sintaxe do comando é SELECT o_que FROM de_
onde, na maioria das vezes seguido de WHERE condições. A cláusula 
o_que é substituída pelos nomes dos campos desejados, usando-se * 
para indicar todos, ou por uma declaração que especifica como deve ser 
exibido um dado. Na cláusula de_onde será informado o nome da tabela 
ou das tabelas das quais os dados serão recuperados. A cláusula WHERE 
especifica condições de busca, por exemplo, nomes iniciando com A. 
Vejamos alguns exemplos.
3.6.6.1 Ver informações dos livros cadastrados
Passo 16: Digite os comandos a seguir para selecionar e exibir dados 
da tabela Livros e veja o resultado na imagem logo após.
SELECT * FROM Livros;
116 Planejamento e Elaboração de Bases de Dados
Figura 49 - Exemplo do comando SELECT usado para selecionar e exibir dados da tabela Livros do BD em uso
Fonte: Produção do próprio autor
Aqui a ordem dada ao SGBD é selecione e mostre (SELECT) todos 
os campos (*) da tabela Livros. O resultado é a exibição de uma LISTA 
contendo no cabeçalho os nomes dos campos e nas diversas linhas seus 
conteúdos (perceba que surgiu na tela uma outra divisão, pois agora exis-
tem dados a serem informados, afinal o comando foi justamente para 
provocar isso, como já havia ocorrido com os comandos SHOW TABLES e 
DESC anteriormente praticados). Observe que a exibição dos nomes dos 
campos segue a ordem na qual foram declarados na estrutura da tabela, 
mas a ordem de exibição desejada (se for diferente) pode ser informa-
da no comando; na sequência dessa prática, veremos como fazê-lo. Os 
dados aparecem na ordem em que foram inseridos no banco, ordem 
esta que também pode ser modificada, conforme critérios informados na 
consulta realizada (muitos programas clientes de SGBDs costuma trazer 
os dados já ordenados, em vez de na sequência em que foram criados, 
porém, isso não é padrão do SQL).
Para maior clareza, deste ponto em diante, vamos verificar somente 
a lista retornada no centro da tela da interface do cliente de consultas:
Figura 50 - Exemplo de resultado de lista de dados da tabela Livros do BD em uso
Fonte: Produção do próprio autor
117Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Note que a ordem de apresentação é a ordem da estrutura da tabela, 
pois não houve menção em contrário. Podemos inverter a ordem em que 
os campos aparecem.
Passo 17: Digite os comandos a seguir para selecionar e exibir dados 
da tabela Livros por ISBN e veja o resultado na imagem logo após.
SELECT titulo,ISBN FROM Livros;
Figura 51 - Exemplo de resultado de lista de dados da tabela 
Livros do BD em uso, selecionando por ISBN
Fonte: Produção do próprio autor
Ou ainda, podemos retornar somente os campos desejados.
Passo 18: Digite os comandos a seguir para selecionar e exibir dados 
da tabela Livros por Título e veja o resultado na imagem logo após.
SELECT titulo FROM Livros;
Figura 52 - Exemplo de resultado de lista de dados da tabela 
Livros do BD em uso, selecionando por Título
Fonte: Produção do próprio autor
O comando SELECT foi executado informando o campo desejado, ti-
tulo. Dessa forma, somente o campo informado foi recuperado e exibido. 
Poderíamos ter solicitado uma lista de campos, ou os campos em qual-
quer ordem.
118 Planejamento e Elaboração de Bases de Dados
3.6.6.2 Ver informações dos livros cadastrados, ordenados 
pelo título do livro
Passo 19: Digite os comandos a seguir para selecionar e exibir dados 
da tabela Livros por Título, em ordem alfabética e veja o resultado na 
imagem logo após.
SELECT * FROM Livros ORDER BY titulo;
Figura 53 - Exemplo de resultado de lista de dados da tabela 
Livros do BD em uso, selecionando por Título, em ordem alfabética
Fonte: Produção do próprio autor
O comando SELECT foi executado com cláusula ORDER BY, seguida do 
nome de um campo (poderia ser mais de um). Dessa forma, o resultado 
foi ordenado e exibido em função do título do livro.
3.6.6.3 Ver informações dos livros cadastrados, ordenadospelo título do livro em ordem descendente
Passo 20: Digite os comandos a seguir para selecionar e exibir dados 
da tabela Livros por Título, em ordem descendente, e veja o resultado na 
imagem logo após.
SELECT * FROM Livros ORDER BY titulo desc;
Figura 54 - Exemplo de resultado de lista de dados da tabela Livros 
do BD em uso, selecionando por Título, em ordem descendente
Fonte: Produção do próprio autor
O comando SELECT foi executado com cláusula ORDER BY, seguida 
do nome de um campo e da cláusula DESC. Dessa forma, o resultado foi 
ordenado e exibido em função do título do livro na forma descendente 
(ou decrescente, termo este utilizado se estivéssemos trabalhando com 
números).
119Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Note que podemos combinar a troca de ordem dos campos com a op-
ção de ordenação. Por exemplo, que consulta foi enviada ao SGBD para 
produzir o seguinte resultado?
Figura 55 - Exemplo de resultado de lista de dados da tabela 
Livros do BD em uso, selecionando por ISBN
Fonte: Produção do próprio autor
Se você pensou em consulta por livros em ordem descendente, acer-
tou! Veja o comando aplicado a seguir.
SELECT ISBN FROM Livros ORDER BY titulo desc;
3.6.6.4 Determinar quantos livros estão cadastrados
Passo 21: Digite os comandos a seguir para determinar a quantidade 
de livros cadastrados na tabela Livros e veja o resultado na imagem logo 
após.
SELECT COUNT(ISBN) FROM Livros;
Figura 56 - Exemplo de resultado de lista de 
dados da tabela Livros do BD em uso, solicitando 
quantidade de livros cadastrados em uma dada tabela, 
no caso, a de Livros
Fonte: Produção do próprio autor
O comando SELECT foi executado informando-se a cláusula 
COUNT(ISBN) na qual COUNT vem contar e ISBN é um campo que tem 
informações únicas, de forma que, se contarmos o número de ISBNs 
diferentes, teremos a quantidade de livros cadastrados. O valor 7 exibido 
abaixo do cabeçalho COUNT(ISBN) corresponde à informação desejada, 
ou seja, são sete livros cadastrados.
Note que estamos criando um novo dado, correspondente ao total 
de livros cadastrados. Essa informação não foi cadastrada no banco de 
dados; ela está sendo gerada no momento em que for necessária. Esse 
procedimento também é usual, por exemplo, quando necessitamos de 
uma idade: calculamos a idade a partir da diferença entre a data atual e 
a data de nascimento.
120 Planejamento e Elaboração de Bases de Dados
Além de diminuir a ocupação de espaço, a vantagem de gerar infor-
mações em tempo de execução é que não precisamos, a cada momento, 
atualizar dados a partir da alteração de outros dados ou de um evento 
importante. Por exemplo, se tivéssemos cadastrado em alguma tabela a 
quantidade de livros existentes no banco de dados, a cada nova inserção 
de um livro, teríamos que atualizar o campo correspondente ao total. 
Da mesma forma, se for cadastrada a idade de uma pessoa no banco de 
dados a cada novo evento de mudança de data, ou seja, todos os dias, 
teríamos que atualizar as idades, verificando se mudaram ou não. E isso 
para todos os registros...
3.6.6.5 Determinar quantos livros estão cadastrados, 
fornecendo o nome de Quantidade para a coluna que 
conterá a resposta
Passo 22: Digite os comandos a seguir para determinar a quan-
tidade de livros cadastrados na tabela Livros fornecendo o nome de 
quantidade e veja o resultado na imagem logo após.
SELECT COUNT(ISBN) AS Quantidade FROM Livros;
Figura 57 - Exemplo de resultado de lista de dados 
da tabela Livros do BD em uso, solicitando quantidade 
de livros cadastrados na dada tabela Livros, fornecendo 
o nome quantidade
Fonte: Produção do próprio autor
O comando SELECT foi executado informando-se a cláusula 
COUNT(ISBN), na qual COUNT vem de contar e ISBN é um campo que 
tem informações únicas, de forma que, se contarmos o número de ISBNs 
diferentes, teremos a quantidade de livros cadastrados, exatamente como 
no item 5.5. Porém, dessa vez, foi incluído na declaração AS Quantidade, 
informando ao SGBD como deverá ser exibido o cabeçalho. Note que 
esse cabeçalho é válido somente para essa exibição; os nomes de campos 
no banco de dados não são alterados. A cláusula AS (apresentado como) 
permite a modificação do nome de exibição de qualquer campo, não 
somente daqueles correspondentes a valores calculados.
3.6.6.6 Listar livros cujos títulos comecem com a palavra 
Modelagem
Passo 23: Digite os comandos a seguir para determinar a quantidade 
de livros cadastrados na tabela Livros fornecendo o título modelagem e 
veja o resultado na imagem logo após.
SELECT * FROM Livros WHERE titulo LIKE ‘Modelagem%’;
121Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Figura 58 - Exemplo de resultado de lista de dados da tabela Livros do BD em uso, 
solicitando quantidade de livros cadastrados na dada tabela Livros, fornecendo o nome 
para título como Modelagem
Fonte: Produção do próprio autor
O comando SELECT foi executado em conjunto com a cláusula WHERE. 
Dessa forma, somente os campos que atenderem o que for declarado após 
essa cláusula serão retornados. Ou seja, a declaração WHERE determina 
condições para a seleção dos dados. Nesse caso, a cláusula utilizou o 
operador LIKE, que significa parecido.
Também foi utilizado o operador %, que significa que podem existir 
outros caracteres na sequência (equivale ao operador * nos sistemas 
operacionais, que em SQL tem outra função).
O que aconteceria se, em vez de LIKE, tivéssemos utilizado = ou se 
não tivéssemos usado o %? Vamos ver. Execute as seguintes variações do 
comando e veja os resultados.
Passo 24: Digite os comandos a seguir e veja o resultado na imagem 
logo após.
SELECT * FROM Livros WHERE titulo = ‘Modelagem%’;
Figura 59 - Exemplo de resultado de lista de dados da tabela 
Livros do BD em uso, solicitando quantidade de livros cadastrados na 
dada tabela Livros, fornecendo o nome para título como Modelagem
Fonte: Produção do próprio autor
Passo 25: Digite os comandos a seguir e veja o resultado na imagem 
logo após.
SELECT * FROM Livros WHERE titulo LIKE ‘Modelagem’;
Figura 60 - Exemplo de resultado de lista de dados da tabela 
Livros do BD em uso, solicitando quantidade de livros cadastrados 
na dada tabela Livros, fornecendo o nome para título como Modelagem
Fonte: Produção do próprio autor
Passo 26: Digite os comandos a seguir e veja o resultado na imagem 
logo após.
SELECT * FROM Livros WHERE titulo = ‘Modelagem’;
122 Planejamento e Elaboração de Bases de Dados
Figura 61 - Exemplo de resultado de lista de dados da tabela 
Livros do BD em uso, solicitando quantidade de livros cadastrados 
na dada tabela Livros, fornecendo o nome para título como Modelagem
Fonte: Produção do próprio autor
Note que os resultados diferem em função de a consulta solicitar 
dados parecidos com ou exatamente igual a. Nenhuma das três 
últimas consultas retornou dados (o que é indicado por NULL na lista). 
Isso ocorre pois não há um livro cadastrado exclusivamente com o nome 
de Modelagem, o que possibilitaria o uso do operador =, e porque não 
podemos utilizar o operador % em conjunto com =, somente com LIKE. 
Novamente: tome cuidado ao formular suas consultas.
3.6.6.7 Uso da cláusula WHERE para unir dados de tabelas 
diferentes
Podemos utilizar a cláusula WHERE para formular uma condição ao 
SGBD que seja pertinente ao nosso modelo de dados, por exemplo, unir 
informações de tabelas diferentes, mas que pertencem ao mesmo con-
texto. Vamos obter uma lista com os autores e seus respectivos livros.
Passo 27: Digite os comandos a seguir aplicando o comando WHERE 
e veja o resultado na imagem logo após.
SELECT nome,titulo FROM livro_autores,Livros WHERE livro_
autores.ISBN=Livros.ISBN;
Figura 62 - Exemplo de resultado usando o comando WHERE
Fonte: Produção do próprio autor
Nesse comando, produzimos uma lista de autores e livros, ligando-os 
por meio da chave previamente definida, o ISBN, que é chave primária 
na tabela Livros e estrangeirana livro_autores. Isso torna o comando 
extremamente poderoso, e corresponde ao início das operações 
conhecidas como JUNÇÃO (em inglês, JOIN, mas não serão exploradas 
nesta disciplina). O resultado da execução dessa consulta é chamado de 
produto cartesiano e, tecnicamente, tem a ver com a álgebra relacional 
e operações com conjuntos.
E se a cláusula WHERE não fosse especificada?
123Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Passo 28: Digite os comandos a seguir sem aplicar o comando WHERE 
e veja o resultado na imagem logo após.
SELECT nome,titulo FROM livro_autores,Livros;
Figura 63 - Exemplo de resultado sem usar o comando WHERE
Fonte: Produção do próprio autor
Como nenhuma cláusula WHERE foi especificada, o SGBD entendeu 
que deveria combinar todos os dados da primeira tabela com todos os 
dados da segunda tabela. E produziu um produto de 9 autores x 7 livros 
= 63 resultados. Imagine a execução de um comando como esse em um 
banco de dados com milhares de linhas em cada tabela...
3.6.6.7.1 Atividade
Pesquise na internet o comando JOIN da linguagem SQL. Para 
que ele serve?
124 Planejamento e Elaboração de Bases de Dados
Resposta comentada
Ele serve para fazer a junção ou a ligação entre tabelas do ban-
co de dados. Baseado em operações da teoria dos conjuntos, é 
capaz de fornecer como resultado o conjunto união, intersecção ou 
disjunção de duas ou mais tabelas.
3.6.6.8 Aninhamento de consultas
Sempre que trabalhamos com o comando SELECT, o SGBD retorna 
uma lista (esta também é uma relação, ou uma pequena tabela). Essa 
lista pode ser utilizada como entrada para outro comando de seleção. 
Chamamos a isso aninhamento.
Vamos ver uma situação de uso dessa característica.
Primeiramente, vamos retornar os CPFs das pessoas que tomaram 
livros emprestados.
Passo 29: Digite os comandos a seguir aplicando o comando SELECT 
e veja o resultado na imagem logo após.
SELECT CPF FROM emprestimos;
Figura 64 - Exemplo de resultado usando o 
comando Select para filtrar por CPF
Fonte: Produção do próprio autor
Agora, vamos utilizar o comando anterior como entrada em um 
comando para determinar os nomes dos usuários.
Passo 30: Digite os comandos a seguir aplicando o comando SELECT 
DISTINCT e veja o resultado na imagem logo após.
SELECT DISTINCT(nome) FROM Usuarios WHERE CPF IN (SELECT 
CPF FROM emprestimos) ORDER BY nome;
Figura 65 - Exemplo de resultado sem usar o comando 
WHERE buscando o nome dos usuários
Fonte: Produção do próprio autor
125Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
O operador IN (em) determina que o comando deverá utilizar a lista 
fornecida como dados de entada (e será executado para cada elemen-
to presente na lista). O ORDER BY determina a ordem de classificação. 
Como um usuário pode fazer mais de um empréstimo, há duplicação de 
nomes. Para evitar a duplicação, utilizamos o DISTINCT().
Assim, obtivemos uma lista dos usuários que tomaram livros empres-
tados. E os que não o fizeram? Poderíamos obter isso informando ao 
SGBD que queremos os nomes de usuários que não estão na lista de 
empréstimo, desta forma:
Passo 32: Digite os comandos a seguir aplicando o comando SELECT 
DISTINCT e WHERE aliado a NOTbIN e veja o resultado na imagem logo após.
SELECT DISTINCT(nome) FROM Usuarios WHERE CPF NOT IN 
(SELECT CPF FROM emprestimos) ORDER BY nome;
Figura 66 - Exemplo de resultado usando o comando 
SELECT DISTINCT e WHERE buscando o nome dos usuários 
com base no CPF aplicando NOT IN
Fonte: Produção do próprio autor
3.6.6.9 Trabalhar formatação de datas no comando select
As datas de empréstimo e devolução que cadastramos em nossa tabela 
de empréstimos ficaram com formatação inglesa. Vamos verificar:
Passo 33: Digite os comandos a seguir aplicando o comando SELECT 
DISTINCT e veja o resultado na imagem logo após.
SELECT ISBN, CPF, data_emprestimo,data_devolucao FROM 
emprestimos;
Figura 67 - Exemplo de resultado usando o comando SELECT DISTINCT e WHERE 
buscando o nome dos usuários com base no CPF aplicando NOT IN
Fonte: Produção do próprio autor
Para modificar essa apresentação, podemos fazer uso da função da 
função DATE_FORMAT(). Essa função recebe dois parâmetros (duas va-
riáveis): o primeiro é a data que desejamos formatar; e, o segundo, o 
formato desejado. Vamos utilizá-la:
126 Planejamento e Elaboração de Bases de Dados
Passo 34: Digite os comandos a seguir aplicando o comando DATE_
FORMAT e veja o resultado na imagem logo após.
SELECT ISBN, CPF, DATE_FORMAT(data_emprestimo, ‘%d/%m/%Y’) 
AS Emprestimo, DATE_FORMAT(data_devolucao, ‘%d/%m/%Y’) 
AS Devolucao FROM emprestimos;
Figura 68 – Exemplo de resultado usando o comando DATE_FORMAT
Fonte: Produção do próprio autor
Já a função DATEDIFF() retorna a diferença entre duas datas forneci-
das. Por exemplo, podemos verificar qual o período de devolução.
Passo 35: Digite os comandos a seguir aplicando o comando 
DATEDIFF e veja o resultado na imagem logo após.
SELECT nome, DATEDIFF(data_devolucao, data_emprestimo) AS 
‘Período em dias’ FROM Usuarios, emprestimos WHERE Usuarios.
CPF = emprestimos.CPF;
Figura 69 - Exemplo de resultado usando o comando DATEDIFF
Fonte: Produção do próprio autor
Também podemos utilizar a função CURDATE(), que retorna a data 
corrente (ou atual) do sistema e combiná-la com outras datas. Vamos ver.
Passo 36: Digite os comandos a seguir aplicando o comando CURDATE 
e veja o resultado na imagem logo após.
SELECT CURDATE();
Figura 70 - Exemplo de resultado 
usando o comando CURDATE
Fonte: Produção do próprio autor
127Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Passo 37: Digite os comandos a seguir aplicando o comando CURDATE 
para tornar a data corrente na tabela empréstimos e veja o resultado na 
imagem logo após.
SELECT nome, DATEDIFF(CURDATE(), data_emprestimo) AS 
‘Emprestado há... dias’ FROM Usuarios, emprestimos WHERE 
Usuarios.CPF = emprestimos.CPF;
Figura 71 - Exemplo de resultado usando o comando 
CURDATE na tabela Empréstimos
Fonte: Produção do próprio autor
Nota: o número de dias calculado nessa última execução é em função 
da data corrente fornecida, 02/12/2014. Dessa forma, leve em conta a 
data de execução desse comando antes de se perguntar o porquê de os 
valores serem diferentes quando for testá-lo com os dados cadastrados 
em nossos exemplos. Nomes que aparecem mais de uma vez são referen-
tes a usuários que possuem mais de um livro emprestado. Por fim, note 
que esses comandos utilizam funções para trabalhar com as datas, as 
quais poderão não estar disponíveis ou serem ligeiramente diferentes de 
um SGBD para outro.
Multimídia
Pesquise outras funções com datas e aprenda muito mais a 
respeito de SQL em: http://downloads.mysql.com/docs/refman-4.
1-pt.a4.pdf 
3.6.7 Campos de numeração automática
Como regra geral, a modelagem deverá ater-se às características, aos 
atributos dos objetos/entidades do mundo real. Dessa forma, não deve-
mos, em princípio, criar algo que não exista na realidade, por exemplo, 
para identificar uma pessoa criar um código qualquer. Na prática, isso 
acaba ocorrendo, por facilidade ou desconhecimento.
Voltando ao caso da identificação da pessoa, em um banco de dados, 
podemos ter como chave o CPF, que é um documento que a pessoa pos-
sui e é universal, serve para integração com outros sistemas, por exemplo. 
http://downloads.mysql.com/docs/refman-4.1-pt.a4.pdf
http://downloads.mysql.com/docs/refman-4.1-pt.a4.pdf
128 Planejamento e Elaboração de Bases de Dados
Mas, não é incomum que seja criado um identificador código e que, 
na documentação de sistemas, por exemplo, encontremos um campo 
cod_pessoa. Se seu sistema necessita da criação de um identificador, ana-
lise primeiro o contexto e verifique se não há como combinar dados para 
criar uma chave, o que poderia ser feito combinando-se nome+data de 
nascimento ou outra combinação única.
Se, mesmo assim, você precisar criar um identificador, pode usar cam-
pos de autonumeração.Veja como:
Passo 38: Digite os comandos a seguir aplicando o comando CREATE 
TABLE COMPONENTES para criar um identificador e veja o resultado na 
imagem logo após.
CREATE TABLE Componentes (
sequencia INT UNSIGNED NOT NULL AUTO_INCREMENT,
descricao CHAR(50) NOT NULL,
PRIMARY KEY (sequencia)
);
O campo sequencia será do tipo inteiro sem sinal, não admitirá nulos 
e será com autoincremento.
INSERT INTO Componentes(descricao) VALUES (‘Resistor’);
SELECT * FROM COMPONENTES;
Figura 72 - Exemplo de resultado usando 
o comando Componentes
Fonte: Produção do próprio autor
Adicione mais alguns itens.
Passo 39: Digite os comandos a seguir e veja o resultado na imagem 
logo após.
INSERT INTO Componentes(descricao) VALUES (‘Capacitor’), 
(‘Transistor’), (‘Circuito integrado’), (‘Diodo’);
Note que, após a cláusula VALUES, colocamos vários valores, economi-
zando a digitação do comando INSERT.
Veja como ficou (use o comando SELECT, que você já conhece) na 
imagem (Figura 73) a seguir.
129Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Figura 73 - Exemplo de resultado 
usando o comando SELECT
Fonte: Produção do próprio autor
Desafio: procure no manual ou na internet uma solução para que os 
próximos valores de autoincremento iniciem em 100; execute a solução e 
insira alguns valores para testar.
Uma possibilidade seria a seguinte:
ALTER TABLE Componentes AUTO_INCREMENT = 100;
INSERT INTO Componentes(descricao) VALUES (‘Varistor’), (‘LED’);
SELECT * FROM Componentes;
Figura 74 - Exemplo de resultado usando 
o comando ALTER TABLE
Fonte: Produção do próprio autor
Essa tabela de componentes eletrônicos foi criada somente para ilus-
trar os campos de autonumeração e, evidentemente, não faz parte da 
modelagem vista até aqui (Figura 34). Mas não se preocupe, pois na se-
quência ela será eliminada do banco de dados.
3.6.8 Apagar dados e destruir objetos
Para apagar o conteúdo de uma tabela, utilizaremos o comando DE-
LETE. Após utilizado, o conteúdo da tabela será apagado, mas não sua 
estrutura.
Para destruir um objeto, ou seja, apagá-lo definitivamente do banco 
de dados, utilizamos o comando DROP. Após utilizá-lo, o objeto será to-
talmente eliminado; se efetuarmos o DROP em uma tabela, seu conteúdo 
e estrutura serão eliminados.
130 Planejamento e Elaboração de Bases de Dados
Atenção
CUIDADO! Os SGBDs não possuem um comando de undelete, de 
desfazer o que foi feito, como nos editores de texto e planilhas. 
Uma vez executada a transação com êxito, ela não poderá ser des-
feita, ou seja, se você apagar os dados de uma tabela, ou a própria 
tabela, não há como recuperá-los com um comando. A única for-
ma é o par backup/restore, se o backup tiver sido executado 
antes (que nem sempre fornecerá a última versão).
3.6.8.1 Apagar dados da tabela Componentes
Vamos apagar da tabela componentes todos os dados referentes a 
componentes cujo código seja menor do que 100.
Passo 40: Digite os comandos a seguir usando o comando DELETE 
para valores menores que 100 e veja o resultado na imagem logo após.
DELETE FROM Componentes WHERE sequencia < 100;
SELECT * FROM Componentes;
Figura 75 - Exemplo de resultado usando o comando 
DELETE para dados menores que 100
Fonte: Produção do próprio autor
Agora vamos apagar os dados restantes.
Passo 41: Digite os comandos a seguir usando o comando DELETE 
para valores maiores que 99 e veja o resultado na imagem logo após.
DELETE FROM Componentes WHERE sequencia > 99;
Observação: se você não estiver rodando no modo de segurança, 
pode executar DELETE FROM Componentes; para apagar todos os da-
dos da tabela. Se estiver, o comando será bloqueado.
SELECT * FROM Componentes;
Figura 76 - Exemplo de resultado usando o 
comando DELETE para dados maiores que 99
Fonte: Produção do próprio autor
131Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
A tabela está vazia, porém, continua no banco de dados. Vamos veri-
ficar se a tabela Componentes ainda é funcional, apesar de ter tido todo 
o conteúdo apagado.
Passo 42: Digite os comandos a seguir e veja o resultado na imagem 
logo após.
INSERT INTO Componentes(descricao) VALUES (‘teste da estrutura 
da tabela’);
SELECT * FROM Componentes;
Figura 77 - Exemplo de resultado usando o comando 
INSERT INTO para verificar se os dados foram 
totalmente apagados do BD
Fonte: Produção do próprio autor
Comprovamos, então, que a estrutura da tabela está intacta. Somente 
seu conteúdo foi apagado ao utilizarmos o comando DELETE.
3.6.8.2 Apagar um objeto do banco de dados
Para retirar um objeto do banco de dados, utilizamos o comando 
DROP (que também pode ser utilizado para apagar o próprio banco de 
dados). Se utilizado para apagar um objeto do tipo tabela, por exemplo, 
ele apagará não somente seu conteúdo mas também sua estrutura; a 
tabela deixará de existir. Vamos retirar de nosso banco de dados a tabela 
Componentes.
Passo 43: Digite os comandos a seguir e veja o resultado.
DROP TABLE Componentes;
SELECT * FROM Componentes;
Retornará:
Error Code: 1146. Table ‘pratica1.componentes’ doesn’t exist
Ou seja, a tabela Componentes não existe mais, desaparecendo com 
ela todo o seu conteúdo!
COMENTÁRIOS
Agora que já possuímos algum conhecimento básico da manipulação 
de bancos de dados utilizando a linguagem SQL, poderá surgir a pergun-
ta: todos os bancos de dados exigem a execução de comandos SQL e, 
portanto, seu conhecimento? A resposta é sim e não. Se forem bancos de 
dados baseados no modelo relacional, e que implementem os comandos 
SQL, sim, será sempre necessário executar comandos nessa linguagem. 
Mas, não, não é essencial conhecer SQL sempre. Vamos tomar por exem-
132 Planejamento e Elaboração de Bases de Dados
plo o difundido MS-Access, que executa comandos SQL mas que permite 
ao usuário, por meio de interface gráfica de consulta, gerar os comandos 
e executá-los simplesmente selecionando ícones ou relações entre o con-
teúdo existente. Embora o usuário possa ver e alterar os comandos, pode 
trabalhar sem utilizá-los de forma direta (o SGBD sempre os utilizará).
Então, por que não estamos utilizando um gerenciador desse tipo? 
Porque o conhecimento da linguagem auxilia na ampliação do pensamento 
lógico, na busca por um melhor modelo e na utilização dos comandos 
que deverão ser colocados em outras aplicações. Por exemplo, páginas da 
internet escritas em linguagem PHP ou JAVA embutem comandos SQL, 
exatamente os praticados aqui, para retornar listas de dados que serão 
posteriormente formatadas e exibidas. Além disso, este material é voltado a 
um curso de bacharelado, o qual é voltado para o aprendizado de conceitos 
e a possibilidade de crescimento de aprendizado e pesquisas futuras.
Como curiosidade, note que executamos o que é popularmente 
conhecido como CRUD, que é um acrônimo para as palavras da língua 
inglesa Create, Read, Update e Delete (ou Destroy), correspondendo, 
respectivamente à criação, leitura/recuperação, atualização e destruição 
de um dado; no SQL utilizamos respectivamente os comandos INSERT, 
SELECT, UPDATE e DELETE para realizar essas operações. Observe que 
essa sequência de operações (PINTO, 2000) implementa o ciclo de vida 
do dado ou da informação a ele vinculada.
3.6.8.3 Atividade
A situação referente ao exercício final da unidade anterior foi retomada em sua empresa (retorne 
àquela unidade e revise-a). Após algumas alterações, decidiu-se que, para idealizar o congresso 
desejado, cada área temática teria um ou mais patrocinadores, e que cada patrocinador teria a 
possibilidade de patrocinar mais de uma área, sempre implicando um determinado valor de auxílio. E 
que cada área poderia ter mais de um palestrante.
Também ficou estabelecido que uma palestra poderia contar com mais de um palestrante, e que 
um mesmo palestrante poderia realizar mais de uma palestra.
O MER foi refeito, ficando com o aspecto apresentado a seguir.
133Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Os tipos dedados foram melhor definidos a partir da análise da documentação e de conversas 
com os interessados. Foram elaborados dicionários de dados, representados pelos quadros anteriores.
TABELA: Patrocinador
CAMPO IDENTIFICADOR TIPO DE DADOS TAMANHO Valor mínimo Valor máximo
Email SIM VARCHAR 50
Nome NÃO VARCHAR 50
Telefone NÃO VARCHAR 20
TABELA: Area
CAMPO IDENTIFICADOR TIPO DE DADOS TAMANHO Valor mínimo Valor máximo
Sigla SIM VARCHAR 10
Descricao NÃO VARCHAR 50
TABELA: Tema
CAMPO IDENTIFICADOR TIPO DE DADOS TAMANHO Valor mínimo Valor máximo
Codigo SIM CHAR 15
Descricao NÃO VARCHAR 50
grau_dificuldade NÃO INT 0 10
TABELA: Palestra
CAMPO IDENTIFICADOR TIPO DE DADOS TAMANHO Valor mínimo Valor máximo
Sequencia SIM INT 1
Titulo NÃO VARCHAR 50
Data NÃO DATE
Duracao NÃO INT 1 2
TABELA: Palestrante
CAMPO IDENTIFICADOR TIPO DE DADOS TAMANHO Valor mínimo Valor máximo
Rg SIM INT
Telefone NÃO VARCHAR 20
Email NÃO VARCHAR 50
Nome NÃO VARCHAR 50
134 Planejamento e Elaboração de Bases de Dados
Note que os tamanhos de campos e tipos de dados não são homogêneos; preste atenção à mo-
delagem.
Definiram-se também quais são as consultas necessárias, chegando-se à seguinte lista:
a) todos os patrocinadores de cada área, ordenados por valor de contribuição;
b) todas as palestras de todos os palestrantes, ordenadas pelo nome do palestrante;
c) relação das palestras em ordem sequencial, informando-se o palestrante que a realizou. A 
data deverá ser no formato brasileiro e o cabeçalho deverá mostrar a palavra Palestrante para 
indicar seu nome;
d) uma relação de todas as palestras que foram realizadas a trinta dias ou menos a partir da data 
atual.
A partir dessas informações:
a) crie todos os comandos necessários à criação das tabelas;
b) apresente as declarações SQL referentes às operações de consulta necessárias.
Dica: lembre-se de que as ferramentas de modelagem podem gerar o código estrutural, de forma 
que você pode contar com o auxílio delas para criar as tabelas, restando apenas as consultas.
Resposta comentada
A solução que segue apresenta consultas que respondem às questões formuladas contra as tabe-
las criadas a partir das declarações que seguem. Se você criou tabelas de forma diferente, as consul-
tas deverão ser adaptadas, evidentemente.
Para ter certeza de que seu modelo funciona, cadastre dados e teste-o.
Criação das tabelas:
a) Consultas
#1. todos os patrocinadores de cada área, ordenados por valor de contribuição;
SELECT descricao, nome, valor FROM Area,Patrocinador, patrocinio WHERE patrocinio.sigla = 
Area.sigla AND patrocinio.email = Patrocinador.email ORDER BY valor;
135Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Explicação: seleciona (SELECT) as colunas descricao, nome e valor, a partir das tabelas (FROM) 
Area,Patrocinador, patrocínio, nas quais (WHERE) exista ligação entre a sigla do patrocínio e 
da área (patrocinio.sigla = Area.sigla) e (AND) do email (patrocinio.email = Patrocinador.email), 
ordenando (classificando) pelo valor (ORDER BY valor).
#2. todas as palestras de todos os palestrantes, ordenadas pelo nome do palestrante;
SELECT nome, titulo FROM Palestrante,Palestra, palestrante_palestra WHERE palestrante_
palestra.rg = Palestrante.rg AND palestrante_palestra.sequencia = Palestra.sequencia ORDER 
BY nome;
Explicação: seleciona (SELECT) os campos nome e titulo a partir (FROM) das tabelas 
Palestrante,Palestra e palestrante_palestra, sempre que (WHERE) os números de RG forem iguais 
(palestrante_palestra.rg = Palestrante.rg) e (AND) as sequências também (palestrante_palestra.
sequencia = Palestra.sequencia), ordenado posteriormente pelo nome do palestrante (ORDER BY 
nome);
#3. relação das palestras em ordem sequencial, informando-se o palestrante que a realizou. 
A data deverá ser no formato brasileiro e o cabeçalho deverá mostrar a palavra Palestrante 
para indicar seu nome
SELECT Palestra.sequencia, titulo, DATE_FORMAT(Palestra.data, ‘%d/%m/%Y’) As ‘Data’, 
duracao, nome AS ‘Palestrante’ FROM Palestrante, Palestra, palestrante_palestra WHERE 
palestrante_palestra.rg = Palestrante.rg AND palestrante_palestra.sequencia = Palestra.
sequencia ORDER BY Palestra.sequencia;
Explicação: seleciona (SELECT) os campos sequência, da tabela palestra (Palestra.sequencia) 
e, nesse caso, estamos informando a tabela, pois pode existir outro campo com o mesmo 
nome em outra tabela, o campo titulo, a data de realização, formatada pelo comando DATE_
FORMAT(Palestra.data, ‘%d/%m/%Y’) e com o cabeçalho de Data (AS ‘Data’), o campo duração, 
o campo nome com o cabeçalho de Palestrante (AS ‘Palestrante’) a partir das tabelas (FROM) 
Palestrante, Palestra e palestrante_palestra, limitando o resultado para quando os números de RG 
e sequência forem idênticos nas tabelas requeridas (WHERE palestrante_palestra.rg = Palestrante.
rg AND palestrante_palestra.sequencia = Palestra.sequencia) e fornecendo o resultado por ordem 
de sequência cadastrada (ORDER BY Palestra.sequencia;)
#4. uma relação de todas as palestras que foram realizadas a 30 dias ou menos a partir da 
data atual.
SELECT Palestra.sequencia AS ‘#’, Palestra.titulo AS ‘Título’, DATE_FORMAT(Palestra.
data, ‘%d/%m/%Y’) AS ‘Data’, Palestra.duracao AS ‘Duração’ FROM Palestra WHERE 
DATEDIFF(CURDATE(), Palestra.data) <31;
Explicação: seleciona o número da palestra com o cabeçalho de # no resultado (SELECT Palestra.
sequencia AS ‘#’), o título da palestra com o cabeçalho Título (Palestra.titulo AS ‘Título’), a data 
de realização no formato dia-mês-ano, com cabeçalho Data (DATE_FORMAT(Palestra.data, 
‘%d/%m/%Y’) AS ‘Data’), e a duração da palestra com o cabeçalho Duração (Palestra.duracao 
AS ‘Duração’), a partir da tabela Palestra (FROM Palestra), somente quando for a atendida a 
situação de que a diferença entre a data atual (CURDATE()) e a data da palestra for menor do 
que 31 (WHERE DATEDIFF(CURDATE(), Palestra.data) <31;), ou seja, para palestras ocorridas há 
30 dias ou menos. Você deve notar aqui que, na execução de seu comando, serão consideradas 
a data atual do seu sistema e as datas cadastradas no seu banco de dados.
136 Planejamento e Elaboração de Bases de Dados
CONCLUSÃO
O trabalho com bancos de dados pode ser fascinante, com 
oportunidades de desenvolvimento profissional e da lógica necessária à 
elaboração de boas consultas. Nesta disciplina, tivemos a oportunidade 
de verificar o papel da modelagem conjunta com o usuário, realizar 
experimentos com diagramas MER e, especificamente nesta unidade, 
colocar em prática os conceitos para ver um banco de dados funcionar. 
Implica conhecer ferramentas de software e técnicas, aliar conceitos a 
atividades práticas, e praticar. Praticar muito.
Embora tenhamos passado nesta unidade pelos comandos básicos, 
os quais constituem grande parte do trabalho com bancos de dados, as 
variações possibilitadas pela SQL e a complexidade que alguns tipos de 
consulta e junções podem atingir nem de longe foi alcançada.
O que foi visto permite que você participe de discussões a repeito 
do planejamento e implementação de bancos de dados com conceitos 
suficientes para compreender o andamento do projeto e, ainda, poderá 
participar de projetos mais simples ou acompanhar os muitos exemplos 
existentes na imensa internet.
Cumprimos o papel de introduzir os conceitos e as práticas iniciais. 
Agora, cabe a você fazer mais por si e aprofundar seus conhecimentos. 
Para quem realmente deseja saber um pouco mais a respeito de bancos 
de dados, sugiro de imediato prosseguir nos estudos com normalização, 
criação de visões e o uso do comando JOIN.
RESUMO
A modelagem física é a ligação do modelo conceitual com a identifi-
cação de tipos de dados e chaves necessárias à implementação do banco 
de dados.
Para a implementação, por meio dos comandos de criação de dados 
(DDL, abreviatura inglesa para a linguagem de definição de dados) da 
linguagem de consulta estruturada, ou SQL, iremos enviar as declarações 
para processamento no SGBD.Os comandos utilizados na criação de dados são o CREATE DATABASE 
e o CREATE TABLE. O primeiro é capaz de criar uma estrutura de banco de 
dados em um arquivo em disco, a ser gerenciado pelo SGBD. O segundo, 
cria as tabelas dentro do banco de dados. Para este último será necessário 
termos previamente uma boa definição dos metadados, tipos de dados, o 
que será considerado chave, o que poderá e o que não poderá ser nulo e 
domínios de valores a armazenar. Isso porque, se a tabela for definida de 
forma incorreta, posteriormente o armazenamento dos dados reais não 
será possível.
O conteúdo das tabelas é definido por declarações entre chaves 
( { e } ) e serão utilizados os tipos de dados compatíveis com o que se 
deseja armazenar e disponíveis no SGBD, por exemplo INT para números 
137Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
inteiros e CHAR e VARCHAR para caracteres. Os tipos CHAR e VARCHAR 
deverão ter o tamanho máximo informado (quantidade de caracteres dis-
poníveis para armazenamento), o que é realizado na forma VARCHAR 
(50), que possibilita cinquenta caracteres.
Após a criação dos objetos básicos no SGBD (banco e suas tabelas) 
o trabalho passará a ser realizado por meio dos comandos do grupo de 
manipulação de dados (DML na sigla inglesa).
São quatro os comandos básicos para trabalhar com a manipulação 
dos dados: INSERT, para inserir os dados no banco, SELECT, para re-
cuperar os dados na forma de listas, UPDATE, para atualizar os dados 
após cadastrados, e DELETE, para apagar dados que não são mais 
necessários. Esses comandos são auxiliados por uma série de cláusulas 
e de funções, tais como para manipulação de datas ou geração de 
números sequenciais.
A utilização dos comandos SELECT, UPDATE e DELETE quase sempre 
vem acompanhada da cláusula WHERE, que permite especificar exata-
mente qual a linha ou conjuntos de linhas da tabela deverão ser recupe-
radas, atualizadas ou apagadas, respectivamente. A cláusula WHERE está 
fortemente ligada às chaves e aos identificadores utilizados na modela-
gem das tabelas do banco.
O comando INSERT possui em sua sintaxe a sequência INSERT INTO 
nome-da-tabela VALUES seguido dos valores dos dados a cadastrar.
O comando SELECT tem sintaxe básica SELECT quais-campos-selecionar 
FROM nome-da-tabela WHERE cláusulas-condicionais.
Para o comando UPDATE a sintaxe é UPDATE nome-da-tabela SET 
nome-do-campo = valor WHERE condição.
O comando DELETE possui a seguinte sintaxe: DELETE FROM nome-
da-tabela WHERE condições.
Embora exista um comando, ALTER, que permite realizar algumas al-
terações nas tabelas, e mesmo sabendo-se que as estruturas criadas po-
dem ser eliminadas, com o comando DROP, e depois recriadas, fica claro 
o papel e a importância da modelagem prévia, por exemplo, por meio 
de um MER, para o trabalho produtivo e eficiente com bancos de dados 
relacionais.
Além das questões conceituais, lembre-se de praticar os comandos. É 
a melhor forma de aprendê-los, pois o que se pode resumir é somente a 
sintaxe básica; a prática é que trará a aprendizagem.
Finalmente, note que os objetos, tais como o banco de dados ou 
as tabelas, são criados. Já os dados são manipulados. Os dados só são 
criados quando utilizamos operações de agrupamento ou matemáticas. 
Um exemplo é contar o número de livros cadastrados em uma tabela, por 
exemplo, por meio do comando COUNT. Porém, se estamos criando esse 
dado, na verdade, estamos criando uma informação, ou seja, estamos 
processando os dados (contando os livros) para criar uma informação 
que corresponda a esse número desejado (quantidade de livros). Note a 
ligação com seus conhecimentos teóricos prévios.
138 Planejamento e Elaboração de Bases de Dados
Sugestão de Leitura
CELKO, J. SQL for smarties: advanced SQL programming. 4. ed. 
[s.l.]: Morgan Kaufmann, 2010.
DATE, C. J. Introdução a sistemas de banco de dados. Rio de 
Janeiro: Campus, 2001.
HEUSER, C. A. Projeto de banco de dados. 6. ed. São Paulo: 
Bookman, 2009.
LARMAN, C. Applying UML and patterns: an introduction 
to object- oriented analysis and design and the unified process. 
Prentice-Hall: New Jersey, 2004.
PINTO, J. S. de P. Bancos de dados distribuídos, middleware 
e integração de aplicações. In: SOUZA, L. de; QUINÁIA, M. 
A.; VENSKE, S. M. S. (orgs.). ERI 2007. XIV Escola Regional 
de Informática SBC-PR. Guarapuava, PR: Gráfica Universitária 
Unicentro, 2007. v. 1, p. 199-224.
ULLMAN, J. D.; WIDOM, J. A first course in database systems. 
New Jersey: Prentice Hall, 1997.
REFERÊNCIAS
ELMASRI, R.; NAVATHE, S. B. Sistemas de bancos de dados. 
6. ed. São Paulo: Pearson, 2011.
LAUDON, K. C.; LAUDON, J. P. Sistemas de informação com 
internet. 4. ed. Rio de Janeiro: LTC, 1999.
MACHADO, F.; ABREU, M. Projeto de banco de dados: uma 
visão prática. 11. ed. São Paulo: Érica, 2004.
MARTIN, J.; FILKELSTEIN, C. Engenharia da Informação: 
técnicas e abordagens de implementação. Cadernos de 
Informática, São Paulo, [s.n.], 1984. (Série James Martin)
NASCIMENTO, J. B. do. Metodologias de desenvolvimento 
de sistemas. São Paulo: Érica, 1993.
PINTO, J. S. de P. SQL: guia de consulta e aprendizagem. Rio de 
Janeiro: BookExpress, 2000.
PINTO, J. S. de P. CGI: guia de consulta e aprendizagem. Rio de 
Janeiro: BookExpress, 2001.
139Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
SERVA, M.; JAIME JR, P. Observação participante e pesquisa 
em administração: uma postura antropológica. Revista de 
Administração de Empresas, São Paulo, v. 35, n. 1, p, 64-79, 
maio/jun. 1995.
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de 
banco de dados. 5. ed. São Paulo: Elsevier, 2006.
STAIR, R. M. Princípios de Sistemas de Informação: uma 
abordagem gerencial. 2. ed. Rio de Janeiro: LTC, 1998.
SUSMAN, G. I.; EVERED, R. D. An assessment of the scientific 
merits of action research. Administrative Science Quarterly, 
v. 23, p, 582-603, Dec. 1978.
APÊNDICE A
 APRESENTAÇÃO DA 
FERRAMENTA BR MODELO PARA 
MODELAGEM ENTIDADE VERSUS 
RELACIONAMENTO
Existem várias ferramentas de software, pagas e gratuitas, disponíveis na internet, as quais são 
capazes de apoiar o desenvolvimento de diagramas que correspondem aos modelos físico e lógico de 
bancos de dados. Nesta disciplina, optou-se pela brModelo, que é disponível (infelizmente) somente 
para ambiente Microsoft Windows, o que não impede que seja utilizada diretamente no Linux, por 
exemplo, por meio do Wine ou de máquinas virtuais.
Não é o objetivo desta disciplina um curso da ferramenta, mas sim da modelagem. Porém, para 
facilitar seu trabalho de aprendizagem, nas páginas seguintes veremos uma rápida apresentação 
da ferramenta escolhida e de sua utilização no apoio à modelagem de um banco de dados. 
Alternativamente você poderá utilizar qualquer outra ferramenta que tenha à sua disposição, nesse 
caso, passando diretamente à modelagem.
A ferramenta em questão pode ser obtida no seguinte link: http://sis4.com/brModelo/. Acesso em 
20 ago. 2014.
142 Planejamento e Elaboração de Bases de Dados
A imagem (Figura A.1) mostra a tela inicial da ferramenta.
Figura A.1 - Tela inicial da ferramenta brMODELO
Fonte: Produção do próprio autor15
Para trabalhar com essa ferramenta, dispomos de três grandes conjun-
tos de ícones.
Os Quadros A.1, A.2 e A.3, ao final desse texto, explicam suas funcio-
nalidades.
Após baixar e instalar a ferramenta, para começarmos os trabalhos 
com ela, a partir da tela inicial (Figura A.1), vamos utilizar inicialmente as 
ferramentas de modelagem conceitual (as funções estão no Quadro A.2).
Veja uma sequência de trabalho (acompanhe pela Figura A.2):
a) clicar no ícone de criação de nova entidade;
b) ;
c) posicionar o cursor no ponto desejado do diagrama e clicar; será 
criado um retângulo com o nome de Entidade_1;
d) clique na Entidade_1, ela vai ficar selecionada;
15 Cópia de tela da execução do programa brMODELO.
143Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
e) na guia de seleção,na edição dos atributos da entidade, clique 
sobre o nome e renomeie-o para Pessoa;
f) a entidade está criada e com o novo nome.
Figura A.2 - Utilização da ferramenta brMODELO para criação de uma nova entidade pessoa
Fonte: Produção do próprio autor16
Vamos agora criar atributos em nossa entidade Pessoa. O processo é 
parecido com o anterior, bem fácil de realizar. Vamos fazer assim (acom-
panhe pela Figura A.3):
a) clicar no ícone de atributo identificador ;
b) clicar na entidade Pessoa;
c) selecionar o atributo, clicar no aba de mudança de edição e trocar 
o nome para CPF;
d) repetir os passos anteriores, porém clicando no ícone de criação de 
atributo ( ), e criar e nomear o atributo nome;
e) clicar no ícone de atributo multivalorado e 
criar o atributo telefone, conforme os passos anteriores;
f) clique na entidade pessoa e arraste-a pela tela. Você verá que é 
possível posicioná-la onde quiser. Depois, pode ajustar os atributos 
(para ajustá-los em conjunto basta selecioná-los com o mouse);
g) clicar no ícone de atributo composto e criá-lo 
na entidade Pessoa.
Neste ponto, seu diagrama deverá ter uma entidade correspondente à 
da imagem (Figura A.3).
16 Cópias de telas da ferramenta brMODELO editadas pelo autor.
144 Planejamento e Elaboração de Bases de Dados
Figura A.3 - Utilização da ferramenta brMODELO para 
criação de atributos na entidade pessoa
Fonte: Produção do próprio autor17
Para ajustar o atributo composto (Figura A.4):
a) clique primeiramente sobre o nome Atributo_1 e mude-o para 
endereco (acostume-se a evitar cedilhas e outras formas gráficas de 
acentuação nos modelos); na sequência ajuste o Atributo_2 para 
logradouro e o Atributo_3 para numero;
b) clique no ícone de criação de atributo e depois clique no atributo 
endereco; faça isso três vezes, para criar três novos atributos, 
renomeando-os depois para CEP, cidade e estado.
Figura A.4 - Utilização da ferramenta brMODELO para ajuste 
do atributo composto endereço na entidade pessoa
Fonte: Produção do próprio autor18 
Vamos agora trabalhar com os atributos em função do dicionário de 
dados (Figura A.5):
Nosso dicionário de dados simplificado será o seguinte:
Quadro A.1 - Dicionário de dados
Campo Identificador Multivalorado Opcional Composto
Tipo 
de dado
CPF SIM NÃO NÃO NÃO int
nome NÃO NÃO NÃO NÃO char(50)
telefone NÃO
SIM, 
máximo 3
SIM NÃO char(20)
endereco NÃO NÃO NÃO SIM char(148)
endereco.logradouro NÃO NÃO NÃO NÃO char(50)
endereco.numero NÃO NÃO NÃO NÃO char(20)
endereco.cep NÃO NÃO NÃO NÃO int
endereco.cidade NÃO NÃO NÃO NÃO char(50)
endereco.estado NÃO NÃO NÃO NÃO char(20)
17 Cópias de telas da ferramenta brMODELO editadas pelo autor.
18 Cópias de telas da ferramenta brMODELO editadas pelo autor.
145Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
a) clique no atributo CPF;
b) clique na aba de edição de atributo;
c) informe o tipo de dados int no campo nomeado Tipo (opcional). 
Note as outras informações pertinentes, tais como se é ou não 
composto ou se é multivalorado. Experimente trocar a opção 
Identificador para Não e veja o que acontece no diagrama, depois 
retorne para Sim.
Figura A.5 - Utilização da ferramenta brMODELO para ajuste de características 
dos atributos conforme o dicionário de dados do modelo
Fonte: Produção do próprio autor19 
Continue a edição para os demais atributos, seguindo o espe-
cificado no dicionário de dados passado. Para o caso do telefone, 
informe 3 na cardinalidade máxima.
Agora vamos criar um modelo lógico:
a) clique sobre a entidade Pessoa e, com o botão direito do mouse, 
selecione Gerar Esquema Lógico;
b) surgirá uma janela com três opções. Selecione a opção b) e clique 
em OK;
c) outra janela do assistente surgirá. Selecione novamente a opção b);
d) você criou o modelo lógico. Observe-o, explore-o, salve-o. Para 
voltar à janela do modelo conceitual use .
Figura A.6 - Criação do modelo lógico a partir do modelo conceitual
Fonte: Produção do próprio autor20 
19 Cópias de telas da ferramenta brMODELO editadas pelo autor.
20 Cópias de telas da ferramenta brMODELO editadas pelo autor.
146 Planejamento e Elaboração de Bases de Dados
A escolha de outras opções durante a geração do modelo trará, 
evidentemente, resultados diferentes. Observe outras possibilidades na 
imagem (Figura A.7).
Figura A.7 - Criação do modelo lógico a partir do modelo conceitual: outras opções
Fonte: Produção do próprio autor21
Rápida discussão: comparando-se as Figuras A.6 e A.7, vemos 
que o modelo lógico gerado em cada caso implicará termos uma 
única tabela (A.6), duas tabelas (A.7 direito) ou três tabelas (A.7 
esquerdo) em nosso banco de dados. A vantagem de dividir é que 
podemos reaproveitar melhor os dados e criar possibilidades de 
conjuntos (conjuntos de endereço, de telefone) para cada pessoa. 
A desvantagem é que serão mais tabelas a unir no momento da 
consulta. É uma decisão de projeto; todas são funcionais.
Volte ao modelo conceitual ( ) e gere um novo 
modelo lógico (clique na entidade Pessoa e clique o botão direito do 
mouse, selecionando Gerar Esquema Lógico). Responda a) e a) para 
as opções apresentadas pelos assistentes (criar tabelas separadas), de 
forma a gerar um esquema equivalente ao da Figura A.7, lado esquerdo. 
Ajuste a cardinalidade da tabela endereço para (1,n). Acompanhe o 
resultado pela imagem (Figura A.8). Note que, se você não conseguiu 
o resultado esperado na primeira interação, sempre poderá realizar 
novamente os passos, até aprender. O objetivo é esse. Não tenha medo 
de errar nem se preocupe com o fato de ter de fazer mais de uma vez, 
cada pessoa tem um ritmo e uma concentração.
21 Cópias de telas da ferramenta brMODELO editadas pelo autor.
147Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Figura A.8 - Utilização da ferramenta brMODELO para gerar modelo lógico: 
cardinalidade ajustada
Fonte: Produção do próprio autor22
Assim, teremos agora a possibilidade de que a pessoa possua mais de 
um endereço, digamos um residencial e um comercial (e deveríamos ter 
um identificador de qual é, mas deixaremos para depois).
Agora vamos gerar o esquema físico. Clique com o botão direito do 
mouse sobre qualquer ponto do diagrama e selecione Gerar Esquema 
Físico. Clique em Conversão e Converter para confirmar a conversão de 
dados solicitada e você terá o esquema físico gerado. O arquivo com 
as declarações pode ser salvo e posteriormente aberto dentro de sua 
ferramenta de trabalho com o SGBD. Acompanhe o resultado dessas 
operações pela imagem (Figura A.9).
Figura A.9 - Utilização da ferramenta brMODELO para gerar o esquema físico
Fonte: Produção do próprio autor23
22 Cópias de telas da ferramenta brMODELO editadas pelo autor.
23 Cópias de telas da ferramenta brMODELO editadas pelo autor.
148 Planejamento e Elaboração de Bases de Dados
O esquema físico será utilizado na Unidade 3 desta disciplina.
Agora que você já possui o básico, pratique mais um pouco e volte 
para a Unidade 2 da disciplina, para aprender mais a respeito de mode-
lagem conceitual.
Quadro A.2 - Funções dos ícones da barra de ferramentas básicas 
do software brMODELO
Ícone Finalidade
Cria um novo diagrama de modelagem 
conceitual. Não salva o anterior automati-
camente, caso tenha sido realizada alguma 
modificação nele.
Cria um novo diagrama de modelagem ló-
gica. Não salva o anterior automaticamen-
te, caso tenha sido realizada alguma modi-
ficação nele.
Carrega para edição os arquivos de mo-
delos conceituais e lógicos anteriormente 
salvos.
Permite que os modelos sob edição sejam 
automaticamente salvos em disco em inter-
valos de tempo configuráveis pelo usuário. 
Sistema/Configurações do sistema/Aba 
de autossalvamento. O tempo deverá ser 
informado, em minutos. O padrão, caso 
não seja alterado, é de salvamento a cada 
5 minutos.
Guarda em arquivo digital o diagrama exi-
bido na tela.
Fecha a exibição e a edição do arquivo 
atual, perguntando antes se é necessáriosalvar alterações, caso tenham ocorrido.
Abre a tela do gerenciador de impressão, 
que permite configurar impressoras e a for-
ma de impressão, assim como comandar a 
impressão do diagrama exibido.
Desfaz a última alteração realizada no dia-
grama em edição. O atalho para a mesma 
função, padrão no Windows, é a combina-
ção das teclas CTRL + Z.
Permite desfazer o trabalho da função des-
fazer, caso essa função tenha sido clicada 
por engano. O atalho para a mesma fun-
ção, padrão no Windows, é a combinação 
das teclas CTRL + Z. ATENÇÃO: essa tecla 
pode trazer a mensagem “Stream read er-
ror” e não funcionar, tratando-se de um 
bug do programa.
Permite alternar a tela de edição entre os 
diagramas abertos.
Permite a localização rápida dos objetos 
adicionados no diagrama aberto para edi-
ção (se houver mais de um diagrama aber-
to, localiza os objetos no diagrama que 
está em exibição).
Fonte: Produção do próprio autor24
24 Elaboração do autor a partir das características e cópias de telas da ferramenta brMODELO.
149Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Quadro A.3 - Funções dos ícones da barra de ferramentas para modelagem conceitual do software brMODELO
Ícone Finalidade
Cancela a seleção de operação (ícones a seguir). Somente fica habili-
tado se for clicado um dos ícones da barra, comentados na sequência.
Criar uma nova entidade no diagrama. Por exemplo, criar a entidade 
pessoa ou a entidade livro.
Criar um relacionamento entre entidades do diagrama. Por exemplo, 
criar o relacionamento de empréstimo entre uma entidade pessoa e 
uma entidade livro.
Criar uma entidade associativa no diagrama. Por exemplo, criar uma 
entidade empréstimo, relacionando pessoas com livros. A diferença 
desta para a anterior (criar relação) é que, na associação, será criada 
uma tabela que existe sempre, enquanto, na relação, poderá ou não 
existir uma tabela.
Criar uma especialização de uma entidade no diagrama. Por exemplo, 
a partir de uma entidade pessoa, criar as especializações pessoa física 
e pessoa jurídica. Esse conceito amplia as possibilidades de mode-
lagem e torna os SGDBs mais próximos à modelagem orientada a 
objetos, comumente utilizada hoje no desenvolvimento de sistemas 
de informação.
Permite a utilização da modelagem estendida, com a criação de con-
ceitos de herança advindos da orientação a objetos.
Permite a utilização da modelagem estendida, com a criação de con-
ceitos de herança advindos da orientação a objetos.
Cria um atributo na entidade selecionada. Permite atribuir as carac-
terísticas da entidade. Por exemplo, criar os atributos nome e gênero 
para uma entidade pessoa.
Permite a criação de um atributo que será o identificador ou a chave 
da tabela.
Permite a criação de um atributo que, na verdade, é formado por um 
conjunto de outros atributos. Endereço é um caso típico.
Atributo que será posteriormente marcado como sendo um campo 
que pode ser nulo, ou seja, que não deverá estar sempre preenchido/
sendo informado.
Um atributo que poderá assumir vários valores, como o telefone (pode 
haver mais de um). Na transformação do diagrama para tabelas pode-
rá ser representado por uma tabela à parte.
Permite a criação de um relacionamento da tabela com ela mesma. 
Por exemplo, no caso de uma tabela empregado, podemos ter na 
modelagem a especificação de que empregado é chefe de empre-
gado. O relacionamento é chefe de representa a ligação da tabela 
empregado com ela mesma.
Efetua a ligação dos objetos selecionados no diagrama em exibição.
Permite colocar um texto com observações ou destaques no diagrama 
em edição. O texto poderá ter uma moldura configurável, veja o ícone 
seguinte.
Permite colocar um texto com observações ou destaques no diagrama 
em edição. O texto será destacado por um retângulo configurável, 
que poderá ser retirado, ficando o texto com a aparência obtida por 
meio do ícone anterior.
Permite apagar objetos a serem selecionados, inclusive de forma par-
cial quando se tratar de um conjunto. Por exemplo, podemos apagar 
com essa ferramenta um campo de uma tabela.
Apaga o objeto que estiver selecionado, seja conjunto ou único. A 
diferença em relação ao ícone anterior é que. para que essa ferramen-
ta funcione, o objeto a ser apagado já deverá ter sido previamente 
selecionado.
Fonte: Produção do próprio autor25
25 Elaboração do autor a partir das características e cópias de telas da ferramenta brMODELO.
150 Planejamento e Elaboração de Bases de Dados
Quadro A.4 - Funções dos ícones da barra de ferramentas para modelagem lógica da ferramenta brMODELO
Ícone Finalidade
Cancela a seleção de operação (ícones a seguir). Somente fica habilitado se for 
clicado um dos ícones da barra, comentados na sequência.
Permite a criação de tabelas no diagrama correspondente ao modelo físico (as 
tabelas representarão as entidades, associações e especializações do modelo 
conceitual).
Cria relacionamentos entre tabelas, utilizando campos destas (chaves) para 
garantir sua integridade (os campos correspondem aos atributos do modelo 
conceitual). Permite especificar a cardinalidade da relação (a quantidade que 
participa da relação, por exemplo, um livro possui um ou mais autores: cardina-
lidade de 1 para n ).
Cria um campo de dados (atributo, no modelo conceitual) na tabela seleciona-
da. Permite que seja especificado/modificado, se é chave primária ou estrangei-
ra e o tipo de dados correspondente (número, caractere).
Cria um campo que é identificador único de outra tabela. Por exemplo, em uma 
tabela de autores, uma chave estrangeira poderia ser a que corresponde ao 
identificador de uma obra, digamos o ISBN de um livro. As tabelas podem ter 
mais de uma chave estrangeira.
Cria um campo em uma tabela cujo valor é capaz de identificar unicamente 
um elemento de sua composição. Por exemplo, em uma tabela de livros, um 
campo identificador pode ser o ISBN. Quando esse campo é referenciado por 
outra tabela (por exemplo, uma de autores de livros), nessa outra tabela, ele é 
chamado de chave estrangeira (veja o ícone anterior). Somente pode haver uma 
chave primária por tabela, embora ela possa ser composta (por exemplo, nome 
+ nome da mãe + data de nascimento para uma identificação de pessoa).
Cria um separador gráfico no desenho da tabela. Só tem utilidade na melhoria 
da visibilidade dos campos, não influencia o modelo lógico do banco de dados 
em si.
Permite colocar um texto com observações ou destaques no diagrama em edi-
ção. O texto poderá ter uma moldura configurável. Veja o ícone seguinte.
Permite colocar um texto com observações ou destaques no diagrama em edi-
ção. O texto será destacado por um retângulo configurável, que poderá ser 
retirado, ficando o texto com a aparência obtida por meio do ícone anterior.
Permite apagar objetos a serem selecionados, inclusive de forma parcial, quan-
do se tratar de um conjunto. Por exemplo, podemos apagar com essa ferramen-
ta um campo de uma tabela.
Apaga o objeto que estiver selecionado, seja conjunto ou único. A diferença em 
relação ao ícone anterior é que, para que essa ferramenta funcione, o objeto a 
ser apagado já deverá ter sido previamente selecionado.
Fonte: Produção do próprio autor26
26 Elaboração do autor a partir das características e cópias de telas da ferramenta brMODELO.
151Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
APÊNDICE B
APRESENTAÇÃO DA FERRAMENTA 
MYSQL WORKSHOP PARA TRABALHO 
COM SQL E BANCOS DE DADOS 
RELACIONAIS MYSQL
Existe grande variedade de produtos de software que podem ser utilizados para a prática de bancos 
de dados. Entre eles encontramos opções pagas e gratuitas. Escolhemos para esta disciplina um 
gerenciador que possui versão livre para estudantes e práticas acadêmicas (e paga para o mercado): 
o MySQL. Esse SGBD foi escolhido por sua simplicidade de utilização e grande popularidade no meio 
acadêmico e comercial, mas, caso você possua acesso a Oracle, DB2, PostgreSQL, SQLite, MS-SQL Server, 
Microsoft Accessou outro banco de dados que aceite comandos SQL poderá utilizá-lo para as práticas 
que seguem. Eventualmente, pequenos ajustes de sintaxe/digitação serão necessários.
Se quiser utilizar o banco aqui sugerido, para baixar o SGBD foi a acessada a página: http://dev.mysql.
com/downloads/repo/apt/. O último acesso foi realizado em agosto de 2014, de forma que, quando 
você estiver acessando, poderá existir uma versão mais nova; em caso de problemas, consulte a seção 
de downloads a partir da página inicial do MySQL.
Também foi instalado o MySQL Workbench, para facilidade de acesso ao servidor por meio de uma 
interface gráfica, disponível na página indicada.
Este material foi desenvolvido em Linux, distribuição Ubuntu 14.04 LTS, mas a sintaxe aqui utilizada 
funciona igualmente em ambiente MS-Windows (em outros SGBDs, como já comentado, poderá haver 
mínimas diferenças nos comandos e, certamente, haverá nas telas).
http://dev.mysql.com/downloads/repo/apt/
http://dev.mysql.com/downloads/repo/apt/
152 Planejamento e Elaboração de Bases de Dados
• INSTALAÇÃO DO MySQL
Se o MySQL não estiver instalado, poderá sê-lo a partir do gerenciador 
de programas ou a partir dos comandos usuais que, no Ubuntu, por 
exemplo, são (lembre-se de que você precisa da senha de root, use 
sudo na frente do apt-get se não estiver logado como root):
# apt-get install mysql-server
A configuração e o estabelecimento do serviço podem ser realiza-
das com:
a) # mysql_install_db
b) # service mysqld start
c) # chkconfig mysqld on
d) # mysql_secure_installation
e) # service mysql restart
E, finalmente, atribuir uma senha para o usuário root do SGBD:
# mysqladmin -u root password coloque aqui sua senha
No MS-Windows a instalação poderá ser realizada a partir do 
programa baixado na seguinte página: https://dev.mysql.com/downloads/
workbench/ (acesso em: dez. 2014).
Após baixá-lo, basta iniciá-lo e responder às questões do assistente.
Executados esses passos, o SGBD estará instalado e pronto para 
funcionar. A partir de agora, você já pode utilizar seu MySQL, basta digitar 
os comandos no terminal, no caso do Linux (veja Figura B.1), ou na janela 
de comandos, se for MS-Windows.
https://dev.mysql.com/downloads/workbench/
https://dev.mysql.com/downloads/workbench/
153Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Figura B.1 - Execução de comandos no MySQL em interface texto por meio do terminal no sistema Ubuntu
Fonte: Produção do próprio autor27
• INSTALAÇÃO DO MySQL WORKSHOP
Para melhorar a usabilidade, podemos instalar o ambiente gráfico 
MySQL Server Workshop. Vejamos como.
No Ubuntu, ele pode ser obtido em http://dev.mysql.com/downloads/
repo/apt/ (acesso em: ago. 2014) e executado com o gerenciador de 
pacotes, por exemplo.
No MS-Windows, acesse: http://dev.mysql.com/downloads/installer/ 
(acesso em: dez. 2014), baixe o programa e depois execute-o. Bastará 
seguir as instruções do assistente.
27 Cópia de tela durante a execução do terminal no equipamento do autor.
http://dev.mysql.com/downloads/repo/apt/
http://dev.mysql.com/downloads/repo/apt/
http://dev.mysql.com/downloads/installer/
154 Planejamento e Elaboração de Bases de Dados
A seguir, estão cópias de telas de algumas operações a serem realizadas 
no Workbench. Antes, uma observação. Os programas evoluem. E muito, 
muito rapidamente. Dessa forma, não é improvável que a interface 
do programa que você está utilizando seja diferente; com certeza será 
se a versão for antiga. Se isso acontecer, verifique o help, a ajuda do 
programa, ou seu manual (por exemplo, http://dev.mysql.com/doc/index.
html), para obter um auxílio inicial. De qualquer forma, é improvável que 
os comandos mudem, somente a forma de obtê-los, eventualmente, 
deverá mudar.
2.1 CRIAR CONEXÃO NO 
MYSQL WORKSHOP
Para que possamos enviar as declarações de comandos ao SGBD, de-
verá haver uma conexão de rede. Ela deverá ser criada para cada SGBD 
desejado e, uma vez criada, ficará disponível na tela inicial do programa. 
Para efetuá-lo, basta clicar em MySQL Connections, fornecer um nome 
e confirmar. Acompanhe pela imagem (Figura B.2).
Figura B.2 - Criação de conexão com o MySQL dentro do workshop
Fonte: Produção do próprio autor28
Após nomear a conexão, forneça a senha (1) e crie a conexão de tra-
balho confirmando (2); ela ficará disponível na tela inicial (3) do programa 
(os números correspondem à sequência marcada na Figura B.3).
28 Cópia de tela durante a execução do terminal no equipamento do autor.
http://dev.mysql.com/doc/index.html
http://dev.mysql.com/doc/index.html
155Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Figura B.3 - Fornecer senha e confirmar conexão com o MySQL
Fonte: Produção do próprio autor29
2.2 TRABALHAR NO 
MYSQL WORKBENCH
Para trabalhar com o programa, após logados, teremos uma tela com 
várias opções, úteis à edição de comandos e gerenciamento do SGBD e 
seus bancos de dados.
Uma visão geral pode ser vista na imagem (Figura B.4). Somente os 
principais pontos de interesse serão explorados neste apêndice; consulte 
o manual do produto para mais informações (disponível em: http://
downloads.mysql.com/docs/workbench-en.a4.pdf).
Figura B.4 - Visão da tela do MySQL Worbench após logado
Fonte: Produção do próprio autor29
29 Montagem do autor a partir de cópias de telas do programa.
http://downloads.mysql.com/docs/workbench-en.a4.pdf
http://downloads.mysql.com/docs/workbench-en.a4.pdf
156 Planejamento e Elaboração de Bases de Dados
As três áreas de interesse inicial visíveis na Figura B.4 são as áreas 
nas quais serão executados os comandos (1), a de mensagens do sis-
tema (2) e aquela na qual serão apresentadas as listas de respostas aos 
comandos (3).
Além das três áreas comentadas, localiza-se ao lado delas uma tela 
com auxílio sensível ao contexto (Figura B.5), útil para lembrar a sintaxe 
dos comandos e muito adequada a iniciantes (toda a sintaxe é exibida 
em inglês).
Figura B.5 - Auxílio sensível ao contexto
Fonte: Produção do próprio autor30
Para executar um comando, ele pode ser digitado (ou colado, ou ob-
tido de um arquivo previamente salvo) na área 1 da Figura B.4. Também 
poderá vir de um arquivo.
No momento da execução, o comando deverá estar SELECIONADO. 
Se não houver um comando selecionado, TODOS os comandos de todas 
as linhas presentes na área de comandos serão executados.
Para auxiliar a execução das atividades, temos duas barras de ferra-
mentas contendo vários ícones (1 e 2 na Figura B.6). Vamos ver suas 
funções.
Figura B.6 - Barras de ferramentas do MySQL Worbench e seus ícones
Fonte: Produção do próprio autor31
30 Montagem do autor a partir de cópias de telas do programa.
31 Montagem do autor a partir de cópias de telas do programa.
157Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
A primeira barra (barra 1 na Figura B.6) fornece acesso a assistentes e 
controle; novas abas de edição e suas funções podem ser vistas de forma 
comentada a seguir .
Quadro B.1 - Funções dos ícones da barra de ferramentas de assistentes
Ícone Utilidade
Cria uma nova aba para a execução de consultas na área de comandos.
Abre um arquivo com scripts previamente salvos em outra aba para edição/uso.
Abre a janela de inspeção de objetos em uma nova aba. Permite verificar várias caracterís-
ticas dos objetos, por exemplo, uma tabela.
Abre uma aba para a criação de um novo banco de dados (SCHEMA). É o mesmo que exe-
cutar o comando CREATE SCHEMA ou CREATE DATABASE.
Abre o assistente para a criação de tabelas e permite criar uma nova tabela no banco de 
dados atual do servidor a que estiver conectado. É o mesmo que CREATE TABLE.
Abre o editor para a criação de visões e permite criar uma nova visão no banco de dados 
atual do servidor a que estiver conectado. É o mesmo que CREATE VIEW.
Abre o editor para com modelo para criação de procedimento armazenado e permite criar 
uma STORED PROCEDURE no banco.
158 Planejamento e Elaboração de Bases de Dados
Abreo editor para com modelo para criação de função e permite criar uma FUNCTION 
no banco.
Dá acesso ao mecanismo de pesquisa: 
Efetua a reconexão ao banco de dados, utilizando o mesmo usuário e senha.
Fonte: Produção do próprio autor33
Vamos ver agora, no Quadro B.2, a barra de ferramentas do editor de 
comandos, localizada acima da área de comandos (barra 2 na Figura B.6), 
que será a mais utilizada para a realização dos exercícios descritos nesta 
disciplina.
O termo usual que aparecerá a seguir como referência a uma sequên-
cia de comandos é script e será mantido devido à sua popularidade. Seu 
significado é um conjunto de instruções que deve ser executado para a 
realização de uma tarefa por um aplicativo.
Poderia ser traduzido como roteiro, mas isso não é usual e pode con-
fundi-lo quando estiver lendo material técnico ou interagindo com pes-
soal técnico da área, motivo pelo qual foi mantido o termo em inglês.
Quadro B.2 - Funções dos ícones da barra de ferramentas do editor de comandos
Ícone Utilidade
Abre um arquivo previamente salvo que contém comandos SQL. Eles são chamados 
de scripts.
Salva em um arquivo o script atual da área de comandos.
Permite a execução dos comandos de script digitados na área de comandos. Confor-
me já alertado, executa todos, caso não esteja selecionada somente uma parte dos 
comandos.
Executa somente o comando da linha atual.
32 Montagem do autor a partir de cópias de telas do programa.
159Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Termina (aborta) a execução da consulta atual. Utilizado quando uma consulta for 
muito demorada ou não houver resposta para novos comandos.
Determina se a execução dos próximos comandos SQL continuará ou não após falha 
em alguma declaração.
Grava definitivamente a transação atual. Só funciona se o autocommit estiver desli-
gado (veja o ícone , a seguir).
Desfaz a gravação da transação atual. Só funciona se o autocommit estiver desligado 
(veja o ícone , a seguir).
Estabelece se será ou não realizado o autocommit das transações.
Em bancos de dados, COMMIT significa finalizar uma transação, aceitando como 
corretos seus resultados e salvando todos em disco (uma sequência de atualizações 
ou inserções, por exemplo). Se a transação falha, pode ser realizado um ROLLBACK, 
que desfaz os comandos já executados. Porém, isso somente funciona dentro de 
transações, as quais terão a forma BEGIN TRANSACTION ... END TRANSACTION. As 
declarações a executar (STATMENTS) estarão incluídas entre o início e o final, assim 
como a decisão de executar o commit ou o rollback.
Para efeitos dos conteúdos desta disciplina, deixe ligado o autocommit (ícone na 
forma pressionada, ).
Limita o número de linhas retornadas em uma consulta. Serve para evitar que uma 
tabela com muitas linhas (por exemplo milhares, milhões) congestione a rede e o 
buffer do cliente.
Salva a declaração ou seleção atual para uma lista de transações mais usadas, permi-
tindo dar-lhe um nome.
Essa declaração ficará disponível na subdivisão SQL Additions, que fica ao lado da 
área de comandos, na aba Snippets:
Melhora a formatação do script da área de comandos para melhorar sua compreen-
são. Exemplo:
Exibe o painel de buscas:
160 Planejamento e Elaboração de Bases de Dados
Apresenta ou esconde os caracteres invisíveis, de formatação. É semelhante ao dos 
editores de texto.
Quebra linhas de comando longas em linhas que caibam na área de visualização dos 
comandos. Não é aconselhada para arquivos muito extensos.
Fonte: Produção do próprio autor34
O mínimo a utilizar do gerenciamento do servidor está no quadro de 
navegação, que pode ser visto na imagem (Figura B.7). Para efeitos desta 
disciplina são de interesse verificar se o servidor MySQL está ativo, iniciar 
ou para o serviço do servidor MySQL, e navegar pelos esquemas (ou ban-
cos de dados).
Figura B.7 - Principais comandos presentes no quadro de navegação e gerenciamento
Fonte: Produção do próprio autor35
2.3 CRIAR DIAGRAMAS NO 
MYSQL WORKBENCH
O Workbench possui um poderoso editor de diagramas para mode-
lagem de bancos de dados, que podem posteriormente criar objetos no 
banco de dados gerenciado pelo MySQL ao qual estiver conectado.
33 Montagem do autor a partir de cópias de telas do programa.
34 Montagem do autor a partir de cópias de telas do programa.
161Curso de Bacharelado em Biblioteconomia na Modalidade a Distância
Figura B.8 - Edição de diagramas no Workbench
Fonte: Produção do próprio autor35
Você verá a tela de um novo diagrama em branco, na qual poderá 
editar seu diagrama (Figura B.9).
Figura B.9 - Aspecto da tela de edição de diagramas
Fonte: Produção do próprio autor36
Podemos então iniciar a criação das tabelas, o que é realizado clicando-
se no ícone de criação de tabelas e depois selecionando-a, para possibilitar 
os ajustes de seus metadados e atributos (Figura B.10).
Figura B.10 - Criação de tabelas
Fonte: Produção do próprio autor37
35 Montagem do autor a partir de cópias de telas do programa.
36 Montagem do autor a partir de cópias de telas do programa.
37 Montagem do autor a partir de cópias de telas do programa.
162 Planejamento e Elaboração de Bases de Dados
Uma facilidade extra proporcionada pela ferramenta é a de que você 
poderá inserir dados para testar a tabela (Figura B.11).
Figura B.11 - Tela de inserção de dados na tabela criada
Fonte: Produção do próprio autor38
Por fim, também será possível criar relacionamentos, conforme exibi-
do na imagem (Figura B.12).
Figura B.12 - Criação de relacionamentos entre as tabelas no editor de diagramas
Fonte: Produção do próprio autor39
Evidentemente há muito mais a explorar, porém, isso não está no es-
copo desta disciplina, que é introdutória. Sugerimos que você explore 
melhor a ferramenta, em especial as funções de conexão e geração de 
esquemas e de backup/restore.
38 Montagem do autor a partir de cópias de telas do programa.
39 Montagem do autor a partir de cópias de telas do programa.
Curso de Bacharelado em 
Biblioteconomia na Modalidade 
a Distância
José Simão de Paula Pinto
Planejamento e Elaboração 
de Bases de Dados
C
u
rso
 d
e B
ach
arelad
o
 em
 B
ib
lio
teco
n
o
m
ia
n
a M
o
d
alid
ad
e a D
istân
cia
Plan
ejam
en
to
 e Elab
o
ração
 
d
e B
ases d
e D
ad
o
s
José Sim
ão de Paula Pinto
Se
m
e
stre
8
Semestre
8
	Figura 1 - Esquema comparativo entre o funcionamento do sistema de arquivos 
e o sistema de gerenciamento de banco de dados
	Figura 2 - Os SGBDs permitem que façamos compras e investimentos on-line, por exemplo, de modo que as transações possam ocorrer simultaneamente e com confiabilidade entre o comprador e o vendedor ou investidor e bolsa de valores
	Figura 3 - Assim como apenas guardar as notas fiscais não vai ajudar uma pessoa a gerenciar suas finanças se ela não fizer uma análise delas, o mesmo acontece com os dados em um SGDB. Se não servirem de subsídios para o conhecimento, ficarão apenas armaze
	Figura 4 - Uma base de dados pode ser composta por vários bancos de dados. Por exemplo, a área de Educação pode conter dados de Filosofia e Psicologia. 
As bases de dados analógicas eram consultadas nas estantes das bibliotecas, 
atualmente elas são digit
	Figura 5 - A usabilidade e a performance de um SGBD interferem 
na sua percepção de uso de um determinado sistema
	Figura 6 - Níveis de abstração na arquitetura de bancos de dados ANSI-SPARC
	Figura 7 - Exemplo de tabela de banco de dados relacionais
	Figura 8 - Ao fazer uma compra via internet, você certamente estará interagindo com um banco de dados que estará gerenciando essa transação visando a assegurar a integridade lógica e física dos dados
	Figura 9 - Síntese dos conceitos apresentados
	Figura 10 - Representação da comunicação pela rede no ambiente cliente x servidor
	Figura 11 - O par login/identificador (user name) e senha (password), após o usuário fazer a digitação das informações nos respectivos campos e clicar no botão enviar (submit), estabelece a comunicaçãodo cliente identificado com o servidor do banco de da
	Figura 12 - Ciclo de vida de um sistema de informação para modelagem de negócios, de acordo com Martin e Filkelstein (1984)
	Figura 13 - Antes de planejar modelar um banco de dados, é preciso conhecer os seus futuros usuários. No caso de uma biblioteca de uma universidade, por exemplo, significa saber quem são as pessoas que a utilizam, para que fins e quais as suas necessidade
	Figura 14 - É importante observar a rotina do usuário, seu modo de buscar informações e os tipos de informações pesquisadas, pensando em suprir as suas necessidades atuais, mas também orientadas para o futuro, pois os modos e as necessidades também são pa
	Figura 15 - Exemplo de diagrama de casos de uso
	Figura 16 - A identificação dos usuários padrão e sua colaboração são fundamentais para a elaboração da modelagem do banco de dados
	Figura 17 - A participação do usuário é central no processo, desde a concepção, passando pelo desenho, pela implementação e pela validação de um banco de dados
	Figura 18 - Representação da sequência de projeto de bancos de dados
	Figura 19 - Criação de um modelo conceitual a partir dos requisitos do usuário
	Figura 20 - Representação gráfica genérica do Modelo Entidade x Relacionamento (MER)
	Figura 21 - Representação de uma entidade e seus tipos de atributos
	Figura 22 - Exemplo de representação MER no programa Ferret
	Figura 23 - Exemplo de generalização e especialização
	Figura 24 - Exemplo de modelagem com especialização
	Figura 25 - Modelagem de associações entre as entidades pessoa e livro
	Figura 26 - British Museum Library e Magee Public Library. Modelar significa entender as necessidades de cada instituição e modelar os dados de acordo com as necessidades dessa instituição e de seus usuários, que podem ser muito diferentes de uma organiza
	Figura 27 - Exemplos de autorrelacionamento entre as entidades
	Figura 28 - Exemplos de entidade
	Figura 29 - Exemplos de relacionamento
	Figura 30 - Exemplo de MER contendo relacionamento quaternário
	Figura 31 - Exemplo de possível solução para o estudo de caso 1
	Figura 32 - Exemplo de mapeamento entre os modelos ER e Relacional
	Figura 33 - Exemplo de MER com aspectos físicos
	Figura 34 - Exemplo de criação de BD
	Figura 35 - Exemplo do comando USE para indicar qual BD será usado para os próximos comandos
	Figura 36 - Exemplo do comando CREATE TABLE para criar as tabelas no BD em uso
	Figura 37 - Exemplo do comando SHOW TABLES para mostrar as tabelas no BD em uso
	Figura 38 - Exemplo do comando DESC para mostrar a estrututra de uma tabela no BD em uso
	Figura 39 - Exemplo do comando DESC para mostrar a estrututra de uma tabela no BD em uso
	Figura 40 - Exemplo do comando INSERT INTO para mostrar a inserção de dados em uma tabela no BD em uso, no caso, a Tabela Autores
	Figura 41 - Exemplo do comando INSERT INTO usado para tentar inserir novamente dados já cadastrados na tabela autores no BD em uso
	Figura 42 - Exemplo do comando INSERT INTO usado para inserir dados na tabela Usuarios no BD em uso
	Figura 43 - Exemplo do comando INSERT INTO usado para inserir dados na tabela Livros no BD em uso
	Figura 44 - Exemplo do comando INSERT INTO usado para inserir dados na tabela Livro-autores no BD em uso
	Figura 45 - Exemplo do comando INSERT INTO usado para inserir dados na tabela livro-autores no BD em uso
	Figura 46 - Exemplo do comando INSERT INTO usado para inserir dados na tabela livro-autores no BD em uso
	Figura 47 - Exemplo do comando INSERT INTO usado para inserir dados na tabela Empréstimos no BD em uso
	Figura 48 - Exemplo do comando UPDATE usado para inserir dados de devolução na tabela Empréstimos do BD em uso
	Figura 49 - Exemplo do comando SELECT usado para selecionar e exibir dados da tabela Livros do BD em uso
	Figura 50 - Exemplo de resultado de lista de dados da tabela Livros do BD em uso
	Figura 51 - Exemplo de resultado de lista de dados da tabela 
Livros do BD em uso, selecionando por ISBN
	Figura 52 - Exemplo de resultado de lista de dados da tabela 
Livros do BD em uso, selecionando por Título
	Figura 53 - Exemplo de resultado de lista de dados da tabela 
Livros do BD em uso, selecionando por Título, em ordem alfabética
	Figura 54 - Exemplo de resultado de lista de dados da tabela Livros 
do BD em uso, selecionando por Título, em ordem descendente
	Figura 55 - Exemplo de resultado de lista de dados da tabela 
Livros do BD em uso, selecionando por ISBN
	Figura 56 - Exemplo de resultado de lista de 
dados da tabela Livros do BD em uso, solicitando 
quantidade de livros cadastrados em uma dada tabela, 
no caso, a de Livros
	Figura 57 - Exemplo de resultado de lista de dados 
da tabela Livros do BD em uso, solicitando quantidade 
de livros cadastrados na dada tabela Livros, fornecendo 
o nome quantidade
	Figura 58 - Exemplo de resultado de lista de dados da tabela Livros do BD em uso, solicitando quantidade de livros cadastrados na dada tabela Livros, fornecendo o nome para título como Modelagem
	Figura 59 - Exemplo de resultado de lista de dados da tabela 
Livros do BD em uso, solicitando quantidade de livros cadastrados na 
dada tabela Livros, fornecendo o nome para título como Modelagem
	Figura 60 - Exemplo de resultado de lista de dados da tabela 
Livros do BD em uso, solicitando quantidade de livros cadastrados 
na dada tabela Livros, fornecendo o nome para título como Modelagem
	Figura 61 - Exemplo de resultado de lista de dados da tabela 
Livros do BD em uso, solicitando quantidade de livros cadastrados 
na dada tabela Livros, fornecendo o nome para título como Modelagem
	Figura 62 - Exemplo de resultado usando o comando WHERE
	Figura 63 - Exemplo de resultado sem usar o comando WHERE
	Figura 64 - Exemplo de resultado usando o 
comando Select para filtrar por CPF
	Figura 65 - Exemplo de resultado sem usar o comando 
WHERE buscando o nome dos usuários
	Figura 66 - Exemplo de resultado usando o comando 
SELECT DISTINCT e WHERE buscando o nome dos usuários 
com base no CPF aplicando NOT IN
	Figura 67 - Exemplo de resultado usando o comando SELECT DISTINCT e WHERE buscando o nome dos usuários com base no CPF aplicando NOT IN
	Figura 68 – Exemplo de resultado usando o comando DATE_FORMAT
	Figura 69 - Exemplo de resultado usando o comando DATEDIFF
	Figura 70 - Exemplo de resultado 
usando o comando CURDATE
	Figura 71 - Exemplo de resultado usando o comando 
CURDATE na tabela Empréstimos
	Figura 72 - Exemplo de resultado usando 
o comando Componentes
	Figura 73 - Exemplo de resultado 
usando o comando SELECT
	Figura 74 - Exemplo de resultado usando 
o comando ALTER TABLE
	Figura 75 - Exemplo de resultado usando o comando 
DELETE para dados menores que 100
	Figura 76 - Exemplo de resultado usando o 
comando DELETE para dados maiores que 99
	Figura 77 - Exemplo de resultado usando o comando 
INSERT INTO para verificar se os dados foram 
totalmente apagados do BD
	Figura A.1 - Tela inicial da ferramenta brMODELO
	Figura A.2 - Utilização da ferramenta brMODELO para criação de uma nova entidade pessoa
	Figura A.3 - Utilização da ferramenta brMODELO para 
criação de atributos na entidade pessoa
	Figura A.4 - Utilização da ferramenta brMODELO para ajuste 
do atributo composto endereço na entidade pessoa
	Figura A.5 - Utilização da ferramenta brMODELO para ajuste de características 
dos atributos conforme o dicionário de dados do modelo
	Figura A.6 - Criação do modelo lógico a partir do modelo conceitual
	Figura A.7 - Criação do modelo lógico a partir do modelo conceitual: outras opções
	Figura A.8 - Utilização da ferramenta brMODELO para gerar modelo lógico: cardinalidade ajustada
	Figura A.9 - Utilização da ferramenta brMODELO para gerar o esquema físico
	Figura B.1 - Execução de comandos no MySQL em interface texto por meio do terminal no sistema Ubuntu
	Figura B.2 - Criação de conexão com o MySQL dentro do workshop
	Figura B.3 - Fornecer senha e confirmar conexão com o MySQL
	Figura B.4 - Visão da tela do MySQL Worbench após logado
	Figura B.5 - Auxílio sensível ao contexto
	FiguraB.6 - Barras de ferramentas do MySQL Worbench e seus ícones
	Figura B.7 - Principais comandos presentes no quadro de navegação e gerenciamento
	Figura B.8 - Edição de diagramas no Workbench
	Figura B.9 - Aspecto da tela de edição de diagramas
	Figura B.10 - Criação de tabelas
	Figura B.11 - Tela de inserção de dados na tabela criada
	Figura B.12 - Criação de relacionamentos entre as tabelas no editor de diagramas
	Apresentação
	UNIDADE 1
	CONCEITOS RELATIVOS 
A BANCOS DE DADOS
	1.1 OBJETIVO GERAL
	1.2 OBJETIVOS ESPECÍFICOS
	1.3 Pré-requisitos
	1.4	A IMPORTÂNCIA DA ESTRUTURAÇÃO DAS BASES DE DADOS E A BIBLIOTECONOMIA
	1.4.1 Das aplicações de bancos de dados ao sistema gerenciador de bancos de dados
	1.4.2 Conceitos
	1.4.2.1 Dados, metadados, informação e conhecimento
	1.4.2.2 Bancos de dados e bases de dados
	1.4.2.3 Atividade
	1.4.2.4 Níveis de abstração em bancos de dados
	1.4.2.5 Tarefas do sistema gerenciador de bancos de dados
	1.4.2.6 Ambiente de rede e segurança
	1.4.3 Desenvolvimento de sistemas e bancos de dados
	1.4.3.1 Levantamento de dados e requisitos do sistema
	1.4.3.2 Participação do usuário
	1.4.3.3 Breves considerações a respeito da tecnologia
	1.4.4 Os níveis de abstração e a modelagem do banco de dados
	1.4.5 Atividade
	CONCLUSÃO
	RESUMO
	UNIDADE 2
	PLANEJAMENTO E DESENHO DE BANCOS DE DADOS POR MEIO DE MODELAGEM CONCEITUAL
	2.1 OBJETIVO GERAL
	2.2 OBJETIVOS ESPECÍFICOS
	2.3 Pré-requisitos
	2.4	A MODELAGEM COMO UM MODO DE VER A REALIDADE
	2.5	MODELO ENTIDADE RELACIONAMENTO – MER
	2.5.1 Entidades
	2.5.2 Atributos
	2.5.3 Relacionamentos
	2.5.4 Formas de modelagem MER – Relacionamentos
	2.6	DESENHO DE BANCOS DE DADOS BASEADO NO MODELO ENTIDADE RELACIONAMENTO (MER)
	2.6.1 Atividade
	2.6.2 Estudo de caso 1: modelagem de uma situação de compra e venda
	2.6.3 Atividade
	2.6.4 Estudo de caso 2: ampliando o modelo de compra e venda com a inclusão dos fornecedores
	2.6.5 Atividade
	2.6.6 Atividade
	CONCLUSÃO
	RESUMO
	UNIDADE 3
	MANIPULAÇÃO DE BANCOS DE DADOS
	3.1 OBJETIVO GERAL
	3.2 OBJETIVOS ESPECÍFICOS
	3.3 Pré-requisitos
	3.4 INTRODUÇÃO 
	3.5	INTRODUÇÃO À SQL
	3.6	PRÁTICA DE DECLARAÇÕES SQL
	3.6.1 Criar o banco de dados
	3.6.2 Criar as tabelas necessárias para implementar o modelo
	3.6.3 Criar constraints de integridade: chaves primárias e estrangeiras
	3.6.4 Inserir dados de teste
	3.6.4.1 Dados para a tabela Autores
	3.6.4.2 Dados para a tabela Usuarios
	3.6.4.3 Dados para a tabela Livros
	3.6.4.4 Dados para a tabela livro_autores
	3.6.4.5 Dados para a tabela emprestimos
	3.6.5 Atualizar dados
	3.6.6 Praticar recuperação de dados e pesquisas no banco de dados
	3.6.6.1 Ver informações dos livros cadastrados
	3.6.6.2 Ver informações dos livros cadastrados, ordenados pelo título do livro
	3.6.6.3 Ver informações dos livros cadastrados, ordenados pelo título do livro em ordem descendente
	3.6.6.4 Determinar quantos livros estão cadastrados
	3.6.6.5 Determinar quantos livros estão cadastrados, fornecendo o nome de Quantidade para a coluna que conterá a resposta
	3.6.6.6 Listar livros cujos títulos comecem com a palavra Modelagem
	3.6.6.7 Uso da cláusula WHERE para unir dados de tabelas diferentes
	3.6.6.7.1 Atividade
	3.6.6.8 Aninhamento de consultas
	3.6.6.9 Trabalhar formatação de datas no comando select
	3.6.7 Campos de numeração automática
	3.6.8 Apagar dados e destruir objetos
	3.6.8.1 Apagar dados da tabela Componentes
	3.6.8.2 Apagar um objeto do banco de dados
	3.6.8.3 Atividade
	CONCLUSÃO
	RESUMO
	Sugestão de Leitura
	REFERÊNCIAS
	APÊNDICE A
	 APRESENTAÇÃO DA FERRAMENTA BR MODELO PARA MODELAGEM ENTIDADE VERSUS RELACIONAMENTO
	APÊNDICE B
	APRESENTAÇÃO DA FERRAMENTA MySQL WORKSHOP PARA TRABALHO COM SQL E BANCOS DE DADOS RELACIONAIS MySQL
	2.1	CRIAR CONEXÃO NO MySQL WORKSHOP
	2.2	TRABALHAR NO MySQL WORKBENCH
	2.3	CRIAR DIAGRAMAS NO MySQL WORKBENCH