Curso Técnico em Informática Integrado ao Ensino Médio Módulo II. Banco de Dados - PDF
Curso Técnico em Informática Integrado ao Ensino Médio Módulo II. Banco de Dados
Download "Curso Técnico em Informática Integrado ao Ensino Médio Módulo II. Banco de Dados"
Raul Neto Coelho
1 Curso Técnico em Informática Integrado ao Ensino Médio Módulo II Maria de Fátima de Freitas Bueno Marcílio 2012
2 2 Sumário 1. Introdução Noções Preliminares Propriedades básicas Principais diferenças entre um BD e um sistema baseado em arquivos Conceitos Adicionais Modelos de dados Linguagens de Base de Dados SGBDs Etapas no desenvolvimento de sistemas O papel da Modelagem de Dados no desenvolvimento de sistemas Análise de Dados x Análise de Processos Normalização de Dados Conceitos usados na Normalização de Dados Atributo Registro Arquivo Chave Dependência Funcional Formas Normais Primeira Forma Normal (1FN) Segunda Forma Normal (2FN) Terceira Forma Normal (3FN) Regras práticas para normalização de arquivos Até onde normalizar Desnormalização de dados Modelo Entidade Relacionamento (ER) Elementos usados no modelo Entidade-Relacionamento Entidade Sub-Entidade Entidade Fraca Instância Atributo Chave Primária e Estrangeira Relacionamento Cardinalidade do Relacionamento Um-para-um (1:1) Um-para-muitos (1:N) Muitos-para-muitos (M:N) Relacionamento Reflexivo Relacionamento mandatório e opcional Diagrama Entidade-Relacionamento Estendendo o Modelo Entidade-Relacionamento Modelo de Dados Relacional Conceitos do Modelo Relacional Características de Relações Restrições Relacionais Bancos de Dados Relacionais e Esquemas Integridade de Entidade, Integridade Referencial e Chaves Estrangeiras Operação de Atualização e Violação de Restrições Operação de inserção Operação de deleção...31
3 4.6.3 Operação de Atualização SQL Structured Query Language Operadores utilizados em SQL: Comandos para manipulação de dados O comando SELECT: Combinando dados entre tabelas diferentes Relacionamentos entre mais de duas tabelas Relacionamento Reflexivo Agrupando e sumarizando os dados Filtrando dados agrupados com a cláusula HAVING Comandos para manutenção de dados INSERT DELETE UPDATE...38 Referências Bibliográficas
4 1. Introdução Noções Preliminares Um ou Base de Dados (BD) é uma coleção de dados relacionados entre si. Com dados queremos dizer fatos conhecidos que podem ser armazenados e possuem um significado implícito. Um exemplo (simples): coleção de nomes das pessoas que você conhece, juntamente com o endereço e telefone de cada uma delas (podem ser armazenados em uma agenda ou em um computador). Outro exemplo (um pouco mais complexo): coleção de todas as fotos recolhidas ao longo dos anos pelo programa espacial americano Propriedades básicas Um BD possui as seguintes propriedades: 1. Representa algum aspecto do mundo real; 2. Coleção logicamente coerente de dados com um significado inerente; 3. Projetado, construído e preenchido (instanciado) com dados para um propósito específico. A ele está relacionado um grupo de usuários e aplicações de interesse a esses usuários. Em outras palavras, um BD possui alguma fonte de onde os dados são obtidos, um grau de iteração com eventos do mundo real e um grupo de pessoas interessados no seu conteúdo. Exemplo (extremamente simples) de um BD para a escola: Aluno Nome_alu RA Disciplinas João João José Disciplinas Nome_disc Código Horas Sala L02 Sistema Operacional I S05 Algoritmos L02 Essa base de dados é organizada em dois arquivos distintos, cada um contendo registros do mesmo tipo. Para defini-la, necessitamos especificar a estrutura dos registros em cada um dos arquivos. Ou seja, necessitamos definir os elementos a serem armazenados em cada um dos registros. Cada registro de estudante, por exemplo, guarda o nome, código e disciplinas sendo cursadas pelo estudante. Além disso, o tipo de cada um dos elementos da estrutura precisa ser definido (nome: sequência de caracteres; RA: inteiro sem sinal; Disciplina: inteiro sem sinal) Principais diferenças entre um BD e um sistema baseado em arquivos Em um sistema baseado em arquivos, o que temos é uma coleção de arquivos cujo conteúdo são dados a serem consultados ou modificados de acordo com as necessidades do usuário detentor desses arquivos e por meio de programas específicos, desenvolvidos com o formato desses arquivos em mente. Exemplo: a secretária do departamento tem a sua disposição um arquivo com os nomes dos estudantes e as disciplinas sendo cursadas por cada um deles. Já a tesouraria do departamento precisaria de um arquivo com os nomes dos estudantes e informações sobre pagamento de bolsas. O principal problema dessa abordagem: redundância dos dados (gasto de espaço e necessidade de esforços consideráveis para manter consistência).
5 Existem dois tipos de redundância de dados: a controlada e não controlada. Na primeira, o software garante a consistência das informações. Na segunda, cabe ao usuário garantir essa consistência. Em um sistema baseado em uma base de dados, um único repositório de dados é mantido, o que elimina o problema da redundância e, mais do que isso: 1. Um sistema baseado em banco de dados inclui uma descrição detalhada de sua base. Essa descrição corresponde ao catálogo do banco de dados, que guarda, dentre outras coisas, informações sobre a estrutura de cada arquivo, e sobre o tipo de cada item de dado. O catálogo permite que um mesmo conjunto de programas acesse diferentes tipos de bases de dados, ao contrário dos programas que manipulam os arquivos em um sistema baseado em arquivos. 2. Por meio do catálogo, qualquer mudança na base de dados é prontamente reconhecida pelos programas que as acessam (independência entre dados e programa). Além disso, em alguns sistemas de banco de dados, existe também uma independência entre o programa e operação. 3. Em um sistema baseado em banco de dados, certas operações sobre os dados devem ser feitas de forma conjunta e indivisível com o intuito de preservar a consistência da base de dados. Isso, mesmo na presença de falhas no equipamento de armazenamento ou na comunicação com a base de dados (atomicidade). 4. Um sistema baseado em banco de dados inclui programas de controle de concorrência. Ou seja, programas que assegurem um acesso adequado a uma base de dados quando vários usuários a acessam ao mesmo tempo (consistência). 5. Um sistema baseado em banco de dados é suficientemente robusto para se recuperar de falhas de hardware ou software (durabilidade). A construção e manutenção de um sistema que atende aos requisitos acima requerem o auxílio de programas bem elaborados. Daí, temos as seguintes definições: Sistema Gerenciador de Base de Dados: coleção de programas que permitem a criação e manutenção de qualquer base de dados, independentemente da aplicação pretendida. Sistema de Banco de dados: Sistema gerenciador juntamente com a base de dados. 1.2 Conceitos Adicionais Uma das principais características da abordagem de base de dados é que ela provê ao usuário um nível de abstração de dados que não inclui detalhes de como eles esses dados encontram-se armazenados e como as operações que os manipulam estão implementadas. O modelo de dados é a principal ferramenta utilizada para prover esse tipo de abstração Modelos de dados Um modelo de dados é um conjunto de conceitos lógicos (objetos, suas propriedades e o interrelacionamento entre eles) compreensíveis aos usuários finais do sistema e usados para descrever a estrutura de uma base de dados. Por estrutura de uma base de dados entenda-se os tipos de dados, relacionamentos e restrições associadas aos dados. Vários modelos de dados definem também um conjunto de operações para recuperação e modificação da base de dados. De acordo com os tipos de conceitos que fornecem para descrever a estrutura da base de dados, os modelos de dados podem ser classificados em: Conceituais: provê conceitos muito próximos àqueles percebidos pelos usuários finais do sistema. Esses modelos utilizam conceitos entidades, atributos, e relacionamentos. Uma entidade representa objetos ou conceitos do mundo real (exemplos: empregados, voos). Um atributo representa alguma propriedade de interesse relacionada a uma entidade (nome e salário dos empregados, por exemplo). Um relacionamento entre duas (ou mais entidades) representa uma interação entre entidades (relacionamento entre empregado e projeto, por exemplo). 5
6 Físicos: provê conceito que descrevem os detalhes de como os dados encontram-se armazenados no computador. Representam informações como formato dos registros, ordenação dos registros e caminhos de acesso. Lógicos: provê conceitos que podem ser entendidos pelos usuários finais do sistema e que estão próximos da forma como os dados são fisicamente armazenados. São os mais utilizados pelos SGBD atuais e incluem o modelo de dados relacional, de rede e hierárquicos. Esquemas, instâncias e estado de um banco de dados: Em qualquer modelo de dados é importante distinguir entre a descrição da base de dados e base de dados propriamente dita. A descrição de uma base de dados é chamada de esquema de uma base de dados. Esse esquema é especificado durante o projeto da base de dados e não costuma sofrer mudanças frequentes. A forma de visualização de um esquema é chamada Diagrama do Esquema. Muitos modelos de dados têm certas convenções para, diagramaticamente, mostrar esquemas especificados no modelo. Tomando como exemplo o BD (extremamente simples) para a universidade, temos o seguinte diagrama do esquema para essa base: 6 Aluno Disciplina Nome_alu RA Disciplinas Nome_disc Código Horas Sala Os dados em uma base de dados, estes sim, costumam mudar frequentemente. Os dados armazenados em um banco em um determinado instante é chamado de estado ou instância da base de dados Linguagens de Base de Dados Linguagem de Definição de Dados (DDL - Data Definition Language): Utilizada pelo administrador e projetistas da base de dados para definição dos esquemas. O SGBD possui um compilador que traduz descrições em DDL em descrições dos esquemas em catálogo; Linguagem de Manipulação de Dados (DDL - Data Manipulation Language): Utilizada pelos usuários para manipulação (recuperação, inserção, remoção e modificação) dos dados SGBDs Um sistema gerenciador de base de dados é composto de vários módulos distintos: Gerenciador de dados armazenados: controla o acesso as informações dos sistemas que estão armazenadas no disco. Esse módulo utiliza-se de serviços básicos do sistema operacional para transferir dados do disco para a memória principal. Uma vez transferidos, esses dados podem então ser usados por outros módulos do sistema (ou por aplicações do usuário). Compilador DLL: processa as descrições do esquema (escritas em DLL) e as armazenam no catálogo do sistema (que se encontra no disco rígido). Processador run-time: manipula acessos à base de dados em tempo de execução. Ele recebe operações de atualizações ou recuperações de dados. Compilador de consultas: manipula consultas em mais alto nível. Ele compila ou interpreta consultas e então gera chamadas ao run-time processor. O pré-compilador extrai comandos DML de um programa de aplicação escrito em uma linguagem de alto nível qualquer. Esses comandos são então enviados ao compilador DML, que os transformam em códigos para acesso a base. O resto do código é enviado ao compilador da linguagem. Os códigos para os comandos DML e o resto do programa são linkados, gerando um código executável que inclui chamadas ao processador run-time.
7 1.3 Etapas no desenvolvimento de sistemas 7 O desenvolvimento de sistemas pode ser dividido em etapas que se complementam. São elas: Análise funcional: são levantados os processos manuais que deverão ser informatizados e a relação entre eles. Análise de dados: ou Modelagem de dados. Quais informações que deverão ser tratadas pelo sistema. Além de ser registrar as informações agrupando-as, também são analisadas as relações entre estas informações. São utilizadas técnicas como Normalização de Dados e Modelo Entidade-Relacionamento. Implementação: escrita do código em alguma linguagem de programação. Testes: utilizados para validar o programa em relação aos objetivos propostos nas etapas de análise. Implantação: implantação do sistema e treinamento dos usuários. Manutenção e acompanhamento: esta fase segue por toda vida útil do sistema, onde são levantadas novas necessidades levando a um processo cíclico O papel da Modelagem de Dados no desenvolvimento de sistemas A maioria dos sistemas, principalmente os sistemas comerciais (Administrativos, Financeiros, Recursos Humanos, etc.), tem como característica o tratamento de muitas informações e poucos cálculos, diferente dos sistemas de uso científico (Cálculo estrutural, Redes Neurais, etc.) que possuem poucos dados e muitos cálculos. Com o objetivo de atender a todo tipo de sistema a Modelagem de Dados visa: Conhecer as informações dos usuários e como elas se relacionam: Saber exatamente quais as informações que deverão ser tratadas pelos sistemas, agrupandoas e verificando as relações entre elas. Criar uma linguagem comum entre analistas e usuários para que os conceitos possam ser claros e iguais para ambos: Auxiliar os analistas a entenderem e serem entendidos pelos usuários, fazendo uso de símbolos e notações. Os símbolos e notações na Modelagem de Dados servem para apresentar o projeto do sistema a ser construído em relação aos dados para validação pelo usuário. Criar uma base de conhecimento em relação às informações tratadas pela empresa: Criar um repositório único para todos os dados da empresa, disponibilizandoos de acordo com critérios de segurança aos usuários quando eles necessitarem. Projetar Bancos de Dados confiáveis, eficientes e com fácil escalabilidade: Evitar
8 8 informações redundantes e de difícil acesso, permitir que futuras alterações nos bancos de dados possam ser realizadas, garantir o uso adequado dos recursos do banco de dados utilizando o espaço de maneira otimizada. Unificar conceitos entre os diferentes departamentos da empresa: Fazer com que todos os departamentos se entendam e não haja conflitos de conceitos Análise de Dados x Análise de Processos As análises de dados e de processos são distintas, mas se complementam. Após levantar e mapear os processos e funções que serão tratados pelo sistema através da análise de processos, a análise de dados se preocupa com os dados que devem ser usados nos processos e gerados por eles. É importante que processos e dados sejam analisados exaustivamente e que tenham sido validados pelo usuário que fornece as informações ao analista para que não apareçam problemas nas etapas seguintes do desenvolvimento do sistema. Novas tecnologias de desenvolvimento (Componentização, Desenvolvimento em camadas, etc.), e as linguagens RAD (Rapid Application Development) diminuem o grau de importância da análise de processos e de dados, o que tem gerado sistemas com um tempo de programação muito rápido e com forte apelo visual, porém com uma estrutura funcional e de dados pobre, fazendo com que a manutenção seja extremamente difícil quando não impossível, e que não atende às expectativas dos usuários. Para auxiliar no processo de análise tanto de dados como de processos existem no mercado excelentes ferramentas denominadas CASE (Computer Aided Software Engineering), como o BPWin e o ERWin da Platinum Technologies e o System Architect da Computer Associates, que além de agilizarem a construção de diagramas de análise de processos e de dados, podem descobrir inconsistências, e ainda podem gerar scripts para criação dos bancos de dados e fazer engenharia reversa. Análise de Dados Analisa os dados gerados pelo usuário e por processos. Usa técnicas como Normalização de Dados e Modelo Entidade-Relacionamento (ER). Deve ser validado pelo usuário. É feito antes da programação. Análise de Processos Analisa os processos manuais e funções que devem ser informatizadas. Usa técnicas como Diagrama de Fluxo de Dados (DFD) e Análise Essencial. Deve ser validado pelo usuário. É feito antes da programação.
9 9 2. Normalização de Dados 2.1 Conceitos usados na Normalização de Dados A normalização de dados é uma técnica que visa analisar e refinar arquivos de dados, dividindoos em vários outros arquivos e estabelecendo relacionamentos entre eles através de informações comuns. Existem alguns conceitos que são utilizados na Normalização de Dados: Atributo Toda e qualquer informação de se deseja armazenar. Os atributos apresentam características como: tipo de informação a ser armazenada, tamanho, se é obrigatório ou opcional, se é condicionado a outros atributos, se possui várias ocorrências. Exemplo: cpf, nome, endereço, telefone, cargo Registro Conjunto de atributos que contém informações comuns de um determinado assunto. Exemplo: funcionário: dados de um funcionário, dados de um aluno Arquivo Conjunto de registros que tratam do mesmo assunto. Pode ser físico, quando as informações são guardadas em formulários de papel, ou eletrônico, quando as informações são armazenadas com a ajuda da informática. Exemplo: cadastro de clientes, cadastro de alunos Chave Atributo ou conjunto de atributos que permite a identificação única de um registro dentro de um arquivo. Pode ser classificada como: Simples: formada por um único atributo (RA, CPF). Composta: formada por mais de um atributo (Nº Nota Fiscal + Cód_Produto). Virtual: gerada por um atributo criado especificamente para ser chave e que tem seu valor gerado pelo sistema (operação bancária, protocolo de atendimento). Para que um atributo seja considerado chave, algumas características devem ser analisadas. Uma chave deve ser: Única: não podem existir mais de um registro como o mesmo valor para atributos que compõem a chave. Obrigatória: sempre deve existir um valor para os atributos que compõem a chave. Imutável:o valor dos atributos que compõem a chave não pode ser modificado. Exemplo: RA, chassi de um automóvel, cpf Dependência Funcional Característica de um atributo depender de outro, ou de outros atributos representarem uma informação completa. Ela pode ser verificada quando se analisa um atributo isoladamente e chega-se a conclusão de que por si só ele não representa uma informação completa. Normalmente os atributos de um registro dependem da chave do registro. Exemplo: código do produto em uma nota fiscal, código de um professor em uma disciplina.
10 2.2 Formas Normais 10 Formais normais são níveis de refinamento feitos em arquivos no processo de normalização. Pode-se chegar até 5 níveis de refinamento, mas na prática atingindo a 3 a forma normal (3FN) já garantimos um bom grau de normalização para nossos arquivos. Arquivos muito normalizados podem ter problemas de acesso quando implementados fisicamente nos SGBD s (Sistemas Gerenciadores de ) Primeira Forma Normal (1FN) Na primeira forma normal (1FN) o arquivo é organizado em uma estrutura bi-dimensional, ou seja, são criados registros compostos de colunas e linhas. Também deve ser identificada a chave do registro e eliminadas colunas com duplo significado, gerando mais colunas no arquivo normalizado. Exemplo (1FN): O Frigorífico Boi Morto possui um arquivo de vendas para os clientes. Nesse arquivo a data da venda e a data de entrega atualizam o mesmo atributo chamado de Data, não existe no arquivo um identificador único para o registro de venda. Usando as regras para transformar o arquivo para a primeira forma normal (1FN) criamos um atributo identificador para a venda (chave) e dividimos o atributo Data em dois novos atributos Data de venda e Data de Entrega. Arquivo de Vendas Data Data Cliente Número Nome do cliente Texto Endereco cliente Texto Produto-01 Número Descricao-01 Texto Quantidade-01 Número Preço-01 Número Produto-02 Número Descricao-02 texto Quantidade-02 Número Preço-02 Número Subtotal Número Desconto Número Valor total Número 1ª Forma Normal Arquivo de Vendas (1FN) Código da venda número Data da venda Data Data da entrega Data Cliente Número Nome do cliente Texto Endereco cliente Texto Produto-01 Número Descricao-01 Texto Quantidade-01 Número Preço-01 Número Produto-02 Número Descricao-02 texto Quantidade-02 Número Preço-02 Número Subtotal Número Desconto Número Valor total Número Segunda Forma Normal (2FN) Na Segunda forma normal (2FN) as informações que não têm dependência funcional com a chave do arquivo são separadas. Essa separação faz com que sejam gerados novos arquivos contendo as informações excluídas do arquivo normalizado, evitando problemas de anomalias de atualização (onde uma informação ao ser alterada exige a alteração de vários registros no mesmo arquivo), economiza-se espaço e garantem-se buscas mais rápidas. Ao separar as informações redundantes cria-se um atributo de referência no arquivo normalizado apontando para a chave do arquivo gerado, o que possibilita a obtenção da informação completa em outro arquivo. Exemplo (2FN): Eliminam-se atributos redundantes referentes ao cliente (nome e endereço) criando um novo arquivo chamado Clientes.
11 11 2ª Forma Normal Arquivo de Vendas (2FN) Código da venda número Data da venda Data Data da entrega Data Cliente Número Produto-01 Número Descricao-01 Texto Quantidade-01 Número Preço-01 Número Produto-02 Número Descricao-02 texto Quantidade-02 Número Preço-02 Número Subtotal Número Desconto Número Valor total Número Arquivo Clientes (2FN) Cliente Número Nome do cliente Texto Endereco cliente texto Terceira Forma Normal (3FN) Na Terceira forma normal (3FN), eliminam-se atributos multivalorados e atributos calculados. Atributos multivalorados são aqueles que se repetem no arquivo por várias vezes e a sua eliminação além de evitar redundâncias também permite que os limites pré-estabelecidos para a ocorrência de informações sejam ultrapassados, tornando o arquivo mais flexível. A separação de atributos multivalorados gera um novo arquivo que também pode ser normalizado. Atributos calculados são aqueles que podem ser gerados a partir de outros. Exemplo (3FN): Eliminam-se os atributos multivalorados referentes aos produtos vendidos, gerando um novo arquivo denominado Itens Vendidos; esse novo arquivo gerado pode então ser normalizado também para não conter informações redundantes de produtos (descrição) gerando o arquivo de Produtos. Como atributo calculado tem-se o Valor Total da venda que corresponde ao Sub-Total - Desconto. 3ª Forma Normal Arquivo de Vendas (3FN) Código da venda número Data da venda Data Data da entrega Data Cliente Número Subtotal Número Desconto Número Arquivo Clientes (3FN) Cliente Número Nome do cliente Texto Endereco cliente Texto Itens Vendidos (3FN) Número Venda Número Produto Número Quantidade Número Preço Número Arquivo Produtos (3FN) Produto Número Descricao Texto Preco Número Regras práticas para normalização de arquivos Para normalizar um arquivo não é obrigatório seguir uma sequência entre as formas normais, pode-se atingir um nível de normalização satisfatório (3FN ou maior) seguindo algumas regras práticas: Identificar a chave do arquivo: Importante para identificar as dependências funcionais. Separar os atributos que não dependam da chave: São os atributos redundantes e que representam anomalias de atualização e gasto extra de espaço. Criar um arquivo para atributos multivalorados: Permite que os atributos que eram limitados a um número de ocorrências, não tenham mais essa limitação. Eliminar os atributos calculados: Economiza espaço e garante confiabilidade, pois a informação será calculada em tempo de uso.
12 2.2.5 Até onde normalizar 12 Ao usarmos as técnicas de normalização de dados corremos o risco de fragmentar de tal forma a informação em múltiplos arquivos fazendo com que na etapa de implementação física dos bancos de dados o processo de recuperação da informação seja comprometido, isso porque para que tenhamos a informação consolidada o SGBD deverá efetuar várias operações para juntar os arquivos. Essas operações consomem recursos do SGBD e fazem com que haja maior acesso físico ao disco o que pode representar uma perda de desempenho. Ao normalizar seus arquivos use sempre o bom senso em relação ao resultado final e as condições onde esses arquivos serão implementados Desnormalização de dados A desnormalização de dados é o processo inverso à normalização, permitindo que os dados sejam armazenados em duplicidade gerando redundâncias. Existem casos bem específicos onde é necessário haver uma desnormalização de dados, alguns deles são: Para se manter um histórico de dados voláteis: um exemplo é um arquivo de itens de pedidos que contenha os atributos preço unitário do produto, caso seja necessário saber o preço unitário do produto no momento da venda deve-se criar esse atributo que já existe no arquivo de produtos, também no arquivo de itens de pedido, senão corre-se o risco de perder a informação do preço unitário no momento da criação do pedido, que não necessariamente deve ser igual ao preço unitário atual. Para minimizar processos de junção e aperfeiçoar as buscas: Nesse caso, quando for implementado o projeto físico pode ser necessária a duplicidade de atributos para melhorar o tempo de buscas, minimizando a junção entre arquivos. Por exemplo: podese criar um arquivo com o histórico de vendas de produtos por mês, apesar de essa informação ser uma informação calculada a partir de atributos já existentes no arquivo de itens de pedidos. Para minimizar cálculos: Pode-se criar arquivos, ou atributos calculados para minimizar processos de cálculos. Exercícios: 1) Quais as etapas no desenvolvimento de sistemas e qual a função de cada uma? 2) Qual a principal diferença entre sistemas comerciais e científicos? 3) Conceitue normalização de dados. 4) Explique qual a função de uma chave em um arquivo de dados. De que tipos podem ser? 5) O que são formas normais e para que servem? 6) Quais as regras para se normalizar um arquivo? Exemplifique. 7) Quando pode ser usada a desnormalização de dados? Explique.
13 13 3. Modelo Entidade Relacionamento (ER) O Modelo Entidade-Relacionamento, ou simplesmente modelo ER é uma técnica que visa representar através de um conjunto de símbolos, as informações armazenadas em arquivos e os relacionamentos entre essas informações. Com as técnicas de normalização de dados analisamos os dados necessários para executar processos e também os dados gerados por esses processos. Através do modelo ER poderemos fazer com que esse conjunto de dados seja entendido de maneira mais fácil pelo usuário através do uso de figuras (ícones). Essa visão única entre desenvolvedor e usuário é de fundamental importância para o sucesso na construção de um sistema, e o modelo ER contribui para isso usando figuras que são universais para auxiliar na comunicação. Então o que fazemos no final é levantar no mundo real as informações, organizá-ias de maneira eficiente através da normalização, e representar essa organização de uma forma gráfica para validação com o usuário através do modelo. 3.1 Elementos usados no modelo Entidade-Relacionamento Da mesma forma que na normalização de dados são conceituados alguns elementos (arquivo, registro, atributo, chave e dependência funcional), no modelo ER também vamos conceituar alguns termos usados e estabelecer uma relação entre eles e os termos usados na normalização de dados. Normalização Arquivo Registro Atributo Chave Modelo ER Entidade Instância Atributo Chave Primária Relação entre Normalização e Modelo ER Entidade Entidades são elementos do mundo real dos quais coletamos e armazenamos informações que serão utilizadas pelo sistema. Uma entidade pode ser: Um objeto: Uma máquina, peça, área geográfica, prédio, produto, etc. Uma pessoa: Um funcionário, cliente, paciente, etc. Um processo: O empréstimo de um livro, a aprovação de crédito bancário, etc.
14 Para descobrir que elementos em nossa análise são candidatos a entidade, devemos prestar atenção aos substantivos e ao sujeito de uma frase. Por exemplo, na frase: "Clientes são atendidos por vendedores para fazerem seus pedidos". Clientes, vendedores e pedidos são candidatos a entidade, mas além disso podemos levantar algumas questões: Existe a necessidade de se armazenar informações sobre esse elemento? Precisamos saber o nome, telefone, CGC e endereço de entrega para o cliente. Há mais de um elemento desse tipo? Existem vários pedidos a serem analisados Existe alguma informação que identifica univocamente o elemento analisado? O número de matrícula identifica de maneira única cada vendedor na empresa. 14 Pessoa Nome Idade Sexo Objeto Modelo Cor Fabricante Ano Codigo Data Qtde Processo Sub-Entidade Sub-Entidades são atributos de uma entidade que são separados gerando novas entidades. As sub-entidades são usadas quando em uma mesma entidade temos atributos que são usados para grupos diferentes de instâncias. Por exemplo, na entidade Clientes podemos ter um grupo de atributos específicos para clientes pessoa física (RG, CPF, Data de nascimento), e um grupo de atributos para clientes pessoa jurídica (CNPJ, Inscrição Estadual, Inscrição Municipal). Nesse caso poderíamos derivar a entidade Clientes em duas Sub-Entidades: Pessoa Física e Pessoa Jurídica. Existem dois processos para a geração de Sub-Entidades: Especialização: A partir de uma entidade principal derivamos as sub-entidades. É o caso do exemplo citado anteriormente de Clientes. Generalização: É o processo inverso, onde a partir de sub-entidades extraímos atributos comuns, gerando uma entidade principal. Por exemplo, a partir de atributos comuns (nome, endereço, telefone) entre as entidades Vendedores Externos e Vendedores Internos, geramos a entidade principal Vendedores. Clientes Código do Cliente Tipo do cliente Nome do cliente Endereço Telefone Pessoa Física Código do Cliente RG CPF Data de nascimento Pessoa Jurídica Código do Cliente CNPJ Insc. Estadual Insc. Municipal Exemplo de Sub-entidade por especialização
Modelo Entidade-Relacionamento Banco de Dados I Fases do Projeto jt de BD Enunciado de requisitos entrevista com o usuário do banco de dados para entender e documentar seus requerimentos de dados. Projeto
BANCO DE DADOS PROFESSOR MAURÍCIO - MAURICIO.MELLO@PUCPR.BR AULA 02. O Modelo Entidade-Relacionamento ( MER )
AULA 02 BANCO DE DADOS PROFESSOR MAURÍCIO - MAURICIO.MELLO@PUCPR.BR O Modelo Entidade-Relacionamento ( MER ) Fases do Projeto de Bases de Dados (EN94)- O Modelo Entidade- Relacionamento Definição : modelo
Prof. Alexandre Unterstell Banco de Dados I
Prof. Alexandre Unterstell Banco de Dados I Etapas para o projeto de um BD Análise de requisitos Analista: Entrevista Necessidade do negócio As etapas não consideram ainda nenhuma característica específica
Curso Superior de Tecnologia em BD Modelagem de Dados Aula 01 Revisão Modelos de Dados Existem modelos para diferentes níveis de abstração de representação de dados modelos conceituais modelos lógicos
Modelagem dos dados. entendo. Reino Real. Reino. Representação
Modelagem dos dados entendo Reino Real Reino Imaginário (modelagem) Reino Representação represento Nós não somos capazes de representar tudo o que imaginamos. Nós somente representamos o que é interessante.
Fernando Fonseca Ana Carolina
Banco de Dados Ciclo de Desenvolvimento de Sistemas de BD Investigação dos Dados Modelagem dos Dados Modelagem Conceitual Projeto do Banco de Dados Fernando Fonseca Ana Carolina Implementação do Banco
Banco de Dados 1 2º Semestre
Banco de Dados 1 2º Semestre Aula 07 Prof. Gladimir Ceroni Catarino gladimir@gmail.com SERVIÇO NACIONAL DE APRENDIZAGEM COMERCIAL FACULDADE DE TECNOLOGIA SENAC PELOTAS o Uma coletânea de conceitos que
Banco de Dados Modelo Entidade-Relacionamento. Frederico D. Bortoloti freddb@ltc.ufes.br
Banco de Dados Modelo Entidade- Frederico D. Bortoloti freddb@ltc.ufes.br Modelo Entidade- Proposto por Peter Chen, em 1976 Baseado na percepção do mundo real Consiste de um conjunto de objetos básicos
Banco de Dados. Modelagem de Dados com MER. Prof. Walteno Martins Parreira Jr www.waltenomartins.com.br waltenomartins@yahoo.
Banco de Dados Modelagem de Dados com MER Prof. Walteno Martins Parreira Jr www.waltenomartins.com.br waltenomartins@yahoo.com 2015 Modelagem de Dados Modelagem de Dados tem como objetivo transformar uma
Banco de Dados - Senado Introdução Ilka Kawashita Material preparado :Prof. Marcio Vitorino Ementa do Curso n Banco de Dados n Sistemas de Apoio à Decisão (SAD) n ORACLE BANCO DE DADOS (BD) n Modelo Entidade
PARTE I Lista de exercícios 01 1. Defina os seguintes termos: entidade, atributo, valor do atributo, atributo composto, atributo multivalorado, atributo derivado, atributo-chave, domínio. 2. Explique as
Introdução a Banco de Dados e Access
Roteiro Introdução a Banco de Dados e Access Isabel Harb Manssour. Conceitos Básicos B de Banco de Dados. 3. 4. Porto Alegre, maio de 007 Baseado no material das professoras Miriam Sayão, Adriana Beiler
Universidade Estadual de Campinas - UNICAMP Instituto de Computação - IC MC536 Bancos de Dados: Teoria e Prática Aula #3 : MER e MER Estendido Profs. Anderson Rocha e André Santanchè Campinas, 1 de Agosto
Introdução a Banco de Dados e Access Edson Ifarraguirre Moreno Porto Alegre, maio de 2011 Baseado no material da professora Isabel Harb Manssour Roteiro 1. Conceitos Básicos de BD 2. Microsoft Access 3.
Capítulo 5 Complemento. 5.1 Laudon, Cap. 5
Capítulo 5 Complemento Fundamentos de Bancos de Dados: Modelo de Entidade e Relacionamento - MER 5.1 Laudon, Cap. 5 Modelo mais utilizado: simplicidade e eficiência. Banco de dados relacional. Base: percepção
Ciclo de vida de um banco de dados relacional
Ciclo de vida de um banco de dados relacional 1. Formulação e análise de requisitos: a) Relacionamentos naturais entre os dados (independentes de processo). b) Requisitos de uso (dependentes de processo).
I Requisitos de um modelo conceitual: - clareza (facilidade de compreensão) - exatidão (formal)
Modelagem Conceitual C O objetivo É: Representar a semântica da informação, independente de considerações de eficiência. D O objetivo NÃO É: Descrever a estrutura do armazenamento do banco de dados. I
Descreve relacionamentos entre objetos de dados; conduz à modelagem de dados; atributos de cada objeto => Descrição de Objetos de Dados;
Diagrama Entidade-Relacionamento (DER) Descreve relacionamentos entre objetos de dados; conduz à modelagem de dados; atributos de cada objeto => Descrição de Objetos de Dados; Profa. Maria Auxiliadora
Unidade II ADMINISTRAÇÃO DE. Prof. Luiz Fernando de Lima Santos
Unidade II ADMINISTRAÇÃO DE BANCOS DE DADOS Prof. Luiz Fernando de Lima Santos Modelagem de Dados Coleção de ferramentas conceituais para descrever dados, suas relações e restrições Modelo Conceitual:
Ciclo de Desenvolvimento de Sistemas de BD
Gerenciamento de Dados e Informação Fernando Fonseca Ana Carolina Valeria Times Bernadette Loscio Robson Nascimento Ciclo de Desenvolvimento de Sistemas de BD Investigação dos Dados Modelagem dos Dados
Disciplina: Unidade II: Prof.: E-mail: Período:
Encontro 03 Disciplina: Sistemas de Banco de Dados Unidade II: Modelagem Conceitual de Dados Prof.: Mario Filho E-mail: pro@mariofilho.com.br Período: 5º. SIG - ADM 2. Modelagem Conceitual de Dados (Modelo
Modelagem de Dados Usando o Modelo Entidade-Relacionamento
Usando o Modelo Entidade-Relacionamento MER 1 MER Levantamento e Análise de requisitos Entrevista Entender e documentar seus requisitos de dados Requisitos funcionais da aplicação empregadas ao banco de
Profa. Daniela Barreiro Claro
Profa. Daniela Barreiro Claro Modelar é criar representações do mundo real A modelagem relacional pode ser representada via MER (Modelo de Entidade Relacionamento) O MER define estruturas e restrições
Exemplo de Necessidade de Modelagem de Dados. Exemplo de Necessidade de Modelagem de Dados
Exemplo de Necessidade de Modelagem de Dados 1 Exemplo de Necessidade de Modelagem de Dados 2 1 Exemplo de Necessidade de Modelagem de Dados 3 Exemplo de Necessidade de Modelagem de Dados 4 2 Exemplo de
AULA 11-12. Entidade-Relacionamento
AULA 11-12 Modelo Conceitual, Lógico e Físico, Entidade-Relacionamento Curso: Técnico em Informática (Integrado) Disciplina: Banco de Dados Prof. Abrahão Lopes abrahao.lopes@ifrn.edu.br Modelos de banco
OBJETIVOS. Orientações para Projetos de BD; Dependências Funcionais (DFs): Definição de DF; Regras de inferência para DFs.
BANCO DE DADOS Universidade do Estado de Santa Catarina Centro de Ciências Tecnológicas Departamento de Ciência da Computação Prof. Alexandre Veloso de Matos alexandre.matos@udesc.br OBJETIVOS Orientações
Introdução à Banco de Dados
Introdução à Banco de Dados Introdução à Banco de Dados Agenda O que é Banco de Dados Como ele funciona Sistema Gerenciador de Banco de Dados Modelagem de Dados Modelo de dados Entidade-Relacionamento
Projeto e Implementação
Felipe Nery Rodrigues Machado Banco de Dados Projeto e Implementação 2 Edição 4 Reimpressão São Paulo 2011 Editora Érica Ltda. 3 Projeto Sumário Capítulo 1 O Que É Projeto de Banco de Dados 15 Modelagem
Banco de Dados. Arquitetura e Terminologia. Prof. Walteno Martins Parreira Jr www.waltenomartins.com.br waltenomartins@yahoo.
Banco de Dados Arquitetura e Terminologia Prof. Walteno Martins Parreira Jr www.waltenomartins.com.br waltenomartins@yahoo.com 2015 Modelo de Dados e Esquemas O modelo de Banco de Dados é como um detalhamento
Modelo de Entidade e Relacionamento (MER) - Parte 07
Modelo de Entidade e Relacionamento (MER) - Parte 07 7.1 Definição Consiste em mapear o mundo real do sistema em um modelo gráfico que irá representar o modelo e o relacionamento existente entre os dados.
CIn/UFPE Projeto Conceitual de BD - Prof. Robson Fidalgo 1
CIn/UFPE Projeto Conceitual de BD - Prof. Robson Fidalgo 1 Projeto Conceitual de BD Transformação ER/Relacional Por: Robson do Nascimento Fidalgo rdnf@cin.ufpe.br CIn/UFPE Projeto Conceitual de BD - Prof.
O Modelo de Entidades e Relacionamentos (MER) é um modelo conceitual usado para projeto de aplicações de banco de dados.
Fases do Projeto de um Banco de Dados Modelo ER O Modelo de Entidades e Relacionamentos (MER) é um modelo conceitual usado para projeto de aplicações de banco de dados. É um modelo baseado na percepção
Banco de Dados Modelo Conceitual, Lógico, Físico, Entidade- Relacionamento (ER) Hélder Nunes
Banco de Dados Modelo Conceitual, Lógico, Físico, Entidade- Relacionamento (ER) Hélder Nunes Modelos de banco de dados Modelo de banco de dados é uma descrição dos tipos de informações que estão armazenadas
Modelo Entidade-Relacionamento. Prof. Antonio Almeida de Barros Jr.
Modelo Entidade-Relacionamento Prof. Antonio Almeida de Barros Jr. Conteúdo Contexto Histórico A Importância da Modelagem de Dados Projeto de Banco de Dados Modelagem Conceitual Projeto Lógico Projeto
ENGENHARIA DA COMPUTAÇÃO BANCO DE DADOS I CONTEÚDO 5 ABORDAGEM RELACIONAL
ENGENHARIA DA COMPUTAÇÃO BANCO DE DADOS I CONTEÚDO 5 ABORDAGEM RELACIONAL PROF. MS C. RICARDO ANTONELLO WWW.ANTONELLO.COM.B R PORQUE SER RELACIONAL? Hoje, há um claro predomínio dos SGBD relacionais, principalmente
Banco de Dados - Senado Modelo Relacional Ilka Kawashita Material preparado :Prof. Marcio Vitorino Abordagem Relacional n Abordagem de modelagem de dados utilizada nos sistemas de gerenciamento de bancos
Banco de Dados Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br 1 Processo de Projeto de Banco de Dados Minimundo Projeto Lógico (Mapeamento do Modelo de Dados) 1 4 Esquema Lógico (Modelo do SGBD)
Modelos. Comunicação com clientes
Material baseado nas notas de aula: Maria Luiza M. Campos IME/2005 Carlos Heuser - livro Projeto de Banco de Dados CasaNova / PUC/RJ Prof. MSc. Edilberto Silva edilms@yahoo.com Sistemas de Informação Brasília/DF