Projeto de Banco de Dados

Projeto de Banco de Dado Profa.
Marina Teresa Pires Vieira

Universidade Federal de So Carlos
Departamento de Computao

Projeto de Banco de Dados

Prof
a
Marina Teresa Pires Vieira

Maro 2000

ltima reviso: Abril 2002

Projeto de Banco de Dado Profa. Marina Teresa Pires Vieira 1
PROJ ETO DE BANCO DE DADOS
1. Conceitos de Modelagem de Dados............................................................................. 3
1.1. Processo de Projeto de Banco de Dados .........................................................................3
1.2. Modelos de Dados Semnticos.........................................................................................5
1.2.1. Abstraes no Projeto Conceitual de Banco de Dados.........................................................6
1.3. Modelo EER (Extended Entity-Relationship)................................................................7
1.3.1. Modelo ER...............................................................................................................................7
1.3.2. Extenso do Modelo ER..........................................................................................................9
1.4. Exerccios ........................................................................................................................12
2. Questes no Projeto Conceitual de um Banco de Dados......................................... 15
2.1.Introduo........................................................................................................................15
2.2. Projeto de Viso..............................................................................................................15
2.2.1. Projeto de Viso com base em Linguagem Natural ...........................................................15
2.2.2. Projeto de Viso com base em Formulrios........................................................................18
2.2.4. Exerccios - Projeto de Viso................................................................................................23
2.3. Integrao de Vises.......................................................................................................26
2.4. Estudo de Caso: Gerenciamento de uma Biblioteca...................................................28
2.5. Melhorando a Qualidade de um Esquema de Banco de Dados.................................32
2.5.1. Qualidades de um esquema de BD.......................................................................................32
2.5.2. Transformaes de Esquema ...............................................................................................35
2.5.2.1. Transformaes para conseguir minimalidade ...............................................................35
2.5.2.2. Transformaes para conseguir Expressividade.............................................................36
2.5.2.3. Transformaes para obter Normalizao ......................................................................38
2.5.3. Reestruturao do esquema de Gerenciamento de uma Biblioteca..................................41
2.6. Exerccio..........................................................................................................................42
3. Projeto Lgico de Banco de Dados........................................................................... 45
3.1. Refinamento do Esquema Conceitual...........................................................................45
3.1.1. Particionamento de Entidades .............................................................................................46
3.1.2. Fuso de entidades ................................................................................................................48
3.1.3. Reproduo de atributos ......................................................................................................48
3.2. Mapeamento para o Modelo Relacional.......................................................................48
3.2.1. Exerccios Mapeamento.....................................................................................................53
3.3. Tpicos Adicionais sobre Modelagem de Dados e Mapeamento Anlise de diferentes
situaes..................................................................................................................................54
3.3.1.Categorizao - mapeamento................................................................................................54
3.3.2. Atividades de extenso - fazer o esquema conceitual .........................................................55
3.3.3. Docentes e Docentes Bolsistas - fazer o esquema conceitual..............................................56
3.3.4. A modelagem satisfaz aos requisitos dos usurios?...........................................................57
3.3.5. Elaborao de Esquemas Conceituais .................................................................................58
3.4. Esquema de Navegao para Operaes de Banco de Dados.....................................60
3.4.1. Exerccios - Esquema de Navegao....................................................................................63
3.5. Modelagem da Carga do Banco de Dados....................................................................64
4. Projeto Fsico de Banco de Dados........................................................................ 67
Estruturas de Armazenamento - OpenI ngres............................................................... 67
4.1. HEAP...............................................................................................................................67
4.2. HASH...............................................................................................................................68
4.3. ISAM...............................................................................................................................70
4.4. Btree.................................................................................................................................71
4.5. ndices Secundrios........................................................................................................73
5. Bibliografia.........................................................................................................................74

1. Conceitos de Modelagem de Dados

1.1. Processo de Projeto de Banco de Dados

Bancos de dados so componentes importantes dos sistemas de informao (SIs)
e, consequentemente, o projeto do banco de dados apresenta-se como uma atividade
essencial na fase de desenvolvimento dos SIs. Projetar bancos de dados tem se tornado
uma atividade popular, as vezes realizada no somente por profissionais da rea de
banco de dados, mas tambm por no especialistas. Freqentemente, a falta de
abordagens adequadas para o projeto de um banco de dados pode incorrer em resultados
indesejveis, como ineficincia em atender a demanda de aplicaes e problemas com a
manuteno do banco de dados. Geralmente a causa disso a falta de clareza em
entender a natureza exata dos dados em um nvel conceitual (abstrato).
O projeto de um banco de dados decomposto em Projeto Conceitual, Projeto
Lgico e Projeto Fsico, conforme mostrado na figura 1.1.

Requisitos
de dados

Esquema conceitual

Esquema Lgico

Esquema Fsico

Fig. 1.1

O Projeto Conceitual usa como base a especificao dos requisitos produzindo
como resultado o esquema conceitual do banco de dados. Um esquema conceitual
Projeto
Conceitual
Projeto
Lgico
Projeto
Fsico
uma descrio em alto nvel da estrutura do banco de dados, independente do Sistema
de Gerenciamento de Banco de Dados (SGBD) adotado para implement-lo. Um
modelo conceitual (por exemplo, o modelo Entidade-Relacionamento) usado para
descrever os esquemas conceituais.
O propsito do projeto conceitual descrever o contedo de informao do
banco de dados ao invs das estruturas de armazenamento que sero necessrias para
gerenciar essa informao.
O Projeto Lgico tem por objetivo avaliar o esquema conceitual frente s
necessidades de uso do banco de dados pelos usurios/aplicaes, realizando, no
mesmo, possveis refinamentos para alcanar maior desempenho das operaes sobre o
banco de dados. A tarefa final do projeto lgico a gerao do esquema lgico
correspondente ao esquema conceitual resultante do refinamento . Um esquema lgico
uma descrio da estrutura do banco de dados que pode ser processada por um
Sistema Gerenciador de Banco de Dados (SGBD). Um modelo lgico usado para
especificar esquemas lgicos. Os modelos lgicos mais conhecidos para bancos de
dados convencionais, pertencem a trs classes: relacional, em redes e hierrquico, sendo
o modelo relacional o mais amplamente usado atualmente. O projeto lgico depende da
classe do modelo de dados usado pelo SGBD, mas no do SGBD especfico usado.
O Projeto Fsico toma por base o esquema lgico para construir o esquema
fsico. Um esquema fsico uma descrio da implementao do banco de dados em
memria secundria; ele descreve as estruturas de armazenamento e mtodos de acesso
usados para efetivamente realizar o acesso aos dados. O projeto fsico direcionado
para um SGBD especfico (por exemplo: Oracle, Sybase, OpenIngres, Access).
Decises tomadas durante o projeto fsico, para melhorar o desempenho, podem afetar a
estrutura do esquema lgico.
Uma vez que o projeto fsico do banco de dados completado, os esquemas
lgico e fsico so expressos usando a linguagem de definio de dados do SGBD
adotado. O banco de dados criado e populado e pode ser testado para se tornar
operacional.
O esquema fsico do banco de dados influenciado pelas fases por que passou a
construo do banco de dados. A fase de projeto conceitual tida como uma das mais
(seno a mais) delicadas em todo esse processo, pois depende muito da habilidade do
projetista do banco de dados e das qualidades do modelo de dados adotado para a
elaborao do esquema conceitual. A meta nessa fase obter um esquema conceitual do
banco de dados que seja to completo e expressivo quanto possvel. Esse esquema deve
procurar expressar o mximo da semntica envolvida na informao. Mecanismos de
representao de alto nvel so empregados, tais como representao de hierarquias de
subconjunto e de generalizao, representao de restries de cardinalidade e de
atributos compostos e multivalorados. Para a representao do esquema conceitual
geralmente utiliza-se uma extenso do modelo Entidade-Relacionamento.
O projeto conceitual de um banco de dados no pode ser totalmente auxiliado
por ferramentas automticas; cabe ao projetista entender e transformar os requisitos dos
usurios em esquemas conceituais. O projeto conceitual , assim, a fase mais crtica do
projeto do banco de dados. Ele no depende somente da habilidade e experincia do
projetista, mas tambm da cooperao dos usurios que so responsveis por descrever
suas necessidades e o significado dos dados.
O esquema conceitual deve fazer parte da documentao do processo de projeto,
sendo utilizado durante a operao e manuteno do banco de dados, pois facilita o
entendimento dos esquemas de dados e das aplicaes que os utilizam.
Para auxiliar o projetista a elaborar o projeto conceitual de um banco de dados
existem as abstraes de dados, que apresentam as vantagens:
ajudam o projetista a entender, classificar e modelar a realidade,
melhoram a eficincia de implementaes subsequentes,
permitem melhor representar a semntica das novas aplicaes de banco de dados,
provenientes de reas no tradicionais.

1.2. Modelos de Dados Semnticos

Modelos de dados so veculos para descrever a realidade. Um modelo de
dados uma coleo de conceitos que podem ser usados para descrever um conjunto de
dados e operaes para manipular os dados. Os modelos de dados servem de base para o
desenvolvimento de Sistemas de Gerenciamento de Banco de Dados (SGBDs).
Distingue-se dois tipos de modelos de dados:
Modelos conceituais, que so ferramentas para representar a realidade em alto nvel
de abstrao;
Modelos lgicos, que suportam descries de dados que podem ser processados por
um computador (ex: modelos relacional, hierrquico, em redes). Esses modelos so
facilmente mapeados para a estrutura fsica do banco de dados .

Modelos de dados semnticos so modelos de dados que procuram capturar
tanto quanto possvel, os relacionamentos semnticos existentes entre as entidades do
mundo real. So exemplos de modelos de dados semnticos o modelo Entidade-
Relacionamento e o modelo funcional DAPLEX.

1.2.1. Abstraes no Projeto Conceitual de Banco de Dados

Para auxiliar o projetista na tarefa de modelar os dados, existem os mecanismos
de abstrao de dados que permitem melhor representar a semntica da informao
envolvida na aplicao.
As abstraes comumente usadas no projeto conceitual so: classificao,
agregao e generalizao.

Abstrao de Classificao: usada para agrupar objetos similares, caracterizados
por propriedades comuns, em classes de objetos.
Ex: classe EMPREGADO - instancias : (Joo, Pedro, ..., Maria).
A classificao estabelece um relacionamento -INSTANCIA-DE entre cada elemento
da classe e a classe.

Abstrao de Agregao: um conceito de abstrao para construir objetos
compostos a partir de seus objetos componentes.
Ex:
- Uma entidade uma agregao de atributos: PESSOA, composta por Nome,
Sexo, Profisso;
- Um relacionamento uma agregao de entidades e atributos;
- Um atributo composto uma agregao de atributos;
- Pode-se agregar entidades relacionadas entre si, compondo uma entidade de nvel
mais alto.
Essa abstrao estabelece um relacionamento -PARTE-DE entre os componentes e
a classe.

Abstrao de Generalizao: define um relacionamento de subconjunto entre os
elementos de duas ou mais classes.
Ex: classes CARRO e BICICLETA so subconjuntos da classe VECULO.
Essa abstrao estabelece um relacionamento -UM entre a classe pai (chamada
superclasse) e cada classe filha (subclasse).
As subclasses so definidas com base em alguma caracterstica da superclasse. No
exemplo dado, essa caracterstica tipo de veculo (Carro, Bicicleta).

Propriedade Fundamental da Generalizao: Todas as abstraes definidas para a
classe genrica so herdadas por todas as classes que so subconjunto.

1.3. Modelo EER (Extended Entity-Relationship)
1.3.1. Modelo ER

Devido popularidade e ampla utilizao do modelo Entidade-Relacionamento (ER)
para o projeto conceitual de bancos de dados, vrias extenses desse modelo foram
propostas, visando sua utilizao para a modelagem de informaes mais complexas. O
modelo ER foi proposto por Peter Chen em 1976, sendo que originalmente o modelo
incluia somente os conceitos de entidade, relacionamento e atributos; posteriormente
outros conceitos foram introduzidos no modelo, tais como atributos compostos e
hierarquias de generalizao.
As entidades representam classes de objetos do mundo real. Na figura 1.2,
Aluno e Professor so exemplos de entidades. So representadas graficamente atravs
de um retngulo.
Relacionamentos representam associaes entre duas ou mais entidades. Na
figura 1.2, orienta representa um relacionamento binrio entre as entidades Professor e
Aluno, representando que um aluno tem 1 (um) professor como orientador e um
professor orienta n (vrios) alunos. Os relacionamentos so representados graficamente
atravs de losangos.
Os atributos representam propriedades das entidades ou dos relacionamentos.
Na figura 1.2 tem-se para a entidade Aluno os atributos nro_aluno e nome; Professor
possui os atributos nome e sexo.

nro_aluno n 1
nome orienta

Cardinalidade mnima e mxima de uma entidade em um relacionamento:
Para indicar, de forma mais precisa, a cardinalidade de um relacionamento, pode-se usar
uma notao que indique a ocorrncia mnima e mxima de cada entidade no
relacionamento. Por exemplo, a cardinalidade do relacionamento da figura 1.2 pode ser
representada como na figura 1.3, indicando que um aluno pode ou no ter um orientador
e pode ter no mximo 1 orientador; um professor orienta vrios alunos, podendo haver
professor que no orienta nenhum aluno.

nro_aluno (0,1) (0,n)
nome orienta

Figura 1.3 - Uso de cardinalidade mnima e mxima no relacionamento

Cardinalidade mnima e mxima de um atributo :
Os atributos tambm so caracterizados por cardinalidade mnima e mxima. Por
exemplo, na entidade Professor, da figura 1.4, o atributo ttulos possui cardinalidade
mnima 1 e mxima n, indicando que cada professor deve ter no mnimo um ttulo e
pode ter vrios. Quando no especificado no atributo, o valor da cardinalidade (1,1).

Fig. 1.4 - cardinalidade mnima e mxima de atributo

Professor
Aluno

Professor
nome
sexo

nome
sexo
ttulos (1,n)

Professor
Aluno
nome
sexo
Figura 1.2 - Diagrama Entidade-Relacionamento

Cardinalidade mnima de atributo igual a 0 (zero) indica atributo opcional;
cardinalidade mxima de atributo maior que 1 (um) indica que o atributo
multivalorado.

Atributos compostos:
Um atributo composto representa um grupo de atributos que possuem uma afinidade em
significado ou uso. Como exemplo, considere o atributo endereo na figura 1.5, que
composto por Rua, Cidade, Estado, Pas e CEP.

Fig. 1.5 - atributo composto

Um identificador interno um atributo ou grupo de atributos que determina uma
entidade. Ser adotada a representao da figura 1.6 para identificador interno.

identificador ident1
ident2
Fig. 1.6 - identificador interno

Quando uma entidade identificada atravs de outra entidade associada a ela, tem-
se um identificador externo, cuja representao pode ser a da figura 1.7(a) ou usando
a notao de entidade fraca (figura 1.7 (b)). Essa figura indica que o identificador de A
faz parte do identificador de B
1.3.2. Extenso do Modelo ER

Para permitir melhor expressar as informaes a serem modeladas, foram introduzidos
no modelo ER as hierarquias de generalizao e de subconjunto.

endereo

Professor

Rua
Cidade
Estado
Pas
CEP
A

B
Fig. 1.7 (b) - identificador externo
A

B
Fig. 1.7 (a) - identificador externo
Hierarquia de Generalizao: Uma classe E uma generalizao de um grupo de classes
E1, E2, ..., En se cada objeto das classes E1, E2, ..., En tambm um objeto da classe E.
Uma forma de representar uma hierarquia de generalizao dada na figura 1.8.

Propriedades de Cobertura da generalizao

Cobertura TOTAL ou PARCIAL:

A cobertura de uma generalizao total (t) se cada elemento da classe genrica
mapeada para pelo menos um elemento das classes especializadas.
Ex: A generalizao formada pela classe PESSOA e as subclasses HOMEM e
MULHER (figura 1.9) possui cobertura total.

A cobertura parcial (p) se existe algum elemento da classe genrica que no
mapeado para nenhum elemento das subclasses.
Exemplo: Suponha que VECULO uma classe que contm outros tipos de veculos
alm de carros e bicicletas. A generalizao da figura 1.10 parcial.

Fig.1.9 - cobertura total Fig.1.10 - cobertura parcial

parcial
total
Pessoa

Homem Mulher

Veculo
Carro Bicicleta
E
E1
E2
En
. . .
Fig. 1.8 - Hierarquia de generalizao
Cobertura EXCLUSIVA (DISJUNO) ou de SOBREPOSIO (OVERLAPPING):

A cobertura de uma generalizao exclusiva (e) se cada elemento da classe genrica
mapeado para no mximo um elemento das subclasses.
Ex: A figura 1.10 representa uma cobertura exclusiva.

A cobertura de sobreposio (s) se existe algum elemento da classe genrica que
mapeado para elementos de duas ou mais subclasses diferentes.
Ex: Na figura 1.11, supondo que pode existir aluno que cursa a graduao e a ps-
graduao ao mesmo tempo, tem-se uma cobertura de sobreposio.

Fig. 1.11 - cobertura de sobreposio

Notao: Para denotar o tipo de cobertura de uma hierarquia de generalizao ser
usada a seguinte notao: (t,e), (t,s), (p,e), (p,s) e ser indicado como na figura 1.12.
Quando numa generalizao a cobertura no est especificada, admite-se que (t,e).

(p,e)

Fig. 1.12 - cobertura parcial e exclusiva

Hierarquia de Subconjunto: uma entidade E1 um subconjunto de uma entidade E
se toda ocorrncia de E1 for tambm uma ocorrncia de E (figura 1.13). um caso
particular da hierarquia de generalizao.
Numa hierarquia de subconjunto o tipo de cobertura (p,e) sempre.

Veculo
Carro Bicicleta
sobreposio
Aluno

Aluno-
Graduaao
Aluno-Ps-
Graduao
A representao de hierarquia de subconjunto dada na figura 1.13.

Observaes:
1. O identificador da entidade genrica tambm um identificador para as entidades da
especializao.
2. Entidades da especializao podem ter outros identificadores, como mostrado na
figura 1.15.

nome
RG
ttulo

situao-
serv-mil

nome_ nro-emp nome_diviso categoria posio
solteira
Fig.1.15

1.4. Exerccios

1. Indique na figura 1.9 se a cobertura exclusiva ou sobreposio.

2. Indique na figura 1.11 se a cobertura total ou parcial.

3. Indique as propriedades de cobertura da generalizao na figura 1.16.
Suposies: - s existem jogadores de futebol e de tnis;
- pode ter jogadores que jogam os dois esportes.

Pessoa
Homem
Mulher
Empr Chefe Gerente Militar
diviso
ident-na-
diviso

Cliente
Cliente
Especial
nro-cli
nome-cli
endereo
vantagens
Fig.1.14 - Exemplo

E

E1
e1
e2
e3
e4
e5
Fig.1.13 - hierarquia de subconjunto

Fig.1.16

4. Verifique como as propriedades de cobertura se relacionam com as restries de
cardinalidade. (Sugesto: interprete hierarquias de generalizao como tipos especiais
de relacionamento entre classes).

5. Transforme as hierarquias do exerc.4 em relacionamentos entre a classe genrica e as
subclasses.

6. Considerando a propriedade fundamental de hierarquias de generalizao, simplifique
o esquema da figura 1.17.

mora
(1,n)
(1,n) nome
nasci-
da (1,1)

(1,n) (1,1)
reside
(0,n)
idade
tra-
balha
(0,1) idade

Fig.1.17

7. Considere o esquema da figura 1.17. Como voc pode mud-lo para representar no
esquema todos os empregados, homens e mulheres?

Masculino
Jogador

Futebol
Tnis
Pessoa

Feminino
Cidade
Soldado
Empregado
8. Faa o esquema conceitual do seguinte problema:
Uma companhia mantm informaes sobre todas as pessoas que, de
alguma forma, possuem com ela algum vnculo, dentre essas seus funcionrios. Os
seguintes requisitos foram levantados junto aos usurios:

a. De cada pessoa mantm-se um cdigo, o nome, endereo.

b. De cada funcionrio guarda-se tambm seu salrio e o departamento a que ele
pertence. Desses funcionrios, alguns so gerentes e para cada um destes guarda-se os
nomes dos projetos que eles gerenciam.

c. Dos demais funcionrios que so operrios, guarda-se suas habilidades (um operrio
pode ter vrias habilidades).

d. Mantm-se tambm os tipos de trabalho executados na Companhia (cdigo e
caracterstica) e os operrios que executaram cada trabalho, juntamente com o perodo
que isto se deu. Sabe-se tambm que pode haver operrios que no exercem nenhum
tipo de trabalho dentre os cadastrados.

e. Deve-se tambm manter os dependentes de cada funcionrio (nome, sexo e data de
nascimento).

2. Questes no Projeto Conceitual de um Banco de Dados
2.1.Introduo

A meta na fase de projeto conceitual obter um esquema conceitual do banco de dados
que seja to completo e expressivo quanto possvel. Esse esquema deve procurar
expressar o mximo da semntica envolvida na informao. Mecanismos de
representao de alto nvel so empregados, tais como representao de hierarquias de
subconjunto e de generalizao, representao de restries de cardinalidade e de
atributos compostos e multivalorados. Para a representao do esquema conceitual
geralmente utiliza-se uma extenso do modelo Entidade-Relacionamento.

Vises:
Quando as aplicaes so complexas e usualmente diferentes analistas esto envolvidos
no processo de projeto do banco de dados, a aplicao pode ser particionada em
atividades menores, representando vises de grupos de usurios.
Viso, na fase de projeto conceitual, a parte de um banco de dados ou dos requisitos
de dados de uma aplicao que vista por um usurio ou grupo de usurios.
2.2. Projeto de Viso
Refere-se modelagem da parte do banco de dados de interesse de um usurio ou grupo de
usurios, com base nos requisitos de dados, usando os conceitos de um modelo de dados.
Os requisitos podem estar expressos atravs de:

Descries em linguagem natural, atravs da qual os usurios expem suas
necessidades;
Formulrios impressos em papel, que so utilizados para coletar dados. Se j
houver um sistema preexistente, esses formulrios podem ser telas formatadas para
entrada de dados;
Declaraes de registros pertencentes a aplicaes preexistentes.

2.2.1. Projeto de Viso com base em Linguagem Natural

Considere a seguinte descrio de um sistema envolvendo dados de uma universidade:

1 [Em um bd de universidade representamos dados sobre
2 alunos e professores]. [ Para alunos,
3 representamos o ltimo nome, idade, sexo, cidade e estado de
4 origem, cidade e estado de residncia de suas
5 famlias, locais e estados onde viveram antes
6 (com o perodo em que viveram), disciplinas que
7 tenham cursado, com nome, cdigo, professor,
8 nota e data.] [Representamos tambm disciplinas que
9 esto freqentando presentemente e para cada dia, locais
10 e horrios que as aulas so oferecidas (cada disciplina
11 oferecida no mximo uma vez em um dia)].[ Para estudantes
12 graduados, representamos o nome do orientador
13 e o nmero total de crditos do ltimo ano.
14 Para alunos de doutorado, representamos o ttulo e rea de pesquisa
15 de suas teses].[ Para professores, representamos o ltimo
16 nome, idade, local e estado de origem, nome do
17 departamento a que pertencem, nmero do telefone,
18 ttulo, estado civil e tpicos de sua pesquisa.]
Requisitos do banco de dados da universidade.

Nessa descrio pode-se identificar algumas ambigidades, como mostrado abaixo.

LINHA TERMO NOVO TERMO RAZO PARA CORREO
5 locais Cidades Local uma palavra genrica
6 perodo nmero de anos Perodo uma palavra genrica
9 Presentemente no ano corrente Presentemente ambguo
9 dia dia da semana mais especfico
9 locais Salas Homnimo de locais na linha 5
10 aulas Disciplinas Sinnimo de disciplinas na linha 8
11 estudantes Alunos Sinnimo de alunos na linha 2
16 local Cidade igual linha 5
17 telefone telefone do
departamento
mais especfico
18 tpico rea de pesquisa linha 14
Termos ambguos nos requisitos, com possveis correes.

Descrio com os termos ambguos substitudos por novos termos:

[Em um bd de universidade representamos dados sobre alunos e professores]. [Para
alunos, representamos o ltimo nome, idade, sexo, cidade e estado de origem, cidade e
estado de residncia de suas famlias, cidades e estados onde viveram antes (com o
nmero de anos em que viveram), disciplinas que tenham cursado, com nome, cdigo,
professor, nota e data]. [Representamos tambm disciplinas que esto freqentando no
ano corrente e para cada dia da semana, salas e horrios que as disciplinas so
oferecidas (cada disciplina oferecida no mximo uma vez em um dia)]. [Para alunos
graduados, representamos o nome do orientador e o nmero total de crditos do ltimo
ano. Para alunos de doutorado, representamos o ttulo e rea de pesquisa de suas teses].
[Para professores, representamos o ltimo nome, idade, cidade e estado de origem,
nome do departamento a que pertencem, nmero do telefone do departamento, ttulo,
estado civil e reas de pesquisa] .
Requisitos aps a filtragem das ambigidades.

Exerccio: Faa o esquema conceitual desse banco de dados.
2.2.2. Projeto de Viso com base em Formulrios

Distinguem-se:

- Partes do formulrio que no apresentam informaes relevantes a serem
armazenadas (assinaturas, data de emisso, cabealho, etc.).

- Partes que so pr-impressas no formulrio e que referem-se a nomes de campos;

- Partes que devem ser preenchidas pelos usurios e que sero armazenadas no
sistema;

- Partes descritivas referentes s instrues que devem ser seguidas para preencher os
campos do formulrio.

A seguir so dados vrios exemplos de formulrios. Para cada caso, faa o esquema
conceitual correspondente.

a) Formulrio para registrar informaes de docentes que atuam em programa de ps-
graduao.

Formulrio 1

INFORMAO DE DOCENTE ATUANTE NA PS-GRADUAO

Nome do docente: __________________________________________
Departamento:_____________________________________________
Ms/Ano trmino doutorado:__________________________________
Instituio do doutorado: _____________________________________
reas de atuao (no mximo 4 reas): __________________________
__________________________________________________________
__________________________________________________________

Orientaes de Mestrado/Doutorado no programa:

Nome do aluno Data Data Categoria
incio trmino (mestr/dout)
. . .
b) Considere no formulrio 1 as seguintes alteraes:

b1) para informaes sobre alunos, adicionar colunas para indicar a situao do
aluno:

b2) Para docente incluir campos para assinalar opes, onde vrias opes podem
ser selecionadas para um mesmo docente:

Assinale:
Professor contratado
Ministra aula na graduao
Possui vnculo com outras Instituies. Se sim, indique os nomes das Instituies:
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________

c) Considere a tabela tridimensional que representa os gastos de vrias companhias
para um perodo de 3 anos. Sobre cada companhia deseja-se guardar esses
gastos,bem como o nome da companhia, CGC e endereo.

Gastos nos ltimos 3 anos
Ano Ms
1996 Jan Fev Mar Abr ... Dez
01-15
quinzena
16-31

01-15
quinzena
16-31

01-15
quinzena
16-31

Nome do aluno . . . Categoria Situao
(mestr/dout) cursando trancado Abandonou

2.2.3. Projeto de Viso com base em Declaraes de Registro

A seguir so tratados alguns aspectos relativos estrutura de declarao de arquivos
como guia para a modelagem de esquemas E-R (Entidade-Relacionamento). No sero
tratadas declaraes de registros de um SGBD (Oracle, Acess, Dbase, Paradox, etc...), e
sim, declaraes de registros de linguagens de mais baixo nvel (C, C++, Pascal, Cobol,
etc...).

As aplicaes comerciais geralmente utilizam arquivos compostos de registros que so
armazenados na memria secundria. Esses arquivos so acessados, consultados e/ou
alterados de acordo com as funes executadas pelo sistema.

Os registros so compostos de campos. Os campos por sua vez podem ser compostos de
sub-campos. Como conseqncia, geralmente tm uma estrutura hierrquica, e cada
campo se coloca numa posio desta hierarquia. Em C pode-se utilizar estruturas ou
classes definidas pelas clusulas struct/class, para armazenar informaes nos arquivos
segundo as estruturas declaradas. O mesmo se aplica aos tipos definidos em Pascal. Em
Cobol, a declarao do(s) arquivo(s) que ir(o) fazer parte do sistema realizada em
uma estrutura chamada DATA DIVISION.

Cobol formado por quatro partes principais ( as DIVISIONS). So elas:
IDENTIFICATION (Identificao do programa - nome, autor, data compilao...);
ENVIRONMENT (Informaes a respeito do ambiente fsico de compilao e de
execuo);
DATA (Descrio resumida de cada arquivo e a organizao dos registros no
arquivo);
PROCEDURE (Informaes a respeito do processamento em si).

A parte que nos interessar a DATA DIVISION, que subdividida da seguinte forma:

DATA DIVISION.

FILE SECTION.
[descrio do arquivo
descrio do registro]...

WORKING STORAGE SECTION
[descrio de item ou de registro]...

A seguir apresenta-se um exemplo de declarao de um arquivo e da estrutura dos
registros em Cobol, e as correspondentes declaraes de registros em C e em Pascal .

COBOL:

DATA DIVISION

FILE SECTION

FD ARQUIVO-EXEMPLO
BLOCK CONTAINS O RECORDS
RECORD CONTAINS 80 CHARACTERES

01 EXEMPLO
05 DADO-NUMERICO PIC 9(8).
05 LETRA PIC X(1).

C:

struct exemplo
{
int dado_numerico;
char letra;
};

Pascal:

Type

Exemplo = record
dado_numerico: integer;
letra: char;
end;

Na declarao de um registro podem estar expressos vrios tipos de campos, como por
exemplo, campos simples, campos multivalorados (em COBOL os campos
multivalorados so definidos na clusula OCCURS), redefinio de campos (atravs da
clusula REDEFINES), etc. Esses campos devem ser mapeados para uma modelagem
adequada no esquema, que expresse toda a semntica da informao envolvida.

A seguir so dados vrios exemplos de declaraes de registros em COBOL. Para cada
caso, faa o esquema conceitual correspondente.

a) Considere a declarao em COBOL dos registros para um arquivo de pedidos:

01 PEDIDO.

02 NRO-PEDIDO PIC X(10).

02 DATA-DE-EMISSO.
03 DIA PIC 9(2).
03 MS PIC 9(2).
03 ANO PIC 9(2).

02 DATA-ENTREGA.
03 DIA PIC 9(2).
03 MS PIC 9(2).
03 ANO PIC 9(2).

02 VALOR.
03 PREO PIC 9(6)V99.
03 TAXA-MUDANA PIC 9(6)V99.

02 PEAS-PEDIDO OCCURS 10 TIMES.
03 CODIGO-PEA PIC 9(6).
03 QTIDADE PIC 9(4).

b) Uso de clusulas OCCURS subordinadas:

01 PRODUTO.
02 NOME PIC X(20).
02 CDIGO PIC X(4).
02 PREO PIC 9(5).

02 QTDE-EM-ESTOQUE.
03 QTDE-EM-ESTOQUE-POR-ANO OCCURS 4 TIMES.
04 QTDE-EM-ESTOQUE-POR-MS PIC 99 OCCURS 12 TIMES.

c) Redefinio de campo

Permite ao programador definir a mesma parte de um registro usando declaraes de
campos diferentes. Com isso, otimiza o espao de armazenamento fsico.

01 PESQUISADOR.
02 NOME-PESQUISADOR PIC X(30).
02 ENDEREO PIC X(25).
02 DOCENTE-INTERNO.
03 NOME-PROGRAMA-POS-GRAD PIC X(27).
03 PROJETOS-PESQUISA-DO-DOCENTE PIC X(15) OCCURS 5 TIMES.

02 PESQUISADOR-VISITANTE REDEFINES DOCENTE-INTERNO.
03 INSTITUIO-ORIGEM PIC X(50).
03 DATA-INCIO.
04 DIA PIC 9(2).
04 MS PIC 9(2).
04 ANO PIC 9(2).
03 DATA-TRMINO.
04 DIA PIC 9(2).
04 MS PIC 9(2).
04 ANO PIC 9(2).
03 AREA-ATUAO PIC X(10) OCCURS 4 TIMES.

d) Ponteiros Simblicos

02 EMPREGADO.
03 CDIGO PIC X(10).
03 COD-DEPTO PIC X(5).
03 COD-PROJETO PIC X(7) OCCURS 10 TIMES.

02 DEPTO.
03 CDIGO PIC X(5).
03 NOME PIC X(20).

02 PROJETO.
03 CDIGO PIC X(7).
03 DESCRIO PIC X(30).
03 EMPREGADO-RESPONSVEL PIC X(10).

e) Ponteiro que se refere ao campo identificador do registro em que ele definido.

01 PROJETO.
02 CDIGO PIC X(7).
02 DESCRIO PIC X(30).
02 CDIGO-SUPERPROJETO PIC X(7).
02 ORAMENTO PIC 9(6)V99.
2.2.4. Exerccios - Projeto de Viso

1. Construa um esquema conceitual para a seguinte descrio em linguagem natural:
Projete o banco de dados para um ambiente de suporte de programao. Nesse ambiente
os programadores produzem programas, que so escritos em determinadas linguagens
de programao. Cada programa escrito por um certo programador, pode chamar
outros programas e pode ser usado por determinados usurios. Os usurios so
reconhecidos por seu nome de log-in e por seu cdigo; os programas tm nomes
compostos que incluem o nome do programa, a extenso e o cdigo do programador. Os
programas tm um nmero de verso, uma data e uma breve descrio; alguns
programas interagem com SGBDs. Cada SGBD mantm dados armazenados na forma
de relaes, com vrios atributos e uma chave primria. Cada banco de dados definido
por um administrador de banco de dados, que um programador especializado em
gerenciamento de dados.

2. Transcreva as definies de arquivo em COBOL a seguir para um esquema ER. A
aplicao lida com o controle distribudo de um processo industrial. O arquivo DADOS-
EMPREGADO indica que cada empregado pode controlar comandos e alarmes. O
arquivo SISTEMA-COMANDOS lida com comandos disponveis para controle de
processos e os locais onde cada comando pode ser executado. O arquivo SISTEMA-
ALARMES lida com os mesmos dados para alarmes. Finalmente, o arquivo
COMUNICAES descreve dados sobre subsistemas de comunicao, sua tecnologia,
os dispositivos conectados, locais dos dispositivos, etc. A transmisso de dados pode ser
atravs de microondas ou cabos.

01 DADOS-EMPREGADO.
02 NRO-ID PIC 9(6).
02 NOME PIC X(20).
02 SUPERVISOR-EMPREGADO PIC 9(6).
02 SISTEMA-COMANDO-CONTROLADO PIC X(5) OCCURS 10 TIMES.
02 SISTEMA-ALARME-CONTROLADO PIC X(5) OCCURS 10 TIMES.

01 SISTEMA-COMANDOS.
02 TIPO PIC X(5).
02 DATA PIC 9(6).
02 HORARIO.
03 HORA PIC 99.
03 MINUTO PIC 99.
03 SEGUNDO PIC 99.
02 POSIO.
03 NOME PIC X(20).
03 LOCAL PIC X(20).
03 TIPO PIC X(5).

01 SISTEMA.ALARMES.
02 TIPO PIC X(5)
02 DATA PIC 9(6).
02 VALOR PIC 9(8).
02 HORARIO.
03 HORA PIC 99.
03 MINUTO PIC 99.
03 SEGUNDO PIC 99.
02 POSIO.
03 NOME PIC X(20).
03 LOCAL PIC X(20).
03 TIPO PIC X(5).

01 COMUNICAES.
02 TECNOLOGIA PIC X(8).
02 VELOCIDADE PIC 9(6).

02 DISPOSITIVO-REMOTO OCCURS 10 TIMES.
03 NOME PIC X(10).
03 TIPO PIC X(5).
03 LOCAL PIC X(20).

02 DADOS-CABO.
O3 MODEM.
04 TIPO PIC X(10).
04 TAXA-TRANSMISSO PIC 9(6).

02 DADOS-MICROONDAS REDEFINES DADOS-CABO.
03 RADIO.
04 RADIO PIC X(5).
04 MODO-TRANSMISSO PIC X(5).
04 FREQUENCIA PIC X(10).
04 ANTENA PIC X(5).
2.3. Integrao de Vises

Integrao de vises: Processo de fuso de vrios esquemas conceituais em um
esquema conceitual global que representa todos os requisitos da aplicao.
Aconselha-se o uso do processo de integrao principalmente para aplicaes
complexas, aonde o volume de informao grande, podendo haver vrios analistas
envolvidos no processo de projeto. O projetista estabelece uma prioridade entre os
esquemas com base em sua importncia, confiabilidade e completitude.

A integrao dos esquemas pode ser realizada por etapas conforme ilustrado abaixo:

Anlise de Conflito: realiza-se uma anlise nos esquemas a serem integrados para
verificar se h algum conflito entre informaes de diferentes esquemas. Os tipos de
conflitos que podem ocorrer so:

a. Conflito de nome:

Sinnimos : quando h nomes diferentes para uma mesma informao em diferentes
esquemas. Nesse caso deve-se escolher um dos nomes e renomear os demais com esse
nome.

Homnimos: quando h informaes diferentes com o mesmo nome. Nesse caso deve-
se renomea-las para diferenciar.

b. Conflito estrutural:

Aps realizada a eliminao dos conflitos de nomes, tem-se que dois conceitos de
diferentes esquemas com mesmo nome representam o mesmo conceito. Esses conceitos
com mesmo nome so agora comparados para verificar se podem ser fundidos num
nico. Usa-se o seguinte procedimento:
Esquema 1 Esquema 2
Esquema parcial
integrado
Esquema 3
Esquema n
Esquema global
correo dos
conflitos
. . .
b1. Conceitos idnticos
Se os conceitos so idnticos (mesma representao e mesmos relacionamentos com
outras entidades), eles se resumem num nico.

b2. Representaes diferentes da mesma realidade:
Se os conceitos so compatveis, isto , possuem diferentes representaes no
contraditrias, muda-se uma das representaes.A seguir tem-se exemplos de
esquemas nessa situao.

b3. Especificaes de projeto incompatveis:

Se os conceitos forem incompatveis, como por exemplo, diferentes cardinalidades para
o mesmo atributo ou relacionamento, diferentes identificadores, etc., as possveis
solues so: selecionar uma das representaes ou construir uma representao comum
satisfazendo todas as restries dos dois esquemas.
Exemplo:
esquema 1 esquema 2
Livro
ttulo
nome_editora
Livro
Editora
ttulo
nome
esquema 1 esquema 2
Pessoa
nome
sexo
Pessoa
nome

Homem Mulher
esquema 1
esquema 2
Empregado
Projeto
(1,n)
(1,n)
Empregado
Projeto
(1,1)
(1,n)
2.4. Estudo de Caso: Gerenciamento de uma Biblioteca

Projeto de Vises Biblioteca particular de pesquisadores

Considere os esquemas conceituais a seguir que tm por finalidade armazenar
informaes sobre publicaes (livros, revistas, etc) de uma biblioteca.

O esquema 1 representa informaes de interesse de pesquisadores em suas bibliotecas
particulares. Nesse esquema tem-se:

Publicao: publicaes (artigos) mantidas pelos pesquisadores em seus gabinetes
particulares. Elas so geralmente obtidas pelos pesquisadores atravs de contatos com
os autores.

Tpico: refere-se s reas de pesquisa de interesse dos autores.

Solicitado-por: relaciona artigos que foram enviados por autores, aos pesquisadores
que os solicitaram.

O esquema 2 representa as informaes a serem mantidas na biblioteca do
Departamento desses pesquisadores:

Publicao: publicaes presentemente mantidas na biblioteca.

Artigo: artigos publicados em revistas ou anais mantidos na biblioteca.

Comprado-pelo: indica que o pesquisador responsvel pelo recurso usado para
comprar a publicao.

Etapa1: Analisar os esquemas da Fig. 2.1 a e b, quanto a :
a) conflito de nomes
b) conflitos estruturais
Tpico
Publicao
Anais
Referente-a

Pesquisador
Editora
Publicado
-por
Comprada-pelo
cd-tpico
nome
(1,n)
(1,n)
(0,n)
(0,n)
ltimo-nome
posio
grau
cidade-nasceu

nome
endereo

trata
(1,n)
Ttulo
estante
Empresta
dia-emprestimo
Revista Livro
(1,1)
Autor (1,n)
Artigo
pertence
-rev
pertence
-anais
Ttulo
autor (1,n)
(1,n)
(0,1)
(0,1)
(0,n)
(0,n)
(0,1)
(0,n)
(1,1)
Fig. 2.1 - (b) Esquema :Biblioteca do Depto (esquema 2)
Tpico
Autor
Pertence
Grupo_
Pesquisa
de_interesse
Publicao
Publ-de-
interesse
Pesquisador
Escrito_por

(0,n)
nome
(1,n)
(1,n)
(1,n)
nome
endereo

Sries
Livro de-interesse
Pertence_a
ultimo-nome
idade
estado-nasceu
Editora
tem
Nome
endereo
ltimo-nome
endereo
(1,n)
(1,n)
(1,n)
(1,n)
(1,n)
(1,n)
(1,1)
(1,1)
(1,n)
(1,n)
nome
editor

nmero
ttulo
ano

Solicitado
-por
Enviado-
por
(0,n)
(0,n)
(0,n)
(0,n)
(0,n)
(0,n)
ttulo
palavra-chave (1,n)
ano
Fig. 2.1 - (a) Esquema : Biblioteca Particular (esquema 1)
Exemplo: Gerenciamento de uma Biblioteca - Esquemas modificados

rea_
pesquisa
Autor
Pertence
Grupo_
Pesquisa
de_interesse
Artigo
Artigo-de-
interesse
Pesquisador
Escrito_por

(0,n)
nome
(1,n)
(1,n)
(1,n)
nome
endereo

Sries
Livro de-interesse
Pertence_a
ultimo-nome
idade
estado-nasceu
Editora
tem
Nome
endereo
ltimo-nome
endereo
(1,n)
(1,n)
(1,n)
(1,n)
(1,n)
(1,n)
(1,1)
(1,1)
(1,n)
(1,n)
nome
editor

nmero
ttulo
ano

Solicitado
-por
Enviado-
por
(0,n)
(0,n)
(0,n)
(0,n)
(0,n)
(0,n)
ttulo

ano
Tpico
Publicao
Anais
Referente-a

Pesquisador
Editora
Publicado
-por
Comprada-pelo
cd-tpico
nome
(1,n)
(1,n)
(0,n)
(0,n)
ltimo-nome
posio
grau
cidade-nasceu

nome
endereo

trata
(1,n)
Ttulo
estante
Empresta
dia-emprestimo
Revista Livro
(1,1)
Artigo
pertence
-rev
pertence
-anais
Ttulo

(1,n)
(0,1)
(0,1)
(0,n)
(0,n)
(0,1)
(0,n)
(1,1)
Tpico
nome
A-T
(1,n)
(1,n)
(1,n)
Autor
escreve-
livro
escrito_
por

(0,n) (0,n)
(1,n)
(1,n)
nome
Fig. 2.2 - (a) Esquema : Biblioteca Particular (esquema 1)
Fig. 2.2 - (b) Esquema :Biblioteca do Depto (esquema 2)
Etapa 2: Fazer a integrao dos esquemas.

Esquema global aps fuso dos esquemas: Biblioteca Particular e
Biblioteca do Depto

Publicao
(1,n)
ttulo estante
Tpico
Referente-a
cd-tpico
nome
(1,n)
(1,n)
(1,1)
Pesquisador
Comprada-pelo
(0,n)
ltimo-nome
posio
grau
cidade-nasceu
estado-nasceu
idade

Empresta
dia-emprestimo
(0,n)
(0,1)
Anais Livro Revista
trata
Artigo
ttulo
ano

(1,n)
(0,1)
pertence
-rev
pertence
-anais
(0,1)
(0,n) (0,n)
Editora
Publicado
-por
(0,n)
nome endereo

(1,1)
Srie
Pertence_a
de
(1,n)
(0,n)
(1,1)
(1,1)
(1,n)
nmero
ano

nome editor
de-
interesse
Autor
Escrito_por
Escreve
-livro
(0,n)
rea-
Pesquisa

de_interesse
(1,n)
(1,n)
nome-area
ltimo-nome
endereo
(1,n)
(1,n)
(0,n)
(1,n)
artigo-de-
interesse
(1,n)
(1,n)
Solicitad
o-por
(0,n)
(0,n)
(0,n)
Enviado-
por
(0,n)
(0,n)
(0,n)
Pertence
Grupo_
Pesquisa
(0,n)
(1,n)
nome
endereo

Fig. 2.3 Esquema global (fuso de Biblioteca Particular e Biblioteca do Depto
Projeto de Banco de Dado Profa. Marina Teresa Pires Vieira

2.5. Melhorando a Qualidade de um Esquema de Banco de Dados

Meta: Aplicar transformaes para reestruturar o esquema para produzir uma verso
melhor em termos das seguintes qualidades:

a. Ser completo
b. Ser correto
c. Ser mnimo
d. Ser expressivo e auto explicativo
e. Ser Legvel
f. Estar normalizado

2.5.1. Qualidades de um esquema de BD

a. Ser completo
esquema completo com relao aos requisitos: se todos os requisitos do domnio da
aplicao estiverem representados no esquema.

requisitos completos com relao ao esquema: se cada conceito no esquema
mencionado nos requisitos.

b. Ser correto
Um esquema correto quando usa adequadamente os conceitos do modelo ER.

Erros semnticos mais freqentes:

a. Usar um atributo no lugar de uma entidade.

b. Esquecer de representar uma generalizao.

c. Esquecer a propriedade de herana das generalizaes.

d. Usar um relacionamento com um nmero errado de entidades (por ex: usar
um relacionamento binrio no lugar de um relacionamento ternrio).

e. Usar uma entidade ao invs de um relacionamento.

f. Esquecer algum identificador de entidade, especialmente identificadores
compostos externos.

g. Omitir alguma especificao de cardinalidade mnima ou mxima.

c. Ser mnimo

Um esquema mnimo se no for possvel eliminar qualquer conceito do esquema sem
perder informao.
Exemplo:

nro_empregados pode ser eliminado sem afetar o contedo de informao do
esquema, pois pode ser derivado a partir do esquema, logo o esquema no mnimo.

Pode-se permitir alguma redundncia no esquema, que deve ser documentada.

d. Ser expressivo e auto-explicativo

Um esquema expressivo quando pode ser entendido atravs dos construtores do
esquema E-R, sem a necessidade de explicao adicional.

Exemplo: Considere o esquema:

Suponha que cada aluno tem, no mximo, um orientador
de mestrado e um orientador de doutorado e um mesmo
aluno pode ser um aluno de mestrado e de doutorado(em
momentos diferentes).

A informao acima est totalmente representada no
esquema?

(1,n)
Empregado
nome
data-nasc
trabalha
Projeto
cdigo
gerente
nro_empregados
(1,n)
Aluno
tem
orientador
Professor
(0,2)
(0,n)
tipo

e. Ser legvel

Respeitar critrios de esttica que tornam o diagrama agradvel.

- evitar cruzamento de ligaes dos relacionamentos;
- evitar curvas
- hierarquias: pai deve ser colocado acima dos filhos.

Soluo:
A
D

C
B

C A D
B

mudar para
2.5.2. Transformaes de Esquema

Esquema E1
transformaes
Esquema E2

2.5.2.1. Transformaes para conseguir minimalidade

Situaes que apresentam redundncia na modelagem:

a) Ciclos de Relacionamentos

Exemplo:

- Trab-no redundante?

- Trab-com redundante?

- Dirige redundante?

b) Atributos Derivados

Atributos derivados podem ser omitidos de um esquema ER, porm podem ser
teis para melhorar a eficincia do banco de dados.

(1,1)
Empregado
trab-com
Diretor
Dirige
Departamento
Trab-no
(1,1)
(1,1)
(1,n)
(1,n)
(1,n)
c) Subconjuntos Implcitos

2.5.2.2. Transformaes para conseguir Expressividade

Expressividade: melhorada quando se simplifica o esquema.

Transformaes tpicas para melhorar a expressividade:

a) Eliminar Subentidades "Inexpressivas" em Hierarquias de Generalizao:

Inexpressivas: sem atributos ou com poucos

b) Eliminar Entidades "Inexpressivas"

Membro
Ensino
Professor Instrutor Estudante
Graduado
Membro
Ensino
categoria
nome RG idade cidade_nasc

Pessoa
transformar
para:
(1,n)
Pessoa
nome RG idade
nascida Cidade
nome
(1,1)
Empregado
Especialista
em Computao
Analista
Empregado
Analista
integrao?
Soluo:
c) Criar uma Generalizao

Quando se tem entidades com propriedades semelhantes. No exemplo a seguir,
Professor e Instrutor tm propriedades semelhantes.

Melhorando a expressividade:

d) Criar um Subconjunto

Professor
d Seminrio
Instrutor
ensina Curso
ensina
d
auxilia
Assistente
Ensino
Membro
Docente
ensina
Atividade
Seminrio Curso
Instrutor
Professor
auxilia
Assistente
Ensino
nome nro
Empregado dirige
Carro_da_
Compainha
tipo
nro_licena
ano

(0,1) (1,1)
Motorista dirige
Carro_da_
Compainha
tipo
nro_licena
ano

(1,1) (1,1)
nome nro
Empregado
Transformar para:
Obs: Quando for significativo para o projeto, pode-se usar a criao de um novo
subconjunto quando a entidade possui cardinalidade mnima = 0 em um relacionamento.
Isso enfatiza o papel da entidade.

2.5.2.3. Transformaes para obter Normalizao

2FN:

Exemplo da 2FN para relacionamento:

dependncias funcionais:

nro-al, cod-disc prof, mdia
cod-disc prof

Pedido
nro-ped
nro-pea
custo
qtde
data

Pedido
nro-ped
data

P-P
(1,n)

Pea
nro-pea
custo

qtde
(1,n)

nro-ped, nro-pea qtde
nro-pea custo
nro-ped data

Aluno
nro-aluno

cursou

Discip
cod-disc

prof

mdia

Aluno
nro-aluno

cursou

Discip
cod-disc
prof

mdia

3FN:


nro-e nome, nro-depto, nome-depto, nro-diviso, gerente
nro-depto nome-depto, nro-diviso
nro-diviso gerente

Empregado
nro-e
nome
nro-depto
nome-depto
nro-diviso
gerente

Suposio:

Cada departamento pertence a uma
s diviso e cada diviso tem um
gerente.

Empregado
nro-e
nome
Pertence

Departamento
nro-depto
nome-depto

Da

Diviso
nro-diviso
gerente

Obs: 2 transitividades:

nro-e nro-depto nro-diviso

nro-depto nro-diviso gerente
Exemplo de relacionamento que viola a 3FN:

nro-e, nro-depto : identificador de trabalha

Para os atributos do relacionamento tem-se:

nro-e, nro-depto nro-proj, verba, horas-trab

nro-proj verba => no est na 3FN

Passando para a 3FN:

(1,n) (1,n)
nome nro-e
Empregado Trabalha

Depto

nro-depto
nome

verba
nro-proj horas-trab
(1,n) (1,n)
nome nro-e
Empregado Trabalha

Depto

nro_depto
nome

horas-trab

Projeto

nro_proj
verba

(1,n)
2.5.3. Reestruturao do esquema de Gerenciamento de uma Biblioteca
Reestruturao do esquema da Fig. 2.3 (Etapa 3).

cdigo
ano
ltimo-nome
posio
grau
idade

Endereo
ltimo_nome

Publicao
ttulo estante
(1,1)
Pesquisador
Comprada-pelo
(0,n)
Empresta
dia-emprestimo
(0,n)
(0,1)
(0,n)
nasceu-
em
Cidade-nasc
cdigo nome estado

(1,1)
(1,n)
(1,n)
Tpico
Referente-a
cd-tpico
nome
(1,n)
Trabalho_de_autoria
Publicao-
coletiva
de-interesse
Artigo
ttulo
ano

Livro
nmero
ano

Tipo-publ

Solicitado
-por
Enviado-
por
Autor
(1,n)
(0,n)
(1,n)
Editora
Publicado
-por
(0,n)
(1,1)
Srie
Pertence_a
de
(1,n)
(1,n)
(1,1)
(1,1) nome editor
nome endereo

Escrito_por
rea-
Pesquisa

de_interesse
(1,n)
(1,n)
nome-area
Pertence Grupo_
Pesquisa
(1,n)
nome
endereo

(0,n)
(0,n)
(0,n)
(0,n)
(0,n)
(1,n) (1,n)
trata
(1,n)
(0,n)
contm
(1,n)
(1,1)
Fig. 2.4 - Esquema global aps reestruturao
2.6. Exerccio

Deseja-se desenvolver o esquema conceitual do banco de dados de informaes sobre os
empregados de uma empresa. As informaes sobre o sistema est organizado em 4
vises, conforme mostrado a seguir.
a) Faa o esquema conceitual de cada uma dessas vises. Faa a integrao das vises
por etapas, conforme dado em aula. Para os esquemas intermedirios, caso queira,
indique somente as partes que mudam na nova etapa de integrao, porm o esquema
final deve ser completo.
Siga as seguintes diretrizes:
1. Os esquemas devem satisfazer aos critrios de qualidade dados em aula.
2. FAA AS SUPOSIES QUE ACHAR NECESSRIAS E INDIQUE-AS (faa
isso, por exemplo, para as cardinalidades de relacionamentos no definidas nas vises).
3. Use a notao dada em aula para desenhar os esquemas.

Viso 1 - Formulrio para cadastramento de empregado.

Nome do empregado:____________________________________ Nro empr:________
Endereo:______________________________________________________________
RG:_________________________________ CIC: _____________________________
Data nascimento:_________________ nro carteira reservista: _____________________
Sigla Depto: ______ Nome Depto:___________________Data admisso:___________

Dependentes (no mximo 10):

Nome dependente Data nascimento
________________________________________________
________________________________________________
________________________________________________
. . .

Se vendedor, indicar:
regio em que atua: ___________________
Porcentagem comisso:__________

Viajante regional Viajante nacional No viajante

Viso 2 - Formulrio para clculo de salrio. Um empregado horista ou mensalista. As
informaes de cada ms, constantes do formulrio, devem ser mantidas no bd.

Nome do empregado:________________________________ Sigla Depto:__________
Ms/Ano: ________________

Horista. Tipo Contrato:______ Horas Trabalhadas no ms:_____
Horas extras no ms:__________

Mensalista. Regime de Trabalho:________________ Total faltas no ms:______

Viso 3 - Informaes sobre empregados e departamentos. Declarao dos registros
em COBOL.

01 EMPREGADO.
02 NRO-EMP PIC X(5).
02 SALRIO PIC 9(4).
02 ENDEREO PIC X(30).

02 SECRETRIA.
03 FORMAO PIC X(10).

02 OPERADOR REDEFINES SECRETRIA.
03 TURNO PIC X(7).

02 ENGENHEIRO REDEFINES OPERADOR.
03 ESPECIALIDADE PIC X(10) OCCURS 3 TIMES.

01 DEPTO.
02 NOME-DEPTO PIC X(15).
02 LOCAL PIC X(10).


Viso 4 - Histrico de vendas no atacado e varejo, de cada vendedor, nos ltimos 5
anos.
Nesse formulrio so colocados os valores totais de venda em cada ms, no atacado e
varejo.

Nome do Vendedor : ________________________________________ Sigla Depto: __________

Ano Tipo Jan Fev Mar Abr Mai Jun Jul Ago Set Out Nov Dez
1993

Atacado

Varejo

1998 Atacado

Varejo

1999 Atacado

Varejo

2000 Atacado

Varejo

2001 Atacado

Varejo


3. Projeto Lgico de Banco de Dados

Projeto lgico de banco de dados a fase do projeto de um banco de dados que visa
desenvolver o esquema lgico do banco de dados, voltado para o modelo de dados a ser
adotado para sua implementao. Se for adotado o Modelo Relacional (como o caso aqui
abordado), esta etapa ir gerar como resultado um esquema de banco de dados relacional,
que contemple, da melhor forma possvel, as necessidades dos usurios. Esse esquema
lgico gerado com base no esquema conceitual do banco de dados, que, por sua vez, foi
gerado durante a etapa de projeto conceitual. Cabe a esta etapa de projeto lgico realizar
transformaes no esquema conceitual, visando torn-lo eficiente no atendimento s
consultas mais freqentes e/ou mais crticas que sero realizadas sobre o banco de dados.
Assim, esta etapa est preocupada com o desempenho das operaes a serem executadas no
banco de dados. Pode-se destacar duas tarefas a serem realizadas nesta etapa: Refinamento
do Esquema Conceitual e Mapeamento para o modelo de dados adotado.
A seguir so apresentadas essas tarefas, aonde o termo entidade utilizado no lugar
de tipo de entidade, por questes de simplicidade de expresso. Pelo mesmo motivo
utiliza-se relao no lugar de esquema de relao.
3.1. Refinamento do Esquema Conceitual

O objetivo desta tarefa reestruturar o esquema conceitual para obter um novo
esquema no qual as operaes mais importantes possam ser executadas mais
eficientemente.
Realiza-se um refinamento nas entidades do esquema, de modo a reduzir o nmero
de acessos lgicos das operaes s entidades e a quantidade de dados transferidos em
operaes de entrada e sada entre o meio de armazenamento e a memria.
Para auxiliar a anlise das operaesa realizadas sobre o banco de dados pode-se
utilizar um esquema de navegao, conforme descrito na seo 3.4. neceessrio
realizar uma estimativa do volume de acessos das operaes para apoiar a deciso
quanto a modificaes no esquema do banco de dados, visando obter melhor
desempenho. A seo 3 discute uma forma de realizar essa estimativa do volume de
acessos.
Deve-se observar, no entanto, que esse nmero de acessos lgicos e a quantidade de
dados transferidos no so estimados precisamente neste ponto, pois dependem da
descrio das estruturas fsicas que sero projetadas numa fase posterior.
Pode-se aplicar as seguintes transformaes no esquema, visando otimizar a
execuo das operaes:
particionamento de entidades,
fuso de entidades
reproduo de atributos
3.1.1. Particionamento de Entidades
Subdivide-se em grupos os atributos que no fazem parte do identificador da
entidade. Os atributos que iro compor cada grupo so escolhidos de acordo com as
operaes que usam o grupo de atributos. Para o particionamento de uma entidade,
segue-se os passos:

Escolhe-se os atributos que so mais usados pelas operaes que acessam a entidade
atravs do seu identificador, formando um grupo com esses atributos, juntamente
com o identificador. Esse grupo forma a sub-entidade principal.

Para cada grupo restante constri-se uma sub-entidade, que conectada sub-entidade
principal atravs de um relacionamento 1:1. A sub-entidade principal identifica as
outras sub-entidades.

Cada relacionamento, do qual a entidade original participa, transferido para a sub-
entidade que usa o relacionamento mais freqentemente.

Exemplo: Considere a entidade Vendedor, da figura 3.1 abaixo e suponha que as
operaes sobre essa entidade, na maioria, usam somente os atributos nome e endereo
do vendedor e que apenas as operaes que calculam a comisso dos vendedores e o
relatrio mensal de comisso de vendedor utilizamos outros atributos. Nessas
condies, a entidade Vendedor uma candidata ao particionamento, resultando nas
entidades Dados-Comisso-Vendedor e Vendedor, mostradas na figura 3.2.


(1,1)
(1,1) (o,n)

Vendedor
nro-vendedor
nome_vendedor
endereo

atende

Cliente
nro-cli
nome_cli
ender_cli
saldo
lim_cred
(1,1)
(o,n)

Pedido
nro-ped data
faz
Dados_comisso_
Vendedor

comisso_total
taxa_comisso
_do
(1,1)
Fig. 3.2
(1,1)
(o,n)

Vendedor
nro-vendedor
nome_vendedor
endereo
comisso_total
taxa_comisso
atende

Cliente
nro-cli
nome_cli
ender_cli
saldo
lim_cred
(1,1)
(o,n)

Pedido
nro-ped data
faz
Fig. 3.1

3.1.2. Fuso de entidades

Para reduzir o nmero de acessos lgicos, pares de entidades conectadas por um
nico relacionamento 1:1 so examinados para decidir de devem ser fundidos.

As operaes que utilizam as entidades so divididas em duas classes:
- operaes que usam o relacionamento e ambas as entidades,
- operaes que usam somente uma das entidades.

Se o nmero de acessos lgicos na primeira classe for maior que na segunda classe,
as entidades so fundidas em uma nova entidade que herda todos os atributos das
originais.
3.1.3. Reproduo de atributos
Os atributos a
1
, a
2
, ..., a
n
de uma entidade x so candidatos a uma reproduo em
uma entidade y conectada a x, se a presena de a
1
, a
2
, ..., a
n
em y elimina a necessidade
de travessia de x para y em algumas operaes.
A reproduo de atributos fora a introduo de operaes adicionais para manter a
consistncia mtua dos dados. Deve-se, portanto, pesar as vantagens e desvantagens da
sua utilizao.
Alm das transformaes discutidas acima pode-se tambm usar atributos derivados
para otimizar a execuo de operaes.
3.2. Mapeamento para o Modelo Relacional
O objetivo dessa tarefa gerar o esquema relacional com base no esquema refinado
(resultado da aplicao das transformaes discutidas no item anterior). A atividade
bsica realizada aqui refere-se traduo das entidades e dos relacionamentos do
esquema refinado, para o esquema relacional. Para tanto, seguem-se as regras:

a. Entidades com identificao externa
Para todos os pares de entidades x e y do esquema refinado, tal que x identifica
externamente y, constri-se:

- uma relao correspondente entidade x,
- uma relao correspondente a y, contendo o identificador da entidade x.
Os identificadores principais das entidades tornam-se as chaves primrias das
relaes correspondentes e so sublinhados no esquema relacional. O identificador
de y ser o conjunto de atributos formado pelo identificador de x com o
identificador de y.

b. Demais entidades
As outras entidades restantes do esquema, aps realizado o passo a anterior, so
mapeadas para relaes correspondentes.

Nos passos a e b, os atributos compostos e os multivalorados so tratados da
seguinte forma:
- atributos compostos: incluir na entidade somente seus atributos simples
- atributos multivalorados: para cada atributo multivalorado m criar uma relao
contendo esse atributo e a chave primria ch da relao original. Se o atributo
multivalorado m no for composto (atributo a3 do esquema do exemplo a
seguir), a chave primria da nova relao ser composta pela chave primria ch
e o atributo m. Se o atributo multivalorado m for composto (atributo a4 do
exemplo), a chave primria ser composta pela chave primria ch juntamente
com um subconjunto do conjunto de atributos que compem m.
Exemplo:

Mapeamento da entidade A:

A(a1, a21, a22)
A1(a1, a3)

A
a1

a2

a3 (1,n)

a4(1,n)
a41
a42
a43

a21
a22
A2(a1, a41, a42, a43) supondo que so necessrios os 3 atributos (a1, a41 e
a42) para identificar, de forma nica, a entidade A2.

c. Relacionamentos
1:1
Escolher uma das entidades (por ex. E1) que participam do relacionamento para
conter como chave estrangeira a chave primria da outra entidade (por ex.E2).
Aconselha-se escolher uma entidade com participao total no relacionamento para
fazer o papel de E1. Se houver atributos no relacionamento, inclui-los em E1.

1:N (no fraco)
Incluir na relao do lado N a chave primria do lado 1, tornando-se esta uma chave
estrangeira da relao. Incluir os atributos do relacionamento na entidade do lado N.
Obs: Essa regra refere-se ao uso de cardinalidade 1:N. No caso de uso da restrio
(min, max) para a cardinalidade do relacionamento, a chave primria da relao do
lado indicado com (min,N) deve ser incluida como chave estrangeira na relao do
lado (min,1).

M:N
Criar uma nova relao para representar o relacionamento. Os atributos que iro
compor esta relao sero as chaves primrias das duas relaes participantes do
relacionamento (estes iro formar a chave primria desta nova relao), juntamente
com os atributos do relacionamento.

Relacionamentos n_rios, n>2
O tratamento anlogo ao de relacionamento N:M. A chave primria geralmente a
combinao das chaves primrias das entidades participantes do relacionamento.

Obs: O tratamento dado para relacionamentos N:M pode ser adotado para
relacionamentos 1:1 e 1:N quando existem poucas instncias envolvidas no
relacionamento (isto , quando se trata de relacionamento parcial).

d. Tratamento de hierarquias de generalizao
Considere a hierarquia de generalizao da figura a seguir.

O mapeamento dessa hierarquia para esquemas de relao pode seguir uma das opes
abaixo:

d1. Criar um esquema de relao correspondente a C:
C (ch, a
1
, a
2
, ..., a
n
)
e um esquema de relao para cada S
i
, i=1,...,m :
S
i
(ch, atributos de S
i
)
d2. Somente criar um esquema de relao R
i
para cada subclasse S
i
, i=1,...,m:
R
i
(ch, a
1
, a
2
, ..., a
n
, atributos de S
i
)

Esta opo adequada para hierarquias de generalizao com cobertura total e
exclusiva.
Um inconveniente dessa opo que para toda busca interessada em recuperar
uma entidade arbitrria em C, deve-se pesquisar todas as m relaes R
i
.

d3. Criar uma s relao R, colocando em R os atributos de todas as entidades
envolvidas na generalizao. Neste caso pode-se ter as seguintes situaes:
d3a. As classes so disjuntas: cria-se um atributo t para indicar a qual subclasse uma
determinada tupla de R pertence.
R(ch, a
1
, a
2
, ..., a
n
, atributos de S
1
, atributos de S
2
, ..., atributos de S
m
, t)

ch
a
1

a
2

...
a
n

C
S
1 S
2
S
m

. . .
d3b. As classes se sobrepem:
R(ch, a
1
, a
2
, ..., a
n
, atributos de S
1
, atributos de S
2
, ..., atributos de S
m
, t
1
, t
2
,..., t
m
)
onde cada t
i
pode ser um atributo booleano para indicar se a tupla pertence ou no
subclasse S
i
.

O uso da opo d3 vlido quando o nmero de atributos das subclasses pequeno.
No geral, essa opo gera um grande nmero de valores nulos.

e. Mapeamento de Hierarquias de Herana Mltipla
Para hierarquias de herana mltipla pode-se usar qualquer opo dada. Usualmente
utiliza-se a opo 1, como a seguir.
Considere o esquema abaixo:

Utilizando a opo 1, o mapeamento desse esquema gera o seguinte conjunto de
relaes:
C
1
(ch
1
, atributos da entidade C
1
)
C
2
(ch
2
, atributos da entidade C
2
)
S (ch
1,
ch
2
, atributos da entidade S)
A chave primria de S pode ser a de C
1
ou de C
2
.

Exemplo:

C
1
C
2

S

ch
2
ch
1
Aluno Professor
Assistente-
Ensino
RG
nome
cargo
nro-al
nome
curso
previso_fim_curso
horas_disponveis

Aluno(nro-al, nome, curso)
Professor(RG, nome, cargo)
Assistente_Ensino(nro-al, RG, previso_fim_curso, horas_disponveis)

3.2.1. Exerccios Mapeamento

1. Faa o mapeamento do esquema conceitual do exerccio 8, do captulo 1.
2. Faa o mapeamento do esquema conceitual da figura 2.4.

3.3. Tpicos Adicionais sobre Modelagem de Dados e Mapeamento
Anlise de diferentes situaes

3.3.1.Categorizao - mapeamento
Em algumas situaes de modelagem, surge a necessidade de modelar um nico
relacionamento de superclasse/subclasse, com mais que uma superclasse, onde as
superclasses representam diferentes tipos de entidade. Nesse caso chamamos a
subclasse uma categoria.

Exemplo: Suponha que temos trs tipos de entidades: PESSOA, BANCO E
COMPANHIA. Em um banco de dados para registro de veculos, um proprietrio de um
veculo pode ser uma pessoa, um banco ou uma companhia. Precisamos criar uma
classe que inclui entidades de todos os trs tipos para exercer o papel de proprietrio de
veculo. Cria-se uma categoria PROPRIETRIO que uma subclasse da unio das trs
classes PESSOA, BANCO E COMPANHIA.
A figura 3.3, a seguir, representa uma categoria. As superclasses PESSOA, BANCO E
COMPANHIA so conectadas ao crculo com um smbolo U, indicando uma operao
de unio de conjunto. Na figura 3.3 tem-se duas categorias: PROPRIETRIO, que
uma subclasse da unio de PESSOA, BANCO e COMPANHIA e
VECULO_REGISTRADO, que uma subclasse da unio de CARRO e CAMINHO.
VECULO_REGISTRADO inclui alguns carros e alguns caminhes, mas no
necessariamente todos eles (alguns carros ou caminhes podem no ser registrados).

Uma categoria pode ser:
a) Total ou parcial;
b) As superclasses podem ter diferentes atributos chaves (como na categoria
PROPRIETRIO) ou o mesmo atributo como em veculo registrado;
c) Quando a categoria total ela pode ser alternativamente representada como uma
generalizao. Se duas classes representam os mesmos tipos de entidades e
compartilham muitos atributos, incluindo o mesmo atributo chave, generalizao/
especializao preferido, caso contrrio a categorizao mais apropriada.

Fazer o mapeamento das categorias para o modelo relacional.

3.3.2. Atividades de extenso - fazer o esquema conceitual

Deseja-se armazenar os projetos de extenso desenvolvidos pelos docentes de uma
universidade. Todo Projeto possui: um nmero, ano (nmero e ano identificam um
projeto), nome do projeto, pblico alvo e responsvel. Projetos no existem por si, eles
so compostos por pelo menos uma atividade.
As atividades de extenso que podem compor um projeto so:

Cursos: tipo do curso, carga horria, data de incio, data de final do curso;
Reunies: nmero de inscritos, nmero de participantes, taxa cobrada, perodo;
Eventos: nmero de participantes, tipo do evento (congresso, simpsio, seminrio,etc)
Servios: receita envolvida (cobrada), tipo de servio.
Fig. 3.3 - Exemplo de Categorizao

Pessoa

Banco

Companhia
U
Proprietrio
nome
RG
ender
nro_cart_mot
nomeB enderB
nomeC enderC
Possui
Veculo-
Registrado

nro_chassi

Carro

Caminho
id_veculo
fabricante ano
estilo
id_veculo
tonelagem ano
U
(1,n)
(1,n)
data_compra
Um projeto pode consistir de qualquer conjunto de atividades entre as listadas, podendo
inclusive conter uma mesma atividade mais de uma vez.

3.3.3. Docentes e Docentes Bolsistas - fazer o esquema conceitual

Deseja-se desenvolver um bd para armazenar informaes sobre todos os docentes de
uma universidade. Se o docente j obteve algum tipo de bolsa (de mestrado, doutorado,
ps-doutorado) deseja-se guardar informaes complementares a respeito de sua
situao como bolsista.
De cada docente deseja-se guardar: um cdigo de identificao, nome, CPF, RG e
cargo.
Para docentes bolsistas deseja-se guardar: tipo da bolsa (mestrado/doutorado/ps-
doutorado), instituio de desenvolvimento do trabalho, local, data de incio e de fim da
bolsa.
Um docente pode ter sido bolsista de uma mesma categoria mais de uma vez, em
perodos diferentes envolvendo a mesma instituio de desenvolvimento do trabalho ou
no.

1) Agregao - Fazer mapeamento

Deseja-se desenvolver um banco de dados para armazenar informaes sobre entrevistas
de candidatos a trabalhos para vrias companhias.
Para Companhia deseja-se guardar nome e endereo.
Para candidatos: nome, RG, telefone e endereo.
A cada entrevista realizada com um candidato deve-se guardar a data e nome da pessoa
da companhia que realizou a entrevista.
Algumas entrevistas geram ofertas de trabalho, envolvendo as informaes: tipo de
trabalho, descrio.

Companhia Candidato
entrevista
(1,n)
(1,n)
data entrevistador
resulta-em
Trabalho
tipo_trabalho
descrio
(0,n)
(0,n)
nome endereo
RG
Nome
Fone
ender

Fig. 3.4 - Agregao

3.3.4. A modelagem satisfaz aos requisitos dos usurios?

a) Dado o esquema abaixo,indique quais das consultas a seguir retornam
informaes corretas:

Dado o nmero de um aluno, recupere o nome das disciplinas que ele est cursando
atualmente e os nomes dos professores que esto dando aula para esses alunos.

Dado o nome de um departamento, recupere os nros dos alunos que so orientados
por professores, desse departamento, que atuam na rea de pesquisa "Banco de
Dados".

dado o RG de um professor, recupere o nome dos alunos que esto cursando suas
disciplinas.

Fig. 3.5

pertence

RG
(1,n)

(1,n)

(1,n)

(1,n)
(1,n)

(1,n)

(0,n)

fone
nomedepto
(1,n)

Cursa

Pessoa

Depto

Aluno

Professor

Aluno-
graduado

Aluno-
Doutorado

Disciplina

Aprovado

ministra

Cod-disc
nome
(1,1)

titulo-tese
ano-ingresso

curso
estado-civil
titulao (1,n)
rea-pesquisa
sexo
nro-al
nome
idade
(1,n)
orienta


b) O esquema a seguir atende consulta: "Selecione os nomes dos clientes que
compraram a revista "Veja" na livraria Saraiva1." ?

Fig. 3.6

3.3.5. Elaborao de Esquemas Conceituais

a) Deseja-se fazer a modelagem de um banco de dados envolvendo peas e
projetos, onde para cada pea deseja-se guardar o cdigo da pea, a descrio e o
conjunto de cores existentes para a pea; para cada projeto deseja-se guardar o cdigo
do projeto, uma descrio e o nome do coordenador do projeto. Um projeto usa vrias
peas e uma pea pode ser usada por diferentes projetos.
Faa o esquema conceitual desse problema, supondo-se que deseja-se guardar tambm o
preo das peas nas seguintes situaes:

a1) Para diferentes projetos, uma pea pode possuir diferentes preos.

a2) Para diferentes projetos, uma pea pode possuir diferentes preos e para um
mesmo projeto, uma mesma pea pode ser usada em vrios tamanhos distintos ,
possuindo preos diferentes dependendo do tamanho, porm o mesmo cdigo.

nome
RG
fone

Livraria
vende

Publicao
cod_publ
nome_publ
editora
compra

Cliente
frequenta
nome_livr
endereo
fone
(1,n)
(1,n)
(1,n)
(1,n)
(1,n)
(0,n)
b) Deseja-se manter um banco de dados de empregados, departamentos e projetos.
Dos empregados deseja-se manter seu nmero (nico para cada empregado), nome,
endereo e informaes sobre as funes exercidas nos projetos (cdigo da funo,
nome, descrio).
Dos departamentos mantm-se a sigla (que identifica cada departamento), descrio,
localizao, nomes de suas reparties e data de incio e de trmino de mandato de cada
diretor. Cada departamento possui apenas um diretor em um determinado momento, que
um empregado do departamento. Um mesmo empregado pode ter sido diretor mais de
uma vez em pocas diferentes. Todo departamento possui um diretor.
Dos projetos guarda-se seu cdigo, descrio e o departamento a que pertence.

As seguintes condies devem ser contempladas:
a) Um departamento desenvolve vrios projetos e todos os empregados do
departamento trabalham em todos os projetos desenvolvidos em seu
departamento.
b) Os empregados s trabalham em projetos desenvolvidos em seu departamento e
cada empregado trabalha em um departamento especfico.
c) Cada empregado exerce certas funes em certos projetos (isto , em projetos
distintos, um mesmo empregado pode exercer funes diferentes) e em cada
projeto um empregado pode exercer mais de uma funo.
d) No existe departamento sem empregados.
e) Pode existir departamento que no desenvolve nenhum projeto.

Faa o esquema conceitual desse banco de dados usando o modelo Entidade-
Relacionamento.

3.4. Esquema de Navegao para Operaes de Banco de Dados

Uma operao de banco de dados uma interao elementar com o banco de
dados (atravs de um comando de recuperao ou atualizao), que no inclui
comandos de controle (tais como, if-then-else, while-do, repeat-until). Essas operaes
podem ser realizadas atravs de uma nica chamada ao sistema de banco de dados.
Num sistema de banco de dados, as operaes so realizadas como parte das
atividades que compem um processo. Para cada operao desenha-se um esquema de
operao, que um subconjunto do esquema do banco de dados contendo todos os
elementos que so mencionados na especificao da operao ou que so requeridos
para navegao, se eles no so explicitamente mencionados. Um esquema de operao
inclui:
- atributos usados para condies que governam a seleo de entidades e
relacionamentos,
- atributos usados por operaes de recuperao ou atualizao,
- entidades ou relacionamentos nos quais so inseridas ou eliminadas
instncias ou entidades das quais sero recuperadas instncias,
- relacionamentos ou hierarquias de generalizao que so usadas para
navegao.
Um esquema de navegao um esquema de operao acrescido de smbolos
especiais (exemplificado na figura 3.7):
- setas apontando para os atributos: indicam os atributos que so usados nas
condies de seleo;
- setas ao longo dos relacionamentos: indicam a navegao no banco de dados;
- Letras R (Retrieval), U(Update), I(Insert) e D(Delete) dentro das entidades
ou dos relacionamentos indicam a operao de acesso ao banco de dados.
a
1
E
1

R
R R
a
2
a
3

a
4
E
2

R
Fig. 3.7. Um esquema de navegao
O esquema de navegao da figura 3.7 corresponde consulta em SQL:

SELECT a
3
, a
4

FROM E
1
, R, E
2
WHERE condio-a
1
AND condio-a
2
AND condies de juno

Exemplo. Considere o esquema de banco de dados da figura 3.8 e a seguinte operao
a ser realizada nesse banco de dados: "Selecione todos os nomes de alunos que tiveram
mdia inferior a 6.0 em pelo menos uma disciplina de 2 crditos". O esquema de
navegao correspondente a essa consulta mostrado na figura 3.9.

nome-trab
orientador
(0,1) data-defesa

mdia
ano-sem

Disciplina
cod nome crditos
cursa

Aluno
nroal
nome
cursou
(0,n) (0,n)
(0,n) (0,n)
Aluno-
Mestrado
Fig. 3.8 - Banco de dados de alunos e disciplinas
(0,n)

mdia

Disciplina
crditos
cursou

Aluno
nome
(0,n)
Fig. 3.9 - Esquema de navegao da consulta
R
R
R
O esquema de navegao til para as fases subsequentes do projeto do banco
de dados, em particular para projeto lgico. Na construo de esquemas de navegao
deve-se considerar as seguintes questes:
a) existem operaes que podem gerar mais do que um esquema de navegao;
b) a mesma entidade ou relacionamento pode ser usada em diferentes maneiras pela
mesma operao e isso resulta em uma replicao da entidade ou relacionamento no
esquema de navegao.

3.4.1. Exerccios - Esquema de Navegao

Para o esquema de bd da figura 3.8, faa o esquema de navegao das consultas a
seguir.

1. Selecionar os nomes dos alunos de mestrado que tiveram mdia inferior a 6.0
em pelo menos uma disciplina de 2 crditos.
2. Selecionar os nomes das disciplinas que o aluno Joo da Silvacursou ou est
cursando.

Para o esquema da figura 3.10 faa os esquemas de navegao para as operaes a seguir.
3. Recuperar os nomes de todos os programadores que moram em cidades com menos
que 1000 habitantes.

4. Dado o RG e nome de casada de uma pessoa do sexo feminino existente, atualizar
seu nome e inserir seu nome de solteira.

5. Selecionar os nomes dos fsicos que moram na mesma cidade em que eles nasceram.
(p,e)

Pessoa
RG
nome
profisso
data-nasc
sexo
(0,1) nome_cnjuge
nascida
mora

Cidade
cod estado habitantes
nome
(1,1) (0,m)
(0,m) (0,m)
Homem
cart-reservista
Mulher
Casada
nome-solteira
Fig. 3.10
3.5. Modelagem da Carga do Banco de Dados

O termo "carga do banco de dados" ser empregado para significar as atividades
ou aplicaes que sero realizadas sobre o banco de dados. Para caracterizar a carga
sero utilizados: o volume dos dados e a descrio das aplicaes.
O volume dos dados medido no modelo ER pela determinao das seguintes
informaes:
- N(E) - nmero mdio de instncias da entidade E
- N(R) - nmero mdio de instncias do relacionamento R;
- cardinalidade mdia card-media(E,R) (mdia, para simplificar) de cada
entidade E em cada relacionamento R que ela participa.

Num esquema, a informao sobre o volume dos dados pode ser representada conforme
mostrado na Figura 5, aonde so
definidos: o nmero mdio estimado
de instncias das entidades; o
nmero mdio estimado de
instncias dos relacionamentos; e as
cardinalidades mdias de cada
relacionamento, para cada instncia
de entidade envolvida no
relacionamento, definidas ao lado
das cardinalidades mnima e mxima
dos relacionamentos. O esquema da
Figura 5 representa um banco de
dados de contas bancrias, com uma
mdia de 15.000 clientes, 20.000
contas e 600.000 transaes. Para
cada cliente h, em mdia, 2 contas;
para cada conta h uma mdia de 1.5
clientes e 40 transaes; cada
transao est relacionada, em
(1,2) mdia=1.33
(1,3) mdia=1.5
15.000

Cliente
nro-cli
nome
fone(1,n)
endereo
saldo-lquido
nro-de-contas
limite-crdito
30.000
mantm
20.000
Conta
nro-conta
saldo-conta
800.000
possui
600.000
Transao

nro-trans
data
tipo
valor
(1,n) mdia=2
(1,n) mdia=40
Figura 5 -Esquema com informao
sobre volume de dados
mdia, com 1.33 contas (isso ocorre porque algumas transaes envolvem mais do que
uma conta: por exemplo, transferncia de conta entre conta corrente e poupana,
poupana e emprstimo, etc.).
A cardinalidade mdia calculada por:

A carga da aplicao estimada em termos das operaes importantes
(transaes em batch e on-line, bem como consultas ad hoc). Para muitos casos prticos,
impossvel ter uma idia precisa sobre a futura carga sobre o banco de dados. Deve-se,
portanto, estimar a carga em termos das operaes mais usadas.
Cada operao descrita por:
- seu esquema de navegao;
- a freqncia mdia de ativao da operao, medida em uma unidade
apropriada (por exemplo,100 vezes ao dia, 5 vezes ao ms);
- o tipo da operao (se em batch ou on line).
Os exemplos aqui apresentados iro considerar que as operaes so on-line.
As informaes acima so utilizadas para a elaborao de uma tabela de volume
de acesso das operaes. Essa tabela possui as seguintes informaes (ver tabela
1): o nome da operao (um nome abreviado para a transao ou consulta); a
freqncia (indica quo freqentemente a operao ocorre, em mdia); o nome
do conceito (refere-se ao conceito acessado no esquema de navegao); tipo do
conceito (E, se entidade ou R, se relacionamento); read/write (indica se o acesso
de leitura ou escrita); e nmero mdio de ocorrncias acessadas.
Para o exemplo de contas bancrias, suponha que as seguintes operaes
so realizadas:

O1: Abrir uma conta para um novo cliente (ou clientes, no caso de conta
conjunta). Freqncia: 100 vezes ao dia.
O2: recuperar o saldo lquido de um cliente. Freqncia: 3000 vezes ao dia.
O3: Mostrar as ltimas 10 transaes de uma conta. Freqncia: 200 vezes ao dia.
O4: Retirar dinheiro de uma conta. Freqncia: 2000 vezes ao dia.
O5: Depositar dinheiro em uma conta. Freqncia: 1000 vezes ao dia.
card-mdia = N(R)/ N(E)
A tabela a seguir apresenta o volume de acessos lgicos da operao O1, avaliado com
base no esquema de navegao. Complete a tabela para as outras operaes.
Legenda:
Op: nome da operao E/R: Tipo do conceito (Entidade ou Relacionamento)
R/W: Read ou Write

Tabela de volume de acessos lgicos das operaes
Op Freq Conceito E/R R/W Mdia de ocorrncias acessadas
O1

100 vezes/ dia Conta
Mantm
Cliente
E
R
E
W
W
W
100
100 x 1,5 = 150
100 x 1,5 = 150
O2

O3

O4

O5

4. Projeto Fsico de Banco de Dados
Estruturas de Armazenamento - OpenIngres
4.1. HEAP

Tabela desordenada
Insero: rpida (linha adicionada no fim da tabela)
Adequada para carregar inicialmente a base de dados
Fator de preenchimento: 100%
No deve ser usada para grandes tabelas, a no ser que se crie ndices
secundrios

4.2. HASH
modify employee to hash on age

Funo hash para calcular o endereo, com base em uma chave.
o mtodo de acesso mais rpido para consultas de match exato
No adequado para os tipos de buscas:

- match no exato: Recuperar empregados com idade>50
=> toda a tabela precisa ser pesquisada

- baseadas em faixas de valores.
Ex: encontrar empregados com nmeros entre 50 e 100.

- que utilizam s parte da chave.
Ex: chave = (age,name)

Modify employee to hash on age, name

Select *
From employee
Where employee.age = 28 => busca sequencial!

- que utilizam pattern matching.

Ex: Select * from employee
Where name = Mar%

fator de preenchimento = 50%

Utilizao: quando a recuperao das linhas feita com base em valores
conhecidos da chave.


4.3. ISAM

ndice esttico, nro esttico de pginas na tabela principal
Novas inseres so colocadas :
- no final, se valor chave>todos os existentes, ou
- em rea de overflow
Suporta:
- pattern matching (MA%)
- busca por faixa de valores
- busca atravs de chave parcial (desde que usada a parte mais da esquerda)
- busca por match exato
Utilizao: para tabelas predominantemente estticas.

4.4. Btree

O ndice da Btree dinmico, crescendo com a tabela.
Nvel de ndice = Isam
Diferena da Btree para Isam:
- ndice Isam aponta para pgina de dados
- nvel de ndice Btree -> aponta para as pginas folhas.

Permite buscas com:
- faixa de valores
- pattern matching

RESUMO:

4.5. ndices Secundrios

Create [unique] index [schema.] nome-indice on nome-tabela
(nome-coluna {, nome-coluna}) [with opes]

Custos adicionais nas operaes: atualizao, eliminao e insero.

Fatores a serem levados em conta:
- nro de vezes em que a consulta executada
- tempo de resposta aceitvel
- importncia da consulta

5. Bibliografia

. BATINI, C.; CERI, S. & NAVATHE, S.B. - Conceptual Database Design. The
Benjamin/Cummings Publishing Company, Inc., 470pp., 1992.

. ELMASRI, R. & NAVATHE, S.B. - Fundamentals of Database Systems. Addison-
Wesley Publishing Company, 3
a
. edio, 955 pp., 2000.

. KORTH, H.F. & SILBERSCHATZ, A. - Sistema de Bancos de Dados. Makron
Books, 2
a
. edio revisada, 754 pp., 1995.

. RAMAKRISHNAN, R. - Database Management Systems. McGraw -Hill
Companies, Inc., 741pp., 1998.

. OpenIngres - Manual de utilizao

Projeto de Banco de Dados

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Projeto de Banco de Dados

Enviado por

Direitos autorais:

Formatos disponíveis

Projeto de Banco de Dado Profa.

Marina Teresa Pires Vieira

Você também pode gostar