tema2

Modelagem
de dados
O objetivo deste tema é compreender e criar os modelos de
dados que permitem representar a realidade em uma apli-
cação de banco de dados. Como visto no tema anterior, o
Modelo de Dados é um conjunto de conceitos que permitem
ao profissional definir uma estrutura de banco de dados
que represente a realidade de um determinado ambiente.
O processo de criação do modelo de dados é chamado de
Modelagem de Dados, e compõe uma das etapas de todo o
processo da definição de uma aplicação de banco de dados.
Veremos as demais etapas no transcorrer deste tema.

Iniciaremos este tema estudando o Modelo de Dados Enti-

dade-Relacionamento (Modelo E-R), verificando seus con-
ceitos e elementos que permitem criar um Modelo de Dados
Conceitual. O objetivo deste modelo é criar uma visão ini-
cial da estrutura de banco de dados que represente a reali-
dade sem obrigação com regras técnicas de implementação
em um SGBD, tendo como foco apenas aspectos semânti-
cos da solução (MEDEIROS, 2007), criando uma definição
de fácil entendimento com possibilidade de entendimento
até pelos usuários que não possuem conhecimento técni-
co na área. Após o estudo do Modelo E-R, conheceremos o
Modelo de Dados Lógico, mais especificamente o Modelo
Relacional, que já possui regras que devem ser seguidas
para implementação em um SGBD. Após conhecermos es-
tes dois modelos, verificaremos as técnicas de transforma-
ção do Modelo E-R para o Relacional. Para isso, criaremos
um ambiente fictício de uma Instituição de Ensino Superior,
a qual terá sua realidade modelada para uma estrutura de
banco de dados.
2.1
MODELO ENTIDADE-RELACIONAMENTO

Antes de tratarmos de forma específica em como utilizar o Mo-

delo E-R, vamos conversar sobre as etapas necessárias para definir o
modelo de dados que será implementado no banco de dados.

Etapas de um Projeto de Banco de Dados

Todo o processo é iniciado através do surgimento de uma ne-
cessidade de desenvolvimento de software. Partindo desta necessi-
dade, o analista de sistema deverá realizar o levantamento e análise
de requisitos. Este levantamento é realizado através de entrevistas
com os usuários que geraram a necessidade, cujos requisitos devem
ser devidamente documentados. Com todos os requisitos definidos,
é necessário especificar as operações necessárias para atender estes
requisitos. Dentro de todo projeto de software estes requisitos são es-
pecificados utilizando diagramas de caso de uso, diagrama de classe
e sequência, entre outros artefatos que foram vistos na disciplina de
Engenharia de Software e não fazem parte dos nossos objetos de es-
tudo. Após todos os requisitos especificados, o próximo passo é criar
o Modelo de Dados Conceitual de Banco de Dados, o qual será criado
utilizando o Modelo E-R. Chamamos esta etapa de Projeto Conceitu-
al, cujo principal objetivo é criar um modelo de dados preliminar, com
alto nível de representatividade e que possa ser validado verificando
o atendimento aos requisitos especificados. Após a definição do Mo-
delo E-R, é realizado o mapeamento para o Modelo Relacional, o qual
já possui regras mais rígidas de definição, de forma a possibilitar a sua
criação no SGBD escolhido. Esta fase é conhecida como Projeto Ló-
gico (ELMASRI; NAVATHE, 2005), cujo produto final é o esquema de
62
Banco de Dados I

banco de dados pronto para ser implementado no SGBD. A última eta-

pa é a definição do Projeto Físico da base de dados cuja execução é
responsabilidade do DBA e leva em considerações questões de confi-
guração do SGBD para se obter o melhor desempenho da aplicação. A
figura 10 ilustra a visão geral das etapas do projeto de banco de dados.

Etapas do projeto de banco de dados

Neste tema faremos um estudo aprofundado dos projetos Con-

ceitual e Lógico.

Aplicação Exemplo

Para darmos continuidade ao estudo sobre modelagem de da-

dos, utilizaremos uma aplicação exemplo a qual será utilizada no pro-
jeto Conceitual e Lógico.

Vamos admitir que o levantamento de requisitos já tivesse sido

realizado e que as operações estejam todas especificadas, faltando
apenas o trabalho a modelagem de dados.
 63
Tema 2
Modelagem de Dados

Nossa aplicação exemplo irá tratar das situações envolvendo

uma Universidade fictícia, a qual batizaremos de UniGrande. O prin-
cipal objetivo de nossa aplicação de banco de dados é criar o modelo
de dados que represente os alunos, disciplinas, cursos entre outros
elementos que compõe a UniGrande. Para que possamos fazer este
mapeamento da melhor forma, vamos interpretar o texto criado pelo
analista de sistema que descreve todos estes elementos. O texto que
descreve a realidade da UniGrande está disponível no AVA. Sua leitura
é fundamental para o bom entendimento do restante do conteúdo.

O texto que descreve um determinado am-

biente é também conhecido como Estudo de
Caso.

A figura 11 ilustra o diagrama que representa o Modelo E-R ge-

rado para o estudo de caso da UniGrande. Este diagrama é conhecido
como DER (Diagrama de Entidade-Relacionamento) e veremos como
obtê-lo através da modelagem e dados da UniGrande.
64
Banco de Dados I

DER do Estudo de Caso UniGrande

O DER é um documento fundamental, pois através dele é pos-

sível entender a realidade proposta no estudo de caso além de aju-
dar na validação do modelo e seu atendimento à realidade. Quando
chegamos ao DER, podemos considerar que o Projeto Conceitual foi
concluído.

Existem várias notações gráficas para representar o modelo de

dados conceitual. Em nossa disciplina vamos utilizar o modelo pro-
posto em 1976 por Peter Chen, considerado ainda hoje como padrão
para a modelagem conceitual.

Vamos começar agora a entender os elementos que formam o

Modelo E-R e como eles são extraídos do estudo de caso.
 65
Tema 2
Modelagem de Dados

Modelo E-R

O modelo E-R baseia-se no princípio que o mundo real deve ser

representando por um conjunto de objetos chamados de Entidade e
pelo conjunto de Relacionamento entre esses objetos.

Entidade
É o objeto básico do Modelo E-R e representa “algo” do mundo
real (ELMASRI; NAVATHE, 2005). Pode ser um objeto de existência
física, como um carro, uma pessoa ou um funcionário, como também
um objeto com existência conceitual, como um curso de graduação.
Também consideramos como entidade, eventos que ocorrem no
mundo real, como por exemplo, uma venda. Começamos a defini-
ção de nosso Modelo E-R, identificando as entidades presentes em
nosso estudo de caso, fazendo uma leitura detalhada do estudo de
caso identificando “objetos” do mundo real. Para ajudar, devemos en-
contrar todas as “coisas” que possui características associadas. Por
exemplo, na passagem “Cada aluno está vinculado a apenas um curso,
sendo que cada aluno possui um número de matrícula único, nome,
data de nascimento, créditos cursados e média geral”, podemos iden-
tificar a entidade Aluno, o mesmo acontece na passagem “Os cursos
de graduação são coordenados por apenas um professor e possui um
código único, nome e total de créditos necessários para que um aluno
possa concluir o curso”, quando identificamos as entidades Curso e
Professor.

Também é possível identificar uma entidade analisando a ne-

cessidade de armazenamento das informações vinculadas a ela. Por
exemplo, se for verificada a necessidade de armazenamento do nome
e matrícula de um aluno então temos a entidade Aluno. Uma entidade
66
Banco de Dados I

representa o modelo de um aluno, ou seja, todo aluno da UniGrande

deverá ter uma matrícula e um nome diferenciados apenas por seus
valores. Cada ocorrência da entidade Aluno é chamada de Instância.
Na figura 12, podemos observar instâncias da entidade Aluno.

Instâncias da Entidade Aluno

No Modelo E-R, as entidades são representadas através de re-

tângulos. A figura 13 exibe todas as entidades encontradas no estudo
de caso.

Entidades do estudo de caso

 67
Tema 2
Modelagem de Dados

Atributos

Após identificar as entidades, devemos encontrar os atributos

que formam as entidades. Atributos são características vinculadas a
uma determinada entidade (MEDEIROS, 2007). Assim como as enti-
dades, são identificados através de uma leitura detalhada do estudo
de caso. Por exemplo, no fragmento “Cada disciplina da universidade
possui um código único, nome e uma quantidade de créditos” do estu-
do caso, é possível identificar os atributos código, nome e quantidade
de créditos para a entidade Disciplina. Os valores dos atributos variam
entre as instâncias da entidade.

Entre os atributos elencados em uma entidade, é importante

identificar entre eles um atributo chave. Um atributo chave é aquele
que consegue identificar uma determinada instância. Por exemplo, na
entidade Aluno, podemos identificar a matrícula como atributo cha-
ve. A figura 14 ilustra como devem ser representados os atributos de
uma entidade. Os atributos com um círculo preenchido representam
os atributos chaves.

Atributos de uma entidade

Relacionamentos

Representa a associação entre instâncias de entidades diferen-

tes. Analisando o estudo de caso, podemos observar que em diversos
momentos são indicadas situações de referências entre entidades.
Por exemplo, quando falamos que “Cada aluno está vinculado a ape-
nas um curso”, estamos associando a entidade Aluno com a entidade
68
Banco de Dados I

Curso. Como as entidades e os atributos, os relacionamentos devem

ser identificados e mapeados no Modelo E-R.

Os relacionamentos são representados por um nome dentro de

um losango que liga uma entidade a outra. A figura 15 ilustra a repre-
sentação do relacionamento entre as entidades Aluno e Curso.

Relacionamento Aluno – Curso

Cardinalidade
Segundo Medeiros (2007), cardinalidade ou multiplicidade de-
fine a quantidade de elementos de uma entidade que se relaciona com
uma quantidade de elementos de outra entidade.

Quando identificamos os relacionamentos, é necessário definir

as quantidades de associações entre as instâncias das entidades. Em
todo o relacionamento é possível observar quantas instâncias podem
associar-se a instâncias de outra entidade, como também ser refe-
renciadas. Por exemplo, no relacionamento Possui da figura 15, vimos
que um aluno pode estar associado a apenas um curso, ou seja, uma
instância de aluno deve estar associada a apenas uma instância da
entidade Curso, enquanto que um curso pode estar associado a um
conjunto de instância de alunos. Neste caso dizemos que existe uma
relação 1:N ou um para muitos (um curso para muitos alunos). Na fi-
gura 16 podemos observar a representação gráfica da cardinalidade
1:N do relacionamento Possui entre Aluno e Curso.
 69
Tema 2
Modelagem de Dados

Relacionamento Aluno – Curso com Cardinalidade 1:N

Uma forma de definir melhor a cardinalidade de um relaciona-

mento é utilizando o Diagrama de Ocorrência. Um diagrama de ocor-
rência consiste na representação das entidades e do relacionamento
através de exemplos de instâncias das entidades e suas associações
conforme figura 17.

Diagrama de Ocorrência Aluno – Curso

Neste exemplo, os alunos A1 e A2 possuem associação com o

curso C1, enquanto que o curso C2 possui associação com o aluno A3.
Analisando o diagrama, fica fácil observar que um curso está associa-
do a um conjunto de alunos e um aluno está associado a apenas um
curso.

Além do relacionamento 1:N, podemos ter o relacionamento

N:N (muito para muitos) e 1:1 (um para um).

O relacionamento N:N é indicado quando existe a possibilidade

de um conjunto de instâncias de uma entidade se relacionar com um
70
Banco de Dados I

conjunto de instâncias de outra entidade. No nosso estudo de caso

observamos um relacionamento N:N entre as entidade Curso e Disci-
plina através da passagem “Cada curso está associado a um conjunto
de disciplinas, sendo que para cada curso a disciplina é vinculada a um
determinado período curricular. É comum uma disciplina fazer parte
de vários cursos”. Na figura 18 podemos observar a representação
gráfica para relacionamento N:N e respectivo diagrama de ocorrência.

Relacionamento Curso – Disciplina e Diagrama de Ocorrência –

Cardinalidade N:N

Observe que a disciplina D2 está associada aos cursos C1 e C2,

enquanto que o curso C1 está associado às disciplinas D1 e D2.

O relacionamento 1:1 é indicado quando identificamos no texto

uma associação onde apenas uma instância de uma entidade associa-
-se a uma instância de outra entidade. Por exemplo, o relacionamento
entre Professor e Curso identificado através dos fragmentos de texto
“Os cursos de graduação são coordenados por apenas um professor” e
 71
Tema 2
Modelagem de Dados

“Além de ministrar aula, um professor também pode ser coordenador

do curso não podendo acumular mais de uma coordenação”. Na figura
19 podemos observar a representação gráfica para o relacionamento
1:1 e o seu diagrama de ocorrência.

Relacionamento Curso – Professor e Diagrama de Ocorrência –

Cardinalidade 1:1

Observe na figura 19, que o coordenador P1 está associado a

apenas ao curso C1 e o curso de C1 está associado ao professor P1. Não
existe a associação de P1 a outro curso, como também o curso de C1 a
outro professor.
72
Banco de Dados I

LEITURA COMPLEMENTAR

D ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de Banco de

Dados. 4. ed. São Paulo: Pearson Brasil, 2005.

Vimos que o próximo passo, após a definição das entidades, é a iden-

tificação dos atributos. Na seção 3.3.1 deste livro é feita uma classifi-
cação dos tipos de atributos que podem ser identificados. Faça uma
leitura destes tipos e classifique os atributos do estudo de caso con-
forme esta definição.

D SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S.

Sistema de bancos de dados. 3. ed. São Paulo: Makron books,
1999.

O mapeamento das cardinalidade é sempre uma tarefa difícil e que

pode gerar problemas no projeto conceitual e consequentemente no
projeto. Na seção 2.3.1 deste livro o autor trata do mapeamento das
cardinalidade. Faça a leitura desta seção para lhe ajudar a fixa o con-
ceito de cardinalidade e como identificá-las.

PARA REFLETIR
Para concretizar a nossa aprendizagem acesse o Ava e, junto com seus
colegas, identifique as entidades, os atributos e os relacionamentos,
com suas cardinalidades, do estudo de caso identificado como Estudo
de Caso 1.
 73
Tema 2
Modelagem de Dados

2.2
MODELAGEM DE DADOS UTILIZANDO O MODELO DE
ENTIDADE-RELACIONAMENTO

No conteúdo anterior vimos os elementos básicos do Modelo

E-R (entidades, relacionamentos e atributos), agora iremos estudar
variações que envolvem os relacionamentos para que seja possível
gerar o Modelo E-R mais próximo da realidade.

Até agora vimos apenas um tipo de relacionamento, o relacio-

namento binário, o qual envolve duas entidades. Além deste tipo,
também podemos modelar relacionamentos com três entidades –
ternário – ou com apenas uma entidade - recursivo (MEDEIROS,
2007) e ainda realizar generalizações/especializações de entidades.

Relacionamento Ternário
Este tipo de relacionamento ocorre quando identificamos três
entidades que juntas representam alguma informação. Por exemplo,
no fragmento do texto “Ao final do semestre, as disciplinas são asso-
ciadas aos alunos em um determinado período letivo”, observamos um
relacionamento ternário. Quando um aluno cursa uma disciplina, ele
obrigatoriamente deve ter cursado em determinado período letivo. Ou
seja, toda vez que falarmos que um aluno cursou uma disciplina de-
vermos obrigatoriamente dizer que ela foi cursada em determinado
ano/semestre (período letivo). Encontrar o relacionamento ternário
não é uma tarefa complicada, porém identificar a cardinalidade não
desfruta da mesma facilidade. Para encontramos as cardinalidades
temos que “ler” sempre a composição do relacionamento em relação
74
Banco de Dados I

às três entidades e não aos pares. Uma boa estratégia é realizar as

seguintes perguntas: 1. Um aluno em um determinado semestre pode
ter várias disciplinas? Sim, então no lado da entidade Disciplina temos
um relacionamento N. Um aluno em um determinado semestre ge-
ralmente cursa várias disciplinas. 2. Um aluno pode cursar a mesma
disciplina em vários semestres? Sim, ele pode cursar uma disciplina
em um semestre reprovar e cursá-la novamente em outro. Neste caso
termos a cardinalidade N no lado da entidade Período Letivo. 3. Uma
disciplina em determinado semestre pode ser cursada por vários alu-
nos? Sim, geralmente uma disciplina é cursada por vários alunos que
formam várias turmas. Neste caso temos a cardinalidade N no lado da
entidade Aluno. Na figura 20 temos a representação gráfica do rela-
cionamento ternário.

Relacionamento Ternário – Aluno / Disciplina / Período Letivo

Com este relacionamento podemos representar as seguintes

situações:

Período Letivo / Aluno / Disciplina

1 - 2000/2º / Augusto / Engenharia de Software

2 - 2000/2º / João / Engenharia de Software

 75
Tema 2
Modelagem de Dados

3 - 2001/1º / João / Banco de Dados

4 - 2001/1º / Pedro / Banco de Dados

5 - 2001/1º / Pedro / Redes

6 - 2001/1º / Augusto / Engenharia de Software

Agora imagine que a UniGrande não permite que um aluno cur-

se mais de uma vez a mesma disciplina, ou seja, o aluno só poderá
cursar a disciplina em um determinado semestre. Com esta restrição a
situação 6 não poderia acontecer e a resposta à pergunta II seria Não.
Nesta condição a cardinalidade para o lado da entidade Período Letivo
seria 1, conforme representando na figura 21.

Relacionamento Ternário – Aluno / Disciplina / Período Letivo

– Com cardinalidade 1

Relacionamento Recursivo ou Autorrelacionamento

Acontece quando uma entidade se relaciona com ela mesma.
No estudo de caso pode acontecer de instâncias de uma entidade ne-
cessitar se relacionar com outras instâncias da mesma entidade. No
nosso estudo de caso da UniGrande, na parte do texto “É possível cada
76
Banco de Dados I

disciplina ter apenas uma outra disciplina como pré-requisito”, pode-

mos identificar que uma disciplina pode referenciar outra disciplina
para indicar o pré-requisito. Toda vez que isso acontece, identificamos
um relacionamento recursivo ou um autorrelacionamento. Por exem-
plo, a disciplina Banco de Dados possui como pré-requisito a discipli-
na Engenharia de Software, ou seja, existe uma disciplina que neces-
sita se relacionar com outra para poder compor seu pré-requisito. A
representação gráfica deste relacionamento é ilustrada na figura 22.

Relacionamento Disciplina – Disciplina

Generalização/Especialização
Acontece quando uma entidade pode ser subdivida em outras
entidades que possuem características particulares, mas que se as-
semelham em outras características. Por exemplo, a entidade Arqui-
vo pode ter os subtipos Imagem, Áudio e Texto. Todos eles possuem
atributos comuns, como nome e tamanho, porém também possuem
atributos específicos. O arquivo de imagem tem a informação de di-
mensão, o de áudio possui a duração e o texto, a quantidade de carac-
teres. Desta forma, podemos fazer uma modelagem definindo a enti-
dade pai Arquivo e as entidades filhas Imagem, Vídeo e Áudio. Neste
caso todos os atributos definidos na entidade Arquivo serão comuns
a todos os seus filhos, enquanto que atributos definidos nos filhos se-
rão exclusivos de cada um. A figura 23 exibe a representação gráfica
de uma Generalização/Especialização.
 77
Tema 2
Modelagem de Dados

Generalização/Especialização

No estudo de caso da UniGrande podemos observar a generali-

zação/especialização na passagem “A universidade possui dois gran-
des grupos de disciplinas, as chamadas Normais e as de Estágio. Esta
divisão existe, pois as disciplinas de estágio devem ter, além das carac-
terística já citadas, a quantidade mínima de horas que o aluno deve ter
para ser aprovado na disciplina, característica que não existe na disci-
plina normal que possui a quantidade limite de falta para aprovação”.
Neste caso, temos a entidade pai Disciplina dividida entre Normal e
Estágio, conforme representado na figura 24.

Generalização/Especialização - Disciplina
78
Banco de Dados I

Os tipos Normal e Estágio herdam as características da entidade

pai Disciplina e adicionam suas características particulares. Ou seja,
tudo que estiver associado à entidade Disciplina automaticamente se
reflete aos seus filhos. Como no caso do relacionamento entre Curso
e Disciplina, onde um curso ao se relacionar com uma disciplina per-
mite que este relacionamento seja com uma disciplina normal ou de
estágio.

Entidade Associativa
Durante o desenvolvimento do Modelo E-R, podemos identificar
a necessidade de relacionar um relacionamento já definido com outra
entidade. Por exemplo, foi identificado que uma disciplina relaciona-
-se com um ou vários períodos letivos, formando o relacionamento
Oferta. Ou seja, este relacionamento representa as turmas que serão
disponibilizadas em um dado ano/semestre. Porém durante a análise
do estudo de caso foi identificado que para cada turma (uma discipli-
na em um período letivo) é necessário alocar um professor para mi-
nistrar a turma. Não podemos relacionar diretamente à disciplina, pois
o mesmo não irá ministrar a disciplina em todos os semestres, portan-
to a relação deve ser feita com o relacionamento Oferta. Para que seja
possível criar este tipo de relacionamento é necessário transformar o
relacionamento Oferta em uma entidade, sem que esta transforma-
ção exclua as características do relacionamento. Quando realizamos
esta transformação criamos uma Entidade Associativa (a figura 25
ilustra a representação gráfica deste elemento), que na verdade é uma
entidade combinada com um relacionamento.
 79
Tema 2
Modelagem de Dados

Representação gráfica de uma Entidade Associativa

Uma entidade associativa possui todo o comportamento/carac-

terística de uma entidade e ao mesmo tempo todo o comportamento/
característica de um relacionamento.

Obrigatoriedade nos Relacionamentos

Em qualquer relacionamento podemos identificar uma relação
de obrigatoriedade ou não entre as entidades envolvidas. A obriga-
toriedade observa-se verificando em que entidade pode ocorrer ins-
tâncias sem a presença de instâncias da outra entidade. O Modelo E-R
permite a representação da obrigatoriedade através da indicação dos
valores máximo e mínimo para a quantidade de elementos existentes
de uma entidade em relação à outra. Por exemplo, no relacionamento
entre Aluno e Curso, podemos observar o conceito de obrigatoriedade
de forma muito clara. Para representar a obrigatoriedade vamos ex-
pandir a representação da cardinalidade para um par de valores X e Y.
Onde X representa o valor mínimo e Y o valor máximo. Agora vamos
aplicar a obrigatoriedade neste relacionamento, fazendo algumas
perguntas:
80
Banco de Dados I

Pergunta 1: Qual a quantidade mínima de alunos que um curso pode

ter?

Resposta 1: 0

Neste caso representamos do lado do Aluno o valor 0.

Pergunta 2: Qual a quantidade máximo de alunos que um curso pode

ter?

Reposta 2: N

Então representamos no lado do Aluno o valor N. Com isso formamos

o par (0,N) no lado do Aluno indicando que um curso pode ter nenhum
ou vários alunos e que a entidade Aluno não é um elemento obriga-
tório para que um curso exista. Devemos agora fazer as mesmas per-
guntas tendo com base a entidade Aluno.

Pergunta 3: Qual a quantidade mínima de cursos que um aluno pode

estar associado?

Resposta 3: 1

Pergunta 4: Qual a quantidade máxima de cursos que um aluno pode

estar associado?

Resposta 4: 1
 81
Tema 2
Modelagem de Dados

Com estas respostas formamos o par (1,1) que deve ser repre-
sentado no lado da entidade Curso. Agora podemos chegar a conclu-
são que um aluno só existe se estiver vinculado a curso (valor mínimo
1) e que não poderá estar vinculado a mais de um curso. Resumindo,
um aluno só poderá existir se o curso existir. A figura 26 exibe como
devemos escrever o par mínimo e máximo nos relacionamentos.

Obrigatoriedade no Relacionamento Aluno - Curso

Para identificar a obrigatoriedade basta realizar as mesmas

perguntas aos demais relacionamentos do modelo.

A figura 27 traz o DER com a indicação de todas as obrigato-

riedades.
Obrigatoriedade no DER UniGrande
82
Banco de Dados I
 83
Tema 2
Modelagem de Dados

Relacionamentos com Atributos

Quando falamos em atributos, tratamos apenas dos atributos

vinculados às entidades, porém alguns atributos identificados no es-
tudo de caso não ficariam bem localizados na entidade. Quando isso
acontece podemos criar atributos nos próprios relacionamentos. Por
exemplo, no fragmento “Cada curso está associado a um conjunto de
disciplinas, sendo que para cada curso a disciplina é vinculada a um de-
terminado período curricular” do nosso estudo de caso, identificamos
o atributo período. Porém, fica claro que o mesmo só existe quando
acontece um relacionamento entre Curso e Disciplina. Se incluísse-
mos o atributo na entidade Disciplina, não seria possível associar uma
disciplina a outros cursos em períodos diferentes. Vamos a um exem-
plo prático. Imagine que o curso de Informática possui a disciplina Me-
todologia Científica que está localizada no segundo período do curso,
esta mesma disciplina também faz parte do curso de História, porém
neste curso a mesma disciplina fica alocada no terceiro período. Note
que o período da disciplina Metodologia Científica muda de valor con-
forme o curso que está associado, ou seja, conforme o relacionamento
entre Disciplina e Curso. Na figura 28 podemos observar a represen-
tação gráfica de um atributo no relacionamento.

Representação do atributo em um relacionamento

84
Banco de Dados I

Neste conteúdo foi possível observar todos os elementos para

construirmos o Projeto Conceitual de Banco de Dados. Nos próximos
conteúdos iremos trabalhar os conceitos para a construção do Projeto
Lógico de Banco de Dados.

LEITURA COMPLEMENTAR
D ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de Banco de
Dados. 4. ed. São Paulo: Pearson Brasil, 2005.

A seção 4.2.1 deste livro traz mais detalhes sobre Especialização e Ge-
neralização de entidades. A leitura desta seção ajudará você a enten-
der como encontrar e definir especialização e generalização.

D SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S.

Sistema de bancos de dados. 3. ed. São Paulo: Makron books, 1999.

Na seção 2.6 desta obra o autor fala sobre entidades fracas. Não abor-
damos este conceito em nosso estudo preliminar, desta forma faça
a leitura desta seção para entender sobre entidade fraca e como ela
pode ser representada no DER.

PARA REFLETIR
Junto aos seus colegas, identifique situações no seu dia a dia que re-
presentem relacionamentos recursivos e ternários.
 85
Tema 2
Modelagem de Dados

2.3
MODELO RELACIONAL

Vimos que o Modelo E-R é um modelo de dados que representa

de uma forma conceitual a realidade, sem preocupações que regras
de implementação no SGBD. Neste conteúdo veremos o Modelo de
Dados Relacional, cujo objetivo é definir uma estrutura que possa ser
implementada em um SGBD e que ao mesmo tempo represente as
definições do Modelo E-R.

O Modelo Relacional foi criado em 1970 por Ted Codd, pesqui-

sador da IBM, através da publicação de um artigo que apresentava
um modelo de dados extremamente simples e com base matemática
(ELMASRI; NAVATHE, 2005). Veremos agora todos os elementos que
compõe o modelo relacional e como eles podem ser utilizados para
representar um modelo de dados em um SGBD.

Neste modelo, o banco de dados é representado por um conjun-

to de relações, que na verdade são tabelas. Cada tabela representa
uma Entidade e cada linha uma instância da mesma e seus relaciona-
mentos. As colunas de uma tabela definem os valores representati-
vos de cada instância da entidade. Na figura 29 temos um exemplo de
uma tabela no modelo relacional. Neste exemplo, a tabela Alunos está
representando a entidade Aluno e suas instâncias.

Tabela Alunos
86
Banco de Dados I

Na terminologia formal do modelo relacional uma tabela é cha-

mada de relação (por isso Modelo Relacional), uma linha é chamada
de tupla e uma coluna é chamada de atributo.

Além de representar a realidade em forma de tabelas, o modelo

relacional também define um conjunto de validações que devem ser
impostos aos dados. Estas validações são conhecidas como Restri-
ções e garantidas automaticamente pelo SGBD. Veremos agora quais
os tipos de restrições que podem ser expressas no modelo relacional:

1. Restrições de Domínio
São restrições que atuam sobre os dados de uma coluna. A pri-
meira restrição imposta (esta faz parte dos princípios do modelo re-
lacional) é que uma coluna deve ter um valor Atômico, ou seja, cada
coluna deve armazenar um valor e não um conjunto destes valores.
Por exemplo, uma coluna que armazena o telefone de um aluno, deve-
rá armazenar apenas um telefone e não uma coleção. Outra restrição
de domínio diz respeito aos tipos de dados que podem ser atribuídos
a uma coluna. Durante a definição do modelo relacional precisamos
informar o tipo de valor que pode ser atribuído a cada coluna. Ou seja,
é preciso definir se a coluna terá valores do tipo inteiro, real, lógico, ca-
ractere, data, entre outros. Uma vez definido o tipo da coluna, todas as
linhas da tabela deverão ter valores do mesmo tipo, sendo responsa-
bilidade do SGBD garantir que valores que não sejam do tipo definido
não sejam atribuídos. Por exemplo, a coluna media da tabela Alunos
certamente deve ser definida com o tipo real, de forma que a atribui-
ção de um valor caractere deve ser rejeitada pelo SGBD, de forma a
garantir a restrição de domínio e manter a base de dados consistente.
Também é possível definir restrições condicionais, como por exemplo:
o atributo media da tabela Alunos deve ter valores maiores ou iguais
a 0 e menores ou iguais a 10.
 87
Tema 2
Modelagem de Dados

2. Restrições de Atributos Obrigatórios

Atributos que não são obrigatórios são identificados no mode-

lo relacional como NULL, já os atributos que são obrigatórios são re-
presentados como NOT NULL. Na definição do modelo relacional, o
projetista deverá definir a obrigatoriedade de cada campo da tabela.
Por exemplo, o campo que armazena o e-mail de um aluno deve ser
um campo não obrigatório (NULL), pois nem todo o aluno é obrigado
a ter um e-mail. Já o nome deve ser obrigatório (NOT NULL), pois todo
aluno deve ter obrigatoriamente um nome.

O SGBD deve garantir que um atributo definido como NOT

NULL, sempre será preenchido no cadastro da linha.

3. Restrições de Chave
Uma tabela é um conjunto de linhas (ou, uma relação é um con-
junto de tuplas), por definição um conjunto não pode ter elementos
repetidos, desta forma todas as linhas que formam uma tabela devem
ser distintas, ou seja, duas linhas não podem ter a mesma combinação
de valores para suas colunas de forma que pelos menos um valor deve
ser diferente (ELMASRI; NAVATHE, 2005).

Para garantir este conceito, devemos identificar em cada relação

um atributo ou conjunto de atributos que não se repetirá em linhas di-
ferentes da tabela (este atributo é chamado de chave). Imagine uma
tabela que represente os alunos de uma universidade formada pelos
campos nome, cidade e estado. Com esta estrutura é possível que,
ao representar a realidade, existam duas linhas exatamente iguais?
Apesar desta condição ser muito difícil de ocorrer, poderemos ter dois
alunos com nomes iguais e que moram na mesma cidade. Quando não
88
Banco de Dados I

for possível identificar um campo ou conjunto de campos que juntos

sejam únicos dentro do conjunto de linhas, devemos criar um cam-
po que faça isso. Geralmente isso não acontece, pois o próprio estudo
de caso já indica um campo chave de forma implícita, como acontece
com a entidade Aluno, cujo campo chave é a matrícula.

Depois de definir o campo chave de uma tabela, este represen-

tará cada elemento da tabela, assim poderemos utilizar a matrícula
sempre que quisermos identificar um aluno. É possível termos mais
de um campo como chave. Por exemplo, o atributo CPF de um alu-
no poderia, também, ser considerado uma chave, pois o mesmo não
se repete. O modelo relacional define dois tipos de chaves, as chaves
primárias e as chaves candidatas. Chave Primária é a chave que foi
escolhida para representar os elementos da tabela, enquanto que a
Chave Candidata (ou Chave Única) representa uma chave que, ape-
sar de identificar de forma única um elemento na tabela, não será uti-
lizada como identificar do elemento, ou seja, como Chave Primária.
Agora que aprendemos o conceito de chaves, é possível perceber a
necessidade de todo aluno ter um número de matrícula, todo cliente
de um banco ter uma conta corrente, todo produto ter um código de
barras etc. A identificação do atributo chave impede que problemas
de duplicidade em cadastros ocorram como também de identificação
de elementos dentro de uma tabela. Imagine se você fosse realizar
uma transferência para um colega e tivesse que informar o nome dele
ao invés da conta. Junte a este inconveniente a possibilidade de existir
outra pessoa com o mesmo nome de seu colega no banco. Seria im-
possível identificar qual o real destinatário do valor.

Além de resolver os problemas de identificação, a chave primá-

ria tem papel importantíssimo na definição de modelo relacional, pois
através delas são representados os relacionamentos encontrados du-
rante a definição do Modelo E-R.
 89
Tema 2
Modelagem de Dados

Após a definição das chaves primárias e candidatas, o SGBD

deve garantir a validade do banco de dados, impedindo que existam
linhas com os mesmos valores para chave primária ou candidata.

Além de impor a não repetição das chaves primárias e candida-

tas, o SGBD também garante que as chaves primárias não deverão ser
NULL. Esta restrição é imposta, pois com o os atributos vazios não é
possível realizar a distinção das linhas (ELMARSI; NAVATHE, 2005).

4. Restrições de Integridade Referencial

Durante a definição do Modelo E-R identificamos vários rela-
cionamentos. Para implementar estes relacionamentos no modelo
relacional vamos utilizar as Restrições de Integridade Referencial.
Neste tópico vamos entender o conceito de Integridade Referencial
e no próximo conteúdo iremos aprender as regras de transformação
dos relacionamentos em Integridade Referencial.

Integridade Referencial consiste na referência que uma linha de

uma tabela faz em relação à outra linha de outra tabela. Por exemplo,
para podermos indicar o curso que um aluno está vinculado, precisa-
mos definir um atributo na tabela de alunos para referenciar um curso
na tabela de cursos. Este novo campo existe apenas para fazer a refe-
rência e deve armazenar o valor da chave primária da tabela de cur-
sos. Geralmente este campo tem o mesmo nome da tabela de origem,
mas alguns projetistas adotam outro padrão, porém a referência é de-
finida independente dos nomes dos campos equivalentes. Na figura
30 é possível observar a forma de relacionar o um aluno a um curso.
90
Banco de Dados I

Integridade Referencial Alunos – Cursos

O campo criado na tabela Alunos para fazer a referência à ta-

bela Cursos é chamado de Chave Estrangeira e sempre deve estar
associado uma chave primária na tabela de referência. Note que para
implementar o relacionamento definido no Modelo E-R no Modelo Re-
lacional foi necessário criar uma nova coluna. No próximo conteúdo
veremos que será necessário criar novas colunas e até novas tabelas
para podermos representar os relacionamentos no modelo relacional.

O SGBD dever garantir a consistência da referência, ou seja, o

valor do campo de chave estrangeira deve obrigatoriamente existir na
tabela referenciada. Por exemplo, se um aluno for cadastrado e vincu-
lado a um curso de código 5 e este código não existir na tabela Cursos,
o SGBD irá gerar um erro informando do insucesso da operação.

Outros Tipos de Restrição

As restrições que vimos até agora são impostas pelos conceitos
do modelo relacional e já garantem bons resultados quanto à consis-
tência dos dados. Porém, existem restrições que devem ser aplicadas
aos dados e que ultrapassam os limites do modelo relacional. São res-
trições do tipo “o salário de um funcionário não pode ser superior ao
salário do seu superior imediato”, “o aluno não pode cursar uma dis-
ciplina se não tiver cursado os pré-requisitos para ela”, entre outras.
Estas restrições são conhecidas como Restrição de Integridade Se-
 91
Tema 2
Modelagem de Dados

mântica e devem ser implementadas nas aplicações clientes ou atra-

vés de linguagem de definição de restrições que são disponibilizadas
pelos SGBDs.

Operações Que Podem Violar as Restrições

Podemos resumir as operações aplicadas aos dados de um mo-
delo relacional em recuperações e atualizações. Veremos como rea-
lizar estas operações nos temas 3 e 4, agora vamos tratar apenas na
forma como as operações de atualização podem violar as restrições
definidas no modelo relacional. As operações de atualização são: In-
clusão, Alteração e Exclusão. Todas estas operações atuam sobre
uma determinada linha. Vamos ver agora quais violações de restrição
estas operações podem gerar e qual o comportamento do SGBD.

Inclusão (Insert)
Esta operação realiza a inserção de uma linha em uma determi-
nada tabela. Esta inclusão é feita informando as colunas e os valores
para cada coluna da tabela. Nesta operação, poderemos ter a violação
da restrição de domínio, de chave, de obrigatoriedade e de integridade
referencial.

Violação da restrição de domínio: pode ser informado o valor

de campo cujo tipo não seja compatível com a respectiva coluna. Por
exemplo: informar o nome do aluno na coluna de média.

Violação de restrição de chave: ocorre quando é informado um valor

para o campo chave (primária ou candidata) que já existe na tabela. Por
exemplo: informar um número de matrícula que já existe em outra linha.
92
Banco de Dados I

Violação de restrição de integridade referencial: ocorre quando

é atribuído a um campo de chave estrangeira um valor que não existe
na tabela referenciada.

Violação de restrição de atributos obrigatórios: quando for pas-

sado um valor NULL para um campo definido como NOT NULL.

Em todas as violações, o SGBD deve rejeitar a operação exibin-

do a mensagem de erro com informações suficientes para o usuário
identificar o motivo do erro.

Exclusão (Delete)
A única violação que pode acontecer é de integridade referen-
cial. Ocorre quando uma linha de uma tabela que é referenciada por
linhas de outras tabelas é excluída. Por exemplo, se a linha do curso
de código 4 fosse excluída, todos os alunos que fazem referência a
esta curso ficariam sem vínculo com o mesmo. Quando o SGBD de-
tecta esta situação ele pode realizar duas ações: rejeitar a operação
gerando uma mensagem de erro ou propagar a operação, realizando
também exclusões nas linhas que fazem referência a linha excluída.
Esta última operação é chamada de remoção em cascata (ELMASRI;
NAVATHE, 2005). Com esta operação o banco de dados manteria o
seu estado consistente. O SGBD não irá escolher a opção, na verdade
ela é definida no projeto lógico quando a estrutura do banco de dados
será implementada.
 93
Tema 2
Modelagem de Dados

Alteração (Update)

Esta operação realiza a alteração do valor de um ou mais atribu-

tos de uma linha. Durante a operação de alteração, devem ser especi-
ficados os atributos que serão alterados e seus novos valores.

Caso a alteração não seja realizada nos atributos que façam

parte da chave primária ou da estrangeira, a única violação que pode
ocorrer é de domínio. Porém, quando ocorrer a alteração do valor de
um campo de chave primária, poderemos ter violações de:

Restrição de Chave: quando o atributo chave for alterado para

um valor que já existe na tabela. Neste caso, o SGBD irá rejeitar a ope-
ração;

Integridade referencial: quando o atributo alterado já possui seu

valor referenciado por outra tabela. Quando é detectada esta situação
o SGBD poderá rejeitar a operação ou propagá-la, realizando a mesma
alteração nas tabelas que fazem referência ao valor. Por exemplo, se o
código do curso de Direito fosse alterado de 4 para 5, todos os alunos
que faziam referência ao curso 4 teriam seu valor alterado automati-
camente para 5;

Restrição de atributos obrigatórios: Quando for associado um

valor NULL a um atributo definido como NOT NULL.

Todas as operações de atualização (inclusão, alteração e exclu-

são) podem também violar as Restrições de Integridade Semântica.
Neste caso, a responsabilidade é do programador da aplicação, o qual
deverá detectar e tomar a ação correta seja rejeitando ou realizando
outra ação para manter o banco de dados consistente.
94
Banco de Dados I

LEITURA COMPLEMENTAR

D ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de Banco de

Dados. 4. ed. São Paulo: Pearson Brasil, 2005.

Nos conteúdos que estudamos aprendemos em como realizar a mo-

delagem de dados utilizando o Modelo E-R. Para representar esta
modelo fizemos uso de uma notação diagramática proposta por Peter
Chen. Apesar desta ser a mais comum, outras notações também são
bastante utilizadas. No apêndice A deste livro, você encontrará a indi-
cação de outras notações para a modelagem de dados.

D SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S.

Sistema de bancos de dados. 3. ed. São Paulo: Makron books, 1999.

Neste conteúdo falamos sobre modelo relacional e vimos que as opera-

ções que envolvem o modelo relacional são basicamente recuperações
e atualizações. A seção 3.2 deste livro apresenta todos os conceitos da
Álgebra Relacional, que consistem em um conjunto de operações que po-
dem ser aplicadas a um modelo relacional para recuperação de dados. A
leitura deste capítulo é fundamental para o entendimento dos próximos
temas, pois os mesmos conceitos aplicados na Álgebra Relacional serão
aplicados nos comandos de recuperação de dados na linguagem SQL.

PARA REFLETIR
Vimos que o SGBD pode rejeitar operações que violem as restrições
de integridade referencial ou simplesmente propagá-la através do
efeito “cascata” em eventos de alteração e exclusão. Debata com seus
 95
Tema 2
Modelagem de Dados

colegas, sobre as vantagens e desvantagens em utilizar a definição

para rejeitar a operação ou para propagá-la em casos de violações de
integridade referencial.

2.4
PROJETO DE BANCO DE DADOS

Como foi visto no conteúdo 2.1, após realizar a modelagem E-R,

o próximo passo é construir o Projeto Lógico de banco de dados que
consiste no mapeamento do Modelo E-R para o Modelo Relacional de
forma a gerar o modelo de dados lógico. O objetivo do projeto lógico é
encontrar as tabelas do modelo relacional que irão atender ao Modelo
E-R definido. Para isso vamos utilizar todos os conceitos que trata-
mos no conteúdo 2.3.

Precisamos do projeto lógico de banco de dados (ou modelo ló-

gico) para adaptar o Modelo E-R às regras do modelo relacional o qual
pode ser entendido pelo SGBD. Além disso, o Modelo E-R não define
as restrições que vimos no conteúdo anterior, que são de fundamental
importância para aplicações que utilizam banco de dados.

Mapeamento de Entidades
Começamos o nosso projeto lógico realizando o mapeamento
das entidades e atributos. Cada entidade é transformada em uma ta-
bela (relação) e seus atributos transformados em colunas. Os atribu-
96
Banco de Dados I

tos identificados como chave, deverão compor a chave primária da

tabela. Durante este mapeamento não é obrigatório manter os nomes
das entidades ou dos atributos. A figura 31 ilustra todas as tabelas
originárias das entidades do modelo de estudo. Note que já podemos
definir os tipos de dados das colunas e as obrigatoriedades.

Mapeamento das Entidades para Tabelas

Geralmente neste mapeamento trocamos os nomes das entida-

des pelo seu equivalente no plural. Também é comum neste trabalho
alterarmos o nome dos campos para possibilitar a sua implementação
no SGBD. Esta alteração consiste em abreviar alguns nomes, retirar
os espaços e os acentos. Este mapeamento ainda não está completo,
trabalhamos apenas com a definição das tabelas e das colunas, mas
ainda estão faltando os mapeamentos dos relacionamentos, que, em
 97
Tema 2
Modelagem de Dados

algumas situações irão gerar novas tabelas. Veremos agora como re-
alizar este mapeamento.

Mapeamento do Relacionamento 1:N

Para implementar este relacionamento deve-se identificar a ta-
bela gerada a partir da entidade do lado N. Após esta identificação,
deve ser adicionado a esta tabela os atributos que fazem parte da cha-
ve primária da tabela do lado 1, formando assim a chave estrangeira.
Esta operação permite que a tabela do lado N faça referência aos va-
lores da tabela do lado 1. Na figura 32, o relacionamento das entidades
Aluno e Curso é implementado através da criação do campo cod_cur-
so na tabela Alunos. Este campo irá armazenar os valores do código
do curso ao qual o aluno está vinculado.

Mapeamento dos relacionamentos 1:N

98
Banco de Dados I

Mapeamento do Relacionamento N:N

Quando é identificado relacionamento N:N, devemos criar uma

nova tabela cujo atributos serão as chaves primárias das tabelas en-
volvidas. Estes campos formarão a chave primária da nova tabela e
ao mesmo tempo serão a chave estrangeira para a respectiva tabela.
Por exemplo, existe um relacionamento N:N para as entidades Curso e
Disciplina em nosso estudo de caso. As colunas que formam as tabe-
las Cursos e Disciplinas possuem a seguinte estrutura:

Cursos: { #cod_curso, nom_curso}

Disciplinas: { #cod_disc, nom_disc, creditos}

Quando aplicamos a regra de mapeamento do relacionamento

N:N, o relacionamento Matriz que envolvia as entidades Curso e Disci-
plina é transformada na tabela Matrizes formada pelas chaves primá-
rias das tabelas Cursos e Disciplinas e mais os atributos que estavam
diretamente ligados ao relacionamento, como o atributo período, con-
forme estrutura a seguir:

Matrizes: { #cod_curso, #cod_disc, periodo }

Uma chave primária formada por mais de

um campo é chamada de Chave Primária
Composta.
 99
Tema 2
Modelagem de Dados

Veja que a chave primária da tabela Matrizes é formada por

duas colunas, desta forma é possível realizar combinações de valores
que garantem o relacionamento N:N, conforme exemplificado nas ta-
belas 5, 6 e 7:

Tabela de Cursos

Cursos

cod_curso nom_curso

10 Informática

12 Direito

Tabela de Disciplinas

Disciplinas

cod_disc nom_disc creditos tipo_disc

1 Direito penal 4 Normal

2 Metodologia 4 Normal

3 Algoritmo 8 Normal

Relacionamento NxN entre Cursos e Disciplinas

Matrizes

cod_curso cod_disc periodo

10 2 1

10 3 2

12 1 4

12 2 1
100
Banco de Dados I

Quando uma chave primária é composta a restrição de integri-

dade para a chave só é violada quando todas as colunas formadoras
da chave são iguais. Neste caso podemos fazer combinações entre
cod_curso e cod_disc, permitindo associar um curso a várias disci-
plinas e uma disciplina a vários cursos. A figura 33 ilustra o modelo
relacional incluindo o relacionamento N:N.

Mapeamento dos Relacionamentos N:N

Mapeamento do Relacionamento 1:1

A solução para implementar este relacionamento é a mesma
utilizada no relacionamento 1:N, com a diferença que poderemos criar
a chave estrangeira em qualquer uma das tabelas. No nosso estudo
de caso temos o relacionamento Coordena, que envolve as entidades
Professor e Curso. Pela regra do estudo de caso, um professor pode
 101
Tema 2
Modelagem de Dados

ser coordenador de um e apenas um curso e curso só pode ter um

coordenador. Vamos ver agora como ficaria a implementação deste
relacionamento na tabela Professores e na tabela Cursos.

Para implementar na tabela Cursos, basta adicionar o campo

cod_prof, que fará a representação do professor que é coordenador
do curso. Como o curso deve ter obrigatoriamente um coordenador,
este campo deve ser obrigatório. A figura 34 ilustra o resultado deste
mapeamento.

Mapeamento do Relacionamento 1:1

Para a tabela Professores, devemos adicionar a coluna cod_cur-

so, a qual representará o curso que o professor coordena. Ao contrário
da solução anterior, o campo deve ser não obrigatório, pois um pro-
fessor pode não ser coordenador de um curso. As tabelas 8 e 9 trazem
exemplos deste relacionamento:

Tabela de Cursos

Cursos

cod_curso nom_curso

10 Informática

12 Direito
102
Banco de Dados I

Tabela de Professores – Relacionamento 1:1

Professores

Cod_prof nom_prof cod_curso

1 Professor 01 10

2 Professor 02 12

3 Professor 03

Note que o campo cod_curso do Professor 03 está vazio, indi-

cando que este professor não é coordenador.

Em ambas as soluções, o campo adicionando deve ser defini-

do como Chave Candidata, de forma a não permitir a repetição de um
mesmo valor. Veja o exemplo da tabela 10:

Tabela de professores em representação da chave candidata

Professores

Cod_prof nom_prof cod_curso

1 Professor 01 10

2 Professor 02 12

3 Professor 03 10

Neste caso, o curso 10 estaria associado a dois professores, si-

tuação que não estaria de acordo com o estudo de caso. A definição da
chave candidata para a coluna cod_curso não permitiria tal situação.
 103
Tema 2
Modelagem de Dados

Mapeamento do Autorrelacionamento

Para realizar o mapeamento do autorrelacionamento, deve-se

aplicar as mesmas regras que vimos anteriormente. No nosso mode-
lo observamos a existência do autorrelacionamento na entidade Dis-
ciplina através do relacionamento Pré-Requisito. Aplicando a regra,
temos que criar uma nova coluna na tabela do lado N composta pela
chave primária da tabela do lado 1, ou seja, vamos criar uma nova co-
luna na própria tabela Disciplinas. Desta forma, teríamos a seguinte
estrutura para a tabela disciplina:

Disciplinas = { #cod_disc, nom_disc, creditos, tipo_disc, (cod_

disc_pre) }

O campo cod_disc_pre, foi definido como não obrigatório, pois

uma disciplina não tem obrigatoriedade de ter um pré-requisito. A ta-
bela 11 representa um exemplo desta estrutura:

Autorrelacionamento da tabela disciplinas

Disciplinas

cod_disc nom_disc qtd_cred tipo_disc cod_disc_pre

1 Introdução ao 4 Normal
Direito

2 Direito Penal I 4 Normal 1

104
Banco de Dados I

Podemos observar neste exemplo que a disciplina “Direito Pe-

nal I” possui como equivalente a disciplina “Introdução Direito” e que
este não possui pré-requisito, pois não existe valor para o campo cod_
disc_pre.

Mapeamento do Relacionamento Ternário

A regra do mapeamento ternário é a mesma do relacionamen-
to binário N:N. Deve ser criada uma nova tabela cuja chave primária é
formada pelas chaves primárias das tabelas envolvidas. Para mapear
este relacionamento criamos a tabela Históricos, cuja chave primária
é formada pelas chaves primárias das tabelas Disciplinas, Alunos e
Períodos_Letivos. A figura 35 exibe o mapeamento do relacionamen-
to ternário.

Mapeamento do Relacionamento Ternário

 105
Tema 2
Modelagem de Dados

Com este mapeamento podemos combinar várias situações

diferentes entre cursos, disciplinas e alunos, como exemplificado na
tabela 12.

Tabela de históricos – relacionamento ternário

Historicos

ano semestre mat_alu cod_disc media

2011 1 10 10 5,0

2011 2 10 12 10,0

2011 1 11 10 7,5

2010 2 10 10 8,0

Generalização/Especialização
Para mapear esta situação devem ser adicionados todos os atri-
butos de todas as entidades filhas na tabela pai. Desta forma, a tabela
pai terá todas as colunas necessárias para seus filhos. Por exemplo: no
nosso estudo de caso a entidade Disciplina é especializada em Estágio
e Normal, sendo que a entidade filha Estágio possui o atributo horas e
entidade Normal limite de faltas. Para mapear esta categorização, de-
vem ser criadas as colunas horas e limite_faltas na tabela Disciplinas,
os quais devem ser não obrigatórios. Para completar o mapeamento,
deve ser criada uma coluna adicional que indicará qual o tipo da disci-
plina. Esta coluna, que no nosso mapeamento chamamos de tipo_disc,
irá indicar o tipo da disciplina (estágio ou normal) e consequentemen-
te se o campo horas e limite_faltas devem ou não ser preenchidos. A
combinação de valores ficaria conforme a tabela 13:
106
Banco de Dados I

Generalização/Especialização – Tabela de disciplinas

Disciplinas

cod_disc nom_disc tipo_disc cod_disc_pre horas_obrig limite_faltas

1 Disc 01 Normal 18

2 Disc 02 Normal 1 18

3 Disc 03 Estágio 40

Para que este mapeamento funcione, a aplicação deve garantir

a correta combinação entre o campo que indica o tipo e os campos
relacionados.

Com este mapeamento completamos o nosso mapeamento para

o modelo lógico. No Ava você encontrará o modelo lógico completo.

Para completar nosso projeto lógico, precisamos agora definir o

tipo de dados de todas as colunas e algumas restrições (além das já de-
finidas pelo próprio modelo relacional). Se você já sabe em qual SGBD
será implementada a solução, estes tipos já podem ser os específicos
do SGBD escolhido, se não, podem ser utilizados tipos “genéricos”, os
quais serão substituídos durante as atividades de definição do projeto
físico do banco de dados. Embora seja mais comum fazer esta definição
dos tipos utilizando os tipos específicos do SGBD escolhido, vamos uti-
lizar os tipos genéricos uma vez que no próximo tema vamos aprender
sobre os tipos de dados de um determinado SGBD e como implementar
o modelo utilizando declarações DDL. Para o nosso estudo vamos defi-
nir os seguintes tipos genéricos: Texto, Inteiro, Real e Data.

Este trabalho deve ser feito analisando todos os campos do mo-

delo e para cada um deles definir: tipo de dado, tamanho e restrições.
Esta definição deve ser feita utilizando o modelo representado na ta-
bela 14:
 107
Tema 2
Modelagem de Dados

Modelo para representação de tabelas

Alunos

Nome Tipo Tamanho Obrigatório Restrição

Mat_alu Inteiro 10 Sim Mat_alu > 0

Nom_alu Texto 80 Sim Not null

Cod_curso Inteiro 2 Sim Cod_curso>0

Chave Mat_alu
Primária

Chave Cod_curso -> Cursos

Estrangeira1

Após o preenchimento destas tabelas, o modelo de dados pode-

rá ser implementado em um SGBD apenas realizando a troca dos ti-
pos genéricos pelos específicos. Atualmente existem vários softwares
que já realizam a implementação do modelo automaticamente, sem
necessidade do projetista de banco de dados ou DBA escrever código
DDL para isso. No Ava você poderá encontrar a definição completa de
todas as tabelas do nosso modelo.

Com modelo pronto, encerramos o projeto lógico do nosso ban-

co de dados, o próximo passo é construir o projeto físico.

LEITURA COMPLEMENTAR
D MACHADO, Felipe; ABREU, Maurício. Projeto de Banco de Da-
dos: Uma Visão Prática. São Paulo: Érica, 2007.
108
Banco de Dados I

Após a finalização de todas as etapas do projeto de banco de dados,

é possível encontrar problemas no modelo gerados por estruturas de
tabelas incorretas. Estes problemas geralmente envolvem redundân-
cia de dados e acarretam problemas de atualização. O capítulo 12 des-
te livro aborda o assunto Normalização, cujo objetivo é identificar e
corrigir estes problemas. A leitura deste capítulo contribuirá bastante
na construção de um projeto de banco de dados de qualidade.

ESTUDO DE CASO
No Ava está disponibilizado um estudo de caso e todos os documen-
tos que representam as etapas do projeto de banco de dados. Faça a
leitura deste estudo de caso e analise os documentos criados para fi-
xar os conhecimentos vistos neste conteúdo. Este estudo de caso está
identificado como Estudo de Caso 2.

PARA REFLETIR
Neste conteúdo falamos da forma de mapeamento das generaliza-
ções/especializações. Existem outras estratégias que podem ser utili-
zadas para realizar este mapeamento. Junto com seus colegas identi-
fique quais são estas estratégias realizando uma análise comparativa
com a que foi demonstrada neste conteúdo.
 109
Tema 2
Modelagem de Dados

RESUMO
Neste tema tratamos sobre as etapas que envolvem a construção de
um banco de dados e o que devemos definir em cada uma delas. Vi-
mos que todo o processo inicia-se com o levantamento de requisitos,
onde um profissional entrevista o usuário para coletar todas as infor-
mações necessárias para construir o modelo. Com as informações co-
letadas são realizados o projeto conceitual, onde é definido o modelo
conceitual (DER), o projeto lógico, onde é realizado o mapeamento
para o modelo relacional e por último o projeto físico quando o modelo
relacional é implementado no SGBD.

Nos próximos temas iremos aplicar os conceitos vistos neste tema na

prática através do uso do SGBD Oracle e da linguagem SQL.
Anotações