Fundamentos Do Design de Banco de Dados

05/12/2014 Fundamentosdodesigndebancodedados

data:text/htmlcharset=utf8,%3Cdiv%20class%3D%22row%22%20style%3D%22boxsizing%3A%20inherit%3B%20display%3A%20flex%3B%20flexwra 1/22

Fundamentos dodesign de banco dedadosUm banco de dados criado adequadamente fornece acessoa informaes atualizadas e precisas. Como um designcorreto essencial para alcanar as metas de um trabalhocom banco de dados, importante investir o temponecessrio no aprendizado dos princpios de um bomdesign. Ao final, mais provvel que voc obtenha umbanco de dados que atenda suas necessidades e queaceite alteraes com facilidade.

Este artigo fornece diretrizes para o planejamento dobanco de dados. Voc aprender como optar pelasinformaes de que necessita, como dividir essasinformaes em tabelas e colunas apropriadas, e comoessas tabelas so interrelacionadas. Leia este artigo antesde criar seu primeiro banco de dados.

Neste artigoAlguns termos de banco de dados a serem conhecidosO que um bom design de banco de dados?O processo do designDeterminando a finalidade do banco de dadosLocalizando e organizando as informaes necessriasDividir as informaes em tabelasTransformando itens de informaes em colunasEspecificando chaves primriasCreating the table relationshipsRefinando o designAplicando as regras de normalizaoPara obter mais informaes

Alguns termos de banco de dados aserem conhecidosO Microsoft Office Access 2007 organiza suas informaesem tabelas: listas de linhas e colunas que lembram as



linhas e as colunas do livro razo ou de uma planilha doMicrosoft Office Excel 2007. Em um banco de dadossimples talvez haja apenas uma tabela. Na maioria dosbancos de dados necessria mais de uma. Por exemplo,pode haver uma tabela que armazene informaes sobreprodutos, uma outra que armazene informaes sobrepedidos e uma outra tabela com informaes sobreclientes.

Cada linha tambm denominada de registro, e cadacoluna tambm chamada de campo. Um registro umaforma significativa e coerente de combinar informaessobre algo. Um campo um item nico de informao um tipo de item que aparece em cada um dos registros.Na tabela Produtos, por exemplo, cada linha ou registroguardaria informaes sobre um produto. Cada coluna oucampo mantm algum tipo de informao sobre esseproduto, como nome ou preo.

Parte superior da pgina

O que um bom design de bancode dados?Certos princpios guiam o processo de design do banco dedados. O primeiro princpio que informaes duplicadastambm denominadas dados redundantes so ruinsporque consomem espao e aumentam a possibilidade deerros e inconsistncias. O segundo princpio que acorreo e completitude das informaes importante. Seo banco de dados contiver informaes incorretas, todosos relatrios que empregam informaes do banco dedados tambm contero informaes incorretas. Comoresultado, todas as decises tomadas a partir dessesrelatrios sero errneas.



Um bom design de banco de dados, portanto, um que:

Divide as informaes em tabelas baseadas emtpicos, visando reduzir a redundncia de dados.

Fornece ao Access os dados essenciais reunio deinformaes nas tabelas, conforme necessrio.

Ajuda a oferecer suporte e assegurar a preciso e aintegridade das informaes.

Atende suas necessidades de processamento dedados e de relatrios.


O processo do designO processo do design consiste nas seguintes etapas:

Determinar a finalidade do seu banco dedados

Isso ajuda a preparlo para as etapas restantes.

Localizar e organizar as informaesnecessrias

Reunir todos os tipos de informaes que voc possadesejar gravar no banco de dados, como nome deproduto e nmero de pedido.

Dividir as informaes em tabelas

Dividir os itens de informaes em entidades outpicos principais, como Produtos ou Pedidos. Cadatpico tornase ento uma tabela.

Transformar informaes em colunas

Opte pelas informaes que deseja armazenar emcada uma das tabelas. Cada item tornase um campoque exibido como coluna da tabela. Por exemplo,uma tabela Funcionrios pode incluir campos comoSobrenome e Data de Contratao.

Especificar as chaves primrias

Escolher a chave primria de todas as tabelas. A chaveprimria uma coluna usada unicamente paraidentificar cada linha. Um exemplo pode ser Cdigode Produto ou Cdigo de Pedido.

Configurar as relaes de tabelas

Observar cada uma das tabelas e decidir como osdados em determinada tabela esto relacionados aos



dados de outras tabelas. Adicionar campos a tabelasou criar novas tabelas para esclarecer as relaes, senecessrio.

Refinar o design

Analisar o design com relao aos erros. Criar astabelas e adicionar alguns novos registros de dadosde exemplo. Observe se os resultados esperados dastabelas so obtidos. Faa ajustes no design, conformenecessrio.

Aplicar as regras de normalizao

Aplicar as regras de normalizao de dados paraexaminar se as tabelas esto corretamenteestruturadas. Faa ajustes nas tabelas, conformenecessrio.


Determinando a finalidade do bancode dadosRecomendase anotar a finalidade do banco de dados emum papel sua finalidade, como se espera uslo e quemo usar. Com relao a um banco de dados pequeno e deempresa caseira, por exemplo, voc escreveria algo como"O banco de dados cliente mantm uma lista deinformaes de clientes com a finalidade de produzir malasdiretas e relatrios". Se o banco de dados for maiscomplexo ou usado por diversas pessoas, como ocorrefreqentemente em um ambiente empresarial, a finalidadepoderia ser contida em um simples pargrafo ou mais,devendo incluir quando e como cada pessoa ir usar obanco de dados. A idia ter uma declarao de missobem desenvolvida, qual se possa referir durante todo oprocesso de design. Ter uma declarao como essa ajuda afocar nas metas no momento da tomada de decises.


Localizando e organizando asinformaes necessriasPara localizar e organizar as informaes requeridas,comece pelas informaes existentes. Por exemplo, possvel registrar os pedidos de compra em um livro razoou manter as informaes do cliente em formulrios depapel em um gabinete de arquivos. Rena essesdocumentos e liste cada um dos tipos de informaesmostrados por exemplo, cada caixa preenchida em umformulrio. Se no houver formulrios, imagine que ser



necessrio criar um formulrio para registrar asinformaes do cliente. Que informaes voc colocaria noformulrio? Que caixas de preenchimento voc criaria?Identifique e liste todos esses itens. Por exemplo, supondoque voc atualmente mantm a lista de clientes emcartes de ndice. O exame desses cartes demonstra quecada carto contm um nome, endereo, cidade, estado,cep e nmero de telefone de cliente. Cada um desses itensrepresenta uma coluna potencial em uma tabela.

medida que prepara a lista, no se preocupe emconseguir uma lista perfeita na primeira tentativa. Em vezdisso, liste todos os itens que lhe vierem mente. Seoutras pessoas usarem o banco de dados, pea sugestestambm. Voc poder refinar posteriormente a lista.

Em seguida, considere os tipos de relatrios ou de listas dedistribuio a serem produzidos com o banco de dados.Por exemplo, voc poder gerar um relatrio de vendas deproduto que apresente as vendas por regio, ou umrelatrio de resumo de inventrio mostrando os nveis deinventrio do produto. igualmente possvel gerar cartasmodelo para enviar aos clientes, que divulguem um eventode vendas ou que ofeream um brinde. Crie o relatrioideal e imagine sua aparncia. Que informaes voccolocaria no relatrio? Liste todos os itens. Faa o mesmocom a carta formulrio e com todos os relatrios cujacriao voc antev.

Pensar nos relatrios e listas de distribuio a seremcriados ajuda na identificao dos itens necessrios aobanco de dados. Por exemplo, supondo que voc d aosclientes a chance de optar por ou no por atualizaesperidicas via email, e que deseja imprimir uma listagemdos que optaram pela opo. Para registrar essasinformaes, adicione uma coluna "Enviar email" tabelado cliente. possvel configurar o campo como Sim ouNo com relao a todos os clientes.



A necessidade de enviar mensagens de email aos clientessugere que um outro item seja registrado. Aps saber se ocliente deseja receber mensagens de email, ser tambmnecessrio saber o endereo de email para os quais asmensagens sero enviadas. Portanto, necessrio registrarum endereo de email para cada um dos clientes.

H sentido em construir um prottipo de cada relatrio oulistagem de sada, e pensar nos itens necessrios produo do relatrio. Por exemplo, ao examinar umacarta formulrio, algumas coisas podem vir sua mente.Para incluir uma saudao adequada por exemplo, aseqncia de caracteres "Sr.", "Srta." ou "Sra.", que iniciauma saudao, ser preciso criar um item de saudao. Damesma forma, possvel comear normalmente uma cartacom Prezado Sr. Silva, em vez de Prezado EdmundoSilva. Isso quer dizer que voc deseja armazenarregularmente o sobrenome em separado do nome.

Um ponto essencial a ser lembrado que todas as partesda informao devem ser quebradas em suas partes teismenores. No caso de nome, para disponibilizarprontamente o sobrenome, quebreo em duas partes Nome e Sobrenome. Para classificar um relatrio peloltimo nome, por exemplo, til armazenarseparadamente o sobrenome do cliente. Em geral, quandose deseja classificar, pesquisar, calcular ou criar umrelatrio com base em um item de informaes, deveseinserir esse item em seu prprio campo.

Pense nas perguntas que voc deseja que o banco dedados responda. Por exemplo, quantas vendas do produtoem destaque foram fechadas ms passado? Onde vivemseus melhores clientes? Quem o fornecedor de seuproduto de maior vendagem? A antecipao dessasperguntas ajuda a que voc se concentre nos outros itensa serem registrados.

Aps reunir essas informaes, voc estar pronto para aprxima etapa.


Dividir as informaes em tabelasPara dividir as informaes em tabelas, escolha as maioresentidades ou tpicos. Por exemplo, aps localizar eorganizar informaes relativas a um banco de dados devenda de produto, a lista preliminar deve ter a seguinteaparncia:



As maiores entidades mostradas aqui so os produtos, osfornecedores, os clientes e os pedidos. Assim, h sentidoem comear pelas seguintes tabelas: uma de fatos sobreprodutos, uma de fatos sobre fornecedores, uma de fatossobre clientes, e uma de fatos sobre pedidos. Emboraessas tabelas no completem a lista, so um ponto departida. Continue e refinar essa lista at ter um design quefuncione bem.

Ao examinar pela primeira vez a lista de itens, voc talvezse sinta tentado a coloclos todos em uma nica tabela,em vez de ter quatro, como mostrado na ilustraoanterior. Voc saber aqui por que isso no recomendado. Pense um momento na tabela mostrada aseguir:

Nesse caso, cada linha contm informaes sobre oproduto e seu fornecedor. Como pode haver vriosprodutos de um mesmo fornecedor, o nome e o endereodo fornecedor devero ser repetidos inmeras vezes. Issoconsome espao em disco. Gravar as informaes dofornecedor uma nica vez em uma tabela Fornecedoresseparada e, em seguida, vincular essa tabela tabelaProdutos, uma soluo muito melhor.

Um segundo problema com esse design advm danecessidade de se modificarem as informaes sobre ofornecedor. Por exemplo, supondo seja necessrio alterar oendereo de um fornecedor. Como o endereo aparece emvrios lugares, voc talvez altere acidentalmente oendereo em um local, porm se esquea de alterlo nosoutros. Gravar o endereo do fornecedor em apenas um



local resolve esse problema.

Ao criar seu banco de dados, tente sempre registrar cadafato apenas uma vez. Quando se pegar repetindo amesma informao em mais de um local, como o endereode determinado fornecedor, coloque a informao em umatabela separada.

Finalmente, suponhamos que haja apenas um produtofornecido pela Coho Winery, e que voc deseje excluir oproduto, retendo, porm, o nome do fornecedor e asinformaes de endereo. Como excluir o registro doproduto sem tambm perder as informaes dofornecedor? Isso no possvel. Como cada registrocontm fatos sobre um produto, assim como fatos sobre ofornecedor, no possvel excluir um sem eliminar o outro.Para manter esses fatos de maneira distinta, separe essatabela em duas: uma tabela de informaes sobre oproduto, e uma outra tabela de informaes sobre ofornecedor. A excluso do registro do produto deveeliminar apenas os fatos sobre o produto, no os fatossobre o fornecedor.

Aps a seleo do tpico a ser representado na tabela, ascolunas da tabela s devem armazenar fatos sobre essetpico. Por exemplo, a tabela de produto s devearmazenar fatos sobre produtos. Como o endereo dofornecedor um fato sobre o fornecedor, e no um fatosobre o produto, pertence tabela do fornecedor.


Transformando itens de informaesem colunasPara determinar as colunas de uma tabela, opte pelasinformaes que voc necessita controlar sobre o tpicoregistrado na tabela. Por exemplo, com relao tabelaCliente, Nome, Endereo, CidadeEstadoCEP, Email paraenvio de correspondncia, Saudao e Endereo de emailconstituem uma lista de colunas que um bom comeo.Cada registro da tabela contm o mesmo conjunto decolunas, de modo que possvel armazenar informaessobre o Nome, Endereo, CidadeEstadoCEP, Email paraenvio de correspondncia, Saudao e endereo de emailde todos os registros. Por exemplo, a coluna de endereocontm os endereos dos clientes. Cada registro contmdados sobre um cliente, e o campo de endereo contm oendereo do cliente.

Aps determinar o conjunto inicial de colunas de cadatabela, voc poder refinar as colunas. Por exemplo, recomendado armazenar o nome do cliente em duascolunas separadas: o nome e o sobrenome, de modo que



se possa classificar, pesquisar e indexar apenas nessas duascolunas. Da mesma forma, o endereo na verdade consisteem cinco componentes distintos: endereo, cidade, estado,cep e pas/regio. igualmente recomendado armazenlos em colunas diferentes. Se voc deseja realizar umaoperao de pesquisa, filtro ou classificao por estado,por exemplo, ser necessrio armazenar a informao deestado em uma coluna separada.

Verifique se o banco de dados conter somenteinformaes de origem domstica, ou se, alm disso,conter informaes internacionais. Por exemplo, se vocplaneja armazenar endereos internacionais, deve haveruma coluna de Regio em vez de Estado, porque essacoluna aceita os estados domsticos e as regies de outrospases/outras regies. Semelhantemente, o cdigo deendereamento postal tem mais sentido que o CEP sevoc pretende armazenar endereos internacionais.

A lista a seguir mostra algumas dicas sobre adeterminao de colunas.

No incluso de dados calculados

Na maior parte dos casos, o resultado de clculos nodeve ser armazenado em tabelas. Em vez disso, possvel fazer com que o Access realize clculosquando se deseja exibir o resultado. Por exemplo,supondo que haja um relatrio de Produtos doPedido que exiba o subtotal de unidades do pedidopor categoria de produto no banco de dados.Contudo, no h coluna de subtotal de Unidades noPedido em nenhuma tabela. Em vez disso, a tabela deProdutos inclui uma coluna Unidades do Pedido quearmazena as unidades do pedido com relao a cadaum dos produtos. Usando esses dados, o Accesscalcula o subtotal cada vez que o relatrio impresso.O prprio subtotal no pode ser armazenado natabela.

Armazenar as menores partes lgicas dasinformaes

Voc pode ficar tentado a ter um nico campo paranomes completos, ou para nomes de produtosjuntamente com descries de produto. Se voccombinar mais de um tipo de informao em um scampo, ser difcil recuperar posteriormente os fatosindividuais. Tente quebrar as informaes em parteslgicas, por exemplo, criando campos distintos paranome e sobrenome, ou por nome, categoria edescrio de produto.


data:text/htmlcharset=utf8,%3Cdiv%20class%3D%22row%22%20style%3D%22boxsizing%3A%20inherit%3B%20display%3A%20flex%3B%20flexwr 10/22

Apos refinar as colunas de dados de cada tabela, vocestar pronto para escolher a chave primria de cadatabela.


Especificando chaves primriasToda tabela deve incluir uma coluna ou conjunto decolunas que identifica com exclusividade cada linhaarmazenada na tabela. Tratase, em geral, de um nmerode identificao exclusivo, como o nmero de identificaode um funcionrio ou um nmero de srie. Naterminologia de banco de dados, essas informaes sodenominadas chave primria da tabela. O Access usa oscampos de chave primria para associar rapidamente osdados de vrias tabelas e passar a voc as informaesconsolidadas.

Se j houver um identificador exclusivo para a tabela, comoum nmero de produto que identifica exclusivamente cadaproduto do seu catlogo, voc poder usar esseidentificador como chave primria da tabela porm,apenas se os valores da coluna forem sempre diferentescom relao a todos os registros. No possvel duplicarvalores em uma chave primria. Por exemplo, no usenomes de pessoas como chave primria, porque nomesno so exclusivos. fcil encontrar duas pessoas com omesmo nome em uma mesma tabela.

A chave primria deve sempre conter um valor. Se o valorde uma coluna pode se tornar sem alocao oudesconhecido valor faltante em dado momento, nopoder ser usado como componente de chave primria.

Escolha sempre uma chave primria cujo valor no se



altere. Em um banco de dados que utiliza mais de umatabela, a chave primria de uma tabela pode ser usadacomo referncia em outras tabelas. Se a chave primria sealterar, a alterao precisa tambm ser aplicada a todos oslocais em que a chave citada. Usar uma chave primriaque no se altera reduz a possibilidade de que a chaveprimria fique fora de sincronia com outras tabelas quefazem referncia a ela.

Em geral, um nmero exclusivo arbitrrio usado comochave primria. Por exemplo, possvel atribuir umnmero exclusivo de pedido a todos os pedidos. Afinalidade do nmero de pedido identificlo. Apsatribudo, ele no mais alterado.

Se voc no estiver visando a uma coluna ou conjunto decolunas que possam consistir em chave primriaadequada, pense em usar uma coluna que tenha um tipode dados de AutoNumerao. Quando o tipo de dados deAutoNumerao usado, o Access atribuiautomaticamente um valor a voc. Esse identificador isento de fatos; no contm informaes factuais quedescrevam a linha que representam. Os identificadoresisentos de fatos so ideais para se usar como chaveprimria porque no se alteram. Uma chave primria quecontenha fatos a respeito de uma linha nmero detelefone ou nome de cliente, por exemplo tem maisprobabilidade de se alterar porque as prprias informaesfactuais podem se modificar.

1. Um conjunto de colunas para o tipo de dados deAutoNumerao consiste, em geral, em uma chaveprimria adequada. Jamais dois cdigos de produto soidnticos.

Em alguns casos, prefervel usar dois ou mais camposque, juntos, forneam a chave primria para uma tabela.Por exemplo, uma tabela de Detalhes do Pedido quearmazene itens de linha de pedidos usaria duas colunasem sua chave primria: Cdigo de Pedido e Cdigo deProduto. Quando uma chave primria emprega mais deuma coluna, tambm denominada chave composta.

Com relao ao banco de dados de vendas de produto, possvel criar uma coluna de AutoNumerao para cadauma das tabelas, para servir como chave primria:CdigoDoProduto para a tabela Produtos,CdigoDoPedido para as tabelas Pedidos,



CdigoDoCliente para a tabela Clientes eCdigoDoFornecedor para a tabela Fornecedores.


Creating the table relationshipsAgora que as informaes esto divididas em tabelas, hnecessidade de uma forma de reunir as informaesnovamente, com um sentido. Por exemplo, o formulrio aseguir engloba informaes de vrias tabelas.

1. As informaes desse formulrio so originrias databela Clientes...



2. ...da tabela Funcionrios...

3. ...da tabela Pedidos...

4. ...da tabela Produtos...

5. ...e da tabela Detalhes do Pedido.

O Access um sistema de gerenciamento de banco dedados relacional. Em um banco de dados relacional, asinformaes so divididas em tabelas distintas, baseadasem tpicos. So ento utilizadas as relaes de tabelaspara reunir informaes, medida que se tornemnecessrias.


Criando uma relao umparamuitos

Examine este exemplo: as tabelas Fornecedores e Produtosdo banco de dados de pedidos de produto. Um fornecedorpode fornecer qualquer nmero de produtos.Conseqentemente, para qualquer fornecedorrepresentado na tabela Fornecedores pode haver vriosprodutos representados na tabela Produtos. A relaoentre a tabela Fornecedores e a tabela Produtos ,portanto, uma relao umparamuitos.

Para representar uma relao umparamuitos em umdesign de banco de dados, tome a chave primria do lado"um" da relao e adicionea como coluna ou colunasadicionais tabela do lado "muitos" da relao. Nesse caso,por exemplo, a coluna Cdigo do Fornecedor da tabelaFornecedores adicionada tabela Produtos. O Accesspode, em seguida, usar o nmero do cdigo do fornecedorda tabela Produtos para localizar o fornecedor correto detodos os produtos.

A coluna Cdigo do Fornecedor da tabela Produtos



denominada chave estrangeira. A chave estrangeira umachave primria de outra tabela. A coluna Cdigo doFornecedor da tabela Produtos uma chave estrangeiraporque tambm a chave primria da tabelaFornecedores.

As bases para a associao de tabelas relacionadas sofornecidas pelo estabelecimento da unio de chavesprimrias com chaves estrangeiras. Quando no se estcerto sobre quais tabelas devem compartilhar uma colunacomum, identificar uma relao umparamuitos asseguraque as duas tabelas envolvidas exigiro verdadeiramenteuma coluna compartilhada.


Criando uma relao muitosparamuitos

Examine a relao entre a tabela Produtos e a TabelaPedido.

Um nico pedido pode incluir mais de um produto. Poroutro lado, um nico produto pode constar em vriospedidos. Assim, para todos os registros da tabela Pedidospode haver vrios registros na tabela Produtos. E paracada registro na tabela Produtos pode haver registros natabela Pedidos. Esse tipo de relao denominado relaomuitosparamuitos porque com relao a todos osprodutos pode haver vrios pedidos, e para todos ospedidos pode haver vrios produtos. Observe que paradetectar relaes muitosparamuitos entre as tabelas importante considerar ambos os lados da relao.

Os tpicos das duas tabelas pedidos e produtos tmuma relao muitosparamuitos. Isso representa umproblema. Para entender o problema, imagine o que



aconteceria se voc tentasse criar a relao entre duastabelas adicionando o campo Cdigo do Produto tabelaPedidos. Para ter mais de um produto por pedido, necessrio mais de um registro na tabela Pedidos porpedido. Voc repetiria as informaes do pedido em cadauma das linhas relativas a um nico pedido o queresultaria em um design ineficaz que poderia resultar emdados imprecisos. O mesmo problema enfrentadoquando se coloca o campo Cdigo do Pedido na tabelaProdutos haveria mais de um registro na tabelaProdutos para cada produto. Como resolver esseproblema?

A soluo criar uma terceira tabela, em geraldenominada tabela de juno, que divide as diversasrelaes muitosparamuitos em duas relaes umparamuitos. Insira a chave primria de cada uma das duastabelas em uma terceira tabela. Conseqentemente, aterceira tabela registra todas as ocorrncias ou instnciasda relao.

Cada registro da tabela de Detalhes do Pedido representaum item de linha do pedido. A chave primria da tabelaDetalhes do Pedido consiste em dois campos as chavesestrangeiras das tabelas Pedidos e Produtos. Usarsomente o campo Cdigo do Pedido no funciona comochave primria dessa tabela, porque um nico pedidopode conter vrios itens de linha. O Cdigo do Pedidorepetese em cada item de linha em um pedido, de modoque o campo no possa conter valores nicos. Usarapenas o campo Cdigo do Produto no funcionatambm, porque um mesmo produto pode surgir emdiversos pedidos diferentes. Em conjunto, porm, os doiscampos podem sempre produzir um valor nico para cadaregistro.

No banco de dados de vendas de produto a tabela



Pedidos e a tabela Produtos no esto relacionadas entresi de forma direta. Em vez disso, so relacionadasindiretamente atravs da tabela Detalhes do Pedido. Arelao muitosparamuitos entre pedidos e produtos representada no banco de dados por meio de duasrelaes umparamuito:

A tabela Pedidos e a tabela Detalhes tem uma relaoumparamuitos. Todos os pedidos podem ter maisde um item de linha, porm todo item de linha conectado a apenas um pedido.

A tabela Produtos e a tabela Pedidos tem umarelao umparamuitos. Cada produto pode tervrios itens de linha associados a ele, mas cada itemde linha se refere a apenas um produto.

Da tabela de Detalhes do Pedido, possvel determinartodos os produtos em um pedido particular. possveltambm determinar que todos os pedidos de um produtoparticular.

Aps incorporar a tabela de Detalhes do Pedido, a lista detabelas e campos pode ter a seguinte aparncia:


Criando uma relao umparaum

Um outro tipo de relao a relao umparaum. Porexemplo, suponhamos que haja necessidade de registrar



algumas informaes especiais e complementares de umproduto, que sero raramente usadas ou que se saplicam a uns poucos produtos. Como essas informaesno so exigidas com freqncia, e como armazenarinformaes na tabela Produtos resultaria em espao vaziopara todos os produtos aos quais elas no se aplicam,coloque essas informaes em uma tabela distinta. Assimcomo a tabela Produtos, utilize o CdigoDoProduto comochave primria. A relao entre essa tabela complementare a tabela Produto uma relao umparaum. Para cadaregistro da tabela Produto, existe apenas um registrocorrespondente na tabela complementar. Quando essarelao identificada, ambas as tabelas devemcompartilhar um campo comum.

Quando a necessidade de uma relao umparaum detectada no banco de dados, considere colocar asinformaes das duas tabelas juntas em uma s tabela. Sehouver um motivo para no o fazer, talvez porque issoresulte em uma srie de espaos vazios, a lista a seguirmostra como representar a relao no design:

Se as duas tabelas tiverem o mesmo tpico, vocpoder provavelmente configurar a relao por meioda mesma chave primria em ambas as tabelas.

Se as duas tabelas tiverem tpicos diferentes comchaves primrias diversas, escolha uma das tabelasqualquer uma e insira a chave primria na outratabela como chave estrangeira.

A determinao das relaes entre tabelas ajuda aassegurar que se tenham as tabelas e colunas corretas.Quando existe uma relao umparaum ou umparamuitos, as tabelas envolvidas exigem o compartilhamentode uma coluna ou colunas comuns. Quando existe umarelao muitosamuitos, uma terceira tabela necessriapara representar a relao.


Refinando o designAps ter as tabelas, campos e relaes necessrios, crie epreencha as tabelas com dados de exemplo e tentetrabalhar com as informaes: criao de consultas, adiode novos registros, entre outros. Fazer isso ajuda alevantar os problemas potenciais por exemplo, pode sernecessrio adicionar uma coluna que se esqueceu deinserir durante a fase de design, ou pode haver uma tabelaque deva ser dividida em duas tabelas para removerduplicao.

Confirme se possvel usar o banco de dados para obteras respostas desejadas. Crie rascunhos dos seus



formulrios e relatrios, e veja se eles apresentam osdados esperados. Procure por duplicaes de dadosdesnecessrias e, quando encontrar alguma, altere odesign para eliminla.

medida que voc faz experincias com o banco de dadosinicial, provavelmente descobrir espao paramelhoramentos. Seguem algumas coisas a seremverificadas:

Voc esqueceu alguma coluna? Se esqueceu, asinformaes pertenciam a tabelas existentes? Se setrata de informaes sobre alguma outra coisa, sernecessrio criar uma outra tabela. Crie uma colunapara cada item de informao que necessita decontrole. Se as informaes no podem ser calculadasa partir de outras colunas, provvel que exijam umaoutra coluna.

H alguma coluna desnecessria porque pode sercalculada a partir de campos existentes? Se um itemde informao puder ser calculado de outras colunasexistentes um preo descontado calculado dopreo de varejo, por exemplo em geral melhorfazer exatamente isso e evitar criar uma nova coluna.

Informaes duplicadas so repetidamente inseridasem uma das tabelas? Em caso afirmativo, talvez sejanecessrio dividir a tabela em duas tabelas quetenham a relao umparamuitos.

Existem tabelas com vrios campos, um nmerolimitado de registros e vrios campos vazios emregistros individuais? Se for o caso, pense em criarnovamente a tabela de modo que passe a ter menoscampos e mais registros.

Todos os itens de informaes foram quebrados empartes teis menores? Se for necessrio criar relatrio,classificar, pesquisar ou calcular um item deinformao, coloque esse item em sua prpria coluna.

Cada coluna contm um fato sobre o tpico databela? Quando uma coluna no contm informaessobre o tpico da tabela porque pertence a umatabela diferente.

Todas as relaes entre tabelas so representadastanto por campos comuns como por uma terceiratabela? As relaes umparaum ou umparamuitosrequerem colunas comuns. As relaes muitosparamuitos requerem uma terceira tabela.

Refinando a tabela Produtos

Suponhamos que cada produto no banco de dados de



vendas de produto incida sobre uma categoria geral, comobebidas, condimentos ou frutos do mar. A tabela Produtospoderia incluir um campo que apresente a categoria decada produto.

Suponhamos que aps examinar e refinar o design dobanco de dados voc decida armazenar uma descrio decategoria juntamente com o nome da categoria. Quandose adiciona um campo Descrio de Categoria tabelaProdutos, preciso repetir todas as descries decategoria de cada produto que incida nessa categoria oque no uma boa soluo.

Uma soluo mais adequada transformar Categorias emum tpico novo para controle do banco de dados, comsua prpria tabela e sua prpria chave primria. Adicioneento a chave primria da tabela Categorias tabelaProdutos como chave estrangeira.

As tabelas Categorias e Produtos tm uma relao umparamuitos: uma categoria pode incluir mais de umproduto, porm um produto s pode pertencer a umacategoria.

No momento de examinar as estruturas da tabela, presteateno a grupos repetidos. Por exemplo, considere umatabela contendo as seguintes colunas:

Cdigo do Produto

Nome

Cdigo de Produto1

Nome1

Cdigo de Produto2

Nome2

Cdigo de Produto3

Nome3

Aqui, cada produto um grupo separado de colunas quediferem entre si apenas pela adio de um algarismo aofinal do nome da coluna. Quando colunas numeradasdessa forma aparecerem, reexamine o design.

Esse tipo de design tem vrias falhas. Com relao aosiniciantes, fora a colocao de um limite superior nonmero de produtos. To logo voc exceda esse limite,ser preciso adicionar um novo grupo de colunas estrutura da tabela, o que uma tarefa administrativaessencial.

Um outro problema que os fornecedores com nmero



de produtos inferior ao mximo iro desperdiar espao,uma vez que as colunas adicionais estaro vazias. A maiorfalha com relao a esse design que isso torna vriastarefas difceis de desempenhar, como a classificao ouindexao da tabela por cdigo ou nome de produto.

Sempre que forem exibidos grupos repetidos, examinedetalhadamente o design, visando a dividir a tabela emdois. No exemplo acima melhor usar duas tabelas, umapara fornecedores e uma para produtos, vinculadas porcdigo de fornecedor.


Aplicando as regras de normalizao possvel aplicar as regras de normalizao de dadostambm chamadas simplesmente regras de normalizaocomo prxima etapa do design. Use essas regras para verse as tabelas esto corretamente estruturadas. O processode aplicao de regras ao design do banco de dados denominado normalizao de banco de dados, ou apenasnormalizao.

A normalizao muito mais til aps a representao detodos os itens de informaes e da obteno de umdesign preliminar. A idia ajudar a assegurar que vocdistribua os itens de informaes pelas tabelas corretas. Oque a normalizao no pode fazer assegurar que setenham todos os itens de dados corretos de incio.

Aplique as regras em seqncia, assegurando a cada etapaque o seu design chegue ao que conhecido como"formas normalizadas". Cinco formas normalizadas soamplamente aceitas da primeira forma normalizada quinta forma normalizada. Este artigo se expande nas trsprimeiras, porque elas so tudo o que se exige para amaior parte dos bancos de dados.

Primeira forma normalizada

A primeira forma normalizada declara que a cadainterseo de linha e coluna da tabela existe um valornico e nunca uma lista de valores. Por exemplo, no possvel ter um campo denominado Preo, em que seinsira mais de um Preo. Quando se entende cadainterseo de linhas e colunas como uma clula, cadaclula poder manter apenas um valor.

Segunda forma normalizada

A segunda forma normalizada requer que cada colunanochave seja totalmente dependente de toda a chaveprimria, no apenas de parte da chave. Essa regra aplica



se quando se tem uma chave primria que consiste emmais de uma coluna. Por exemplo, supondo que haja umatabela contendo as colunas a seguir, onde Cdigo doPedido e Cdigo do Produto formam a chave primria:

Cdigo do Pedido chave primria

Cdigo de Produto chave primria

Nome de Produto

Esse design desrespeita a segunda forma normalizada,uma vez que o Nome do Produto dependente doCdigo do Produto, mas no do Cdigo do Pedido,portanto, no depende de toda a chave primria. precisoremover o Nome do Produto da tabela. Ele pertence auma tabela diferente Produtos.

Terceira forma normalizada

A terceira forma normalizada exige que no apenas todasas colunas nochave sejam dependentes de toda a chaveprimria, mas que as colunas nochave sejamindependentes entre si.

Uma outra forma de dizer isso que cada coluna nochave seja dependente da chave primria e somente dachave primria. Por exemplo, na hiptese de haver umatabela contendo as seguintes colunas:

CdigoDeProduto chave primria

Nome

SRP

Desconto

Suponha que Desconto dependa do SRP suggested retailprice, preo a varejo sugerido. Essa tabela desrespeita aterceira forma normalizada, porque uma coluna no chave,Desconto, depende de uma outra comuna nochave, SRP.A independncia da coluna significa que possvel alterartodas as colunas nochave sem afetar nenhuma outracoluna. Se voc alterar um valor do campo SRP, Descontoseria pertinentemente alterada, o que infringiria a regra.Nesse caso, Desconto seria movida para uma outra tabelachaveada em SRP.


Para obter mais informaesPara obter mais informaes sobre os fundamentos dodesign de tabelas, consulte o artigo Criando tabelas embancos de dados.



Para obter informaes adicionais sobre design de bancode dados, consulte os seguintes livros:

Hernandez, Michael J. Database Design for MereMortals: A HandsOn Guide to Relational DatabaseDesign, Segunda edio. AddisonWesleyProfessional. 2003.

Fleming, Candace C. von Halle, Barbara. Handbook ofRelational Database Design. AddisonWesleyProfessional. 1989.

Riordan, Rebecca M. Designing Effective DatabaseSystems. AddisonWesley Professional. 2005.


Aplicvel a: Access 2007

Fundamentos Do Design de Banco de Dados

Documents

Transcript of Fundamentos Do Design de Banco de Dados