Projeto de Banco de Dados

Visualizações: 620
Classificação: (0)

Em sua sexta edição e adotado por faculdades de todo o Brasil, Projeto de Banco de Dados aborda as duas primeiras etapas do ciclo de vida de um banco de dados: modelagem conceitual e projeto lógico.

FORMATOS DISPONíVEIS

eBook

Disponível no modelo assinatura da Minha Biblioteca

7 capítulos

Formato Comprar item avulso Adicionar à Pasta

1 introdução

PDF Criptografado

20

Projeto de Banco de Dados

1.1

1.1.1

banco de dados compartilhamento de dados

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, na qual são executadas três funções:

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. produção – esta função concentra as atividades da indústria relativas

à produção, como planejamento da produção e controle do que foi produzido. 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 acima, os dados de um produto são usados em várias funções. Estes dados são necessários na função Produção, no planejamento da 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 na função Compras, pois nesta função é necessário saber quais componentes devem ser adquiridos. Já na função Vendas, também é necessário conhecer dados de produtos, como seu preço, seu estoque atual, seu prazo de fabricação, etc.

 

2 abordagem entidade-relacionamento

PDF Criptografado

34

Projeto de Banco de Dados

A técnica de modelagem de dados mais difundida e utilizada é a abordagem entidade-relacionamento(ER). Nesta técnica, o modelo de dados é representado através de um modelo entidade-relacionamento (modelo ER). Geralmente, um modelo ER é representado graficamente através de um diagrama entidade-relacionamento (DER). A abordagem ER foi criada em 1976 por

Peter Chen, podendo ser considerada como um padrão de fato para a modelagem conceitual. Mesmo as técnicas de modelagem orientada a objetos, que têm surgido nos últimos anos, como a UML, baseiam-se nos conceitos da abordagem ER.

Este capítulo apresenta os conceitos centrais da abordagem ER: entidade, relacionamento, atributo, generalização/especialização e entidade associativa.

Junto com estes conceitos, é apresentada uma notação gráfica para diagramas ER. A notação gráfica usada no capítulo é a notação originalmente introduzida por Peter Chen. No capítulo 3, são discutidas as principais notações usadas na prática para construir diagramas ER.

 

3 construindo modelos ER

PDF Criptografado

72

3.1

Projeto de Banco de Dados

propriedades de modelos ER

Nesta seção, discutimos algumas propriedades de modelos ER relevantes para a modelagem ER.

3.1.1

um modelo ER é um modelo formal

Um modelo ER é um modelo formal, preciso, não ambíguo. Isto significa que diferentes leitores de um mesmo modelo ER devem sempre entender exatamente o mesmo. Tanto é assim, que um modelo ER pode ser usado como entrada a uma ferramenta CASE (Computer Aided Software Engineering)1 na geração de um banco de dados relacional. Por isso, é de fundamental importância que todos os envolvidos na confecção e no uso de diagramas ER sejam devidamente treinados.

Observa-se, em certas organizações, que modelos ER são subutilizados, servindo apenas como ferramenta para a apresentação informal de idéias. Isso pode ser evitado com treinamento formal de todos os envolvidos na modelagem e no projeto do banco de dados.

É importante que todos os que manipulam modelos ER sejam treinados para compreendê-lo. O fato de um DER ser gráfico e intuitivo pode transmitir a falsa impressão de ser compreensível até por alguém não treinado.

 

4 abordagem relacional

PDF Criptografado

120

Projeto de Banco de Dados

Especificamente, o capítulo detalha como um banco de dados relacional

é organizado (que estruturas de dados são usadas, como elas estão relacionadas), mas não discute como um banco de dados relacional pode ser modificado ou acessado, ou seja, não apresenta as linguagens de manipulação de dados, como SQL. Para maiores detalhes sobre sistemas de BD relacionais, o leitor deve procurar livros específicos (ver leituras recomendadas deste capítulo).

Além dos SGBDs relacionais, existem outros tipos de sistemas no mercado.

Entretanto, hoje, há um claro predomínio dos SGBDs relacionais, principalmente fora das plataformas de grande porte. Mesmo nestes ambientes, os

SGBD relacionais estão gradativamente substituindo os SGBDs de outras abordagens (hierárquica, rede, sistemas proprietários). Além disso, muitos conceitos usados no projeto de BD, como o conceito de normalização, foram criados em combinação com a abordagem relacional. Por esses motivos, vamos considerar unicamente a abordagem relacional neste livro.

 

5 transformações entre modelos

PDF Criptografado

136

Projeto de Banco de Dados

Inicialmente, vamos apresentar o projeto lógico de BD relacional. O projeto lógico consta da transformação de um modelo ER em um modelo lógico, que implementa, em nível de SGBD relacional, os dados representados abstratamente no modelo ER. O termo “implementação” significa que ocorre uma transformação de um modelo mais abstrato para um modelo que contém mais detalhes de implementação. Neste livro somente o projeto de BD relacional é tratado. Para outros tipos de SGBD (p.ex.: orientado a objetos ou objeto/relacional) outras regras de projeto são necessárias.

Após discutir o projeto lógico, vamos apresentar o processo inverso ao projeto, chamado de engenharia reversa de modelos relacionais. Neste processo, partese de um modelo relacional e obtém-se um diagrama ER, que representa de forma abstrata os dados armazenados no BD.

A Figura 5.1 dá uma visão geral dos dois processos de transformação entre modelos.

modelo ER

(nível conceitual)

engenharia reversa de BD relacional

 

6 engenharia reversa de arquivos e normalização

PDF Criptografado

184

6.1

Projeto de Banco de Dados

introdução

Muitos dos sistemas de informação hoje usados foram desenvolvidos ao longo dos últimos 20 anos e não utilizam bancos de dados relacionais, sendo chamados de sistemas legados (legacy systems). Os dados desses sistemas estão armazenados em arquivos de linguagens de terceira geração, como COBOL ou Basic, ou então em bancos de dados da era pré-relacional, como IMS ou ADABAS. Raramente, os arquivos destes sistemas estão documentados através de modelos conceituais.

Adicionalmente, há bancos de dados relacionais que não possuem documentação na forma de um modelo conceitual.

No entanto, há situações no ciclo de vida de um sistema nas quais um modelo conceitual é de grande valia.

Um exemplo é a manutenção rotineira do software de um sistema de informações. Neste caso, o modelo conceitual pode ser usado como documentação abstrata dos dados, durante discussões entre usuários, analistas e programadores. A existência de um modelo conceitual permite que pessoas que não conheçam o sistema possam aprender mais rapidamente o seu funcionamento.

 

7 soluções de exercícios selecionados

PDF Criptografado

230

Projeto de Banco de Dados

■ exercício 2.4

Grande parte do exercício está resolvida na Seção modelos ER têm poder de expressão limitado (página 73). Lá é apresentado um diagrama de ocorrências no qual:

uma pessoa pode estar casada com ela mesma e uma pessoa pode participar de dois casamentos, desde que no papel de marido em um casamento e no papel de esposa em outro.

A Figura 7.1 mostra como é possível excluir essas duas possibilidades do modelo ER. A mudança que foi feita em relação ao modelo original (Figura 2.7) foi a de transformar CASAMENTO em entidade e, com isso, abrir a possibilidade de especificar a cardinalidade do relacionamento de casamento com pessoa.

Outra alternativa que poderia ser considerada é a de especializar a entidade

PESSOA em homens e mulheres. Essa solução somente deve ser considerada caso existam atributos diferentes para homens e mulheres.

■ exercício 2.5

A Figura 7.2 apresenta um possível diagrama de ocorrências para o relacionamento de SUPERVISÃO. Este diagrama modela as seguintes instâncias do relacionamento:

 

Detalhes do Produto

Livro Impresso
Book
Capítulos

Formato
PDF
Criptografado
Sim
SKU
B000000042588
ISBN
9788577804528
Tamanho do arquivo
2,3 MB
Impressão
Desabilitada
Cópia
Desabilitada
Vocalização de texto
Não
Formato
PDF
Criptografado
Sim
Impressão
Desabilitada
Cópia
Desabilitada
Vocalização de texto
Não
SKU
Em metadados
ISBN
Em metadados
Tamanho do arquivo
Em metadados