Escolar Documentos
Profissional Documentos
Cultura Documentos
v1 n1 Art03 PDF
v1 n1 Art03 PDF
ARAJO, M. A. P.
1. INTRODUO
33
Este artigo dividido em outras seis sees, alm desta introduo. Na seo
2 so apresentadas as principais caractersticas de modelagem de dados. A seo 3
discute a utilizao de relacionamentos 1:1 e 1:n, enquanto a seo 4 apresenta a
utilizao de relacionamentos n:n. Na seo 5 so abordados os autorelacionamentos e relacionamentos ternrios. A seo 6 descreve a utilizao de
Agregaes e Estruturas de Generalizao/Especializao e, por fim, a seo 7
apresenta as consideraes finais.
34
Relacionamentos ainda podem ter atributos, quando algum dado precisa ser
associado ligao das duas instncias envolvidas. Relacionamentos so descritos
atravs da cardinalidade, que indica como as instncias das entidades se
relacionam. Os tipos utilizados na modelagem so (KORTH, SILBERCHATZ e
SUDARSHAN, 2006):
35
Neste sentido, existem algumas regras de converso do Modelo EntidadeRelacionamento para o Diagrama de Tabelas Relacionais, sendo as principais
(ELMASRI e NAVATHE, 2005):
Relacionamentos
n:n
devem
ser
transformados
em
dois
36
1 Forma Normal (1FN): toda relao deve ter uma chave primria e
deve-se garantir que todo atributo seja atmico. Atributos compostos
devem ser separados. Por exemplo, um atributo Endereo deve ser
subdividido
em
seus
componentes:
Logradouro,
Nmero,
37
38
uma
nica
obra
e ser
de
um nico usurio,
39
40
(cod_emprestimo,
data_emprestimo,
cod_obra,
horario_emprestimo,
cod_usuario,
data_prevista_retorno,
num_matricula_funcionario)
Devolucao
(cod_emprestimo,
data_devolucao,
horario_devolucao,
num_matricula_funcionario)
Funcionario (num_matricula, nome_funcionario, cod_departamento)
Saber Digital: Revista Eletrnica do CESVA, Valena, v. 1, n. 1, p. 33-69, mar./ago. 2008
41
Departamento
(cod_departamento,
nome_departamento,
num_matricula_chefe)
Reserva
(cod_reserva,
cod_usuario,
cod_obra,
data_reserva,
horario_reserva, data_retirada)
precisaria
existir.
Relacionamentos
com
esta
42
43
44
FK
Tipo
Inteiro
Texto
Texto
Inteiro
Inteiro
tipo_obra
Inteiro
cod_editora
Inteiro
Obra
Tamanho Obrigatrio
Restries
Sim
50
Sim
50
Sim
Sim
Sim
1=Disponvel
2=Emprestado
Sim
1=Livro
2=Peridico
Sim
Integridade
referencial com
tabela Editora
Tipo
Inteiro
Texto
Texto
Editora
Tamanho Obrigatrio
Sim
50
Sim
50
Sim
Restries
Usuario
Tipo Tamanho
Inteiro
Texto
50
Texto
50
Inteiro
Texto
20
Texto
30
Texto
30
Texto
2
Texto
10
Texto
15
Texto
20
Obrigatrio
Sim
Sim
Sim
Sim
No
No
Sim
Sim
No
No
No
Restries
45
Atributo
cod_emprestimo
cod_obra
Emprestimo
Tipo
Tamanho
Inteiro
Inteiro
Obrigatrio
Sim
Sim
FK
cod_usuario
Inteiro
Sim
data_emprestimo
horario_emprestimo
data_prevista_retorno
num_matricula_funcion
ario
Data
Hora
Data
Inteiro
Sim
Sim
Sim
Sim
FK
Restries
Integridade
referencial
com
tabela
Obra
Integridade
referencial
com
tabela
Usuario
Integridade
referencial
com
tabela
Funcionario
Devolucao
Tipo Tamanho Obrigatrio
Inteiro
Sim
Atributo
cod_emprestimo
data_devolucao
horario_devolucao
num_matricula_funciona
rio
FK
Data
Hora
Inteiro
Sim
Sim
Sim
Restries
Integridade
referencial com
tabela
Emprestimo
Integridade
referencial com
tabela
Funcionario
Atributo
num_matricula
nome_funcionario
cod_departamento
Funcionario
Tipo
Tamanho
Inteiro
Texto 50
Inteiro
Obrigatrio
Sim
Sim
Sim
Restries
Integridade
referencial
com
tabela
Departamento
46
Obrigatrio
Sim
Sim
Sim
Restries
Integridade
referencial com
tabela
Funcionrio
Chave
PK
FK
Atributo
cod_reserva
cod_usuario
Tipo
Inteiro
Inteiro
Obrigatrio
Sim
Sim
FK
cod_obra
Inteiro
Sim
data_reserva
horario_reserva
data_retirada
Data
Hora
Data
Sim
Sim
Sim
Restries
Integridade
referencial
com
tabela Usuario
Integridade
referencial
com
tabela Obra
chave
estrangeira
em
relao
tabela
Emprestimo,
47
48
Neste caso, a nova tabela gerada, Obra_Assunto, ter como chave primria a
juno das chaves primrias das duas tabelas participantes, formando uma chave
primria composta. Alm disso, cada parte da chave primria ser tambm uma
chave estrangeira para sua tabela de origem. Assim, a cada relacionamento de uma
obra com um assunto, gera-se um novo registro na tabela Obra_Assunto,
transformando o relacionamento n:n do modelo conceitual em dois relacionamentos
1:n no modelo lgico. Observa-se ainda que o nome do relacionamento no modelo
conceitual foi substitudo por um nome de tabela que tivesse algum significado no
modelo lgico, pois este ser o nome da tabela no banco de dados.
Um outro requisito apresentado trata da necessidade de armazenar os
autores de uma obra. Trata-se tambm de um relacionamento n:n, uma vez que uma
obra tem diversos autores e um autor pode estar associado a diversas obras. Porm,
neste caso especfico, tem-se uma particularidade, uma vez que importante
identificar a ordem dos autores de uma obra, caracterizando quem o primeiro
autor, o segundo, e assim sucessivamente. Este requisito tornou-se necessrio para
evitar cadastrar repetidamente um mesmo autor que participa em diversas obras,
facilitando tambm a busca por autores. A questo a ser tratada aqui relativa
ordem do autor na lista de autores de uma obra. Esta informao no pode ficar na
tabela Obra, uma vez que esta possui diversos autores, e tambm no pode ficar na
tabela Autor, uma vez que o mesmo pode estar vinculado a diversas obras. Neste
caso, o local apropriado para armazenar esta informao no prprio
Saber Digital: Revista Eletrnica do CESVA, Valena, v. 1, n. 1, p. 33-69, mar./ago. 2008
49
50
51
(0,N)
(1,1)
Devolucao
(0,1)
(1,1)
(0,N)
Emprestimo
(0,N)
ordem
(0,N)
(0,N)
(0,N)
Possui
Usuario
(0,N)
Chefia
(1,1)
(0,N)
(0,N)
(0,1)
Funcionario
(1,1)
Autor
Possui
(1,1)
(1,1)
(1,1)
(0,N)
Obra
Lotacao
Exemplar
(1,1)
(0,N)
(1,1)
(0,N)
Assunto
Reserva
(0,N)
Departamento
(0,1)
(1,1)
Editora
52
Tipo
Inteiro
Texto
Inteiro
Inteiro
FK
Inteiro
cod_editora
Obra
Tamanho Obrigatrio
Restries
Sim
50
Sim
Sim
Sim
1=Livro
2=Peridico
Sim
Integridade
referencial com
tabela Editora
Assunto
Tipo Tamanho Obrigatrio
Inteiro
Sim
Texto
50
Sim
Restries
Tipo
Inteiro
Texto
Autor
Tamanho Obrigatrio
Sim
50
Sim
Restries
PK
cod_assunto
Obra_Assunto
Tipo
Tamanho Obrigatrio Restries
Inteiro
Sim
Integridade
referencial com
tabela Obra
Inteiro
Sim
Integridade
referencial com
tabela Assunto
PK
cod_autor
ordem
Obra_Autor
Tamanho Obrigatrio
Restries
Sim
Integridade
referencial com
tabela Obra
Inteiro
Sim
Integridade
referencial com
tabela Autor
Inteiro
Sim
Tipo
Inteiro
53
Chave
Atributo
PK FK cod_obra
num_exemplar
data_aquisicao
situacao_exemplar
Atributo
cod_emprestimo
cod_obra
num_exemplar
Emprstimo
Tipo Tamanho Obrigatrio
Inteiro
Sim
Inteiro
Sim
Inteiro
Sim
FK
cod_usuario
Inteiro
Sim
data_emprestimo
horario_emprestimo
data_prevista_retorno
num_matricula_funcionar
io
Data
Hora
Data
Inteiro
Sim
Sim
Sim
Sim
FK
Restries
Integridade
referencial com
tabela Exemplar
Integridade
referencial com
tabela Usuario
Integridade
referencial com
tabela
Funcionario
Exemplar.
Na
tabela
Obra,
foram
retirados
os
atributos
54
5.
UTILIZAO
DE
AUTO-RELACIONAMENTOS
RELACIONAMENTOS
TERNRIOS
55
56
outro usurio. Por outro lado, um usurio poder indicar diversos novos usurios.
Este problema semelhante ao anterior, exceto que o relacionamento neste caso
1:n. Desta forma, como todos so usurios, existir um auto-relacionamento na
tabela Usurio. Sendo um relacionamento 1:n, basta acrescentar uma chave
estrangeira para o usurio que fez a indicao na prpria tabela Usuario. A Figura
13 mostra a soluo para este problema tanto no modelo conceitual como no lgico,
apresentando apenas alguns dos atributos da tabela Usuario.
57
58
Chave Atributo
PK FK cod_assunto
59
Usuario
Tipo Tamanho Obrigatrio Restries
Inteiro
Sim
Texto 50
Sim
Texto 50
Sim
Inteiro
Sim
Texto 20
No
Texto 30
No
Texto 30
Sim
Texto 2
Sim
Texto 10
No
Texto 15
No
Texto 20
No
Inteiro
No
Integridade
referencial
com tabela
Usuario
Chave
Atributo
PK FK cod_obra
num_exemplar
60
6.
UTILIZAO
DE
AGREGAES
ESTRUTURAS
DE
GENERALIZAO/ESPECIALIZAO
61
que
representa
situaes
onde
determinadas
62
atributos da hierarquia foram agrupados numa nica tabela, fazendo com que
atributos fiquem eventualmente vazios em funo do tipo da obra. A situao 2
representa apenas as especializaes, fazendo com que os atributos da
generalizao sejam repetidos. A situao 3 apresenta uma tabela para cada
entidade da hierarquia, eliminando atributos repetidos, mas fazendo com que o
acesso a uma obra tenha que agrupar dados de mais de uma tabela. Neste estudo
de caso, ser utilizada a situao 3, onde cada entidade mapeada para uma tabela
especfica, no havendo redundncia de dados ou atributos com valores nulos em
funo do tipo de obra em questo, atendendo assim ao requisito proposto.
63
64
Emprestimo
Autor
Funcionario
Reserva
Obra_Autor
Exemplar
Obra_Assunto
Manutencao
Obra
Motivo_Manutencao
Assunto
Departamento
Assunto_Relacionamento
Livro
Periodico
Requisicao
Editora
Item_Requisicao
Fornecedor
65
ISBN
Livro
Tamanho Obrigatrio
Restries
Sim
Integridade
referencial com
tabela Obra
Inteiro
Sim
Tipo
Inteiro
ISSN
Periodico
Tipo Tamanho Obrigatrio
Restries
Inteiro
Sim
Integridade
referencial com
tabela Obra
Inteiro
Sim
Fornecedor
Tipo Tamanho Obrigatrio
Inteiro
Sim
Texto
50
Sim
Texto
15
No
Restries
Requisicao
Tipo Tamanho
Inteiro
Data
Inteiro
Obrigatrio
Restries
Sim
Sim
Sim
1=Aberta
2=Fechada
66
FK cod_obra
quantidade
FK cod_fornecedor
preco_compra
data_compra
Item_Requisicao
Tipo Tamanho Obrigatrio
Restries
Inteiro
Sim
Integridade
referencial com
tabela
Requisicao
Inteiro
Sim
Integridade
referencial com
tabela Obra
Integer
Sim
Integer
No
Integridade
referencial com
tabela
Fornecedor
Real
No
Data
No
Percebe-se nas tabelas Livro e Periodico que ambas possuem como chave
primria o campo cod_obra, o mesmo da tabela que representa a generalizao.
Esta uma caracterstica de estruturas generalizao/especializao, onde todas as
tabelas da hierarquia possuem a mesma chave primria, aquela definida na tabela
mais genrica. Usualmente, ainda coloca-se um atributo na tabela que representa a
generalizao, neste caso a tabela Obra, para indicar a tabela que possui a
complementao de seus dados, Livro ou Periodico neste caso. Isto no precisou
ser feito neste momento, pois a tabela Obra j possua um atributo chamado
tipo_obra, justamente para este fim.
A tabela Item_Requisicao representa a agregao do modelo conceitual.
Percebe-se, neste caso, que o relacionamento entre as entidades Obra e Requisicao
de cardinalidade n:n, fazendo com que esta tabela surgisse de qualquer forma. A
particularidade aqui se refere ligao desta tabela Item_Requisicao com a tabela
Fornecedor, de forma opcional, oferecendo a possibilidade de um item de requisio
ainda no possuir um fornecedor. Isto fica evidenciado no modelo conceitual uma
vez que o relacionamento com a tabela Fornecedor feito diretamente com a
agregao, e no com nenhuma de suas entidades participantes, caracterizando
que um fornecedor est associado com uma obra de uma determinada requisio.
Esta situao no poderia ser resolvida com um relacionamento ternrio entre as
entidades Obra, Fornecedor e Requisio pois, neste caso, as chaves primrias das
trs
entidades
participantes
comporiam
chave
primria
da
entidade
67
7. Consideraes Finais
8. Referncias Bibliogrficas
68
69