CES-30 Técnicas de Banco de Dados - BD e CE-240 Projeto de Sistema de BD

Transcrição

1 CURSO DE GRADUAÇÃO e DE PÓS-GRADUAÇÃO DO ITA 1º SEMESTRE 2002 CES-30 Técnicas de Banco de Dados - BD e CE-240 Projeto de Sistema de BD A Integração de Dados, a Independência de Dados e a 9 a Técnica de BD - Auditoria da Terceira Forma Normal CES-30 / CE A. M. Cunha Integração de Dados e Independência de Dados (1) A Integração de Dados propicia: - Melhorias no Gerenciamento dos Sistemas de Informação; - Melhorias nas Organizações como um todo; - Aumentos nos Compartilhamentos; e - Reduções nas Duplicações. A Integração de Dados acarreta impactos: 1) Nos Controles de Acesso; 2) Nas Visões de Aplicações Orientadas a Dados; e 3) Nas Limitações às Mudanças. A Adoção do Enfoque da Independência de Dados alivia esses impactos. Principais Impactos da Integração de Dados nos Controles de Acesso: - A Integração de Dados permite que Arquivos Isolados sejam acessados apenas por um número limitado de Programas; - Considerando que um Banco de Dados pode servir à diversas aplicações, a Integração de Dados evita que alterações sejam realizadas nos Banco de Dados Integrados por pessoas ou programas não autorizados; CES-30 / CE A. M. Cunha 7.1.2

2 Integração de Dados e Independência de Dados (2) Impactos da Integração de Dados nas Aplicações Orientadas a Dados - Propiciam Visões de Aplicações Orientadas a Dados: Aplicações de BD costumam ser desenvolvidas, de forma apropriada para conter somente as informações necessárias às Aplicações; Um SGBD pode apoiar um determinado número de Aplicações de BD, mas o conteúdo e a estrutura dessas Aplicações devem obedecer a Técnicas e Critérios Globais de utilização; Do ponto de vista das Aplicações individuais de BD, um Modelo de Dados Corporativo poderá conter muitas informações irrelevantes e uma Estrutura de Dados que não seja a ideal; e Na medida que os Modelos Entidade Relacionamento MER das Aplicações de BD vão sendo modificados, para inclusão e integração aos Modelos de Dados Setoriais MDS ou Modelos de Dados Corporativos - MDC, diversas modificações no seu conteúdo e estrutura poderão ser necessárias. Entretanto, essas integrações devem ocorrer, sem se perder a Independência dos Dados e a Identidade dessas Aplicações de BD. Limitando Impactos de Mudanças: Devido às integrações naturais que se fazem necessárias nos Projetos de Sistemas Banco de Dados Corporativos, até mesmo Aplicações de BD não diretamente afetadas pelas mudanças poderão ainda ser alteradas. CES-30 / CE A. M. Cunha Integração de Dados e Independência de Dados (3) Um outro acesso é a capacidade de adaptação do esquema/subesquema pelo grupo de tarefas do banco de dados (DBTG) no modelo rede. Esquema : Descrição das entradas do banco de dados. Subesquema : São criados para descrever as visões da relevância do banco de dados para um usuário particular ou grupos. A estrutura do esquema/subesquema pode ser efetivada se houver recurso suficiente de mapeamento no processo do subesquema. A definição de subesquema, usando algumas linguagens de definição de dados (DDL), deve especificar como cada objeto de dado no subesquema relaciona-se com o referido esquema. Quando uma inclusão ou alteração do subesquema não requerer qualquer modificação no esquema, todos os mapeamentos para outros subesquemas já existentes permanecerão válidos. Aquelas aplicações que usarem os outros subesquemas estarão totalmente inalteradas pelas mudanças. CES-30 / CE A. M. Cunha 7.1.4

3 A Heurística dos SGBDs (Metáfora do Futebol) DEFESA MEIO CAMPO ATAQUE Back end DB Machine Servidor CAKE Servidor de BD Servidor CASE Servidor Firewall Empresas Holdings ou Grandes Corporações ORACLE 8i, DB2, SYBASE, INFORMIX, etc... Redes Corporativas, Distribuídas e de Grande Porte Pequenas Corporações ou Empresas de Médio Porte SQL Server, Interbase, Delphi (Pascal OO), Personal ORACLE 8i, etc... Redes Corporativas de Médio Porte Empresas de Pequeno Porte Access, Interbase, FoxPro, Personal ORACLE 8i, etc... Pequenas Redes Locais N o Aplicat BD >= 90 N o Entidades >= 180 N o Atributos s >= > N o Aplicat BD > > N o Entidades > > N o Atributos > 90 N o Aplicat BD <= 30 N o Entidades <= 60 N o Atributos <= 90 DE FACTO FACTORS TCP / IP Linguagens OO SQL e OQL CES-30 / CE A. M. Cunha Visão Geral dos Modelos Conceituais de BD das Empresas Exemplos no Domínio de Conhecimento da Aeronáutica: Empresa Holding = Ministério da Defesa / Comando da Aeronáutica /... Modelo de Dados da Holding - MDH Empresas Corporativas = COMGAR / COMGAP / DEPED /... Modelos de Dados Corporativos - MDC Empresas Setoriais = COMAR / CTA / Diretorias /... Empresas Locais = Unidades Aéreas / Institutos do CTA /... Modelos de Dados Setoriais - MDS Modelos de Dados de Aplicativos de BD MER ou DER UPSIZING RIGHTSIZING DOWNSIZING CES-30 / CE A. M. Cunha 7.1.6

4 Como Desenvolver Projetos de Sistema de BD e Manter a Independência de Dados? Para integrar os Aplicativos de BD, deve-se, de forma iterativa e continuada, aplicar as Técnicas de BD, de baixo para cima: 1) Modelar, re-modelar, normalizar, re-normalizar, denormalizar, dicionarizar e re-dicionarizar os MERs dos Aplicativos de BD, quando for necessário; 2) Integrar os MERs aos Modelos de Dados Setoriais MDSs, modelar, remodelar, normalizar, re-normalizar, denormalizar, dicionarizar e redicionarizar os MDSs, sempre que for necessário; 3) Integrar os MDSs aos Modelos de Dados Corporativos MDCs, modelar, remodelar, normalizar, re-normalizar, denormalizar, dicionarizar e redicionarizar modelando-os e re-modelando-os, quando for necessário; e 4) Integrar os MDCs ao Modelo de Dados da Holding MDH, modelar, remodelar, normalizar, re-normalizar, denormalizar, dicionarizar e re-dicionarizar o MDH, sempre que for necessário. CES-30 / CE A. M. Cunha As 5 Formas Normais Universo das Relações Normalizadas e Não Normalizadas Relações na 1FN Relações na 2FN Relações na 3FN 4FN 5FN CES-30 / CE A. M. Cunha 7.1.8

5 Definições para as Formas Normais : Uma relação R está na 1FN, se e somente se, todos os domínios básicos contiverem somente valores atômicos; Uma relação R está na 2FN, se e somente se, estiver na 1FN e todos os atributos não-chave forem totalmente dependentes da chave primária; e Uma relação R está na 3FN, se e somente se, estiver na 2FN e todos os atributos não-chave forem dependentes não-transitivos da chave primária, isto é, forem mutuamente independentes. CES-30 / CE A. M. Cunha Vantagens da Normalização (3FN) : Otimiza o desempenho das atualizações; Ajuda a dirimir dúvidas de Projeto, pois por vezes, com a finalidade de melhorar o desempenho das funções de acesso, o projetista de BD pode tomar decisões que comprometam as funções de atualização. Ao seguir estritamente o processo de normalização, isso seria evitado; Agrupa dados, de tal forma, que numa Relação, cada dado torna-se um dado dependente da Chave, de toda a Chave e nada mais que a Chave primária da Relação; e Provê um meio formal de se estruturar a informação, de tal forma, que fica claro, exatamente, que tipos de dados existem, e que dependências funcionais são satisfeitas. CES-30 / CE A. M. Cunha

6 Outro Exemplo de 3FN - Eliminando Transitividades (campos não-chave referenciando campos não-chave) Relação fora da 3FN - Employee # S6 Relação na 3FN - Department Biology Computer Location Boston Chicago Employee # Department # Department # Location S6 Biology Computer Biology Computer Boston Chicago CES-30 / CE A. M. Cunha Um exemplo de 4FN (4FN deve satisfazer a 3FN e conter dois ou mais Atributos Interdependentes) Exemplo de interdependência de Atributos - Empregados possuem múltiplas habilidades e múltiplas linguagens. Na Relação EMP_TALENTO existem dois relacionamentos muitos-para-muitos, entre os atributos empregado e habilidade, e empregado e linguagem. EMP_TALENTO Relação na 3FN => Relações na 4FN = empregado # EMP_HABILIDADE empregado # habilidade Cook Type habilidade Cook Type Type EMP_LINGUAGEM empregado # linguagem German Spanish Russian Russian Neste Exemplo, foram eliminadas as Anomalias de Atualização da Relação EMP_TALENTO na 3FN. Nas Relações EMP_HABILIDADE e EMP_LINGUAGEM, passadas para a 4FN, acabou-se com as ambigüidades e com os dois relacionamentos muitos-para-muitos do exemplo. linguagem German Spanish CES-30 / CE A. M. Cunha

7 Um exemplo de 5FN (A 5FN deve satisfazer a 3FN e conter dois ou mais Atributos Interdependentes) Contexto: Deseja-se armazenar e recuperar Vendedores quevendem Produtospor Empresas. Neste caso, os Vendedores devem sempre trabalhar com os mesmos Produtos. Portanto, um Vendedor só deverá trabalhar para uma Empresa, que venda todos os Produtos contidos na relação. VEND_REL Relação na 3FN => Note-se que a Relação VEND_REL não está na 5FN, pois pode-se reconstruí-la a partir das Relações VEND_PROD, VEND_EMPR e EMPR_PROD. VEND # S4 EMPR GM GM Ford Ford Ford PROD Carro Caminhao Carro Caminhao Carro Relações na 5FN = VEND_PROD VEND # PROD # Carro Caminhao S4 Carro VEND_EMPR VEND # EMPR # GM Ford S4 Ford EMPR_PROD EMPR # Ford PROD # Carro Ford Caminhao GM Carro GM Caminhao CES-30 / CE A. M. Cunha Evolução até a Terceira Forma Normal - 3FN 0 N F CATALOGO {num_chamada, titulo, autor, editora, cidade_edit, 1 N F num_associado, data_de_devolucao} CATALOGO {num_catalogo, num_copia, titulo, autor, editora, cidade_edit, num_associado, data_de_de volucao} 2 N F COLECAO {num_catalogo, titulo, autor, editora, cidade_edit} VOLUME {num_catálogo, num-copia, num_associado, data_de_devolucao} 3 N F CATALOGO {num_catalogo, titulo, autor, editora} EDITORA {editora, cidade_edit} VOLUME {num_catalogo, num_copia, num_associado, data_de_devolucao} CES-30 / CE A. M. Cunha

8 Utilizando um Auditor de 3FN: 1) Carregar o third.doc; 2) Listar o conteúdo de um arquivo na 2FN; 3) Executar o third.exe com o arquivo na 2FN; e 4) Verificar e validar os Resultados obtidos na 3FN. CES-30 / CE A. M. Cunha