Fundamentos de Banco de Dados - Análise e Desenvolvimento de Sistemas 1º Semestre

1 Análise e Desenvolvimento de Sistemas 1º semestre 1 nto de o de olvim im Fundamentos de Banco de Dados Análise e Desenvolvimento de Sistemas 1º semestre 1º Semestre Fundamentos de Banco de Dados 1º Semestre 2 Introdução 8 1 Fundamentos de Bancos de Dados 12 11 Bancos de Dados 12 12 Sistema Gerenciador de Bancos de Dados 12 13 Quando não utilizar um Sistema Gerenciador de Bancos de Dados 15 2 Sistema de Banco de Dados 17 21 Modelos de dados esquemas e instâncias 17 211 Modelo hierárquico 17 212 Modelo de rede 17 213 Modelo relacional 18 22 Categorias de modelos de dados 19 23 Transações 19 24 Arquitetura de três esquemas 21 241 Independência dos dados 22 3 Modelagem Conceitual 24 31 Modelos em Geral 24 32 Modelos Conceituais 25 4 Modelo EntidadeRelacionamento 28 41 Entidades 28 411 Atributos Compostos 29 412 Atributos Multivalorados 30 413 Atributos Derivados31 414 Valores Nulos 31 42 Tipos de Entidades 32 421 Atributoschave de um Tipo de Entidade 32 43 Tipos de Relacionamento 33 431 Relacionamentos como atributos 34 3 Análise e Desenvolvimento de Sistemas 1º semestre 3 432 Nomes de Função e Relacionamentos Recusivos 34 44 Razão de Cardinalidade e Restrição de Participação 35 45 Tipo de EntidadeFraca 37 46 Resumo da Notação para Diagramas EntidadeRelacionamento 37 Referências 51 Especialização e Generalização 42 511 Especialização 42 512 Generalização 42 513 Restrições sobre especialização e generalização 43 52 Agregação 44 612 Atributos das classes 48 613 Visibilidade 48 614 Multiplicidade do atributo 48 615 Atributo derivado 49 62 Relacionamentos ou Associações 49 63 Associação Binária 50 ão de Papéis 50 65 Associação Ternária ou Nária 51 66 Classe Associativa 51 67 Generalização Especialização 51 671 Generalização Normal 53 Fundamentos de Banco de Dados 1º Semestre 4 672 Restrições de Sobreposição e Disjuntiva 53 68 Agregação 54 69 Composição 54 71 Conceito do Modelo Relacional 57 72 Notação relacional 58 731 Restrições de domínio 60 732 Restrições de domínio e Chaves 60 733 Restrições de integridade 62 81 Primeiro Passo 65 82 Segundo Passo 66 83 Terceiro Passo 66 84 Quarto Passo 66 85 Quinto Passo 67 86 Sexto Passo 67 88 Projeto lógico do banco de dados 68 89 Mapeando construções do modelo EER para relações 68 891 Passo 8 69 91 Abordagens de Projeto de Banco de Dados 72 92 Anomalias 72 921 Anomalias de Atualização 73 922 Anomalias de Alteração 73 923 Anomalias de Exclusão 74 5 Análise e Desenvolvimento de Sistemas 1º semestre 5 93 Dependências Funcionais 74 931 Exemplos de Dependências Funcionais 74 932 Regras para encontrar Dependências Funcionais 75 94 Formas Normais77 941 Primeira Forma Normal 1FN 78 942 Segunda Forma Normal 2FN 78 943 Terceira Forma Normal 3FN 79 944 Forma Normal de Boyce Codd FNBC 80 945 Dependências Multivaloradas e a Quarta Forma Normal 4FN 82 946 Dependências de Junção e a Quinta Forma Normal 5FN 84 947 Demais Formas Normais 85 Referências 87 Fundamentos de Banco de Dados 1º Semestre 6 O professor Prof Alexandre Leite Rangel Doutor em Ciências e Mestre em Enfermagem pela Escola de Enfermagem de Ribeirão Preto da USP 2010 onde pesquisou o problema computacional da área de Otimização e Programação Linear Nursing Schedule Problem Desenvolveu no Mestrado 2007 um Sistema de Apoio à Tomada de Decisão para Elaboração durante o seu doutoramento Anteriormente concluiu uma especialização Latu Sensu em Análise de Sistemas pela Universidade de Ribeirão Preto 1996 Graduouse no Bacharelado em Análise de Sistemas também pela UNAERP 1994 Obteve na FATEC a Licenciatura Plena com habilitação em Processamento de Dados 1999 É professor desde 1994 tendo lecionado na UNAERP USP UNIFEB UNIP e FATEC e atualmente atua no Claretiano Centro Universitário e na Faculdade Impacta de Tecnologia Destaque para o projeto da Fábrica de Software do curso de Sistemas de Informação do UNIFEB ao qual coordenou entre 2013 e 2016 onde implementou vários sistemas e coordenou alunos e bolsistas Foi analista de sistemas do HCFMRPUSP Hospital das Clínicas da Faculdade de Medicina de Ribeirão Preto da Universidade de São Paulo por 9 anos É também autor de 6 livros sendo 5 sobre Bancos de Dados e um sobre Desenvolvimento para Web Prof Oswaldo Kotaro Takai Mestre em Ciências de Computação e Matemática Computacional pela USP de São Carlos ICMCUSP e Graduado em Ciências da Computação também pela USP São Carlos Consultor em desenvolvimento e modelagem de sistemas computacionais mais de 20 anos de experiência como docente do ensino superior nas áreas de Computação Engenharia de Software Banco de Dados e Sistemas de Informação Atuou como consultor do PNUD foi especialista em Engenharia de Sistemas do Atech Tecnologias Críticas do Grupo EMBRAER e consultor interno da empresa VAGAS Tecnologia Atualmente é prestador de serviço Superintendência de Tecnologia da Informação USP professor convidado da Universidade Estadual de Campinas professor da Faculdade Impacta de Tecnologia e desenvolve seu projeto de pesquisa junto ao grupo de Banco de Dados do IMEUSP Coordenador dos cursos de Bacharelado em Sistemas de Informação e do Curso Superior de Tecnologia em Gestão da Tecnologia for Requirements Engineering Foundation Level dado pelo IBQTS Brasil Licensed Examination Institute como Licensed Examination Institute do IREB International 7 Análise e Desenvolvimento de Sistemas 1º semestre 77 Apresentação Objetivos Competências da disciplina A grande maioria dos bancos de dados são armazenados e acessados através de um software denominado Sistema Gerenciador de Banco de Dados SGBD O SGBD possui recursos que permitem uma interação do usuário e a manipulação das informações do banco de dados Temos como exemplos de SGBD o SQL Server Oracle MySQL e o PostgreSQL Em um SGBD o modelo de dados mais utilizado para representar e armazenar os dados é o modelo relacional no qual as estruturas são representadas por tabelas compostas por linhas e colunas formando as tuplas Uma vantagem principal do SGBD é a persistência dos dados porém ele possui outras propriedades que são muito importantes abstrações de dados escalabilidade durabilidade consistência e controle de concorrência entre outras características Um banco de dados BD é uma coleção ou conjunto de dados interrelacionados com uma estrutura regular que é armazenado de forma organizada para serem utilizados em situações um determinado contexto e que pode ser armazenado Podemos controle de estoque em uma empresa Fundamentos de Banco de Dados 1º Semestre 8 Introdução Existem muitos tipos de banco de dados e eles estão presentes em nosso diaadia quando você vai ao supermercado quando envia uma mensagem para alguém pelo celular quando lê seus emails Todas estas informações são armazenadas em bancos de dados e é o que estudaremos neste material Segundo Rangel et al 2014 Os bancos de dados são amplamente utilizados e constituem a parte essencial de quase todas as empresas independentemente do seu ramo de atividade A importância dos bancos de dados foi impulsionada nos últimos anos devido ao crescimento das aplicações web das implantações de ERPs Enterprise Resourcing Process de BI Businnes Intelligence dentre outras Todas estas informações são dependentes de bancos de dados pois demandam grandes volumes de dados para serem armazenados e recuperados sem contar mecanismos de recuperação em caso de falhas Mas existe diferença entre informação e dados É de fundamental importância conhecer a diferença entre estes dois conceitos De acordo com Rangel et al 2014 Os dados são considerados exemplo todas as mensagens enviadas pelo Twitter em 1 minuto que segundo Domo 2018 são da ordem de 456mil por minuto Certamente há muita informação nestas mensagens twits mas primeiro é necessário que se faça um tratamento delas Da mesma forma pense em quantas compras são registradas por dia em um rede de lojas como o Carrefour ou o Walmart Todos são dados brutos precisando ser lapidados Estes dados lapidados são a informação como por exemplo Quanto se vendeu de sabão em pó hoje na rede de lojas ou no caso do twitter os trending topics Um exemplo dos Trending Topics Figura 1 Trending Topics Brazil 20032018 15h19 TRENDS24 2018 Para se conseguir extrair tais informações de um número tão grande de dados é preciso Antes do uso dos SGBDs Sistemas Gerenciadores de Banco de Dados as empresas armazenavam seus dados em sistemas de arquivos que não tinham a capacidade nem de compartilhamento nem de proteção a estes dados Um bom exemplo foram os inúmeros sistemas desenvolvidos em linguagem COBOL E por falar em COBOL você já ouviu falar em Bug do Milênio Foi uma falha no tratamento das datas nos programas desenvolvidos antes do ano 2000 Os programas desenvolvidos em 9 Análise e Desenvolvimento de Sistemas 1º semestre 9 linguagem COBOL foram muito provavelmente os que tiveram a maior quantidade de erros a serem corrigidos As datas eram armazenadas em texto no formato YYMMDD ou seja o réveillon de 2000 teríamos 991231 e 000101 tornando todos os cálculos com datas incorretos Em um SGBD e em todos os programas que fazem acesso aquele dado Mas e o que são os SGBDs São os softwares que gerenciam e guardam os dados dentre os quais podemos destacar o Oracle SQL Server Postgree MySQL Firebird etc Os softwares citados são apenas os relacionais já que existem diversos tipos de SGBD sendo estes os mais utilizados atualmente e fruto de avaliação neste material Para criar um banco de dados em um SGBDR Sistema Gerenciador de Banco de Dados Relacional precisamos criar um projeto que possui três níveis de abstração Conceitual Lógico e Físico O nível conceitual é composto pelo Projeto Conceitual que é o Modelo Entidade Relacionamento utilizandose o Diagrama EntidadeRelacionamento onde estará o nível mais alto de abstração do projeto e nenhum SGBD deve ser levado em consideração Posteriormente baseado neste projeto conceitual será elaborado o projeto lógico que está situado no modelo Relacional portanto fazendo uso do Esquema de Relações do Banco de Dados as quais devem ser aplicadas as regras de normalização para eliminação das redundâncias que possam haver Neste nível um SGBDR já pode ser considerado pois há pequenas diferenças entre eles que precisam ser levadas em conta eliminando alguns elementos sem causar perda de informação nas entidades e nas relações RANGEL et al 2014 Estas regras de normalização são chamadas de formas normais e são em um total de 6 sendo 1FN Primeira Forma Normal 2FN Segunda Forma Normal 3FN Terceira Forma Normal FNBC Forma Normal de Boyce Codd 4FN Quarta Forma Normal 5FN Quinta Forma Normal Findas estas fases iniciase o projeto físico que é elaboração dos scripts de construção das tabelas no SGBDR selecionado Baseandose então no Projeto Lógico que contém o esquema de relações do banco de dados criase o script em Linguagem SQL no dialeto do SGBDR escolhido para em seguida aplicálo e criar efetivamente o conjunto de tabelas A Linguagem SQL Structure Query Language ou Linguagem Estruturada de Consulta é a que se utiliza para criação e manutenção dos bancos de dados relacionais Ela está subdividida em três a saber DML Data Manipulation Languagem ou Linguagem de Manipulação dos Dados DCL Data Control Language ou Linguagem de Controle de Dados banco de dados como por exemplo a criação das tabelas e índices objetivam mecanismos para manipular e gerenciar o banco de dados permitindo assim que sejam aos dados do banco de dados com o gerenciamento de usuários e a criação de regras para realização Glossário de Conceitos 1 Atributo abstração de uma propriedade de uma entidade ou de um relacionamento 2 Banco de Dados sistema de armazenamento de dados cujo objetivo é registrar e guardar Fundamentos de Banco de Dados 1º Semestre 10 informações importantes que poderão ser acessadas quando necessário 3 BI Business Intelligence ou Inteligência de Negócios utiliza conceitos em que as informações são coletadas armazenadas e analisadas tendo como base fatos reais eou hipóteses Esses sistemas auxiliam na gestão organizacional e no processo de tomada de decisões 4 Dado atômico tipo de dado considerado básico ou seja indivisível 5 Dado não atômico tipo de dado considerado complexo divisíveis fragmentados 6 Entidade abstração de um fato do mundo real para o qual se deseja manter seus dados no banco de dados 7 ERPs são sistemas de gestão empresarial que possibilitam a integração de todos os dados e 8 Gerenciamento de Banco de Dados utiliza Sistemas Gerenciadores de Banco de Dados SGBDs 9 Modelagem Conceitual nível mais alto de abstração cujo objetivo é representar os requisitos de dados do domínio da aplicação independente do modelo de banco de dados 10 Modelagem Lógica representação da modelagem conceitual em um modelo de banco de dados 11 Modelagem Física constitui um esquema SQL para a modelagem lógica depende exclusivamente do SGBD 12 Relacionamento abstração de uma associação entre ocorrências de entidades 13 Sistema Gerenciador de Banco de Dados SGBD coleção de programas responsáveis pela criação e manutenção de banco de dados RANGEL et al 2014 Perspectiva Histórica Com o passar do tempo as empresas descobriram que a quantidade de dados gerados pelos sistemas de informação aumentava imensamente e que tornavase cada vez mais dispendioso o processo de armazenagem destes dados Desta forma percebeuse que era valido o esforço para Da mesma forma que muitas tecnologias da computação os fundamentos de banco de dados relacionais surgiram na empresa IBM em meados dos anos 1960 e 1970 como fruto de pesquisas por ela desenvolvidas Diversas outras pesquisas desta época culminaram em outros modelos de bancos de dados como os hierárquicos e de rede RANGEL et al 2014 Em 1970 Ted Codd então pesquisador da IBM publicou o primeiro artigo sobre bancos de dados relacionais o qual tratava sobre o uso de cálculo e álgebra relacional Ele procurava o desenvolvimento de um sistema que fosse capaz de acessar as informações com comandos em inglês Como fruto deste artigo a IBM idealizou o projeto System R SANCHES 2005 Este projeto visava criar um sistema de banco de dados relacional que deveria tornarse um produto o que posteriormente ocorreu sendo primeiro o SQLDS e depois o DB2 que ela produz até os dias atuais A linguagem que foi criada pelo projeto SystemR foi a linguagem SQL Structure Query Language que tornouse o padrão para bancos de dados relacionais e atualmente é um padrão ISO International Organization for Standardization RANGEL et al 2014 Os primeiros protótipos foram utilizados por muitas organizações como o MIT Sloan School of Management A IBM no entanto manteve o SystemR em segundo plano por vários e decisivos anos SANCHES 2005 Elison que percebeu uma oportunidade onde outras empresas não haviam visto Ele encontrou uma descrição de um protótipo funcional de um banco de dados relacional e descobriu que nenhuma empresa tinha se empenhado em comercializar essa tecnologia WIKIPEDIA 2010 Ellison e os cofundadores da Oracle Corporation Bob Miner e Ed Oates perceberam que havia um tremendo potencial de negócios ali tornandoa assim uma das maiores empresas de software empresarial do mundo cuja primeira versão comercial foi lançada em 1979 sob o nome de RSI Atualmente chamase Oracle Database e encontrase na versão 12g FARIAS 2018 11 Análise e Desenvolvimento de Sistemas 1º semestre 11 Capítulo 1 Fundamentos de Bancos de Dados Fundamentos de Banco de Dados 1º Semestre 12 1 Fundamentos de Bancos de Dados O que é um banco de dados Por que utilizamos banco de dados De onde surgiram os bancos de dados O que são os Sistemas Gerenciadores de Bancos de Dados e para que eles servem Estas são algumas das questões que se pretende responder neste capítulo Segundo Silberschatz Korth e Sudarshan 2008 um banco de dados é uma coleção de dados inter possível agrupar informações que se relacionam e tratam de um mesmo assunto posso dizer que tenho um banco de dados 11 Bancos de Dados Segundo Date 2000 Em essência um sistema de bancos de dados é apenas um sistema computadorizado de armazenamento de registros O banco de dados pode ele próprio ser visto como o equivalente eletrônico de um armário de arquivamento De acordo com Elmasri e Navathe 2011 os bancos de dados são componentes essenciais em nossa vida cotidiana presente na maioria as atividades e aplicativos que envolvem algum tipo de manipulação de informações Por exemplo quando você consulta as suas notas ou suas faltas quando vai até a biblioteca e pega um livro emprestado ou quando compra um produto pela internet ou mesmo em várias lógicas físicas tais como as grandes redes como Magazine Luíza ou Casas Pernambucanas Estas operações são exemplos do que podemos chamar de aplicações de bancos de dados tradicionais em que a maior parte da informação é armazenada como textos ou números de forma estruturada EMASRI NAVATHE 2011 O crescimento do uso de computadores está intimamente relacionado a utilização de bancos de dados pelos sistemas computacionais O termo banco de dados é tão utilizado que precisa NAVATHE 2011 Já por dados podemos tomar quaisquer fatos conhecidos que possam ser armazenados telefones e emails EMASRI NAVATHE 2011 Segundo Rangel et al 2014 É importante que você entenda a diferença entre dados e informações Os dados são considerados fatos brutos o que indica que os fatos ainda não foram informações Desta forma os bancos de dados começaram a crescer e o volume de dados tornava trabalhoso e dispendioso sua manutenção A IBM iniciou um grupo de pesquisa denominado SystemR para que posteriormente pudesse se tornar um produto Um de seus pesquisadores Ted Codd publicou um artigo descrevendo detalhadamente como deveriam ser o uso de cálculos e álgebra relacional Um dos leitores deste artigo era Larry Elison que posteriormente seria um dos fundadores da Oracle o primeiro SGBDR Sistema Gerenciador de Banco de Dados Relacional comercial e atualmente um dos principais do mercado FARIAS 2018 12 Sistema Gerenciador de Bancos de Dados Um SGBD Sistema Gerenciador de Banco de Dados é uma coleção de programas que compartilhamento de dados entre aplicações diversas e seus usuários EMASRI NAVATHE 2011 São várias as características que distinguem o funcionamento de um SGBD em relação 13 Análise e Desenvolvimento de Sistemas 1º semestre 13 ao modus operandi anterior a eles com uso de arquivos Quando se trabalha com arquivos cada aplicação EMASRI NAVATHE 2011 Um bom exemplo destes tipos de sistemas foram os programas em COBOL Common Business Oriented Language ou Linguagem Comum Orientada para os Negócios que foi uma linguagem de programação orientada ao processamento de bancos de dados comerciais O COBOL foi criado no segundo semestre de 1959 A linguagem possui várias versões de padronização sendo a última em 2002 que substituiu a versão do COBOL85 1985 WIKIPEDIA 2004 Os programas em COBOL como a versão Microbase brasileira trabalhavam com arquivos próprios basicamente texto ASCII que podia ser acessado por qualquer editor de texto e ter seus de fornecer Por exemplo em COBOL a organização de arquivos indica como os registros são organizados em um arquivo podendo ser sequencial ou indexado Cada modo de organização podia ter na estrutura de um arquivo todos os programas que fazem acesso aquele arquivo independente da Bug do Milênio onde mesmo arquivos que não utilizassem as datas se faziam acesso a um arquivo 01 IDENTIFICATION DIVISION 02 PROGRAMID HELLO 03 04 ENVIRONMENT DIVISION 05 INPUTOUTPUT SECTION 06 FILECONTROL 07 SELECT STUDENT ASSIGN TO OUT1 08 ORGANIZATION IS SEQUENTIAL 09 ACCESS IS SEQUENTIAL 10 FILE STATUS IS FS 11 Fundamentos de Banco de Dados 1º Semestre 14 12 DATA DIVISION 13 FILE SECTION 14 FD STUDENT 15 01 STUDENTFILE 16 05 STUDENTID PIC 95 17 05 NAME PIC A25 18 05 CLASS PIC X3 19 20 WORKINGSTORAGE SECTION 21 01 WSSTUDENT 22 05 WSSTUDENTID PIC 95 23 05 WSNAME PIC A25 24 05 WSCLASS PIC X3 25 26 PROCEDURE DIVISION 27 OPEN EXTEND STUDENT 28 MOVE 1000 TO STUDENTID 29 MOVE Tim TO NAME 30 MOVE 10 TO CLASS 15 Análise e Desenvolvimento de Sistemas 1º semestre 15 31 WRITE STUDENTFILE 32 ENDWRITE 33 CLOSE STUDENT 34 STOP RUN Listagem 1 Programa em COBOL TUTORIALSPOINT 2018 Percebese então que o controle de redundância de dados de segurança da informação e como solução mais robusta e indicada Entretanto não se deve usar SGBDs indiscriminadamente 13 Quando não utilizar um Sistema Gerenciador de Bancos de Dados Em algumas situações como em aplicações muito simples e estáveis provavelmente a utilização do SGBD tornea demasiadamente complicada fazendo com que se perca sua simplicidade Segundo Elmasri e Navathe 2011 p 17 Apesar das vantagens de usar um SGBD existem algumas situações em que esse sistema pode envolver custos adicionais desnecessários que não aconteceriam no processamento de arquivos tradicional Os custos adicionais quando da utilização de um SGBD devemse aos seguintes fatores Alto investimento inicial em hardware software e treinamento Esforço adicional para oferecer funções de segurança controle de concorrência recuperação e integridade ELMASRI NAVATHE 2011 Desta forma pode ser mais vantajoso utilizar sistemas de arquivos nas seguintes situações Requisitos rigorosos de tempo real para alguns programas de aplicação que podem ser atendidos devido as operações extras executadas pelo SGBD Sistemas embarcados com capacidade de armazenamento limitada onde um SGBD de uso geral não seria indicado Nenhum acesso de múltiplos usuários aos dados ELMASRI NAVATHE 2011 Fundamentos de Banco de Dados 1º Semestre 16 Capítulo 2 Sistema de Banco de Dados 17 Análise e Desenvolvimento de Sistemas 1º semestre 17 2 Sistema de Banco de Dados A arquitetura dos SGBDs evolui constantemente Essa evolução espelha as mudanças que ocorrem na computação que evoluiu de grandes mainframes para servidores web e de banco de dados Uma arquitetura básica de um SGBD é a clienteservidor onde um módulo é o cliente e é executado na estação do usuário estação cliente e outro módulo é executado no servidor servidor de banco de dados 21 Modelos de dados esquemas e instâncias Uma característica fundamental de um banco de dados é a possibilidade de se obter abstração de dados em algum nível Elmasri e Navathe 2011 p 19 destacam que A abstração de dados geralmente se refere a supressão de detalhes da organização e armazenamento de dados destacando recursos essenciais para um melhor conhecimento desses dados Assim é possível num organização dos dados Outra característica é a de que os bancos de dados fornecem esta abstração de dados no nível de detalhamento ideal para cada tipo de usuário que estão armazenadas em um banco de dados Por exemplo para uma escola o modelo de dados poderia informar que o banco de dados armazena informações sobre alunos e que para cada aluno são armazenados o RA Registro do Aluno nome endereço telefone e email É importante salientar que o modelo de dados não informa quais alunos estão armazenados mas que o banco de dados armazena informações sobre os alunos Surgiram assim vários modelos de dados tais como Rede Hierárquico ou Relacional Todo SGBD deve suportar um modelo que permita a representação dos dados de uma realidade FANDERUFF 2003 211 Modelo hierárquico Figura 2 Modelo de Banco de Dados Hierárquico 212 Modelo de rede de 1970 Sua forma de organizar os dados é utilizando uma estrutura formada por várias listas FANDERUFF 2003 Similar ao modelo hierárquico os dados de rede são organizados em tipos de registros e ligações entre dois tipos de registro Não existe restrição hierárquica FANDERUFF 2003 p 5 O modelo hierárquico surgiu nos anos de 1960 e os dados são organizados em formato de hierarquias ou árvores Neste modelo os nós das hierarquias possuem ocorrências de registros sendo que cada registro é uma coleção de atributos onde cada atributo contém somente uma informação O primeiro registro da hierarquia é o registropai e todos os demais são denominados de Fundamentos de Banco de Dados 1º Semestre 18 Ainda segundo a autora uma rede é portanto um conjunto ilimitado de nós Não há o sentido de raiz e uma desvantagem é o fato de que caso o banco de dados tenha muitos tipos de entidades pode resultar em esquemas complexos de relacionamentos Um esquema deste tipo de Figura 3 Banco de Dados de Rede 213 Modelo relacional era System R Baseado neste projeto surgiu a primeira versão da Linguagem SQL Structured Query Language ou Linguagem Estruturada de Consulta e que é utilizada até os dias atuais pelos SGBDs Relacionais cujos exemplos mais famosos podemos citar o Oracle o SQL Server e o DB2 dentre os de cunho proprietário e o MariaDB Postgree e Firebird dentre os Free Livres FANDERUFF 2003 de dados relacionais visam eliminar a redundância e é o mais utilizado pelo mercado nos dias atuais Figura 4 Banco de Dados Relacional 19 Análise e Desenvolvimento de Sistemas 1º semestre 19 22 Categorias de modelos de dados conceitos que utilizam para descrever a estrutura do banco de dados Por exemplo para Elmasri e Navathe 2011 p20 os Modelos de dados de alto nível ou Modelos Conceituais oferecem conceitos os Modelos de dados de baixo nível ou físicos oferecem conceitos que descrevem os detalhes de como os dados são armazenados no computador Estes são os extremos mas entre eles está uma classe de modelos de dados representativos muito longe do modo como os dados são organizados e armazenados pelo computador ELMASRI NAVATHE 2011 p 20 Os modelos de dados conceituais utilizam os conceitos de entidades atributos e relacionamentos Segundo Emasri e Navathe 2011 uma entidade representa um objeto ou conceito do mundo real como por exemplo um funcionário um produto ou um veículo os atributos representam as propriedades de interesse de cada entidade e os relacionamentos representam associações entre duas ou mais entidades ELMASRI NAVATHE 2011 23 Transações Segundo Silberschatz Korth e Sudarshan 2006 uma transação é uma unidade de execução do programa que acessa e possivelmente atualiza vários itens de dados Para garantir a integridade dos dados é necessário que o sistema de banco de dados mantenha as seguintes propriedades das transações Atomicidade Em uma transação envolvendo duas ou mais partes de informações discretas ou a transação será executada totalmente ou não será executada garantindo assim que as transações sejam atômicas Consistência A transação cria um novo estado válido dos dados ou em caso de falha retorna todos os dados ao seu estado antes que a transação foi iniciada Isolamento Uma transação em andamento mas ainda não validada deve permanecer isolada de qualquer outra operação ou seja garantimos que a transação não será interferida por nenhuma outra transação concorrente Durabilidade Dados validados são registados pelo sistema de tal forma que mesmo no caso de uma falha eou reinício do sistema os dados estão disponíveis em seu estado correto SILBERSCHATZ KORTH SUDARSHAN 2006 Uma transação é criada quando se executam comandos de manipulação de dados da transação podem haver um ou vários destes comandos combinados Neste caso a transação deve ser formalmente iniciada com o comando START TRANSACTION que somente pode ser encerrada com os comandos COMMIT ou ROLL BACK Quando todos os comandos da transação são executados com sucesso o comando COMMIT erro acontecer o comando ROLL BACK é emitido e o banco de dados retorna ao estado inicial antes 01 sid transactionsavepoint Fundamentos de Banco de Dados 1º Semestre 20 02 try início do bloco protegido 03 bsave Poderia lançar uma exceção 04 transactionsavepointcommitsid 05 except IntegrityError 06 transactionsavepointrollbacksid 07 csave Sucesso e asave não será desfeita Listagem 2 Transação em Python django Observando o código na listagem 02 percebese que existe um bloco protegido try except Na linha 1 está o comando que inicia a transação Na linha 2 o comando de início do bloco aconteça algum problema ou erro durante a execução da linha 4 como por exemplo falha da rede o bloco protegido desviará o processamento para a linha 6 exceção e o comando ROLL BACK então será emitido Em uma transação seja qual for o seu encerramento com COMMIT ou com ROLL BACK o mesmos dados assim se dados forem incluídos e transação for encerrada com COMMIT eles estarão inseridos no banco de dados e disponíveis para os demais usuários e por outro lado se a transação for encerrada com ROLL BACK os dados não terão sido inseridos O mesmo raciocínio vale para Figura 5 Esquema de Transações no Banco de Dados 21 Análise e Desenvolvimento de Sistemas 1º semestre 21 24 Arquitetura de três esquemas De acordo com Emasri e Navathe 2011 as três das quatro características importantes da abordagem de banco de dados são Uso de um catálogo para armazenar a descrição esquema tornandoo assim autodescritivo Isolamento de programas e dados Suporte para múltiplas visões do usuário A arquitetura de três esquemas tem por objetivo separar as aplicações do usuário do banco durante um projeto de banco de dados O nível interno tem um esquema interno que descreve a estrutura do armazenamento físico do banco de dados O esquema interno usa um modelo de dados físico e descreve os detalhes completos do armazenamento de dados e caminhos de acesso para o banco de dados O nível conceitual tem um esquema conceitual que descreve a estrutura do banco de dados inteiro para uma comunidade de usuários O esquema conceitual oculta os detalhes das estruturas de armazenamento físico e se concentra na descrição de entidades tipos de dados relacionamentos operações do usuário e restrições Normalmente um modelo de dados representativo é usado para descrever o esquema conceitual quando um sistema de banco de dados é implementado O nível externo ou de visão inclui uma série de esquemas externos ou visões do usuário Cada esquema externo descreve a parte do banco de dados em que um grupo de usuários em particular está interessado e oculta o restante do banco de dados do grupo de usuários De forma semelhante ao nível conceitual cada esquema externo é comumente implementado usando um modelo de dados representativo baseado em um projeto de esquema externo ELMASRI NAVATHE 2011 p 22 Devido a arquitetura de três esquemas permite que um usuário possa visualizar os níveis de esquema em um sistema de banco de dados Segundo Elmasri e Navathe 2011 A maioria dos SGBDs não separa os três níveis completa e explicitamente mas dá suporte a eles de alguma forma É importante destacar que os três esquemas são apenas descrições dos dados pois os dados realmente armazenados estão no nível físico Se a solicitação for uma recuperação os dados extraídos do banco de dados armazenado devem ser reformatados para corresponder à visão externa do usuário ELMASRI NAVATHE 2011 Os processos de transformação e os resultados entre os níveis são chamados de mapeamentos Figura 6 A arquitetura de três esquemas Fundamentos de Banco de Dados 1º Semestre 22 241 Independência dos dados Podese dizer que é possível efetuar alterações no esquema ou no nível de um banco de dados sem alterar um nível superior A arquitetura de três esquemas pode ser utilizada para ser usada para explicar melhor o conceito de independência de dados Independência lógica de dados Permite alterar apenas o nível conceitual não havendo nenhuma alteração no nível externo ou nas aplicações do usuário Independência física de dados Permite alterar o nível interno sem ter que alterar o nível conceitual nível externo ou as aplicações do usuário 23 Análise e Desenvolvimento de Sistemas 1º semestre 23 Capítulo 3 Modelagem Conceitual Fundamentos de Banco de Dados 1º Semestre 24 3 Modelagem Conceitual A modelagem conceitual é a representação de uma porção da realidade através de um modelo conceitual que a represente e mantenha conexão com a realidade existente Neste capítulo serão estudados os conceitos de modelo conceitual e sua representações 31 Modelos em Geral que representa um fenômeno ou conjunto de fenômenos complexos e permite compreendêlos e proverlhes a evolução HOUAISS 2009 mental de um objeto abstrato ou concreto que se mostra como um instrumento fundamental do da realidade HOUAISS 2009 contém todos os detalhes delas sequer contém o traçado idêntico aos das linhas reais como pode ser todas as pessoas Um modelo conceitual pode ou não ter um padrão visual Um mapa mental por exemplo ali representados são reais e não foram inventados Entretanto um mapa mental não contém um padrão visual já que ele pertence a uma única pessoa e as pessoas os criam de formas diferentes devem ser projetados utilizandose um modelo conceitual em notação que possua um padrão visual Figura 7 Mapa do Metrô de São Paulo METRO 2018 25 Análise e Desenvolvimento de Sistemas 1º semestre 25 32 Modelos Conceituais Segundo Heuser 2009 p 25 um modelo conceitual é uma descrição do banco de dados de forma independente de implementação em um SGBD O modelo conceitual registra que dados podem aparecer no banco de dados mas não registra como estes dados estão armazenados comportamento de um software A partir deste modelo é que o software será criado o que facilita o seu entendimento e seu projeto uma vez que com características principais erros de programação de projeto e de funcionamento serão evitados WIKIPEDIA 2004 De acordo com Elmasri e Navathe 2011 p 132 A modelagem conceitual é uma fase muito importante no projeto de uma aplicação de banco de dados bemsucedida Geralmente o termo aplicação de banco de dados referese a um banco de dados em particular e aos programas relacionados que implementam as consultas e atualizações dele Para se modelar um banco de dados utilizase o modelo EntidadeRelacionamento MER que é um modelo de dados conceitual popular de alto nível Esse modelo e suas variações costumam ser utilizados para o projeto conceitual de aplicações de banco de dados e muitas ferramentas de projeto de banco de dados empregam seus conceitos Ao se empregar o MER criase o Diagrama EntidadeRelacionamento DER Entretanto a metodologia de modelagem de objetos como a dados onde se utiliza o diagrama de classes ELMASRI NAVATHE 2011 O uso de modelos conceituais para projeto de banco de dados é largamente empregado A primeira etapa do projeto de um banco de dados é o levantamento e análise de requisitos De requisitos de usuário e de sistema em um documento de requisitos Idealmente os requisitos de usuário e de sistema devem ser claros inequívocos de fácil compreensão completos e consistentes funcionais e não funcionais e que devem ser compreensíveis para os usuários do sistema que não tenham conhecimentos técnicos O resultado desta etapa é um conjunto de requisitos dos usuários escrito de forma concisa ELMASRI e NAVATHE 2011 que pode ser chamado de minimundo O documento de requisitos não deve conter detalhes de arquitetura ou projeto do sistema Por este motivo não utilize jargões de software notações estruturadas ou formais SOMMERVILLE 2011 Um requisito é um aspecto que o sistema proposto deve fazer ou uma restrição no desenvolvimento do sistema De acordo com Sommerville 2011 pp 6566 os requisitos de sistema são versões expandidas dos requisitos de usuário Eles acrescentam detalhes e explicam como os requisitos de usuário devem ser atendidos pelo sistema Os requisitos de sistema devem descrever apenas o comportamento externo do sistema e suas restrições operacionais e não devem se preocupar como o sistema será projetado ou implementado Já os requisitos de usuário são quase sempre escritos em linguagem natural que no caso do Brasil é em português e se necessário acompanhados de diagramas ou tabelas para facilitar a compreensão SOMMERCILLE 2011 dados é útil determinar os conhecidos requisitos funcionais da aplicação Assim que os requisitos estiverem todos levantados a próxima etapa então será a criação do modelo conceitual Os mesmos O esquema conceitual é uma descrição concisa dos requisitos de dados dos usuários e inclui detalhes dos tipos de entidade relacionamentos e restrições estes são expressos usando os conceitos fornecidos pelo modelo de dados de alto nível A etapa seguinte no projeto de um banco de dados é a implementação real do próprio banco de dados utilizando um SGBD Essa etapa é chamada de modelo lógico ou mapeamento do modelo de dados Ela tem como resultado um esquema de banco de dados no modelo de dados da implementação do SGBD ELMASRI NAVATHE 2011 Fundamentos de Banco de Dados 1º Semestre 26 internas organização de arquivo índices caminhos de acesso e parâmetros físicos do projeto para 27 Análise e Desenvolvimento de Sistemas 1º semestre 27 Capítulo 4 Modelo Entidade Relacionamento Fundamentos de Banco de Dados 1º Semestre 28 4 Modelo EntidadeRelacionamento A modelagem conceitual é muito importante no projeto de uma aplicação de banco de dados bemsucedida ELMASRI NAVATHE 2011 p 131 O Modelo EntidadeRelacionamento é um modelo de alto nível criado com o objetivo de representar a semântica associada aos dados do minimundo O MER é utilizado na fase de projeto conceitual onde se cria o esquema conceitual do banco de dados Utiliza conceitos intuitivos permitindo assim aos projetistas de banco de dados capturar os conceitos associados aos dados dados O esquema conceitual é criado usandose o MER chamase Diagrama Entidade Relacionamento DER MER conjunto de conceitos e elementos de modelagem que o projetista do banco de dados precisa conhecer DER Resultado do processo de modelagem executado pelo projetista de dados que conhece o ME R O MER é a técnica de modelagem de dados mais difundida e utilizada o DER foi criado em 1976 por Peter Chen e pode ser considerada de fato como um padrão para modelagem conceitual HEUSER 2009 41 Entidades O conceito fundamental da abordagem ER é o conceito de entidade HEUSER 2009 Entretanto o MER descreve os dados além das entidades como relacionamentos e atributos ELMASRI NAVATHE 2011 Uma entidade representa no modelo conceitual um conjunto de objetos ou de entidades como sugere o nome da realidade modelada Estas entidades tem também uma existência independente ELMASRI NAVATHE 2011 HEUSER 2009 A entidade pode ser uma coisa física como um carro ou uma pessoa ou conceitual como um cargo uma empresa ou um pedido de compras ELMASRI NAVATHE 2011 Cada entidade possui atributos que nada mais são do que suas características Por exemplo uma entidade PRODUTO pode ser descrita pelo seu nome fabricante preço de custo preço de venda e quantidade em estoque e para cada atributo a entidade terá um valor Os valores de cada atributo de entidade tornamse parte importante dos dados que serão armazenados no banco de dados ELMASRI NAVATHE 2011 atributos nome código RG CPF endereço idade telefone residencial e salário Seus valores são respectivamente João da Silva 2222 12345678 09876543210 Rua Goiás 711 São Paulo SP 1301100 55 713749 e 120000 Em um DER podem ocorrer vários tipos de atributos simples versus composto valor único versus valor multivalorado e armazenado versus derivado ELMASRI NAVATHE 2011 29 Análise e Desenvolvimento de Sistemas 1º semestre 29 Figura 9 Atributos de uma entidade De forma geral os atributos univalorados atributos simples são representados no DER Figura 10 Atributo simples 411 Atributos Compostos Atributos compostos podem ser subdivididos em subpartes menores Cada uma destas 2011 O exemplo mais clássico deste tipo de atributo é muito provavelmente o endereço que muitas pessoas chamam de endereço completo O que vem a ser um endereço É um atributo que pode ser decomposto em atributos menores como por exemplo nome do logradouro número do imóvel complemento no caso de apartamentos e similares nome do bairro nome da cidade nome do estado e o CEP SP 1301100 que pode ser decomposto em Tipo do Logradouro Rua Nome do Logradouro Goiás Número 711 Cidade São Paulo Estado SP e o CEP 1301100 Os atributos compostos podem formar uma hierarquia como por exemplo o Logradouro ser subdividido em três atributos simples Tipo do Logradouro Nome do Logradouro e Número O valor de um atributo composto é a concatenação dos valores de todos os seus atributos simples ELMASRI NAVATHE 2011 Concatenação é um termo usado em computação para designar a operação de unir o conteúdo de duas strings Por exemplo considerando as strings Alex e Andre a concatenação da primeira com a segunda gera a string Alexandre WIKIPEDIA 2008 Modelase um atributo como composto quando o projetista referese a ele hora como uma unidade hora como um dos seus subcomponentes Se a referência ao atributo for sempre como unidade não há a necessidade modelálo como atributo composto ELMASRI NAVATHE 2011 Fundamentos de Banco de Dados 1º Semestre 30 Figura 11 Esquema de um atributo composto Um atributo composto é representado no DER por um conjunto de elipses com borda Figura 12 Atributo Composto 412 Atributos Multivalorados A grande maioria dos atributos possui um único valor para uma determina entidade como e um nome João da Silva para o atributo nome Estes valores são chamados de valores únicos Por exemplo o CPF é um valor único de uma pessoa Entretanto em alguns casos o atributo pode ter mais de um valor sendo então um atributo multivalorado Podese citar como exemplo as cores Telefone e email que uma mesma pessoa pode ter mais de um Um atributo multivalorado no DER é representado por uma elipse de bordas duplas como Figura 13 Atributo Multivalorado 31 Análise e Desenvolvimento de Sistemas 1º semestre 31 Figura 14 Carro com duas cores Figura 15 Cadastro de pessoa física com quatro referências comerciais ELMASRI NAVATHE 2011 413 Atributos Derivados Em alguns casos dois ou mais valores de atributos estão relacionados como por exemplo pode ser determinada calculada utilizandose a data atual data de hoje e a data de nascimento obtendo assim a idade em anos meses e dias Desta forma o atributo idade é chamado de atributo derivado enquanto que a data de nascimento é considerada um atributo armazenável ELMASRI NAVATHE 2011 Alguns atributos derivados podem ser obtidos com o relacionamento de atributos de diferentes entidades como por exemplo obter o número de funcionários que trabalham em um determinado departamento ELMASRI NAVATHE 2011 No DER um atributo derivado é representado por uma elipse de bordas tracejadas como Figura 16 Atributo Derivado 414 Valores Nulos Certas vezes uma determinada entidade pode não ter um valor para ser aplicado a um email sobretudo as mais idosas Outro exemplo pode ser a Formação Acadêmica uma vez que ainda existem pessoas analfabetas Para estas situações foi criado um valor especial chamado NULL ELMASRI NAVATHE 2011 podem receber o valor NULL NULL pode ser aplicado quando a informação está faltando quando se desconhece a informação ou quando a informação não é aplicável Na primeira situação por exemplo se uma pessoa não tem o número de telefone no momento do preenchimento do cadastro o segundo poderia ser um paciente que chega desacordado a uma unidade de emergência e sem solicitarse o número da reservista serviço militar para uma mulher que pode mas não é obrigada a alistarse portanto a grande maioria não teria este documento Fundamentos de Banco de Dados 1º Semestre 32 42 Tipos de Entidades Um banco de dados em geral contém grupos de entidades que são semelhantes ELMASRI NAVATHE 2011 p 136 Por exemplo uma escola que possui centenas de alunos pode desejar armazenar informações semelhantes relacionadas a seus alunos As entidades dos alunos compartilham os mesmos atributos mas cada uma tem os próprios valores para cada atributo os mesmos atributos Cada Tipo de Entidade no banco de dados é descrito por seu nome e atributos ELMASRI NAVATHE 2011 p 136 Tipo de Entidade junto com os valores para cada um de seus atributos A coleção de todas as entidades individuais de determinado tipo de entidade no banco de dados em qualquer ponto no tempo é chamada de conjunto de entidades ELMASRI NAVATHE 2011 p 136 No DER um Tipo de Entidade é representada por um retângulo e deve ter como nome um substantivo no singular como Funcionário ou Filme Figura 17 Tipos de Entidades Entidades e valores dos Atributos 421 Atributoschave de um Tipo de Entidade Um Tipo de Entidade possui uma restrição importante chamada de restrição de exclusividade sobre os atributos Esta restrição é obtida através do atributochave De acordo com ELMASRI NAVATHE 2011 p 137 Um tipo de entidade normalmente tem um ou mais atributos cujos valores são distintos para cada entidade individual no conjunto de entidades Esse atributo é denominado atributochave e seus Voltando ao exemplo do Tipo de Entidade ALUNO citado no item 42 podese utilizar o RA Registro Acadêmico ou Registro do Aluno como atributo chave do Tipo de Entidade ALUNO uma vez que cada aluno tem seu próprio RA e eles não se duplicam Da mesma forma outro atributo que poderia ser usado como atributochave é o CPF do aluno Entretanto como pode haver um aluno que não possua o CPF ou em caso de irmão que utilizassem o CPF do pai ou da mãe este atributo poderia causar erros ao ferir a restrição de exclusividade exigida Em algumas situações existem Tipos de Entidades que podem ter mais de um atributo chave Como exemplo podese ter um Tipo de Entidade PESSOA que tenho como atributos o RG o forma única cada uma das entidades Pessoas do Tipo de Entidade Desta forma se faz necessário a utilização de dois atributos chave RG e Local de Expedição pois o RG é um documento estadual e seu número pode ser duplicado em diferentes estados mas ao unilo ao Local de Expedição tornase 33 Análise e Desenvolvimento de Sistemas 1º semestre 33 ELMASRI NAVATHE 2011 Cada um dos atributoschave de um Tipo de Entidade no DER são representados por uma Entidade com seus atributos Figura 18 Atributochave Figura 19 Tipo de Entidade e Atributos 43 Tipos de Relacionamento Em um projeto de banco de dados existem vários relacionamentos explícitos entre os diversos tipos de entidade pois toda vez que um atributo de um tipo de entidade se refere a outro atributo de outro tipo de entidade existe um relacionamento Como exemplo podemos citar o DEPARTAMENTO em que o EMPREGADO trabalha Ele referencia em qual departamento um determinado empregado trabalha Desta forma um tipo de relacionamento R entre n tipos de entidade E1 E2 En relacionamento entre dois tipos de entidades ELMASRI NAVATHE 2011 Figura 20 Relacionamento entre dois Tipos de Entidade O grau de um tipo de relacionamento é o número do tipo de entidades participantes Fundamentos de Banco de Dados 1º Semestre 34 e DEPARTAMENTO Um tipo de relacionamento de grau dois é chamado de binário e um de grau três Figura 21 Relacionamento com grau 3 três Figura 22 Tipo de Relacionamento 431 Relacionamentos como atributos Em algumas situações é conveniente pensar em um tipo de relacionamento em termos 22 podese pensar em um atributo chamado Departamento do tipo de entidade FUNCIONÁRIO em que cada valor do atributo Departamento é uma referência à entidade DEPARTAMENTO onde o funcionário trabalha Logo o conjunto de valores possíveis para esse atributo Departamento é o conjunto de todas as entidades DEPARTAMENTO Entretanto quando existe um relacionamento binário sempre há duas opções então o raciocínio for invertido e se colocar um atributo Empregado no tipo de entidade DEPARTAMENTO ele será um atributo multivalorado uma vez que os valores possíveis para este atributo são o conjunto de todas as entidades EMPREGADO ELMASRI NAVATHE 2011 432 Nomes de Função e Relacionamentos Recusivos Cada tipo de entidade que participa de um tipo de relacionamento possui um papel EMPREGADO é do de empregado ou trabalhador e o de DEPARTAMENTO é o papel de empregador Entretanto nem sempre a escolha do nome é simples ELMASRI NAVATHE 2011 desempenha em cada instância de relacionamento e ajuda a explicar o que o relacionamento O nome da função não é uma informação obrigatória uma vez que o nome do Tipo de Entidade pode servir como nome de função Entretanto há situações em que um mesmo Tipo de Entidade participa mais de uma vez do mesmo tipo de relacionamento executando funções diferentes Nestes casos a utilização do nome de função tornase obrigatória Este tipo de relacionamento recebe o 35 Análise e Desenvolvimento de Sistemas 1º semestre 35 Figura 23 Relacionamento Recursivo e Nomes de Função 44 Razão de Cardinalidade e Restrição de Participação de instâncias de relacionamentos em que uma entidade pode participar As razões de cardinalidade possíveis são 11 Umparaum 1N UmparaN N1 NparaUm NN NparaN No caso do relacionamento TRABALHAPARA DEPARTAMENTOFUNCIONÁRIO tem razão de cardinalidade 1N UmparaN indicando assim que um Departamento pode estar relacionado com quaisquer número de Empregados mas que um Empregado pode estar relacionado com apenas um Departamento A restrição de cardinalidade para relacionamentos binários são representadas 2011 Figura 24 Relacionamento binário com restrição de cardinalidade de relacionamento em que cada entidade pode participar e as vezes é chamada de restrição de Fundamentos de Banco de Dados 1º Semestre 36 cardinalidade mínima Existem dois tipos de restrição de participação total e parcial Se a então uma entidade de funcionário só pode existir se participar em pelo menos uma instância de relacionamento TRABALHAPARA ELMASRI NAVATHE 2011 p 143 Neste caso a participação de FUNCIONÁRIO em TRABALHAPARA é total já que o conjunto total de funcionários devem estar relacionados e uma entidade DEPARTAMENTO estrutural Figura 25 Restrição de Cardinalidade 1N Figura 26 Restrição de Cardinalidade 11 Figura 27 Restrição de Cardinalidade NN No relacionamento GERENCIA não é esperado que todo funcionário gerencie um departamento tendo assim parte das entidades de FUNCIONARIO relacionadas a uma parte de DEPARTAMENTO Desta forma a participação é parcial Em diagramas EntidadesRelacionamento a participação total é exibida como uma linha dupla que conecta o tipo de entidade participante ao relacionamento enquanto que a participação parcial é representada por uma linha simples ELMASRI NAVATHE 2011 Figura 28 Restrição Estrutural Os Tipos de Relacionamentos também podem ter Atributos Por exemplo para registrar a quantidade de horas trabalhadas por um empregado em um dado projeto Horas pode ser representado como um atributo do relacionamento TRABALHAEM a data em que um gerente começou a gerenciar um departamento DataInício pode ser representado como um atributo do relacionamento GERENCIA Os atributos dos tipos de relacionamento 11 e 1N podem ser migrados para um dos tipos de entidades participantes Em relacionamento 1N o atributo pode ser migrado 11 a decisão de onde colocar o atributo de relacionamento é determinada de maneira subjetiva pelo projetista ELMASRI NAVATHE 2011 37 Análise e Desenvolvimento de Sistemas 1º semestre 37 Para relacionamento MN alguns atributos podem ser determinados pela combinação de entidades participantes em uma instância de relacionamento e não pode haver qualquer entidade de relacionamento Figura 29 Atributo de Relacionamento 1N 45 Tipo de EntidadeFraca Tipos de entidade que não possuem atributoschave próprios são chamado tipos de entidadefraca ELMASRI NAVATHE 2011 p 144 As entidades destes tipos de entidades estão entidade fraca Um tipo de entidadefraca sempre tem restrição de participação total dependência tipos de entidadefraca podem ter uma chaveparcial que é um conjunto de atributos que pode NAVATHE 2011 No DER um tipo de entidadefraca é representado por um retângulo de bordas duplas Figura 30 Tipo de Entidade Fraca 46 Resumo da Notação para Diagramas EntidadeRelacionamento Fundamentos de Banco de Dados 1º Semestre 38 relacionamento abordando todas as possibilidades de representação neste tipo de diagrama Figura 31 Resumo da Notação para o Diagrama EntidadeRelacionamento 39 Análise e Desenvolvimento de Sistemas 1º semestre 39 Figura 32 DER para o esquema EMPRESA Fundamentos de Banco de Dados 1º Semestre 40 Capítulo 5 Modelo EntidadeRelaciona mento Estendido 41 Análise e Desenvolvimento de Sistemas 1º semestre 41 Quase todas as aplicações de bancos de dados podem ser representadas por meio do modelo entidaderelacionamento Entretanto alguns bancos de dados são mais complexos e exigem para sua melhor representação alguns aspectos adi cionais Para solucionar esse problema o modelo ER é expandido para o modelo EER Esse modelo inclui além dos novos conceitos todos os conceitos de modelagem do modelo ER RANGEL et al 2014 p 69 O Modelo EntidadeRelacionamento Estendido inclui todos os conceitos de modelagem existentes no Modelo EntidadeRelacionamento Além disso ele acres centa os conceitos de subclasse e superclasse que estão relacionados aos conceitos Figu ra 33 Notação do EER para representar subclasse e especialização ELMASRI NAVATHE 2011 p 162 O relacionamento entre uma superclasse e qualquer uma de suas subclasses recebe o nome de relacionamento superclassesubclasse Como exemplo pode ser e FUNCIONÁRIOTÉCNICO Em um relacionamento assim uma entidade da sub classe representa a mesma entidade do mundo real que a entidade da superclasse Desta forma podese citar como exemplo que o funcionário EMERSOM FITIPALDI também é o técnico EMERSON FITIPALDI Então embora sendo a mesma entidade o relacionamento é implementado no banco de dados é representada como objetos distintos relacionados através do atributo chave ELMASRI NAVATHE 2011 Em um banco de dados uma entidade não pode existir pelo simples fato de pertencer a uma subclasse assim ela deve pertencer também à superclasse Esta entidade pode ou não ser incluída como membro de uma ou mais subclasses Uma subclasse então herda os atributos existentes na superclasse e desta forma repre senta a mesma entidade do mundo real ELMASRI NAVATHE 2011 Ao conceito de superclasse e subclasse está associado o conceito de herança RANGEL et al 2014 p 70 Fundamentos de Banco de Dados 1º Semestre 42 51 Especialização e Generalização entidade a partir de uma superclasse RANGEL et al 2014 p 70 Este tipo de classe é chamado de tinta das entidades da superclasse ELMASRI NAVATHE 2011 pecialização de FUNCIONÁRIO e que possui um atributo TIPOENG que não existe em FUNCIONÁRIO uma vez que somente engenheiros precisam desta informação 511 Especialização 511 Especialização 511 Especialização 511 Especialização 511 Especialização 511 Especialização uma condição no valor de algum atributo da superclasse RANGEL et al 2014 p 70 Isto acontece especialização de FUNCIONÁRIO Podese observar também como uma entidade da superclasse é a mesma entidade da subclasse que representa uma entidade do mundo real Existem dois motivos principais para incluir relacionamentos de classesub classe e especializações em um banco de dados sendo que o primeiro motivo de vese ao fato de que certos atributos podem ser aplicados a algumas entidades da superclasse mas não a todas e o segundo motivo é que em alguns relacionamentos podem participar apenas algumas das subclasses ELMASRI NAVATHE 2011 512 Generalização RANGEL et al 2014 p 70 Ela pode ser vista ou pensada como o processo reverso da abstração onde as diferenças entre vários tipos de entidades são suprimidas suas características comuns reunidas e ELMASRI NAVATHE 2011 Por exemplo se na especialização ao se deparar com um um tipo de entida CARRO e CAMINHÃO ele poderá fazer o raciocínio invertido agrupandoas em uma 43 Análise e Desenvolvimento de Sistemas 1º semestre 43 165 Segundo Elmasri e Navathe 2011 pp 165166 Uma notação dramática para distinguir generalização de es pecialização é usada em algumas metodologias de projeto Uma seta apontando para a superclasse generalizada representa uma generali zação ao passo que setas apontando para subclasses especializadas representam uma especialização Entretanto a utilização deste tipo de notação não é muito adotada porque a decisão sobre qual processo é seguido em determinada situação costuma ser sub jetiva ELMASRI NAVARTHE 2011 p 166 513 Restrições sobre especialização e generalização De modo geral podem haver diversos tipos de entidade especializadas de uma outra como da mesma forma uma especialização pode consistir em apenas um tipo de entidade É possível de terminar a quantidade de entidades que se tornarão membros das subclasses ou colocar uma condição sobre algum atributo da superclasse Essas subclasses são chamadas de subclas exatamente quais entidades farão parte da subclasse ELMASRI NAVATHE 2011 tem uma condição para determinar os membros das subclasses dizse que esta é Há ainda dois outros tipos de restrição A restrição de disjunção que espe ção ELMASRI NAVATHE 2011 Em matemática dois conjuntos são ditos disjuntos se não tiverem nenhum elemento em comum Os conjuntos 1 2 3 e 6 7 são disjuntos pois não Fundamentos de Banco de Dados 1º Semestre 44 possuem elementos em comum WIKIPEDIA 2007 Figura 36 Notação de para disjunção de uma especialização ELMASRI NAVATHE 2011 p 166 Outra restrição possível de ser aplicada a uma especialização é a restrição de completude ou de totalidade e que pode ser total ou parcial Quando é total indica que toda entidade da superclasse precisa ter um correspondente em pelo menos uma das subclasses Por outro lado quando é parcial permite que uma entidade da superclasse não pertença a nenhuma das subclasses Uma restrição parcial é indi NAVATHE 2011 Figura 37 Notação de para sobreposição de especialização ELMASRI NAVATHE 2011 p 167 É importante salientar que restrições de disjunção e completude são inde pendentes podendo então haver 4 possibilidades sendo disjunção total disjunção parcial sobreposição total e sobreposição parcial Todavia a restrição correta será determinada baseandose no mundo real 52 Agregação É um conceito de abstração para a criação de objetos compostos com base em seus objetos componentes ELMASRI NAVATHE 2011 p 178 No modelo EER normalmente a necessidade de agregação ocorre quando se tem a necessidade de ligar um tipo de relacionamento a outro A notação do DER não prevê este tipo de situação assim a solução é a agregação criandose 45 Análise e Desenvolvimento de Sistemas 1º semestre 45 uma entidade virtual em um nível mais alto de abstração Entretanto uma manei ra mais elegante de solucionar este problema é transformar o tipo de entidade que se deseja relacionar com o relacionamento em um tipo de entidadefraca que depende do relacionamento das outras duas entidades Como exemplo temse o caso de um CANDIDATO a procura de emprego em uma determinada EMPRESA e o relacionamento entre eles é ENTREVISTA Do resultado da entrevista surgirá ou não uma oferta de emprego que para ser melhor descrita precisa estar ligado a um relacionamento RESULTAEM mas como não é possível ligar dois relacionamentos ENTREVISTA e RESULTAEM agregase o relacionamento ENTREVISTA e a agrega ELMASRI NAVATHE 2011 Figura 38 Exemplo de agregação em EER ELMASRI NAVATHE 2011 p 180 Fundamentos de Banco de Dados 1º Semestre 46 Capítulo 6 Diagrama de Classes 47 Análise e Desenvolvimento de Sistemas 1º semestre 47 O diagrama de classes é um dos mais importantes e mais utilizados da UML GUEDES 2009 p 101 Segundo a Wikipedia 2004 elaboração da estrutura de projetos de software Ela poderá ser documentação de artefatos que façam uso de sistemas complexos de software Em outras palavras na área de Engenharia de Sof tware a UML é uma linguagem de modelagem que permite re presentar um sistema de forma padronizada com intuito de faci litar a compreensão préimplementação A UML é adequada para a modelagem de sistemas cuja abrangência poderá incluir desde sistemas de informação corporativos a serem distribuídos a apli cações baseadas na Web e até sistemas complexos embutidos de tempo real É uma linguagem muito expressiva abrangendo todas as visões necessárias ao desenvolvimento e implantação desses sistemas O principal enfoque do diagrama de classes é permitir a visualização das classes que irão compor o sistema e seus atributos e métodos assim como de monstrar como elas se relacionam O diagrama de classes é composto basica mente por classes e suas associações GUEDES 2009 61 Atributos e Métodos Classes costumam ter atributos que armazenam os dados dos ob jetos da classes GUEDES 2009 p 101 Além dos atributos as classes também podem ter métodos entretanto esta parte não será abordada pois para modelar um banco de dados são necessários apenas os atributos Quanto aos atributos seus valores podem varia de uma instância para outra assim tornase possível As Classes representam objetos do mundo real e estes objetos tem carac terísticas similares As classes são representadas por um retângulo que segundo a notação básica da UML pode estar subdividido em três partes ou comparti mentos que contém Nome da Classe a lista de atributos e a lista de operações Destes apenas o compartimento com o Nome da Classe é obrigatório GÓES 2014 Não é realmente obrigatório que uma classe apresente as três divisões pois pode haver classes que não tenham atributos ou classes que não conte nham métodos GUEDES 2009 p 103 611 Nomes das Classes De acordo com GÓES 2014 p 134 O nome da Classes deve sempre estar no singular em negruto e centralizado dentro do seu compartimento Ele pode ser simples ou composto e sempre a primeira letra do nome deve estar em letra Fundamentos de Banco de Dados 1º Semestre 48 maiúscula e seguida de letras minúsculas classe Figura 39 Compartimentos do Diagrama de Clas ses 612 Atributos das classes Segundo Góes 2009 p 135 Os atributos devem ser escritos em formatação normal e começar por letras minúsculas e posicionadas à esquerda do seu comparti mento e podem ter nomes simples saldo ou compostos fotosA luno Nesses casos o segundo termo do nome do atributo assim como os demais termos deve iniciar com letra maiúscula Esta notação para os nomes dos atributos é também chamada de No tação Camel Case que é a denominação em inglês para a prática de escrever palavras compostas ou frases onde cada palavra é iniciada com maiúsculas e unidas sem espaços WIKIPEDIA 2006 Ao se modelar bancos de dados com o diagrama de classes devese colo car os atributos chave no início da lista de atributos Um exemplo de classe com Figura 40 Classe com atributos 613 Visibilidade priedade desse atributo pode ser utilizada Existem três tipos de visualização a saber publico representado pelo símbolo protegido representado pelo símbolo privado representado pelo símbolo GÓES 2014 A Programação Orientada a Objetos POO possui uma característica que é a Encapsulação Visando não quebrála atributos e métodos devem ser visíveis apenas onde é estritamente necessário desta forma os atributos de uma classe devem ter visibilidade privada pois somente a classe deve ter acesso à eles Para acessar os atributos de uma classe utilizamse métodos públicos Entretanto este não é o objetivo deste material e portanto abordaremos somente atributos devendo todos eles 614 Multiplicidade do atributo 49 Análise e Desenvolvimento de Sistemas 1º semestre 49 No caso dos atributos a multiplicidade determino a número mínimo e máximo de calo res que um atributo pode conter Se nenhuma multiplicidade for indicada assumese que ela é 1 Desta forma atributos multivalorados devem ter sua multiplicidade indicada GÓES 2014 As Figura 41 Multiplicidades possíveis 615 Atributo derivado De acordo com Góes 2014 p 137 Atributos derivados são aqueles cujos valores podem ser deduzi dos calculados em função dos valores de outros atributos deri vados eou de atributos essenciais também conhecidos por ar mazenados Atributos derivados são representados por uma barra à esquerda do seu nome A barra indica que o atributo é calculado em função de uma operação Um exemplo de uma classe com um atributo derivado e um atributo com Figura 42 Atributo derivado e atributo composto 62 Relacionamentos ou Associações As classes costumam ter relacionamentos entre si que permitem que elas compar tilhem informações GUEDES 2009 p 106 Uma associação é um relacionamento entre objetos de uma mesma classe ou de classes distintas GÓES 2014 p 139 As associações são repre sentadas por linhas ligando as classes envolvidas Essas linhas podem ter nomes ou títulos para auxiliar a compreensão de vínculo estabelecido entre os objetos das classes envolvidas nas asso ciações GUEDES 2009 p 106 Outra informação importante em uma associação é a multiplicidade que representa o número de objetos de cada classe que participa da associação A navegabilidade é representada por uma seta em uma das extremidades entre os objetos das classes envolvidas GUEDES 2009 p 109 Um exemplo de Fundamentos de Banco de Dados 1º Semestre 50 Figura 43 Multiplicidade e Navegabilidade em Associações de Classes 63 Associação Binária tintas Este tipo de associação é em geral a mais comumente encontrada GUEDES 2009 p 109 ão de Papéis São relacionamentos que ocorrem entre objetos de uma mesma classe GÓES 2014 p 141 Em outras palavras este tipo de associação ocorre quando existe um relacionamento de um objeto de uma classe com objetos da mesma classe GUEDES 2009 p 107 Nestes casos podese perceber que uma única classe é encontrada no diagrama e que seus objetos relacionamse com outros objetos dela Um exem plo clássico deste tipo de relacionamento é a classe de EMPREGADO que pode ou supervisão Em casos como estes pode haver confusão ou falta de clareza em quem cumpre qual papel e portanto tornase necessário a indicação de papéis En tenda que a indicação de papéis não é obrigatória e é utilizada apenas quando necessária para aumentar a clareza sobre o relacionamento Pode também ser papéis com indicação de papeis 51 Análise e Desenvolvimento de Sistemas 1º semestre 51 65 Associação Ternária ou Nária Associações ternárias ou nárias são associações que conectam objetos de mais de suas classes São representadas por um losango para onde convergem todas as ligações da associa ção Um exemplo de um relacionamento ternário com classe associativa pode 66 Classe Associativa Este tipo de relação ocorre normalmente quando existe um relacionamento cuja mul tiplicidade entre as classes é muitos em ambas as extremidades da relação GÓES 2009 p 147 As classes associativas são necessárias nos casos em que existem atributos relacionados à associação que não podem ser armazenados por nenhuma das classes envolvidas GUEDES 2009 p 115 É importante frisar que Classes Associativas não tem atributo chave Figura 45 Associação ternária Figura 46 Associação Binária 67 Generalização Especialização subclasses mais especializadas Generalização é o processo inverso de generali zar várias classes em uma classe abstrata de mais alto nível A Especialização ELMASRI NAVATHE 2011 p 178 Este é um tipo especial de associação É utilizada quando ocorre herança lhas ou subclasses chamadas especializadas demonstrando assim a hierarquia entre elas GUEDES 2009 A generalizaçãoespecialização ocorre quando existem duas ou mais clas ses com características muito semelhantes Desta forma para evitar ter de atri butos eou métodos idênticos e assim conseguir reutilizar código se cria uma classe geral onde são declarados os atributos e métodos comuns a todas as clas ses envolvidas no processo e depois declarase as classes especializadas ligadas a ela que então herdam duas características podendo também ter métodos ou atributos próprios GUEDES 2009 Este tipo de associação também pode ser chamada de é um pois uma classe geral é um objeto da classe especializada como pode ser observado na Fundamentos de Banco de Dados 1º Semestre 52 um técnico ou um secretário além é claro de qualquer outro funcionário que não o destas quatro subclasses ELMASRI NAVATHE 2011 Figura 47 Generalização Especialização 53 Análise e Desenvolvimento de Sistemas 1º semestre 53 671 Generalização Normal classe mais geral chamada de superclasse Os atributos operações e todas as associações são herdados A generalização normal é representada por uma linha entre as duas clas ses que fazem o relacionamento sendo que se coloca uma seta no lado da linha onde se encontra a superclasse indicando a generalização como pode ser ob Figura 48 Generalização Normal 672 Restrições de Sobreposição e Disjuntiva tuamente exclusivas ou seja uma entidade pode pertencer a somente uma subclasse da espe ciclomotor ou ônibus ou caminhão exclusivamente GUEDES 2009 Contrária a essa situação temos que uma entidade pode pertencer a mais de uma subclasse ao mesmo tempo Nesse caso dizemos que há uma sobrepo sição ou seja uma mesma entidade pode pertencer a mais de uma subclasse da anfíbio pode ser carro e barco simultaneamente caso do Amphicar model 770 veículo alemão anfíbio fabricado nos anos de 1961 e 1965 num total de 3878 uni de Anfíbio e carro no inglês WIKIPEDIA 2004 Figura 49 Restrição disjuntiva Figura 50 Restrição de sobreposição Figura 51 Amphicar como carro Figura 52 Amphicar como barco 673 Restrição de Integralidade A restrição de integralidade pode ser total ou parcial Ela será total quan do toda entidade de uma superclasse pertencer a pelo menos uma das subclas Fundamentos de Banco de Dados 1º Semestre 54 homens ou mulheres no sentido biológico Não há uma terceira opção GUEDES 2009 A parcialidade da restrição ocorre quando uma entidade da superclasse Desta forma pode haver quatro possibilidades de restrições consideran dose que os dois tipos total e parcial de restrições são independentes a Disjunção total b Disjunção parcial c Sobreposição total d Sobreposição parcial Rangel et al 2014 Uma destas possibilidades deve ser informada em toda generalização especialização Quando há apenas uma subclasse subentendese que é uma Disjunção Parcial GUEDES 2009 A UML permite que se construa uma hierarquia múltipla que é quando uma classe herda características de duas ou mais classes entretanto não utilize esta solução pois não pode ser implementada em SGBDs relacionais e nem todas as linguagens de programação tem essa capacidade de implementação 68 Agregação A agregação é um tipo de relacionamento no qual duas classes estão inseridas em um contexto todoparte entre pares um objeto não é mais importante que o outro É um relacio namento em que um objeto contém o outro numa associação de posse GUEDES 2009 As classes deste tipo de relacionamento podem viver de forma indepen dente de forma que os objetos da parte constituinte ou da agregada sejam independentes com relação à vida porém ambas pertencem a um único todo contém é parte de GUEDES 2009 O símbolo de agregação difere do de associação por conter um losango na extremidade da classe que representa o todo Um exemplo de agregação Figura 53 Agregação de Departamentos de um Empresa 69 Composição Uma associação de composição nada mais é do que uma variação da agregação ocor rendo quando duas classes só têm sentido no momento em que estiverem associadas Isso implica que se uma instância da classe deixar de existir todas as outras associadas por composição deixarão de existir também Este é o conceito aplicado às entidades fracas GUEDES 2009 55 Análise e Desenvolvimento de Sistemas 1º semestre 55 54 onde a entidade fraca Exemplar está associada por composição à classe Livro Figura 54 Composição de Exemplares de um Livro Figura 55 Diagrama de Classes para o esquema EMPRESA ELMASRI NAVATHE 2011 Fundamentos de Banco de Dados 1º Semestre 56 Capítulo 7 Modelo Relacional 57 Análise e Desenvolvimento de Sistemas 1º semestre 57 O modelo relacional é um modelo de dados representativo ou de implementação adequado a ser o modelo subjacente de um Sistema Gerenciador de Banco de Dados SGBD que se baseia no princípio de que todos os dados estão armazenados em tabelas predicados e na teoria dos conjuntos WIKIPEDIA 2004 O conceito do modelo relacional foi criado por Tedd Codd em 1970 sendo este baseado em lógica e na teoria dos conjuntos Neste modelo os dados são armazenados em relações que também armazenam os relacionamentos entre estas relações Os primeiros SGBDs relacionais comerciais surgiram no início da década de 1980 através da IBM e da Oracle Dentre os SGBDs relacionais mais populares atualmente podemos destacar o Oracle o DB2 da IBM e o SQL Server da Microsoft dentre os que são comerciais e o Postgree o MariaDB e o Firebird dentre aqueles que são livres ou de código aberto ELMASRI NAVATHE 2011 71 Conceito do Modelo Relacional O banco de dados no modelo relacional é representado por meio de relações De maneira informal cada relação é semelhante a uma tabela ou um arquivo de dados Quando uma relação é considerada uma tabela de valores cada linha nela representa uma coleção de valores relacionados representando assim cada linha uma entidade do mundo real Os nomes ELMASRI NAVATHE 2011 Tupla é o nome formal dado a cada linha da relação enquanto o cabeçalho das colunas recebe o nome de atributo Cada tipo de dado que descreve os tipos de valores que uma coluna pode receber é representado ELMASRI NAVATHE 2011 Fundamentos de Banco de Dados 1º Semestre 58 Figura 56 relação DEPENDENTE No modelo relacional os atributos devem ser atômicos ou seja indivisíveis e cada atributo pode ter somente um domínio O conjunto de atributos de uma relação recebe o nome de relação esquema O grau de uma relação é determinado pelo número de atributos que esta relação possua Um domínio D é um conjunto de valores atômicos Com atômico queremos dizer que cada valor no domínio é indivisível em se tratando do modelo relacional formal ELMASRI NAVATHE 2011 p 39 Um exemplo de uma relação e dos Figura 57 Detalhes da relação DEPENDENTE 72 Notação relacional Um esquema relacional R indicado por RA1 A2 An é composto de um nome de relação R e por uma lista de atributos A1 A2 An Cada atributo Ai é o nome de um papel desempenhado por algum domínio D no esquema de relação R D é chamado de domínio 59 Análise e Desenvolvimento de Sistemas 1º semestre 59 de Ai e indicado por domAi Um esquema de relação é usado para descrever uma relação R é o nome dessa relação O grau ou aridade é o número de atributos n desse esquema de relação ELMASRI NAVATHE 2011 p 40 Figura 58 Notação Relacional Figura 59 Exemplo de Notação Relacional 73 Restrições em modelo relacional e esquemas de bancos de dados relacionais Uma restrição é uma condição restritiva ou imposição de limite Pode ser entendida também como uma limitação ou condição imposta ao livre exercício de um direito ou de uma atividade HOUAISS VILLAR 2009 As restrições baseadas em esquema incluem restrições de domínio restrições de chave restrições sobre NULLs restrições de integridade de Fundamentos de Banco de Dados 1º Semestre 60 entidade e restrições de integridade referencial ELMASRI NAVATHE 2011 731 Restrições de domínio possíveis em cada atributo como por exemplo aceitar F ou M ambos maiúsculos para o atributo SEXO ELMASRI NAVATHE 2011 732 Restrições de domínio e Chaves todos distintos ou seja cada tupla é diferente das demais e que não podem ter a mesma combinação de valores para todos os seus atributos Além disso existem outros subconjuntos chamados de superchave Assim uma superchave de uma determinada tupla deve ser diferente da superchave em outra tupla representados por t1SC t2SC Cada relação tem pelo menos uma superchave padrão o conjunto de todos os atributos dela Como uma superchave pode conter atributos redundantes é mais útil o conceito de chave Uma chave é uma superchave mínima ou seja uma superchave que não pode mais ter nenhum de seus Figura 60 Exemplos de Superchaves de uma relação superchave mínima pois nenhum dos dois atributos pode ser removido relação Assim uma chave satisfaz a duas propriedades Na primeira duas tuplas não podem ter valores idênticos para os atributos de uma chave propriedade que também se aplica às superchaves e na segunda ela é uma superchave mínima da qual não é mais possível remover nenhum dos seus 61 Análise e Desenvolvimento de Sistemas 1º semestre 61 atributos Quando uma relação tem mais de uma chave ela é denominada como chave candidata Mas candidata a que Candidata a chave primária Sim do rol de chaves candidatas escolhese uma delas para chave primária da relação Embora não seja uma regra um bom critério é o de escolher a menor chave ou seja a que utiliza o menor número de bytes ou caracteres uma vez que estes atributos seráão utilizados nos relacionamentos NAVATHE 2011 r ale çã o a usa r e pode s can did at a chav e d e exemp ol Com o EMPREGADO Nome Uf Rg Código Cpf Endereço Salário conforme listado abaixo CC1 Uf Rg Superchave mínima Chave e ChaveCandidata CC2 Código Superchave mínima Chave e ChaveCandidata CC3 Cpf Superchave mínima Chave e ChaveCandidata Estas chaves são candidatas à chave primária já que todas elas anteriormente um bom critério é escolher a menor chave uma vez que a chave primária pode ser chave estrangeira em outra relação e assim utiliza se menos espaço no banco de dados e desta forma por este critério chave escolhida seria a CC2 Código que utiliza no máximo 4 bytes por ser um número inteiro Fundamentos de Banco de Dados 1º Semestre 62 Figura 61 Superchave e Chaves Figura 62 Relacionamento e Chave Estran geira da relação EMPREGADO Como ela é a chave primária de outra relação na relação TELEFONE este atributo passa a ser chamado de Chave Estrangeira 733 Restrições de integridade Restrição de Integridade são regras que restrigem os valores que podem ser armazenados em relações Um SGBDR Sistema Gerenciador de Banco de Dados Relacional deve garantir Restrição de Chave os valores das chavescandidatas devem ser únicos em todas as tuplas de uma relação Restrição de Entidade chavesprimárias não podem ter valores nulos tupla na relação EMPREGADO com o valor do atributo NSS o SGBDR deve recusar a inserção e emitir mensagem de erro Restrição de Integridade Referencial Usada para manter a consistência entre tuplas Estabelece que um valor de atributo que faz referência a uma outra tupla devese referir a uma tupla existente seja inserido uma tupla na relação TELEFONE com um valor para o atributo NSS que não esteja previamente cadastrado na relação EMPREGADO ELMASRI NAVATHE 2011 63 Análise e Desenvolvimento de Sistemas 1º semestre 63 Capítulo 8 Mapea mento do Modelo EntidadeRelaciona mento para o Modelo Relacional Fundamentos de Banco de Dados 1º Semestre 64 Ao se projetar um banco de dados normalmente se utiliza um modelo conceitual e o modelo conceitual mais utilizado é o Modelo EntidadeRelacionamento Entretanto os SGBDR Sistemas Gerenciadores de Bancos de Dados Relacionais utilizam o modelo relacional retrata do no capítulo 7 para representar os dados no banco de dados e assim é necessário que se faça uma conversão de modelos ou seja que se interprete o DER Diagrama EntidadeRelaciona mento para o modelo relacional ou regras para que se chegue ao modelo relacional como pode ser observado nos próximos tópicos Como exemplo será utilizado um modelo para um banco Figura 63 DER para um banco de dados escolar O produto da aplicação destas regras é o esquema do banco de dados e 64 65 Análise e Desenvolvimento de Sistemas 1º semestre 65 Figura 64 Projeto Lógico do Banco de Dados 81 Primeiro Passo Para cada tipo de entidade normal E no DER criase uma relação R que inclua todos os atributos simples de E Inclua também os atributos simples dos atributos compostos Escolha um dos atributoschave de E como a chaveprimária de R Se a chave escolhida é composta então o conjunto de atributos simples que o compõem formarão a chaveprimária de R Aluno Curso Turma Professor Disciplina Aluno RA Nome Rua Número Curso CodCurso Nome CargaHoraria Professor Matricula Nome Título Disciplina NúmeroDisciplina Nome CargaHorária Turma NúmeroTurma DataInicio DataFim Semestre Sala Fundamentos de Banco de Dados 1º Semestre 66 82 Segundo Passo cação E criase uma relação R e inclua todos os atributos simples como também os atributos simples de atributos compostos de W como atributos de R Além disso inclua como a chaveestrangeira de R a chaveprimária da A chaveprimária de R é a combinação da chaveprimária do tipo de en W Avaliação Aula Avaliação NúmeroDisciplinaCE NúmeroAvaliaçãoCE Enunciado RespostaPadrao TipoAvaliação Aula NúmeroDisciplinaCE NúmeroAulaCE Data Conteúdo 83 Terceiro Passo correspondem aos tipos de entidade que participam de R Devese escolher uma das relações por exemplo S e incluirse como cha veestrangeira de S a chaveprimária de T Entretanto é melhor escolher o tipo de entidade com participação total em R como sendo a relação S Incluise também todos os atributos simples e os atributos simples de atri butos compostos do tipo de relacionamento 11 R como atributos de S Tem Turma NúmeroTurma DataInicio DataFim Semestre Sala Nume roDisciplinaCE 84 Quarto Passo Para cada tipo de relacionamento binário regular 1N excluindose o relacionamento do senta o tipo de entidade que participa do lado N de R Inclua como chaveestrangeira de S a chaveprimária de T que represen ta o outro tipo de entidade que participa em R isto porque cada entidade do lado 1 está relacionada a mais de uma entidade no lado N Incluise também quaisquer atributos simples bem como atributos sim ples de atributos compostos do tipo de relacionamento 1N como atributos de S tos com cardinalidade 1N são 67 Análise e Desenvolvimento de Sistemas 1º semestre 67 Curso e Turma para o relacionamento possui Turma NúmeroTurma DataInicio DataFim Semestre Sala Numero DisciplinaCE CodCursoCE 85 Quinto Passo Para cada tipo de relacionamento binário MN R crie uma nova relação S para represen tar R Incluise como chaveestrangeira de S as chavesprimárias das relações que representam os tipos de entidade participantes sua combinação irá formar a chaveprimária de S Incluase também qualquer atributo simples do tipo de relacionamento MN ou atributos simples dos atributos compostos como atributos de S É importante frisar que não se pode representar um tipo de relacionamento MN como uma simples chaveestrangeira em uma das relações participantes como foi feito para os tipos de relacionamentos 11 e 1N Isso ocorre porque o MR não permite a representação de atributos multivalorados são Matriculase Realiza Frequenta Matriculase NumeroTurmaCE RACE DataMatricula Realiza NumeroDisciplinaCE NumeroAvaliaçãoCE RACE Nota Frequenta NumeroDisciplinaCE NumeroAulaCE RACE Situação 86 Sexto Passo Para cada atributo A multivalorado criese uma nova relação R que inclua o atributo A e a chaveprimária K da relação que representa o tipo de entidade ou o tipo de relacionamento que tem A como atributo A chaveprimária de R é a combinação de A e K Se o atributo multivalorado é composto inclua os atributos simples que o compõem entidade onde este está vinculado são Telefone e Email do tipo de entidade Cliente Telefone e Email do tipo de entidade Fornecedor TelefoneCliente CodigoClienteCE Telefone EmailCliente CodigoClienteCE Email TelefoneFornecedor CodigoFornecedorCE Telefone EmailFornecedor CodigoFornecedorCE Email 87 Sétimo Passo Para cada tipo de relacionamento nário R n2 ou seja um relaciona mento com mais de 2 tipos de entidade criase uma nova relação S para re Fundamentos de Banco de Dados 1º Semestre 68 presentar R Nesta relação devem ser incluídos como chaveestrangeira em S as chavesprimárias das relações que representam os tipos de entidades partici pantes Além disso incluase também qualquer atributo simples do tipo de rela cionamento nário ou atributos simples dos atributos compostos como atributo de S A chaveprimária de S é normalmente a combinação de todas as chaves estrangeiras que referenciam as relações que representam os tipos de entida des participantes Porém se a restrição estrutural min max de um dos tipos de entidades E que participa em R tiver max1 então a chaveprimária de S pode ser a chaveestrangeira que referencia a relação E isto porque cada entidade e univocamente esta instância de relacionamento relacionamento ternário que é Leciona Leciona CodigoCursoCE NumeroDisciplinaCE MatriculaCE 88 Projeto lógico do banco de dados Após a aplicação de cada um dos passos citados nos itens 81 até 87 gera o projeto lógi Aluno RA Nome Rua Número Curso CodCurso Nome CargaHoraria Professor Matricula Nome Título Disciplina NúmeroDisciplina Nome CargaHorária Turma NúmeroTurma DataInicio DataFim Semestre Sala Nume roDisciplinaCE CodCursoCE Avaliação NúmeroDisciplinaCE NúmeroAvaliaçãoCE Enunciado RespostaPadrao TipoAvaliação Aula NúmeroDisciplinaCE NúmeroAulaCE Data Conteúdo Matriculase NumeroTurmaCE RACE DataMatricula Realiza NumeroDisciplinaCE NumeroAvaliaçãoCE RACE Nota Frequenta NumeroDisciplinaCE NumeroAulaCE RACE Situação TelefoneCliente CodigoClienteCE Telefone EmailCliente CodigoClienteCE Email TelefoneFornecedor CodigoFornecedorCE Telefone EmailFornecedor CodigoFornecedorCE Email Leciona CodigoCursoCE NumeroDisciplinaCE MatriculaCE 89 Mapeando construções do modelo EER para relações serem seguidos para se fazer o mapeamento para o modelo relacional Para o mapeamento de 69 Análise e Desenvolvimento de Sistemas 1º semestre 69 especializações e generalizações existem várias opções ELMASRI NAVATHE 2011 891 Passo 8 Converta cada especialização com n subclasses S1 S2 Sn e a superclasse C em que os atributos de C são ch a1 an e ch é a chave primária para os esquemas da relação usando a seguinte opção que funciona para qualquer tipos de especialização Opção 8A Múltiplas relações superclasse e subclasses Criase uma relação L para C com atributos AtrsL ch a1 an e ChPL1 ch Criase uma relação L1 para a subclasse Si 1 i m com os atributos AtrsL ch U atributos de Si e ChPL1 ch Essa opção funciona para qualquer especialização parcial ou total disjunta ou sobre posta Livro CodigoLiteraturaCE ISBN AnoPublicação AutorLivro CodigoLiteraturaCE ISBNCE Autor Artigo CodigoLiteraturaCE CodigoArtigo PagInicial PagFinal TCC CodigoLiteraturaCE NivelTCC TipoTCC AnoPublicacao Co digoInstituicaoCE Fundamentos de Banco de Dados 1º Semestre 70 Figura 65 DER com EspecializaçãoGeneralização 71 Análise e Desenvolvimento de Sistemas 1º semestre 71 Capítulo 9 Normali zação Fundamentos de Banco de Dados 1º Semestre 72 Cada esquema de relação consiste em uma série de atributos e o es quema de banco de dados relacional consiste em uma série de esquemas de relação ELMASRI NAVATHE 2011 p 337 Normalização de banco de dados é um conjunto de regras que visa principalmente a organização de um projeto de banco de dados para reduzir a redundância de dados aumentar a integridade de dados e o desempenho Para normalizar o banco de dados devese examinar as colunas atributos de uma entidade e as relações entre enti dades tabelas com o objetivo de se evitar anomalias observadas na inclusão exclusão e alteração de registros WIKIPEDIA 2018 Obtido o esquema relacional correspondente ao documento passase ao processo de normalização Este processo baseiase no conceito de forma nor mal HOUSER 2009 Existem 6 formas normais sendo 1FN Primeira Forma Normal 2FN Segunda Forma Normal 3FN Terceira Forma Normal FNBC Forma Normal de BoyceCodd 4FN Quarta Forma Normal 5FN Quinta Forma Normal 91 Abordagens de Projeto de Banco de Dados Um projeto pode ser abordado de modo TopDown ou BottonUp O método TopDown inicia pelo agrupamento dos atributos obtidos a par tir do projeto conceitual de mapeamento Isso é chamado de projeto por análi se Já o método BottomUP considera os relacionamentos entre atributos para construir as relações Isso é chamado projeto pela síntese Neste material será abordado o método TopDown 92 Anomalias Um projeto não normalizado pode proporcionar a ocorrências de anoma lias Segundo Ramakrishnan e Gehrke 2008 p 507 O armazenamento das mesmas informações de forma redundante isto é em mais de um lugar dento de um banco de dados pode acarretar vários problemas Estas anomalias po dem ser da ordem de Inserção de Remoção ou de Alteração Um exemplo de um 73 Análise e Desenvolvimento de Sistemas 1º semestre 73 Figura 66 Banco de Dados de Pedidos de Compras 921 Anomalias de Atualização São os problemas causados durante uma inserção atualização ou exclusão em uma base que os dados do fornecedor do fornecimento e da localização do fornecedor estão todos mistu rados na mesma relação Podese ver ainda que não existem tabelas auxiliares uma vez que to das as informações estão na mesma relação Outro fator importante é que nenhum campo pode CodPeça ma localização de fornecedor pode ser inserida até que este fornecedor forne ça pelo menos uma peça o que inviabiliza a participação de um fornecedor em qualquer compra já que ele não estará previamente cadastrado Ainda há o problema de que sempre que uma peça for fornecida será preciso repetir os dados do fornecedor Neste caso existe a possibilidade de que o usuário erre ou nome da cidade Supondose a existência de um fornecedor que venha a fornecer 100 peças para a empresa em questão e que este fornecedor esteja situado na cidade de Santo Antônio do Aracanguá SP Podese encontrar após a inserção de 100 registro variantes como Sto Antônio Aracanguá até S A Aracanguá fazendo com exista perda de informação RAMAKRISHNAN GEHRKE 2008 922 Anomalias de Alteração repetido várias vezes na tabela Isso aumenta a probabilidade de erros Se o for necedor 1 mudar para Amsterdã será necessária a atualização de várias tuplas Se cuidados não forem tomados pode haver uma ocorrência do Forne cedor 1 em Londres e outra em Amsterdã O mesmo problema ocorre com os atributos NOME e STATUS Referindose ao exemplo de inserção citado no item 9211 caso o fornecedor do exemplo mudarse do município de Santo Antônio do Aracanguá SP para o município de São João do Pau dAlho no mesmo esta do propiciará a possibilidade erro ou até mesmo a não atualização de todos os registros Fundamentos de Banco de Dados 1º Semestre 74 O atributo valor apresenta outra anomalia Ele é calculado pela multipli será preciso atualizar também o atributo VALOR um passo a mais que pode ser esquecido RAMAKRISHNAN GEHRKE 2008 923 Anomalias de Exclusão necedor precisarem ser apagados não apenas serão excluídas suas relações com as peças mas também a informação de que o fornecedor está localizado em uma determinada cidade acarretando portanto perda de informação RAMAKRISHNAN GEHRKE 2008 93 Dependências Funcionais Uma dependência funcional é uma restrição entre dois conjuntos de atributos do banco de dados ELMASRI NAVATHE 2011 p 346 Dependências funcionais DFs são usadas para medir formalmente a qualidade do projeto relacional As Dependências Funcionais e as chaves são De acordo com Elmasri e Navathe 2011 p 346 Uma dependência funcio nal É indicada por XY entre dois conjuntos de atributos X e Y que são sub conjuntos podem formar um estado de relação r de R eles há uma dependência funcional de tal forma que X é o determinante e Y é o dependente A representação é X Y ELMASRI NAVATHE 2011 Desta forma se X Y e se as duas tuplas tiverem o mesmo valor para X elas devem ter o mesmo valor para Y Ou seja se X Y então para quaisquer tu plas t1 e t2 de rR assim se t1X t2X então t1Y t2Y Assim podese constatar que se K é uma chave de R então K determina funcionalmente todos os atributos de R isso porque nunca teremos duas tuplas distintas com t1Kt2K É importante frisar que X tâncias de R As DFs são derivadas das restrições do mundo real e não de uma 931 Exemplos de Dependências Funcionais Um exemplo de dependência funcional pode ser o número do seguro social que deter mina o nome do empregado NSS ENOME Um outro pode ser o número do projeto que deter mina o nome do projeto e a sua localização PNUMERO PNOME PLOCALIZACAO Por outro lado O NSS de empregado e o número do projeto PNUMERO determinam as horas semanais HORAS que o empregado trabalha no projeto NSS PNUMERO HORAS Ainda podese citar mais um exemplo que é o relacionamento entre ci ESTADO e que ESTA DO PAIS onde temse que Estado é funcionalmente dependente de cidade 75 Análise e Desenvolvimento de Sistemas 1º semestre 75 País é funcionalmente dependente de estado Resumindo cidade determina estado que determina país Trivialidade A dependência funcional trivial indica que um determinante com mais de um atributo pode determinar seus próprios membros quando isolados Exemplo banco agência banco DF trivial pois banco é parte do determinante banco agência agência DF trivial pois agência é parte do determinante Quando um determinante indica outro atributo qualquer temos uma depen dência funcional não trivial Exemplo banco agência cidade DF não trivial pois cidade não faz parte do determinante RAMAKRISHNAN GEHRKE 2008 Dependência funcional irredutível à esquerda Dizse que o lado esquerdo de uma dependência funcional é irredutível quan do o determinante está em sua forma mínima que é quando não é mais possível reduzir a quantidade de atributos determinantes sem perder a dependência funcio nal Exemplo cidade estado país DF não está na forma irredutível à esquerda estado país querda RAMAKRISHNAN GEHRKE 2008 932 Regras para encontrar Dependências Funcionais Existem algumas regras para que se encontre as Dependências Funcionais em um esque ma de banco de dados relacional Regras de inferência de Armstrong X é subconjunto de então X Y Isso também é válido quando XY RI2 Aumentativa Se X Y então XZ YZ U Z RI3 Transitiva Se X Y e Y Z então X Z Fundamentos de Banco de Dados 1º Semestre 76 RI1 RI2 e RI3 formam um conjunto completo de regras de inferência Regra de Separação A BC então A B e A C Exemplo CPF nome endereço então CPF nome e CPF endereço Leiase o exemplo acima da seguinte maneira Se com um número de CPF encontrase o nome e o endereço de uma pes soa então com este mesmo número é possível encontrar apenas o nome e com este mesmo número podese encontrar apenas o endereço Regra de Acumulação Aditiva A B então AC B Exemplo CPF Endereço então CPF Idade endereço Leiase o exemplo acima da seguinte maneira Se com um número de CPF encontrase o endereço de uma pessoa então com este mesmo número mais a idade da pessoa podese encontrar o endereço também Regra de Transitividade A B e B C então A C Exemplo CPF códigocidade e códigocidade nomecidade então CPF no mecidade Leiase o exemplo acima da seguinte maneira Se com um número de CPF encontrase o código da cidade de uma pes soa e com o código da cidade é possível encontrar o nome da cidade então com o número do CPF podese encontrar o nome da cidade Um outro exemplo pode ser cidade estado estado país cidade país cidade determina país de forma transitiva Regra de PseudoTransitividade A B e BC D então AC D Exemplo CPF códigofuncionário e códigofuncionário mês saláriofuncio nário então CPF mês saláriofuncionário 77 Análise e Desenvolvimento de Sistemas 1º semestre 77 Leiase o exemplo acima da seguinte maneira Se com um número de CPF encontrase o código do funcionário e com o código do funcionário mais um certo mês é possível encontrar o salário que ele recebeu naquele mês então com o número do CPF mais um certo mês podese encontrar o salário que ele recebeu naquele mês 94 Formas Normais Intuitivamente a redundância surge quando um esquema relacional impõe uma associação entre atributos que não é natural As dependências funcionais A ideia básica é que muitos problemas provenientes da redundân cia podem ser resolvidos substituindose uma relação por uma co leção de relações menores Uma decomposição de um esquema de relação R consiste na subs tituição do esquema de relação por dois ou mais esquemas de relação cada um contendo um subconjunto dos atributos de R e juntos incluindo todos os atributos presentes em R RAMAKRISHNAN GEHRKE 2008 p 510 A decomposição de um esquema de relação pode criar mais problemas do que resolvêlos e por isso necessita de cuidados Desta forma duas perguntas devem ser feitas repetidamente É preciso decompor uma relação Várias formas normais foram proposta para relações e se um es quema de relação esta em uma delas sabese que alguns proble mas podem surgir Quais problemas se houver determinada decomposição causa Duas são as propriedades principais a propriedade da junção sem perda nos permite recuperar qualquer instância da relação de composta e a propriedade da preservação da dependência que permite impor qualquer restrição na relação original simplesmente impondo algumas restrições em cada uma das relações menores Do ponto de vista do desempenho consultas na relação original podem exigir que se juntem as relações decompostas RAMAKRISHNAN GEHRKE 2008 Figura 67 Relação de Funcionário É preciso que se façam decomposições sem perdas Deste modo a decompo sição deve ser reversível para que nenhuma informação seja perdida Os conceitos de decomposição sem perdas e dependência funcional são conceitos intimamente plos A e B onde o modelo A mostra a decomposição sem perdas da relação Funcio nário uma vez que no exemplo B não há mais como de obter a relação original Fundamentos de Banco de Dados 1º Semestre 78 Figura 68 Exemplos de Decomposição RAMAKRISHNAN GEHRKE 2008 941 Primeira Forma Normal 1FN Proíbe que relações tenham atributos compostos atributos multivalorados ou relações aninhadas ou seja permite apenas atributos que sejam atômicos Considerado como Figu ra 69 Normalização para a Primeira Forma Normal 942 Segunda Forma Normal 2FN Para entender a 2FN precisamos entender os conceitos de Dependência Funcional Cha veprimária Atributo NãoPrimo e Dependência funcional total Uma DF Y Z onde a remoção de qualquer atributo de Y invalida a DF Exemplos NSS PNUMERO HORAS é dependente totalmente de NSS PNUMERO uma vez que NSS não determina HORAS e nem PNUMERO determina HORAS NSS PNUMERO ENOME não é dependente totalmente de 79 Análise e Desenvolvimento de Sistemas 1º semestre 79 NSS PNUMERO ENOME é dependente parcialmente de NSS PNUMERO pois NSS ENOME Uma relação esquema R está na 2FN se estiver na 1FN e todos os atributos nãoprimos A de R forem totalmente dependentes da chaveprimária A relação esquema R pode ser decomposto em relações que estejam na 2 FN através do processo de normalização A Segunda Forma Normal visa a diminuição da redundância e o desagru pamento de informações Na 2FN uma tabela representa um quantidade menor de entidades Uma tabela está na 2FN se Estiver na 1FN Todo atributo nãochave for determinado por todos os campos da cha ve primária É preciso eliminar as dependências funcionais parciais Para fazer a normalização para segunda forma normal devese mover os campos não enquadrados na 2FN para uma nova relação que também deverá ser normalizada Figura 70 Normalização para 2FN 943 Terceira Forma Normal 3FN Para entender a 3FN é preciso entender A 2FN Segunda Forma Normal Atributo NãoPrimo Dependência funcional transitiva Se X Y e Y Z então X Z Desta forma uma relação esquema R está na 3FN se ela estiver na 2FN e ne nhum atributo nãoprimo A for transitivamente dependente da chaveprimária O esquema de relação R pode ser decomposto em relações que estejam na 3FN via o Fundamentos de Banco de Dados 1º Semestre 80 processo de normalização Nota Em X Y e Y Z sendo X a chaveprimária pode ser considerado um problema se e somente se Y não for uma chavecandidata Quan do Y é uma chavecandidata não existe problema com a depen dência transitiva Por exemplo considerando o esquema de relação EMP NSS Emp Salario Aqui NSS Emp Salario e Emp é uma chavecandidata A 3Fn Terceira Forma Normal tem o mesmo objetivo da 2FN que é o de Estiver na 2FN Todo atributo não chave deve ser determinado de forma não transitiva pela chave primária ou todo atributo não chave deve ser determinado apenas pela chave primária Para normalizar para a 3FN é preciso mover os campos não enquadrados para outra tabela e normalizála também Figura 71 Normalização para a 3FN 944 Forma Normal de Boyce Codd FNBC Uma relação esquema R está na BCNF se sempre que houver uma DF X A em R então X é uma superchave de R Perceba que cada forma normal engloba a forma normal anterior Toda relação em 2FN está na 1FN Toda relação em 3FN está na 2FN Toda relação em BCNF está na 3FN Existem relações que estão na 3FN mas não em BCNF A meta portanto é alcançar a BCNF Forma Normal de Boyce Codd ou 3FN Terceira Forma Normal em todas as relações Desta forma Uma relação esquema R está na 3FN se sempre que houver uma DF X A então 81 Análise e Desenvolvimento de Sistemas 1º semestre 81 X é uma superchave de R ou A é atributo primo de R Uma relação esquema R está na BCNF se sempre que houver uma DF X A então X é uma superchave de R Figura 72 3FN e BCNF df1 estudante curso instrutor df2 instrutor curso Se a relação tivesse apenas df1 a relação estaria na BCNF mas em df2 ins trutor não é uma superchave e portanto viola a BCNF mas não a 3FN pois curso é primo Uma relação que não esteja na BCNF deve ser decomposta para atender a esta propriedade mas abdica da preservação das dependências funcionais nas re lações decompostas Três possíveis decomposições para relação R1estudante instrutor e R2estudante curso R1curso instrutor e R2curso estudante R1instrutor curso e R2instrutor estudante Assim todas as três decomposições perdem a df1 É preciso conviver com composição Das três apenas a terceira decomposição não gera tuplas espúrias após a junção join e assim mantém a propriedade nãoaditiva Fundamentos de Banco de Dados 1º Semestre 82 Figura 73 Alcançando a BCNF pela Decomposição 945 Dependências Multivaloradas e a Quarta Forma Normal 4FN As dependências multivaloradas são consequência da 1FN a qual não aceita atributos multivalorados Desta forma sempre que X àà Y ocorrer dizemos que X multidetermina Y Devido implica X àà Z por isso às vezes é escrito como XààY Z Figura 74 Relação ACERVO ISBN àà AUTOR CÓPIAS As dependências multivaloradas são uma consequência da primeira forma normal 1FN que desaprova um atributo em uma tupla para ter um conjunto de valores e o processo correspondente de conversão de uma relação não normaliza da para 1FN ELMASRI NAVATHE 2011 p 357 Ao normalizarse a relação ACERVO 83 Análise e Desenvolvimento de Sistemas 1º semestre 83 Figura 75 Relação ACERVO normalizada para 1FN Podese observar entretanto que ainda existem redundâncias na relação ACERVO mesmo depois de normalizada mas por que Porque restaram as depen dências multivaloradas ISBN AUTOR e ISBN CÓPIAS Assim o objetivo da 4FN Quarta Forma Normal é eliminar as redundâncias provocadas pelas dependências multivaloradas MVD Uma relação está na 4FN se estiver na 3FN e não contiver mais de uma dependência multivalorada MVD ELMASRI NAVATHE 2011 É possível questionar o porque é tão ruim ter uma tabela com múltiplas de para inserir mais uma cópia do ISBN 0130319953 será necessário inserir 3 tuplas uma para cada autor Alterações e remoções sofrerão do mesmo problema então as dependências multivaloradas MVD ISBN àà AUTOR e ISBN àà CÓPIAS como Figura 76 ISBN àà AUTOR Figura 77 ISBN àà CÓPIAS Assim a dependência multivalorada desejável é aquela cujo determinante é superchave da relação Entretanto há um caso especial Se R tiver as seguintes MVDs dependências multivaloradas A àà B e B àà C neste caso R estará na 4FN se e somente se B e C são dependentes um do outro ELMASRI NAVATHE 2011 Um outro exemplo pode ser a relação LECIONA que possui as MVDs PROFES SOR DISCIPLINA e PROFESSOR SORDISCIPLINA e PROFESSORTÍTULO Fundamentos de Banco de Dados 1º Semestre 84 Figura 78 PROFESSOR àà DISCIPLINA Figura 79 PROFES SOR àà TÍTULO 946 Dependências de Junção e a Quinta Forma Normal 5FN Algumas vezes uma relação não pode ser decomposta sem perdas em duas relações mas pode ser decomposta em três ou mais Se uma relação é decomposta em várias relações e a reconstrução não é possível pela junção das outras relações dizemos que existe uma depen dência de junção A quinta forma normal 5FN A 5FN capta a ideia de que uma relação esquema deve ter alguma decomposição sem perda dependência de junção Segundo Elmasri e Navathe 2011 p 360 É importante observar que tal dependência é uma restrição semântica muito pe culiar que é muito difícil de detectar na prática Portanto a normalização para a 5FN raramente Figura 80 Relação AEP Regra Se um AGENTE vende um certo PRODUTO e este AGENTE repre senta uma EMPRESA que faz este PRODUTO então O AGENTE deve vender o PRO DUTO para a EMPRESA Desta forma AGENTES representam EMPRESAS EMPRESAS fazem PRODUTOS AGENTES vendem PRODUTOS Neste exemplo ao normalizar a relação AEP para a 5FN serão obtidas 3 85 Análise e Desenvolvimento de Sistemas 1º semestre 85 Figura 81 Re lação AEP na 5FN Segundo Elmasri e Navathe 2011 uma relação R satisfaz a depen dência de junção JD R1 R2 Rn se R R1 R2 Rn de forma que R1 R2 Rn são subconjuntos dos atributos de R É possível notar que uma dependência multivalorada é um caso espe cial de dependência de junção n2 Assim uma relação R está na 5FN se e somente se ela estiver na 4FN e todas as suas dependências de junção forem determinadas pelas chaves candidatas A descoberta de Dependências de Junção em bancos de dados reais com centenas de atributos é praticamente impossível Isso poderá ser feito apenas contando com um grande grau de intuição sobre os dados por parte do projetista Por isso a prática atual de projeto de banco de dados dá pouca atenção a elas ELMASRI NAVATHE 2011 947 Demais Formas Normais Existem outras formas normais porém elas estão fora do escopo desta disciplina de aplicação prática Fundamentos de Banco de Dados 1º Semestre 86 87 Análise e Desenvolvimento de Sistemas 1º semestre 87 Referências DATE C J Introdução a sistemas de bancos de dados Elsevier Rio de Janeiro 2003 ELMASRI Ramez NAVATHE Shamkant B Sistemas de banco de dados 6 ed São Paulo Pearson Education 2011 788 p FANDERUFF Damaris Dominando o Oracle 9i Modelagem e Desenvolvimento São Paulo Pearson Education do Brasil 2003 398 p FARIAS Anderson Rodrigo História da Oracle Para Devmedia Disponível em httpswww devmediacombrhistoriadaoracle4685 Acesso em 21 mar 2018 HEUSER Carlos Alberto Projeto de Banco de Dados 6 ed São Paulo Bookman 2009 282 p HOUAISS Antônio Dicionário Houaiss da Língua Portuguesa Rio de Janeiro Objetiva 2009 1986 p METRO Mapa do Metrô de São Paulo Disponível em httpsptsaopaulomap360commapa metrosaopauloWrjiveYh3rc Acesso em 26 mar 2018 RANGEL Alexandre Leite et al Ed BANCO DE DADOS Batatais Claretiano 2015 254 p SANCHES Andre Rodrigo Fundamentos de Armazenamento e Manipulação de Dados 2005 Disponível em httpswwwimeuspbrandrersaulasbd20051aula2 Acesso em 21 mar 2018 SILBERSCHATZ Abraham KORTH Henry F SUDARSHAN S Sistema de Banco de Dados Rio de Janeiro Elsevier 2008 Tradução da 5ª Edição SOMMERVILLE Ian Engenharia de Software 9 ed SÃo Paulo Pearson Education 2011 529 p TRENDS24Trends 24 Brasil Disponível em httpstrends24inbrazil Acesso em 20 mar 2018 TUTORIALSPOINT COBOL Manipulação de Arquivo Verbos Disponível em httpswww WIKIPEDIA Banco de dados 2010 Disponível em httpsptwikipediaorgwikiBancodedados Acesso em 21 mar 2018 WIKIPEDIA COBOL 2004 Disponível em httpsptwikipediaorgwikiCOBOL Acesso em 21 mar 2018 WIKIPEDIA Concatenação 2008 Disponível em httpsptwikipediaorgwikiConcatenação Acesso em 28 mar 2018 WIKIPEDIA Modelagem de dados 2004 Disponível em httpsptwikipediaorgwikiModelagem dedados Acesso em 26 mar 2018