ESCM_Introdução a Banco_de_Dados_I

Prévia do material em texto

Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
 
 
 
 
 
Análise e Desenvolvimento 
de Sistemas 
 
Disciplina: 
Introdução à Banco de Dados 
 
 
 
 
Autoria: Prof. Alan F Sousa 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
INTRODUÇÃO ............................................................................................................................................................. 3 
CONCEITOS SOBRE DADOS, INFORMAÇÕES E CONHECIMENTO .................................................................................. 4 
CONCEITO DE CAMPO .......................................................................................................................................................... 5 
REGISTROS ......................................................................................................................................................................... 7 
Exercício ..................................................................................................................................................................... 8 
SISTEMA DE ARQUIVO .......................................................................................................................................................... 8 
Sistemas de Arquivos (papel ou eletrônico) ............................................................................................................. 10 
Sistemas de Base de Dados ...................................................................................................................................... 11 
SISTEMAS DE ARQUIVOS X SISTEMAS DE BASE DE DADOS ....................................................................................................... 12 
DEFINIÇÃO DE UM SISTEMA DE GERÊNCIA PARA BASES DE DADOS ................................................................................................ 13 
Objetivos de SGBD .................................................................................................................................................... 13 
HISTÓRIA .................................................................................................................................................................. 17 
MODELO RELACIONAL ........................................................................................................................................................ 17 
CONCEITOS DE OBJETOS DO MODELO RELACIONAL .................................................................................................................. 18 
Tabelas (ou relações, ou entidades) ......................................................................................................................... 18 
Registros (ou tuplas) ................................................................................................................................................ 19 
Colunas (atributos, campo) ...................................................................................................................................... 20 
Relacionamentos ...................................................................................................................................................... 22 
AS 13 REGRAS DO MODELO RELACIONAL ................................................................................................................................ 24 
ARQUITETURAS DE BANCO DADOS ........................................................................................................................... 26 
INTRODUÇÃO .................................................................................................................................................................... 26 
HISTÓRICO ....................................................................................................................................................................... 27 
DEFINIÇÕES DAS ARQUITETURAS DE BD ................................................................................................................................. 30 
MODELAGEM ........................................................................................................................................................... 32 
FUNDAMENTOS DE MODELAGEM DE DADOS .............................................................................................................. 32 
UTILIZAÇÃO DE RELACIONAMENTOS 1:1 E 1:N ............................................................................................................. 53 
UTILIZAÇÃO DE RELACIONAMENTOS N:N ..................................................................................................................... 65 
UTILIZAÇÃO DE AUTO-RELACIONAMENTOS E RELACIONAMENTOS TERNÁRIOS .................................................... 75 
UTILIZAÇÃO DE AGREGAÇÕES E ESTRUTURAS DE GENERALIZAÇÃO/ESPECIALIZAÇÃO ................................................ 83 
ACCESS ..................................................................................................................................................................... 92 
CRIANDO UM BANCO DE DADOS ........................................................................................................................................... 92 
CRIANDO TABELAS ............................................................................................................................................................. 93 
CRIANDO RELACIONAMENTOS .............................................................................................................................................. 95 
CRIANDO CONSULTAS ........................................................................................................................................................ 98 
REFERÊNCIAS BIBLIOGRÁFICAS ........................................................................................................................................... 100 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
 Aula 1 
Introdução 
 
No início da década de 60, foram lançados os primeiros sistemas gerenciadores de banco de 
dados (SGBD), tendo como principal proposta o aumento na produtividade nas atividades de 
desenvolvimento e manutenção de sistemas, até então realizadas de forma artesanal em 
linguagens de programação convencionais de primeira e segunda geração. 
 
Oriundos do ambiente de mainframes, os SGBD tornaram-se mais populares e amigáveis com o 
advento da microinformática. 
 
Cada vez mais as fronteiras entre esses dois mundos estreitam-se e a concorrência pelo domínio 
do mercado de SGBD, tem levado seus diversos fabricantes a sofisticarem seus produtos. Cada 
nova versão lançada, incorpora novidades como interfaces gráficas, ferramentas de apoio ao 
desenvolvimento, utilitários para gerenciamento de BD e facilidades para extração de dados. 
 
Essa evolução vem tornando o trabalho de programadores, analistas e usuários menos artesanal, 
com reflexos na qualidade e produtividade. 
 
A literatura classifica os SGBD como HIERÁRQUICO e RELACIONAL. Essa classificação 
representa a evolução desses produtos no curso da história. Atualmente, o mercado é dominado 
pelos SGBD RELACIONAISe caminha para a colocação em escala comercial dos SGBD 
ORIENTADOS A OBJETOS. 
 
Este texto introduz a teoria de BANCO DE DADOS, a partir de conceitos básicos da teoria de 
arquivos que se perpetuaram na terminologia de banco de dados. 
 
Na sequencia aborda superficialmente a arquitetura e o normalização de dados, os bancos de 
dados relacionais neste texto e em outras biografias pode ser designado pela sigla SGBD-R. 
 
Para compreender com maior facilidade os conceitos relativos a BANCO DE DADOS é de suma 
importância revisarmos alguns conceitos básicos referentes à teoria e terminologia de arquivos 
convencionais, haja vista, que os primeiros SGBD foram criados a partir do aperfeiçoamento de 
sistemas gerenciadores de arquivo, e ainda utilizam muito da base conceitual e da terminologia de 
arquivos. 
 
 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
 
Conceitos sobre Dados, Informações e Conhecimento 
 
Dados: é qualquer elemento identificado em sua forma bruta que, por si só, não conduz a uma 
compreensão de determinado fato ou situação. 
 
Dados são quantificáveis e os únicos passíveis de uma real definição : 
• Símbolos 
• Marcas 
• Números 
 
Os dados emergem da percepção inicial do observador sobre a natureza do objeto: são 
identificados por características visuais ou simbólicas, mensuráveis. 
 
 
 
 
 
 
Informação: Deve ser considerado o dado trabalhado que permite levar o usuário a compreensão 
do seu significado, sendo subsídio útil à tomada de decisão. 
 
 
Conhecimento: Considera-se o conjunto de ferramentas conceituais e categorias usadas pelos 
seres humanos para criar, colecionar, armazenar e compartilhar a informação. 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
 
Dado 
 
Informação 
 
Conhecimento 
 
Fácil estruturação 
Fácil captura em máquinas 
Frequentemente 
quantificado 
Fácil transferência 
 
Requer unidade de análise 
Exige consenso em relação 
ao significado 
Exige necessariamente a 
mediação humana 
 
Difícil estruturação 
Difícil captura em 
máquinas 
Frequentemente tácito. 
Difícil transferência. 
 
 
Exemplo: 
 
dado 1: 40° C. (temperatura corporal do paciente) 
dado 2: 37° C. (temperatura normal do ser humano) 
 
informação: o paciente é o 3° acima do normal 
 
conhecimento 1: temperatura acima de normal (febre) é indesejável. 
conhecimento 2: administração de medicamento antipirético baixa febre. 
 
Exercício de abstração: 
Desenvolver um conjunto de 6 fichas para o controle do atendimento de uma clínica 
dentária. As fichas deverão conter dados diferentes e contemplar todos os tipos de 
controle que encontramos em uma clínica deste tipo, como por exemplo : paciente, 
horário, dentistas , etc... 
Conceito de Campo 
 
É a unidade básica formadora de um registro. Constitui a célula da informação. É a menor porção 
de um arquivo que pode ser referenciada por um programa. 
 
Cada campo deve possuir NOME, TIPO e TAMANHO. 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
Os tipos de campo mais comuns são: 
 NÚMERO - Armazena somente números e pode conter casas decimais, pode ser 
utilizado em operações matemáticas. 
 
 TEXTO ou ALFANUMÉRICO - Pode armazenar letras, números e caracteres especiais. 
 
 DATA - Armazena datas em formatos definidos. 
 
A figura a seguir sintetiza alguns exemplos com relação a definição da utilização de um CAMPO: 
 Campo Tipo/Tamanho Dado 
• Data_nascimento DATA 28/08/2012 
• Nome TEXTO(30) Marlon da Silva 
• Idade NUMERO(2) 38 
• Endereco TEXTO (60) Rua Carmen Lucia Avenida Brasil 
 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
 
Registros 
 
Registros podem ser chamados de estruturas, onde é possível agregar informações de tipos 
diferentes, criando-se um novo tipo de dado. Um registro é, portanto, uma coleção de campos, em 
que cada campo pode ser de um tipo de dado diferente. 
 
Definição Formal: O conceito de registro visa facilitar o agrupamento de variáveis que não são do 
mesmo tipo, mas que guardam estreita relação lógica. O registro é um caso mais geral de variável 
composta na qual os elementos do conjunto não precisam ser, necessariamente, homogêneos ou 
do mesmo tipo (FARRER ET AL, 2008). 
 
Por exemplo, os seguintes dados de um funcionário - código, nome, salário e sexo - são 
informações de tipos diferentes, mas possuem uma estreita relação lógica, que é a de compor as 
características de um funcionário. 
 
 
 TEXTO NÚMERO TEXTO 
 50 8 1 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
 
Exemplo : 
Nome : Jose Maria 
Salário : 10.000,00 
Sexo : M 
 
Nome 
 
Salário 
 
Sexo 
 
Jose Maria 
 
10.000,00 
 
M 
 
Exercício 
Desenvolver a partir do conjunto de 6 fichas do controle de atendimento de uma clínica dentária 
os respectivos campos que iram formar os registros que iram compor um arquivo de dados. 
 
Sistema de Arquivo 
 
Um arquivo é uma coleção de REGISTROS do mesmo tipo, ou seja, referentes a um mesmo 
assunto e com o mesmo formato padrão (layout). Constitui o componente de um sistema no qual 
são armazenados os dados, que combinados através de programa serve de base para a geração 
da informação desejada para um usuário, através de relatórios e consultas on- line. 
 
Um sistema de controle de notas, por exemplo, pode armazenar seus dados em diversos arquivos, 
cada um contendo informações sobre um determinado item do sistema: ALUNO, PROFESSOR, 
MATÉRIA, NOTA, etc. 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
 
Essas informações podem ser combinadas através de programas para gerar, por exemplo, o 
BOLETIM ESCOLAR, a PAUTA 
ou uma tela de CONSULTA DE NOTAS. 
 
 
 
AAA M 34 28/07/2012 
BBBB F 34 28/07/2012 
 CC M 74 28/07/2012 
DDDD M 23 28/07/2012 
 
 
Tradicionalmente, dados eram guardados em arquivos. As informações eram definidas pelas 
estruturas dos arquivos nos quais os dados eram armazenados. Era difícil recombinar estes dados 
para produzir informações diferentes. Mais difícil ainda, por falta de ligações lógicas entre as 
informações. 
 
Os problemas associados comdados armazenados em sistemas de arquivos (escritos em arquivos 
eletrônicos OU em arquivos de papel) incluem: 
 
1. Redundância dos Dados 
• múltiplos arquivos precisam ser atualizados quando dados mudam 
• atualizações precisam ser feitas em uma ordem prescrita 
• atualizações necessitam muito tempo e são caras 
• dados sem conformidade (os mesmos dados têm valores diferentes em arquivos 
diferentes) 
N.. registros -> Arquivo 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
 
2. Dependência dos Dados 
• as maneiras de acesso para os dados não podem ser mudadas sem mudar os 
programas (os formulários no caso de arquivos de papel) 
• os programas não podem ser mudados sem mudar a estrutura dos dados 
• a manutenção de programas (formulários) é cara e consome muito tempo 
 
3. Inflexibilidade dos Dados 
• ligando arquivos por dados semelhantes é muito difícil 
• é muito difícil produzir relatórios imprevistos (relatórios ad hoc) 
 
 
Sistemas de Arquivos (papel ou eletrônico) 
 
 
 
 
 
 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
 
 
 Aula 2 
Sistemas de Base de Dados 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Uma base de dados é uma coleção de dados organizados de uma maneira que todas as 
necessidades de dados dos usuários são satisfeitas. Em geral, só há uma cópia de cada item, mas 
podemos encontrar alguns BD com redundância controlada. 
 
Uma base de dados é uma representação ou modelo de coisas, descrições e conexões que 
definem o negócio e o meio ambiente no qual o negócio funciona. É o material cru que apoia a 
produção de informação. 
Então, a base de dados torna-se um recurso que pertence ao negócio inteiro em vez de pertencer 
a uma área específica dentro do negócio. 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
 
Uma base de dados pode ser definida como uma coleção dados interligados armazenados juntos, 
sem redundância prejudicial ou não necessária, para servir uma ou mais aplicações da melhor 
maneira; Nos BD os dados estão armazenados para ser independente dos programas que usam 
os dados; possuem gerenciamento de acessos comuns que são usados para controlar a adição 
de novos dados e para modificar e buscar dados já existentes na base de dados. 
 
 
 
Sistemas de Arquivos x Sistemas de Base de Dados 
 
 
 
Sistemas de Arquivos (papel ou 
eletrônico) 
 Sistemas de Base de Dados 
 redundância não 
controlada 
 dados sem conformidade 
 inflexibilidade 
 compartilhamento 
limitado dos dados 
 má manutenção de 
padrões, incluindo 
padrões de nomeação 
 sinônimos (mesmos 
dados, nomes diferentes) 
 homônimos (mesmos 
nomes, dados diferentes) 
 baixa produtividade dos 
programadores 
 alta manutenção dos 
programas 
 
 redundância dos dados 
minimizada e controlada 
 dados conformam-se (não há 
sinônimos ou homônimos) 
 dados integrados (registros inter-
ligados) 
 compartilhamento dos dados 
entre programas 
 padrões estão mantidos 
 programação mais fácil 
 independência entre a estrutura 
dos dados e os programas de 
busca de dados 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
 
Definição de um Sistema de Gerência para Bases de Dados 
 
Um sistema de gerência para bases de dados (SGBD) é um conjunto de programas que ajuda e 
controla o acesso e uso à bases de dados, para adicionar, modificar e buscar dados, por cada 
usuário e inclui funções que mantem a independência, integridade e segurança dos dados. 
 
Um SGBD integra arquivos de registros de dados em uma base de dados e prove visões diferentes 
para usuários diferentes. Então, tudo o software, hardware, firmware e procedimentos que se 
usam para gerenciar uma base de dados fazem parte do SGDB 
 
 
 
 
 
Objetivos de SGBD 
 
INDEPENDÊNCIA DE DADOS 
 
Os SGBD devem ser dotados de recursos que possibilitem a descrição das estruturas de dados 
(layout de arquivos e/ou tabelas) de forma independente dos procedimentos de manipulação 
(leitura e gravação) de dados no BD. 
Esse objetivo visa tornar transparente para os programas que acessam o BD as alterações que, 
por ventura, venham a ocorrer nas estruturas de dados, como por exemplo o acréscimo de um 
novo campo de informação ao banco. 
Da mesma forma, alterações em lógicas de programas que acessam o BD não devem afetar as 
estruturas de dados. 
Quanto maior o grau de independência de dados, menor será o tempo em que o BD ficará fora de 
operação para atividades de manutenção. 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
 
 
COMPARTILHAMENTO DE DADOS 
 
Consiste na reutilização dos dados do BD pelo maior número possível de aplicações dentro da 
empresa. Nesse sentido, os dados do BD devem ser muito bem planejados e estruturados. 
Portanto, este objetivo de banco de dados está mais ligado à atividade de análise e projeto de BD. 
O compartilhamento de dados visa diminuir a redundância de dados, considerando-o como um 
recurso da empresa e não propriedade de setores isolados da organização. 
Para implementar o compartilhamento de dados é necessário que a empresa disponha de recursos 
de rede, que permitam colocar o BD ao alcance dos diversos usuários. 
 
Além disso, é necessário que o SGBD possua um competente sistema de segurança, para que se 
estabeleça a privacidade de dados, através de mecanismos de restrição de acesso. 
 
MENOR REDUNDÂNCIA DE DADOS 
 
Redundância de dados consiste na repetição de um mesmo dado em diversos arquivos (tabelas) 
de um sistema, banco de dados, ambiente computacional ou empresa. 
Como exemplo, pode-se tomar a ocorrência do dado “NOME DO FUNCIONÁRIO”, em bases de 
dados não compartilhadas dos sistemas de CADASTRO, FOLHA DE PAGAMENTO e 
TREINAMENTO de uma empresa. 
 
A redundância é danosa para o ambiente computacional, pois aumenta os custos com o 
armazenamento de dados, e demandas da área de informática. 
 
Além disso, a redundância gera inconsistência de dados, ou seja, o dado redundante extraído a 
partir de arquivos diferentes apresenta valores divergentes. Tal fato, pode afetar a credibilidade de 
um sistema. 
 
PRIVACIDADE DE DADOS 
 
O COMPARTILHAMENTO DE DADOS leva um grande número de usuários, com funções 
diversificadas na empresa, a acessar um mesmo banco de dados. 
Nesse contexto, o objetivo de privacidade de dados ressalta a preocupação que o 
projetista de BD deve ter em vedar o acesso de usuários não autorizados a informações sigilosas 
ou de acesso restrito 
 
Nesse sentido, o sistema de segurança dos SGBD, devem possuir meios para que o projetista 
possa definir perfis diferenciados de acesso ao BD, com a criação de grupos de usuários e 
atribuição de direitos de acesso aesses grupos, a partir da utilização de senhas. 
 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
SEGURANÇA DE DADOS 
 
A segurança das informações armazenadas no BD pode ser encarada sob dois prismas: 
SEGURANÇA LÓGICA e SEGURANÇA FÍSICA. 
 
A SEGURANÇA LÓGICA é alcançada com a utilização dos mecanismos de restrição de acesso 
disponíveis nos SGBD para implementação do objetivo de privacidade de dados, tais como senhas 
e sistemas de LOG e AUDIT que registram dados sobre as operações que são efetuadas no BD 
(data, hora, usuário, comando, etc.). 
 
A SEGURANÇA FÍSICA dos dados é obtida a partir de utilitários e aplicativos que os fabricantes 
colocam em seus produtos, visando facilitar o trabalho de proteção aos dados contra danos físicos, 
que podem ser causados por falhas de hardware ou queda da rede. 
 
Nessa linha destacam-se as ROTINAS DE BACKUP, GRAVAÇÃO COM ESPELHAMENTO e 
SISTEMAS DE MONITORAÇÃO DE TRANSAÇÕES DISTRIBUÍDAS (TWO-PHASE-COMMIT) e 
outras. 
TRATAMENTO DE CONCORRÊNCIA 
 
Este objetivo de BD aborda o aspecto do acesso simultâneo de dois usuários a um mesmo 
conjunto de informações. O SGBD deve possuir mecanismos para a identificação e tratamento 
desses acessos concorrentes, para garantir a consistência das informações do BD no sentido de 
sua veracidade. 
 
Os sistemas de bloqueio (LOCK) e desbloqueio (UNLOCK) são os mecanismos utilizados para 
evitar que uma informação que está sendo manipulada por um usuário (“USU1”) seja alterada por 
outro (“usu2”). 
Enquanto o “USU1” dela se utiliza o ‘USU2”, não terá acesso a mesma ou o terá apenas para 
leitura e receberá um aviso do SGBD de que a informação está sendo acessada por outro usuário 
e pode ser modificada. 
 
Existem vários níveis de LOCK. 
As opções variam conforme o produto (SGBD) analisado, sendo que os mais comuns 
ocorrem a nível de tabela, página (conjunto de registros) e linha (nível mais baixo). 
 
Cabe lembrar que o nível de bloqueio influi na performance do SGBD em ambientes de missão 
crítica (altos índices de acesso concorrente), sendo que quanto menor o nível de LOCK, a 
performance tende a ser melhor. Ressalta-se que além desse, existem outros fatores que 
influenciam na performance do SGBD. 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
INTEGRIDADE DE DADOS 
A integridade de dados refere-se a mecanismos que estão disponíveis nos SGBD, que garantem a 
consistência dos dados armazenados no SGBD, segundo parâmetros de validação, especificados 
no momento de criação do BD, em conjunto com 
as estruturas de dados. 
 
Esse objetivo só se tornou disponível, como recurso do SGBD, com o advento dos modelos 
Relacionais e consta como pré-requisito para enquadramento de produtos nessa categoria de 
SGBD. 
 
Mais adiante nesta apostila veremos um tópico dedicado aos SGBD relacionais trataremos esse 
assunto com maior riqueza de detalhes. 
 
As linguagens de banco de dados consistem na interface do usuário para interagir com o SGBD. 
Neste texto destacamos cinco modalidades de linguagens que são mais comumente utilizadas 
nessa interação: 
 SQL, 
 Autocontida (TRIGGERS, STORED PROCEDURES, FUNCÕES).), 
 Hospedeira (Fortran, COBOL -possuem um software PRÉ-COMPILADOR,), 
 Visuais (DELPHI, VISUAL BASIC, POWER BUILDER, CENTURA) 
 e aquelas voltadas para INTERNET (HTML, JAVA SCRIPT, ASP e JAVA). 
 
Esta é uma classificação meramente didática que objetiva apenas demostrar 
formas diferenciadas de interação com o BD. Outros autores possuem diferentes classificações. 
 
Resumo das características desejáveis em um SGDB 
 permite compartilhamento dos dados 
 provê independência entre dados e programas 
 permite transparência entre dados e programas 
 provê segurança para os dados 
 provê integridade dos dados 
 provê controle de conformidade dos dados 
 permite validação dos dados 
 provê controle da estrutura física e lógica 
 permite e provê uma língua para a definição de dados 
 provê uma língua para manipulação dos dados (SQL) 
 provê vistos para usuários 
 provê procedimentos básicos 
 permite e provê funções para a auditoria do sistema 
 permite e provê funções para a recuperação do sistema 
 provê ferramentas para o desenvolvimento de formulários, relatórios 
 provê ferramentas para gerenciar a execução e segurança 
 provê ferramentas par manter a base de dados e seus programas 
 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES Aula 3 
História 
 
Os Bancos de dados relacionais (BDR) surgiram em meados da década de 1970. Porem, apenas 
alguns anos mais tarde as empresas passaram a utiliza-los no lugar de arquivos planos (do inglês 
flat file), bancos de dados hierárquicos e em rede. 
 
Modelo relacional 
 
O modelo relacional apareceu devido às seguintes necessidades: 
• aumentar a independência de dados nos sistemas gerenciadores de banco de dados; 
• prover um conjunto de funções apoiadas em álgebra relacional para armazenamento e 
recuperação de dados. 
 
O modelo tem por base a teoria dos conjuntos e álgebra relacional, foi resultado de um estudo 
teórico realizado por Edgar Frank Codd, criador do modelo relacional. 
 
O Modelo relacional revelou-se ser o mais flexível e adequado ao solucionar os vários problemas 
que se colocam no nível da concepção e implementação da base de dados. 
 
A estrutura fundamental do modelo relacional é a relação (tabela). 
 
Uma relação é constituída por um ou mais atributos (campos) que traduzem o tipo de dados a 
armazenar. Cada instância do esquema (linha ) é chamada de tupla (registro). 
 
O modelo relacional não tem caminhos pré-definidos para se fazer acesso aos dados como nos 
modelos que o precederam. 
 
O modelo implementa estruturas de dados organizadas em relações. Porém, para trabalhar com 
essas tabelas, algumas restrições precisaram ser impostas para evitar aspectos indesejáveis, 
como: Repetição de informação, incapacidade de representar parte da informação e perda de 
informação. 
Essas restrições são: integridade referencial, chaves e integridade de junções de relações. 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
A Figura abaixo, traz exemplos de tabelas sob o modelo relacional. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 1.3 Tabelas do modelo relacional Cliente - Conta Corrente 
 
 
Conceitos de objetos do Modelo Relacional 
Tabelas (ou relações, ou entidades) 
 
Todos os dados de um banco de dados relacional (BDR) são armazenados em tabelas. Uma 
tabela e uma simples estrutura de linhas e colunas. 
Em uma tabela, cada linha contém um conjunto de colunas. 
 
Em um banco de dados podem existir uma ou centenas de tabelas, sendo que o limite pode ser 
imposto tanto pela ferramenta de software utilizada, quanto pelos recursos de hardware disponíveis 
no equipamento ou pela própria regra de negócio a ser especificada. 
 
As tabelas associam-se entre si através de regras de relacionamentos, estas regras consistem em 
associar um ou vários atributo de uma tabela (colunas)com um ou vários atributos de outra tabela. 
 
 Exemplo: A tabela funcionário relaciona-se com a tabela cargo. Atraves deste relacionamento esta 
ultima tabela fornece a lista de cargos para a tabela funcionário. 
 
 
 
 
 
 
 
 
 
Funcionário Cargo 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
Modelo teórico usado para representar conceitualmente um BD, Idealizado por Codd (1970). 
 
Baseado numa estrutura de dados simples chamada relação. 
E o modelo mais amplamente usado, principalmente em aplicações convencionais de BD. 
 
Registros (ou tuplas) 
 
Cada linha formada por uma lista ordenada de colunas representa um registro, ou tupla. Os 
registros não precisam conter informações em todas as colunas, podendo assumir valores nulos 
quando assim se fizer necessário. 
 
Resumidamente, um registro e uma instância de uma tabela, ou entidade. 
O start da modelagem de dados se da a partir das ENTIDADES que é composta por tuplas. 
 
Uma entidade e uma representação de um conjunto de informações sobre 
determinado conceito do sistema. Toda entidade possui ATRIBUTOS, que são as informações que 
referenciam a entidade. 
 
 Para exemplificar no sistema de controle de Biblioteca, partimos do conceito 
principal que e o de empréstimo de obras por parte dos usuários da biblioteca. A partir deste 
conceito inicial, vamos ramificando e descobrindo novos conceitos. 
 
Podemos iniciar nosso raciocínio da seguinte forma: 
 
"Uma biblioteca possui Obras literárias que podem ser tomadas em empréstimos pelos usuários 
credenciados." 
 
Podemos rapidamente enxergar um cadastro de livros, um cadastro de usuários e um registro 
de empréstimos, certo? 
 
E essa visão que temos que ter ao modelarmos um banco, isto e, devemos detectar as 
informações que devemos armazenar. 
Para identificar se aquele conceito pode ser uma entidade você deve apenas se perguntar: 
 
"Eu desejo armazenar quais informações sobre este conceito ?" 
 
 Se houverem informações a serem armazenadas, você tem uma ENTIDADE. 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
 
Exemplificando: 
 
 Eu desejo armazenar os seguintes dados do livro: 
• Titulo, 
• Autor, 
• Editora, 
• Ano, 
• Edição e Volume. 
 
Temos então a entidade Livro. 
 
Exemplo: 
 
 O empregado Pedro e uma instancia (registro) da tabela funcionário, e a função 
 Analista Comercial e a instancia (registro) da tabela cargo. 
 
Uma associação entre estas duas tabelas criaria a seguinte instancia de relacionamento: 
 
Pedro é Analista Comercial, onde o verbo ser representa uma ligação entre os registros 
distintos. 
 
Colunas (atributos, campo) 
As colunas de uma tabela são também chamadas de atributos. Um conjunto de colunas dão 
origem a um registro 
 
 Ex.: O campo Nome, ou endereço de uma tabela de um BD relacional. 
 
Chave 
 
As tabelas relacionam-se umas as outras através de chaves. 
Uma chave e um conjunto de um ou mais atributos que determinam a unicidade de cada registro. 
Por exemplo, se um banco de dados tem como chaves Código do Produto e ID Sistema, sempre 
que acontecer uma inserção de dados, o sistema de gerenciamento de banco de dados irá fazer 
uma consulta para identificar se o registro já não se encontra gravado na tabela. 
Neste caso, um novo registro não será criado, resultando esta operação apenas da alteração do 
registro existente. 
 
A unicidade dos registros, determinada por sua chave, também e fundamental para a criação dos 
índices. 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
 
 
Temos dois tipos de chaves: 
 
• Chave primária: (PK - Primary Key) e a chave que identifica cada registro dando-lhe 
unicidade do dado. A chave primaria nunca se repetira. 
Ela identifica o registro de forma única. 
 
• Chave Estrangeira: (FK - Foreign Key) e uma chave formada através de um relacionamento 
com a chave primaria de outra tabela. 
Define um relacionamento entre as tabelas a associação entre suas chaves e pode ocorrer 
repetidas vezes. Caso a chave primária seja composta na origem, a chave estrangeira 
também o será no destino. 
 
 
 
 
 
 
 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES Aula 4 
Relacionamentos 
 
Com o advento do Modelo de Entidades e Relacionamentos foi causada uma confusão entre os 
termos relação e relacionamento 
O Modelo Relacional, quando descrito de forma matemática, e definido como um modelo formado 
por relações (no sentido matemático) entre os domínios. 
 
Cada tupla é um elemento do conjunto da relação. 
Ou seja, a relação é a tabela. 
 
Um relacionamento do Modelo de Entidades e Relacionamentos e uma associação entre entidades 
distintas. Não há relação direta entre o nome relacionamento e o nome relação. 
 
Porém, um relacionamento, do Modelo de Entidades e Relacionamentos é traduzido para a criação 
de atributos com chaves externas do Modelo Relacional. 
Esta tradução e feita ligando-se um campo de uma tabela X com um campo de uma tabela Y, por 
meio da inclusão do campo chave da tabela Y como um campo (conhecido como chave 
estrangeira) da tabela X. 
 
 
 
 
 
 
 
 
 
 
Por meio das chaves estrangeiras, e possível implementar restrições nos SGBDR. 
 
Tabela X Tabela Y 
Campo A 
Campo A ( FK) 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
 
Existem alguns tipos de relacionamentos possíveis no MER: 
 
 
• Um para um (1 para 1) - indica que as tabelas tem relação unívoca entre si. Você 
escolhe qual tabela vai receber a chave estrangeira; 
 
 
• Um para muitos (1 para N) - a chave primária da tabela que tem o lado 1(unicidade) 
esta para ir para a tabela do lado N. 
 No lado N ela é chamada de chave estrangeira; 
Dizemos que uma ocorrência se relaciona com N outras. 
Ex : Nota fiscal x Produtos 
 
• Muitos para muitos (N para M) - quando tabelas tem entre si relação N..M, é 
necessário criar uma nova tabela com as chaves primárias das tabelas envolvidas, 
ficando assim uma chave composta, ou seja, formada por diversos campos-chave de 
outras tabelas. 
A relação então se reduz para uma relação 1.N, sendo que o lado N ficará com a nova tabela 
criada. 
 
Os relacionamentos 1 para 1 e 1 para N podem ser mapeados diretamente em chaves estrangeiras 
nas tabelas originais. Já o relacionamento N para N exige o uso de uma tabela auxiliar. No 
relacionamento N:N não há chave estrangeira. 
 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
 Aula 5 
As 13 regras do modelo relacional 
 
Em 1985, Edgar Frank Codd, criador do modelo relacional, publicou um artigo onde definiu 13 
regras para que umSistema Gerenciador de Banco de Dados (SGBD) fosse considerado 
relacional: 
 
1. Regra Fundamental: 
Um SGBD relacional deve gerir os seus dados usando apenas suas capacidades relacionais. 
 
2. Regra da informação: 
Toda informação deve ser representada de uma única forma, como dados em uma tabela. 
 
3. Regra da garantia de acesso: 
Todo o dado (valor atômico) pode ser acedido logicamente (unicamente) usando o nome da 
tabela, o valor da chave primaria da linha e o nome da coluna. 
 
4. Tratamento sistemático de valores nulos: 
Os valores nulos (diferente do zero, da string vazia, da string de caracteres em brancos e 
outros valores não nulos) existem para representar dados não existentes de forma sistemática 
e independente do tipo de dado. 
 
5. Catalogo dinâmico on-line baseado no modelo relacional: 
A descrição do banco de dados e representada no nível logico como dados ordinários (isso e, 
em tabelas), permitindo que usuários autorizados apliquem as mesmas formas de manipular 
dados aplicada aos dados comuns ao consulta-las. 
 
6. Regra da sub-linguagem abrangente: 
Um sistema relacional pode suportar varias linguagens e formas de uso, porem deve possuir ao 
menos uma linguagem com sintaxe bem definida e expressa por cadeia de caracteres e com 
habilidade de apoiar a definição de dados, a definição de visões, a manipulação de dados, as 
restrições de integridade, a autorização e a fronteira de transações. 
 
7. Regra da atualização de visões: 
Toda visão que for teoricamente atualizável será também atualizável pelo sistema. 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
 
8. Inserção, atualização e eliminação de alto nível: 
• Qualquer conjunto de dados que pode ser manipulado com um único comando para 
retornar informações, também deve ser manipulado com um único comando para 
operações de inserção, atualização e exclusão. Simplificando, significa dizer que as 
operações de manipulação de dados devem poder ser aplicadas a varias linhas de uma 
vez, ao invés de apenas uma por vez. 
 
9. Independência dos dados físicos: 
• Programas de aplicação ou atividades de terminal permanecem logicamente inalteradas 
quaisquer que sejam as modificações na representação de armazenagem ou métodos de 
acesso internos. 
 
10. Independência logica de dados 
• Programas de aplicação ou atividades de terminal permanecem logicamente inalteradas 
quaisquer que sejam as mudanças de informação que permitam teoricamente a não 
alteração das tabelas base. 
 
11. Independência de integridade: 
• As relações de integridade especificas de um banco de dados relacional devem ser 
definidas em uma sub-linguagem de dados e armazenadas no catalogo (e não em 
programas). 
 
12. Independência de distribuição: 
• A linguagem de manipulação de dados deve possibilitar que as aplicações permaneçam 
inalteradas estejam os dados centralizados ou distribuídos fisicamente. 
 
13. Regra da Não-subversão: 
• Se o sistema relacional possui uma linguagem de baixo nível (um registro por vez), não 
deve ser possível subverter ou ignorar as regras de integridade e restrições definidas no 
alto nível (muitos registros por vez). 
 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
 Aula 6 
Arquiteturas de Banco Dados 
 Introdução 
 
Atualmente, devem-se considerar alguns aspectos relevantes para atingir a eficiência e a eficácia 
dos sistemas informatizados desenvolvidos, a fim de atender seus usuários nos mais variados 
domínios de aplicação: automação de escritórios, sistemas de apoio a decisões, controle de 
reserva de recursos, controle e planejamento de produção, alocação e estoque de recursos, entre 
outros. Tais aspectos são: 
 
a) Os projetos Lógico e Funcional do Banco de Dados devem ser capazes de prever o volume de 
informações armazenadas a curto, médio e longo prazo. Os projetos devem ter uma grande 
capacidade de adaptação para os três casos mencionados; 
 
b) Deve-se ter generalidade e alto grau de abstração de dados, possibilitando confiabilidade e 
eficiência no armazenamento dos dados e permitindo a utilização de diferentes tipos de 
gerenciadores de dados através de linguagens de consultas padronizadas; 
 
c) Projeto de uma interface ágil e com uma "rampa ascendente" para propiciar aprendizado 
suave ao usuário, no intuito de minimizar o esforço cognitvo; 
 
d) Implementação de um projeto de interface compatível com múltiplas plataformas (UNIX, 
Windows NT, Windows Workgroup, etc); 
 
e) Independência de Implementação da Interface em relação aos SGBDs que darão 
condições às operações de armazenamento de informações (ORACLE, SYSBASE, INFORMIX, 
PADRÃO XBASE, etc). 
 
f) Conversão e mapeamento da diferença semântica entre os paradigmas utilizados no 
desenvolvimento de interfaces (Imperativo (ou procedural), Orientado a Objeto, Orientado a 
evento), servidores de dados (Relacional) e programação dos aplicativos (Imperativo, Orientado a 
Objetos). 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
 
 
 Histórico 
 
 
As primeiras arquiteturas usavam mainframes para executar o processamento principal e de 
todas as funções do sistema, incluindo os programas aplicativos, programas de interface com o 
usuário, bem como a funcionalidade dos SGBDs. Esta é a razão pela qual a maioria dos usuários 
fazia acesso aos sistemas via terminais que não possuíam poder de processamento, apenas a 
capacidade de visualização. 
 
Todos os processamentos eram feitos remotamente, apenas as informações a serem 
visualizadas e os controles eram enviados do mainframe para os terminais de visualização, 
conectados a ele por redes de comunicação. 
 
Mainframe e seus terminais 
 
 
 
 
 
Como os preços do hardware foram decrescendo, muitos usuários trocaram seus terminais por 
computadores pessoais (PC) e estações de trabalho. 
 
 PC 
 
No começo os SGBDs usavam esses computadores da mesma maneira que usavam os 
terminais, ou seja, o SGBD era centralizado e toda sua funcionalidade, execução de programas 
aplicativos e processamento da interface do usuário eram 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
executados em apenas uma máquina. Gradualmente, os SGBDs começaram a explorar a 
disponibilidade do poder de processamento no lado do usuário, o que levou à arquitetura cliente-
servidor. 
 
A arquitetura cliente-servidor foi desenvolvida para dividir ambientes de computação onde um 
grande número de PCs, estações de trabalho, servidores de arquivos, impressoras, servidores de 
banco de dados e outros equipamentos são conectados juntos por uma rede. 
 
 A idéia é definir servidores especializados, tais como servidor de arquivos, que mantém os 
arquivos de máquinas clientes, ou servidores de impressão que podem estar conectados a várias 
impressoras; assim, quando se desejar imprimir algo, todas as requisições de impressão são 
enviadas a este servidor. As máquinas clientes disponibilizam para o usuário as interfaces 
apropriadas para utilizaresses servidores, bem como poder de processamento para executar 
aplicações locais. 
 
 
 
 
Esta arquitetura se tornou muito popular por algumas razões. 
 
• Primeiro, a facilidade de implementação dada a clara separação das 
funcionalidades e dos servidores. 
 
• Segundo, um servidor é inteligentemente utilizado porque as tarefas mais simples 
são delegadas às máquinas clientes mais baratas. 
 
 
• Terceiro, o usuário pode executar uma interface gráfica que lhe é familiar, ao invés 
de usar a interface do servidor. 
 
Desta maneira, a arquitetura cliente-servidor foi incorporada aos SGBDs comerciais. 
 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
Diferentes técnicas foram propostas para se implementar essa arquitetura, sendo que a 
mais adotada pelos Sistemas Gerenciadores de Banco de Dados Relacionais (SGBDRs) 
comerciais é a inclusão da funcionalidade de um SGBD centralizado no lado do servidor. 
 
As consultas e a funcionalidade transacional permanecem no servidor, sendo que este é 
chamado de servidor de consulta ou servidor de transação. 
 
É assim que um servidor SQL é fornecido aos clientes. Cada cliente tem que formular suas 
consultas SQL, prover a interface do usuário e as funções de interface usando uma linguagem de 
programação. O cliente pode também se referir a um dicionário de dados o qual inclui 
informações sobre a distribuição dos dados em vários servidores SQL, bem como os módulos 
para a decomposição de uma consulta global em um número de consultas locais que podem ser 
executadas em vários sítios. 
Comumente o servidor SQL também é chamado de back-end machine e o cliente de front-end 
machine. Como SQL provê uma linguagem padrão para o SGBDRs, esta criou o ponto de divisão 
lógica entre o cliente e o servidor. 
 
Atualmente, existem várias tendências para arquitetura de Banco de Dados, nas mais diversas 
direções. 
 
 
SQL – Structed query language (linguagem de consulta estruturada) 
 
Como evolução do modelo cliente/server surgiu a arquitetura de banco de dados distribuídos 
onde cada servidor é responsável pelo processamento de forma transparente da informação. 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
Definições das arquiteturas de BD 
 
Plataformas centralizadas. Na arquitetura centralizada, existe um computador 
com grande capacidade de processamento, o qual é o hospedeiro do SGBD e 
emuladores para os vários aplicativos. Esta arquitetura tem como principal vantagem a 
de permitir que muitos usuários manipulem grande volume de dados. Sua principal 
desvantagem está no seu alto custo, pois exige ambiente especial para mainframes e 
soluções centralizadas. 
 
Sistemas de Computador Pessoal - PC. Os computadores pessoais trabalham em 
sistema stand-alone, ou seja, fazem seus processamentos sozinhos. No começo esse 
processamento era bastante limitado, porém, com a evolução do hardware, tem-se hoje 
PCs com grande capacidade de processamento. Eles utilizam o padrão Xbase e quando 
se trata de SGBDs, funcionam como hospedeiros e terminais. Desta maneira, 
possuem um único aplicativo a ser executado na máquina. A principal vantagem desta 
arquitetura é a simplicidade. 
 
Banco de Dados Cliente-Servidor. Na arquitetura Cliente-Servidor, o cliente (front_end) 
executa as tarefas do aplicativo, ou seja, fornece a interface do usuário (tela, e 
processamento de entrada e saída). O servidor (back_end) executa as consultas no 
DBMS e retorna os resultados ao cliente. Apesar de ser uma arquitetura bastante 
popular, são necessárias soluções sofisticadas de software que possibilitem: o 
tratamento de transações, as confirmações de transações (commits), desfazer 
transações (rollbacks), linguagens de consultas (stored procedures) e gatilhos 
(triggers). A principal vantagem desta arquitetura é a divisão do processamento entre 
dois sistemas, o que reduz o tráfego de dados na rede. 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
 
 
Banco de Dados Distribuídos (N camadas). Nesta arquitetura, a informação está 
distribuída em diversos servidores. Como exemplo, observe a Figura a seguir. 
 
Cada servidor atua como no sistema cliente-servidor, porém as consultas oriundas dos 
aplicativos são feitas para qualquer servidor indistintamente. 
Caso a informação solicitada seja mantida por outro servidor ou servidores, o sistema 
encarrega-se de obter a informação necessária, de maneira transparente para o 
aplicativo, que passa a atuar consultando a rede, independente de conhecer seus 
servidores. 
 
Exemplos típicos são as bases de dados corporativas, em que o volume de informação 
é muito grande e, por isso, deve ser distribuído em diversos servidores. Porém, não é 
dependente de aspectos lógicos de carga de acesso aos dados, ou base de dados 
fracamente acopladas, em que uma informação solicitada vai sendo coletada numa 
propagação da consulta numa cadeia de servidores. 
 
A característica básica é a existência de diversos programas aplicativos consultando a 
rede para acessar os dados necessários, porém, sem o conhecimento explícito de quais 
servidores dispõem desses dados. 
 
 
 
Figura 1.5 - Arquitetura Distribuída N camadas 
 
 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES Aula 7 
Modelagem 
 
FUNDAMENTOS DE MODELAGEM DE DADOS 
 
 
O Modelo Entidade-Relacionamento é um modelo de alto nível, independente do SGBD 
(Sistemas Gerenciadores de Bancos de Dados), que representa o problema a ser 
modelado. 
 
 A notação que será utilizada para a representação deste modelo é o DER (Diagrama 
Entidade-Relacionamento), exemplificado na Figura 1, onde os retângulos representam as 
entidades (elementos do domínio do problema) e os losangos representam os 
relacionamentos entre estas entidades (HEUSER,2004). Entidades ainda são descritas 
através de atributos e devem possuir uma chave primária (ou Primary Key - atributo ou 
conjunto de atributos que identificam unicamente uma instância em uma entidade, e que não 
podem receber um valor nulo). 
 
A Figura 1 representa que uma instância da Entidade A está associada a zero (opcional) ou 
mais instâncias da Entidade B. Por outro lado, uma instância da Entidade B está 
associada a uma (obrigatoriedade), e somente uma, instância da Entidade A. A este par 
de elementos chama-se cardinalidade, onde o primeiro elemento indica a participação 
(opcional ou obrigatório) do relacionamento, enquanto o segundo representa o grau do 
relacionamento (um ou muitos). Naturalmente, existem outros elementos utilizados na 
construção deste diagrama, como agregação, relacionamento ternário (ou de maior grau), 
auto-relacionamento e generalização/especialização, que serão apresentados 
posteriormente. 
 
 
 
 
 
 
 
Figura 1. Notação do Diagrama Entidade-Relacionamento 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJTels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
 
ESCOLA SUPERIOR CANDIDO MENDES 
 
Relacionamentos ainda podem ter atributos, quando algum dado precisa ser associado à 
ligação das duas instâncias envolvidas. Relacionamentos são descritos através da 
cardinalidade, que indica como as instâncias das entidades se relacionam. 
 
Os tipos utilizados na modelagem são (KORTH, SILBERCHATZ e SUDARSHAN, 2006): 
 
• Um-para-um (1:1): uma instância em “A” está associada com no 
 máximo uma instância em “B”, e uma instância em “B” 
 está associada com no máximo uma instância em “A”; 
 
• Um-para-muitos (1:n): uma instância em “A” está associada a 
 qualquer número de instâncias em “B”, e uma 
 instância em “B”, todavia, pode estar associado a no 
 máximo uma instância em “A”; 
 
• Muitos-para-muitos (n:n): uma instância em “A” está associada a 
 qualquer número de instâncias em “B” e vice-versa. 
 Alguns autores preferem chamar esta cardinalidade de 
 m:n, por considerar que podem representar valores 
 diferentes. 
 
O modelo conceitual representa os elementos do domínio do problema e, 
consequentemente, não considera questões tecnológicas. 
Assim, alguns dos elementos descritos neste modelo não possuem correspondência com os 
recursos oferecidos pelos bancos de dados relacionais, tornando necessário transformar o 
Modelo Entidade-Relacionamento em uma notação que possa ser implementada neste 
tipo de banco de dados. 
O DTR (Diagrama de Tabelas Relacionais) é uma representação gráfica deste modelo, cuja 
notação está exemplificada na Figura 2, retratando a mesma situação descrita na Figura 
1. Esta notação também é comumente conhecida como “Pé de Galinha”, devido à 
simbologia utilizada (COUGO, 1997). Este diagrama é interessante, pois apresenta 
elementos com correspondência direta àqueles implementados nos bancos de dados 
relacionais, facilitando a transição do modelo conceitual para o lógico. Além disso, muitas 
ferramentas CASE atuais implementam apenas este diagrama. Assim também será 
apresentado este diagrama de maneira a facilitar o entendimento desta transição. 
 
 
 
 
 
 
Figura 2. Notação do Diagrama de Tabelas Relacionais 
 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
ESCOLA SUPERIOR CANDIDO MENDES 
 
Neste sentido, existem algumas regras de conversão do Modelo Entidade- 
Relacionamento para o Diagrama de Tabelas Relacionais, sendo as principais 
(ELMASRI e NAVATHE, 2005): 
Toda entidade vira uma tabela; 
 
o Relacionamentos que possuem atributos viram tabelas (existe a 
 possibilidade em relacionamentos 1:n dos atributos irem para uma das 
 tabelas, ao invés de se criar uma nova. Entretanto, relacionamentos com 
 atributos são mais comuns em relacionamentos n:n, gerando assim 
uma 
 nova tabela); 
 
o Relacionamentos são representados por chaves estrangeiras (ou 
 Foreign Key – atributo correspondente à chave primária de outra 
 relação, base para a integridade referencial); 
 
o Relacionamentos 1:1 podem ser mapeados numa única tabela (quando 
 possuem a mesma chave primária), em duas tabelas (quando as 
 chaves primárias são diferentes e um dos lados do relacionamento é 
 obrigatório) ou em três tabelas (quando o relacionamento é opcional em 
 ambos os lados); 
 Relacionamentos 1:n são mapeados de forma que a chave primária 
do lado “1” seja representada do lado “n” como chave estrangeira; 
 Relacionamentos n:n devem ser transformados em dois 
relacionamentos 1:n, resultando numa nova tabela; 
 
o Relacionamentos ternários (ou de maior grau) geram novas tabelas; 
 
o Agregações normalmente geram novas tabelas; 
 
 Auto-relacionamentos geram novas tabelas se forem 
relacionamentos do tipo n:n; 
 Generalização/Especialização podem ser mapeadas em uma 
única tabela, em uma tabela para cada especialização ou uma 
tabela para cada entidade envolvida, dependendo da situação. 
 
 
Assim, a partir do modelo conceitual é construído o modelo lógico que, diferentemente 
do primeiro, é dependente das características do SGBD escolhido. A ferramenta para 
este fim é o MR (Modelo Relacional), que representa a solução do problema modelado, 
considerando as estruturas (relações) que serão transformadas em tabelas quando da 
criação do banco de dados propriamente dito. 
 
 
 
 
 
 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
ESCOLA SUPERIOR CANDIDO MENDES 
Existem também algumas diferenças na nomenclatura. 
 
Por exemplo, 
 
“entidades” no Modelo Entidade-Relacionamento são chamadas de “relações” no Modelo 
Relacional, e “instâncias” são chamadas de “tuplas” (as linhas de uma relação). 
 
Quando da construção do banco de dados propriamente dito, as “relações” são chamadas 
de “tabelas”, as “tuplas” de “registros”, e os “atributos” de “campos” ou “colunas”. 
 
Neste contexto, uma questão importante a ser discutida na construção do Modelo Relacional 
é a normalização, que é um conjunto de regras que leva à construção de modelos mais 
robustos, com menos dependências entre seus elementos e menos redundância de 
informações. 
 
Normalização é uma atividade de verificação do modelo lógico e suas Formas Normais 
mais comuns, apesar de existirem outras, são (DATE, 2004): 
 
1ª Forma Normal (1FN): 
 
Toda relação deve ter uma chave primária e deve-se garantir que todo 
atributo seja atômico (único). Atributos compostos devem ser separados. 
Por exemplo ; 
 Um atributo Endereço deve ser subdividido em seus componentes: 
Logradouro, Número, Complemento, Bairro, Cidade, Estado e CEP. Além 
disso, atributos multivalorados devem ser discriminados separadamente ou 
separados em uma outra relação. Por exemplo, um atributo 
multivalorado Telefones poderia ser separado em Telefone Residencial, 
Telefone Comercial e Telefone Celular ou, ainda, ser convertido em 
outra relação que pudesse representar um número indeterminado 
de telefones. 
 
2ª Forma Normal (2FN): 
 
Toda relação deve estar na 1FN e devem-se eliminar dependências 
funcionais parciais, ou seja, todo atributo não chave deve ser totalmente 
dependente da chave primária. Como exemplo, uma relação que 
contenha os atributos Código da Obra, Código do Fornecedor, Nome do 
Fornecedor e Preço de Venda, considerando que a chave primária é 
composta pelos atributos Código da Obra e Código do Fornecedor, não 
está na Segunda Forma Normal, uma vez que o Nome do Fornecedor 
depende apenas do Código do Fornecedor, e não do Código da Obra. 
 
 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
ESCOLA SUPERIOR CANDIDO MENDES 
 
 
Uma nova relação (Fornecedor) deve ser criada contendo os campos 
Código do Fornecedor (como chave) e Nome do Fornecedor. Na 
relação original, ficariam os atributosCódigo da Obra e o Código do 
Fornecedor, ambos formando a chave primária composta, e o atributo 
Preço de Venda. Além disso, o atributo Código do Fornecedor também 
seria uma chave estrangeira para a nova relação criada. Esta forma normal 
ajuda a diminuir redundâncias de informações criadas indevidamente. 
 
3ª Forma Normal (3FN): 
 
 Toda relação deve estar na 2FN e devem-se eliminar dependências 
funcionais transitivas, ou seja, todo atributo não chave deve ser 
mutuamente independente. Como exemplo, uma relação que contenha 
os atributos Matrícula do Funcionário (atributo chave), Nome do 
Funcionário, Código do Departamento e Nome do Departamento não está 
na Terceira Forma Normal. O Nome do Departamento é dependente do 
Código do Departamento, e não da Matrícula do Funcionário. Uma 
mudança no nome do departamento, por exemplo, levaria a modificações 
em todos os funcionários daquele departamento. Para eliminar este 
problema, cria-se uma nova relação (Departamento) contendo Código do 
Departamento e Nome do Departamento. Na relação original, retira-se o 
Nome de Departamento, mantendo-se o Código do Departamento, 
agora como chave estrangeira. Esta forma normal também ajuda a 
diminuir redundâncias e aumentar a independência das relações. 
 
 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
ESCOLA SUPERIOR CANDIDO MENDES 
 Aula 8 
UTILIZAÇÃO DE RELACIONAMENTOS 1:1 E 1:N 
 
 
No sentido de exemplificar estes conceitos, será apresentado um fragmento de um 
sistema de controle de biblioteca. Como requisitos iniciais foram identificados: 
 
1. Devem ser cadastradas as obras do acervo, que representam livros, 
 
periódicos (revistas, jornais) e qualquer outro elemento do acervo da 
biblioteca. Inicialmente, obras devem possuir um código que as 
identifique: título, autor principal, ano de publicação, situação 
(disponível, emprestada) e editora. Editoras, por sua vez, possuem um 
código, nome e cidade. Uma obra sempre é de uma editora e uma 
editora pode possuir diversas obras; 
2. Devem ser cadastrados usuários da biblioteca, que devem ter uma 
 
identificação única, nome, endereço completo, telefone de contato e 
 
CPF; 
 
3. Os funcionários da biblioteca também devem ser cadastrados. 
 
Funcionários têm um número de matrícula, seu nome completo e 
departamento em que trabalha. Departamentos, por sua vez, possuem 
código e nome. Todo funcionário obrigatoriamente é vinculado a um 
departamento, que pode ter vários funcionários. Além disso, todo 
departamento possui um único chefe; 
4. Usuários devem poder realizar empréstimo de obras. Um empréstimo 
deve conter uma única obra e ser de um único usuário, 
obrigatoriamente. Empréstimos ainda devem registrar a data e horário 
do empréstimo, data prevista de retorno, bem como o funcionário que o 
realizou. Quando da devolução da obra em empréstimo, deve-se 
registrar a data e horário da devolução, bem como o funcionário 
responsável; 
 
 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
ESCOLA SUPERIOR CANDIDO MENDES 
 
 
5. Usuários ainda podem realizar reservas de obras. Uma reserva deve 
conter uma única obra e ser de um único usuário, obrigatoriamente. 
Reservas ainda devem registrar a data e horário da reserva e data na 
qual a obra será retirada. 
 
 
Alguns comentários são importantes de serem considerados quando da 
modelagem de dados. 
 
Primeiro, deve-se atentar para o fato de que redundância de dados não é 
desejável. Numa primeira análise, e pela simplicidade inicial do problema, se poderia 
imaginar a construção de uma única entidade contendo todas as informações do 
funcionário, por exemplo, incluindo os dados de seu departamento. Entretanto, a 
cada funcionário alocado a um mesmo departamento, acarretaria que os dados do 
departamento seriam duplicados no novo funcionário. Se, por exemplo, o 
departamento mudasse de nome, teria que mudar esta informação nos diversos 
funcionários lotados nele o que, além de redundante, pode causar inconsistências. 
 
Outra consideração importante é a respeito do endereço do usuário. No 
modelo conceitual pode-se representar apenas o atributo Endereço, pois é o 
problema que está sendo modelado. Entretanto, no modelo lógico, representam-se 
as estruturas internas das relações (atributos, restrições, chaves, relacionamentos). 
 
Neste caso, deve-se lembrar que a Primeira Forma Normal (1FN) 
determina que todo atributo deve ser atômico. Desta forma, deve-se separar o 
endereço em seus diversos atributos. Isso é importante, pois se for necessário 
saber quais são os usuários que vivem numa determinada cidade, este atributo 
deve estar separado. Caso contrário, torna-se difícil distinguir, por exemplo, um 
usuário que mora na cidade do Rio de Janeiro de outro que mora na Rua Rio de 
Janeiro na cidade de Belo Horizonte. 
 
 
 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
ESCOLA SUPERIOR CANDIDO MENDES 
 
Além disso, quando construir um relacionamento entre duas entidades, deve- 
se tomar cuidado com as obrigatoriedades dos dois lados do relacionamento. Por 
exemplo, se for modelado que um funcionário deve pertencer a um departamento e, 
ao mesmo tempo, um departamento deve ter ao menos um funcionário, não se está 
considerando a situação inicial, com o banco de dados vazio, onde primeiro se 
cadastram os departamentos sem funcionários e, no momento do cadastramento do 
funcionário, este é alocado ao departamento. 
Também é importante notar que nem todas as entidades estão explicitamente 
descritas no enunciado do problema. 
Por fim, não se deve preocupar com outras necessidades de modelagem, 
 
devendo-se focar no problema apresentado. 
 
 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
ESCOLA SUPERIOR CANDIDO MENDES 
 
A Figura 3 apresenta o Diagrama Entidade-Relacionamento contendo uma 
possível solução para o problema apresentado. Optou-se por não representar os 
atributos neste diagrama, para não dificultar a legibilidade. Os atributos 
serão apresentados posteriormente na estrutura das entidades. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 3. DER do problema apresentado 
 
 
Vale lembrar que, apesar de uma prática comum, não é obrigatório nomear os 
relacionamentos, exceto quando estes irão originar tabelas, o que é o caso de 
relacionamentos n:n ou relacionamentos que possuem atributos. Nestes casos, o 
nome dos relacionamentos normalmente são os nomes das tabelas resultantes. 
Entretanto, nomear relacionamentos é importante para uma melhor compreensão do 
modelo e este recurso será utilizado quando for necessário. Neste exemplo, foram 
nomeados os relacionamentos entre as entidades Funcionario e Departamento, uma 
vez que seu entendimento fica dificultado se os relacionamentos não forem 
nomeados, por existirem dois relacionamentos entre as mesmas entidades. 
EmprestimoRua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
ESCOLA SUPERIOR CANDIDO MENDES 
 
A seguir, é descrita a estrutura inicial das entidades, onde o atributo 
determinante está sublinhado. Observe que, propositadamente, foram deixados os 
atributos da editora dentro da entidade Obra: 
 
• Obra (cod_obra, titulo, autor_principal, ano_publicacao, 
 situacao_obra, tipo_obra, cod_editora, nome_editora, cidade) 
 
 
• Usuario (cod_usuario, nome_usuario, endereco, telefone, CPF) 
 
 
• Emprestimo (cod_emprestimo, cod_obra, cod_usuario, data_emprestimo, 
 horario_emprestimo, data_prevista_retorno, 
 num_matricula_funcionario) 
 
• Devolucao (cod_emprestimo, data_devolucao, horario_devolucao, 
 num_matricula_funcionario) 
 
• Funcionario (num_matricula, nome_funcionario, cod_departamento) 
 
 
• Departamento (cod_departamento,nome_departamento, 
 num_matricula_chefe) 
 
• Reserva (cod_reserva, cod_usuario, cod_obra, data_reserva, 
 horario_reserva, data_retirada) 
 
 
 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
ESCOLA SUPERIOR CANDIDO MENDES 
 Aula 9 
Para a construção deste diagrama, algumas decisões de projeto foram 
tomadas e valem a pena serem discutidas: 
• Na entidade Emprestimo, uma possibilidade para a definição do atributo 
determinante seria a concatenação dos atributos cod_usuario e 
cod_obra, caracterizando uma chave composta. Entretanto, esta chave 
impediria que o mesmo usuário realizasse o empréstimo da mesma obra 
em datas diferentes. Uma possibilidade seria incluir também o atributo 
data_emprestimo na chave. Neste caso, preferiu-se incluir um atributo 
cod_emprestimo como atributo determinante. Este tipo de situação é 
chamada de chave cega, onde um novo atributo é inserido por 
dificuldades na determinação da chave da entidade. O mesmo raciocínio 
foi utilizado para determinar a chave da entidade Reserva; 
• O relacionamento 1:1 entre as entidades Emprestimo e Devolucao 
não necessariamente precisaria existir. Relacionamentos com esta 
cardinalidade muitas vezes podem ser eliminados e os atributos das 
duas entidades podem ser unificados, principalmente neste caso onde 
os atributos determinantes são os mesmos (a entidade Devolucao 
poderia ter um atributo determinante diferente, como cod_devolucao 
mas, neste caso, seria necessário definir um outro atributo que fizesse a 
ligação com a entidade Emprestimo). Assim, uma possibilidade seria 
transferir para a entidade Emprestimo todos os atributos da entidade 
Devolucao e eliminar esta entidade. Com isso, o empréstimo também 
teria os dados de sua devolução, sendo necessário ter um outro 
relacionamento com a entidade Funcionario, para representar o 
funcionário responsável pela devolução. Neste exemplo, preferiu-se 
manter as entidades separadas, uma vez que são eventos que 
representam situações diferentes e acontecem em momentos distintos e, 
no caso da devolução, pode nem acontecer; 
 
 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
ESCOLA SUPERIOR CANDIDO MENDES 
 
 
 
• Os dois relacionamentos entre as entidades Funcionario e 
Departamento são importantes, uma vez que representam ligações 
diferentes entre as entidades, um representando lotação e outro chefia. 
Neste caso, o relacionamento 1:1 não poderia ser eliminado, uma vez que 
existe um segundo relacionamento entre as mesmas entidades; 
• Optou-se por não fazer um relacionamento entre as entidades 
Emprestimo e Reserva, representando que um empréstimo possa 
ter sido efetivado em função de uma reserva. Esta decisão foi tomada 
uma vez que não existe a necessidade de estar armazenando 
definitivamente as reservas, podendo as mesmas ser eliminadas após a 
data da reserva ter sido vencida; 
• Deve-se observar ainda um problema na entidade Obra. Caso existam 
 
vários exemplares da mesma obra, tem-se que cadastrar a obra várias 
vezes, uma para cada exemplar. Este problema será resolvido 
posteriormente. 
 
 
O próximo passo é analisar se as entidades representadas estão 
normalizadas, podendo transformar-se em relações. Segue esta análise das Formas 
Normais: 
• 1ª FN: esta Forma Normal não foi satisfeita, uma vez que o atributo Endereco 
 
da entidade Usuario não é atômico. Para satisfazer esta FN, este atributo deve 
ser desmembrado em Logradouro, Numero, Complemento, Bairro, Cidade, UF, 
CEP; 
• 2ª FN: o modelo encontra-se na Segunda Forma Normal, que determina que 
 
todo atributo não chave deve ser totalmente funcionalmente dependente da 
chave primária, e não de parte dela. Só faz sentido preocupar-se com esta 
Forma Normal para aquelas relações que possuem chave primária composta. 
No estudo de caso em questão, como todas as relações possuem chaves 
primárias simples, contendo de apenas um atributo, não é necessário 
preocupar-se com esta Forma Normal no momento; 
 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
ESCOLA SUPERIOR CANDIDO MENDES 
 
• 3ª FN: pode-se observar um problema com esta Forma Normal ao analisar a 
 
relação Obra. Neste caso, os atributos nome da editora e cidade da editora 
dependem funcionalmente apenas do atributo código da editora, que é um 
atributo não chave. Lembrando, a 3ª FN indica que todos os atributos não 
chave devem ser mutuamente independentes. Assim, apesar dos dados da 
editora poderem ser considerados como atributos da obra, torna-se importante 
separar estas entidades, primeiro para não ter estes atributos redundantes. 
Segundo, a digitação diferente do nome de uma editora, por exemplo, faz com 
que consultas indiquem editoras diferentes, o que não é desejável. Outra 
situação indesejável acontece se uma editora mudar de cidade, ocasionando 
uma mudança no valor deste atributo em todas as obras desta editora. 
 
 
A Figura 4 apresenta o DTR (Diagrama de Tabelas Relacionais) ou DER 
(Diagrama entidade relacionamento) do modelo após a etapa de normalização. 
Novamente os atributos foram suprimidos para facilitar a visualização e serão 
detalhados a seguir. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 4. O DTR do problema apresentado 
 
 
 
 
 
Rua da Assembléia, nº. 10 -3ºandar - sala 319 CEP 20011-901 • Rio de Janeiro • RJ 
 Tels.: (21) 3543-6442 e 3543-6413 
 escm@candidomendes.edu.br • www.candidomendes.edu.br/escm 
ESCOLA SUPERIOR CANDIDO MENDES 
 
As Tabelas 1 a 8 apresentam as estruturas das tabelas, onde PK (Primary 
Key) representa a chave primária da tabela (que deve ser obrigatória) e FK (Foreign 
Key) representa uma chave estrangeira, onde o valor do atributo deve ser 
correspondente a uma chave primária da tabela a qual está referenciando, ou ser 
nulo, quando não for obrigatório. Isto se chama integridade