Não Não Sim Não Sim Sim

Transcrição

1 DCC011 Introdução a Banco de Dados -19 Mirella M. Moro Departamento de Ciência da Computação Universidade Federal de Minas Gerais mirella@dcc.ufmg.br Projeto de Banco de Dados 1. Processo de Projeto de Bancos de Dados 2. Abordagem ER 3. Estratégias para o projeto do esquema conceitual 4. Construindo o modelo conceitual 1. Processo de Projeto de BD Caracterização Complexidade Multiplicidade de tarefas Fases Coleção e análise de requisitos Projeto conceitual Escolha de um SGBD Projeto lógico ou mapeamento para o modelo de dados do SGBD escolhido Projeto físico Implementação e tuning Projeto de Bancos de Dados Independente de SGBD Específico para um SGBD Requisitos Funcionais Análise Funcional Especificação das Transações (em alto nível) Projeto das Aplicações Mini-Mundo Análise de Requisitos Requisitos do BD Projeto Conceitual Esquema Conceitual (em um modelo de dados de alto nível) Projeto Lógico Esquema Lógico (em um modelo de dados lógico) Projeto Físico Implementação Esquema Físico (para um SGBD específico) DCC011 - profa Mirella 3 Programas DCC011 - profa. Mirella 4 DCC011 - profa Mirella Dependência entre as Fases de Projeto e o SGBD Adotado Projeto Conceitual Classe do SGBD Não SGBD Específico Não Projeto Lógico Sim Não Projeto Físico Sim Sim 5 Independente de SGBD Específico para um SGBD Projeto de Bancos de Dados Requisitos Funcionais Análise Funcional Especificação das Transações (em alto nível) Projeto das Aplicações Implementação Mini-Mundo Análise de Requisitos Requisitos do BD Projeto Conceitual Esquema Conceitual (em um modelo de dados de alto nível) Projeto Lógico Esquema Lógico (em um modelo de dados lógico) Projeto Físico Esquema Físico (para um SGBD específico) Modelo ER Modelo Relacional SGBD Relacional Programas DCC011 - profa. Mirella 6

2 Aplicação exemplo Banco de Dados de uma companhia Organizada em departamentos que têm um nome e um número únicos e um empregado que gerencia o departamento. A data de quando o empregado começou a gerenciar o departamento deve ser registrada. Um departamento pode ter varias localizações Um departamento controla um número de projetos, cada qual com um nome e número únicos e uma única localização Aplicação exemplo Banco de Dados de uma companhia Nós armazenamos para cada empregado seu nome, identidade, endereço, salário, sexo, e data de nascimento. Um empregado é assinalado a um departamento mas pode trabalhar em diversos projetos, os quais não são necessariamente controlados pelo mesmo departamento. Nos registramos o número de horas por semana que o empregado trabalha em cada projeto e o supervisor direto de cada empregado Nós mantemos registro para cada empregado, do numero de dependentes (para seguro) e para cada dependente o primeiro nome, sexo, data de nascimento e relacionamento com o empregado. DCC011 - profa Mirella 7 DCC011 - profa Mirella 8 todo E trabalha_para 1 D todo D trabalha_para N E 3. Estratégias para o Projeto do Esquema Conceitual um E supervisiona 1 E um E supervisor N E Esquema conceitual um E gerencia 1 D todo D gerencia 1 E um D controla N P todo P controla 1 D Centralizado Todos os requisitos são capturados de uma vez Abordagem de integração de visões Uma visão éprojetada para cada grupo de usuários e aplicações Subseqüentemente essas visões são integradas em um esquema conceitual global DCC011 - profa Mirella 9 DCC011 - profa Mirella 10 Integração de Visões Tarefas Identificar correspondências e conflitos nos esquemas Conflito de nomes: comprador vs. cliente; peça (de computador ou de automóvel) Conflito de tipos: departamento como entidade ou como atributo Conflito de dominio: salário em dólar ou em real Conflito de restrição: curso pode ter sóum ou mais de um professor Modificar visões Integrar visões Reestruturação DCC011 - profa Mirella 11 DCC011 - profa Mirella 12

3 n EMPLOYEE[SUPERSSN] EMPLOYEE[SSN] b EMPLOYEE[DNO] DEPARTMENT[DNUMBER] b DEPARTMENT[MGRSSN] EMPLOYEE[SSN] p DEPT_LOCATIONS[DNUMBER] DEPARTMENT[DNUMBER] b PROJECT[DNUM] DEPARTMENT[DNUMBER] b WORKS_ON[ESSN] EMPLOYEE[SSN] b WORKS_ON[PNO] PROJECT[PNUMBER] p DEPENDENT[ESSN] EMPLOYEE[SSN] Construindo o Esquema Conceitual 1. Propriedades do Esquema Conceitual 2. Processo de construção DCC011 - profa Mirella 13 Construindo Esquema Conceitual Na primeira parte da matéria aprendemos a notação de modelos ER Agora vamos aprender a construir esquemas conceituais, garantindo suas propriedades formais 1. Propriedades de Modelos ER (a) Modelo ER é um modelo formal (b) Poder de expressão é limitado (c) Equivalência entre modelos DCC011 - profa Mirella 15 Slide adaptado de HEUSER DCC011 - profa Mirella 16 (a) Modelo ER é um modelo formal Modelo preciso, não ambíguo Diferentes leitores de um mesmo model ER devem sempre entender exatamente o mesmo DER pode ser usado como entrada a uma ferramenta CASE Fundamental: todos os envolvidos devem estar treinados na sua perfeita compreensão Risco: sub-utilização (b) Poder de expressão limitado Modelo ER apresenta apenas algumas propriedades de um banco de dados Foi concebido para o projeto da estrutura de um BD relacional Pouco poderoso para expressar restrições de integridade (regras de negócio) DCC011 - profa Mirella 17 DCC011 - profa Mirella 18

4 Poder de expressão: exemplo Poder de expressão: exemplo DCC011 - profa Mirella 19 DCC011 - profa Mirella 20 Poder de expressão Poder de expressão DCC011 - profa Mirella 21 DCC011 - profa Mirella 22 (c) Equivalência entre modelos Equivalência entre modelos: exemplo Dois modelos ER podem ser equivalentes Modelos equivalentes Expressam o mesmo Modelam a mesma realidade Para fins de projeto de BD, dois modelos ER são equivalentes Geram o mesmo esquema de BD Considerar um conjunto de regras de tradução de modelos ER para modelos lógicos de BD DCC011 - profa Mirella 23 DCC011 - profa Mirella 24

5 Equivalência entre modelos: exemplo Equivalência entre modelos: exemplo DCC011 - profa Mirella 25 DCC011 - profa Mirella Processo de Construção A. Identificando construções B. Verificação do modelo C. Modelo deve refletir o aspecto temporal D. Estratégias de modelagem A. Identificando construções Determinação da construção da abordagem ER (entidade, relacionamento,...) que será usada para modelar um objeto de uma realidade Não pode ser feita através da observação do objeto isoladamente É necessário conhecer o contexto (modelo dentro do qual o objeto aparece) DCC011 - profa Mirella 27 DCC011 - profa Mirella 28 Identificando construções Recomendação geral Decisão por uma construção para a modelagem de um objeto está sujeita à alteração durante a modelagem Não despender um tempo excessivo em longas discussões sobre como modelar um objeto Desenvolvimento do modelo e o aprendizado sobre a realidade irão refinar e aperfeiçoar o modelo Identificando construções Dúvidas mais comuns Atributo versus entidade relacionada Atributo versus especialização/generalização Atributo opcional Atributo multivalorado DCC011 - profa Mirella 29 DCC011 - profa Mirella 30

6 Atributo versus entidade relacionada Atributo versus entidade relacionada Objeto está vinculado a outros objetos Deve ser modelado como entidade Caso contrário Pode ser modelado como atributo Conjunto de valores de um determinado objeto é fixo (domínio fixo) Pode ser modelado como atributo Existem transações no sistema que alteram o conjunto de valores do objeto (domínio variável) Não deve ser modelado como atributo DCC011 - profa Mirella 31 DCC011 - profa Mirella 32 Atributo versus generalização/especialização Questão Modelar um determinado objeto (por exemplo, a categoria funcional de cada empregado de uma empresa) Como atributo? Categoria funcional como atributo da entidade EMPREGADO Como especialização? Cada categoria funcional corresponde a uma especialização da entidade EMPREGADO Atributo versus generalização/especialização Especialização deve ser usada quando As classes especializadas de entidades possuem propriedades particulares Atributos Relacionamentos Generalizações/especializações DCC011 - profa Mirella 33 DCC011 - profa Mirella 34 Atributo versus generalização/especialização Atributo opcional Atributo opcional Podem indicar subconjuntos de entidades que são modelados mais corretamente através de especializações Exemplo DCC011 - profa Mirella 35 DCC011 - profa Mirella 36

7 Atributo multivalorado Atributo multivalorado é indesejável SGBD relacional que segue o padrão SQL/2 Atributo multivalorado não possui implementação direta SGBD OO ou objeto/relacional Atributo multi-valorado normalmente é modelado como classe separada Atributos multivalorados podem induzir a um erro de modelagem Ocultar entidades e relacionamentos em atributos multivalorados DCC011 - profa Mirella 37 DCC011 - profa Mirella 38 B. Verificação do Modelo b.1. Modelo deve ser correto b.2. Modelo deve ser completo b.3. Modelo deve ser livre de redundâncias DCC011 - profa Mirella 39 DCC011 - profa Mirella 40 b.1. Modelo deve ser correto Erros Sintáticos Semânticos Erros semânticos mais difíceis de verificar Regras de normalização auxiliam na validação A partir da próxima aula Erros semânticos: exemplos Estabelecer associações incorretas Associar a uma entidade um atributo que na realidade pertence a outra entidade Usar uma entidade como atributo de outra entidade Usar o número incorreto de entidades em um relacionamento Fundir em um único relacionamento ternário dois relacionamentos binários independentes DCC011 - profa Mirella 41 DCC011 - profa Mirella 42

8 b.2. Modelo deve ser completo Deve fixar todas propriedades desejáveis do banco de dados Somente pode ser verificado por alguém que conhece profundamente o sistema a ser implementado Envolver o usuário Verificar completude Forma de verificar Dados que devem ser obtidos do banco de dados estão presentes? Todas as transações de modificação do banco de dados podem ser executadas sobre o modelo? Requisito é aparentemente conflitante com a falta de poder de expressão de modelos ER DCC011 - profa Mirella 43 DCC011 - profa Mirella 44 b.3. Modelo deve ser livre de redundâncias Modelo deve ser mínimo, isto é, não deve conter conceitos redundantes Tipos de redundância Relacionamentos redundantes Atributos redundantes O que fazer com construções redundantes? Alternativas Não devem aparecer no modelo ou Devem aparecer indicadas como dedundantes Implementação pode conter redundância controlada de dados (desempenho) DCC011 - profa Mirella 45 DCC011 - profa Mirella 46 Atributos redundantes ou deriáveis DCC011 - profa Mirella 47 DCC011 - profa Mirella 48

9 C. Modelo e Aspecto Temporal Atributos temporais O modelo deve refletir o aspecto temporal Dados temporais Dados que mudam ao longo do tempo e Para os quais BD mantém histórico Tipos de dados temporais Atributos cujos valores modificam ao longo do tempo Relacionamentos que modificam ao longo do tempo DCC011 - profa Mirella 49 DCC011 - profa Mirella 50 Relacionamento 1:1 temporal Relacionamento 1:N temporal DCC011 - profa Mirella 51 DCC011 - profa Mirella 52 Relacionamento N:N temporal D. Estratégias de Modelagem Estratégia de modelagem ER Uma seqüência de passos uma receita-debolo de transformação de modelos desde o modelo inicial de modelagem até o final Diferentes estratégias Bottom-up Top-down Inside-out DCC011 - profa Mirella 53 DCC011 - profa Mirella 54

10 Definição da estratégia de modelagem Na prática Nenhuma das estratégias propostas na literatura universalmente aceita Normal Combinação das diversas estratégias de modelagem Compreensível Processo de modelagem é um processo de aprendizagem Definição da estratégia de modelagem Identificar qual a fonte de informaçõesprincipal para o processo de modelagem Descrições de dados existentes Estratégia bottom-up Conhecimento de pessoas sobre o sistema Estratégia top-down (inside-out) DCC011 - profa Mirella 55 DCC011 - profa Mirella 56 d.1. Estratégia top-down Partir de conceitos mais abstratos, de cima Ir gradativamente refinando estes conceitos e conceitos mais detalhados Estratégia top-down : processo Modelagem superficial Enumeração das entidades Identificação dos relacionamentos(cardinalidade máxima) e hierarquiasde generalização/especialização entre as entidades Determinação dos atributosde entidades e relacionamentos Determinação dos identificadoresde entidades e relacionamentos O banco de dados é verificado quanto ao aspectotemporal DCC011 - profa Mirella 57 DCC011 - profa Mirella 58 Estratégia top-down : processo d.2. Estratégia Inside-out Modelagem detalhada Domínios dos atributos Cardinalidades mínimas Demais restrições de integridade Validação do modelo Construções redundantesou deriváveis a partir de outras no modelo Validação com o usuário DCC011 - profa Mirella 59 DCC011 - profa Mirella 60

11 Reserva de passagens aéreas O objetivo do trabalho é projetar um sistema de reservas para uma companhia de aviação. O sistema contará com um banco de dados central, que será acessado por aplicações clientes, rodando tanto dentro da própria companhia, quanto fora dela. A transação central do sistema é a reserva. Uma reserva é identificada por um código gerado pelo sistema em computador. A reserva é feita para um único passageiro, do qual se conhece apenas o nome. A reserva compreende um conjunto de trechos de vôos, que acontecerão em determinada data/hora. Para cada trecho, a reserva é feita em uma classe (econômica, executiva, etc) Um vôo é identificado por um código e possui uma origem e um destino. Por exemplo, o vôo 959 sai de Porto Alegre com destino a São Paulo. Um vôo é composto de vários trechos, correspondendo às escalas intermediárias do vôo. Por exemplo, o vôo 959 é composto de dois trechos, um de Porto Alegre a Londrina, o outro de Londrina a São Paulo. Cabe salientar que há cidades que são servidas por vários aeroportos. Por isso, é importante informar ao passageiro que faz a reserva qual é o aeroporto no qual o vôo passa. Reserva de passagens aéreas Às vezes os clientes, ao fazer a reserva querem saber qual é o tipo de aeronave que será utilizada em determinado trecho de vôo. Alguns poucos vôos, principalmente internacionais, têm troca de aeronave em determinadas escalas. Nem todos vôos operam em todos dias da semana. Inclusive, certos vôos têm pequenas mudanças de horário em certos dias da semana. Cada reserva possui um prazo de validade. Caso os bilhetes não tenham sido emitidos até esgotar-se o prazo da reserva, a mesma é cancelada. Reservas podem ser prorrogadas. Como o check-in de todos os vôos está informatizado, a companhia possibilita a reserva de assento para o passageiro. Reservas de assento podem ser feitas com até três meses de antecedência. Além de efetivar reservas, o sistema deve servir para vários tipos de consultas que os clientes podem querer fazer: Possibilidades de viagem de uma cidade ou de um aeroporto para outro O mesmo, mas restrito a determinados dias da semana Horários de chegada ou de saída em determinados vôos Disponibilidade de vagas em um trecho de vôo Disponibilidade de determinados assentos em um trecho de vôo DCC011 - profa Mirella 61 DCC011 - profa Mirella entidades 2. relacionamentos Entidades Companhia, reserva, passageiro, trecho, voo, cidade, aeroporto, tipo-aeronave, horário, assento Não foi criada uma entidade Pessoas que efetivaram a reserva Problema de homônimos Atributo reserva DCC011 - profa Mirella 63 DCC011 - profa Mirella Atributos e identificadores RESERVA (codigo reserva, passageiro, prazo) VOO (numero) TRECHO () AEROPORTO (codigo, nome) CIDADE (codigo, nome, país) TIPO AERONAVE (codigo, descrição) HORARIO (dia semana, horário partida, horário chegada) ASSENTO (numero, classe) RSRV-TRCH (data) 4. Restrições de integridade Uma reserva de trecho somente pode ser realizada caso existam vagas no trecho em questão na data em questão Uma reserva para um assento somente pode ser feita se o assento em questão existir no tipo de aeronave utilizada no trecho de vôo em questão DCC011 - profa Mirella 65 DCC011 - profa Mirella 66

12 5. Redundância e desempenho Observação geral Solução adotada conceitual Não inclui redundâncias de dados que objetivem melhorar o desempenho Não atributos redundantes Número de vagas em um trecho de vôo, em uma data, inclusive discriminado por classe Criar entidade TRECHO-DIA Etapa de projeto DCC011 - profa Mirella 67 DCC011 - profa Mirella 68 DCC011 - profa Mirella 69 DCC011 - profa Mirella 70 DCC011 - profa Mirella 71 DCC011 - profa Mirella 72

13 DCC011 - profa Mirella 73 DCC011 - profa Mirella 74 DCC011 - profa Mirella 75 DCC011 - profa Mirella 76 DCC011 - profa Mirella 77 DCC011 - profa Mirella 78

14 DCC011 - profa Mirella 79 DCC011 - profa Mirella 80 DCC011 - profa Mirella 81 DCC011 - profa Mirella 82 DCC011 - profa Mirella 83