Sistemas de Informação MODELO CONCEPTUAL DE - Dei-Isep

Sistemas de Informação
MODELO CONCEPTUAL DE DADOS
Escola Superior de Tecnologia e Gestão de Felgueiras
Engenharia Informática
3º ano - 2003/2004
Ana Maria Madureira
Sistemas de Informação
1. MODELO CONCEPTUAL DE DADOS
Descreve o S.I. da Organização identificando:
• ENTIDADES
Objectos do mundo real e com existência independente sobre os quais se pretende
guardar informação.
Ex. Aluno, Disciplina, Cliente, Factura
• RELAÇÕES
Associações entre entidades estabelecidas de acordo com as necessidades de
gestão.
Ex: Frequenta (Aluno, Disciplina)
• ATRIBUTOS
Dados elementares que caracterizam as entidades e as relações.
Ex. ALUNO= #Aluno + Nome + Curso+ …
Os MCD's devem ser desenvolvidos em paralelo c/ os DFD's na fase de Análise,
tendo particular interesse para a definição dos ficheiros ou Base de Dados necessários
para o Sistema de Informação.
Modelo Conceptual de Dados
2
Sistemas de Informação
2. ENTIDADES
2.1.
Entidade Tipo (ou simplesmente Entidade)
Classe de indivíduos caracterizados pelos mesmos Atributos (ex. Aluno)
2.2.
Ocorrência de uma Entidade
Instanciação de uma Entidade_tipo (ex José, nº 980001)
O número de ocorrências previsto para cada entidade é um objectivo importante
da análise tendo em conta que vai determinar a capacidade dos dispositivos de
armazenamento de informação.
2.3.
Atributos de uma Entidade
• Atributo Identificador
Identifica sem ambiguidade cada ocorrência da entidade
Ex. Código_aluno, num_factura
O atributo identificador principal (chave) deve ter obrigatoriamente as
seguintes características :
- Ser ÚNICO – existe uma correspondência bionívoca (sem ambiguidade)
entre o valor do atributo e a ocorrência da entidade a que se refere;
- Ser ETERNO – As características e valores do atributo nunca devem ser
alterados
O atributo identificador principal deve ser definido especificamente para cada
Sistema de Informação de modo a ser independente de alterações externas não
controláveis. Isto é, de modo a garantir que seja Eterno.
Compete ao Analista do Sistema a definição destes atributos.
Um atributo identificador chave também deve ser o mais pequeno possível uma
vez que vai servir de ligação (chave estrangeira) noutras entidade e relações.
Mas nunca tão pequeno que possa ter que ser alterado (deixar de ser eterno) !
Modelo Conceptual de Dados
3
Sistemas de Informação
• Atributos descritivos
Atributos que caracterizam a entidade e cujos valores para, cada ocorrência da
entidade, são (quase) imutáveis ao longo do seu ciclo de vida.
Ex. Nome, data nascimento, sexo
• Atributos de Estado
Atributos cujos valores variam ao longo do ciclo de vida da entidade.
Ex. Saldo_conta, existência_em stock, ano_aluno
• Atributos calculados
São atributos identificados como relevantes para caracterização de uma
entidade mas que podem ser calculados a partir de outros
Ex. Idade_aluno, média_curso
• Atributos de Auditoria
São atributos normalmente só considerados na fase de desenho e que se
destinam a “auditar” as operações realizadas sobre cada ocrrência da entidade:
Ex. Data_criação, data_ult_alteração, utilizador
2.4.
Reconhecimento de Entidades
A identificação das entidade relevantes para o Sistema de Informação a modelar
constitui uma das tarefas mais importantes do Analista de Sistemas, não
existindo nenhum processo “científico “ para o fazer.
Sugestão metodológica baseada em “tipos de entidades”:
1. Identificar todas as entidades com existência física real no ambiente do
sistema a modelar , com as quais este comunica e em relação às quais há
necessidade de guardar informação sobre o seu ciclo de vida:
Ex . Cliente, Fornecedor, Aluno, Professor
Ministério_Educação não é, em geral, uma entidade relevante para o sistema de
informação de uma escola , apesar de poder haver comunicação de informação, uma vez
que não é relevante o seu ciclo de vida.
Modelo Conceptual de Dados
4
Sistemas de Informação
2. Identificar todos os objectos do mundo real com existência física e que
constituem os produtos da actividade/negócio da organização:
Ex. Produto_acabado, Componente, Artigo, Projecto, Obra, Serviço
3. Identificar todos as “entidades informacionais” veiculadas por suportes
físicos reais (papel, documentos electrónicos) cujo ciclo de vida é relevante
para o sistema de informação e pode ser afectado por eventos do ambiente
do sistema :
Ex. Factura, Encomenda
4. Ao longo da fase de Análise novas entidade vão sendo reconhecidas por
agregação e decomposição de entidades ou por relação entre entidades
(nomeadamente no caso de relações do tipo m:n – entidades relação).
Ex. Linha Factura Å Factura, Produto
5. Os factos que originam as transições de estado de uma entidade (i.e afectam
o seu ciclo de vida) também são modelados como Entidades.
Um dos atributos sempre requerido é a data do facto (movimento ou
transacção).
Ex. Movimentos_produto, Movimentos_contabilidade
3. RELAÇÂO
Relação Tipo
Refere uma associação entre dois (ou mais ) entidades tipo
ALUNO
CURRICULUM
DISCIPLINA
NOTA
DATA
Modelo Conceptual de Dados
5
Sistemas de Informação
Ocorrência de uma relação
Refere uma instanciação da relação caracterizada por uma e uma só ocorrência
das entidades que participam na relação
Atributo Identificador da relação
Em geral é constituído pela concatenação dos atributos identificadores das
entidades tipo que nela participam.
#Curriculum = #Aluno + #Disciplina
desde que seja único.
Ex:
PRODUTO
FORNECIMENTO
ENCOMENDA
DATA
QUANT
Se o mesmo produto puder estar em mais do que uma linha (por exemplo no
caso de várias datas de entrega) a concatenação das duas chaves (#Produto +
#Encomenda) não é única. Neste caso é necessário criar um novo atributo
identificador chave (#linha-enc).
3.1.
Cardinalidade de uma entidade numa relação
Número (mínimo e máximo) de vezes que cada ocorrência da entidade pode
participar na relação.
0,1 – cada ocorrência da entidade participa, no máximo, uma vez na relação
1,1 – cada ocorrência da entidade participa uma e só uma vez na relação
0, n – cada ocorrência da entidade pode participar ou não na relação mais que
uma vez
1,n – cada ocorrência da entidade participa pelo menos uma vez na relação
Modelo Conceptual de Dados
6
Sistemas de Informação
3.2.
Dependência Existencial
A cardinalidade mínima = 0 significa que a entidade é independente
existencialmente da relação. Isto é, cada ocorrência da entidade pode existir
sem estar ligada a essa relação.
Se a cardinalidade mínima é superior a zero sigifica que existe uma
dependência existencial da entidade em relação à relação.
Ex.
CLIENTE
(0,n)
(1,1)
FACTURA
(1,n)
(0,n)
PRODUTO
3.3.
Dimensão de uma Relação
Número de entidades que participam na Relação
PROFESSOR
(0,n)
(0,n)
TURMA
AULA
SALA
DISCIPLINA
(0,n)
(0,n)
AULA é uma relação de dimensão 4.
Modelo Conceptual de Dados
7
Sistemas de Informação
Todas as relações podem ser transformadas em relações de dimensão 2
(relações binárias) , “promovendo” as relações a entidades .
No exemplo: considerar AULA uma Entidade .
PROFESSOR
(0,n)
(0,n)
TURMA
(1,1)
(1,1)
AULA
(1,1)
(1,1)
SALA
DISCIPLINA
(0,n)
(0,n)
4. SIMBOLOGIA E NOTAÇÃO DAS RELAÇÕES
Tipo 1
• As relações podem ter dimensão superior a 2
• As cardinalidades minima e máxima de uma entidade numa relação são
referenciadas junto à entidade (caracterizam a entidade)
A Metodologia Merise adopta esta notação. Os exemplos anteriores utilizaram
também estas notações
CLIENTE
Modelo Conceptual de Dados
(0,n)
(1,1)
FACTURA
8
Sistemas de Informação
Tipo 2
• As relações são sempre binárias (entre duas entidades)
• A relação não é representada por qualquer símbolo
• As cardinalidades são referenciadas junto da “entidade relacionada”,
podendo existir várias notações
CLIENTE
1,1
0,n
FACTURA
CLIENTE
FACTURA
CLIENTE
FACTURA
5. TIPOS DE RELAÇÕES BINÁRIAS – MODELAÇÃO ER
Esta modelação visa garantir a visão relacional dos dados
• Relações do tipo 1:1
CAPITAL
PAÍS
#País
#Cidade
0, 1
CIDADE
1,1
#Cidade
#País
- Um país tem uma e uma só cidade como capital
- Uma cidade pode ser capital de um só país (ou de nenhum)
Esta relação é modelada colocando o atributo identificador (chave) de uma
entidade como atributo da outra entidade (chave estrangeira).
Estes atributos podem ser colocados em ambas as entidades embora apenas
seja necessário colocar numa delas para garantir a visão relacional.
Modelo Conceptual de Dados
9
Sistemas de Informação
•
Relações do tipo 1 : n (um para vários)
FACTURA
CLIENTE
1,1
#Factura
#Cliente
0,n
Chave
Estrangeira
Neste caso FACTURA referencia CLIENTE e depende existencialmente da
relação com ele.
A relação é modelada colocando o atributo chave da entidade principal como
atributo (chave estrangeira) da entidade que a referencia.
•
Relações do tipo m : n (muitos para muitos)
ALUNO
CURRICULUM
DISCIPLINA
#Disciplina
#Aluno
m,n
m,n
Neste caso torna-se necessário criar uma nova Entidade (Entidade-Relação)
que se relaciona com as originais através de relações do tipo 1:n.
ALUNO
DISCIPLINA
#Disciplina
#Aluno
1,1
1,1
0,n
Modelo Conceptual de Dados
CURRICULUM
#Aluno
#Disciplina
Data
Nota
0,n
10
Sistemas de Informação
•
Relações Reflexivas
São relações entre entidades do mesmo tipo
Ex.
Precedencias
Disciplina
#Disciplina
#curso
Ano
Semestre
Neste caso a solução é criar uma nova Entidade (relação)
Disciplina
#Disciplina
#curso
Ano
Semestre
Precedências
2,2
0,n
#Disc1
#Disc2
De notar que a cardinalidade mínima e máxima igual a 2: para cada ocorrência
da entidade Precedências correspondem duas e só duas ocorrências da entidade
Disciplina.
Este tipo de relação é típico das estruturas em árvore (ex. Composição de um
produto)
Modelo Conceptual de Dados
11
Sistemas de Informação
6. NORMALIZAÇÂO
A normalização é uma técnica baseada num conjunto de conceitos e regras
propostos por CODD destinados a obter conteúdos de ficheiros de registos
(tabelas) adequados à implementação de bases de dados relacionais.
Objectivos principais da normalização
• Visão Relacional dos dados
Qualquer relação entre entidades devem ser vista como um objecto
informacional idêntico às entidades.
Através de linguagens de interrogação relacionais (tipo SQL) estas relações
são facilmente obtidas.
• Não Redundância da Informação
Cada dado deve ser armazenado uma única vez base de dados .
Evita-se a inconsistência dos dados e reduzem-se os recursos para
armazenamento da informação.
O Modelo Conceptual de Dados a obter na fase de análise deve identificar
todas as entidades e relações relevantes do sistema a modelar, caracterizadas
em termos dos atributos e das cardinalidades respectivas.
Independentemente da utilização de uma Base de dados relacional na fase de
implementação, o MCD final deve estar normalizado.
Modelo Conceptual de Dados
12
Sistemas de Informação
Exemplo :
Pretende-se desenvolver uma aplicação informática destinada à gestão da
Facturação de uma empresa .
Uma factura tem o seguinte formato/conteúdo:
#Factura ________________
Data ________
#Cliente ________
Nome _____________________________
Morada___________________ CodPostal _____ Localidade ___________
#Vendedor _______ Nome-vend ___________________________________
#Prod
_____
_____
_____
_____
_____
Des-Prod
Quant
___________________ _______
___________________ _______
___________________ _______
___________________ _______
___________________ _______
Preço-Unit
_________
_________
_________
_________
_________
Preço-total
_________
_________
_________
_________
_________
Total-factura:…. _________
Existindo um número indefinido e variável de produtos por factura o ficheiro
de Facturas teria o seguinte conteúdo.
Facturas = {#Factura + Data + #Cliente + Nome + Morada + Codpostal +
+ Localidade + #vendedor + Nome-vend + #Prod1 + Des-Prod1 +
Quant1 + Preço-unit1 + Preço + #Prod2 + Des-Prod2 + Quant2 + Preçounit2 + Preço-total2 + …. + #Prodn + Des-Prodn + Quantn +
+ Preço-unit2 + Preço-total2 + Total-factura }
Problemas :
- A partir deste conteúdo como obter a relação de todas as facturas onde um
dado produto X foi vendido?
(notar que em cada factura o mesmo produto X , caso exista, pode ter uma
“posição diferente”).
ÆNão existe uma visão relacional dos dados
Modelo Conceptual de Dados
13
Sistemas de Informação
- É necessário prever um número máximo de produtos por factura
- O que fazer se ocorre uma factura com um número superior?
- Quanto maior o número máximo previsto maior o “despedício
(overhead) para facturas com poucos produtos.
Origem dos problemas: Existem grupos repetidos (redundância).
Um ficheiro não está normalizado se tiver grupos repetidos
No exemplo o conteúdo do ficheiro podia ser especificado com as notações do
dicionário de dados explicitando o grupo repetido entre chavetas.
Facturas = {#Factura + Data + #Cliente + Nome + Morada + Codpostal +
+ Localidade + #vendedor + Nome-vend + { #Prod + Des-Prod + +
Quant + Preço-unit + Preço-total } + Total-factura }
1ª Forma Normal
Um ficheiro está na 1ª forma normal se não tiver grupos repetidos
No caso do exemplo basta partir o ficheiro em dois :
Facturas = {#Factura + Data + #Cliente + Nome + Morada + Codpostal +
+ Localidade + #vendedor + Nome-vend + Total-factura }
Linhas_factura = { #Factura + #Prod + Des-Prod + Quant + Preço-unit + +
Preço-total }
Modelo Conceptual de Dados
14
Sistemas de Informação
(Nota : A chave de Linhas_Factura é obtida pela concatenação da chave de
Factura (#Factura) com #Produto)
Os problemas existentes foram resolvidos:
- A partir do ficheiro Linhas_factura é muito simples obter a ralação das
facturas onde um dado produto foi vendido.
Æ Existe uma visão relacional dos dados
SQL
SELECT * FROM Linhas_Factura
WHERE #Produto = X
- Para cada factura existem tantos registos (ocorrências ) de Linhas_facturas
quantos os produtos que essa factura tem.
Isto é, não há “overhead”.
O grande objectivo da 1ª Forma normal é garantir a Visão Relacional dos
Dados
Problema ainda existente : REDUNDÂNCIA
Ex:
- Se um produto for facturado 1000 vezes é necessário guardar a designação
do produto 1000 vezes.
- nome de um Cliente (e de um Vendedor) é armazenado tantas vezes quantas
as facturas onde participou.
Solução : 2ª e 3ª Formas normais
Garantir que todos os atributos dependam funcionalmente apenas do
identificador principal (Chave)
Modelo Conceptual de Dados
15
Sistemas de Informação
Dependência funcional (entre atributos)
Um atributo a depende funcionalmente do atributo b se para cada valor
de b é possível saber , sem ambiguidade, qual o valor do atributo de a.
O grande objectivo da 2ªe 3ª Formas normais é evitar a Redundância dos
Dados
2ª Forma normal
Um ficheiro está na 2ª forma normal se, para além de estar na 1ª forma
normal, cada atributo não chave depende funcionalmente da totalidade
da chave.
A situação de um ficheiro não estar na 2ª forma normal verifica-se no caso do
identificador chave ser composto ( normalmente resultante da aplicação da 1ª
forma normal ao retirar os grupos repetidos).
Ex. Linhas_factura ( Atributo Identif. = #Factura + #Produto)
Linhas_factura = { #Factura + #Prod + Des-Prod + Quant + Preço-unit + +
Preço-total }
O atributo Des-Prod depende funcionalmente apenas de #Prod. Pressupondo
que a designação do produto é fixa e a mesma em todas as facturas verifica-se
REDUNDÂNCIA.
Solução : Criar um novo ficheiro que relacione #Prod com Des-Prod.
Produtos = { #Prod + Des- Prod }
Os restantes atributos dependem funcionalmente da totalidade da chave.
Modelo Conceptual de Dados
16
Sistemas de Informação
Nota - O atributo Preço-unit representa o preço unitário do produto na data da
factura. O ficheiro Produtos poderá ter também um atributo relativo ao
Preço unitário, mas correspondente ao valor de base actual. O que
acontece se ele for alterado ? É possível refazer integralmente a factura ?
Importante: A possibilidade de reconstruir os dados/informação com efeitos
retroactivos é um dos objectivos mais importantes ( e difíceis) de garantir na
concepção de um sistema de Informação
3ª Forma normal
Um ficheiro está na 3ª forma normal se, para além de estar na 2ª forma
normal, os atributos não chave não dependem funcionalmente uns dos
outros.
No ficheiro Facturas existem dependências funcionais entre atributos não
chave que implicam Redundância:
Facturas = {#Factura + Data + #Cliente + Nome + Morada + Codpostal +
+ Localidade + #vendedor + Nome-vend + Total-factura }
A solução é criar novos ficheiros (tabelas) :
Clientes = { #Cliente + Nome + Morada + Codpostal + Localidade}
Vendedor = { #Vendedor + Nome-vend}
No caso do código postal determinar sem ambiguidade a localidade poderia
também definir-se um novo ficheiro:
Codigos_postais = { codpostal + localidade}
Modelo Conceptual de Dados
17
Sistemas de Informação
Em resumo, normalizando o conteúdo do ficheiro Facturas até à 3ª Forma Normal
obtinham-se os seguintes ficheiros normalizados:
Facturas = {#Factura + Data + #Cliente + #vendedor + Total-factura }
Linhas_factura = { #Factura + #Prod + Quant + Preço-unit + Preço-total }
Produtos = { #Prod + Des- Prod }
Clientes = { #Cliente + Nome + Morada + Codpostal }
Vendedor = { #Vendedor + Nome-vend}
Codigos_postais = { Codpostal + Localidade}
Nota
Os atributos Preço-total, se for igual a Quant*Preço-unit, e Total-factura , se igual
ao somatório de Preço-total, constituem também redundância ( atributos calculados).
Os atributos calculados não são em geral armazenados . Aparecem apenas nos
“outputs”, como é o caso do documento impresso Factura.
Modelo Conceptual de Dados
18
Sistemas de Informação
Importante:
De notar que o exercício (sistemático) de normalização de um documento constituiu
um auxiliar precioso de análise para identificação das principais Entidades e Relações
da aplicação informática destinada à gestão da Facturação.
O Modelo Conceptual de Dados é facilmente derivado:
Cliente
#Cliente
Nome
Morada
Codpostal
Codpostal
#Codpostal
Localidade
Modelo Conceptual de Dados
Factura
Vendedor
#Factura
Data
#Cliente
#Vendedor
#Vendedor
Nome
Linha-fact
Produto
#Factura
#Produto
Quant
Preço-unit
#Produto
Des-prod
19