mmmmmmmmmm

 

Embed or link this publication

Description

mmmmmmmmmmmmmmmmmmmmmmmm

Popular Pages


p. 1

http groupsbeta.google.com/group/digitalsource

[close]

p. 2

projeto de banco de dados carlos a heuser © carlos a heuser 1998 a publicação comercial deste texto está planejada ele deve ser considerado como comunicação pessoal do autor

[close]

p. 3



[close]

p. 4

5wo±tkq qs@aÈ8dp w diusp9vdp 7hpÃqrÃ9hq 1.1.1 1.1.2 compartilhamento de dados sistema de gerência de banco de dados hqryÃqrÃ7hpÃqrÃ9hq 2 4 1.2.1 1.2.2 1.2.3 modelo conceitual modelo lógico modelo conceitual como modelo de organização qwrÃqrÃ79 5 6 7 @rptpv srsrrpvhÃ7viyvtisvph 67ps96b@hÃ@iud969@s@g68dpi6h@iup @vqhqr sryhpvhr 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6 2.2.7 conceituação cardinalidade de relacionamentos cardinalidade máxima classificação de relacionamentos binários relacionamento ternário cardinalidade mínima exemplo de uso de entidades e relacionamentos 6vi 13 15 16 17 19 20 21 2.3.1 2.3.2 identificando entidades identificando relacionamentos brrhyvhomrrpvhyvhom @vqhqrÃhpvhvh @rhÃtisvpÃrÃÃrhvÃqrÃqryÃ@s 24 27 @rptpv srsrrpvhÃ7viyvtisvph 8pitusvdi9pÃhp9@gptÃ@s qvrqhqrÃqrÃqryÃ@s 3.1.1 3.1.2 3.1.3 um modelo er é um modelo formal abordagem er têm poder de expressão limitado diferentes modelos podem ser equivalentes dqrvsvphqÃpo}r 44 44 46 3.2.1 3.2.2 3.2.3 atributo versus entidade relacionada atributo versus generalização/especialização atributos opcionais e multi-valorados 48 49 50

[close]

p. 5

wrvsvphomÃqÃqry 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 modelo deve ser correto modelo deve ser completo modelo deve ser livre de redundâncias modelo deve refletir o aspecto temporal entidade isolada e entidade sem atributos @hiryrprqÃhq}r 53 53 54 55 59 3.4.1 3.4.2 variantes de modelos er uso de ferramentas de modelagem @hptvhÃqrÃqryhtr 59 62 3.5.1 3.5.2 partindo de descrições de dados existentes partindo do conhecimento de pessoas 64 64 @rptpv srsrrpvhÃ7viyvtisvph 67ps96b@hÃs@g68dpi6g 8vomÃqrÃÃ7hpÃqrÃÃ9hqÃsryhpvhy 4.1.1 4.1.2 4.1.3 4.1.4 tabelas chaves domínios e valores vazios restrições de integridade @rpvsvphomÃqrÃihpÃqrÃqhqÃryhpvhy 8yhÃjÃihrÃqrÃqhq 76 77 80 80 @rptpv srsrrpvhÃ7viyvtisvph us6itapsh6d®@tÃ@ius@Ãhp9@gpt wvmÃtrhyÃqÃwrÃyytvp uhshomÃ@sÃhhÃryhpvhy 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 implementação inicial de entidades implementação de relacionamentos detalhes da implementação de relacionamentos implementação de generalização/especialização refinamento do modelo relacional @truhvhÃrrhÃqrÃqryÃryhpvhv 89 91 93 100 105 5.3.1 5.3.2 5.3.3 5.3.4 identificação da construção er correspondente a cada tabela identificação de relacionamentos 1:n ou 1:1 definição de atributos definição de identificadores de entidades 110 111 113 113

[close]

p. 6

@rptpv srsrrpvhÃ7viyvtisvph @ib@ic6sd6Ãs@w@st6Ã9@Ã6srvdwptÃ@Ãipsh6gda6dp dqom wvmÃtrhyÃqÃprÃqrÃrtruhvhÃrrh 9prÃ@ry srrrhomÃhÃshÃqrÃhiryhÃmÃhyvhqh ihyvhom 6.5.1 6.5.2 6.5.3 6.5.4 6.5.5 6.5.6 passagem à primeira forma normal 1fn dependência funcional passagem à segunda forma normal 2fn passagem à terceira forma normal 3fn passagem à quarta forma normal problemas da normalização drthomÃqrÃqry 125 129 130 133 136 139 6.6.1 6.6.2 6.6.3 integração de tabelas com mesma chave integração de tabelas com chaves contidas volta à 2fn 8omÃqÃqryÃ@sÃrÃ@yvvhomÃqrÃsrqqkpvh wrvsvphomÃqÃqryÃ@sÃÃgvvho}rÃqhÃihyvhom 141 143 144 @rptpv srsrrpvhÃ7viyvtisvph tpgvd®@tÃ9@Ã@y@s8Ë8dptÃt@g@8dpi69pt Ëi9d8@Ãs@hdttdwp

[close]

p. 7



[close]

p. 8

2tgh±ekq objetivos do livro sistemas de gerência de banco de dados sgbd surgiram no início da década de 70 com o objetivo de facilitar a programação de aplicações de banco de dados bd os primeiros sistemas eram caros e difíceis de usar requerendo especialistas treinados para usar o sgbd específico nessa mesma época houve um investimento considerável de pesquisa na área de banco de dados esse investimento resultou em um tipo de sgbd o sgbd relacional a partir da década de 80 e devido ao barateamento das plataformas de hardware/software para executar sgbd relacional este tipo de sgbd passou a dominar o mercado tendo se convertido em padrão internacional o desenvolvimento de sistemas de informação ocorre hoje quase que exclusivamente sobre banco de dados com uso de sgbd relacional além do sgbd relacional as pesquisas na área de bd resultaram também em um conjunto de técnicas processos e notações para o projeto de bd o projeto de bd que inicialmente era feito com técnicas empíricas por alguns poucos especialistas no sgbd específico é executado hoje com auxilio de técnicas padronizadas e suportadas por ferramentas case formou-se ao longo do tempo um conjunto de conhecimentos sobre projeto de bd que é largamente aceito e deve ser dominado por qualquer profissional de informática estes conhecimentos são ministrados nas universidades já em cursos de graduação nas disciplinas de fundamentos de banco de dados ou mesmo em disciplinas específicas de projeto de banco de dados o projeto de um banco de dados usualmente ocorre em três etapas a primeira etapa a modelagem conceitual procura capturar formalmente os requisitos de informação de um banco de dados a segunda etapa o projeto lógico objetiva definir a nível de sgbd as estruturas de dados que implementarão os requisitos identificados na modelagem conceitual a terceira etapa o projeto físico define parâmetros físicos de acesso ao bd procurando otimizar a performance do sistema como um todo este livro objetiva ensinar o projeto de banco de dados cobrindo as duas primeiras etapas do ciclo de vida de um banco de dados a da modelagem conceitual e a do projeto lógico na modelagem conceitual o livro utiliza a abordagem entidade-relacionamento er de peter chen considerada hoje um padrão de facto de modelagem de dados além de apresentar os conceitos e notações da abordagem er o livro apresenta regras e heurísticas para construção de modelos com referência ao projeto lógico o livro cobre tanto o projeto propriamente dito transformação de modelos er em modelos relacionais quanto a

[close]

p. 9

engenharia reversa de bd extração de modelo conceitual a partir de modelo lógico relacional ou de arquivos convencionais público alvo o livro objetiva atender a três públicos distintos o primeiro é o de alunos de graduação de ciência da computação de informática ou cursos semelhantes o livro foi concebido para ser usado no ensino de uma primeira abordagem ao tema o que normalmente ocorre em disciplinas de fundamentos de banco de dados ou projeto de banco de dados correspondente a matéria obrigatória t3 do currículo de referência 96 da sbc o livro se origina de notas de aula que escrevi para suportar parte de uma disciplina que ministro há vários anos no curso de bacharelado em ciência da computação da ufrgs para cobrir todo livro necessita-se pelo menos 20 horas/aula se forem executados alguns dos estudos de caso apresentados este tempo deve ser estendido outro público é o daqueles profissionais de informática que em sua formação não tiveram contato com os modelos e técnicas envolvidas no projeto de banco de dados neste caso o livro pode ser usado para auto-estudo ou para suporte a cursos de extensão ou de especialização em projeto de banco de dados mesmo para profissionais que já conheçam modelagem de dados o livro pode ser útil por apresentar um método para engenharia reversa de banco de dados este método é importante na atualidade visto que muitas organizações contam com sistemas legados e estão envolvidas na tarefa de migrar estes sistemas para bancos de dados relacionais um terceiro público é o de usuários de sgbd pessoais que desejem sistematizar o projeto de seus bancos de dados para este leitores a parte referente a engenharia reversa provavelmente será demasiado avançada entretanto o restante do livro é perfeitamente compreensível para aqueles que têm conhecimentos apenas introdutórios de informática organização o livro está organizado de forma a não exigir conhecimentos prévios na área de banco de dados ou de engenharia de software o capítulo 1 apresenta os conceitos básicos de banco de dados necessários à compreensão de restante do texto ali são introduzidos conceitos como banco de dados modelo de dados sistema de gerência de banco de dados modelo conceitual e modelo lógico se o leitor já dominar estes conceitos poderá perfeitamente omitir este capítulo o capítulo 2 está dedicado a apresentar a abordagem entidade-relacionamento o objetivo do capítulo é ensinar os conceitos básicos do modelo er e a notação gráfica para apresentação dos modelos como não há uma notação universalmente aceita para diagramas er neste capítulo preferi usar a notação original de peter chen são apresentados tanto os conceitos básicos de entidade atributo e relacionamento quanto extensões do er em direção a modelos semânticos como o conceito de generalização/especialização e entidade associativa.

[close]

p. 10

enquanto o capítulo 2 objetiva a compreensão de modelos entidaderelacionamento o capítulo 3 objetiva a construção de modelos er além de apresentar o processo de modelagem o capítulo inclui uma série de heurísticas a usar na construção de modelos além disso são discutidas notações alternativas a de peter chen o capítulo 4 é uma introdução ao modelo relacional não se trata aqui de mostrar de forma completa o funcionamento de sgbd relacional mas apenas de transmitir o conhecimento mínimo necessário para a compreensão do restante do livro novamente caso o leitor já conheça a abordagem relacional poderá omitir este capítulo o capítulo 5 apresenta procedimentos para executar dois tipos de transformações entre modelos de dados uma transformação é o projeto lógico de banco de dados relacional ou seja a transformação de um modelo er em um modelo relacional a outra transformação é a engenharia reversa de banco de dados relacional ou seja a transformação de um modelo lógico de banco de dados relacional em modelo conceitual finalmente o capítulo 6 cobre a engenharia reversa de arquivos ou seja apresenta um conjunto de regras para transformar a descrição de um conjunto de arquivos convencionais em um modelo de dados relacional o conjunto de regras está baseado na normalização de banco de dados relacional que é apresentada no capítulo por tratar-se de um texto introdutório são apresentadas apenas as formas normais da primeira a quarta.

[close]

p. 11



[close]

p. 12

%crÃvwnq +pvtqfw¼µq este capítulo apresenta os conceitos básicos da área de banco de dados que são necessário à compreensão do projeto de banco de dados são apresentados conceitos como banco de dados sistema de gerência de banco de dados e modelo de dados além disso é fornecida uma visão geral do projeto de banco de dados o leitores que já conhece os fundamentos de banco de dados provavelmente poderá passar diretamente ao próximo capítulo.

[close]

p. 13

à $5h7iÂ89Â858is à 7yguxtgyqÂpqÂpgp muitas vezes a implantação da informática em organizações ocorre de forma evolutiva e gradual inicialmente apenas determinadas funções são automatizadas mais tarde à medida que o uso da informática vai se estabelecendo novas funções vão sendo informatizadas para exemplificar vamos considerar uma indústria hipotética consideramos que nesta indústria são executadas três funções u vendas esta função concentra as atividades da indústria relativas ao contato com os clientes como fornecimento de cotações de preços vendas e informações sobre disponibilidade de produtos u produção esta função concentra as atividades da indústria relativas à produção propriamente dita como planejamento da produção e controle do que foi produzido u compras esta função concentra as atividades da indústria relativas à aquisição dos insumos necessários à produção como cotações de preços junto a fornecedores compras e acompanhamento do fornecimento no exemplo mencionado acima os dados de um produto são usados em várias funções estes dados são necessários no planejamento de produção pois para planejar o que vai ser produzido é necessário conhecer como os produtos são estruturados quais seus componentes e como são produzidos os dados de produto também são necessários no setor de compras pois este necessita saber que componentes devem ser adquiridos já o setor de vendas também necessita conhecer dados de produtos como por exemplo seu preço seu estoque atual seu prazo de fabricação etc se cada uma das funções acima for informatizada de forma separada sem considerar a informatização das demais funções pode ocorrer que para cada uma das funções seja criado um arquivo separado de produtos ver figura 1.1 qqom wrqh 8h 6vÃqom 3urgxwrv « 6vÃrqh 3urgxwrv « 6vÃph 3urgxwrv « @usgÂÂsuqygÂuxgp

[close]

p. 14

neste caso surge o problema da redundância de dados redundância de dados ocorre quando uma determinada informação está representada no sistema em computador várias vezes no caso do exemplo estão redundantes as informações referentes a um produto que aparecem nos arquivos de produtos de cada um dos três sistemas há duas formas de redundância de dados a redundância controlada de dados e a redundância não controlada de dados a redundância controlada de dados acontece quando o software tem conhecimento da múltipla representação da informação e garante a sincronia entre as diversas representações do ponto de vista do usuário externo ao sistema em computador tudo acontece como se existisse uma única representação da informação essa forma de redundância é utilizada para melhorar a performance global do sistema um exemplo é um sistema distribuído onde uma mesma informação é armazenada em vários computadores permitindo acesso rápido a partir de qualquer um deles a redundância não controlada de dados acontece quando a responsabilidade pela manutenção da sincronia entre as diversas representações de uma informação está com o usuário e não com o software este tipo de redundância deve ser evitado pois traz consigo vários tipos de problemas u redigitação a mesma informação é digitada várias vezes no caso do exemplo da indústria os dados de um produto são digitados no setor de vendas no setor de produção e no setor de compras além de exigir trabalho desnecessário a redigitação pode resultar em erros de transcrição de dados u inconsistências de dados a responsabilidade por manter a sincronia entre as informações é do usuário por erro de operação pode ocorrer que uma representação de uma informação seja modificada sem que as demais representações o sejam exemplificando uma alteração na estrutura de um determinado produto pode ser informada através do sistema de produção e deixar de ser informada nos demais sistemas a estrutura do produto passa a aparecer de forma diferente nos vários sistemas o banco de dados passa a ter informações inconsistentes a solução para evitar a redundância não controlada de informações é o compartilhamento de dados nesta forma de processamento cada informação é armazenada uma única vez sendo acessada pelos vários sistemas que dela necessitam figura 1.2 ao conjunto de arquivos integrados que atendem a um conjunto de sistemas dá-se o nome de banco de dados bd banco de dados conjunto de dados integrados que tem por objetivo atender a uma comunidade de usuários

[close]

p. 15

@b_te|z fu^tqc 3 bqc 2q^s_tutqt_c @b_ted_c « @usg ÂsuqygÂuqsgpÂiyÂpgpÂiyguxtgp o compartilhamento de dados tem reflexos na estrutura do software a estrutura interna dos arquivos passa a ser mais complexa pois estes devem ser construídos de forma a atender às necessidades dos diferentes sistemas para contornar este problema usa-se um sistema de gerência de banco de dados conforme descrito na próxima seção à suqygÂpqÂaq¿iugÂpqÂ6giÂpqÂ8gp a programação de aplicações em computadores sofreu profundas modificações desde seus primórdios no início quando usavam-se linguagens como cobol basic c e outras os programadores incorporavam em um programa toda funcionalidade desejada o programa continha as operações da interface de usuário as transformações de dados e cálculos as operações de armazenamento de dados bem como as tarefas de comunicação com outras sistemas e programas com o tempo foram sendo identificadas funcionalidades comuns a muitos programas por exemplo hoje em dia a grande maioria dos programas comunica-se com os usuários através de interfaces gráficas de janelas entretanto normalmente os programas não contém todo código referente a exibição dos dados na interface mas utilizam gerenciadores de interface de usuário conjuntos de rotinas que incluem as funcionalidades que um programador vai necessitar freqüentemente ao construir uma interface de usuário da mesma forma para comunicar-se com processos remotos usam gerenciadores de comunicação para manter grandes repositórios compartilhados de dados ou seja para manter bancos de dados são usados sistemas de gerência de banco de dados sgbd sistema de gerência de banco de dados software que incorpora as funções de definição recuperação e alteração de dados em um banco de dados essa modularização de programas tem várias vantagens a manutenção de programas torna-se mais simples pois uma separação clara de funções torna programas mais facilmente compreensíveis a produtividade de progra-

[close]

Comments

no comments yet

YOUBLISHER
About
What Others Say
Sitemap
Impressum

PUBLISHERS
Login
Signup
Tutorials
FAQ
Support

BUSINESS
Overview
Advertising
Support

DEVELOPERS
API

LEGAL
Report a Copyright Violation
Copyright FAQ
Terms of Use
Privacy Policy