UNIVERSIDADE CATÒLICA DE MOÇAMBIQUE

Base de dados.
De:
Raquelina Evaristo de Sousa

Trabalho individual da cadeira,

Sistemas de Informação Gerêncial
, Do 20 semestre do 30 ano do curso
de Contabilidade e Auditoria, pós
laboral, por orientação do Docente:
Elizete Márcia António Macie

Tete
Janeiro, de 2021
 ii

Índice
1. Introdução............................................................................................................................4

2. Objetivos..............................................................................................................................4

2.1. Objetivo geral...............................................................................................................4

2.2. Objetivo específicos.....................................................................................................4

3. MYSQL...............................................................................................................................5

3.1. História.........................................................................................................................5

3.2. Licença de Uso.............................................................................................................5

3.3. Características..............................................................................................................6

4. MODELAGEM DE DADOS..............................................................................................7

4.1. Modelos de Bancos de Dados......................................................................................8

4.1.1. Modelo Hierárquico..............................................................................................8

4.1.2. Modelo de Rede....................................................................................................8

4.1.3. Modelo Relacional................................................................................................8

4.2. MER (Modelo Entidade e Relacionamento)..............................................................10

4.2.1. Utilização do método Entidade-Relacionamento................................................10

4.2.2. Vantagens do método Entidade-Relacionamento...............................................10

4.3. Entidades....................................................................................................................11

4.3.1. Concepção de uma entidade................................................................................12

4.4. Atributos.....................................................................................................................12

4.4.1. Tipo de atributo...................................................................................................12

4.5. Chaves........................................................................................................................14

4.5.1. Chave primária....................................................................................................14

4.5.2. Chave secundaria................................................................................................15

4.6. Relacionamento entre entidades.................................................................................15

4.6.1. Tipos de relacionamento entre entidades............................................................16

4.6.2. Relacionamentos.................................................................................................18
 iii

4.6.3. Grau e Classe de um relacionamento..................................................................18

4.6.4. Algumas Extensões ao Modelo ER.....................................................................18

4.7. Formas Normais.........................................................................................................19

4.7.1. Normalização......................................................................................................20

4.7.2. Formas normais...................................................................................................20

5. Conclusão..........................................................................................................................23

6. Bibliografia........................................................................................................................24
 4

1. Introdução

Neste artigo teremos como objetivo conhecer um pouco sobre MySQL, que é um SGBD
(Sistema Gerenciador de Banco de Dados) relacional, que utiliza a linguagem
SQL (Structured Query Language, ou traduzindo, Linguagem de Consulta Estruturada).
MySQL também é multiusuário e multitarefas.

Este SGBD inicialmente foi desenvolvido para trabalhar com projetos de pequeno e médio

porte, com a capacidade de suportar por volta de cem milhões de registros em cada tabela,
podendo chegar ao tamanho médio de aproximadamente cem megabytes por tabela,
entretanto, esses eram os tamanhos recomendados nas primeiras versões. Porém, hoje em dia
o MySQL ultrapassa extraordinariamente esses limites e capacidades das versões anteriores.

2. Objetivos
2.1. Objetivo geral
 Conhecer MySQL

2.2. Objetivo específicos

 Descrever a históricos do MySQL

 Caraterizar MySQL
 Identificar tipos de chaves e atributo

 Definir MySQL
 5

3. MYSQL

MySQL é conhecido por ser de fácil utilização, e usado por empresas que trabalham com
grandes volumes de dados, tais como, NASA, Bradesco, HP, Sony entre outras grandes
empresas de renome. Possui uma interface extremamente simples e é compatível com grande
parte dos sistemas operacionais. Podemos dizer que essas são duas das grandes características
que fazem o MySQL ser tão utilizado atualmente e estar em constante crescimento.

Mesmo sendo um dos bancos de dados mais utilizando em todo o mundo, MySQL continua
em constante desenvolvimento, com atualizações frequentes.

3.1. História

O MySQL foi criado na Suécia, a MySQL AB, desenvolvedora do MySQL, foi adquirida pela
Sun Microsystems por US$ 1 bilhão. Quando ele foi projetado atendia aplicações de pequeno
a médio porte (aproximadamente 100 milhões de registros por tabela, tendo como base o
tamanho de 100mb por tabela), mas com seu desenvolvimento ele atende muito além disso!

O MySQL foi originalmente desenvolvido pela empresa sueca TCX, que necessitava de um
servidor de banco de dados que operasse com grandes escalas de dados rapidamente sem
exigir caríssimas plataformas de hardware. No início eles utilizavam o mSQL, mas depois de
alguns testes chegaram à conclusão que o mSQL não era rápido nem flexível o suficiente para
as necessidades existentes.

3.2. Licença de Uso

O MySQL é de Código Aberto (Open-Source), desenvolvido e distribuído sob as licenças

GNU/GLP (General Public Licence, ou traduzindo, Licença Publica Geral), q qual determina
o que se pode ou não fazer à ferramenta e demais recursos. Além do programa, o seu código-
fonte também é disponibilizado para que qualquer usuário possa edita-lo de forma que atenda
suas necessidades.

Os princípios básicos da licença GNU/GLP são:

 Utilização: Permite que o usuário faça uso do software para qualquer finalidade.
 Distribuição: Livre distribuição do software entre quaisquer pessoas.
 Didática: Permite que seu funcionamento seja estudado através de seu código-fonte
 6

 Colaboração: Possibilita que seu código-fonte seja modificado para evoluir a

ferramenta. Como regra seu novo código-fonte tem que permanecer sendo livre
segundo essa licença.

3.3. Características

 Portabilidade: Devido o MySQL ter sido desenvolvido em C e C++, tornou-se

extremamente fácil a portabilidade entre os diferentes sistemas, plataformas e
compiladores. Possui também módulos de interface para múltiplas linguagens, tais
como Delphi, Java, Python, PHP, ASP, Ruby e entre outras linguagens mais.
 Formas de Armazenamento: O MySQL possibilita diversos tipos de tabela para o
armazenamento dos dados, tendo em conta que cada tipo tem suas próprias
características. Dessa maneira temos a possibilidade de escolhermos o tipo de acordo
com cada situação diferente. Enquanto um tipo tem como prioridade a velocidade,
outro da prioridade ao volume de dados, entre outras características.
 Velocidade: Alta velocidade no acesso dos dados em razão de diversos motivos em
seu desenvolvimento com tabelas ISAM, que foi substituído pelo novo sistema
MyISAM na versão 5 do MySQL, além de utilização de caches em consultas,
utilização de indexação BTREE para as tabelas do tipo HEAP, algoritmos de busca,
entre outros recursos.
 Capacidade: O MySQL possui um alto poder de execução e de armazenamento.

De acordo com a plataforma em que seja usado, suas tabelas poderão armazenar grandes
volumes de dados, o limite ficará por conta somente do tamanho máximo de arquivos que a
plataforma que estiver sendo utilizada puder manipular. Já no caso de tabelas do tipo InooDB,
onde o armazenamento pode ser realizado em um ou vários arquivos separados, fica possível
armazenar volumes de dados equivalentes a TB (Terabytes) de tamanho. E referente a
expressões SQL, o MySQL suporta execuções de script SQL com até 61 milhões de tabelas
“joins”. E no quesito de velocidade de execução, o MySQL pode ser considerado um dos mais
velozes, isso é, se não podemos dizer que é o mais veloz.

O MySQL, por ser um banco de dados poderoso, tem a capacidade de realizar bilhões de
consultas em um único dia em um site e também fazer o processamento de milhões de
transações por minuto.
 7

SQL: Como já sabemos, o MySQL trabalha com a linguagem SQL  (Structured Query
Language, ou traduzindo, Linguagem de Consulta Estruturada), sendo extremamente rápido.
E isso foi possível devido a SQL ter sido implementada no MySQL através de códigos e
funções altamente customizadas pelos seus desenvolvedores. Isso gerou a grande vantagem de
velocidade no processamento dos códigos SQL, porém, ao mesmo tempo trouxe um ponto
negativo, sendo ele o fato de que com essa customização, nem todos os padrões das versões
mais atuais do SQL tenham sido trazidos para o MySQL, porque poderiam prejudicar
consideravelmente a velocidade do banco de dados. Entretanto, essa desvantagem não
influencia em nada na aplicação.

4. MODELAGEM DE DADOS
Sistemas Gerenciadores de Bancos de Dados SGBD, Sistema Gerenciador de Banco de Dados
(ou DBMS, Database Management System) é um sistema utilizado para gerenciar dados que
estão armazenados de forma organizada, permitindo incluir, alterar, excluir, consultar e
manipular dados. O tratamento da informação em um banco de dados oferece vantagens:

 A disponibilidade dos dados para exclusão, consulta ou alteração pode ser autorizada
pelo Administrador de Banco de Dados (DBA, Data Base Administrador) no projeto,
antes das aplicações serem desenvolvidas, permitindo com isso a segurança e a
privacidade dos dados;
 A padronização é reforçada. Os tipos de dados mais importantes são atributos que têm
seus nomes e tamanhos definidos já no projeto do banco de dados.
 Os dados dizem respeito a um ambiente, empresa ou corporação e estão disponíveis
independentemente da aplicação.
 Um projeto de banco de dados coerente reduz ou elimina a redundância, favorecendo a
manutenção da integridade dos dados. A arquitetura de um SGBD é estabelecida a
partir de um modelo de dados, que é uma forma de representação que resulta de uma
abstração. O projeto de um banco de dados envolve o desenvolvimento de um modelo
formal relativo à estruturação dos dados de todo um empreendimento. Os SGBDs
existentes no mercado geralmente adotam o modelo hierárquico, de rede ou relacional.
Dentre os três, o mais utilizado é o modelo de rede. O objetivo de todos os modelos de
dados é modelar a realidade tão proximamente quanto possível.
 8

4.1. Modelos de Bancos de Dados

4.1.1. Modelo Hierárquico
Os SGBD´s baseados no modelo hierárquico foram os primeiros sistemas a estarem
disponíveis comercialmente. No modelo hierárquico, o usuário percebe o banco de dados
como uma estrutura de árvores que envolvem registros e ligações. Cada registro pode possuir
um número qualquer de descendentes, mas apenas um ascendente (exceto a raiz, que não
possui ascendente). O registro ascendente guarda referências do conjunto de descendentes que
possui.

A navegação dentro de um banco de dados hierárquico é feita com comandos do tipo “acessar
primeiro” e “acessar próximo” (get first e get next), admitindo cláusulas e predicados para
pesquisa.

4.1.2. Modelo de Rede

No modelo de rede, a visão do usuário é a de um grafo ou uma malha de ligações um para
muitos entre os registros. Um tipo de registro pode estar envolvido em mais de um
relacionamento, pode ter vários ascendentes e vários descendentes O grupo CODASYL (que
desenvolveu o Cobol), através do Database Task Group (DBTG) desenvolveu um modelo de
rede que é o mais difundido e aceito. O modelo DBTG criou a figura do grupo ou conjunto,
uma representação para os relacionamentos. Cada conjunto tem um tipo de registro
proprietário, que só pode participar de uma ocorrência do conjunto, e um tipo de registro
membro, que pode participar em qualquer quantidade de ocorrências

4.1.3. Modelo Relacional

Um banco de dados relacional é visto pelo usuário como um conjunto de tabelas. Uma tabela
ou relação é formada por linhas conhecidas como tuplas (lê-se “tuplas”) e colunas. Cada
coluna tem um conjunto de valores possíveis chamado domínio. Em linguagem de
computação, tabela ou relação equivale a arquivo, tupla equivale a registro e coluna equivale
a campo. A representação por um conjunto de tabelas estabelece a diferença em relação ao
modelo rede, que é um conjunto de registros e relacionamentos através de ligações. Portanto,
definimos um sistema relacional como aquele onde os dados são notados pelos usuários como
tabelas e as operações aplicáveis ao sistema geram tabelas partindo da primeira.

A teoria sobre o modelo relacional apresenta dois formalismos para a manipulação de banco
de dados: a álgebra relacional e o cálculo relacional, que serviram de base param a construção
de todas as ferramentas relacionais hoje disponíveis. A álgebra relacional é formada por
 9

operações cujos nomes vêm da teoria de conjuntos, e outras operações relacionais que foram
especialmente criadas:

 União: Produz uma tabela resultante da união de outras tabelas operadas;

 Interseção: Cria uma tabela, resultado da interseção de outras tabelas operadas;
 Diferença: Cria uma tabela contendo tuplas que pertencem a primeira tabela operada,
mas não à segunda;
 Produto Cartesiano: Gera todas as combinações possíveis entre as tuplas de duas
tabelas.
 Projeção: Cria uma tabela contendo alguns atributos específicos da tabela operada;
 Seleção ou Restrição: Serve para extrair tuplas de uma certa tabela;
 Junção: Gera uma tabela que é a combinação das tabelas operadas segundo critérios
impostos sobre atributos de uma e outra tabela;
 Divisão: Opera duas tabelas, criando uma terceira com os atributos da primeira tabela,
cujos atributos que os acompanham existem também na segunda tabela.

O cálculo relacional tem poder equivalente à álgebra e dá como resultado relações (tabelas),
da mesma forma. A diferença está na forma de expressão: a álgebra especifica as operações a
fazer sobre as tabelas, enquanto o cálculo relacional apenas nomeia a informação desejada e
um certo predicado ou critério para os valores a serem pesquisados, sem dizer quais as
operações a fazer. Dentre os sistemas relacionais, os System/R e o Ingres foram os primeiros a
serem comercializados. Dentre os sistemas relacionais atuais mais utilizados no brasil, temos:

 MS-Access
 DB2
 Informix
 Oracle
 Progress
 Sybase
 TSGDB
 Unify
 Zim
 MS-SQL Server
 Postgresql
 Mysql
 10

 Interbase / Firebird

4.2. MER (Modelo Entidade e Relacionamento)

Um banco de dados é um acervo de informações armazenadas segundo certos critérios de
organização. O modelo relacional de dados é uma maneira de conceber a organização de um
banco de dados como uma coleção de tabelas e associações entre outras tabelas. Por exemplo,
veja a figura abaixo: cada tabela é armazenada em um arquivo, cada linha é um registro e tem
um conteúdo único na tabela. Cada coluna é um campo, com um nome que representa o tipo
de dados contido na coluna.

Os modelos semânticos de dados surgiram com o objetivo de agregar sentido à descrição de

um banco de dados. A abordagem semântica mais conhecida e adotada é a do modelo
Entidade-Relacionamento (E-R), publicado em artigo de Peter Pin-Shan Chen, baseado na
teoria relacional e teoria dos conjuntos. O ER é um modelo de dados que se propôs a englobar
algumas propostas de modelagem anteriores, como o modelo relacional e o de rede, e dar uma
visão mais abstrata e de mais alto nível a um ambiente de banco de dados.

4.2.1. Utilização do método Entidade-Relacionamento

O método entidade-relacionamento é um método para projeto lógico de banco de dados. A
ideia chave no modelo E-R é acrescentar um estágio intermediário ao projeto lógico de banco
de dados. O projetista do banco de dados primeiro identifica as entidades e relacionamentos
que são de interesse para a empresa ou instituição usando a técnica diagramática Entidade-
Relacionamento.

Nesse estágio, o projetista deve examinar os dados do ponto de vista da empresa como um
todo, e não com a visão de programador de aplicação específica. Por exemplo, vamos chamar
a descrição da visão de uma empresa quanto aos dados de “esquema da empresa”. O esquema
da empresa deve ser uma representação pura do mundo real e deve também ser independente
de consideração sobre armazenamento e eficiência. O projetista primeiro projeta o esquema
da empresa e então o traduz a um esquema do usuário para seu sistema de banco de dados.

4.2.2. Vantagens do método Entidade-Relacionamento

Como já dissemos acima, o método entidade-relacionamento para projeto lógico de banco de
dados é formado por duas partes principais:

 Definição do esquema da empresa usando o diagrama Entidade-Relacionamento;

 Tradução do esquema da empresa em um esquema do usuário.
 11

As vantagens de se utilizar esse método são:

 A divisão da funcionalidade e trabalho em duas etapas torna o processo do projeto de

banco de dados mais simples e mais bem organizado;
 Esquema da empresa fica mais fácil de ser projetado do que o esquema do usuário,
porque não precisa ser restrito pelas características do sistema de banco de dados e é
independente de considerações sobre armazenamento e eficiência;
 O esquema da empresa é mais estável do que o esquema do usuário;
 Esquema da empresa expresso pelo diagrama de Entidade-Relacionamento é mais
facilmente compreendido por pessoas não ligadas ao processamento eletrônico de
dados.

Etapas no projeto lógico de banco de dados segundo o modelo E-R. O método E-R consiste
nas seguintes etapas:

 Identificar tipos de entidades;

 Identificar tipos de relacionamentos;
 Desenhar um diagrama E-R com tipos de entidade e relacionamentos;
 Identificar tipos de valor e atributos;
 Traduzir o diagrama E-R em um diagrama de estrutura de dados;
 Projetar formatos de registros.

4.3. Entidades
Entidade é um conjunto de objetos de mesma natureza, com as mesmas características ou
atributos, abrigados sob um nome genérico. Em um banco de dados de uma universidade, por
exemplo, são entidade: Aluno, Professor, Curso, Departamento, Disciplina, etc., pois cada
uma destas entidades representa uma coleção de objetos com os mesmos tipos de atributos.
Chamamos ocorrência de uma entidade à um objeto que pertence entidade. No exemplo
acima, Ciências da Computação poderia ser uma ocorrência da entidade Curso e Bancos de
Dados uma ocorrência de Disciplina. Cada ocorrência de entidade apresentar-se-á como uma
coleção de elementos de dados ou atributos, por exemplo:

Entidade Atributos
ALUNO Nome Número de matrícula Endereço
PROFESSOR Nome Código Data de admissão Salário
 12

Atributo determinante é aquele que identifica uma ocorrência da entidade. Por exemplo:
Número de matrícula, na entidade ALUNO. Observe, no exemplo acima, que os atributos
Nome aparecem tanto para a entidade ALUNO quanto para PROFESSOR, mas são coisas
diferentes, com significados diferentes.

4.3.1. Concepção de uma entidade

A definição sobre o que deve ou não ser entidade depende do ambiente para o qual se projeta
o banco de dados. Vamos examinar, por exemplo, chassi. Para uma fábrica de chassis,
certamente haverá uma entidade Chassi, com elementos de dados dando as características de
cada ocorrência ou modelo de chassi. Agora, no banco de dados de uma montadora de
veículos, chassi pode ser uma ocorrência da entidade Parte (Item, Peça ou que nome possua),
relacionando-se com outras ocorrências da entidade para compor produtos ou subprodutos.
Por fim, para o banco de dados do Cadastro Nacional de Veículos Roubados, chassi poderá
ser um elemento de dados da entidade Veículo correspondente ao número de série do chassi
(neste caso, a única informação sobre chassi que interessa).

Portanto, conceber uma entidade é uma tarefa cuja decisão é relativa, depende do âmbito do
projeto. Uma boa garantia de que uma entidade foi bem projetada é ter a capacidade de lhe
atribuir um nome que represente o que é cada uma de suas ocorrências e identificar o atributo
determinante que lhe confere identidade.

4.4. Atributos
Atributos é uma função que mapeia um conjunto de entidades num domínio e identifica,
qualifica e descreve esse conjunto de entidades. Uma entidade é representada por um conjunto
de atributos. Ou seja são propriedades (características) que identificam as entidades. Uma
entidade é representada por um conjunto de atributos. Os atributos podem ser simples,
composto, determinante.

Nome, endereço, telefone e cidade, por exemplo, são atributos da entidade Clientes. Enquanto
salário, cargo e departamento são atributos da entidade funcionários.

4.4.1. Tipo de atributo

Existem quatro tipos de atributos: 

 Simples

 Composto,
 13

 Multivalorado e

 Determinante

4.4.1.1. Atributo Simples

Não possui qualquer característica especial. A maioria dos atributos será simples. Quando um
atributo não é composto, recebe um valor único como nome, por exemplo e não é um atributo
chave, então ele será atributo simples..

Em uma entidade cliente, por exemplo, poderemos considerar como atributo simples: nome,
sexo, data de nascimento, dentre outros.

4.4.1.2. Atributo Composto

O seu conteúdo é formado por vários itens menores. Exemplo: Endereço. Seu conteúdo
poderá ser dividido em vários outros atributos, como: Rua, Número, Complemento, Bairro,
Cep e Cidade. Este tipo de atributo é chamado de atributo composto. Veremos mais de sua
aplicação no post sobre normalização de dados.

É importante considerar que na aplicação do banco de dados um atributo composto

geralmente é desmembrado, ou seja, para o caso do endereço, podemos desmembrá-lo em
vários atributos simples, como: Rua, número, complementa, bairro, cidade e cep.
Conceitualmente é aceito o endereço como um único atributo, mas na prática geralmente é
feito este desmembramento para permitir a organização dos dados inseridos e facilitar a busca
e indexação dos mesmos.

4.4.1.3. Atributo Multivalorado

O seu conteúdo é formado por mais de um valor.

Exemplo: Telefone. Uma pessoa poderá ter mais de um número de telefone. É indicado
colocando-se um asterisco precedendo o nome do atributo. Os atributos multivalorado serão
tratados com mais detalhes na normalização de dados.

Este tipo de atributo é aceito conceitualmente, mas ele pode ser um problema no banco de
dados. Há duas possibilidades para tratar com ele. A primeira é mantê-lo como multivalorado
e permitir que mais de um dado seja inserido no mesmo campo, como por exemplo: dois
números de telefone. A segunda alternativa é aplicar o processo de normalização de dados e
 14

transformá-lo em uma entidade a parte ou uma tabela no banco de dados e relacioná-la com a
tabela principal.

A primeira alternativa é mais simples, mas teríamos o problema da consulta de dados, caso
precisássemos fazer uma consulta pelo número de um dos telefones apenas. A segunda é mais
trabalhosa, porém é mais eficaz.

4.4.1.4. Atributo Determinante

Identifica de forma única uma entidade, ou seja, não pode haver dados repetidos.

É indicado sublinhando-se o nome do atributo. Exemplo: CNPJ, CPF, Código do fornecedor,

Número da matrícula, etc. Os atributos determinantes serão as chaves primárias no banco de
dados e seu uso tem implicações na normalização de dados.

Devemos considerar que toda tabela no banco de dados precisa ter um atributo determinante,
que também chamamos de chave primária. Desta forma, se a entidade não oferecer por padrão
uma sugestão de atributo determinante, temos de criá-lo. Este é um princípio bastante básico
da análise e modelagem de dados.

4.5. Chaves

O conceito de chave é importante na modelagem de dados, pois implementa restrições que

garantem a integridade referencial dos dados no banco de dados.

Existem vários tipos de chaves em um modelo lógico. Vamos analisar chave primaria e chave
secundaria.
4.5.1. Chave primária

É a chave candidata escolhida pelo projetista do banco de dados como de 'significado

principal para o negócio' e que permite a identificação de ocorrências dentro de uma entidade.
O objetivo da chave primária é garantir que cada linha da tabela possa ser endereçada de
maneira única e por este motivo ela deve ser preenchida obrigatoriamente.
4.5.1.1. Classificação de chaves primárias

 Simples: exemplo: clientes (codigo, cpf, identidade, nome, endereco, limcre)

 Chave composta: exemplo: contas (agencia, numero, saldo, dtabertura)

 15

4.5.1.2. Características de uma chave primária

 Não pode haver duas ocorrências de uma mesma entidade com o mesmo conteúdo na
chave primária;

 A chave primária não pode ser composta por atributo opcional , ou seja , atributo que
aceite nulo.

 Os atributos identificadores devem ser o conjunto mínimo que pode identificar cada
instância de uma entidade.

 Não devem ser usadas chaves externas. (atributos sobre os quais você não tem
controle. Ex: cpf)

 Cada atributo identificador da chave deve possui um tamanho reduzido

 Não deve conter informação volátil.      

4.5.2. Chave secundaria
Uma chave secundaria é um campo, que aponta para a chave primária de outra tabela ou da
mesma tabela. Ou seja, passa a existir uma relação entre duplas de duas tabelas ou de uma
única tabela. A finalidade da chave secundaria é garantir a integridade dos dados referenciais,
pois apenas serão permitidos valores que supostamente vão aparecer na base de dados.

Esse tipo de atributo não permite exclusão, modificação ou inserção de dados em tabelas que
estejam dependentes umas das outras ("foreign key"), o que requer modificadores especiais,
como cascada, por exemplo. Isso também exige uma maior atenção do administrador da base
de dados, quanto à própria manipulação dos dados.

4.5.2.1. Definição da chave secundaria

As chaves secundariam são definidas no padrão iso do sql, através de uma restrição foreign
key. A sintaxe para adicionar uma tal restrição a uma tabela existente é definido no sql: 2003,
como mostrado abaixo. Omitindo a lista de colunas na cláusula de referências implica que a
chave estrangeira deve referenciar a chave primária da tabela referenciada.

4.6. Relacionamento entre entidades

Relacionamento entre entidades é o tipo de ocorrência existente entre entidades e aplicáveis
no processo de modelar dados. Entender isso é importante pois um modelo consistente é a
 16

base para um banco de dados de sucesso. O símbolo que representa o relacionamento no

Modelo de Entidade e Relacionamento (MER) é um losango com o nome do relacionamento
escrito no seu interior, como no exemplo a seguir.

Em um modelo de entidade e relacionamento, nem todas as entidades serão relacionadas, há

casos em que não há ligação entre elas, nestes casos consideramos como entidades isoladas.
Embora não seja tão comum, é importante levar em conta esta possibilidade. Mas quando as
ligações existirem, elas serão classificadas de acordo com os tipos a seguir.

4.6.1. Tipos de relacionamento entre entidades

Existem três tipos de relacionamento entre entidades:

 Um-para-um
 Um-para-muitos
 Muitos-para-muitos

4.6.1.1. Relacionamento um-para-um

O relacionamento um-para-um é usado quando uma entidade A se relaciona com uma
entidade B e vice-versa.

Este relacionamento é representado pelo sinal: 1:1

Exemplo:

O relacionamento um-para-um é bastante incomum e usado em casos bem específicos.

Geralmente quando você tem duas tabelas paralelas que precisa fazer esse tipo de
relacionamento, as vezes se pergunta se não seria melhor juntar as duas tabelas. Contudo por
se tratar de alguma situação específica, se as duas precisarem serem mantidas, então justifica
relacionar-se um para um nesse caso.
 17

4.6.1.2. Relacionamento um-para-muitos

O relacionamento um-para-muitos é usado quando uma entidade A pode se relacionar com
uma ou mais entidades B.

Este relacionamento é representado pelo sinal: 1:N

Exemplo:

O relacionamento um-para-muitos é o tipo mais comum e que deve ser encontrado na maioria
das tabelas que estão relacionadas. O que justifica esse tipo de relacionamento é o fato de que
normalmente uma entidade tende a ser replicada muitas vezes em outra, como acontece por
exemplo quando um produto é vendido N vezes, um cliente faz N compras, uma sala tem N
alunos e assim por diante.

Desta forma o relacionamento um-para-muitos é aquele que representa de maneira muito

realística o que acontece de fato dentro das organizações e no mundo real, portanto é uma
representação bastante fiel dentro de um banco de dados para os sistemas de informação.

4.6.1.3. Relacionamento muitos-para-muitos

O relacionamento muitos-para-muitos é usado quando várias entidades A se relacionam com
várias entidades B.

Este relacionamento é representado pelo sinal: N:N ou N:M

Exemplo:

Relacionamento muito para muitos é um caso interessante, eu particularmente costumo falar

para os meus alunos que ele só é possível na teoria, pois na prática ficaria totalmente inviável
a implementação dele.
 18

Deixa eu explicar: ele pode até ser implementado na prática, mas para isso é preciso criar uma
terceira tabela que permita esse relacionamento e aí o que vai acontecer na verdade é que você
vai ter dois relacionamentos um para muitos para poder representar o muito para muitos.
Deixa dar um exemplo real para ficar mais fácil de entender.

4.6.2. Relacionamentos
Relacionamento é uma associação entre entidades. Pode haver relacionamento envolvendo
uma (Auto relacionamento) ou mais entidades. Nos diagramas ER, estes últimos são
representados por losangos com o nome rotulado, como mostra a figura 6:

4.6.3. Grau e Classe de um relacionamento

Os relacionamentos são classificados segundo grau e classe. O grau indica o número de
entidades que participam da associação.

A classe de um relacionamento dá conta de quantas ocorrências de cada entidade podem estar

envolvidas no relacionamento. É representada no diagrama ER sobre a linha e chamada entre
a entidade e o relacionamento. Assim, no exemplo da figura 7, Lotação é um relacionamento
1:N, porque cada Departamento pode ter N (vários) Funcionários lotados, mas um
Funcionário está lotado em apenas 1 Departamento, Como CC (composição de centro de
custos) é um relacionamento 1:N porque um centro de custos pode ser componente de 1
centro de custos e pode ser composto por N (vários) centros de custo. Usaremos o exemplo de
relacionamento de grau 3 da figura 7 para enunciar a maneira de estabelecer a classe de um
relacionamento. O relacionamento Estoque, que seria mais apropriadamente chamado Item de
Estoque, é uma construção bastante singular, existente apenas em algumas lojas de
departamentos com várias filiais. Cada filial tem a liberdade de distribuir os produtos nos
departamentos como melhor aprouver à sua gerência. O relacionamento Estoque tem a função
de representar os itens de estoque, com os atributos: quantidade em estoque e preço. Para
estabelecer o indicador 1 ou N junto a cada uma das entidades participantes, devemos fazer a
seguinte pergunta: “ Quantas ocorrências desta entidade podem estar associadas às demais no
relacionamento em questão? ”.-

4.6.4. Algumas Extensões ao Modelo ER

O modelo ER vem recebendo, desde a publicação do artigo de Chen em 1976, inúmeras
contribuições e extensões. Novos modelos vêm sendo propostos, também para alcançar o
objetivo de qualquer modelo de dados modelar a realidade tão proximamente quanto possível.
 19

4.6.4.1. Quando a cardinalidade não é exatamente 1

O modelo ER original prevê o estabelecimento da classe de um relacionamento com os
símbolos 1 ou N (vários). Porém, em algumas situações, isto não é suficiente para expressar a
realidade. Veja o relacionamento da figura 8, de um ambiente de banco de dados de uma
imobiliária que administra contratos de aluguel. Existe a entidade Imóvel , associada a
Inquilino através do relacionamento Aluga . Um inquilino pode alugar quantos imóveis
quiser, e um imóvel pode ser alugado por um inquilino. Ou, o imóvel pode estar desocupado,
momentaneamente. O projeto do relacionamento como 1 N obriga a que cada imóvel tenha
um inquilino. Este fato tem implicações na implementação do banco de dados. Vamos
permitir, então, que a classe do relacionamento seja expressa como 0.1:N, quando o lado 1
não for obrigatório.

4.6.4.2. Agregação
Uma limitação do modelo ER é que os relacionamentos acontecer entre entidades. Acontece,
porém, que às vezes é preciso construir um relacionamento envolvendo algum relacionamento
na associação. Aí precisamos utilizar um novo conceito de agregação. Vejamos o exemplo de
um projeto de banco de dados em evolução, conforme a figura 9, associamos Cliente a
Vendedor através do relacionamento venda. Uma venda, no entanto, costuma estar associada
a vários produtos. Seria necessário, então, associar a venda, através de um relacionamento
Item de venda, uma série de ocorrências da entidade Produto.

4.6.4.3. Generalização/Especialização
Relacionamentos de generalização-especialização ocorrem entre entidades com atributos
globais e entidades especializadas a partir destas, com atributos específicos. Este
relacionamento, também conhecido como “is-a” (“é-um”), e pode ser representado na notação
mostrada na figura 13. Na mesma figura, apresentamos a maneira de representar este tipo de
associação usando

4.7. Formas Normais

Como mencionado anteriormente, temos conjuntos de regras para determinar com qual forma
normal o banco é compatível. Primeiramente, precisamos verificar se encontramos
compatibilidade com a primeira forma normal. Caso esteja tudo conforme, analisamos se a
segunda forma normal se encaixa e assim sucessivamente.
 20

É importante lembrar que para uma relação atender as exigências de uma forma normal, se faz
necessário que esta obedeça as regras da forma normal anterior. A primeira forma normal é
exceção pois não existe uma forma normal anterior a primeira.

4.7.1. Normalização

Normalização é o processo de modelar o banco de dados projetando a forma como as

informações serão armazenadas a fim de eliminar, ou pelo menos minimizar, a redundância no
banco. Tal procedimento é feito a partir da identificação de uma anomalia em uma relação,
decompondo-as em relações melhor estruturadas.

Normalmente precisaram remover uma ou mais colunas da tabela, dependendo da anomalia

identificada e criar uma segunda tabela, obviamente com suas próprias chaves primárias e
relacionarmos a primeira com a segunda para assim tentarmos evitar a redundância de
informações.

O processo de normalização compreende o uso de um conjunto de regras, chamados de formas

normais. Ao analisarmos o banco de dados e verificarmos que ele respeita as regras da
primeira forma normal, então podemos dizer que o banco está na “primeira forma normal”.
Caso o banco respeite as primeiras três regras, então ele está na “terceira forma normal”.
Mesmo existindo mais conjuntos de regras para outros níveis de normalização, a terceira forma
normal é considerada o nível mínimo necessário para grande parte das aplicações. [Microsoft
2007]

Um banco de dados dentro dos padrões de normalização reduz o trabalho de manutenção e

ajuda a evitar o desperdício do espaço de armazenamento. Se tivermos cadastrado no banco
um cliente e tivermos o seu telefone registrado em mais de uma tabela, havendo uma alteração
no seu número de telefone, teremos que fazer essa atualização em cada tabela. A tarefa se torna
muito mais eficiente se tivermos seu telefone registrado em apenas uma tabela.

Os próximos parágrafos demonstram melhor as anomalias no banco de dados e as diferentes

regras de normalização, bem como a forma de aplicá-las para estruturarmos o banco de dados
da melhor maneira possível.
 21

4.7.2. Formas normais

Codd definiu 3 formas normais, conhecidas por:

 1ª Forma Normal (1FN)

 2ª Forma Normal (2FN)
 3ª Forma Normal (3FN)
 4 ª forma normal (4FN)

4.7.2.1. Primeira Forma Normal

Uma relação está na primeira forma normal quando todos os atributos contêm apenas um valor
correspondente, singular e não existem grupos de atributos repetidos, ou seja, não admite
repetições ou campos que tenham mais que um valor.

O procedimento inicial é identificar a chave primária da tabela. Após, devemos reconhecer o

grupo repetitivo e removê-lo da entidade. Em seguida, criamos uma nova tabela com a chave
primária da tabela anterior e o grupo repetitivo.
4.7.2.2. Problemas das Tabelas na 1FN

As tabelas normalizadas apenas na 1FN podem apresentar problemas de redundância de

informação, bem como outros tipos de problemas ou anomalias, nomeadamente:

 Anomalias de inserção: em certas situações, a inserção de um novo registo pode

implicar um ou mais campos em branco; por exemplo, se quisermos registar um novo
cliente sem que, nesse momento, ele tenha feito qualquer encomenda, vários campos
ficariam vazios.
 Anomalias de atualização: dado que numa tabela pode existir repetição de informação
sobre um mesmo elemento, se quisermos atualizar um dado relativo a um determinado
elemento (por exemplo a morada de um cliente), teremos de efetuar tantas atualizações
quantas as vezes que esse elemento aparecer na tabela.
 Anomalias de eliminação: pela mesma razão anteriormente apontada, ou seja, a
possibilidade de existir informação repetida sobre um mesmo elemento, se quisermos
apagar um determinado elemento da nossa base de dados, teremos de o fazer a todos
os registos em que ele figurar.
 22

4.7.2.3. Segunda Forma Normal

É dito que uma tabela está na segunda forma normal se ela atende a todos os requisitos da
primeira forma normal e se os registros na tabela, que não são chaves, dependam da chave
primária em sua totalidade e não apenas parte dela. A segunda forma normal trabalha com
essas irregularidades e previne que haja redundância no banco de dados.

Para isso, devemos localizar os valores que dependem parcialmente da chave primária e criar
tabelas separadas para conjuntos de valores que se aplicam a vários registros e relacionar estas
tabelas com uma chave estrangeira.
4.7.2.4. Terceira Forma Normal

Se analisarmos uma tupla e não encontrarmos um atributo não chave dependente de outro

atributo não chave, podemos dizer que a entidade em questão está na terceira forma normal -
contanto que esta não vá de encontro as especificações da primeira e da segunda forma normal.

Como procedimento principal para configurar uma entidade que atenda as regras da terceira
forma normal, nós identificamos os campos que não dependem da chave primária e dependem
de um outro campo não chave. Após, separamos eles para criar uma outra tabela distinta, se
necessário.
4.7.2.5. Quarta Forma Normal

Uma entidade está na quarta forma normal quando ela estiver na terceira forma normal e não
existir dependências multivaloradas entre seus atributos, ou seja, campos que se repetem em
relação a chave primária, gerando redundância nas tuplas da entidade. Devemos fragmentar
essa relação com o objetivo de não termos mais essas dependências funcionais do gênero.

Em outras palavras, quando houver repetição de dois ou mais atributos não chave, gerando
uma redundância desnecessária na tabela, dividimos essa tabela em dois ou mais subgrupos
evitando assim o problema da redundância. [Silva 2010]
 23

5. Conclusão

Bancos de Dados (BD) é uma área da computação que apresentou grande desenvolvimento nas
décadas de 70 e 80 e contínua em ritmo acelerado de pesquisa e desenvolvimento. Com as
bases teóricas da tecnologia relacional lançadas na década de 70 e o lançamento comercial de
muitos Sistemas Gerenciadores de Banco de Dados (SGBDs) relacionais na década de 80, o
gerenciamento de grandes volumes de dados pode ser feito cada vez mais de forma segura,
eficiente e barata.

Dessa forma, a pessoa que vai analisar a documentação de uma modelagem normalizada
consegue abstrair com mais clareza, pois uma vez conhecendo os padrões, a compreensão é
facilitada e agiliza todo o trabalho. Como desvantagem podemos citar o aumento do número de
tabelas. Bancos devidamente construídos, ou seja, na terceira forma normal, apresentam um
número maior de tabelas em comparação aos bancos não normalizados. Assim, as consultas
em bancos com mais tabelas requerem uma complexidade maior na elaboração do SQL,
fazendo necessário o uso dos Joins e cláusulas para elaborarmos a consulta adequadamente.

Dado o exposto, a aplicação das regras de normalização de dados é altamente recomendada,

pois os ganhos são consideravelmente relevantes. Investir um pouco mais de dedicação e
tempo trabalhando com um número maior de tabelas trás mais benefícios do que um banco de
dados sem a devida organização.
 24

6. Bibliografia

 CALÇADO, Bruno. Normalização de Banco de Dados. 2010.

 CONTRIBUIDORES DA WIKIPÉDIA. Normalização de dados. Wikipédia, a
enciclopédia livre. 2020.
 MICROSOFT. Descrição dos conceitos de normalização banco de dados básicos. 2007.
Disponível em: <http://support.microsoft.com/kb/283878/pt-br>. Acesso em: 20 jul.
2011.
 SILVA, Eduardo. Banco de Dados, Aula 10. Normalização de Dados. 2010. Disponível
em: <http://www.conekti.com/site/index.php/apostilas/>. Acesso em: 20 jul. 2011.
 SILBERSCHATZ, Abraham; Korth, Henry; Sudarshan, S. Sistema de Banco de Dados.
5. ed. Rio de Janeiro. Elsevier, 2006. 781p.