Sistemas de Informao

MODELO CONCEPTUAL DE DADOS

Escola Superior de Tecnologia e Gesto de Felgueiras Engenharia Informtica 3 ano - 2003/2004

Ana Maria Madureira

Sistemas de Informao

1. MODELO CONCEPTUAL DE DADOS Descreve o S.I. da Organizao identificando: ENTIDADES Objectos do mundo real e com existncia independente sobre os quais se pretende guardar informao. Ex. Aluno, Disciplina, Cliente, Factura RELAES Associaes entre entidades estabelecidas de acordo com as necessidades de gesto. Ex: Frequenta (Aluno, Disciplina) ATRIBUTOS Dados elementares que caracterizam as entidades e as relaes. Ex. ALUNO= #Aluno + Nome + Curso+

Os MCD's devem ser desenvolvidos em paralelo c/ os DFD's na fase de Anlise, tendo particular interesse para a definio dos ficheiros ou Base de Dados necessrios para o Sistema de Informao.

Modelo Conceptual de Dados

Sistemas de Informao

2. ENTIDADES

2.1.

Entidade Tipo (ou simplesmente Entidade)

Classe de indivduos caracterizados pelos mesmos Atributos (ex. Aluno) 2.2. Ocorrncia de uma Entidade

Instanciao de uma Entidade_tipo (ex Jos, n 980001) O nmero de ocorrncias previsto para cada entidade um objectivo importante da anlise tendo em conta que vai determinar a capacidade dos dispositivos de armazenamento de informao. 2.3. Atributos de uma Entidade

Atributo Identificador Identifica sem ambiguidade cada ocorrncia da entidade Ex. Cdigo_aluno, num_factura O atributo identificador principal (chave) deve ter obrigatoriamente as seguintes caractersticas : - Ser NICO existe uma correspondncia bionvoca (sem ambiguidade) entre o valor do atributo e a ocorrncia da entidade a que se refere; - Ser ETERNO As caractersticas e valores do atributo nunca devem ser alterados O atributo identificador principal deve ser definido especificamente para cada Sistema de Informao de modo a ser independente de alteraes externas no controlveis. Isto , de modo a garantir que seja Eterno. Compete ao Analista do Sistema a definio destes atributos. Um atributo identificador chave tambm deve ser o mais pequeno possvel uma vez que vai servir de ligao (chave estrangeira) noutras entidade e relaes. Mas nunca to pequeno que possa ter que ser alterado (deixar de ser eterno) !

Modelo Conceptual de Dados

Sistemas de Informao

Atributos descritivos Atributos que caracterizam a entidade e cujos valores para, cada ocorrncia da entidade, so (quase) imutveis 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, existncia_em stock, ano_aluno Atributos calculados So atributos identificados como relevantes para caracterizao de uma entidade mas que podem ser calculados a partir de outros Ex. Idade_aluno, mdia_curso Atributos de Auditoria So atributos normalmente s considerados na fase de desenho e que se destinam a auditar as operaes realizadas sobre cada ocrrncia da entidade: Ex. Data_criao, data_ult_alterao, utilizador 2.4. Reconhecimento de Entidades

A identificao das entidade relevantes para o Sistema de Informao a modelar constitui uma das tarefas mais importantes do Analista de Sistemas, no existindo nenhum processo cientfico para o fazer. Sugesto metodolgica baseada em tipos de entidades: 1. Identificar todas as entidades com existncia fsica real no ambiente do sistema a modelar , com as quais este comunica e em relao s quais h necessidade de guardar informao sobre o seu ciclo de vida: Ex . Cliente, Fornecedor, Aluno, Professor
Ministrio_Educao no , em geral, uma entidade relevante para o sistema de informao de uma escola , apesar de poder haver comunicao de informao, uma vez que no relevante o seu ciclo de vida.

Modelo Conceptual de Dados

Sistemas de Informao

2. Identificar todos os objectos do mundo real com existncia fsica e que constituem os produtos da actividade/negcio da organizao: Ex. Produto_acabado, Componente, Artigo, Projecto, Obra, Servio 3. Identificar todos as entidades informacionais veiculadas por suportes fsicos reais (papel, documentos electrnicos) cujo ciclo de vida relevante para o sistema de informao e pode ser afectado por eventos do ambiente do sistema : Ex. Factura, Encomenda 4. Ao longo da fase de Anlise novas entidade vo sendo reconhecidas por agregao e decomposio de entidades ou por relao entre entidades (nomeadamente no caso de relaes do tipo m:n entidades relao). Ex. Linha Factura Factura, Produto

5. Os factos que originam as transies de estado de uma entidade (i.e afectam o seu ciclo de vida) tambm so modelados como Entidades. Um dos atributos sempre requerido a data do facto (movimento ou transaco). Ex. Movimentos_produto, Movimentos_contabilidade 3. RELAO Relao Tipo Refere uma associao entre dois (ou mais ) entidades tipo
ALUNO CURRICULUM NOTA DATA DISCIPLINA

Modelo Conceptual de Dados

Sistemas de Informao

Ocorrncia de uma relao Refere uma instanciao da relao caracterizada por uma e uma s ocorrncia das entidades que participam na relao Atributo Identificador da relao Em geral constitudo pela concatenao dos atributos identificadores das entidades tipo que nela participam. #Curriculum = #Aluno + #Disciplina desde que seja nico. Ex:
PRODUTO FORNECIMENTO DATA QUANT ENCOMENDA

Se o mesmo produto puder estar em mais do que uma linha (por exemplo no caso de vrias datas de entrega) a concatenao das duas chaves (#Produto + #Encomenda) no nica. Neste caso necessrio criar um novo atributo identificador chave (#linha-enc). 3.1. Cardinalidade de uma entidade numa relao Nmero (mnimo e mximo) de vezes que cada ocorrncia da entidade pode participar na relao.

0,1 cada ocorrncia da entidade participa, no mximo, uma vez na relao 1,1 cada ocorrncia da entidade participa uma e s uma vez na relao 0, n cada ocorrncia da entidade pode participar ou no na relao mais que uma vez 1,n cada ocorrncia da entidade participa pelo menos uma vez na relao
Modelo Conceptual de Dados 6

Sistemas de Informao

3.2.

Dependncia Existencial A cardinalidade mnima = 0 significa que a entidade independente existencialmente da relao. Isto , cada ocorrncia da entidade pode existir sem estar ligada a essa relao. Se a cardinalidade mnima superior a zero sigifica que existe uma dependncia existencial da entidade em relao relao. Ex.
CLIENTE

(0,n)

(1,1)

FACTURA

(1,n)

(0,n)
PRODUTO

3.3.

Dimenso de uma Relao

Nmero de entidades que participam na Relao

PROFESSOR

(0,n)

(0,n)
TURMA

AULA

SALA

DISCIPLINA

(0,n)

(0,n)

AULA uma relao de dimenso 4.

Modelo Conceptual de Dados 7

Sistemas de Informao

Todas as relaes podem ser transformadas em relaes de dimenso 2 (relaes binrias) , promovendo as relaes a entidades . No exemplo: considerar AULA uma Entidade .
(0,n) (1,1)
AULA

(0,n) (1,1)

PROFESSOR

TURMA

(1,1)
SALA

(1,1)
DISCIPLINA

(0,n)

(0,n)

4. SIMBOLOGIA E NOTAO DAS RELAES Tipo 1 As relaes podem ter dimenso superior a 2 As cardinalidades minima e mxima de uma entidade numa relao so referenciadas junto entidade (caracterizam a entidade) A Metodologia Merise adopta esta notao. Os exemplos anteriores utilizaram tambm estas notaes
CLIENTE

(0,n)

(1,1)

FACTURA

Modelo Conceptual de Dados

Sistemas de Informao

Tipo 2 As relaes so sempre binrias (entre duas entidades) A relao no representada por qualquer smbolo As cardinalidades so referenciadas junto da entidade relacionada, podendo existir vrias notaes
CLIENTE

1,1

0,n

FACTURA

CLIENTE

FACTURA

CLIENTE

FACTURA

5. TIPOS DE RELAES BINRIAS MODELAO ER Esta modelao visa garantir a viso relacional dos dados Relaes do tipo 1:1
PAS #Pas #Cidade
0, 1

CAPITAL
1,1

CIDADE

#Cidade #Pas

- Um pas tem uma e uma s cidade como capital - Uma cidade pode ser capital de um s pas (ou de nenhum)

Esta relao 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 necessrio colocar numa delas para garantir a viso relacional.
Modelo Conceptual de Dados 9

Sistemas de Informao

Relaes do tipo 1 : n (um para vrios)

CLIENTE 1,1 0,n
FACTURA

#Factura #Cliente

Chave Estrangeira

Neste caso FACTURA referencia CLIENTE e depende existencialmente da relao com ele. A relao modelada colocando o atributo chave da entidade principal como atributo (chave estrangeira) da entidade que a referencia.

Relaes do tipo m : n (muitos para muitos)

ALUNO
#Aluno CURRICULUM
DISCIPLINA

#Disciplina

m,n

m,n

Neste caso torna-se necessrio criar uma nova Entidade (Entidade-Relao) que se relaciona com as originais atravs de relaes do tipo 1:n.

ALUNO #Aluno

DISCIPLINA

#Disciplina

1,1 0,n
CURRICULUM

1,1

#Aluno #Disciplina Data Nota

0,n

Modelo Conceptual de Dados

10

Sistemas de Informao

Relaes Reflexivas So relaes entre entidades do mesmo tipo Ex.

Precedencias

Disciplina

#Disciplina #curso Ano Semestre

Neste caso a soluo criar uma nova Entidade (relao)

Disciplina Precedncias

#Disciplina #curso Ano Semestre

2,2

0,n

#Disc1 #Disc2

De notar que a cardinalidade mnima e mxima igual a 2: para cada ocorrncia da entidade Precedncias correspondem duas e s duas ocorrncias da entidade Disciplina. Este tipo de relao tpico das estruturas em rvore (ex. Composio de um produto)

Modelo Conceptual de Dados

11

Sistemas de Informao

6. NORMALIZAO A normalizao uma tcnica baseada num conjunto de conceitos e regras propostos por CODD destinados a obter contedos de ficheiros de registos (tabelas) adequados implementao de bases de dados relacionais. Objectivos principais da normalizao Viso Relacional dos dados Qualquer relao entre entidades devem ser vista como um objecto informacional idntico s entidades. Atravs de linguagens de interrogao relacionais (tipo SQL) estas relaes so facilmente obtidas. No Redundncia da Informao Cada dado deve ser armazenado uma nica vez base de dados . Evita-se a inconsistncia dos dados e reduzem-se os recursos para armazenamento da informao. O Modelo Conceptual de Dados a obter na fase de anlise deve identificar todas as entidades e relaes relevantes do sistema a modelar, caracterizadas em termos dos atributos e das cardinalidades respectivas. Independentemente da utilizao de uma Base de dados relacional na fase de implementao, o MCD final deve estar normalizado.

Modelo Conceptual de Dados

12

Sistemas de Informao

Exemplo : Pretende-se desenvolver uma aplicao informtica destinada gesto da Facturao de uma empresa . Uma factura tem o seguinte formato/contedo:

#Factura ________________

Data ________

#Cliente ________ Nome _____________________________ Morada___________________ CodPostal _____ Localidade ___________ #Vendedor _______ Nome-vend ___________________________________ #Prod _____ _____ _____ _____ _____ Des-Prod Quant ___________________ _______ ___________________ _______ ___________________ _______ ___________________ _______ ___________________ _______ Preo-Unit _________ _________ _________ _________ _________ Preo-total _________ _________ _________ _________ _________

Total-factura:. _________

Existindo um nmero indefinido e varivel de produtos por factura o ficheiro de Facturas teria o seguinte contedo. Facturas = {#Factura + Data + #Cliente + Nome + Morada + Codpostal + + Localidade + #vendedor + Nome-vend + #Prod1 + Des-Prod1 + Quant1 + Preo-unit1 + Preo + #Prod2 + Des-Prod2 + Quant2 + Preounit2 + Preo-total2 + . + #Prodn + Des-Prodn + Quantn + + Preo-unit2 + Preo-total2 + Total-factura }
Problemas :

- A partir deste contedo como obter a relao 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 posio diferente).
No existe uma viso relacional dos dados
Modelo Conceptual de Dados 13

Sistemas de Informao

- necessrio prever um nmero mximo de produtos por factura - O que fazer se ocorre uma factura com um nmero superior? - Quanto maior o nmero mximo previsto maior o despedcio (overhead) para facturas com poucos produtos.
Origem dos problemas: Existem grupos repetidos (redundncia). Um ficheiro no est normalizado se tiver grupos repetidos

No exemplo o contedo do ficheiro podia ser especificado com as notaes do dicionrio de dados explicitando o grupo repetido entre chavetas. Facturas = {#Factura + Data + #Cliente + Nome + Morada + Codpostal + + Localidade + #vendedor + Nome-vend + { #Prod + Des-Prod + + Quant + Preo-unit + Preo-total } + Total-factura }

1 Forma Normal Um ficheiro est na 1 forma normal se no 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 + Preo-unit + + Preo-total }

Modelo Conceptual de Dados

14

Sistemas de Informao

(Nota : A chave de Linhas_Factura obtida pela concatenao da chave de Factura (#Factura) com #Produto) Os problemas existentes foram resolvidos: - A partir do ficheiro Linhas_factura muito simples obter a ralao das facturas onde um dado produto foi vendido. Existe uma viso relacional dos dados SQL SELECT * FROM Linhas_Factura WHERE #Produto = X - Para cada factura existem tantos registos (ocorrncias ) de Linhas_facturas quantos os produtos que essa factura tem. Isto , no h overhead. O grande objectivo da 1 Forma normal garantir a Viso Relacional dos Dados Problema ainda existente : REDUNDNCIA Ex: - Se um produto for facturado 1000 vezes necessrio guardar a designao do produto 1000 vezes. - nome de um Cliente (e de um Vendedor) armazenado tantas vezes quantas as facturas onde participou.
Soluo : 2 e 3 Formas normais

Garantir que todos os atributos dependam funcionalmente apenas do identificador principal (Chave)

Modelo Conceptual de Dados

15

Sistemas de Informao

Dependncia funcional (entre atributos) Um atributo a depende funcionalmente do atributo b se para cada valor de b possvel saber , sem ambiguidade, qual o valor do atributo de a.

O grande objectivo da 2e 3 Formas normais evitar a Redundncia dos Dados

2 Forma normal Um ficheiro est na 2 forma normal se, para alm de estar na 1 forma normal, cada atributo no chave depende funcionalmente da totalidade da chave.

A situao de um ficheiro no estar na 2 forma normal verifica-se no caso do identificador chave ser composto ( normalmente resultante da aplicao da 1 forma normal ao retirar os grupos repetidos). Ex. Linhas_factura ( Atributo Identif. = #Factura + #Produto) Linhas_factura = { #Factura + #Prod + Des-Prod + Quant + Preo-unit + + Preo-total } O atributo Des-Prod depende funcionalmente apenas de #Prod. Pressupondo que a designao do produto fixa e a mesma em todas as facturas verifica-se REDUNDNCIA. Soluo : 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 Informao

Nota - O atributo Preo-unit representa o preo unitrio do produto na data da factura. O ficheiro Produtos poder ter tambm um atributo relativo ao Preo unitrio, mas correspondente ao valor de base actual. O que acontece se ele for alterado ? possvel refazer integralmente a factura ? Importante: A possibilidade de reconstruir os dados/informao com efeitos retroactivos um dos objectivos mais importantes ( e difceis) de garantir na concepo de um sistema de Informao 3 Forma normal Um ficheiro est na 3 forma normal se, para alm de estar na 2 forma normal, os atributos no chave no dependem funcionalmente uns dos outros.

No ficheiro Facturas existem dependncias funcionais entre atributos no chave que implicam Redundncia:

Facturas = {#Factura + Data + #Cliente + Nome + Morada + Codpostal + + Localidade + #vendedor + Nome-vend + Total-factura }

A soluo criar novos ficheiros (tabelas) : Clientes = { #Cliente + Nome + Morada + Codpostal + Localidade} Vendedor = { #Vendedor + Nome-vend} No caso do cdigo postal determinar sem ambiguidade a localidade poderia tambm definir-se um novo ficheiro: Codigos_postais = { codpostal + localidade}
Modelo Conceptual de Dados 17

Sistemas de Informao

Em resumo, normalizando o contedo 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 + Preo-unit + Preo-total } Produtos = { #Prod + Des- Prod } Clientes = { #Cliente + Nome + Morada + Codpostal } Vendedor = { #Vendedor + Nome-vend} Codigos_postais = { Codpostal + Localidade}

Nota Os atributos Preo-total, se for igual a Quant*Preo-unit, e Total-factura , se igual ao somatrio de Preo-total, constituem tambm redundncia ( atributos calculados). Os atributos calculados no so em geral armazenados . Aparecem apenas nos outputs, como o caso do documento impresso Factura.

Modelo Conceptual de Dados

18

Sistemas de Informao

Importante:

De notar que o exerccio (sistemtico) de normalizao de um documento constituiu um auxiliar precioso de anlise para identificao das principais Entidades e Relaes da aplicao informtica destinada gesto da Facturao. O Modelo Conceptual de Dados facilmente derivado:
Cliente #Cliente Nome Morada Codpostal Factura #Factura Data #Cliente #Vendedor Vendedor #Vendedor Nome

Codpostal #Codpostal Localidade

Linha-fact #Factura #Produto Quant Preo-unit

Produto #Produto Des-prod

Modelo Conceptual de Dados

19