Modelagem-e-Projeto-de-Banco-de-Dados-Relacionais---eBook

Prévia do material em texto

‘ 
1 
 
 
‘ 
2 
 
Sumário 
APRESENTAÇÃO .................................................................................................................. 4 
Modelagem e Projeto de Banco de Dados Relacionais ................................................... 4 
UNIDADE I ............................................................................................................................... 6 
Projeto de Banco de Dados .............................................................................................. 6 
Modelo Conceitual .............................................................................................................. 9 
Modelo Conceitual como Modelo de Organização ...................................................... 11 
Modelo Lógico ................................................................................................................... 12 
Modelo Físico .................................................................................................................... 14 
UNIDADE II ............................................................................................................................ 17 
Abordagem Entidade Relacionamento .......................................................................... 17 
Propriedades do Modelo ER ........................................................................................... 20 
Entidades ........................................................................................................................... 21 
Relacionamentos .............................................................................................................. 23 
Atributos ............................................................................................................................. 24 
Estratégias de Modelagem.............................................................................................. 26 
Práticas desta Abordagem .............................................................................................. 27 
Partindo de Descrições de Dados Existentes .............................................................. 27 
Partindo do Conhecimento das Pessoas ...................................................................... 28 
Estratégia "top-down" ....................................................................................................... 28 
Estratégia "inside-out" ...................................................................................................... 30 
UNIDADE III ........................................................................................................................... 32 
Modelo Lógico ................................................................................................................... 32 
Abordagem Relacional ..................................................................................................... 36 
Composição de um Banco de Dados ............................................................................ 37 
Tabelas ............................................................................................................................... 37 
As Chaves .......................................................................................................................... 40 
Chave Primária ................................................................................................................. 40 
Chave Alternativa ............................................................................................................. 41 
Chave Estrangeira ............................................................................................................ 42 
Técnica de Transformação entre o Modelo ER e o Modelo Relacional ................... 44 
Refinamento do Modelo Relacional ............................................................................... 58 
Práticas desta Transformação ........................................................................................ 59 
UNIDADE IV .......................................................................................................................... 63 
‘ 
3 
 
Normalização de Banco de Dados ................................................................................ 63 
Conceituação..................................................................................................................... 64 
Aninhamento de Tabelas ................................................................................................. 65 
Praticando a Normalização ............................................................................................. 67 
Regra da Primeira Forma Normal (1FN) ....................................................................... 67 
Dependência Funcional ................................................................................................... 71 
Regra da Segunda Forma Normal (2FN) ...................................................................... 74 
Regra da Terceira Forma Normal (3FN) ....................................................................... 78 
Regra da Quarta Forma Normal (4FN) ......................................................................... 80 
Regra da Quinta Forma Normal (5FN) .......................................................................... 84 
Ferramenta Case para Modelagem ............................................................................... 86 
Modelando dados através de uma ferramenta CASE ................................................ 86 
BrModelo ............................................................................................................................ 87 
UNIDADE V ......................................................................................................................... 92 
Boas Práticas de Administração de Banco de Dados ................................................ 92 
Tuning de Banco de Dados ............................................................................................. 94 
DAMA e Data Governance .............................................................................................. 98 
GOVERNANÇA DE DADOS ......................................................................................... 101 
Agile Database Project .................................................................................................. 104 
DBAs ágeis ...................................................................................................................... 106 
O PAPEL DO DBA ÁGIL ............................................................................................... 106 
Banco de dados distribuídos ......................................................................................... 108 
CONCLUSÃO ...................................................................................................................... 112 
 
 
‘ 
4 
 
APRESENTAÇÃO 
Modelagem e Projeto de Banco de 
Dados Relacionais 
Professor Me. Ricardo Bortolo Vieira 
Olá prezados(as) alunos(as), sejam bem vindos ao livro Modelagem e Projeto 
de Banco de Dados Relacionais. Sou o professor Ricardo Vieira, autor deste 
material. O assunto que abordarei no decorrer do nosso estudo será a base 
para seus estudos mais aprofundados sobre Banco de Dados, sejam eles mais 
gerais como em bancos comerciais como Oracle e SQL SERVER, como 
também para bancos de dados mais específicos como MongoDB, Cassandra, 
Redis e ZopeDB. 
Meu objetivo, por meio deste livro, é ensiná-los os conceitos básicos de 
gerenciamento de banco de dados e as modelagens mais conhecidas para 
poder auxiliá-los nas modelagens de projetos de banco de dados de seus 
projetos empresariais e pessoais. 
Então meu amigo(a), acompanhar e dominar as boas práticas de projetos de 
banco de dados não é mais um diferencial, mas sim a base para estudos maisavançados dentro deste conceito indispensável no desenvolvimento de 
software que é o armazenamento e recuperação de dados. 
Este livro está organizado em quatro unidades, além da apresentação e 
conclusão, cada uma delas correspondendo a uma das partes importante na 
modelagem de banco de dados. 
A primeira unidade trata sobre o projeto de banco de dados e as várias 
camadas existente entre a fase de idealização e modelagem até o 
desenvolvimento físico das estruturas básicas do banco de dados. 
Na segunda unidade é apresentado a abordagem Entidade Relacional 
(abordagem ER) que é um tipo de abordagem para o modelo conceitual. Além 
‘ 
5 
 
disso, nesta unidade será detalhado as propriedade e características dessa 
abordagem tão aceita e utilizada entre os analistas. 
Na terceira unidade é discutido a abordagem Relacional, que é um abordagem 
do modelo lógico. Ainda nesta unidade será apresentado as técnicas para 
conversão da abordagem ER para a abordagem Relacional e as tomadas de 
decisão dentro deste processo de transformação. 
Na quarta unidade abordaremos o processo de normalização, que é utilizado, 
entre outras necessidade, para o processo de engenharia reversa quando já 
temos um sistema funcionando, porém sem documentação de banco de 
usuário. Estudaremos também nesta unidade as ferramentas CASE que 
apoiam o processo de modelagem de um projeto de banco de dados. Por 
último, mas não menos importante, na quinta unidade trataremos sobre boas 
práticas no gerenciamento de banco de dados, Otimização e Tuning, Data 
Governance e muito mais. 
Este livro foi criado especialmente para você, caro(a) aluno(a). Se aprofunde 
nos conteúdos, reflita sobre os assuntos relacionados, estude as propostas de 
leituras complementares e não pare de estudar, este assunto é muito vasto e 
novamente reforço que este é um assunto básico para estudos mais 
detalhados e avançados dentro do vasto conceito de banco de dados. Assim, 
quanto mais estudamos, mais teremos possibilidade de avançar para 
conteúdos mais abrangentes. Desejo uma excelente caminhada em busca do 
conhecimento e muita humildade nesse processo. 
Agora, mãos à obra! Tenha uma boa e agradável leitura! 
 
 
 
 
 
‘ 
6 
 
UNIDADE I 
 
https://blog.4linux.com.br/wp-content/uploads/2018/03/Banco-de-Dados-NoSQL.jpg 
Projeto de Banco de Dados 
Criou-se durante muito tempo, a ideia de que projetar bancos de dados era 
uma disciplina com identidade própria, uma atividade específica e até certo 
ponto isolada no ciclo de vida de um sistema, que tinha existência própria e 
podia ser realizada a partir de primitivas e conceitos exclusivos da técnica de 
modelagem de dados. 
Com a evolução das tecnologias de desenvolvimento de aplicações, 
juntamente com as novas linguagens e principalmente com o advento da 
Orientação a Objetos, não ficaram mais restritas ao ambiente de programação, 
mas extensiva às metodologias de análises de sistemas, o trabalho de projetar 
as bases de dados que serão utilizadas por um sistema em desenvolvimento, 
assumem, nos dias de hoje, características que objetivam mixar um projeto 
Orientado a Objetos, com as necessidades desse mesmo sistema interagir 
com um Banco de Dados Relacional, constituído por um conjunto de tabelas, 
que equivale à denominada camada de persistência de dados. 
Essa necessidade de mixagem é real, pela absoluta ausência de projetos 
comerciais, que utilizem Bancos de Dados Orientados a Objetos que sejam 
confiáveis às grandes massas de dados, a não popularização desses produtos 
‘ 
7 
 
e aos grandes investimentos já realizados em softwares de Sistemas 
Gerenciadores de Bancos de Dados Relacionais (SGBDs Relacionais) 
existentes no mercado nacional e mundial. 
A vantagem obtida é indiscutível, em um projeto orientado a objetos, logo, 
surge à necessidade de uma nova técnica de projeto para banco de dados, 
que não é a formatação pura de classes de dados, mas uma interação alta 
entre o ambiente de análise orientada a objetos e a nossa modelagem de 
dados, que é estritamente necessária à administração de dados da 
organização de TI. A utilização de ferramentas para a camada de persistência 
tais como o Hybernate, acaba levando o desenvolvedor a deixar de lado a 
preocupação com as estruturas do banco de dados, assim como a 
preocupação com a qualidade das queries realizadas em uma aplicação. 
Não existem técnicas e nem ferramentas que possibilitem tanto ao 
Administrador de Dados (Data Administrator - DA) quanto ao Administrador de 
Bancos de Dados (Data Base Administrator - DBA) realizarem suas funções 
sobre classes de dados, pois esses mesmos bancos de dados relacionais 
atuam e têm todas as suas funcionalidades sobre tabelas relacionais de dados, 
às quais são hoje de domínio maior dos usuários de aplicações. 
Há muito tempo tem se escrito sobre modelagem de dados e o processo 
continua existindo como sempre existiu. Para que alcancemos com êxito os 
objetivos de um SGBD, torna-se imprescindível obtermos uma estrutura de 
dados adequada e bem definida, bem como, escolher um modelo de dados 
para ser implementado pelo banco de dados. 
Quando iniciamos a constituição de um projeto de banco de dados, 
normalmente, torna-se necessário basear-se em uma visão abstrata do 
cenário, o que é considerada também como processo de abstração do 
minimundo, inserindo detalhes à medida que o projeto decorre. Essa maneira 
de utilizar níveis de abstração de dados promove facilidade para que 
possamos agrupar as diversas visões de dados existentes dentro das 
organizações empresariais. 
‘ 
8 
 
Como exemplo, podemos considerar que visão de dados abstraída pela 
diretoria é plenamente distinta da visão de dados dos funcionários vinculados 
à produção. Esse detalhe, sem dúvida, deverá ser considerado na fase de 
projetar o banco de dados de uma organização qualquer, independentemente, 
da sua área de atuação. Por isso que, o Comitê de Planejamento e Exigência 
de Padrões (SPARC) do Instituto Nacional Americano de Padrões (ANSI), em 
meados de 1970, elaborou uma estrutura cujo objetivo era auxiliar a fase de 
modelagem de banco de dados baseando-se em diversos níveis de abstração 
de dados. A arquitetura (ANSI/SPARC) considera apenas três níveis de 
abstração de dados, o externo, conceitual e interno. 
Para que você entenda melhor as hierarquias dos modelos de dados, visualize 
adequadamente a Figura 01, ora adaptada, incluindo o Modelo Físico, o qual 
lida explicitamente com os detalhes referente ao modelo interno em seu nível 
físico. 
 
Figura 01. Níveis de Abstração de Dados. Elaborado pelo autor. 
 
Você pode perceber que a visão do usuário final, isso é, do Modelo Externo, 
constitui por sua vez, o Modelo Conceitual, ou seja, o modelo de dados em que 
a grande maioria dos projetistas de dados se baseia para a elaboração de 
‘ 
9 
 
qualquer projeto de banco de dados, independentemente de sua 
complexidade. É importante mencionar que o nível de abstração (Modelo 
Externo/Conceitual) é independente de hardware e software (SGBD). 
Entretanto, o próximo nível, o Modelo Lógico, ao contrário do Modelo 
Conceitual, depende do software (SGBD), todavia, também não considera o 
hardware. Para finalizar, nosso último modelo, este intitulado de Modelo 
Interno (Modelo Físico), depende de maneira exclusiva do software (SGBD) e 
hardware. 
 
 
 
 
 
 
Modelo Conceitual 
 
 
Um Modelo Conceitual é uma descrição do banco de dados de forma 
independente de implementação em um SGBD. O modelo conceitual registra 
quais dados podem aparecer no banco de dados, mas não registra como estes 
dados estão armazenados ao nível de SGBD. 
‘ 
10 
 
Quando falamos em Modelo Conceitual, estamos nos referindo àquela que 
deve ser sempre a primeira etapa de um projeto de banco de dados. 
O objetivo do Modelo Conceitual é descrever de forma simples e facilmente 
compreendida pelo usuáriofinal as informações de um contexto de negócios, 
as quais devem ser armazenadas em um banco de dados. É uma descrição 
de alto nível (macro definição), mas que tem a preocupação de captar e retratar 
toda a realidade de uma organização, processo de negócio, setor, repartição, 
departamento etc. 
É importante destacar que o Modelo Conceitual não retrata e nem é vinculado 
aos aspectos ligados à abordagem do banco de dados que será utilizado, 
tampouco se preocupa com as formas de acesso ou estruturas físicas 
implementadas por um SGBD específico. Sem o Modelo Conceitual não temos 
uma visão clara das regras do negócio e acabamos por criar aplicações sem 
entender para que elas foram criadas. 
O resultado de um Modelo Conceitual é um esquema gráfico que representa 
a realidade das informações existentes em determinado contexto de negócios, 
assim como as estruturas de dados em que estão organizadas essas 
informações. O Modelo Conceitual nunca deve ser construído com 
considerações sobre processos de negócio, com preocupações de acesso aos 
dados, não devendo existir nenhuma preocupação com o modo como serão 
realizadas as operações de consulta e manutenção dos dados nele 
apresentados. O foco deve ser dirigido sempre ao entendimento e à 
representação de uma realidade, de um contexto. 
A técnica mais difundida de Modelo Conceitual é a abordagem entidade-
relacionamento (ER). Nesta técnica, um Modelo Conceitual é usualmente 
representado através de um diagrama, chamado diagrama entidade-
relacionamento (DER). A Figura 02 apresenta um DER parcial. 
 
‘ 
11 
 
 
Figura 02. Exemplo de Modelo Conceitual. Elaborado pelo autor. 
 
Entre outras coisas, este modelo informa que o banco de dados contém dados 
sobre produtos e sobre tipos de produtos. Para cada produto, o banco de 
dados armazena o código, a descrição, o preço, bem como o tipo de produto 
ao qual está associado. Para cada tipo de produto, o banco de dados 
armazena o código, a descrição, bem como os produtos daquele tipo. 
 
 
 
 
 
Modelo Conceitual como Modelo de Organização 
 
Quando se observa um conjunto de arquivos em um computador, sejam eles 
gerenciados por um SGBD, sejam eles arquivos convencionais, verifica-se que 
usualmente um arquivo contém informações sobre um conjunto de objetos ou 
entidades da organização que é atendida pelo sistema em um computador. 
Assim, se considerarmos um exemplo de uma indústria, um sistema em um 
computador provavelmente conteria um arquivo para armazenar dados de 
produtos, outro para armazenar dados de vendas, outro para armazenar dados 
de ordens de compra e assim por diante. 
Desta constatação surgiu uma das idéias fundamentais do projeto de banco 
de dados: a de que através da identificação das entidades que terão 
informações representadas no banco de dados, é possível identificar os 
arquivos que comporão o banco de dados. Devido a esta relação um-para-um 
entre arquivos em computador e entidades da organização modelada, 
‘ 
12 
 
observou-se que um mesmo modelo conceitual pode ser usado em duas 
funções: 
● Como Modelo Abstrato da organização, que define as entidades da 
organização que tem informações armazenadas no banco de dados. 
● Como Modelo Abstrato do banco de dados, que define que arquivos 
farão parte do banco de dados. 
Exemplificando, se considerarmos o modelo da Figura 02, podemos interpretá-
lo de duas formas. Em uma interpretação, como modelo abstrato da 
organização, o diagrama nos informa que na organização há produtos e tipos 
de produtos, que associado a cada tipo de produto há um código do tipo e uma 
descrição e assim por diante. Na outra interpretação, como modelo abstrato de 
um banco de dados, o diagrama nos informa que o banco de dados deverá 
conter informações sobre produtos e tipos de produtos, que para cada tipo de 
produto são armazenados seus códigos e sua descrição e assim por diante. 
Na prática, convencionou-se iniciar o processo de construção de um novo 
banco de dados com a construção de um modelo dos objetos da organização 
que será atendida pelo banco de dados, ao invés de partir diretamente para o 
projeto do banco de dados. Esta forma de proceder permite envolver o usuário 
na especificação do banco de dados. Sabe-se que, na prática da engenharia 
de software, o envolvimento do usuário na especificação do software aumenta 
a qualidade do software produzido. A idéia é que o usuário é aquele que melhor 
conhece a organização e, portanto, aquele que melhor conhece os requisitos 
que o software deve preencher. Modelos conceituais são modelos que 
descrevem a organização, portanto, são mais simples de compreender por 
usuários leigos em Informática, que modelos que envolvem detalhes de 
implementação. 
 
Modelo Lógico 
 
‘ 
13 
 
 
https://becode.com.br/wp-content/uploads/2017/01/Banco-de-Dados.jpg 
 
Um Modelo Lógico é uma descrição de um banco de dados no nível de 
abstração visto pelo usuário do SGBD. Assim, o Modelo Lógico é dependente 
do tipo particular de SGBD que está sendo usado. No presente livro, serão 
tratados apenas modelos lógicos referentes a SGBD relacional. Em um SGBD 
relacional, os dados estão organizados na forma de tabelas. A Figura 03 
mostra um exemplo de BD relacional projetado a partir do Modelo Conceitual 
mostrado na Figura 02. Um Modelo Lógico para o BD deve definir quais as 
tabelas que o banco contém e para cada tabela, quais os nomes das colunas. 
Abaixo é apresentado o Modelo Lógico (de forma textual) da Figura 03: 
TipoDeProduto(CodTipoProd,DescrTipoProd) 
Produto(CodProd,DescrProd,PrecoProd,CodTipoProd) 
CodTipoProd referencia TipoDeProduto 
 
Figura 03. Exemplo de tabelas de banco de dados Relacional. Elaborado pelo autor. 
 
O Modelo Lógico como já foi dito anteriormente, descreve a estrutura do banco 
de dados, conforme vista pelo usuário do SGBD. Detalhes de armazenamento 
‘ 
14 
 
interno de informações, que não tem influência sobre a programação de 
aplicações no SGBD, mas podem influenciar a performance das aplicações, 
por exemplo, as estruturas de arquivos usadas no acesso as informações, não 
fazem parte do modelo lógico. Estas são representadas no modelo físico. 
Modelos Físicos serão tratados em unidades posteriores neste livro. 
 
Modelo Físico 
 
Eles são usados apenas por profissionais que fazem sintonia de banco de 
dados, procurando otimizar a performance. As linguagens e notações para o 
modelo físico não são padronizadas e variam de produto a produto. A 
tendência em produtos mais modernos é esconder o modelo físico do usuário 
e transferir a tarefa de otimização ao próprio SGBD. 
Esse modelo é conhecido por trabalhar com o nível mais baixo de abstração, 
apresentando de maneira detalhada como os dados são efetivamente 
gravados em um dispositivo de armazenamento qualquer (disco rígido, fitas 
magnéticas, etc.). O modelo físico depende exclusivamente do SGBD 
(software) e do hardware, sobretudo por precisar conhecer previamente os 
dispositivos físicos que serão utilizados para o armazenamento dos dados, 
principalmente, os métodos que proverão acesso aos mesmos. 
O DBA (Administrador de Banco de Dados) e ou projetista de dados não 
precisam se preocupar com os detalhes em nível do armazenamento físico, 
entretanto, precisam conhecer minuciosamente como realizar a sintonização 
(tuning) a fim de incrementar a performance, principalmente quando utilizamos 
o modelo de dados relacional. Quando for necessário aplicar qualquer tipo de 
alteração no modelo físico sem precisar refletir a alteração/modificação no 
modelo interno, obtemos o que caracterizamos de independência física de 
dados. 
O modelo físico será construído a partir do modelo lógico e descreve as 
estruturas físicas de armazenamento de dados, tais como: 
● Tipo e tamanho de campos; 
● Índices; 
‘ 
15 
 
● Domínio de preenchimento desses campos; 
● Nomenclaturas; 
● Exigênciade conteúdo; 
● Gatilhos etc. 
Elas são projetadas de acordo com os requisitos de processamento e uso mais 
econômico dos recursos computacionais. Esse modelo detalha o estudo dos 
métodos de acesso do SGBD para criação dos índices necessários para cada 
informação colocada nos modelos conceitual e lógico. 
O modelo físico é aquele que se preocupa com a descrição dos dados no nível 
mais baixo, se preocupam com detalhes de como são armazenados os dados. 
Ao contrário dos modelos lógicos, há poucos modelos físicos em uso. Dois 
deles são amplamente conhecidos: o modelo unificado (unifying model) e o 
modelo de partição de memória (frame memory model). 
 
Figura 04. Exemplo de modelo unificado. Elaborado pelo autor. 
Esta é a etapa final do projeto de banco de dados, na qual será utilizada a 
linguagem de definição de dados do SGBD (Data Definition Language - DDL) 
para a realização da sua montagem no dicionário de dados. Em ambiente de 
banco de dados relacional denominamos script de criação do banco de dados 
o conjunto de comandos em SQL (DDL) que será executado no Sistema 
Gerenciador de Banco de Dados para a criação de banco de dados 
correspondente ao modelo físico. 
A seguir apresentamos um exemplo de script (conjunto de comando DDL) 
escrito em SQL para criação de um pequeno banco de dados: 
‘ 
16 
 
 
Figura 05. Exemplo de script (conjunto de comando DDL) em SQL. Elaborado pelo autor. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
‘ 
17 
 
UNIDADE II 
 
http://www.aster.com.br/wp-content/uploads/2015/10/7-beneficios-que-a-terceirizacao-de-servicos-traz-
para-sua-empresa-e1487861554873.jpg 
 
Abordagem Entidade Relacionamento 
 
A técnica de modelagem de dados mais difundida e utilizada é a abordagem 
entidade-relacionamento (ER). Nesta técnica, o modelo de dados é 
representado através de um modelo entidade-relacionamento (modelo ER). 
Usualmente, um modelo ER é representado graficamente, através de um 
diagrama entidade-relacionamento (DER). 
O modelo Entidade-Relacionamento (ER) foi definido por Peter Pin-Shan 
Chen, em 1976, e baseia-se na percepção do mundo real como constituído por 
um conjunto de objetos básicos chamados entidades e relacionamentos e 
define uma técnica de diagramação para modelos de dados, o diagrama de 
entidades e relacionamentos (DER). Ela pode ser considerada como um 
padrão de fato para Modelagem Conceitual. Mesmo as técnicas de modelagem 
orientada a objetos que têm surgido nos últimos anos baseiam-se nos 
conceitos da abordagem ER. 
Segundo Peter Chen, um Modelo Entidade-Relacionamento é constituído por 
uma notação, ora formada por entidades (graficamente representado por 
retângulos), relacionamentos (graficamente representado por losango), 
atributos, que compõe as características das entidades, e ou, relacionamentos 
(esse, graficamente representado pelo emprego de círculos) e, por fim, linhas 
que realizam a conexão indicando por sua vez a cardinalidade (multiplicidade) 
‘ 
18 
 
de uma entidade ou mais, aplicado a um relacionamento qualquer. Essas 
conexões são graficamente representadas pelo uso de linhas. 
Apesar de ser uma forma gráfica de representar um banco de dados relacional, 
o modelo ER possui um elevado grau de semântica, que o torna mais simples, 
além de permitir uma comunicação mais otimizada entre os usuários e os 
profissionais de informática e desenvolvedores de sistemas como mostra a 
Figura 06. 
 
Figura 06. Representação do Modelo Conceitual por meio de um DER. Elaborado pelo autor. 
 
Dentro do que utilizamos como método de desenvolvimento podemos tanto 
iniciar a análise por modelagem de eventos ou casos de uso quanto por 
modelagem de dados para depois, com as entidades definidas, analisarmos 
os eventos que existem relativos a cada um desses objetos. 
A própria UML prega a utilização da criação dos diagramas de casos de uso 
como primeira etapa de um processo metodológico de desenvolvimento de 
aplicações. Porém, é um cacoete derivado dos conceitos de análise 
estruturada e análise essencial, em que destaque e importância maior sempre 
foram dados aos processos e não aos dados. 
Devemos sempre lembrar que dados são sempre mais estáveis que 
processos. Observe que podemos mudar completamente um processo de 
faturamento, mas os dados relativos ao faturamento continuaram estáveis. Na 
pior das hipóteses esses dados seriam reduzidos, mas não haveria uma 
mudança completa dos dados utilizados para esse processo. 
Os diagramas de caso de uso fornecem um modo de descrever a visão externa 
do sistema e suas interações com o mundo exterior, representando uma visão 
de alto nível de funcionalidade intencional mediante o recebimento de um tipo 
‘ 
19 
 
de requisição de usuário. Entretanto, no caso de iniciarmos um 
desenvolvimento pela especificação de casos de uso, podem conduzir-nos à 
criação de classes de dados redundantes ou não aderentes ao mundo real, o 
que obtemos sempre quando trabalhamos com modelagem de dados pura. 
Já a modelagem de dados pode permitir a criação mais concisa de modelo de 
classes, já que um modelo de dados retrata com maior fidelidade uma 
realidade, ou seja, o mundo real. A estabilidade do modelo de dados é obtida 
quando se investe quantidade de tempo nos aspectos conceituais de 
modelagem de dados, revertendo esse tempo em benefícios consideráveis 
durante a implementação da base de dados. 
A técnica de modelagem Entidade-Relacionamento proposta por Peter Chen 
está definida como uma notação orientada para o desenho de um modelo 
conceitual, pois permite a descrição desse esquema conceitual sem 
preocupação com problemas de implementação física ou de performance do 
banco de dados. 
O diagrama Entidade-Relacionamento descreve a estrutura conceitual e lógica 
geral de um banco de dados. Observa-se então que o objetivo da modelagem 
de dados é definir o contexto dos dados em que os sistemas funcionam. Por 
isso, o produto da modelagem de dados deve ser o mais fiel possível ao mundo 
real e, além disso, possuir uma característica adicional muito importante: as 
suas especificações não devem implicar e tampouco estarem limitadas a 
nenhuma implementação física em particular. Tudo aquilo que for proposto 
pela modelagem de dados deve ocorrer num nível conceitual e lógico, de 
maneira a não viciar a análise pela restrição de pontos de vista técnicos da 
equipe de participantes do processo de análise. Os detalhes físicos vêm 
depois. 
A abordagem de sistemas para bancos de dados relacionais tem como 
principal característica o alto nível em que ocorrem as definições necessárias 
à implantação de uma base de dados. Assim, a qualidade de um projeto como 
um todo é muito dependente da qualidade da modelagem de dados que o 
antecede. 
‘ 
20 
 
É muito importante então que exista uma metodologia simples, precisa e 
eficiente para a representação dos objetos modelados pelo analista e que 
também seja de fácil transposição para os diversos SGBD disponíveis. É isso 
que se obtém com a utilização do modelo ER proposto por Peter Chen. 
 
Propriedades do Modelo ER 
 
 
https://image.freepik.com/vector-gratis/mano-gestion-relaciones-presentacion-al-cliente_1325-26.jpg 
 
Um modelo de dados ER é composto de três classes de objetos: 
● Entidades 
● Relacionamentos 
● Atributos 
As técnicas orientadas a objetos baseiam-se na análise dos procedimentos, e 
com enfoque principalmente direcionado aos casos de uso (use case) e em 
diagramas de classes excessivamente preocupados em retratar não só dados 
e sim processos em conjunto, ou nos casos de análise essencial em diagramas 
de fluxo de dados, o que provoca uma derivação de foco e possibilita uma larga 
margem de erro de conceituação do mundo real. Essas técnicas estruturadas 
colocam as informações derivadas dos procedimentos em classes de dados 
(OO) ou depósitos de dados, as quais sintetizando-se finalmenteacabam 
sendo convertidas em tabelas de um sistema, pura e simplesmente. 
‘ 
21 
 
 
Figura 07. Exemplo de ER com as três classes de objetos: Entidades, Relacionamentos e os 
Atributos. Elaborado pelo autor. 
 
Entidades 
Correspondem a quaisquer coisas do mundo real sobre as quais se deseja 
armazenar informações. São exemplos típicos de entidades: pessoas (físicas 
ou jurídicas, tais como funcionário, empresa, fornecedor e cliente); objetos 
materiais ou abstratos, como produto, veículo, disciplina e projeto e evento ou 
fatos como pedido, viagem, empréstimo e venda principalmente. No modelo 
ER são representados por meio de um retângulo com o nome representativo 
da entidade (um substantivo no singular) ao centro. Uma entidade 
normalmente tem várias manifestações dela mesma. Por exemplo, a entidade 
funcionário representa todos os funcionários da empresa, e não apenas um 
deles; a entidade produto representa todos os produtos com os quais a 
empresa trabalha etc. 
 
Figura 08. Representação da classe Entidade do modelo ER. Elaborado pelo autor. 
Se fizermos uma comparação com a UML, funcionário é o um objeto, o 
conjunto dos objetos funcionários forma a classe de objetos funcionário, que é 
a nossa entidade. Então uma entidade corresponde a uma classe de objetos e 
as ocorrências desta entidade são os objetos funcionários. 
‘ 
22 
 
 
Figura 09. Representação de Diagramas de Classes UML de FUNCIONÁRIO e PRODUTO. 
Elaborado pelo autor. 
 
Dizemos então que uma entidade possui ocorrências ou instâncias, e cada um 
dos funcionários descritos pela entidade funcionário é uma de suas 
ocorrências, ou instâncias. 
● Entidade é a principal classe de objetos sobre a qual são coletadas 
informações. 
● Ela normalmente denota pessoa, lugar, coisa ou fato de interesse de 
informações. 
● É todo objeto concreto ou abstrato que tem existência própria, quando 
considerado o âmbito de um negócio. São coisas sobre as quais 
desejamos arquivar informações. 
● Define-se entidade como aquele objeto que existe no mundo real com 
uma identificação distinta e com um significado próprio. São as coisas 
que existem no negócio, ou ainda, descrevem o negócio em si. 
Quando analisamos um ambiente, tiramos uma fotografia dele que nos 
apresenta as entidades que participam, ou estão naquele ambiente. A 
representação gráfica de uma entidade em um diagrama ER, como já foi dito 
anteriormente, é realizada por meio de um retângulo com o nome da classe de 
dados inserido em seu interior conforme apresentado na Figura 09. 
Numa visão simplista, entidade é similar a um arquivo de um sistema 
convencional, e é natural fazer esta correspondência: um conjunto de 
ocorrências de uma entidade corresponde a um arquivo, e uma única 
ocorrência, que podemos denominar de linha, corresponde a um registro. 
 
‘ 
23 
 
Relacionamentos 
O uso do relacionamento nos permite realizar associações entre as entidades. 
Por exemplo, não basta simplesmente conhecermos os funcionários de uma 
determinada empresa. O projetista de dados deverá associar um funcionário a 
uma empresa, permitindo que seja possível alcançar algum tipo de informação 
mais elaborada. 
No diagrama entidade-relacionamento, um relacionamento é representado 
graficamente através do uso de um losango, ora conectado por meio de 
"linhas" as entidades (retângulos). A Figura 10 nos permite visualizar um 
exemplo de relacionamento, ora identificado de "TRABALHA", representando 
o vínculo existente entre as entidades FUNCIONÁRIO e EMPRESA. 
 
 
Figura 10. Exemplo de uso de relacionamento "TRABALHA". Elaborado pelo autor. 
 
Vamos agora analisar esse relacionamento, visualizado pela Figura 10, que 
estabelece uma associação entre as entidades FUNCIONÁRIO e EMPRESA. 
Ele nos permite referenciar as associações entre o conjunto de entidades. Isso 
é para o relacionamento "TRABALHA", uma ocorrência pode ser caracterizada 
como um par de ocorrências ora formada pelas ocorrências das entidades 
FUNCIONÁRIO e EMPRESA. 
Uma ocorrência em particular de um relacionamento é chamada de instância 
de relacionamento, ou ocorrência. Um relacionamento é descrito em termos de 
grau, cardinalidade e existência. O mais comum dos termos associados a um 
relacionamento é a indicação da cardinalidade entre as ocorrências das 
entidades relacionadas: um para um, um para muitos e muitos para muitos. 
Como cardinalidade é um termo que não explicita muita coisa, vamos utilizar a 
palavra conectividade porque acreditamos que entender o conceito de 
conexão é mais simples. Alguma coisa se conecta a outra. 
O nome do relacionamento normalmente é um verbo, pois é resultante de um 
‘ 
24 
 
fato que associa as entidades. Podemos dar dois nomes, digamos assim, a um 
relacionamento. Um verbo para explicar o fato no sentido da entidade A para 
a entidade B, e outro verbo no sentido da entidade B para a entidade A, uma 
vez que a leitura de um relacionamento não possui um lado específico do 
modelo para ser realizada. 
 
Figura 11. Exemplos de relacionamentos. Elaborados pelo autor. 
 
Entender relacionamentos e a capacidade de enxergar esses objetos, assim 
como a sua participação no mundo real, é fator primordial para o resultado de 
uma modelagem de dados com entendimento e retrato fiel do ambiente em 
análise. Não devemos ter antecipadamente medo da provável complexidade 
de uma técnica, pois essa nada mais é do que uma forma estruturada de 
representar as coisas que existem e ocorrem no mundo real, como sempre 
fizemos com papel e lápis desde a infância. 
 
 
Atributos 
No modelo Entidade-Relacionamento MER, é possível realizar a especificação 
de propriedades relacionadas às entidades. Essas propriedades são 
nomeadas de atributo. Um atributo promove mecanismos para que seja 
possível associar informações a ocorrências de entidades e ou 
relacionamentos. Resumidamente, um atributo tem como propósito vincular 
um determinado dado a cada ocorrência de uma entidade específica ou, 
eventualmente, até mesmo a um relacionamento. 
Após apresentarmos o conceito de um atributo, podemos estender nosso 
aprendizado sobre os vários tipos de atributos existentes, como também 
apresentar suas devidas utilização. Os detalhes são apresentados logo a 
‘ 
25 
 
seguir: 
● Atributo Simples: tipo de atributo que armazena um dado atômico, ou 
seja, um dado considerado indivisível; 
● Atributo Composto: considerado como sendo um tipo especial de 
atributo, pelo simples fato de permitir que sejam vinculados a ele 
diversos dados segmentados de forma isolada por meio de outros 
atributos. Similar ao atributo simples, um atributo composto também 
carece de que o dado seja atômico. Como exemplo, podemos 
mencionar o atributo endereço, pois, o mesmo possui vários dados, 
como tipo de logradouro, o próprio logradouro, número, complemento, 
bairro, cidade, CEP e estado; 
● Atributo Multivalorado: esse atributo permite armazenar vários dados 
para uma única entidade. Um exemplo clássico para o uso desse tipo 
de atributo é o número de telefone de uma determinada pessoa. 
Atualmente, uma pessoa pode ter dois ou mais números de telefones, 
por exemplo: telefone fixo e telefone celular de mais de uma operadora; 
● Atributo Derivado: o atributo derivado armazena um dado proveniente 
de um processamento específico. Por exemplo, o atributo idade de uma 
pessoa qualquer, pode ser obtido a partir do processamento da data de 
nascimento e data atual do aplicativo computacional; 
● Atributo Identificador: tipo de atributo imprescindível em uma 
entidade. Esse atributo permite que identifiquemos exclusivamente 
uma ocorrência dentre as demais ocorrências da mesma entidade. O 
atributo identificador aplicado a uma entidade qualquer pode ser um 
atributo simples ou composto. Por exemplo, suponha a existência de 
uma entidade chamada de Pessoa. Você consegue imaginar os 
possíveis atributosidentificadores que poderíamos utilizar para essa 
entidade? Como possíveis respostas, teríamos o número do CPF, RG 
ou um número identificador produzido automaticamente pelo banco de 
dados. 
‘ 
26 
 
 
Figura 12. Exemplos de Atributos. Elaborados pelo autor. 
 
 
Estratégias de Modelagem 
 
O processo de construção de um modelo é um processo incremental, isto é, 
um modelo de um sistema não é construído em um único passo, mas em 
muitos passos pequenos, muitas pequenas transformações do modelo inicial 
até o modelo completo. Gradativamente, o modelo vai sendo enriquecido com 
novos conceitos e estes vão sendo ligados aos existentes ou os existentes vão 
sendo aperfeiçoados. Uma estratégia de modelagem ER é uma sequência de 
passos (uma "receita de bolo") de transformação de modelos. Estudando o 
processo de construção de modelos ER, diferentes autores propuseram 
diferentes estratégias, que apresentamos abaixo. 
Na prática, observa-se que nenhuma das estratégias propostas na literatura é 
universalmente aceita. Normalmente, é aplicada uma combinação das 
diversas estratégias de modelagem. Isso é compreensível, se considerarmos 
que o processo de modelagem é um processo de aprendizagem. Quando 
construímos o modelo de um sistema, estamos aprendendo fatos sobre aquele 
sistema. A sequência de idéias que se tem durante um processo de 
aprendizagem é dificilmente controlável por uma estratégia. 
Para definir qual a estratégia a usar na construção de um modelo ER, deve-se 
identificar qual a fonte de informações principal para o processo de 
modelagem. São duas as fontes de informação que iremos considerar: 
descrições de dados existentes e o conhecimento que pessoas possuem sobre 
‘ 
27 
 
o sistema. 
 
 
 
 
 
 
 
 
 
 
 
 
 
Práticas desta Abordagem 
 
 
https://www.6i.com.br/blog/wp-content/uploads/2018/04/174839-5-acoes-essenciais-para-melhorar-o-
relacionamento-com-o-cliente.jpg 
 
Partindo de Descrições de Dados Existentes 
Uma opção de fonte de informações para o processo de modelagem de dados 
são descrições de dados já existentes. Exemplificando, esta situação ocorre, 
quando se deseja obter um modelo de dados para um sistema de um 
computador existente. Neste caso usam-se como descrição dos dados as 
‘ 
28 
 
descrições dos arquivos utilizados pelo sistema de um computador. Este caso 
é conhecido por engenharia reversa, pois objetiva obter uma especificação (o 
modelo) a partir de um produto existente (o sistema de um computador). Outro 
exemplo do uso de descrições de dados já existentes é quando são utilizadas 
descrições dos documentos (pastas, fichas, documentos fiscais,…) usados em 
um sistema não automatizado. 
Para estes casos, a estratégia mais adequada é a estratégia "bottom-up" (de 
baixo para cima). Esta estratégia consta de partir de conceitos mais detalhados 
("embaixo" em termos de níveis de abstração) e abstrair gradativamente. O 
processo de modelagem inicia com a identificação de atributos (conceitos mais 
detalhados). A partir daí, os atributos são agregados em entidades e as 
entidades são relacionadas e generalizadas. Essa forma de trabalhar é 
adequada quando já se dispõe dos atributos. Normalmente, isso ocorre, 
quando já se possui uma definição dos dados que deverão estar armazenados 
no banco de dados. 
 
Partindo do Conhecimento das Pessoas 
A outra opção é partir do conhecimento que pessoas possuem sobre o sistema 
sendo modelado. Este é o caso, quando novos sistemas, para os quais não 
existem descrições de dados, estão sendo concebidos. Para este caso, podem 
ser aplicadas duas estratégias, a "top-down" e a "inside-out". 
 
Estratégia "top-down" 
Esta estratégia consta de partir de conceitos mais abstratos ("de cima") e ir 
gradativamente refinando estes conceitos em conceitos mais detalhados. Ou 
seja, segue-se o caminho inverso da estratégia "bottom-up". Aqui o processo 
de modelagem inicia com a identificação de entidades genéricas (conceitos 
mais abstratos). A partir daí, serão definidos os atributos das entidades, seus 
relacionamentos, os atributos dos relacionamentos, e as especializações das 
entidades. Uma sequência de passos para obter um modelo usando a 
estratégia "top-down" é a mostrada abaixo: 
‘ 
29 
 
Modelagem superficial - Nesta primeira etapa, é construído um DER pouco 
detalhado (faltando domínios dos atributos e cardinalidades mínimas de 
relacionamentos) na seguinte sequência: 
● Enumeração das entidades; 
● Identificação dos relacionamentos e hierarquias de 
generalização/especialização entre as entidades. Para cada 
relacionamento identifica-se a cardinalidade máxima; 
● Determinação dos atributos de entidades e relacionamentos; 
● Determinação dos identificadores de entidades e relacionamentos; 
● O banco de dados é verificado quanto ao aspecto temporal. 
Modelagem detalhada - Nesta etapa, completa-se o modelo com os domínios 
dos atributos e cardinalidades mínimas dos relacionamentos: 
● Adicionam-se os domínios dos atributos; 
● Definem-se as cardinalidades mínimas dos relacionamentos. É 
preferível deixar estas cardinalidades por último, já que exigem 
conhecimento bem mais detalhado sobre o sistema, inclusive sobre as 
transações; 
● Definem-se as demais restrições de integridade que não podem ser 
representadas pelo DER. 
 
Validação do modelo 
● Procuram-se construções redundantes ou deriváveis a partir de outras 
no modelo. 
● Se valida o modelo com o usuário. 
Em qualquer destes passos é possível retornar a passos anteriores. 
Exemplificando, durante a identificação de atributos é possível que sejam 
identificadas novas entidades, o que faria com que o processo retornasse ao 
primeiro passo. 
 
‘ 
30 
 
Estratégia "inside-out" 
A estratégia "inside-out" (de dentro para fora) consta de partir de conceitos 
considerados mais importantes (centrais, parte-se "de dentro") e ir 
gradativamente adicionando conceitos periféricos a eles relacionados (ir "para 
fora"). Aqui, o processo inicia com a identificação de uma entidade 
particularmente importante no modelo e que, supõe-se, estará relacionada a 
muitas outras entidades. A partir daí, são procurados atributos, entidades 
relacionadas, generalizações e especializações da entidade em foco, e assim 
recursivamente até obter-se o modelo completo. 
A denominação da estratégia provém da idéia de que entidades importantes 
em um modelo e relacionadas a muitos outras são usualmente desenhadas 
no centro do diagrama, a fim de evitar cruzamento de linhas. Um exemplo da 
aplicação desta estratégia é mostrado na Figura 13. 
 
Figura 13. Aplicação da estratégia "inside-out". Elaborados pelo autor. 
 
Na Figura 13, está mostrada a modelagem de uma parte de um sistema de 
recursos humanos. As linhas em tons de cinza indicam os passos da 
construção do modelo. No caso, considerou-se como conceito central e ponto 
de partida da modelagem a entidade EMPREGADO. 
Após, procurou-se entidades relacionadas a EMPREGADO, tendo sido 
identificada a entidade DEPARTAMENTO. No próximo passo, foram 
identificados os atributos e especializações de EMPREGADO e finalmente 
‘ 
31 
 
foram identificados os atributos e as entidades relacionados às 
especializações de EMPREGADO. 
Os passos que ocorrem no processo "inside-out" são os mesmos que ocorrem 
no processo "top-down" ocorrendo, entretanto, uma iteração muito maior entre 
os passos: 
● Enumeração das entidades; 
● Identificação dos relacionamentos e hierarquias de 
generalização/especialização entre as entidades. Para cada 
relacionamento identifica-se a cardinalidade máxima; 
● Determinação dos atributos de entidades e relacionamentos. 
 
 
‘ 
32 
 
UNIDADE III 
 
Modelo Lógico 
 
Um Modelo de Dados Lógico é uma representação lógica das informações da 
área de negócios, não é um banco de dados, é independente do modelo físico. 
Este é o conceito chave da modelagemde dados lógica. Ele deve ser 
independente da tecnologia implementada, devido as constantes mudanças 
dos produtos tecnológicos. Os desenvolvedores de sistemas não devem se 
apegar a uma determinada tecnologia, precisam desenvolver sistemas 
independentes de tecnologia. Mas como isso seria possível? Há componentes 
de sistemas que estão intimamente ligados nas tecnologias como os 
programas, sistemas gerenciadores de banco de dados, componentes de tela, 
mas há também os componentes de sistema que podem ser criados 
independentes da tecnologia que será implementado como acontece com o 
modelo de dados lógico e as regras de negócios. Estes componentes estão 
intimamente ligados aos negócios, não a tecnologia. 
A área de negócios não muda tão rapidamente como os produtos tecnológicos. 
Pense na indústria como uma área de negócios centenária em que seu objetivo 
é a fabricação de produtos dos mais diversos tipos e que os processos de 
negócios vão desde a compra da matéria-prima, sua transformação, 
empacotamento e distribuição do produto acabado. Ela tem feito isso ao longo 
de toda a sua história. Eles sempre realizaram seus processos de trabalho sem 
os computadores, depois tiveram o apoio dos mainframes, da rede de 
computadores e agora da internet. O que os negócios fazem não mudou ao 
‘ 
33 
 
longo do tempo, mas como eles são feitos sim. A diferença entre "O que" são 
os requisitos de negócios e "Como" eles são executados descreve a diferença 
entre o Modelo Lógico e banco de dados físico. 
Quando surge uma nova tecnologia, o responsável pelo Modelo de Dados 
Lógico não necessita questionar os profissionais da área de negócios de novo, 
pois as regras de negócios continuam sendo as mesmas, ele precisa apenas 
revisar o Modelo Lógico, entender os requisitos de negócios e oferecer 
sugestões para a implementação de mudanças perante a nova tecnologia ou 
sugerir "Como" a nova tecnologia poderia mudar a maneira dos requisitos de 
negócios serem feitos. Desta forma, desenvolver e fazer manutenção 
utilizando Modelo de Dados Lógico permite prover um serviço diferenciado 
para a área de negócios com maior rapidez e menor custo. O modelo de dados 
lógico é o retrato de todas as informações necessárias para a realização dos 
negócios. Ele é representado de diversas maneiras diferentes, utilizando 
metodologias e ferramentas diferentes para implementações diferenciadas. 
O modelo Entidade-Relacionamento (MER) é uma técnica de modelagem 
amplamente utilizada pelos administradores de dados. O diagrama entidade-
relacionamento é um desenho estruturado utilizado como uma ferramenta de 
comunicação entre os profissionais de negócios e os desenvolvedores de 
sistemas de aplicação. Ele representa a diagramação dos dados necessários 
para as regras de negócios. Os componentes do MER são representados 
pelas entidades, os relacionamentos e os atributos. 
 
‘ 
34 
 
 
Figura 14. Modelo Lógico do banco de dados representado através de um MER. Elaborado 
pelo autor. 
Cada entidade representa um conjunto de pessoas, coisas ou conceitos sobre 
os quais o negócio precisa de informações. Cada relacionamento representa 
a associação entre duas entidades. Cada atributo é a característica ou parte 
da informação de uma entidade. Um nome e uma definição textual descreve 
cada um desses componentes. Estes nomes e definições provém da 
documentação das regras de negócio e informações as quais são 
armazenadas e mantidas num repositório de dados garantindo assim a 
padronização conceitual dos dados. 
O Modelo Lógico somente terá início após a criação do Modelo Conceitual, 
pois vamos considerar uma das abordagens possível da tecnologia Sistemas 
Gerenciadores de Bancos de Dados, seja ela Relacional, Hierárquica, Rede ou 
Orientada a Objetos, para a estruturação e estabelecimento da lógica dos 
relacionamentos existentes entre os dados definidos no Modelo Conceitual. 
 
O arquiteto de dados com a ajuda do analista de requisitos de negócios cria o 
modelo de dados lógico e se utiliza dele para avaliar possíveis impactos nos 
requisitos de negócios numa provável mudança tecnológica. O Arquiteto de 
‘ 
35 
 
dados também é responsável por trabalhar com o administrador de banco de 
Dados (DBA), para garantir a implementação do Modelo de Dados Lógico para 
o Modelo de Dados Físico de acordo com o Sistema Gerenciador de Banco de 
Dados (SGBD) que será aplicado. O DBA revisa o Modelo de Dados Lógico e 
define o SGBD mais apropriado, cria índices, detalha os tipos de dados e cria 
a integridade referencial para proteger o valor dos dados. O administrador de 
Banco de Dados pode "desnormalizar" a base de dados, criar stored 
procedures, triggers além de monitorar a desempenho do banco de dados 
físico. 
A elaboração direta e um Modelo Lógico de dados, independentemente de já 
sabermos a abordagem para qual banco de dados estamos realizando um 
projeto, levam à vinculação tecnológica de nosso raciocínio, perturbando a 
interpretação pura e simples de um contexto. Sempre que analisamos um 
contexto sob a ótica tecnológica, temos a tendência de sermos técnicos 
demais, distorcer a realidade, conduzindo-a as restrições da tecnologia 
empregada, o que sempre, e já estatisticamente comprovado, leva a erros de 
interpretação da realidade, criando assim modelos de dados que não possuem 
aderência ao "mini mundo" descrito. 
 
 
Figura 15. Modelo de Lógico de banco de dados Vídeo Locadora. Elaborado pelo autor. 
O Modelo Lógico descreve em formato as estruturas que estarão no banco de 
dados de acordo com as possibilidades permitidas pela sua abordagem, mas 
‘ 
36 
 
sem considerar, ainda, nenhuma característica específica de um Sistema 
Gerenciador de Banco de Dados (SGBD). Isso resulta um Esquema Lógico de 
Dados, sob a ótica de uma das abordagens citadas, pelo emprego de uma 
técnica de Modelagem de Dados Orientada às Restrições de cada abordagem. 
 
Abordagem Relacional 
 
https://www.ibe.edu.br/wp-content/uploads/2015/12/sitenoticia10.jpg 
 
O Modelo Relacional foi introduzido por Edgar F. "Ted" Codd, da IBM 
Research, em 1970, em um artigo clássico (Codd, 1970) que imediatamente 
atraiu a atenção em virtude de sua simplicidade e base matemática. O modelo 
usa o conceito de uma relação matemática, algo como uma tabela de valores, 
como seu bloco de construção básica e tem sua base na teoria dos conjuntos 
e na lógica de predicados de primeira ordem. Neste capítulo discutiremos as 
características básicas do modelo e suas restrições. 
As primeiras implementações comerciais do Modelo Relacional tornaram-se 
disponíveis no início da década de 80, com o SGBD Oracle e o sistema 
SQL/DS do sistema operacional MVS, da IBM. Desde essa época, o modelo 
tem sido implementado em um grande número de sistemas comerciais. Os 
SGBDs Relacionais (SGBD Rs) mais conhecidos atualmente são o DB2 o 
Oracle, o SQL Server, o MySQL e o PostGreSQL. 
A Abordagem Relacional representa uma forma de descrever o banco de 
dados através de conceitos matemáticos simples: a teoria dos conjuntos. 
Voltada, principalmente, a melhorar a visão dos dados pelos usuários, a 
‘ 
37 
 
Abordagem Relacional faz com que os usuários vejam o banco de dados como 
um conjunto de tabelas bidimensionais, originadas em linhas e colunas. 
 
Composição de um Banco de Dados 
 
Um Banco de Dados Relacional é composto de tabelas ou relações. A 
terminologia tabela é mais comum nos produtos comerciais e na prática. Já a 
terminologia relação foi utilizada na literatura original sobre a Abordagem 
Relacional e é mais comum na área acadêmica e nos livros texto. 
 
Tabelas 
 
 Uma tabela é um conjunto não ordenado de linhas (tuplas, na terminologia 
acadêmica). Cada linha é composta por uma série de campos (valor de 
atributo, na terminologia acadêmica). Cada campo é identificado por nome de 
campo (nome de atributo, na terminologia acadêmica).O conjunto de campos 
das linhas de uma tabela que possuem o mesmo nome forma uma coluna. 
 
Figura 16. Representação da estrutura uma tabela. Elaborado pelo autor. 
 
O conceito principal vem da teoria dos conjuntos atrelado à concepção de que 
não é relevante ao usuário saber onde os dados estão e nem como os dados 
estão (transparência). Tal modelo possui como objetivo a apresentação dos 
dados similar a um conjunto de relações. Dessa maneira, podemos comparar 
uma relação como sendo uma possível tabela, ou, simplesmente, um simples 
arquivo contendo "n" registros. 
 
‘ 
38 
 
O Modelo de Dados Relacional é calcado no conceito de matrizes. Podemos 
considerar que as linhas em uma matriz como sendo os registros e as colunas, 
seus respectivos campos. Os identificadores das tabelas (relação) e dos 
campos são de extrema relevância para seu entendimento entre o que você 
está armazenando, onde está armazenando e qual a relação existente entre 
os dados armazenados. Como exemplo, tomamos as Tabelas 01 e 02, que 
estrutura os dados por meio do uso de um Modelo de Dados Relacional. 
 
Tabela 01. Exemplo de Modelo de Dados Relacionais. Elaborado pelo autor. 
 
 
 
Tabela 02. Exemplo de Modelo de Dados Relacionais. Elaborado pelo autor. 
 
 
As relações apresentadas pelas Tabelas 01 e 02, podem ser vistas como, 
linhas que representam vários registros (tuplas), isto é, uma coleção de valores 
relacionados. Nesse contexto, esses valores referem-se a um fato de uma 
entidade específica, ou até mesmo uma instância de um relacionamento 
qualquer. O nome da tabela com os nomes das respectivas colunas são 
cruciais para que seja possível interpretarmos o correto sentido dos valores 
em cada linha (tupla) existente em uma tabela. 
 
É factível identificarmos que a tabela ora nomeada de Tabela Aluno, cada linha 
(tupla) diz respeito a um fato específico ora armazenado nessa tabela. Suas 
colunas, essas identificadas como RA (Registro Acadêmico), Nome, Sala e 
Departamento possibilitam que realizemos a devida interpretação dos valores 
‘ 
39 
 
vinculados para cada linha (tupla). Considere que, para cada coluna, todos os 
valores associados à mesma, deverá, obrigatoriamente, manipular os mesmos 
tipos de dados. 
 
Na maioria das literaturas que discorre sobre o tema Modelo Relacional, como 
foi discorrido anteriormente, uma linha é caracterizada como sendo uma tupla, 
uma coluna como um atributo e uma tabela de relação. Ainda tomando como 
referência o Modelo Relacional, o conceito de domínio refere-se ao tipo de 
dados que será armazenado em uma coluna qualquer. O grau de uma relação 
é interpretado pelo número de atributos existentes nela. A fim de esclarecer o 
grau de uma relação, considere a relação ora apresentada abaixo, que por sua 
vez, apresenta informações referentes aos alunos de uma universidade 
qualquer: 
Aluno (RA, Nome, Endereço, Telefone, Idade, Média Ponderada). 
 
Nessa relação, consideramos que Aluno é o nome da relação, a qual possui 
seis atributos, por isso podemos interpretar que essa relação é de grau seis. É 
possível ainda, detalhar alguns domínios para cada atributo presente na 
relação Aluno, por exemplo, o domínio RA (registro acadêmico – numérico ou 
literal), Nome (nomes dos alunos), Telefone (número do telefone fixo – 
numérico ou literal) e Média Ponderada (valor correspondente à média 
ponderada de um determinado aluno - numérico). 
 
A Tabela 03 é apresentada a relação intitulada de Aluno, onde podemos 
abstrair que cada tupla representa uma entidade aluno. Essa relação 
representada por sua vez como uma tabela considera cada tupla como sendo 
uma linha e, cada atributo existente nessa tabela, como um cabeçalho que, 
tem como propósito indicar um papel específico ou simplesmente promover a 
interpretação dos valores vinculados a cada coluna. 
 
Tabela 03. Tabela Aluno com suas respectivas instâncias. Elaborado pelo autor. 
‘ 
40 
 
 
 
As Chaves 
 
O conceito básico para estabelecer relações entre linhas de tabelas de um 
Banco de Dados Relacional é o da chave. Em um Banco de Dados Relacional, 
há ao menos três tipos de chaves a considerar: a Chave Primária, a Chave 
Alternativa, e a Chave Estrangeira. 
 
Chave Primária 
 
Com os conceitos estudados até o presente momento, já aprendemos que uma 
relação é considerada como um conjunto de tuplas. Devemos considerar que, 
todos os elementos constituintes desse conjunto de tuplas devem ser 
exclusivos, isto significa que, absolutamente nenhuma tupla deverá possuir a 
mesma combinação de valores para todas as suas colunas. Isso significa que, 
em uma relação, eventuais subconjuntos de atributos não podem conter tuplas 
com a mesma combinação de valores. Sendo assim, conclui-se que toda a 
relação deve conter pelo menos uma superchave. Como exemplo, retornamos 
a Tabela 03, onde o atributo nomeado de RA (Registro Acadêmico) é 
considerado uma superchave da relação aluno por simplesmente não deixar 
que um mesmo aluno possua o mesmo registro acadêmico. 
 
Um valor vinculado a um atributo-chave é utilizado para distinguir de maneira 
exclusiva uma tupla em uma relação específica. Ou seja, o valor 21, do atributo 
RA da Tabela 03, é utilizado exclusivamente para identificar a tupla vinculada 
ao aluno "Paulo Henrique", ora existente na relação Aluno. É importante 
‘ 
41 
 
escolher corretamente o atributo-chave de uma relação, principalmente se 
considerarmos que o mesmo não poderá sofrer modificações no transcorrer do 
tempo. A fim de melhor exemplificar, é possível dizer que o atributo Nome da 
mesma relação Aluno não deverá, em hipótese alguma, ser escolhido como 
atributo-chave, sobretudo por, não possuirmos garantia da não existência de 
nomes idênticos. 
 
Chave Alternativa 
 
Na maioria das vezes, em uma relação poderá existir mais de um atributo-
chave. Em alguns casos, mais de uma coluna ou combinações de colunas 
podem servir para distinguir uma linha das demais. Uma das colunas (ou 
combinação de colunas) é escolhida como chave primária. As demais colunas 
ou combinações são denominadas Chaves Alternativas. A Tabela 04 mostra 
um exemplo de uma tabela com dados de Empregados (Emp) na qual tanto a 
coluna CodigoEmp quanto a coluna CPF podem ser usadas para distinguir 
uma linha das demais. Nesta tabela, como a coluna CodigoEmp foi escolhida 
como Chave Primária, diz-se que a coluna CPF é uma Chave Alternativa. 
 
Tabela 04. Exemplo de Chave alternativa coluna CPF. Elaborado pelo autor. 
 
 
Quando, em uma tabela, mais de uma coluna ou combinações de colunas 
podem servir para distinguir uma linha das demais, surge à questão de que 
critério deve-se usar para determinar qual das possíveis colunas (ou 
combinação de colunas) será usada como chave primária. 
 
‘ 
42 
 
No exemplo da Tabela 04, a questão é que critério foi usado para preferir a 
coluna CodigoEmp como Chave Primária e considerar a coluna CPF como 
Chave Alternativa. Porque CPF não foi usado como chave primária e 
CodigoEmp como Chave Alternativa? No fundo, se considerarmos apenas a 
tabela em que a coluna aparece, não há diferença entre uma coluna ser Chave 
Primária ou Alternativa. Em ambos os casos, apenas está sendo especificada 
a unicidade de valores de chave. Entretanto, ao considerarmos Chaves 
Estrangeiras, a diferenciação entre Chave Primária e Chave Alternativa passa 
a ser relevante. 
 
Quando especificamos que uma Chave é Primária, estamos especificando, 
além da unicidade de valores, também o fato de esta coluna ser usada nas 
Chaves Estrangeiras que referenciam a tabela em questão. Assim, no caso da 
Tabela 04, estamos especificando que tanto os valores de CodigoEmp quanto 
os valores de CPF são únicos e adicionalmente que a coluna CódigoEmp será 
usada nas Chaves Estrangeiras que referenciam a tabela Empregados. 
 
Chave Estrangeira 
 
Uma chave estrangeira é uma coluna ou uma combinaçãode colunas, cujos 
valores aparecem necessariamente na Chave Primária de outra tabela (as 
vezes da própria tabela onde ela está inserida). A Chave Estrangeira é o 
mecanismo que permite a implementação de relacionamentos em um Banco 
de Dados Relacional. No banco de dados da Tabela 04, a coluna CodigoDepto 
da tabela Empregados é uma Chave Estrangeira em relação a Chave Primária 
da tabela Departamento. Isso significa que, na tabela Empregados, não podem 
aparecer linhas que contenham um valor do campo CodigoDepto que não 
existam na coluna de mesmo nome da tabela Empregados. A interpretação 
desta restrição é que todo empregado deve estar associado a um 
departamento. 
‘ 
43 
 
Tabela 05. Coluna CodigoDepto. Elaborada pelo autor. 
 
 
 
 
 
Tabela 06. Exemplo de Chave Estrangeira Coluna CodigoDepto. Elaborada pelo autor. 
 
A existência de uma chave Estrangeira impõe restrições que devem ser 
garantidas em diversas situações de alteração do banco de dados: 
● Quando da inclusão de uma linha na tabela que contém a chave 
estrangeira. Neste caso, deve ser garantido que o valor da Chave 
Estrangeira apareça na coluna da Chave Primária referenciada. No 
caso do exemplo da Tabela 06, isso significa que um novo empregado 
deve atuar em um departamento já existente no banco de dados. 
● Quando da alteração do valor da chave estrangeira. Deve ser 
garantido que o novo valor de uma chave estrangeira apareça na coluna 
da chave primária referenciada. 
● Quando da exclusão de uma linha da tabela que contém a Chave 
Primária referenciada pela Chave Estrangeira. Deve ser garantida 
que na coluna Chave Estrangeira não apareça o valor da Chave 
Primária que está sendo excluída. No caso do exemplo da Tabela 05, 
isso significa que um departamento não pode ser excluído, caso nele 
ainda existirem empregados. 
 
A palavra "estrangeira" usada para denominar este tipo de chave pode ser 
enganosa. Ela pode levar a crer que a Chave Estrangeira sempre referência 
‘ 
44 
 
uma Chave Primária de outra tabela. Entretanto, esta restrição não existe. Uma 
Chave Estrangeira poderá referenciar a Chave Primária da própria tabela. 
 
 
 
 
 
 
 
 
 
 
 
Técnica de Transformação entre o Modelo ER e o Modelo Relacional 
 
 
https://universoyrealidad.com/wp-content/uploads/2017/08/FCPA.Internal.Controls.Process.jpg 
 
Serão apresentadas agora, regras para transformação de um modelo ER em 
um modelo relacional. As regras foram definidas tendo em vista dois objetivos 
básicos: 
● Obter um banco de dados que permita boa performance de instruções 
de consulta e alteração do banco de dados. Obter boa performance 
significa basicamente diminuir o número de acessos a disco, já que 
estes consomem o maior tempo na execução de uma instrução de 
banco de dados. 
● Obter um banco de dados que simplifique o desenvolvimento e a 
manutenção de aplicações. 
‘ 
45 
 
 
Estes dois objetivos são os centrais. Além destes, as regras de transformação 
procuram obter um banco de dados que ocupe pouco espaço em disco. O 
objetivo de reduzir espaço de armazenamento era até algum tempo atrás tão 
importante quanto o objetivo de melhorar performance e simplificar o 
desenvolvimento. A fim de alcançar estes objetivos, as regras de tradução 
foram definidas tendo por base, entre outros, os seguintes princípios: 
 
● Evitar junções - ter os dados necessários a uma consulta em uma única 
linha => Um SGBD relacional normalmente armazena os dados de uma 
linha de uma tabela contiguamente em disco. Com isso, todos os dados 
de uma linha são trazidos para a memória em uma operação de acesso 
a disco. Isso significa que, uma vez encontrada uma linha de uma 
tabela, seus campos estão todos disponíveis sem necessidade de 
acesso adicional a disco. 
 
Quando for necessário buscar em disco dados de diversas linhas associadas 
pela igualdade de campos (por exemplo, buscar os dados de um empregado 
e os dados de seu departamento) é necessário usar a operação de junção. Os 
SGBD procuram implementar a junção de forma eficiente, já que ela é uma 
operação executada muito frequentemente. Mesmo assim, a junção envolve 
diversos acessos a disco. Assim, quando for possível, é preferível ter os dados 
necessários a uma consulta em uma única linha somente, ao invés de tê-los 
distribuídos em diversas linhas, exigindo a sua junção. 
 
● Diminuir o número de chaves primárias => Para a implementação 
eficiente do controle da unicidade da chave primária, o SGBD usa 
normalmente uma estrutura de acesso auxiliar, um índice, para cada 
Chave Primária. Índices, pela forma que são implementados, tendem a 
ocupar espaço considerável em disco. Além disso, a inserção ou 
remoção de entradas em um índice podem exigir diversos acessos a 
disco. Assim sendo, quando for necessário escolher entre duas 
alternativas de implementação, uma na qual, dados aparecem em uma 
única tabela e outra na qual os mesmos dados aparecem em duas ou 
‘ 
46 
 
mais tabelas com a mesma Chave Primária e mesmo número de linhas, 
a implementação por uma única tabela deve ser preferida. 
 
 Para exemplificar, vamos considerar que se deseja armazenar dados sobre 
Clientes em um Banco de Dados Relacional. Deseja-se armazenar, para cada 
Cliente, seu Código, seu Nome, o Nome da Pessoa de Contato, o Endereço e 
o Telefone. Estes dados poderiam ser implementados através de uma das 
seguintes alternativas: 
 
 Cliente (CodCliente,Nome,Nome Contato,Endereço,Telefone) 
 ou 
 Cliente (CodCliente,Nome,NomeContato) 
 ClienteEnder (CodCliente,Endereço,Telefone) CodCliente referência Cliente 
 
 Na primeira alternativa, o SGBD cria apenas um índice por Código de Cliente, 
a Chave Primária da tabela. Na segunda alternativa, o SGBD cria, para cada 
tabela, um índice por Código de Cliente. Como cada cliente aparece nas duas 
tabelas, os dois índices possuem exatamente as mesmas entradas, resultando 
em armazenamento e processamento dobrados. A primeira alternativa é a 
gerada pelas regras apresentadas neste capítulo. 
 
● Evitar campos opcionais => Campos opcionais são campos que podem 
assumir o valor VAZIO (NULL em SQL). Os SGBD Relacionais 
usualmente não desperdiçam espaço pelo fato de campos de uma linha 
estarem vazios, pois usam técnicas de compressão de dados e registros 
de tamanho variável no armazenamento interno de linhas. Além disso, 
há uma cláusula de SQL que especifica ao SGBD se o campo deve 
estar preenchido ou pode estar vazio. Assim, em princípio, não há 
problemas em usar este tipo de campos. 
 
Uma situação que pode gerar problemas é aquela na qual a obrigatoriedade 
ou não do preenchimento de um campo depende do valor de outros campos. 
Neste caso, em alguns SGBD, o controle da obrigatoriedade deve ser feito 
pelos programas que acessam o banco de dados, o que deve ser evitado. 
‘ 
47 
 
Estas regras usam como entrada, além do próprio Modelo ER, também alguns 
conhecimentos sobre volumes de dados e volumes de transações. Esses 
conhecimentos permitem escolher uma alternativa de implementação, quando 
diversas alternativas podem ser usadas para implementar um conceito da 
Abordagem ER. A transformação de um Modelo ER em um Modelo Relacional 
dá-se nos seguintes passos: 
 
1. Tradução inicial de entidades e respectivos atributos; 
2. Tradução de relacionamentos e respectivos atributos; 
3. Tradução de generalizações/especializações 
 
Para exemplificar, considere a Figura 17, ora representada por uma entidade 
chamada de EMPREGADOS, que por sua vez, incorpora os atributos RG 
(atributo identificador) nome e idade. Repare que o processo de mapeamento 
para esse exemplo é bem simples e objetivo e que, o atributo identificador 
(chave-primária) é representado pelo uso de um sublinhado no nome do 
atributo. 
 
Figura 17. Mapeando convencional de uma entidade. Elaborado pelo autor. 
 
Em relação ao mapeamento de entidades-fracas, deve-se observarque o 
identificador da entidade considerada forte, constitui parte da chave-primária 
da tabela correspondente à entidade-fraca e, por outro lado, torna-se chave-
estrangeira na tabela fraca. Esse exemplo pode ser visualizado na Figura 18. 
Lembre-se que a entidade-fraca nesse exemplo é Itens. Note que foi utilizada 
uma chave-primária composta para esse exemplo. 
 
‘ 
48 
 
 
Figura 18. Mapeamento da entidade-fraca (Itens). Elaborada pelo autor. 
 
Já o exemplo apresentado pela Figura 19, é realizado o mapeamento dos 
atributos obrigatório, opcional e composto. Note que nesse exemplo, a 
cardinalidade máxima do atributo telefone são três (FoneResid, FoneComl e 
Celular): 
 
Figura 19. Mapeamento dos atributos (obrigatório, opcional e composto). 
Elaborado pelo autor. 
 
Agora, a respeito do mapeamento de entidades especializadas, deve-se 
considerar três opções: 
1. Opção: considerar uma única tabela para a entidade considerada 
genérica e suas especializações; 
2. Opção: considerar o uso de tabelas para entidade genérica e para as 
entidades especializadas; 
3. Opção: considerar o uso de tabelas apenas para as entidades 
especializadas. 
 
‘ 
49 
 
No próximo exemplo, a primeira opção é adotada. Repare na Figura 20 que foi 
realizado o mapeamento da entidade genérica e suas respectivas entidades 
especializadas, mesclando tudo em uma única tabela. Dessa maneira, o 
atributo "tipo" pode armazenar mais de um valor apenas se, a especialização 
for não exclusiva. 
 
Figura 20. Mapeando da entidade genérica e especializada. Elaborada pelo autor. 
 
Para a segunda alternativa de Mapeamento de Entidade Genérica e 
Especializada, considere como exemplo a Figura 21, a qual foi realizada o 
mapeamento de forma separada entre a entidade genérica SERVIDORES e 
suas entidades especializadas, intituladas de FUNCIONARIOS e 
PROFESSORES. 
 
Figura 21. Mapeando de Entidade Genérica e Especializada. Elaborado pelo autor. 
 
Em nossa última alternativa, repare na Figura 22, que realizou-se apenas o 
mapeamento das entidades especializadas FUNCIONARIOS e 
‘ 
50 
 
PROFESSORES. Um detalhe importante diz respeito a não utilização dessa 
alternativa em especializações parciais. 
 
 
Figura 22. Mapeando apenas as entidades especializadas. Elaborado pelo autor. 
 
O mapeamento dos relacionamentos considera uma análise aplicada na 
cardinalidade existente nos relacionamentos. Após essa análise, diversas 
alternativas de mapeamento podem ser escolhidas, a citar: as entidades ora 
relacionadas podem ser fundidas em uma única tabela; outras tabelas podem 
ser criadas para acolher os relacionamentos, e, como última alternativa, 
eventuais chaves-estrangeiras podem ser constituídas nas tabelas para 
estabelecer corretamente o relacionamento. A Figura 23 apresenta um 
exemplo de mapeamento de um relacionamento, cujo cardinalidade é 1:1 (um-
para-um), ou seja, obrigatório em ambos os sentidos. 
 
 
Figura 23. Mapeando um relacionamento (1:1). Elaborado pelo autor. 
 
‘ 
51 
 
Como outro exemplo, podemos tomar o mapeamento de um relacionamento 
que possui duas cardinalidades, a primeira é (1:1) e a segunda cardinalidade 
é (0:1), isso simboliza, opcional em um dos sentidos. A Figura 24 demonstra o 
resultado desse mapeamento, perceba que foi similar ao exemplo anterior, ou 
seja, fundimos em uma única tabela. 
 
 
Figura 24. Primeira alternativa Opcional em um dos sentidos. Elaborado pelo autor. 
 
Existe ainda a alternativa para esse caso, apresentado pela Figura 25, que 
promove também o mapeamento do mesmo MER (opcional em um dos 
sentidos), todavia, utiliza duas tabelas (PESSOAS e 
CARTEIRAS_MOTORISTA). 
 
Figura 25. Segunda alternativa: Opcional em um dos sentidos. Elaborado pelo autor. 
 
A Figura 26 exemplifica uma alternativa aplicada ao mapeamento de 
relacionamento opcional em ambos os sentidos, isso é, a cardinalidade mínima 
das entidades denominadas HOMENS e MULHERES respectivamente, 
equivalem à zero, simbolizando um Relacionamento Opcional 
independentemente do sentido utilizado. 
 
‘ 
52 
 
 
Figura 26. Mapeamento do relacionamento opcional em ambos os sentidos. 
Elaborado pelo autor. 
 
A segunda alternativa para o mesmo MER, representado pela Figura 27 
considera o mesmo relacionamento anterior, ou seja, opcional em ambos os 
sentidos, porém realiza o mapeamento apenas das entidades envolvidas. 
 
 
Figura 27. Mapeamento do relacionamento opcional em ambos os sentidos. 
Elaborado pelo autor. 
 
Quando se trata de um relacionamento 1:N, isso é, um relacionamento 
obrigatório e ou opcional do lado N. O exemplo a seguir, ora representado pela 
Figura 4.18, é possível identificar que a entidade nomeada de EMPREGADO 
trabalha com duas alternativas de cardinalidade, uma representando a 
cardinalidade 1:N e a outra 0:N, a qual caracteriza opcional no lado N. No 
exemplo apresentado, torna-se possível visualizar o mapeamento final 
utilizando duas tabelas, essas nomeadas de DEPARTAMENTOS e 
EMPREGADOS e, ainda, que o atributo referente ao relacionamento 
LOTAÇÃO se encontra incluído na tabela EMPREGADOS. 
‘ 
53 
 
 
 
Figura 28. Mapeando do relacionamento obrigatório e opcional. Elaborado pelo autor. 
 
Repare agora que, quando trabalhamos com relacionamentos 1:N e opcional 
do lado "1", basicamente podemos aplicar duas possibilidades para o processo 
de mapeamento. Como primeira alternativa, ora representada pela Figura 29, 
é criada três tabelas, duas tabelas destinadas ao mapeamento das entidades 
AUTOMOVEIS e PESSOAS, e uma tabela exclusiva para mapear o 
relacionamento POSSE, que por sua vez, possui como característica os 
atributos RG (chave-estrangeira), Chassi (chave-primária e chave-estrangeira) 
e DataCompra. 
 
Figura 29 – Primeira opção: Mapeamento do relacionamento (opcional lado "1"). 
Elaborado pelo autor. 
 
Como segunda opção para o mapeamento do MER apresentado pela Figura 
30, é possível notar que foi utilizado duas tabelas para realizar o mapeamento 
do relacionamento caracterizado de 1:N, isso é, simplesmente foi criado uma 
tabela para mapear a entidade PESSOAS e outra tabela para mapear a 
entidade AUTOMOVEIS. Repare ainda que inserimos o atributo RG da 
‘ 
54 
 
entidade PESSOAS, que por sua vez é uma chave-estrangeira, com o atributo 
DataCompra, de propriedade do relacionamento POSSE. 
 
Figura 30. Segunda opção: Mapeamento do relacionamento (opcional lado "1"). 
Elaborado pelo autor. 
 
Para exemplificar um relacionamento N:N, visualize a Figura 31. Verifique que 
temos três tabelas resultantes do processo de mapeamento, ou seja, duas 
tabelas para mapear as entidades EMPREGADOS e PROJETOS 
respectivamente, e outra tabela exclusiva para mapear o relacionamento 
PARTICIPAÇÃO. Dessa maneira, a tabela PARTICIPAÇÃO é formada pelos 
atributos RG, Código e DataInício, e ainda, note que RG e código tornam-se 
os atributos identificadores constituindo o que denominamos de chave-primária 
composta. O relacionamento aplicado nesse exemplo, entre as entidades 
EMPREGADOS e PROJETOS é obrigatório e ou opcional nos dois sentidos. 
 
 
Figura 31. Mapeando um relacionamento N:N (obrigatório e ou opcional nos dois sentidos). 
Elaborado pelo autor. 
 
Nesse próximo exemplo, exploraremos conhecimentos referente ao 
mapeamento de um auto relacionamento, isso é, de um relacionamento de 
‘ 
55 
 
grau um. Não existe nenhuma exceção, pois é permitido aplicar absolutamente 
todas as regras de mapeamento vistas até o momento. A Figura 32 permite 
que sejam visualizadas duas alternativas de mapeamento de um auto 
relacionamento. É importante lembrar que para esse tipo de relacionamento é 
imprescindível o uso de papéis, esses utilizados para identificar 
adequadamente o papel de cada instância de EMPREGADOS, ora assumindo 
o papel de GERENTE e ou SUBORDINADO. 
 
Figura 32. Mapeamento de um auto relacionamento. Elaborado