Sistemas de Informação

Transcrição

1 MODELO CONCEPTUAL DE DADOS Escola Superior de Tecnologia e Gestão de Felgueiras Engenharia Informática 3º ano /2004 Ana Maria Madureira

2 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

3 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º ) 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 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

4 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

5 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 NOTA DATA DISCIPLINA Modelo Conceptual de Dados 5

6 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 DATA QUANT ENCOMENDA 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) 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

7 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 (1,1) FACTURA (1,n) PRODUTO 3.3. Dimensão de uma Relação Número de entidades que participam na Relação PROFESSOR TURMA AULA SALA DISCIPLINA AULA é uma relação de dimensão 4. Modelo Conceptual de Dados 7

8 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 TURMA (1,1) (1,1) AULA SALA (1,1) (1,1) DISCIPLINA 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 (1,1) FACTURA Modelo Conceptual de Dados 8

9 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 PAÍS #País #Cidade CAPITAL 0, 1 1,1 CIDADE #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

10 Relações do tipo 1 : n (um para vários) CLIENTE FACTURA 1,1 0,n #Factura #Cliente 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 #Aluno CURRICULUM m,n m,n DISCIPLINA #Disciplina 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 #Aluno DISCIPLINA #Disciplina 1,1 1,1 0,n CURRICULUM #Aluno #Disciplina Data Nota 0,n Modelo Conceptual de Dados 10

11 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 Precedências #Disciplina #curso Ano Semestre 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

12 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

13 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-total #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

14 - É 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

15 (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

16 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

17 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

18 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

19 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 Factura #Factura Data #Cliente #Vendedor Vendedor #Vendedor Nome Codpostal #Codpostal Localidade Linha-fact #Factura #Produto Quant Preço-unit Produto #Produto Des-prod Modelo Conceptual de Dados 19