Baixe o app para aproveitar ainda mais
Prévia do material em texto
1. Projetos de Bancos de Dados Bancos de Dados são componentes importantes dos sistemas de informação, portanto, o projeto do banco de dados torna-se uma atividade essencial na fase de desenvolvimento dos sistemas. Muitas vezes a falta de uma abordagem adequada para o projeto de um banco de dados pode incorrer em resultados indesejáveis, como queda de performance ao atender a demanda de aplicações e problemas com a manutenção do banco de dados. Geralmente a causa disso está associada a etapa de entendimento do problema e transcrição da representação para o modelo conceitual. De acordo com Korth1 Um modelo de dados pode ser definido como uma Coleção de ferramentas conceituais para descrição de dados, relacionamento entre os dados, semântica e restrições de dados. O Modelo de Dados é basicamente um conjunto de conceitos utilizados para descrever um Banco de Dados. Não existe uma única forma de representação deste modelo, porém qualquer forma que emite a correta compreensão das estruturas de dados compreendidas no Banco de Dados, pode ser considerada adequada. Os modelos são a base do design. Os engenheiros criam um modelo de carro para estudar os detalhes antes de colocá-lo em produção. Da mesma forma, projetistas de sistemas desenvolvem modelos para explorar idéias e compreender melhor o design de um banco de dados. Os modelos ajudam a comunicar conceitos imaginados pelas pessoas. É possível usá-los com os seguintes objetivos: • Comunicar • Categorizar • Descrever • Especificar • Investigar • Desenvolver • Analisar • Imitar O objetivo é produzir um modelo que se adapte a vários usos, possa ser compreendido por um usuário final e contenha detalhes suficientes para que um desenvolvedor crie um sistema de banco de dados. O projeto de um banco de dados pode ser decomposto em três fases básicas as quais denominamos modelo: • Modelo Conceitual; • Modelo Lógico; ———————————————————— 1 KORTH, H.F., SURDASHAN, S., SILBERSCHATZ, A., Sistema de Banco de Dados, Makron, 1999 1 • Modelo Físico Requisito de Dados Modelo Conceitual Esquema Conceitual Modelo Lógico Esquema Lógico Modelo Físico Esquema Físico Figura 1. 1.1. Modelo Conceitual A construção do Modelo Conceitual é iniciada a partir da especificação dos requisitos e resulta no esquema conceitual do banco de dados, onde a semântica da realidade deve estar correta. Um esquema conceitual é uma descrição em alto nível da estrutura do banco de dados, independente do Sistema de Gerenciamento de Banco de Dados (SGBD) adotado para implementá-lo. É utilizado para descrever os esquemas conceituais. É chamado de modelo de alto nível, pois não está ligado (relacionado) a nenhum Banco de Dados. Sua verdadeira intenção é promover o entendimento dos fatos de uma realidade (mundo) para ser representado e tratado em um BD. De acordo com Cougo2 o modelo conceitual pode ser definido como um modelo no qual os objetos, suas características e relacionamentos têm a representação fiel ao ambiente observado, independente de quaisquer limitações impostas por tecnologias, técnicas de implementação ou dispositivos físicos. ———————————————————— 2 COUGO, P., Modelagem Conceitual e Projeto de Bancos de Dados, Campus, 2000 2 Considerando o ciclo de vida de desenvolvimento de um sistema esta etapa pode ser considerada a fase de análise dos dados (ou requisitos) capturados na etapa anterior (levantamento de dados). São analisados os fatos (entidades ou conjunto de ocorrências de dados) de interesse e seus relacionamentos, juntamente com seus atributos (propriedades ou características) e construída uma notação gráfica (abstrata, uma representação de alto nível) para facilitar o entendimento dos dados e suas relações, tanto para os analistas quanto para os futuros usuários. 1.1.1. Objetivos do Modelo Conceitual • Descrição das Informações – O objetivo do modelo conceitual é descrever as informações contidas em uma realidade, as quais estarão armazenadas em um banco de dados. • Resultado real – O resultado de um Modelo Conceitual é um esquema que representa a realidade das informações existentes, assim como as estruturas de dados que representam essas informações. • Independência de Manipulação e Manutenção dos Dados – Não é construído com considerações procedurais, não existindo preocupação com as operações de manipulação/manutenção dos dados. • Independência do SGBD – Não retrata aspectos ligados à abordagem do banco de dados que será utilizado e nem com as formas de acesso ou estruturas físicas implementadas por um SGBD. 1.1.2. Características do Modelo Conceitual • Representação da Realidade – Registra as necessidades de informação de uma realidade. • Melhor Conhecimento do Sistema – Permite que os analistas possam interagir melhor com os usuários validando seus objetivos e metas permitindo a construção de um sistema de informações cada vez mais próximo da realidade do usuário. • Inicia o projeto – É a primeira etapa do projeto de um sistema de aplicação em banco de dados. A fase de projeto conceitual é tida como uma das mais (senão 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 elaboração do esquema conceitual. A meta nessa fase é obter um esquema conceitual do banco de dados que seja tão completo e expressivo quanto possível. Esse esquema deve procurar expressar o máximo da semântica envolvida na informação. Mecanismos de representação de alto nível são empregados, tais como representação de hierarquias de subconjunto e de generalização, representação de restrições de cardinalidade e de atributos compostos e multivalorados. O esquema conceitual deve permanecer como uma parte da documentação do processo de projeto, sendo utilizado durante a operação e manutenção do banco de dados, pois facilita o entendimento dos esquemas de dados e das aplicações que os utilizam. Para auxiliar o projetista a elaborar o projeto conceitual de um banco de dados existem as abstrações de dados, que apresentam as vantagens: • ajudam o projetista a entender, classificar e modelar a realidade, 3 • melhoram a eficiência de implementações subseqüentes, • permitem melhor representar a semântica das novas aplicações de banco de dados, provenientes de áreas não tradicionais. 1.1.3. O Modelo Conceitual propicia Melhor compreensão pelo usuário leigo: Um modelo conceitual é normalmente uma representação gráfica de fatos e relações do mundo real. Assim sendo, a compreensão destes conceitos é facilitada, se exposta graficamente. O usuário leigo, para o qual o BD será desenvolvido, tem melhores condições de criticar o projeto feito e interagir no projeto. Independência de detalhes de implementação: Um modelo conceitual não é vinculado a nenhum modelo de dados de BD, ou seja, não apresenta detalhes de estruturação de dados que só precisam ser considerados no momento da criação do esquema em um SGBD. Assim, modificações nesta etapa do projeto são menos comprometedoras do que nas etapas seguintes. Inclusive, é recomendado que se critique bastante o modelo conceitual, para evitar mudanças depois. Tradução para qualquer modelo de dados de BD: Um modelo conceitual pode ser mapeado para qualquer modelo de BD, desde que se saibam as regras para realizar tal tarefa. Isto facilita o upgrade do BD (por exemplo, migração de um SGBD relacional para um SGBD orientado a objetos), uma vez que não é preciso repensar do zero a nova organização lógica que os dados terão no novo modelo de dados. Ferramenta indispensável para o processo de engenharia reversa de BD: Oupgrade (ou migração) de um esquema implementado em um certo modelo de dados de BD para outro exige a realização de um processo chamado engenharia reversa. O objetivo deste processo é justamente obter o modelo conceitual a partir de um modelo lógico (projeto de BD “ao contrário”), para que possa então ocorrer o upgrade, como comentado na vantagem anterior. Maior estabilidade frente a mudanças a nível de implementação: O modelo conceitual, por ser um modelo de alto nível (semântico), tem menor probabilidade de ser afetado quando ocorrem mudanças a nível de implementação, realizadas no SGBD, como por exemplo, definir índices para aumentar a performance, tornar o BD distribuído, utilizar estratégias de clusterização para agilizar consultas, etc. Às vezes, mesmo modificações, por exemplo, em tabelas de um BD relacional, não inviabilizam o modelo conceitual, uma vez que as regras de mapeamento para um modelo lógico admitem algumas variações, como por exemplo, o fato de um relacionamento 1:1 com parcialidade gerar ou não uma tabela para o relacionamento. Mais adequado para o exercício da criatividade: Um modelo conceitual é na verdade uma ferramenta que admite diversas alternativas de solução para a interpretação de uma realidade, dependendo de quem está modelando. É interessante que uma modelagem conceitual seja realizada por diversos analistas e comparada entre eles, para se determinar qual delas é a mais clara, ou seja, captura melhor a semântica da realidade. 4 1.1.4. Exemplo de Modelagem Conceitual Filme nome data copyright duracao custo id: nome data id’: copyright tem-atuacao 1-N Paticipacao personagem cache s1/1 atua 1-N Ator nome_arstistico nac idade sexo tipo_papel [0-3] id: nome_artistico produzido-por 1-1 producao produz 0-N Estudio nome dono tem-direcao-de 1-1 direcao dirige 0-N Diretor nome nacionalidade premio [1-N] festival ano nome_premio fundacao faturamento id: nome Obs.: Notação ER da ferramenta DB Main Figura 2. Explicação do Exemplo O modelo retrata o estudo de caso de uma produtora de filmes. • Um filme tem a atuação de vários atores; • Um filme é dirigido por um Diretor; • Um estúdio pode produzir vários filmes; Perceba que em nenhum momento este modelo relata tipo de dados ou fica preso a qualquer restrição de sistema. No caso apresentado ele demonstra as relações existentes entre cada objeto importante dentro da produtora de filmes e caracteriza cada um desses objetos com as informações existentes na realidade da situação. 1.2. Modelo Lógico O Modelo Lógico inicia-se a partir do esquema conceitual e resulta no esquema lógico. Um esquema lógico é uma descrição da estrutura do banco de dados que pode ser processada por 5 um SGBD. Nesta etapa, o desenvolvimento do Banco de Dados começa a se voltar para o ambiente de implementação, uma vez que é feita a conversão do modelo conceitual para um modelo de dados de um Banco de Dados. Os modelos lógicos podem ser construídos de acordo com a abordagem: relacional, em redes, hierárquico ou Orientada a Objetos. O projeto lógico depende da abordagem do modelo de dados usado pelo SGBD, mas não do SGBD específico usado. De acordo com Cougo3 o modelo lógico é aquele em que os objetos, suas características e relacionamentos têm a representação de acordo com as regras e limitantes impostos por algum tipo de tecnologia, mas essa representação é independente dos dispositivos ou meios de armazenamento físico e das estrutura de dados por ela definidos. Na abordagem relacional esta etapa se baseia no uso de regras de mapeamento de um modelo ER para o modelo de dados escolhido. O resultado é uma estrutura lógica, como um conjunto de tabelas relacionadas. Considerando o ciclo de vida de desenvolvimento de sistemas está associado à fase de projeto. Os modelos lógicos podem ser baseados em objetos ou baseados em registros. • Modelos lógicos baseados em objetos: Descrição dos dados nos níveis conceitual e de visões de usuários. Exemplos: Entidade-relacionamento, orientado a objetos. • Modelos lógicos baseados em registros: Descrição dos dados nos níveis conceitual e de visões de usuários; o banco de dados é estruturado em registros de formatos fixos, de diversos tipos; cada tipo de registro tem sua coleção de atributos; há linguagens para expressar consultas e atualizações no banco de dados. Exemplos: Relacional, Rede, Hierárquico. No modelo relacional, dados e relacionamentos entre dados são representados por tabelas, cada uma com suas colunas específicas. Funcionário Código do Funcionario Nome do Funcionário Endereço do Funcionário Telefone do Funcionário Salário do Funcionário Cargo do Funcionário Data de Admissão do Funcionário Data de Nascimento do Funcionário Observações do Funcionário Dependente Código do Dependente Nome do Dependente Data de Nascimento do Dependente Grau de Parentesco do Dependente Código do Funcionário (FK) Figura 3. ———————————————————— 3 COUGO, P., Modelagem Conceitual e Projeto de Bancos de Dados, Campus, 2000 6 1.3. Modelo Físico Esta última etapa é realizada a adequação do modelo lógico ao formato de representação de dados do SGBD escolhido para a implementação. O Modelo Físico inicia-se a partir do esquema lógico e resulta no esquema físico. Um esquema físico é uma descrição da implementação do banco de dados; ele descreve as estruturas de armazenamento e métodos de acesso usado para efetivamente realizar o acesso aos dados. O projeto físico é direcionado para um SGBD específico. Decisões tomadas durante o projeto físico, para melhorar o desempenho, podem afetar a estrutura do esquema lógico. O esquema físico do banco de dados é influenciado pelas fases por que passou a construção do banco de dados. De acordo com Cougo4 o modelo físico de dados é aquele em que a representação dos objetos é feita sob o foco do nível físico de implementação das ocorrência, ou instâncias das entidades e seus relacionamentos. Considerando o ciclo de vida de desenvolvimento de um sistema esta etapa está associada a etapa de implementação (codificação ou desenvolvimento). Para a realização desta etapa, deve-se conhecer a linguagem para descrição e controle 5 do Sistema Gerenciador de banco de dados para realizar a descrição do modelo lógico. O resultado é a especificação do esquema da aplicação, juntamente com a implementação de restrições de integridade e visões. Funcionário cd_funcionario:NUMBER(10) nm_funcionario:VARCHAR2(40) nm_endereco_funcionario:VARCHAR2(40) nr_telefone_funcionario:VARCHAR2(20) vl_salario_funcionario:NUMBER(13,2) nm_cargo_funcionario:VARCHAR2(40) dt_admissao_funcionario:DATE dt_nascimento_funcionario:DATE ds_funcionario:VARCHAR2(4000) Dependente cd_dependente:NUMBER(3) nm_dependente:VARCHAR2(40) dt_nascimento_dependente:DATE nm_parentesco_dependente:VARCHAR2(20) cd_funcionario: NUMBER(10) Figura 4. Nesta etapa também é necessário conhecimento sobre a Linguagem de Manipulação de Dados (DML), pois é por meio dela que será possível o acesso e manipulação dos dados organizados pelo modelo de dados apropriado e sobre gerenciamento de transações. Uma transação é uma coleção de operações que realizam uma única ação lógica na aplicação do banco de dados. A gerência de transações assegura que o banco de dados permaneça em um estado consistente (correto) a despeito de falhas no sistema (ex.: quedas de energia, e crashes do sistema operacional) e falhas de transações. ———————————————————— 4 COUGO, P., Modelagem Conceitual e Projeto de Bancos de Dados, Campus, 2000 5A linguagem de Definição de dados (DDL) é uma notação de especificação para definição do esquema do banco de dados. O compilador da DDL gera um conjunto de tabelas armazenadas em um dicionário de dados. A estrutura de armazenamento e métodos de acesso usados pelo sistema de banco de dados são especificados. 7 A gerência de controle de concorrência controla as interações através de transações concorrentes, para assegurar a consistência do banco de dados. 1.3.1. O que acontece na Conversão do Modelo Lógico para o Modelo Físico? A especificação de campos, ou seja, o modelo lógico está mais perto do usuário e o modelo físico vai ficar bem mais próximo da máquina. Os campos são a base do banco de dados. Eles representam características dos assuntos que são importantes para a organização. Eles armazenam os dados que são recuperados e depois apresentados como informações – informações que são vitais para as operações diárias, para o sucesso e para o futuro crescimento da organização. Eles são os bem mais ignorados, subutilizados e freqüentemente negligenciados da organização! Freqüentemente, pouco ou nenhum tempo é gasto para se garantir a integridade estrutural e lógica /dos campos do banco de dados. A especificação de campos é muito importante por inúmeras razões, dentre elas podemos citar: • A integridade em nível de campo é estabelecida e imposta como resultado da definição de Especificação de Campo • A definição de especificação de campo para cada campo melhora a integridade dos dados. • A definição de Especificações de Campo o impulsiona a adquirir um entendimento completo da natureza e propósito dos dados do banco de dados. Elementos de Campo Ideal ° Ele representa uma característica do assunto da tabela; ° Ele contém apenas um valor; ° Ele não pode ser dividido em componentes menores; ° Ele não contém um valor calculado ou concatenado; ° Ele é único dentro da estrutura inteira do banco de dados; ° Ele mantém todas as suas características, caso apareça em mais de uma tabela. As especificações de campo compreendem vários elementos que são usados para definir cada atributo de um campo. Esses elementos são divididos em três categorias: Elementos Gerais, Elementos Físicos e Elementos Lógicos. Há uma quarta categoria separada: Informações de Especificação. Agrupar os elementos dessa maneira torna-os mais fáceis de encontrar. Isso também permite que você focalize um aspecto específico do campo para o qual você está definindo a Especificação de Campo. Os itens encontrados dentro de cada categoria são: • Elementos Gerais: Nome de campo, tabela de origem, rótulo, compartilhado por, alias (um ou mais), descrição. • Elementos Físicos: Tipo de Dados, suporte de caracteres, comprimento, casas decimais, máscara de entrada, formato de exibição. 8 • Elementos Lógicos: Tipo de Chave, exclusividade, valor obrigatório, suporte a nulo, regra de edição, comparações permitidas, operações permitidas, valores introduzidos por valor padrão, intervalo de valores. • Informações de Especificação: Tipo de especificação, baseadas em especificação existente, especificação de origem. 2. Modelos de Banco de Dados 2.1. Modelo Hierárquico de Banco de Dados O modelo de banco de dados hierárquico funcionou muito bem com os sistemas de armazenamento em fita, usado pelos computadores nos anos 70 e foi muito popular nas companhias que usavam este sistema. Apesar de o modelo hierárquico oferecer acesso rápido e direto aos dados e ter sido um modelo de grande utilidade em numerosas circunstâncias, era clara a necessidade de ser ter um novo modelo que resolvesse os problemas de dados redundantes e relacionamentos complexos de dados. A própria IBM6 nos informa que a linguagem de dados da IBM DL/I-(Data Languagem/I) constitui um relevante exemplo de gerenciamento de banco de dados, cujo método utilizado é o modelo hierárquico. Onde esta linguagem faz parte em banco de dados de seu sistema de gerenciamento de informações (IMS - Information Management System) e sistema de controle de informações sobre o cliente (CICS - Custemar Information Control System). Descreve uma Hierarquia como um conjunto de registros interligados, isto é, em cada um há um tipo de registro “PAI”, exceto a Raiz. Numa Hierarquia, o acesso aos dados é utilizado através de segmento “Raiz”, quando um campo é escolhido como campo-chave e os outros são baseados em índice ou acesso aleatório. Nome Sobrenome Rua Conta Saldo cliente conta Campo-chave conta Campo-chave cliente Figura 5. Diagrama de estrutura de árvore com campo-chave. No modelo hierárquico o os dados são armazenados em registros organizados hierarquicamente como árvores. Os registros são conjuntos de campos conectados uns aos outros por meio de um “link”, onde cada “link” deve relacionar apenas dois registros. ———————————————————— 6 IBM Training Center, Fundamentos de Bancos de Dados, 1989. 9 Inês Coel Vergueiro Ana Knor Laguna Vera Henfil Correio 0933 4000 1024 3280 0020 6000 1963 4000 Figura 6. Exemplo de Modelo Hierárquico. Na Figura 5. – Exemplo de Banco de Dados Hierárquico: há dois tipos de registros, Cliente e Conta. O registro Cliente é composto por três campos: Nome, Sobrenome e Rua. O registro Conta é composto por dois campos: Número da Conta e Saldo. Podemos ver que o cliente Inês tem a conta 0933, o cliente Ana tem as contas 1024 e 0020 e o cliente Vera tem a conta 1963. O conjunto de todos os registros de clientes e de contas é organizado na forma de uma raiz, em que a raiz da árvore é um nó vazio (dummy). Como podemos ver, um banco de dados hierárquico é uma coleção do tipo de árvores com raiz e, por isso, forma uma floresta. Podemos nos referir a cada uma dessas árvores com raiz como sendo uma árvore de banco de dados 7. O modelo hierárquico acessa os dados rapidamente por trabalhar com ponteiros, mas sua estrutura em árvore pode levar a redundância de dados e isso, eventualmente, pode resultar em dados inconsistentes quando ocorrer uma atualização, sem contar com o desperdício – inevitável – de espaço. O acesso aos dados só pode ser feito através de programas desenvolvidos por especialistas. DICA: Para saber mais sobre bancos de dados hierárquicos consulte http://www.cs.yale.edu/homes/avi/db-book/b.pdf 2.2. Modelo Banco de Dados em Rede A primeira especificação-padrão de banco de dados, chamada de relatório CODSYL 8 DBTG 1971, foi escrita no final da década de 1960 pelo Database Task Group. Vários sistemas de gerenciamento de banco de dados se baseiam nesse modelo de rede que ficou conhecido apenas como modelo “CODASYL”. Uma rede é, essencialmente, um conjunto ilimitado de nós (tipos de registros neste caso) e de ramais de ligação, ou bordas. Na verdade, uma hierarquia (visto no tópico anterior) é apenas um tipo particular de rede. Uma rede não apresenta o conceito de nó “raiz” e os registros podem ter diversos tipos de registros-pais, assim como diversos tipos de registros-filhos. ———————————————————— 7 Silberschatz, Abraham; Korth, Hary F. e Sudashan, S., Sistema de Banco de Dados, Editora Makron Books, 1999 8 CODASYL: Conferência Sobre Linguagem de Sistemas de Dados (Conference on Data Sistems Languages). 10 Abaixo temos um modelo de um banco de dados em rede mostrando detalhadamente. Inês Coel Vergueiro 0933 4000,00 1024 3280,00 Ana Knor Laguna 0020 6000,00 Vera Henfil Correio 1963 4000,00 Figura 7. Exemplo de Modelo de Rede. Na Figura 7. – Exemplo de modelo de rede podemos ver que o cliente Inês possui a conta 0933, o cliente Ana possui as contas 1024 e 0020 e o cliente Verapossui a conta 1963. Funcionalmente os modelos de rede e hieráquico possuem muitas semelhanças. Tal como no modelo hierárquico os registros são interligados por ponteiros e as linhas entre os registros (também conhecidos como ramais) representam relacionamentos um-para-muitos. Outras semelhanças com o modelo hierárquico persistem, por exemplo, ambos precisam usar de artifícios para implementar uma relação muitos-para-muitos; no modelo de rede foi criado um registro especial chamado de “ligação” para implementar esse relacionamento. No modelo hierárquico esse registro especial é chamado de “registro virtual”. É importante lembrar que ambos os sistemas-hierárquicos e de rede são chamados de “sistemas de navegação” já que, nos dois casos, os programadores precisam atravessar um conjunto de registros pré-articulados (pré-interligados). Sabe-se que esta pré-articulação representa um benefício em termos de desempenho, embora seja restrita em termos da complexibilidade do processo do projeto e das modificações posteriores ao projeto. O modelo Banco de Dados em rede foi criado na tentativa de resolver alguns problemas do modelo hierárquico. O modelo em rede também pode ser representado como uma árvore invertida. Entretanto, podem existir inúmeras árvores invertidas compartilhando galhos, que são parte de uma mesma estrutura de bando de dados. Os relacionamentos num modelo em rede são estabelecidos e representados por uma estrutura de conjunto. Uma estrutura de conjunto é uma construção transparente que relaciona duas tabelas ao mesmo tempo, usando uma tabela como proprietária e outra como membro. Estruturas de conjunto suportam relacionamentos um-para-muitos, o que significa que numa estrutura de conjunto, um registro numa tabela proprietária pode ser associado a vários registros na tabela-membro, mas um único registro da tabela-membro está relacionado a um só registro na tabela-proprietária. Um registro da tabela-membro também não pode existir sem que ele esteja relacionado com um registro existente na tabela-proprietária. Por exemplo, uma conta-corrente deve ser associada a um cliente, apesar de poder existir um cliente sem conta-corrente 9. ———————————————————— 9 Silberschatz, Abraham; Korth, Hary F. e Sudashan, S., Sistema de Banco de Dados, Editora Makron Books, 1999 11 Cliente Deposita Tabela - Proprietária Estrutura de Conjunto Conta/Corrente Tabela - Membro Figura 8. Exemplo de Estrutura de Conjunto. Na figura 8. – Exemplo de Estrutura de Conjunto um cliente pode depositar em uma ou mais de suas contas correntes. No modelo em rede os dados podem ser acessados rapidamente, o que é uma das vantagens deste modelo. O usuário pode elaborar consultas mais complexas no modelo em rede do que no modelo hierárquico. Como no modelo hierárquico o usuário deve estar familiarizado com a estrutura do banco de dados para poder trabalhar através das estruturas de conjunto. Na figura 8, por exemplo, é obrigatório que o usuário esteja familiarizado com as estruturas de conjunto para que ele possa descobrir se uma apresentação específica foi paga. Também, não é fácil mudar a estrutura do banco de dados sem afetar as aplicações do programa que interagem com ele. Os relacionamentos são definidos como estruturas de conjunto, uma estrutura de conjunto não pode ser mudada sem afetar as aplicações do programa, pois são usadas pela aplicação para navegar pelos dados. Se uma estrutura de conjunto é mudada, todas as referências usadas nas aplicações daquela estrutura deverão ser alteradas. DICA: Para saber mais sobre bancos de dados em rede consulte: http://www.cs.yale.edu/homes/avi/db-book/a.pdf 2.3. Modelo Relacional10 Nos anos 60, Dr. E.F. Codd, um pesquisador cientista da IBM, estava procurando novas maneiras de lidar com grandes volumes de dados. Insatisfeito com os modelos e produtos de banco de dados daquele tempo, ele teve a idéia de que aplicando disciplinas e estruturas matemáticas na administração de dados, ajudaria a resolver muitos dos problemas encontrados nos outros modelos de banco de dados, tais como: redundância de dados, grande dependência física na implementação e falha na integridade de dados. Em 1970 o Dr. Codd apresentou o seu trabalho, agora patenteado, “Um Modelo Relacional de Dados para Grandes Bancos de Dados Compartilhados”. Neste trabalho ele primeiramente apresenta o modelo relacional de banco de dados. Este modelo se baseou em duas vertentes da matemática – teoria dos conjuntos e lógica de predicado de primeira ordem. Na verdade o modelo relacional deriva seu nome do termo “relação”, que é uma parte da teoria dos conjuntos. ———————————————————— 10 O modelo de banco de dados relacional será estudado em detalhes ao longo dos capítulos seguintes. 12 Em um modelo relacional, os dados são armazenados em relações, que são percebidas pelo usuário como sendo tabelas. Cada relação é composta de tuplas ou registros e atributos ou campos. A ordem física em que os registros encontram-se numa tabela é totalmente arbitrária. Cada registro de uma tabela é identificado por um campo que contém valores únicos. Essas duas características do modelo relacional permitem que os dados existam, independente da forma como eles foram fisicamente armazenados. Então, o usuário não precisa saber o local físico de um registro para poder trabalhar com ele. Por este lado, o modelo relacional é diferente do modelo hierárquico e do de rede, pois nestes modelos era imprescindível que o usuário conhecesse o desenho da estrutura para que pudesse usar os seus dados. Cliente Conta Empréstimo Figura 9. Exemplo de modelo relacional. Na figura 9. – Exemplo de modelo relacional, um cliente pode ter uma ou mais contas correntes. Empréstimos podem ser depositados em sua conta corrente. Esse mesmo cliente pode fazer pagamento do empréstimo através de depósito em conta corrente. Uma das principais características do modelo relacional é a possibilidade de relacionar várias tabelas para evitar a redundância no armazenamento de dados. Os relacionamentos no modelo relacional podem ser um-para-um, um-para-muitos e muitos-para-muitos. Duas tabelas (A e B) estarão conectadas quando uma delas (A, por exemplo) tiver um campo de compartilhamento que poderá ser plenamente usado em outra (B) para diminuir redundância de dados nas inserções de registros e facilitar futuras buscas e/ou pesquisas. Logo várias tabelas podem estar compartilhando um mesmo campo de uma determinada tabela. A partir do momento em que o usuário esteja familiarizado com os relacionamentos entre as tabelas do banco de dados, ele pode acessar os dados de inúmeras formas diferentes. Ele pode acessar os dados de tabelas que estejam diretamente conectadas, como de tabelas que estejam indiretamente conectadas. No exemplo a seguir, apesar da tabela Cliente estar indiretamente conectada a tabela de Empréstimo, o usuário pode gerar uma listagem de empréstimos por cliente ou por conta. O usuário pode facilmente fazer isso, porque a tabela de Empréstimos está diretamente conectada à tabela de Conta. 13 Cliente Identificação do Cliente Prenome do Cliente Sobrenome do Cliente Data da Contratação 100 Inês Coel 21/10/02 101 Ana Knor 12/01/01 102 Vera Henfil 15/02/99 Conta Identificação da Conta Identificação do Cliente Saldo Código Empréstimo 0933 100 4000,00 A15 1024 101 3280,00 0020 101 6000,00 1963 102 4000,00 B26 Tabela 1. 2.3.1. Vantagens do Modelo Relacional • Construção de Níveis Múltiplos de Integridade: A integridade dos dados neste modelo é construída em nível decampo para assegurar a acuracidade dos dados; em nível de tabela para assegurar que os registros não estão duplicados e para detectar se estão faltando valores na chave-primária; em nível de relacionamentos para assegurar que o relacionamento entre duas tabelas é válido, e em nível do negócio, propriamente dito, para assegurar que os dados estão acurados de acordo com o negócio. • Independência Física e Lógica da Aplicação do Banco de Dados: Nem as mudanças efetuadas pelo usuário no projeto lógico do banco de dados, tampouco as mudanças físicas de implementação do banco de dados feitas pelos fabricantes de software irão prejudicar as aplicações nele construídas. • Garantia da Consistência e Acuracidade dos Dados: Os dados são acurados e consistentes graças aos vários níveis de integridade que você pode impor ao banco de dados. • Fácil Armazenamento de Dados: Ao comando do usuário, os dados podem ser armazenados numa tabela ou em várias tabelas do banco de dados. 14 2.4. Modelo Orientado a Objetos11 A técnica de modelagem orientada a objetos normalmente é empregada nos casos onde os dados envolvidos na aplicação apresentam uma estrutura complexa. A principal diferença entre os modelos de dados relacional, hierárquico e em redes e os modelos de dados orientados a objetos está na maneira como os dados são tratados. A meta dos bancos de dados orientados a objetos é manter a correspondência direta entre os objetos do mundo real e os do banco de dados, isso implica que podemos identificar e manipular os objetos como um todo. Representar um objeto complexo no modelo relacional significa que o objeto tem que ser subdividido em um grande número de linhas ou tuplas, o que leva à necessidade de realizar um considerável número de operações de junção para recuperar o objeto. Nos modelos de dados tradicionais os dados são vistos como uma coleção de tipos de registros ou de relações, cada qual tendo uma coleção de registros, linhas ou tuplas armazenadas em um banco de dados. Em um modelo de dados orientado a objetos um banco de dados é considerado como uma coleção de objetos do mundo real. Os bancos de dados orientados a objetos foram propostos para dar suporte às necessidades de aplicações mais complexas, como aquelas que exigem transações mais longas, textos longos e armazenamento de imagens. Muitos dos conceitos das Linguagens de Programação Orientadas a Objetos (LPOO) são utilizados nos Banco de Dados Orientados a Objetos (BDOO) apesar de estes necessitarem de conceitos próprios. Por exemplo, os objetos nas LPOO são transitórios, isto é, só existem durante a execução do programa enquanto que nos BDOO os objetos são persistentes, isto é, a existência de um objeto pode ser estendida de modo que sejam armazenados permanentemente. Vejamos mais alguns dos principais conceitos envolvidos com BDOO: • Métodos: Os objetos nos SGBDOOs são manipulados através de métodos. Em geral, a definição de um método consiste de assinatura e corpo. A assinatura especifica o nome do método, os nomes e classes dos argumentos e a classe do resultado, se existir. O corpo representa a implementação do método e consiste de um conjunto de instruções expressas em uma dada linguagem de programação. • Tipos e Classes: Um tipo modela as características comuns de um conjunto de objetos e corresponde à noção de tipos abstratos de dados. Uma classe é um conjunto de objetos que tem exatamente a mesma estrutura interna, i.é, os mesmos atributos e mesmos métodos. Os modelos de dados orientados a objetos usam o conceito de classe como uma base para instanciação. • Herança: É um mecanismo de reusabilidade muito poderoso. Com herança, uma classe chamada uma subclasse pode ser definida com base na definição de outra classe chamada a superclasse. A subclasse herda os atributos, métodos e mensagens de sua superclasse e pode ter atributos específicos, métodos e mensagens adicionais. • Polimorfismo: Os SGBDOOs oferecem o recurso de polimorfismo de operações, também conhecido como sobrecarga de operador (overloading). Outros conceitos relacionados com o polimorfismo são os de late binding (ligação tardia) e overriding (redefinição de operação). ———————————————————— 11 Modelagem de sistemas complexos será visto com mais detalhes em capítulo específico ao tema 15 • Valores: A maioria dos SGBDOOs representam as entidades primitivas, tais como inteiros ou caracteres, por valores (não possuem OIDs), enquanto as entidades não primitivas são representadas como objetos. • Estrutura do objeto: O valor de cada atributo de um objeto pode ser: ° atômico: integer, real, character, booleano, etc. ° complexo: definido através de construtores: array, table, UDT12. • Encapsulamento: A cada objeto está associado sua estrutura e seu comportamento (os métodos ou operações). O comportamento é armazenado no banco de dados junto com a estrutura do objeto. • Objetos e Identidade: Cada entidade do mundo real é modelada como um objeto. A cada objeto é associado um estado e um comportamento: o estado é representado pelos valores dos atributos do objeto; o comportamento é definido pelos métodos que agem sobre o estado do objeto pela invocação de operações. A cada objeto armazenado no banco de dados é associado um identificador único ( OID: Object Identifier), que é gerado pelo SGBDOO (sistema de gerenciamento de banco de dados orientado a objetos) • OIDs x Chaves Primárias Nos modelos orientados a objetos não existe o conceito de chave primária como acontece no modelo relacional. Ao invés disso, existem os OIDs dos objetos que, como já dito, são criados e mantidos pelo sistema de gerenciamento de banco de dados e não são de acesso do usuário. As vantagens do uso de OIDs com relação às chaves são: • os programadores de aplicações não precisam se preocupar com a seleção de chaves para as várias classes de objetos; • obtém-se melhor desempenho, pois os OIDs são implementados em baixo nível pelo sistema; • embora as chaves sejam mais significativas ao usuário, muitas vezes o usuário precisa usar códigos artificiais, sem significado semântico, para poder identificar as tuplas de uma relação. ———————————————————— 12 UDT - User Defined Type. Tipo de dado definido pelo usuário. Caso necessário é possível criar tipos de dados diferentes do tipos de dados padrão do BD. Ex: litro, pneu, galão, perímetro. 16 3. Modelo Entidade Relacionamento (MER) 3.1. Conceitos Básicos Neste capítulo serão apresentados de maneira simplificada os conceitos básicos que serão utilizados e detalhados ao longo do curso. 3.2. Dados e Informações Os dados existem fisicamente e precisam de um contexto para adquirir algum significado. São estáticos, isto é, permanecem no mesmo estado até que sejam modificados por um processo manual ou automático. Mellanzone 55 03909-70 22,00 Mesozóica Isoladamente estes dados não têm nenhum sentido. O que é Mellanzone? Será o nome de uma pessoa, de um supermercado ou de uma pizza? E 55? É um código? Uma soma? Uma nota? Os dados tornam-se informações quando são associados a um contexto e transmitem significados lógicos às pessoas. Nome da Pizza Ingredientes Código Pizza Preço da Pizza Apelido da Pizza Mellanzone 55 03909-70 22,00 Mesozóica Tabela 2. 3.2.1. Qual é a diferença entre Dado e Informação? Se lhe dissermos que a temperatura ambiente está em 28ºC ou que estamos viajando a 140km/hora, você estará recebendo dados ou informações? Mas se agora lhe dissermos que a temperatura ambiente é de 82ºF ou que estamos viajando a 87 milhas/hora? Qual é a sua resposta? Os dados 28ºC e 140 km/hora são rapidamente convertidos em sensaçõestérmicas e de velocidade (informação) – porque você compreende essas unidades de medida. Mas se você não teve uma formação anglo-saxônica, 82ºF ou 87 milhas/hora não lhe fornecem a exata sensação de frio ou calor, ou de velocidade baixa ou alta. Vejamos mais um exemplo. Encontramos uma pessoa de 5 pés e 10 polegadas de altura que colocou 16 galões de combustível no seu carro, pois iria viajar para uma cidade a 100 milhas de distância, com 100 francos no bolso. Temos certeza de que você não conseguiu transformar todos os dados embutidos na frase em informações. Mas se lhe disséssemos que encontramos uma pessoa de 1,78m de altura que colocou 61 litros de combustível no seu carro, pois iria viajar 17 para uma cidade a 161 km de distância com R$ 100,00 no bolso, você certamente compreenderia melhor. A informação existe quando o cérebro humano recebe um conjunto de dados e os utiliza como entrada para algum tipo de processamento neural. Se não houver esse processamento neural, o dado não se transforma em informação; continua sendo dado. A informação é a compreensão do dado, matéria-prima para atividade cerebral. Se alguém conversa em russo, grego ou chinês conosco, recebemos dados, mas se não conhecermos o idioma (protocolo de comunicação) não podemos traduzir os dados em informações. Ficamos parados – sem ação. Sem dados e um mecanismo (processo) de compreensão desses dados, não existe o exercício cerebral. Informação versus Dado Informação Dado Idade: 35 anos Data do Nascimento: 16/07/61 Quente Medição x Métrica de Temperatura = 38º C Longe Medição x Métrica de Distância = 10.000 Tabela 3. O Dado é tão importante ao ser humano que permanecemos 24 horas por dia com nossos sensores ligados ou de prontidão! Para nossos propósitos de modelagem, estaremos estudando as informações que queremos ou precisamos para transformá-las em dados. Nosso objetivo é obtenção de um modelo de dados onde não exista informação. Declaração estranha para um observador casual, mas um modelo de dados, conforme o próprio nome sugere, deve conter dados, e não informações. Suponha que venhamos a armazenar a informação idade de uma pessoa em vez do dado data de nascimento. Daqui a alguns anos, as pessoas cujas informações (e não dados) estão armazenadas conosco continuarão a apresentar a mesma idade de hoje, pois, é evidente, armazenado 35 anos de idade hoje, tal informação será a mesma com o passar do tempo! Mas armazenando-se a data de nascimento, digamos, 21/12/1960, podemos saber com precisão e em qualquer ponto da régua do tempo a informação da idade da pessoa. A conclusão é que armazenando informação perdemos informações. Na vida real, verifica-se freqüentemente o armazenamento de informações, e não de dados, por motivos de limitações técnicas do processamento de dado em larga escala. Caso típico é o dos correntistas de bancos que fazem ao longo de suas vidas, como clientes, uma infinidade de transações de crédito e débito em suas contas correntes, sendo estes os dados básicos resultantes que devem ser armazenados. Todavia, se quisermos obter o saldo atual das contas, teríamos de promover as somas e subtrações de todos os movimentos, o que seria impraticável do ponto de vista de carga de processamento e tempo de resposta. Portanto, a solução técnica mais viável é armazenar os saldos dos correntistas (saldo é uma informação) em uma dada posição de tempo, não muito distante da atual fazendo-se os cálculos aritméticos com os dados mais recentes para se obter a última posição de saldo. Essa situação é aceitável, uma vez que não há outra forma mais eficaz de contornar o problema, restando-nos apenas a preocupação de manter a informação armazenada consistente com os movimentos realizados, se ocorrer um lançamento retroativo à data do saldo, este último deverá ser ajustado automaticamente. Tais 18 limitações técnicas têm conduzido à criação de bases de informações, como é o caso das bases de dados executivas. Vemos a utilização de bases de informações apenas como um artifício técnico que não deve representar a base de dados principal de uma organização. 3.3. Entidade Uma entidade13 ou classe de entidade é uma representação abstrata de “coisas semelhantes”, concretas ou abstratas, que existem no mundo real, sobre a qual um sistema de informação captura, armazena e processa dados para cumprir seus objetivos na empresa, atendendo, assim, às necessidades de seus usuários. Para Korth14 uma entidade é uma “coisa” ou objeto no mundo real que pode ser identificada de forma unívoca em relação a todos os outros objetos. Por exemplo, um aluno é uma entidade que tem um conjunto de propriedades (dados), dentre elas o número do registro acadêmico, que deve ser um valor único capaz de identificar cada ocorrência desta entidade. Cada ocorrência15 de uma entidade é um conjunto de propriedades (atributos)16 que identificam, qualificam ou quantificam esta entidade, por exemplo a entidade aluno tem como atributos nome, registro acadêmico, data de nascimento, entre outros. Estas ocorrências devem satisfazer duas regras básicas: • Todas as “coisas do mundo real” que compõem o conjunto - suas ocorrências - devem ter as mesmas características; • Todas as ocorrências devem estar sujeitas e em conformidade com as mesmas normas. 3.4. Atributos Cada entidade tem propriedades particulares, chamadas atributos, estas propriedades podem identificar, qualificar ou quantificar a entidade. Em outras palavras os atributos descrevem as entidades. Por exemplo, uma entidade empregado pode ser descrita pelo seu nome, o trabalho que realiza, data de nascimento, endereço e salário. Cada ocorrência de uma entidade terá um valor para cada um de seus atributos. Os valores de atributos que descrevem cada entidade ocupam a maior parte dos dados armazenados na base de dados. A figura 10. ilustra duas entidades com seus atributos. ———————————————————— 13 As entidades são representadas por tabelas na etapa de implementação do Banco. 14 Silberschatz, A; Korth, H. R. e Sudarshan, S. Sistemas de Bancos de dados. São Paulo: Makroon Books, 1999 15 Uma ocorrência é o mesmo que um registro. 16 Um atributo é representado em uma tabela por um campo. O campo é a menor estrutura de armazenamento de dados em um banco de dados relacional 19 Nome = João da Silva Endereço = Rua Goiás 711, e1 São Paulo, SP - 1301100 c1 Idade = 55 Telefone residencial = 713-749 Nome = Cooper Sugar Sede = Ribeirão Preto Presidente = João da Silva Figura 10. Exemplo de duas entidades (e1 e c1) com seus atributos. A entidade EMPREGADO e1 tem quatro atributos: Nome, Endereço, Idade e Telefone residencial. Os seus valores (dados) são: “João da Silva”, Rua Goiás 711, São Paulo, SP, 1301100”, “55” e “713-749”, respectivamente. A entidade companhia c1 tem três atributos: Nome, Sede e Presidente. Seus valores (dados) são: “Cooper Sugar”, “Ribeirão Preto”, “João da Silva”. Atenção: • Os atributos de uma entidade permanecem constantes para todos os seus relacionamentos. • Os atributos de uma entidade são independentes de todas as demais entidades 3.5. Chaves • Chave Primária: É um campo ou um conjunto de campos que identifica unicamente cada registro da tabela, sendo assim, um registro não pode conter, neste campo, um dado que já esteja armazenado em outro registro. Exemplo: No contexto de um sistema de controle acadêmico o número de matricula de uma entidade aluno é um atributo identificador já que identifica de forma única um aluno dentro de uma faculdade. • Chave Estrangeira: É um campo ou conjunto de campos usado para estabelecer um relacionamento entre duas tabelas. Na tabela de origem deve ser chave primária. • ChaveSecundária (Terciária, etc): São chaves que possibilitarão pesquisas ou ordenações alternativas, ou seja, diferentes da ordem criada a partir da chave primária ou da ordenação natural (física) da tabela. • Chave Composta: É a chave que contém mais de um atributo (Por exemplo, um cadastro ordenado alfabeticamente por Estado, Cidade e Nome do Cliente, necessitaria de uma chave composta que contivesse esses três atributos). • Chave candidata: São atributos que podem vir a ser chave primária. Exemplo: A entidade FUNCIONARIO tem os atributos: registro funcional, nome, cpf, rg, endereco, dt_nascimento. Os atributos registro funcional, cpf e rg são chaves candidatas, pois podem identificar cada ocorrência de FUNCIONARIO. Mas para que uma chave candidata possa ser eleita a chave primária deverá atender a restrição de unicidade, isto é o conteúdo do campo deverá ser único para cada ocorrência da entidade. 20 d1 d2 d3 3.6. Relacionamentos Um relacionamento estabelece a conexão entre duas tabelas dentro de um banco de dados por meio das chaves primária e estrangeira ou por meio de tabelas de vínculo. No exemplo da figura 11. podemos ver que um aluno pode se matricular em mais de uma disciplina. Ao dizermos que um aluno está matriculado em muitas disciplinas estamos determinando a cardinalidade de nosso relacionamento. Como veremos mais à frente, neste caso a cardinalidade e’ de 1:N. a1 a2 a3 Aluno Matrícula Disciplina Figura 11. Exemplo de Relacionamento. 21 4. Metodologias para Modelagem de Bancos de Dados Relacionais Segundo o dicionário Michaelis a Metodologia é o estudo científico dos métodos, que por sua vez é o conjunto dos meios dispostos convenientemente para alcançar um fim e especialmente para chegar a um conhecimento científico ou comunicá-lo aos outros. Uma metodologia para modelagem de bancos de dados relacionais é um conjunto de regras que são empregadas para demonstrar como será constituído o banco de dados, isto é, como as tabelas serão relacionadas. É uma ferramenta de comunicação de alto nível. Neste capítulo serão apresentadas algumas metodologias e definições propostas por diferentes autores e que são utilizadas para modelagem de bancos de dados relacionais. 4.1. Metodologia de Peter Chen17 Na década de 70, Peter Chen propôs uma técnica de diagramação que, associada a um conjunto de conceitos, tornou-se o que conhecemos como a abordagem entidade-relacionamento (E-R) para o processo de modelagem de dados. Em sua essência, o modelo E-R representa coisas do mundo real (Entidades), que possuem características próprias (Atributos) e que se relacionam entre si (Relacionamentos). Representação de uma Entidade Identificador da entidade Exemplo: Funcionário trabalha em Departamento. Neste exemplo temos duas entidades: Funcionário e Departamento. Representação dessas duas entidades fica da seguinte forma: Departamento Funcionário Representação dos Atributos Identificador do aTributo ———————————————————— 17 Chen p., Modelo Entidade-Relacionamento. São Paulo: Makroon Books, 1999 22 Departamento Atenção: Muitas vezes, com o objetivo de manter o modelo simples e claro, os atributos só são representados no dicionário de dados. Exemplos de atributos da Entidade DEPARTAMENTO: • Código (do Departamento) • Nome (do Departamento) • Localização (do Departamento) DEPARTAMENTO CÓDIGO NOME LOCALIZAÇÃO Figura 12. Exemplo da entidade departamento. Podemos usar uma representação alternativa para os atributos. No exemplo abaixo usaremos traços ao invés de elipses: Funcionário Trabalha em NOME TELEFONE ENDEREÇO CÓDIGO NOME Figura 13. Representação alternativa para atributos. Representação dos relacionamentos: Na notação original de Chen, são representados por losangos. Identificação Figura 14. 23 Exemplo: Funcionário trabalha em DEPARTAMENTO FUNCIONÁRIO trabalha DEPARTAMENTO Figura 15. Relacionamento na notação de Chen Representação da cardinalidade: O grau da cardinalidade é expresso acima da linha do relacionamento e pode ser representado por 0, 1 ou N FUNCIONÁRIO N 1 trabalha DEPARTAMENTO Figura 16. Pode-se também expressar o grau mínimo e máximo de relacionamento entre as entidades: FUNCIONÁRIO 0 : N 1 : 1 trabalha DEPARTAMENTO Figura 17. Na notação expandida de Chen a cardinalidade é representada da seguinte forma: Um-para-um Um-para-muitos Muitos Um-e-apenas-um Zero-para-um Zero-ou-muitos Um-ou-muitos Figura 18. Cardinalidade segundo Chen. 24 4.2. Metodologia de James Martin18 Na década de 80, James Martin apresentou uma nova proposta de modelagem que visava estabelecer a fronteira entre o modelo lógico e físico, desviando o foco do processo e centrando o foco nos eventos do sistema. Com essa nova proposta ele estabelece o particionamento por eventos, delimitando a área de atuação do sistema, através da utilização da lista de eventos e incorpora a modelagem de dados na especificação, introduzindo o modelo Entidade Relacionamento e Atributo (ERA). 4.2.1. Representação da Entidade Identificador da entidade Figura 19. Exemplo: Funcionário trabalha em Departamento. Neste exemplo temos duas entidades: Funcionário e Departamento. A representação dessas duas entidades fica da seguinte forma: FUNCIONÁRIO DEPARTAMENTO Figura 20. Exemplo de Entidade. ———————————————————— 18 Silberschatz, A; Korth, H. R. e Sudarshan, S. Sistemas de Bancos de dados. São Paulo: Makroon Books, 1999 25 4.2.2. Representação dos Atributos ENTIDADE Identificador dos atributos Figura 21. Exemplos de atributos da Entidade DEPARTAMENTO do exemplo anterior: • Código (do Departamento) • Nome (do Departamento) • Localização (do Departamento) DEPARTAMENTO cod_dept nome local Figura 22. Exemplo de atributo representado com a entidade. 4.2.3. Representação dos Relacionamentos e Cardinalidade No método proposto por Martin devemos indicar a cardinalidade do relacionamento. Dessa forma temos: 26 Cardinalidade - 1:1 Esta linha indica que um departamento está relacionando com apenas um registro de funcionário FUNCIONÁRIO Código Nome Contratação Gerente Salário Comissão Departamento DEPARTAMENTO Código Nome Localização Esta linha indica que um funcionário está relacionado com apenas um registro de departamento Figura 23. Cardinalidade - 1:1 Esta linha indica que um departamento está relacionando com apenas um registro de funcionário FUNCIONÁRIO Código Nome Contratação Gerente Salário Comissão DEPARTAMENTO Código Nome Localização Esta linha indica que um funcionário está relacionado com apenas um registro de departamento Figura 24. Neste caso a leitura da relação das tabelas é: Cada funcionário está em um departamento e um departamento tem vários funcionários. 27 4.2.4. Relacionamento Opcional Esta linha indica que um departamento está relacionando com muitos registros de funcionário. A bola cheia indica participação opcional. FUNCIONÁRIO Código Nome Contratação Gerente Salário Comissão Departamento DEPARTAMENTOCódigo Nome Localização Esta linha indica que um funcionário está relacionado com apenas um registro de departamento. A bola vazia indica participação obrigatória. Figura 25. Neste caso a leitura da relação das tabelas é: cada funcionário deve estar em um departamento e um departamento pode ter vários funcionários. 4.3. CASE*MethodTM A notação CASE*MethodTM, foi criada por Richard Baker, Ian Palmer, Harry Ellis na época em que eram funcionários da empresa britânica de consultoria CACI. O CASE*MethodTM é usado por grandes companhias, como a Oracle Corporation. É uma derivação da metodologia de James Martin e Peter Chen. Seu uso deve-se ao fato de estar mais focado para o desenho de banco de dados do que para a estrutura inerente dos dados da empresa. 4.3.1. Representação da Entidade Identificador da entidade Figura 26. 28 4.3.2. Representação dos Atributos ENTIDADE Identificador dos atributos Figura 27. Um ou mais atributos descrevem uma entidade, e os valores desses atributos descrevem as ocorrências da entidade. • Os identificadores dos atributos (nomes) devem estar no singular e em letras minúsculas. • Os atributos obrigatórios ou que devem ser conhecidos são marcados com *. • Os opcionais ou valores que podem ser conhecidos devem ser marcados com º. Identificadores exclusivos (Chaves primárias) devem ser marcados com #. Exemplo: DEPARTAMENTO #* código * nome º localização Figura 28. 4.3.3. Representação dos Relacionamentos Simbologia Descrição Representação Linha tracejada Elemento opcional indicando “pode ser” Linha sólida Elemento obrigatória indicando “deve ser” Pé de galinha Elemento de grau indicando “um ou mais” Linha única Elemento de grau indicando “somente um” Tabela 4. 29 Como o relacionamento indica a relação entre duas entidades para cada direção do relacionamento, são necessários: • um label, verbo que indica o relacionamento; • uma opcionalidade, indicando que algo deve ser ou pode ser; • um grau (ou cardinalidade) indicando somente um ou um ou mais. Exemplo: FUNCIONÁRIO DEPARTAMENTO #* número * nome º cargo Trabalha em composto de #* código * nome º localização Figura 29. 4.4. ERWin19 O software ERWin foi criado pela Logic Works, sendo uma ferramenta para o projeto de sistemas cliente-servidor de banco de dados. A principal característica do software é a existência de editores que definem os objetos lógicos e físicos do Banco de Dados, e de suporte à linguagem de definição de dados dos diversos servidores de banco de dados, SQL e não SQL. Utilizando-se de uma interface totalmente gráfica, padrão Windows, esta ferramenta permite uma modelagem completa de entidades e relacionamentos, a partir de ferramentas de desenho, tornando sua utilização extremamente fácil. Esta ferramenta gera o modelo lógico e físico para diversos gerenciadores de Banco de Dados, sejam eles SQL ou não SQL, distribuídos ou não. O ERWin é uma ferramenta de modelagem de dados com capacidade de gerar DDL para os principais RDBMS de mercado podendo incorporar triggers, stored procedures, regras de validação, domínios e templates. Uma de suas características mais avançadas é a capacidade de fazer engenharia reversa através de scripts ou direto do dicionário de dados do banco podendo, através da função “COMPLETE COMPARE”, oferecer um relatório detalhado das eventuais discrepâncias entre o modelo e a base ou script podendo inclusive promover a sincronização entre ambos. Ao acessarmos o software encontramos o menu principal: ———————————————————— 19 Extraido do manual on-line do ERWin, traducao livre do autor 30 Gerador de relatórios de modelagem Visão de nível de entidade (para trabalhar até a fase 2 de modelagem) Visão completa (para trabalhar nas fases 3 e 4) Visões funcionais (subject areas, para dividir o modelo em partes) Figura 30. Barra de ferramentas do ERWin Figura 31. Menu principal do ERWin. O software permite trabalhar com o modelo físico, com o lógico ou ambos. Para isso basta escolher o modelo na caixa: 31 Indica modelo físico/lógico Indica modelo lógico Indica modelo físico Figura 32. Opção para escolha do modelo. A figura 33. mostra a diferença ente os dois modelos. O modelo lógico não se preocupa com os futuros campos das tabelas e, sim, com a criação do dicionário de dados. O modelo físico preocupa-se com os campos das tabelas, suas chaves e restrições. Physical Model Logical Model MOVIE movie_number movie_director movie_description movie_rating movie_name movie_genre movie_rental_rate MOVIE movie_number rating rental_rate genre_ movie_clip description movie title_ MOVIE_COPY movie_number movie_copy_number movie_format general_condition MOVIE_COPY movie copy number movie number (FI<) General_condition movie_format Figura 33. Exemplo do modelo lógico e do modelo físico O ERWin distingue as entidades usando retângulos. Esses retângulos podem ter os cantos arredondados (soft-box) ou não. Quando o retângulo não tiver os cantos arredondados dizemos que irá dar origem a uma tabela pai. Quando o retângulo tiver os cantos arredondados ( soft-box) indica que irá dar origem a uma tabela filho, ou seja, irá receber uma chave estrangeira da tabela pai. Não importa se você estiver usando o modelo físico ou lógico, você pode escolher a notação que deseja trabalhar. O ERWin trabalha com duas notações: 32 • IDEF1X (Integration DEFinition for Information Modeling) ou • IE (Information Engeneering) IDEF1X e IE usam símbolos diferentes para representar o relacionamento entre entidades e tabelas. A figura 34. mostra a diferença entre as duas notações. STORE store number manager address phone IDEF1X rents / is in MOVIE movie_number name director description star rating genre rental_rate STORE store number manager address phone IE rents / is in MOVIE movie_number name director description star rating genre rental_rate Figura 34. Diferença entre a notação IDEF1X e IE. A notação defaulf usada pelo ERWin é IDEF1X mas pode ser alterado a qualquer momento. Basta entrar em Model, Properties, e escolher a notação. Para os modelos físicos existe a opção de DM (Dimensional Notation) que é usado para modelagem de Datawarehouse. 33 DM option displays in physical models only Figura 35. Alterando o modelo. O toolbox é alterado conforme o modelo escolhido. Veja exemplo na figura 36. Logical IE Notation Physical IDEF1X Notation Logical Physical Figura 36. Diferença entre a notação IE e a IDE1X. Existem três tipos de relacionamentos no ERWin: • O relacionamento identificado, representado pela linha contínua com uma bola cheia na ponta (Notação IDEF1X) ou com um pé de galinha (Notação IE) • O relacionamento não-identificado, representado pela linha tracejada com uma bola cheia na ponta (Notação IDEF1X) ou com um pé de galinha (Notação IE) • O relacionamento muitos-para-muitos, representado pela linha contínua com uma bola cheia em cada ponta (Notação IDEF1X) ou com um pé de galinha em cada ponta (Notação IE) 34No caso do relacionamento identificado a chave primária da tabela pai faz parte da chave primária da tabela filho. No caso do relacionamento não-identificado a chave primária não faz parte da chave primária da tabela filho. A figura 37. nos ajuda a compreender melhor.. CUSTOMER customer number credit card customer first_name Identifying relationship migrated key attribute credit card exp status code customer address customer phone email migrated non-key attribute MOVIE RENTAL RECORD customer number rental record date due date rental status payment transation number overdue charge PAYMENT payment transation number type amount date status rental rate rental date non-identifying relationship Figura 37. Exemplo de relacionamento identificado e não-identificado. 35 4.5. Quadro Resumido Peter Chen James Martin CASE *MethodTM IDEF1X IE Entidade ENTIDADE Atributos ENTIDADE atributo chave Atributos Atributo Relacionamento Cardinalidade 0 : 1 0 : N 1 : 1 1 : N N : M Figura 38. 36 5. Entidade De acordo com o que vimos nos capítulos anteriores. uma entidade 20 ou classe de entidade é uma representação abstrata de “coisas semelhantes”, concretas ou abstratas, que existem no mundo real, sobre a qual um sistema de informação captura, armazena e processa dados para cumprir seus objetivos na empresa, atendendo, assim, às necessidades de seus usuários. 5.1. Como identificar uma Entidade Com o tempo e a experiência em modelagem passamos a identificar as entidades de forma quase intuitiva, mas enquanto ainda não temos essa experiência podemos utilizar várias técnicas para isso, por exemplo na fase de levantamento podemos identificar as entidades através de substantivos. Uma outra técnica consiste na proposta apresentada Shlaer & Mellor 21 na qual podemos detectar as entidades através da observação de cinco grupos de elementos: • As coisas tangíveis • As funções exercidas por elementos • Eventos ou ocorrências • Interações • Especificações Segundo Cougo[2], esta separação das entidades será tratada como grupos de classificação que serão úteis apenas para identificação das entidades. Coisas tangíveis – Tudo aquilo que pode ser tocado, que tem existência concreta. Exemplos: caminhão, computador, moto, tear. O agrupamento desses objetos em Entidades dependerá do nível de abstração que se deseja atingir na modelagem do ambiente observado. Por exemplo: Entidade Objetos Produto Caminhão, computador, moto, tear Tabela 5. ———————————————————— 20 As entidades são representadas por tabelas na etapa de implementação do Banco. 21 apud Cougo, Paulo. Modelagem Conceitual e projeto de banco de dados. Rio de Janeiro:Campus, 1997 37 Atingindo um nível de abstração maior podemos ter: Entidade Objetos Veículo Caminhão, moto Equipamento computador, tear Tabela 6. Podemos abstrair um pouco mais e ter: Entidade Objetos Caminhão Todos os caminhões observados Moto Todas as motos observadas Computador Todos os computadores observados Tear Todos os teares observados Tabela 7. Funções – Papel, atribuição, classificação ou outra característica que especifique a atuação de um objeto identificado no ambiente observado. Exemplos: Uma analista de suporte, um engenheiro civil, departamento de Recursos Humanos. Entidade Objetos "Coisa" Tangível Especialista Analista, Engenheiro Pessoa Tabela 8. Abstraindo um pouco mais temos: Entidade Objetos "Coisa" Tangível Analista Todas as especialidades de analista Pessoa Engenheiro Todas as especialidades de engenheiro Pessoa Tabela 9. 38 Eventos ou ocorrências – Cougo22 define como objetos que são materializáveis quando alguma ação ou fato acontece. “Enquanto programado, durante sua execução ou após encerrado, esse elemento caracteriza-se como um evento ou ocorrência ao qual podemos fazer alguma referência.” Exemplos: Uma partida de futebol, um vôo de avião, uma viagem de carro. Interações – Resultantes da associação entre objetos em função de um processo sendo executado. Também podem ser modelados como entidades associativas (relacionamentos). Exemplos: A compra de um imóvel, a venda de um produto a um cliente. Especificações – Entidades que reúnem as características de objetos pertencentes a outros objetos. Podem ser identificados já na modelagem conceitual, ou aparecerem somente no modelo lógico, em função da aplicação de técnicas de normalização. Exemplo: Automóvel; Modelo do automóvel Automóvel é uma “coisa” tangível que poderíamos detalhar com os atributos: cor, modelo, ano de fabricação entre outros. Já a entidade Modelo do automóvel é uma entidade que específica (detalha) dados sobre o modelo tais como: banco de couro, direção hidramática, cambio hidráulico, farol de milha, entre outros. 5.2. Representações de Entidade O símbolo utilizado para representação de uma entidade depende da metodologia escolhida para a modelagem, conforme vimos nos capítulos anteriores. Neste material utilizaremos a metodologia proposta por Peter Chen e em alguns exemplos ilustraremos como é a representação utilizada pelo Erwin23. Peter Chen Erwin IDENTIFICADOR DA ENTIDADE IDENTIFICADOR DA ENTIDADE Figura 39. ———————————————————— 22 Cougo, Paulo. Modelagem Conceitual e projeto de banco de dados. Rio de Janeiro:Campus, 1997 23 Ferramenta de Modelagem relacional comercializada pela empresa Computer Associates. 39 Exemplos: 1. Sistema de Controle de Conta Corrente No ambiente de um sistema de controle de conta corrente, temos pessoas que são clientes de um banco. Pode-se então definir uma entidade cliente. Neste mesmo sistema, as contas mantidas no banco poderão ser definidas como uma entidade conta. CLIENTE CONTA Figura 40. Exemplo: Sistema de Controle de contas de um Hospital No contexto de um sistema de controle de contas de um hospital, algumas pessoas desempenham a função de médicos. Neste mesmo sistema, as pessoas que irão realizar uma consulta desempenham a função de pacientes. Estas pessoas são ocorrências de entidades distintas: médicos e pacientes. Note que um médico em um determinado momento também pode desempenhar a função de um paciente. MÉDICO PACIENTE Figura 41. Atenção: O identificador de uma entidade deve ser um nome relevante ao assunto que representará e recomenda-se que: • Não sejam utilizados caracteres especiais tais como acento, cedilha, *, $, entre outros; • Não seja iniciado por números; • Esteja no singular. Na etapa de implementação do modelo deve-se também atentar para as recomendações e particularidades do SGBDR utilizado. 5.3. Cuidado: Aquilo que é entidade numa circunstância, pode não ser em outra! Portanto, ao identificar as entidades de um sistema de informação, os desenvolvedores de software devem estar atentos à possibilidade de uma “coisa do mundo real” desempenhar mais de um papel no contexto deste sistema. 40 5.4. Tipos de Entidades 5.4.1. Entidade Meramente Conceitual Uma entidade meramente conceitual é aquela que representa uma classe de domínio e que não tem outras propriedades que não seu próprio conceito. Exemplos: Data, Hora,Período 5.4.2. Entidade Forte Uma entidade forte é aquela que não depende de outra entidade para existir. Exemplo: No contexto de uma organização faz-se necessário o armazenamento de dados de um funcionário por diversas demandas, uma delas é a folha de pagamento. Cada ocorrência de funcionário é r identificada de forma única, por exemplo por uma atributo identificado por registro funcional, sendo assim a entidade funcionário é uma entidade forte. 5.4.3. Entidade Fraca Entidades cuja existência depende da existência de outra entidade, dita forte. É representada por um retângulo duplo, podendo, opcionalmente, ser indicada uma seta que parte dela e chega a sua entidade forte, para tornar mais clara a dependência. A cardinalidade de uma ocorrência de uma entidade fraca com a forte é sempre (1,1), indicando que ela sempre depende de uma ocorrência da entidade forte. Em poucas palavras, entidade fraca é aquela que depende de uma outra entidade para existir. À entidade da qual depende dá-se o nome de entidade pai. Exemplo: Os funcionários de uma empresa possuem dependentes, por exemplo, seus filhos, cujos dados são utilizados por exemplo para concessão de benefícios ou descontos de IRRF. Os dados de dependentes estão relacionados diretamente à existência de uma ocorrência de funcionário. 1 : 1 possui 0 : N FUNCIONÁRIO DEPENDENTE Figura 42. 5.4.4. Entidade Associativa Uma entidade associativa é aquela que não existe por si só e sua existência está condicionada à existência de duas ou mais entidades, a partir das quais ela é concebida. 41 Exemplo: A entidade associativa aluno x disciplina surge quando há a derivação do modelo lógico a partir do modelo conceitual devido ao relacionamento n:n entre a entidade aluno e a entidade disciplina24. 5.4.5. Entidade de Dados Podem ser subdivididas em diversas categorias de elementos (Subtipos), cada uma se caracterizando por atributos específicos. Pessoa Física Jurídica Figura 43. Supertipo: É o conjunto de características que originou o subtipo. Subtipo: É definido como um subconjunto de características de um tipo. Exemplo: Supertipo pessoa e subtipos Pessoa Física e Pessoa Jurídica. ———————————————————— 24 Veja tópico sobre Derivação do Modelo Lógico a partir do Modelo Conceitual nos capítulos anteriores. 42 6. Atributos Conforme vimos anteriormente, cada entidade tem propriedades particulares, chamadas atributos, estas propriedades podem identificar, qualificar ou quantificar a entidade, em outras palavras os atributos descrevem as entidades. Por exemplo, uma entidade funcionário pode ser descrita pelo seu nome, o trabalho que realiza, data de nascimento, endereço e salário. Cada ocorrência de uma entidade terá um valor para cada um de seus atributos. 6.1. Como Identificar os Atributos Para identificar um atributo devemos estabelecer quais são suas características. Remetendo-nos a entidade funcionário, podemos perguntar “Quais são as características de um funcionário? O que o identifica?”. Responder a essas perguntas traz os atributos da entidade. No nosso exemplo, as respostas poderiam ser: Nome, Endereço, Telefone, Data de Nascimento, Cargo, Salário, Código do Funcionário. Percebam que essas características são os atributos do funcionário. 6.2. Representações de Atributos Assim como para as entidades, a representação de uma atributo depende da metodologia escolhida para a modelagem, conforme vimos nos capítulos anteriores. Neste material utilizaremos a metodologia proposta por Peter Chen que utiliza uma elipse para representar os atributos e em alguns exemplos ilustraremos como é a representação utilizada pelo Erwin 25. Peter Chen Erwin FUNCIONÁRIO cod_func endereço dt_nasc nome cargo FUNCIONARIO cod_func nome dt_nasc cargo endereco Figura 44. ———————————————————— 25 Ferramenta de Modelagem relacional comercializada pela empresa Computer Associates. 43 6.3. Classificação de Atributos Cougo26 classifica os atributos em três grupos: • Atributos Descritivos: Atributos que expressam características intrínsecas ao objeto, isto é, que representam qualidades ou descrições de um objeto. Por exemplo: data de nascimento, endereço, cor dos cabelos, peso, sexo, modelo de um automóvel. • Atributos Nominativos: Atributos que podem identificar um objeto, mesmo que não o faça de maneira única. Por exemplo: Nome de um funcionário, Registro acadêmico de um aluno, Código do produto, Placa de um automóvel. Atenção: Os atributos nominativos podem ser chaves candidatas e aqueles que atendem aos critérios podem vir a ser chaves primárias. • Atritutos Referenciais: Atributos que não pertencem à entidade a qual estão alocados, mas que fazem algum tipo de citação ou estabelecem uma relação entre esta entidade e a entidade de origem. Normalmente estes atributos são as chaves estrangeiras. No exemplo apresentado a seguir note que a entidade FUNCIONARIO tem o atributo cod_dept (código do departamento), mas este atributo, originalmente é um atributo nominativo da tabela DEPARTAMENTO, sendo assim para a entidade FUNCIONARIO este atributo é um atributo referencial, pois será utilizado para estabelecer um relacionamento 27 com a tabela DEPARTAMENTO. FUNCIONÁRIO DEPARTAMENTO cod_func cod_dept nome_func end cod_func nome_dept cod_dept Figura 45. 6.4. Tipos de atributos Independente da sua classificação um atributo pode possuir características que nos possibilitam defini-los como: • Atributo Simples • Atributo Composto • Atributo Monovalorado ———————————————————— 26 Cougo, Paulo. Modelagem Conceitual e projeto de banco de dados. Rio de Janeiro:Campus, 1997 27 Este assunto foi apresentado anteriormente e será detalhado no próximo capítulo 44 • Atributo Multivalorado • Atributo Derivado ou virtual • Atributo Opcional • Atributo Chave 6.4.1. Atributo Simples Atributos que não são divisíveis são chamados simples ou atômicos, por exemplo o atributo cargo para a entidade FUNCIONARIO. 6.4.2. Atributo Composto Alguns atributos podem ser divididos em subpartes com significados independentes. Um atributo que é composto de outros atributos mais básicos é chamado composto. Atenção: Atributos compostos podem formar uma hierarquia. No exemplo a seguir o endereço da entidade FUNCIONARIO pode ser dividido em endereço da rua, cidade, estado e cep; o atributo endereço da rua pode ser subdividido em nome da rua, numero do imóvel e complemento. FUNCIONÁRIO cod_func cod_dept nome_func end cep UF end_rua cidade nome_rua complemento número Figura 46. Atributos compostos são úteis quando os usuários referenciam o atributo composto como uma unidade e, em outros momentos, referenciam especificamente a seus componentes. Se o atributo 45 composto for sempre referenciado como um todo, não existe razão para subdividi-lo em componentes elementares. 6.4.3. Atributo Monovalorado Um atributo monovalorado - também chamado de univalorado - possui um valor único, ou seja, só existe uma representação daquele atributo para a mesma tupla. Vejamos, por exemplo, o atributo idade: um funcionário nunca poderá ter mais de uma idade ao mesmo tempo, o que torna esse atributo monovalorado. 6.4.4. Atributo Multivalorado Uma única entidade que tem ocorrências com diversos valores para este atributo. Atributos multivalorados podem possuir uma multiplicidade, indicando as quantidades mínima e máxima de valores.
Compartilhar