BANCO_DE_DADOS_-_CAP._2_PARTE_I_

Prévia do material em texto

29
Linguagem de Programação
MODELAGEM DE DADOS
Olá!
Imagino que esteja ansioso por “colocar a mão na massa” – imple-
mentar um banco de dados na prática. Isso é bom, mas ainda deve-
mos conter nossa ansiedade.
Antes de sair criando tabelas, relacionamentos e consultas, devemos 
aprender a projetar um banco de dados que atenda satisfatoriamen-
te aos objetivos de nossos usuários.
Um banco de dados bem modelado demandará pouca ou nenhuma 
manutenção corretiva num futuro próximo. Por isso, é conveniente des-
pender parte de seu tempo inicial de trabalho projetando ou modelan-
do o banco de dados propriamente dito. Uma vez concluída essa etapa, 
pode-se finalmente dedicar tempo à criação do banco de dados com 
suas tabelas, relacionamentos, consultas, visões, procedimentos etc.
Na modelagem de um banco de dados, nos concentramos nos 
objetivos que pretendemos atender com essa tecnologia. Se pre-
tendemos criar um banco de dados para um sistema de controle 
acadêmico que permita armazenar dados sobre alunos, turmas, 
disciplinas, notas e frequências, quais serão as tabelas necessárias 
e seus respectivos atributos?
E se o sistema objetivar gerenciar o atendimento de consultas médicas 
em uma clínica? Certamente serão outras as tabelas e atributos neces-
sários. Mas, quais serão essas tabelas e como se relacionarão entre si?
Neste capítulo abordaremos a modelagem conceitual de dados. Um 
modelo conceitual objetiva projetar os requisitos de negócio segundo 
a perspectiva do usuário-final. Tendo em vista apenas o modelo re-
lacional de banco de dados, não precisamos ainda determinar qual 
SGBD utilizaremos para implementar nosso banco de dados, não 
importando se o SGBD será o Oracle, o Microsoft SQL-Server, o 
Sybase, o PostgreeSQL, o Firebird ou o MySQL. O que modelaremos 
pode ser implementado em qualquer SGBD relacional.
Trabalharemos, com especial destaque, com o Modelo de Entidade e 
Relacionamentos (ER).
Bom estudo!
Prof. Vanderson José Ildefonso Silva
30
Técnico em Informática
2.1 Modelo entidade-relacionamento
O Modelo Entidade-Relacionamento (MER) é uma técnica criada em 
1976 por Peter Chen (CHEN, 1990) que expressa graficamente a estru-
tura lógica de um banco de dados. A aplicação dessa técnica resulta na 
elaboração de um diagrama composto dos seguintes elementos:
Entidades:1. representadas graficamente por um retângulo, as entida-
des são “coisas” ou “objetos” que deverão ser armazenados em um 
banco de dados. Médico e paciente, por exemplo, são claramente 
entidades em um banco de dados projetado para suportar um sis-
tema de agendamento de consultas (Figura 6). Afinal, tal sistema 
seria impossível de implementar sem o armazenamento de dados 
relativos aos médicos que atendem na clínica e aos pacientes que 
agendam consultas com esses profissionais.
 Figura 6 – Representação Gráfica das Entidades Médico e Paciente
Atributos: 2. são características ou propriedades relevantes de uma 
entidade. Por “relevantes” pretendemos destacar que nem todas as 
informações sobre uma entidade são pertinentes para o modelo: sa-
ber qual a cor do cabelo do paciente ou o time de futebol para o qual 
um médico torce em nada contribui para a marcação de uma con-
sulta. Por outro lado, o nome do paciente, sua data de nascimento 
(forma de manter atualizada sua idade), um telefone para contato, o 
endereço e o sexo a que pertence (“feminino” ou “masculino”) são 
informações que podem ser classificadas como relevantes para o 
contexto (Figura 7).
 Figura 7 – Entidades e seus respectivos atributos
Médico Paciente
Médico
Nr_CRM
Nome
Celular
Paciente
Matricula
Nome
Endereço
Telefone
Celular
Genero
Capítulo 2 
31
Linguagem de Programação
Relacionamentos: 3. são vínculos ou associações lógicas entre duas 
ou mais entidades. Em alguns casos particulares, um relacionamen-
to pode ser estabelecido entre uma entidade e ela mesma (autor-
relacionamento). Porém, a forma mais comum de relacionamento 
é entre duas entidades. As Figuras 8, 09 e 10 apresentam variados 
exemplos de relacionamentos. Eles são representados por uma linha 
com um losango sobreposto e um verbo que o identifica. No inte-
rior desse losango há geralmente uma seta indicando o sentido da 
leitura do verbo. Na Figura 8, por exemplo, podemos ler que “mé-
dico atende paciente”. Por sua vez, a Figura 09 demonstra um rela-
cionamento entre três entidades simultaneamente (relacionamento 
ternário). Nesse caso não usamos o verbo e nem a seta, apenas o 
losango na junção das linhas. A vantagem desse relacionamento em 
relação ao da Figura 08 é que se torna possível saber qual o plano 
de saúde utilizado pelo paciente em uma determinada consulta com 
um dado médico. A Figura 10 exemplifica um relacionamento entre 
uma entidade e ela mesma (o autorrelacionamento). Nesse caso, um 
funcionário pode coordenar os trabalhos de outros funcionários. 
Esse relacionamento nos permite identificar quais funcionários são 
coordenados por outros funcionários.
Figura 8 – Relacionamento entre duas entidades
Figura 09– Relacionamento entre três entidades (ternário)
Figura 10 – Relacionamento de uma entidade consigo mesma(autorrelacionamento)
Médico Paciente
atende
Médico
Plano de Saúde
Paciente
coordena
Funcionário
Modelagem de Dados
32
Técnico em Informática
Atividade 10
Faça um diagrama que demonstre relacionamentos coerentes en-
tre as seguintes entidades de um Restaurante: Mesa, Prato, Gar-
çon e Comanda (pedidos feitos pelos ocupantes da mesa). Indique 
para cada entidade um conjunto de atributos adequados.
2.1.1 A Cardinalidade de relacionamentos
A cardinalidade é uma característica de todo relacionamento no Mo-
delo Entidade-Relacionamento (MER). Indica com quantas ocor-
rências de uma entidade as ocorrências de uma outra entidade po-
dem se relacionar.
A Figura 11 mostra um autorrelacionamento ainda sem a indicação 
da cardinalidade. A novidade do exemplo está na utilização dos cha-
mados indicadores de papéis (“Marido” e “Esposa”). Ele pode ser 
lido como “pessoa casa com pessoa”. A indicação dos papéis apenas 
torna claro que, no casamento, algumas pessoas têm o papel de ma-
rido e outras, o de esposa.
Figura 11– Autorrelacionamento com indicação de Papéis.
A ausência de cardinalidade nos impossibilita uma melhor compreen-
são das regras envolvidas nesse casamento entre pessoas. Em algumas 
sociedades é permitido que um homem se case com várias mulheres. 
Caso nosso banco de dados precise refletir esse costume, devemos im-
por um relacionamento de cardinalidade um-para-muitos (1:N), como 
mostrado na Figura 12.
casa com
Pessoa
Marido Esposa
Capítulo 2 
33
Linguagem de Programação
Figura 12 – Cardinalidade Um-para-Muitos (1:N)
O relacionamento da Figura 12 exemplifica as regras de uma sociedade 
poligâmica, na qual um homem pode ter várias esposas. Então lemos 
que “uma (1) pessoa (Marido) pode casar-se com muitas (N) pesso-
as (Esposas)”. Define, também, que “uma pessoa (Esposa) somente 
pode casar-se com uma pessoa (Marido)”. Portanto, os direitos não 
são iguais nessa sociedade e a cardinalidade define isso com clareza. Um 
homem pode ter várias mulheres, mas uma mulher pode ter apenas um 
homem como marido.
Os atributos da entidade Pessoa evidenciados na figura acima são:
Identificador:1. código que possibilite distinguir uma pessoa de ou-
tra sem que haja confusões.
Nome:2. nome completo da pessoa. Não serviria para identificar com 
precisão uma pessoa, dada a possibilidade da ocorrência de homô-
nimos (pessoas com o mesmo nome. Ex: José da Silva).
Sexo:3. classificação das pessoas conforme seu sexo: “F” para femini-
no e “M” para masculino.
IdentificadorMarido: 4. atributo que será utilizado apenas pelas pessoas 
do sexo feminino. Geralmente, sociedades poligâmicasnão demons-
tram tolerância com casamentos de pessoas do mesmo sexo. Esse atri-
buto ou terá valor nulo (para homens e mulheres solteiras) ou conterá 
o identificador de uma pessoa do sexo masculino (o marido).
A Figura 13 apresenta uma tabela em banco de dados relacional que 
corresponderia a uma implementação do diagrama da figura anterior, 
no qual um homem poderia ter várias esposas, mas, uma mulher, so-
mente um marido.
casa com
Pessoa
Identificador
Nome
Sexo
IdentificadorMarido
Marido Esposa
1 N
Modelagem de Dados
34
Técnico em Informática
Figura 13 – Tabela Pessoa correspondente a Entidade Pessoa
Observamos que, pelos dados da tabela Pessoa, Altair Ramos tem três 
esposas (Martha, Sueli e Ângela). Essas mulheres possuem o seu número 
identificador na coluna (atributo) IdentificadorMarido. Por outro lado, 
Karla apresenta esse atributo sem a indicação de qualquer número (va-
lor nulo). Significa que Karla é solteira. Rita de Cássia (pessoa de identi-
ficador = 6) é casada com Ricardo Souza (pessoa de identificador = 5).
Devemos destacar que a cardinalidade indicada não implica a obriga-
toriedade de cada homem ter mais de uma esposa. No exemplo, Ricardo 
tem apenas uma esposa, e poderiam ainda existir homens solteiros.
Suponhamos agora que uma verdadeira revolução de costumes tenha 
acontecido nessa sociedade poligâmica. A partir de agora, os homens 
somente poderão se casar com uma mulher, mas uma mulher poderá 
casar-se com muitos homens (poliandria). Nosso MER sofreria uma 
alteração em sua cardinalidade, deixando de apresentar um relaciona-
mento um-para-muitos (1:N) para assumir um relacionamento mui-
tos-para-um (N:1).
A Figura 14 mostra o resultado dessa mudança para uma sociedade 
poliândrica. Curiosamente, essa figura quase não difere da Figura 12. 
As únicas alterações perceptíveis são a troca de posições entre “N” e 
“1” na indicação da cardinalidade, além da substituição do atributo 
IdentificadorMarido pelo IdentificadorEsposa. Portanto, a ordem 
dos fatores influi sobre o resultado final. O relacionamento agora indi-
ca que “uma pessoa (Marido) pode casar-se com apenas uma pessoa 
(Esposa)” e que “uma pessoa (Esposa) pode casar-se com muitas 
pessoas (Maridos)”.
Pessoa
Identificador Nome Sexo IdentificadorMarido
1 Altair Ramos M
2 Karla Ramalho F
3 Martha Ramos F 1
4 Sueli Cantagalo F 1
5 Ricardo Souza M
6 Rita de Cássia F 5
7 Ângela Paneton F 1
Capítulo 2 
35
Linguagem de Programação
 Figura 14 – Cardinalidade Muitos-para-Um
Essa estranha sociedade foi de um extremo (poligamia) a outro (polian-
dria). Agora consideremos que homens e mulheres negociaram uma sa-
ída mais equilibrada, tornando essa sociedade monogâmica. Essa nova 
situação é representada na Figura 15.
 Figura 15– Cardinalidade Um-para-Um
Mais uma vez deparamos com pequenas mudanças: o atributo Identi-
ficadorConjuge substitui o atributo IdentificadorEsposa ou Identifi-
cadorMarido; e a cardinalidade do relacionamento agora é Um-para-
Um (1:1). Não temos mais o indicador “N” (que simboliza “muitos” 
ou “vários”). Dessa forma, agora um homem pode casar-se com ape-
nas uma mulher simultaneamente e uma mulher, com somente um 
homem por vez.
Esgotamos todas as possibilidades de cardinalidade para esse relacio-
namento? Certamente que não. Ainda há a possibilidade de que um ho-
mem possa casar-se com muitas mulheres e que também uma mulher 
possa casar-se com muitos homens. Esse seria um relacionamento de 
cardinalidade Muitos-para-Muitos (N:N).
casa com
Pessoa
Identificador
Nome
Sexo
IdentificadorEsposa
Marido Esposa
1N
casa com
Pessoa
Identificador
Nome
Sexo
IdentificadorConjuge
Marido Esposa
11
Modelagem de Dados
36
Técnico em Informática
A Figura 16 exemplifica essa situação de Muitos-para-Muitos. Nes-
se caso as mudanças são substanciais e merecem uma explicação 
mais detalhada.
 Figura 16 – Cardinalidade Muitos-para-Muitos
Olhando para a Figura 16, percebemos que um retângulo tracejado 
apareceu sobre o losango do relacionamento. Essa é uma consequên-
cia direta de qualquer relacionamento de cardinalidade Muitos-para-
Muitos. Esse retângulo tracejado corresponde a uma relação e, como 
tal, possui nome (Casamento) e atributos (IdentificadorMarido e 
IdentificadorEsposa).
Transpondo essa situação para um banco de dados relacional, encontra-
mos duas tabelas: Pessoa e Casamento, exemplificado na Figura 17.
casa com
Pessoa
Identificador
Nome
Sexo
Casamento
IdentificadorMarido
IdentificadorEsposa
N N
Capítulo 2 
37
Linguagem de Programação
Figura 17 – Banco de Dados equivalente ao Modelo ER da Figura 16
Conforme os dados apresentados na Figura 17, Eduardo Licoli (Iden-
tificador = 1) possui duas ocorrências na tabela Casamento. Uma vez 
que é do sexo masculino, seu Identificador aparece na coluna (atributo) 
IdentificadorMarido. Significa que Eduardo é casado com duas mulhe-
res: Ana Paula Souza (Identificador = 2) e Cecília Castro (Identificador 
= 6). Como essas pessoas são do sexo feminino, seus identificadores são 
reproduzidos na coluna IdentificadorEsposa da tabela Casamento. Por 
analogia, Ronaldo Silvestre é casado com três mulheres: Ana Paula Sou-
za, Cibele Tornado e Cecília Castro. Sérgio Couto continua solteiro, pois 
não tem ocorrências na tabela Casamento.
Atividade 11
Acrescente a cardinalidade aos relacionamentos da Atividade 10.
2.1.2 Exemplos do modelo entidade-relacionamento
Considere um banco de dados que objetive manter informações atua-
lizadas sobre os projetos desenvolvidos por uma empresa e as equipes 
responsáveis por esses mesmos projetos. Todos os integrantes das equi-
pes são funcionários da empresa. Cada projeto é gerenciado por um 
funcionário e as equipes podem ser formadas por um número indeter-
Pessoa
Identificador Nome Sexo
1 Eduardo Lincoli M
2 Ana Paula Souza F
3 Ronaldo Silvestre M
4 Cibele Tornado F
5 Anabela Couto F
6 Cecília Castro F
7 Sérgio Souto M
Casamento
IdentificadorMarido IdentificadorEsposa
1 2
1 6
3 2
3 4
3 6
Modelagem de Dados
38
Técnico em Informática
minado de funcionários. Independentemente dos projetos, cada funcio-
nário possui uma função específica na empresa (administrador, analista 
de sistemas, contador, engenheiro, etc.).
De cada projeto importa armazenar seu número identificador, nome, data 
de início, data prevista de conclusão e data efetiva de conclusão. Em relação a 
cada funcionário é importante guardar sua matrícula, nome, sexo e função.
A Figura 18 apresenta um diagrama ER que modela o banco de dados 
proposto. Nela há três relacionamentos, três entidades e uma relação.
Observe que conforme modelado, um funcionário pode gerenciar muitos 
projetos, mas um projeto pode ser gerenciado apenas por um funcioná-
rio. Por outro lado, um funcionário pode trabalhar em muitos projetos 
(simultaneamente ou ao longo do tempo), e cada projeto pode ter muitos 
funcionários nele trabalhando. Também é verdade que um funcionário 
possui apenas uma função, mas uma função pode pertencer a muitos fun-
cionários. Portanto, um funcionário não pode ser contador e programador 
de computadores ao mesmo tempo, mas a empresa pode, por exemplo, ter 
mais de um programador de computadores dentre seus funcionários.
Como indicam os atributos do modelo, um projeto ainda em andamen-
to apresentaria a Data_Final_Efetiva com valor nulo. A existência de 
uma Data_Final_Prevista e de uma Data_Final_Efetiva permite ava-
liar o atraso de um projeto em andamento ou já concluído.
Figura 18 – Exemplo de Diagrama ER
Funcionário
Matricula
Nome
Sexo
Função
Possui
trabalha em
Id_Função
Descrição
Projeto
Equipe
1
1 N
N
N
N
Matricula
Numero
Numero
Nome
Data_Inicio
Data_Final_Prevista
Data_Final_Efetiva
Capítulo2 
39
Linguagem de Programação
Consideremos agora a modelagem de um banco de dados desenvolvido 
para o gerenciamento de uma biblioteca. Para efeito de simplificação, 
essa biblioteca empresta apenas livros. Não há revistas ou dvds em seu 
acervo. Também é vetado ao usuário dessa biblioteca reservar um livro 
indisponível no momento como em algumas bibliotecas em que o usuá-
rio pode entrar em uma fila de reservas, de modo que, ao ser devolvido 
um exemplar do livro reservado, os usuários que fizeram a reserva po-
dem, conforme a ordem que ocupam na fila, requisitar o empréstimo do 
livro. Como dito, nossa biblioteca não dispõe desse serviço. Por outro 
lado, o banco de dados modelado deve prover os seguintes requisitos:
(1) Manter dados sobre as obras do acervo, como nome dos autores, 
data da aquisição, editora, edição e título.
(2) Manter registro de todos os livros de uma mesma obra.
(3) Efetuar o empréstimo e a devolução de livros, mantendo registros 
detalhados dos mesmos ao longo do tempo.
(4) Consultar livros por código de identificação, título da obra, nome de 
autores e gênero da obra (autoajuda, dicionário, literatura, etc.).
(5) Manter dados sobre os usuários da biblioteca: matrícula, nome, sexo, 
data de nascimento, endereço e telefone.
A Figura 19 mostra o diagrama ER para o sistema de informação dessa 
biblioteca. Não se assuste com o tamanho; embora seja maior que o an-
terior, ainda é bem menor que a média em uma situação real.
Repare que foram usadas duas entidades – Obra e Livro – em vez de 
uma com todos os seus atributos. Você deve estar se perguntando o 
porquê dessa decisão. Embora, a princípio, pareça correto utilizar 
uma entidade com todos esses atributos, na verdade eles pertencem 
a entidades diferentes.
A entidade Livro, por exemplo, refere-se a uma edição em particular de 
uma obra. Considere uma obra do século XIX, como Helena, de Ma-
chado de Assis, um clássico da literatura brasileira em sua fase român-
tica, que já foi publicada por diferentes editoras ao longo de mais de 
um século de existência. Portanto, a entidade Editora não poderia estar 
relacionada à entidade Obra, mas sim à entidade Livro, como demons-
trado na Figura 19. Se fosse diferente, essa obra somente poderia ser 
publicada por uma editora.
Modelagem de Dados
40
Técnico em Informática
Figura 19 – Diagrama ER do Sistema de Gerenciamento de Biblioteca
Por analogia, o atributo Edição não pode estar na entidade Obra, mas na 
entidade Livro. Afinal, somente livros publicados de uma mesma obra 
podem ter edições diferentes. Nessa biblioteca, por exemplo, podem 
existir 30 livros da obra Helena. Desses, 10 foram publicados pela edi-
tora Guanabara em 1981 e são da quinta edição e 4 desses livros adqui-
ridos mais recentemente foram publicados pela editora Martin Claret.
A entidade Autor se relaciona à entidade Obra, pois se estivesse relaciona-
da a Livro implicaria o relacionamento pouco justificável de seus autores 
a cada livro adquirido pela biblioteca. Nesse caso, se 50 livros da obra de 
Alexandre Dumas, Os Três Mosqueteiros, fossem doados para a bibliote-
publica
referencia
classifica
escreve
movimenta
Movimentação
Autoria
1
1
1
NN
N
N
N
N
N Usuário
Matrícula
Nome
Sexo
Data_Nascimento
Telefone
Celular
E_Mail
Endereço
Matrícula
Nr_Livro
Data_Emprestimo
Data_Prevista
Data_Devolução
Autor
Id_Autor
Nome
Obra
Nr_Obra
Título
Nr_Obra
Id_Autor
Livro
Nr_Livro
Data_Aquisição
Edição
Editora
Id_Editora
Nome_Fantasia
Gênero
Id_Gênero
Descrição
Capítulo 2 
41
Linguagem de Programação
ca, um funcionário deveria relacionar sua ocorrência a 50 ocorrências de 
Livros. Contudo, o relacionamento de Autor com Obra evita esse traba-
lho. O autor Alexandre Dumas seria relacionado a uma única obra e esta, 
por sua vez, aos 50 livros dessa mesma obra. O funcionário da biblioteca 
agradece seu empenho em tornar sua tarefa menos árdua.
Olhando o diagrama ER da Figura 19, notamos que um gênero pode 
classificar várias obras, mas que uma obra pode ser classificada por um 
gênero. Assim, Helena e Os Três Mosqueteiros podem ser classificadas 
como Literatura. Porém, nenhuma dessas obras pode ser classificada em 
mais de um gênero simultaneamente.
Um autor pode escrever muitas obras e uma obra pode ser escrita por 
muitos autores. Em razão da cardinalidade N:N surgiu a relação Au-
toria (o retângulo tracejado), cobrindo a possibilidade de obras com 
mais de um autor, comum em livros didáticos ou em uma coleção de 
artigos científicos.
Um livro pode referenciar apenas uma obra, mas uma obra pode ser 
referenciada por muitos livros.
Uma editora pode publicar muitos livros, mas um livro pode ser publi-
cado apenas por uma editora.
Um usuário pode movimentar vários livros e um mesmo livro pode ser 
movimentado por vários usuários ao longo do tempo. Mais uma vez a 
cardinalidade N:N faz emergir a relação Movimentação. Essa relação ar-
mazena os empréstimos e devoluções de livros efetuados na biblioteca.
Quando a biblioteca empresta um livro para um usuário, uma ocorrên-
cia de movimentação é gerada com o atributo Data_Devolução nulo e 
Data_Empréstimo com a data atual do sistema. Na devolução do livro 
essa movimentação é atualizada com a alteração do atributo Data_De-
volução para a data corrente do sistema.
Um terceiro e último exemplo de um diagrama ER está na Figura 20.
Modelagem de Dados
42
Técnico em Informática
Figura 20 – Diagrama ER para Marcação de Consultas Médicas
Nesse caso temos um banco de dados modelado para suportar um sis-
tema de gerenciamento da marcação de consultas médicas. Na verda-
de, deve estar lembrado, já fizemos algumas considerações acerca desse 
contexto (Figuras 7 a 10), mas ainda não havíamos apresentado seu 
diagrama completo.
O referido diagrama foi modelado a partir dos seguintes requisitos:
armazenar dados de médico: número de registro no Conselho Re-1. 
gional de Medicina (CRM), nome completo, sexo, telefone fixo, ce-
lular e e-mail para contato.
armazenar informações de paciente: número identificador, nome 2. 
completo, sexo, telefone fixo e celular.
identificar as especialidades de cada médico (um mesmo médico 3. 
pode atuar, por exemplo, como clínico geral e dermatologista).
agendar consultas para um paciente, especificando o plano de saúde 4. 
e o médico.
possui
N N
N
N
N
Médico
CRM
Nome
Sexo
Telefone
Celular
E-Mail
Paciente
Consulta
Especialista
Id_Paciente
Nome
Sexo
Telefone
Celular
Especialidade
Cod_Especialidade
Descrição
Plano_Saude
Id_Plano
Nome_Fantasia
CRM
Cod_Especialidade
CRM
Data
Hora
Id_Plano
Id_Paciente
Capítulo 2 
	BANCO DE DADOS - CAPÍTULO 2
	BANCO DE DADOS - PARTE I