BANCO_DE_DADOS_-_CAP._2_PARTE_II_

Prévia do material em texto

43
Linguagem de Programação
como simplificação do modelo não será necessário armazenar os 5. 
horários de atendimento semanal para cada médico. Considerare-
mos apenas que todos os médicos atendem todos os dias úteis da 
semana em um horário fixo e igual para todos.
Note que Consulta é uma relação gerada a partir de um relacionamento 
ternário entre as entidades Médico, Paciente e Plano_Saúde.
2.1.3. Generalização / especialização de entidades
Existem situações em que diferentes entidades apresentam algumas ca-
racterísticas em comum, divergindo apenas em algumas outras poucas 
características. Na Figura 21, por exemplo, temos duas entidades nessa 
condição de semelhança: Médico e Paciente.
 Figura 21 – Entidades com Atributos em Comum
Essas entidades foram extraídas do exemplo de diagrama ER da Figura 
21. Repare que ambas apresentam 4 atributos em comum: nome, sexo, 
telefone e celular. Médico ainda possui dois atributos exclusivos: CRM 
e e-mail. Por sua vez, a entidade Paciente apresenta um único atributo 
somente seu: Id_Paciente.
Nesse e em casos semelhantes podemos lançar mão de um recurso pre-
visto na modelagem de dados, conhecido como generalização. Então, 
uma nova entidade, mais genérica – ou se preferir, menos especializada 
– deve ser criada para agregar os atributos comuns.
Na Figura 22 temos uma entidade de nome Pessoa que assume esse papel de 
entidade menos especializada. Essa nova entidade chama para si os atribu-
tos comuns das entidades mais especializadas: Médico e Paciente. O símbolo 
triangular que interliga essas entidades indica que os atributos de Pessoa são 
compartilhados por Médico e Paciente, ou seja, Médico e Paciente herdam os 
atributos de Pessoa. Entretanto, o atributo de Id_Paciente pertence somente a 
Paciente; e CRM e E_Mail são atributos exclusivos de Médico.
Médico
CRM
Nome
Sexo
Telefone
Celular
E_Mail
Paciente
Id_Paciente
Nome
Sexo
Telefone
Celular
Modelagem de Dados
44
Técnico em Informática
Figura 22 – Exemplo de Generalização / Especialização
Generalização: entidades de um nível mais baixo de abstração, 
com características comuns; são agrupadas, dando origem a uma 
entidade de nível mais alto.
Especialização: uma entidade de nível mais alto de abstração é 
desmembrada em várias entidades de nível mais baixo, com ca-
racterísticas parcialmente distintas.
Atividade 12
Construa um diagrama ER completo para um sistema de super-
mercado que permita as seguintes funcionalidades:
(1) Manter informações sobre produtos (código, nome, preço uni-
tário, quantidade em estoque e estoque mínimo);
(2) Registrar vendas de produtos nos caixas;
(3) Registrar recebimentos – discriminando o tipo: em dinheiro, 
cheque, cartão de débito, ou cartão de crédito.
Pessoa
Nome
Sexo
Telefone
Celular
Paciente
Id_Paciente
Médico
CRM
E_Mail
Capítulo 2 
45
Linguagem de Programação
2.1.4 Entidades fracas
Uma entidade fraca é qualquer entidade cuja existência no modelo ER 
não se justiça por si mesma. Essa entidade surge apenas em razão do 
relacionamento desta com uma outra entidade, considerada forte. A 
chamada entidade fraca deve apresentar identificadores compostos 
(formados pelo menos por dois atributos). Um desses atributos deve 
ser originário da entidade forte. Ele é replicado na entidade fraca para 
estabelecer uma ligação entre ocorrências das duas entidades.
Um exemplo clássico de entidade fraca é demonstrado na Figura 23. 
Dependente é a entidade fraca, pois a identificação de um dependente 
é impossível sem a identificação do sócio. Na verdade, os dependentes 
não existiriam se não houvesse os sócios.
Figura 23 – Exemplo de Entidade Fraca (Dependente)
2.2 Modelo relacional normalizado
O Modelo Entidade-Relacionamento (MER) constitui apenas a pri-
meira etapa da chamada modelagem de dados para a implementação 
de um banco de dados que poderá ser parte de um sistema de banco de 
dados. Desenvolvido pelo analista de sistemas, o MER é considerado 
um modelo conceitual do banco de dados em implementação. Como 
afirmado anteriormente, o MER pode ser elaborado antes mesmo da 
definição do Sistema Gerenciador de Banco de Dados (SGBD) em que 
a solução será implementada. A única restrição imposta pelo modelo 
ER é a escolha de um SGBD também relacional.
Uma vez concluída esta etapa, a equipe de analistas de sistemas deve ocu-
par-se do projeto lógico do banco de dados, também conhecido como 
1 N
Sócio
Id_Sócio
Nome
Sexo
Endereço
Telefone
CPF
RG
Data_Nascimento
Id_Sócio
Id_Dependente
Nome
Sexo
Data_Nascimento
Dependente
Modelagem de Dados
46
Técnico em Informática
o Modelo Relacional Normalizado (MRN). Nessa fase o projetista deixa 
de ocupar-se exclusivamente com os requisitos levantados junto ao usuá-
rio demandante do banco de dados. Não que esteja autorizado a ignorar 
as necessidades e desejos do usuário e possa, a partir de agora, impor di-
tatorialmente a sua própria vontade. Em momento algum os requisitos do 
usuário-final devem ser ignorados. Ao ocupar-se com o MRN, o analista 
de sistemas deve também preocupar-se com a forma de armazenamento 
das informações em um banco de dados relacional.
Na elaboração do modelo conceitual do banco de dados (o modelo ER), 
ignoramos alguns importantes conceitos que, agora, durante o modelo 
lógico, não podemos mais deixar de considerar. O mais básico desses con-
ceitos e nosso ponto de partida nesta etapa é a chamada chave primária.
2.2.1 Chave primária
Em bancos de dados relacionais as informações são armazenadas em ta-
belas, sendo essencialmente organizadas em linhas e colunas. Cada linha 
de uma tabela corresponde a uma ocorrência da informação. Assim, em 
uma tabela de alunos (Figura 24), cada linha (ou registro) corresponde ao 
conjunto de informações inter-relacionadas de um aluno em particular. 
As colunas (ou campos) correspondem a subdivisões lógicas ou compar-
timentos para diferentes informações contidas em uma mesma linha.
Na tabela Aluno da Figura 24, cada linha foi subdividida em 5 colunas 
(Matrícula, Nome, Sexo, Nascimento e Curso). No exemplo apresenta-
do existem 6 linhas armazenando as informações de 6 diferentes alunos 
de uma instituição de ensino. Os dados armazenados nas colunas de 
uma mesma linha são relativos a um mesmo aluno. Assim, podemos 
afirmar que o aluno de nome Rodrigo Bívar tem matrícula 1099, é do 
sexo masculino, nasceu em 25 de dezembro de 1992 e cursa informática. 
Também podemos confirmar que a aluna Karina Gonçalves encontra-se 
matriculada no curso de Biologia com a matrícula 1203.
Figura 24 – Tabela Aluno
Aluno
Matrícula Nome Sexo Nascimento Curso
1099 Rodrigo Bívar M 25/12/1992 Informática
1100 Ximene Lascasas F 13/09/1996 Informática
1203 Karina Gonçalves F 03/11/1998 Biologia
1399 José da Silva M 27/02/1995 Matemática
1500 Cesário Antunes M 16/12/1999 Farmácia
1701 José da Silva M 03/10/1991 Informática
Capítulo 2 
47
Linguagem de Programação
Uma tabela como essa pode armazenar centenas ou milhares de linhas (re-
gistros). Imaginar a complexidade da tarefa de localizar um registro espe-
cífico em meio a milhares de outros na mesma tabela é algo que não exige 
muito esforço. Uma ou mais colunas podem servir para identificar uma li-
nha em específico, distinguindo-a de todas as demais linhas existentes.
Supondo que desejamos acessar os dados de um aluno em específico, a 
busca pela linha que armazena esses dados deve ser parametrizada pelo 
valor de uma ou mais colunas, mas não de qualquer coluna. Afinal, di-
ferentes alunos podem, por exemplo, ter o mesmo nome. Na Figura 24, 
essa situação encontra-se exemplificada nas linhas 4 e 6 da tabela, onde 
estão registrados dois alunos de nome José da Silva. A possibilidade de 
ocorrência de alunos homônimos desqualifica a coluna nome como uma 
colunaadequada para a identificação de um registro em particular.
A Figura 25 mostra o resultado de uma busca na tabela Aluno com o 
critério de pesquisa Nome = “José da Silva”. O fato dessa busca/con-
sulta resultar na apresentação de mais de uma linha evidencia a inade-
quação da coluna Nome na identificação de uma linha em particular. 
Embora com mesmo nome, os alunos são pessoas diferentes, com datas 
de nascimento distintas.
Figura 25 – Resultado da Busca por Aluno de Nome = “José da Silva”
Por outro lado, a utilização da coluna Matrícula como critério de pes-
quisa mostra-se perfeitamente adequada para a identificação de uma 
única linha. Afinal, não podem existir dois alunos com um mesmo nú-
mero de matrícula. A Figura 26 exemplifica o resultado de uma busca 
utilizando a coluna Matrícula como critério de pesquisa.
Figura 26 – Resultado da Busca por Aluno de Matrícula = 1701
 
Matrícula Nome Sexo Nascimento Curso
1399 José da Silva M 27/02/1995 Matemática
1701 José da Silva M 03/10/1991 Informática
 
Matrícula Nome Sexo Nascimento Curso
M1701 José da Silva 03/10/1991 Informática
Modelagem de Dados
48
Técnico em Informática
Ao conjunto de um ou mais atributos que permite identificar 
com precisão uma única linha de uma tabela dá-se o nome de 
superchave.
Na Figura 27 é apresentada a entidade Funcionário dotada de 12 atri-
butos. Destes, podemos selecionar algumas superchaves: Carteira_
Identidade é certamente uma superchave, pois não deve existir mais 
de um funcionário com o mesmo número da carteira de identidade. 
Entretanto, essa não é a única superchave. CPF também pode ser 
considerado uma superchave, assim como a combinação de atributos 
{Nome e Carteira_Identidade}, ou {Nome e CPF}, ou ainda {Nome, 
Carteira_Identidade e CPF}.
Figura 27 – Atributos da Entidade Funcionário
Como destacado anteriormente, o atributo Nome isoladamente não 
pode ser considerado uma superchave. Porém, sua combinação com 
outros atributos pode formar superchaves. É o caso da combinação 
{Nome, Logradouro}.
Nome
Sexo
Data_Nascimento
Carteira_Identidade
CPF
Logradouro
Complemento
Bairro
Cidade
UF
CEP
Telefone
Funcionário
Capítulo 2 
49
Linguagem de Programação
Chaves candidatas são um subconjunto específico das chamadas 
superchaves. Somente podem ser chaves candidatas as chamadas 
superchaves mínimas.
Ou seja, uma superchave formada pela combinação de mais de 
um atributo pode ser classificada como uma chave candidata 
apenas se essa combinação não possuir qualquer subconjunto 
próprio que seja ele mesmo uma superchave. Veja o exemplo do 
CPF a seguir.
Portanto, a combinação de atributos {Nome, CPF}, apesar de ser super-
chave, não pode ser uma chave candidata, pois {CPF} também é super-
chave e subconjunto da combinação. O mesmo vale para a combinação 
{Carteira_Identidade, CPF, Nome}, que não é chave candidata, pois 
existem inúmeros subconjuntos que são superchaves.
A entidade Funcionário possui várias chaves candidatas: {CPF}, {Car-
teira_Identidade} e {Nome, Logradouro}.
Chave primária é uma chave candidata escolhida pelo projetista 
de banco de dados. Ela é o principal meio de identificação unívoca 
de uma linha em uma entidade.
Toda chave primária obedece às seguintes regras:
(1) Não pode conter valor nulo (a chave primária é de preenchi-
mento obrigatório. Não pode ser omitida);
(2) Não pode conter valores duplicados (não pode existir na enti-
dade mais de uma linha com o mesmo valor de chave primária).
A Figura 28 mostra as entidades e relações do sistema de marca-
ção de consultas com suas respectivas chaves primárias. Observe 
que a distinção na representação gráfica entre entidades e relações 
desapareceu. De fato, no Modelo Relacional Normalizado (MRN) 
as relações deixam de ser representadas por linhas tracejadas e são 
tratadas como as entidades.
Modelagem de Dados
50
Técnico em Informática
Figura 28– Chaves Primárias nas Entidades do Sistema de Marcação de Consultas
Graficamente, as chaves primárias são representadas em uma faixa es-
treita abaixo do nome das entidades. Todo atributo no interior dessa 
faixa é parte da chave primária.
A escolha da chave primária é relativamente fácil para algumas entida-
des. O atributo CRM foi escolhido para ser a chave primária de Médi-
co, pois podem compartilhar do mesmo nome e sexo, mas não podem 
existir dois médicos com o mesmo registro no Conselho Regional de 
Medicina. Os atributos telefone, celular e e-mail costumam ser únicos, 
como toda chave primária, mas costumam mudar com muita facilidade 
ao longo do tempo.
Código da especialidade foi selecionado para ser a chave primária de 
Especialidade. Embora a descrição da especialidade também seja única, 
o código geralmente apresenta um menor tamanho, ocupando menos 
espaço de armazenamento e o que demanda menor esforço de digita-
ção e memorização da parte do usuário-final. O mesmo é válido para a 
identificação do plano de saúde, que é preferível ao nome fantasia para 
ser a chave primária da entidade Plano de Saúde.
A entidade Especialista não apresenta atributos próprios. CRM é origi-
nário da entidade Médico e o código da especialidade – como dito em 
seu nome – é proveniente da entidade Especialidade. Diante da escassez 
de atributos, ambos foram combinados para a formação de uma chave-
primária composta. Afinal, nenhum desses atributos isoladamente fun-
ciona adequadamente como chave primária. Se apenas o CRM fizesse 
parte da chave primária, não teríamos como registrar um médico com 
Médico
Nome
Sexo
Telefone
Celular
Email
CRM
Paciente
Nome
Sexo
Telefone
Celular
Id_Paciente
Especialidade
Descrição
Cod_Especialidade
Plano_Saude
Nome_Fantasia
Id_Plano
Especialista
Cod_Especialidade
CRM
Consulta
Data
Hora
Id_Plano
CRM
Id_Paciente
Capítulo 2 
51
Linguagem de Programação
mais de uma especialidade nessa entidade. Para tanto, precisaríamos re-
petir o CRM e chaves primárias não aceitam duplicação de valores. Por 
outro lado, se apenas o código da especialidade fizesse parte da chave 
primária, não teríamos como registrar mais de um médico para uma 
mesma especialidade. Afinal, isso exigiria a impossível replicação de có-
digos de especialidade.
A solução encontrada, de definição da chave primária com a combi-
nação dos dois atributos, é a ideal. Nesse caso, o que não pode repetir 
é a combinação dos valores desses atributos. Ficamos assim impedidos 
de registrar um médico com a mesma especialidade mais de uma vez. 
Entretanto, nada nos impede de registrar o mesmo médico para dife-
rentes especialidades ou a mesma especialidade para diferentes médi-
cos. Isso exigiria a replicação do CRM ou do código de especialidade 
isoladamente, mas não a repetição conjunta do CRM e código da es-
pecialidade simultaneamente.
Qualquer entidade sempre apresentará uma e apenas uma chave 
primária. Contudo, uma chave primária pode ser formada por 
um único atributo (chave primária simples) ou por uma combi-
nação de dois ou mais atributos (chave primária composta).
A entidade Consulta possui dois atributos próprios: data e hora. Porém, 
sua chave primária é composta principalmente por atributos originários 
de outras entidades: Identificador do paciente, CRM e Data. Assim como 
no caso da entidade Especialista, a replicação dos valores de um desses 
atributos isoladamente é perfeitamente possível. Somente a repetição 
dos valores dos três atributos simultaneamente seria problemática.
2.2.2 Chave estrangeira
O conceito de chave estrangeira é tão importante para os bancos de da-
dos relacionais quanto o de chave primária.
Modelagem de Dados
52
Técnico em Informática
Chave estrangeira é um atributo ou conjunto de atributos ori-
ginário de uma entidade que é replicado em outra. Essa repli-
cação tem porobjetivo estabelecer uma associação entre linhas 
das duas entidades.
Sem as chaves estrangeiras seria impossível criar relacionamen-
tos entre entidades no modelo relacional.
Uma chave estrangeira em uma determinada entidade sempre 
será uma chave primária em sua entidade de origem.
Na Figura 29 é apresentado um diagrama ER para o contexto de uma 
instituição de ensino que oferece variados cursos. Cada aluno pode 
matricular-se em apenas um curso, mas cada curso pode ter muitos 
alunos. Caso um aluno resolva fazer mais de um curso, precisará de 
nova matrícula.
Ao longo do curso, o aluno pode frequentar muitas disciplinas e uma 
disciplina pode ser frequentada por muitos alunos. Desse relaciona-
mento de cardinalidade N:N, surge a relação Histórico – onde podem 
ser registradas as notas e frequências obtidas pelo aluno.
Um curso pode possuir muitas disciplinas e uma mesma disciplina 
pode pertencer a muitos cursos simultaneamente. Desse relacionamen-
to de cardinalidade N:N surge a relação Grade_Curricular, que mantém 
informações sobre as disciplinas que fazem parte de cada curso, assim 
como o período a que pertencem.
Capítulo 2 
53
Linguagem de Programação
Figura 29 – Diagrama Entidade-Relacionamento
Observe que no relacionamento N:1 entre Aluno e Curso nenhuma cha-
ve estrangeira aparece. No modelo Entidade-Relacionamento (MER), 
a chave estrangeira não aparece explicitamente. Ela é apenas sugerida 
pela existência do relacionamento. Uma exceção ocorre nos relaciona-
mentos de cardinalidade N:N. Note que a relação Histórico apresenta 
atributos que não são originários dela mesma: Matrícula é proveniente 
da entidade Aluno e Cod_Disciplina, da entidade Disciplina. O mesmo 
com Grade_Curricular: Cod_Curso vem da entidade Curso e Cod_Dis-
ciplina, da entidade Disciplina.
A Figura 30 mostra o relacionamento entre as tabelas Aluno e Curso. A 
chave estrangeira aparece na tabela Aluno em vez de na tabela Curso. 
Conforme explicado no primeiro capítulo, essa é a melhor solução (ver se-
ção 1.4.3, sobre o modelo relacional). Caso a chave estrangeira residisse 
na tabela Curso, teríamos um nível exagerado de replicação dos dados.
possui
cursa
Matricula-se em
N
N
N
N N
1
Cod_Disciplina
Nome_Disciplina
Carga_Horária
Ementa
Disciplina
Grade_Curricular
Histórico
Aluno
Matricula
Nome_Aluno
Sexo
Nascimento
Cod_Curso
Cod_Disciplina
Período
Matrícula
Cod_Disciplina
Semestre
Nota_Final
Frequência
Condição
Curso
Cod_Curso
Nome_Curso
Modelagem de Dados
54
Técnico em Informática
Existe uma regra bem simples para a determinação de qual tabela 
deve apresentar a chave estrangeira em um relacionamento de 
cardinalidade 1:N ou N:1. Nesses casos, a tabela do lado “N” do re-
lacionamento sempre fica com a chave estrangeira (que é a chave 
primária da entidade da extremidade “1” do relacionamento).
Quando a cardinalidade é N:N, a chave estrangeira fica com ne-
nhuma das tabelas localizadas na extremidade do relacionamen-
to. Afinal todas as extremidades são “N”. Sob essa situação de 
equilíbrio é natural que as chaves estrangeiras – provenientes das 
tabelas das extremidades – permaneçam na relação que emerge 
no centro do relacionamento.
Figura 30 – Tabelas Aluno e Curso (destaque para a chave estrangeira).
No exemplo da Figura 30, a tabela Aluno passou a contar com o atributo 
Cod_Curso como uma chave estrangeira, pois, em seu relacionamento 
com a tabela Curso, encontra-se do lado “N” da cardinalidade 1:N.
Ao contrário de uma chave primária, a chave estrangeira pode 
conter valores nulos.
Atividade 13
Determine as chaves primárias e estrangeiras para cada entidade 
do diagrama ER desenvolvido na Atividade 12.
Aluno
Matrícula Nome_Aluno Sexo Nascimento Cod_Curso
12359 José da Silva M 14/02/1985 INF
12360 Asdrúbal Linhares M 20/12/1982 SAN
12361 Andressa Simões F 25/08/1986 SAN
12390 Desidério Silva M 03/10/1989 MAT
13000 Lina Silva F 22/09/1996 INF
Curso
Cod_Curso Nome_Curso
INF Informática
MAT Matemática
SAN Saneamento Ambiental
Capítulo 2 
	BANCO DE DADOS - CAPÍTULO 2
	BANCO DE DADOS - PARTE I