Modelagem de Dados: Introdução ao Projeto de Banco de Dados, Notas de estudo de Engenharia Informática

Baixe Modelagem de Dados: Introdução ao Projeto de Banco de Dados e outras Notas de estudo em PDF para Engenharia Informática, somente na Docsity!

GEEK BRASIL – http://www.geekbrasil.com.br

MODELAGEM de dados

Modelagem de

Dados

em Microsoft

Access 95

Capítulo

Introdução à modelagem

de dados

Aprenda os conceitos básicos de

normalização

Um projeto de banco de dados é uma matéria complexa, não importando como algumas pessoas achem que seja fácil. Esta sessão apenas arranha a superfície, mas com um belo arranhão.

Um banco de dados projetado de forma conveniente é um modelo de uma empresa, ou de alguma outra “coisa” no mundo real. Como seu modelo físico, em contrapartida, um modelo de dados permite a você fazer perguntas sobre os fatos que compõem os objetivos a serem alcançados. Estas são as perguntas que precisam de respostas e que determinarão quais fatores precisarão serem armazenados no modelo de dados.

No modelo relacional, os dados são organizados em tabelas que possuem as seguintes características:

Todo registro tem o mesmo número de fatos;

Todo campo contém o mesmo tipo de fato em cada um dos registros;

Há apenas um ingresso para cada fato;

Dois registros nunca são exatamente os mesmos;

A ordem dos registros e campos não é importante.

Por que Projetar?

Um projeto preciso é crucial para a operação de um sistema de informações seguro e eficiente. A tecnologia dos microcomputadores é atualmente tão avançada que o impacto de um projeto pobre pode não se mostrar tão cedo quanto no passado; todavia, quando os problemas aparecerem, eles serão severos.

Um projeto de um banco de dados tem que fazer com que o caminho dos dados seja armazenado e mostrar como os dados serão relatados. Os processos do projeto são desenvolvidos depois de você determinar exatamente quais informações precisam ser armazenadas e como elas serão recuperadas.

Quanto mais cuidadoso seu projeto, tanto melhor o banco de dados físico se identificará com as necessidades do usuário. No processo de desenvolvimento de um sistema completo, você precisa considerar as necessidades do usuário de vários pontos de vista.

Problemas Resultantes de um Projeto Pobre

Diversos problemas podem se manifestar como resultado de um banco de dados mal projetado:

O banco de dados e/ou aplicação não podem funcionar adequadamente.

Os dados podem não ser confiáveis ou serão inexatos.

A performance pode ser degradada.

A flexibilidade poderá ser perdida.

A seção seguinte explica sobre alguns dos problemas mais comuns resultantes de um projeto de banco de dados pobre. Os problemas podem ser agrupados sob duas categorias: dados redundantes e modificações anômalas.

Introdução ao Projeto de Banco de Dados

Considere a tabela seguinte que armazena dados sobre produtos e fornecedores. Esta aparentemente inofensiva tabela contém muitos problemas potenciais.

IDProdut o

Descrição Fornecedor Endereço Cidade Região País 34 Sasquatch Ale Bigfoot Breweries 3400 - 8th Avenue, Suite 210

Bend OR USA 27 Schoggi Schokolade Heli Süßwaren GmbH

Tiergartenstraße 5 Berlin Germany 68 Scottish Longbreads Specialty Biscuits, Ltd.

29 King’s Way Manchester UK 42 Singaporean Fried Mee

Leka Trading 471 Serangoon Loop, Singapore Singapore 20 Sir Rodney’s Marmalade

Specialty Biscuits, Ltd.

29 King’s Way Manchester UK 21 Sir Rodney’s Scones Specialty Biscuits, Ltd.

29 King’s Way Manchester UK 61 Sirop d’érable Forêts d’érables 148 rue Chasseur Ste- Hyacinthe

Québec Canada 46 Spegesild Lyngbysild Lyngbysild Fiskebakken 10

Lyngby Denmark 35 Steeleye Stout Bigfoot Breweries 3400 - 8th^ Avenue Suite 210

Bend OR USA

Suponhamos que você deseje adicionar outro registro

37 Lumberman’s Lager Bigfoot Breweries 3400 - 8th Avenue Suite 210

Bend OR USA

O espaço em disco é perdido por duplicação dos dados sobre o fornecedor. Toda vez que um novo produto é registrado para um fornecedor em particular, todos os dados sobre este fornecedor tem de ser repetidos. Imagine o problema se diversos fornecedores fornecem centenas de produtos cada um.

Modificações Anômalas O que acontece se o fornecedor Bigfoot Breweries se muda para Portland? Quantos campos terão de ser modificados para se assegurar que o novo endereço foi registrado?

IDProdut o

Descrição Fornecedor Endereço Cidade Região País 34 Sasquatch Ale Bigfoot Breweries 3400 - 8th Avenue Suite 210

Bend OR USA 27 Schoggi Schokolade Heli Süßwaren GmbH

Tiergartenstraße 5 Berlin Germany 68 Scottish Longbreads Specialty Biscuits, Ltd.

29 King’s Way Manchester UK 42 Singaporean Fried Mee

Leka Trading 471 Serangoon Loop, Singapore Singapore 37 Lumberman’s Lager Bigfoot Breweries 3400 - 8th Avenue Suite 210

Bend OR USA

46 Spegesild Lyngbysild Lyngbysild Fiskebakken 10

Lyngby Denmark 35 Steeleye Stout Bigfoot Breweries 3400 - 8th Avenue Suite 210

Bend OR USA

Uma exclusão anômala faz com que percamos mais informações do que o necessário. Nós perdemos dados sobre mais de um assunto a cada exclusão.

Inserção Anômala Agora você precisa adicionar um novo fornecedor, StarStruck, mas você ainda não tem encomendado nenhum produto deste fornecedor. O que você adicionará?

IDProdut o

Descrição Fornecedor Endereço Cidade Região País 34 Sasquatch Ale Bigfoot Breweries 3400 - 8th Avenue Suite 210

Bend OR USA 27 Schoggi Schokolade Heli Süßwaren GmbH

Tiergartenstraße 5 Berlin Germany 68 Scottish Longbreads Specialty Biscuits, Ltd.

29 King’s Way Manchester UK 42 Singaporean Fried Mee Leka Trading 471 Serangoon Loop, Singapore Singapore 20 Sir Rodney’s Marmalade

Specialty Biscuits, Ltd.

29 King’s Way Manchester UK 21 Sir Rodney’s Scones Specialty Biscuits, Ltd.

29 King’s Way Manchester UK 61 Sirop d’érable Forêts d’érables 148 rue Chasseur Ste- Hyacinthe

Québec Canada 46 Spegesild Lyngbysild Lyngbysild Fiskebakken 10

Lyngby Denmark 35 Steeleye Stout Bigfoot Breweries 3400 - 8th^ Avenue Suite 210

Bend OR USA ??? ?????? StarStruck, Inc. 101 Mariposa Seattle WA USA

Esta situação é chamada de inserção anômala. Não podemos adicionar um dado sobre um assunto até que nós tenhamos dados adicionais sobre outro assunto.

Modelo Domínio/Chave

Teorias relacionais têm classificado os esquemas de banco de dados que têm inconsistências, baseando-se nas anomalias a qual eles são suscetíveis. Você pode ter encontrado discussões sobre diferentes formas. Uma das únicas normalizações foi propostas por R. Fagin, em 1981, e é usada como a base desta apresentação. Fagin apurou que se as tabelas em seu banco de dados estão no Modelo Domínio/ Chave, então eles estão livres de modificações anormais.

Para compreender este modelo aí estão quatro termos que devem ser compreendidos: dependência, chave, domínio e restrição.

Dependência Uma dependência é uma relação que pode existir entre duas colunas. Dados os valores da primeira coluna , você estará apto para determinar o valor de uma outra. Vamos usar a tabela dos exemplos anteriores. Dados o número do produto, nós estaremos capazes de determinar as descrições dos produtos. Esta é uma dependência: descrições são dependências nos números dos produtos. Dados um nome de fornecedor, seremos nós capazes de determinar a descrição do produto? Não necessariamente. No caso do BigFoot Breweries, este fornecedor tem um número de produtos associados a ele. Portanto , nas tabelas acima, descrição não é uma dependência de fornecedores.

Para detectar uma dependência, pergunte a si mesmo o seguinte:

Nesta tabela, pode o valor de uma coluna determinar TODOS OS VALORES POSSÍVEIS de outra coluna?

IDProduto determina Descrição? SIM Fornecedor determina Endereço? SIM Fornecedor determina IDProduto? NÃO

Chave A maior parte das tabelas deve ter uma coluna ou uma combinação de colunas que unicamente identifique uma linha de dados. Uma coluna é chave se todas as outras colunas numa linha de dados são dependentes dela.

A primeira olhada, pode parecer que a coluna IDProduto em nosso exemplo unicamente identifica uma linha de dados. Mas IDProduto 34 identifica o fornecedor como BigFoot Breweries, que também faz parte dos números 35 e 37. Portanto, a coluna IDProduto não é uma chave. Nesta tabela, nós temos uma chave complexa, derivada de IDProduto, Descrição, e Fornecedor.

O Processo de Normalização

Normalizar o banco de dados garante que a estrutura permitirá as mudanças a serem feitas sem que ocorram conseqüências inesperadas. O papel da normalização é manter estável, e com dados confiáveis, o banco de dados, através de um bom projeto.

O objetivo de um bom projeto de banco de dados é assegurar que todas as restrições sejam conseqüências lógicas das restrições de domínio e chave.

Tabelas, como parágrafos, devem ter um só tema. A tabela nos exemplos de anomalias teve dois temas:

Informações sobre os produtos.

Informações sobre os fornecedores dos produtos.

A maneira de administrar esta informação mais eficientemente é dividir a tabela em duas: uma tabela de produtos e uma tabela de fornecedores.

Produtos IDProdu to

Descrição Fornecedor

34 Sasquatch Ale Bigfoot Breweries 27 Schoggi Schokolade Heli Süßwaren GmbH & Co. KG 68 Scottish Longbreads Specialty Biscuits, Ltd. 42 Singaporean Hokkien Fried Mee Leka Trading 20 Sir Rodney’s Marmalade Specialty Biscuits, Ltd. 21 Sir Rodney’s Scones Specialty Biscuits, Ltd. 61 Sirop d’érable Forêts d’érables 46 Spegesild Lyngbysild 35 Steeleye Stout Bigfoot Breweries

Fornecedores

Fornecedor Endereço Cidade Regiã o

País

Bigfoot Breweries 3400 - 8th Avenue Suite 210

Bend OR USA

Heli Süßwaren GmbH & Co. KG

Tiergartenstraße 5 Berlin Germany

Specialty Biscuits, Ltd. 29 King’s Way Manchester UK Leka Trading 471 Serangoon Loop, Suite

Singapore Singapor e Forêts d’érables 148 rue Chasseur Ste-Hyacinthe Québec Canada Lyngbysild Lyngbysild Fiskebakken 10 Lyngby Denmark

Ter um confiável e estável banco de dados, onde as tabelas sejam tão independentes quanto possível

Ser fácil de usar

Projeto do Modelo do

Banco de Dados

O projeto da estrutura do banco de dados necessita dos seguintes passos:

1. Relacione os objetos.
2. Liste os fatores relacionados aos objetos.
3. Transforme os objetos e fatores em tabelas e colunas.
4. Determine as relações entre os objetos.
5. Determine as chaves das colunas.
6. Determine as colunas relacionadas.
7. Determine as relações de reserva.
8. Avalie o modelo projetado.
9. (^) Desenvolva o banco de dados.

“últimos nomes” de todos os empregados com 15 caracteres ou menos.

Se uma coluna é usada para conectar duas ou mais tabelas, o domínio precisa ser o mesmo e as colunas devem ter o mesmo nome. Se a descrição lógica diferir (por exemplo, “último nome” do funcionário e “último nome” do cliente), as colunas não são as mesmas e não devem partilhar o mesmo nome. A seguir se encontra uma lista das tabelas preliminares, colunas e domínios para a Zipper:

Tabela: CLIENTE

Tabela: PRODUTO

Nome Tipo Compr Nome Tipo Compr COMPANY TEXTO 45 PRODNAME TEXTO 30 CADD1 TEXTO 30 PRODDESC TEXTO 50 CADD2 TEXTO 30 PRODCOST MOEDA CCITY TEXTO 25 PMARKUP NÚM CSTATE TEXTO 2 CZIP TEXTO 10 Tabela: DEPENDENTE CAC TEXTO 3 Nome Tipo Compr CTELPH TEXTO 7 DLAST TEXTO 15 CONTACT TEXTO 30 DFIRST TEXTO 10 TITLE TEXTO 30 DDOB D/H

Tabela: FATURA Tabela: FUNCIONÁRIO

Nome Tipo Compr Nome Tipo Compr INVDATE D/H ESSN TEXTO 11 REQDATE D/H ELASTN TEXTO 15 SHIPNAME TEXTO 45 EFIRSTN TEXTO 10 SHIPADDR TEXTO 30 EDOB D/H SHIPCITY TEXTO 25 EGENDER TEXTO 1 SHIPZIP TEXTO 10 EMARITAL TEXTO 1 INVTOTAL MOEDA EADDR1 TEXTO 30 EADDR2 TEXTO 20 ECITY TEXTO 25 Tabela: TAXA DE EMBARQUE ESTATE TEXTO 2 Nome Tipo Compr EZIP TEXTO 10 SHIPST TEXTO 2 EAC TEXTO 3 SHIPRATE NÚM EHOMEPH TEXTO 7

Freqüentemente uma ajuda no estágio de projeto é desenhar caixas representando as tabelas. Em passos posteriores você poderá então preencher as colunas chave e desenhar as relações entre as tabelas.

Passo 4: Determine as relações entre objetos Para determinar as relações entre os objetos, pegue um objeto e olhe como este objeto pode se relacionar com outro. Mantenha em mente que nem toda relação existente entre objetos é importante. As relações que são importantes são aquelas que permitem a você modelar o banco de dados de maneira a corresponder às situações do mundo real que ele representa.

Relações um-para-um. Para qualquer linha de dados na tabela A, existe uma única linha na tabela B. Para qualquer linha de dados na tabela B, existe uma única linha na tabela A. Não existe nenhum relacionamento um-para-um no banco de dados da Zipper. Um exemplo de uma relação um-para-um é aquela que abrange dados sobre o funcionário e dados pessoais sobre o funcionário. Informações gerais, como nome do funcionário, endereço, data de contratação, são mantidas em uma tabela, e para manter privacidade, informações pessoais, como salário, são mantidas em outra tabela.

Relações um-para-vários. Para qualquer linha de dados na tabela A, existem várias linhas na tabela B. Para qualquer linha de dados na tabela B, existe uma única linha na tabela A. As relações entre funcionários e seus dependentes é um-para-vários, porque um funcionário pode ter muitos dependentes, mas um dependente é relacionado a apenas um funcionário. A relação entre clientes e faturas é também um-para-vários. Uma fatura é relacionada a um cliente, mas um cliente pode ter várias faturas.