Modelagem de Dados Introduo.

Tera-feira, 01/08/2006 s 11h14, por Mauri Gonalves

Neste e nos prximos artigos vou falar um pouco sobre um assunto que muitos desconhecem: a Modelagem de Dados. Primeiramente, o que modelagem dados? Para quem no sabe, a modelagem de dados um processo no qual voc "projeta" ou "planeja" a sua base de dados de forma que voc possa aproveitar os recursos do Gerenciador de Banco e tambm para que possa construir um banco de dados consistente, que reaproveite recursos, que exija menos espao em disco e, sobretudo, que possa ser bem administrado. Assim, como no processo de software, a modelagem de dados um processo que possui etapas a serem seguidas, mas que podem ser superadas, dependendo do tipo de banco que se pretende construir. O documento principal da modelagem de dados o Diagrama de Entidade-Relacionamento - DER (leia-se: dr) ou Modelo de Entidade-Relacionamento (MER). Neste documento, so representadas as entidades e os relacionamentos entre elas. As entidades so os "embries" das tabelas do banco. At avanarmos esta fase da modelagem, elas recebem esta nomenclatura. Esta primeira fase o que chamamos de Modelagem Lgica. quando determinamos o fluxo de dados entre as entidades, isto , como o prprio nome diz, quando determinamos a lgica do banco que iremos construir. O relacionamento entre as entidades um quesito que deve ser especialmente analisado. No modelo lgico, toda entidade deve estar relacionada outra. Quando sobram entidades sem relacionamento, sinal de que h algum problema. Podem ser entidades que esto sobrando, ou seja, que na verdade no deveriam existir, ou alguma entidade pode estar relacionada qual no deveria. Dependendo do tipo de base de dados que se deseja, pode-se aproveitar ferramentas do prprio banco e, desta forma, economizar linhas de cdigo. Suponha que faamos um controle de bens domsticos. Certamente para este sistema no h previso de migrar a base de dados para uma plataforma maior, como o SQL Server, ou Oracle, certo? Ento por que no aproveitar alguns recursos do banco de dados Access para controlar os seus dados? Isto deve ser levado em conta quando se modela um banco. Mas h tambm casos onde se prev uma migrao ou, quem sabe, se est apenas pensando em um mdulo de um sistema. Neste caso, quanto menos dependncia do gerenciador do banco, melhor. Podese implementar rotinas no prprio sistema e torn-lo "universal" a qualquer tipo de

banco de dados, seja ele proprietrio (Access, SQL Server, Oracle) ou livre (MySQL, PostGreSQL). Em plataformas como a Oracle, h mdulos de modelagem de dados prprios, totalmente integrados ao banco de dados. Como sabemos, este no o caso do Access. Mesmo assim, podemos fazer uma anlise, por mais simples que seja o banco de dados, antes de colocar Access para rodar. Aps terminarmos a modelagem lgica, partimos para a modelagem fsica. Nesta etapa, vamos determinar as tabelas, campos e relacionamentos que efetivamente vamos construir em nosso banco de dados. Para isto, vamos repensar o modelo lgico que criamos e adequ-lo para a "realidade".

Modelagem de Dados 1:Entidades

Quarta-feira, 30/08/2006 s 13h15, por Mauri Gonalves

iniciar o Modelo Lgico do nosso banco de dados. Para que os conceitos fiquem bem visveis, vou exemplificar para vocs um banco de dados para um sistema de Biblioteca. O start da modelagem se d a partir das ENTIDADES. Uma entidade uma representao de um conjunto de informaes sobre determinado conceito do sistema. Toda entidade possui ATRIBUTOS, que so as informaes que referenciam a entidade. Para exemplificar no sistema de controle de Biblioteca, partimos do conceito principal que o emprstimo de obras por usurios da biblioteca. A partir deste conceito inicial, vamos ramificando e descobrindo novos conceitos. Podemos iniciar nosso raciocnio da seguinte forma: "Uma biblioteca possui Obras literrias que podem ser tomadas em emprstimos pelosusurios credenciados." Podemos rapidamente enxergar um cadastro de livros, um cadastro de usurios e umregistro de emprstimos, certo? essa viso que temos que ter ao modelarmos um banco, isto , devemos detectar as informaes que devemos armazenar. Para identificar se aquele conceito pode ser uma entidade voc deve apenas se perguntar: "Eu desejo armazenar quais informaes sobre este conceito ?" Se houverem informaes a serem armazenadas, voc tem uma ENTIDADE. Exemplificando: Eu desejo armazenar os seguintes dados do livro: Ttulo, Autor, Editora, Ano, Edio e Volume. Temos ento a entidade Livro. A estas informaes que armazenamos, damos o nome de ATRIBUTO. Um atributo pode ser uma informao nica, bem como pode ser um conjunto de informaes. Exemplificando: Sobre emprstimos, eu tenho os seguintes atributos: Cdigo, livro emprestado, usurio que emprestou, data de emprstimo e data de devoluo. O atributo "livro emprestado" refere-se ao livro, porm sabemos que h informaes que devem ser armazenadas sobre livros como vimos antes. Temos a um exemplo de um atributo que um conjunto de outros atributos: todos os atributos da entidade Livro, formam um atributo da entidade Emprstimo. Outra situao a seguinte: deseja-se armazenar 2 nmeros de telefone para cada usurio. Telefone um dos atributos da entidade Usurio. Neste caso, no temos referncia nenhuma outra entidade, ou seja, temos mais de uma informao para o mesmo atributo. A este atributo damos o nome de ATRIBUTO MULTIVALORADO, pois temos 2 valores para o mesmo atributo em uma mesma entidade. Sabemos que nos bancos de dados no possivel armazenar mais de uma informao no mesmo campo. Por isso, veremos mais frente uma soluo para os atributos multivalorados. Quando os atributos de uma entidade formam o atributo de outra, podermos dizer que existem uma referenciao entre as entidades. Naquele atributo da entidade Emprstimos vamos armazenar apenas uma referncia entidade Livro. O mesmo ocorrer com relao entidade Usurio. Pelo simples fato de existir esta referncia de uma entidade em outra, temos ento o que chamamos de RELACIONAMENTO.

Neste comeo, temos um rascunho do nosso Diagrama de EntidadeRelacionamento: Entidades: Usurio, Livro, Emprstimo Relacionamentos: Usurio - Emprstimo, Livro - Emprstimo No prximo artigo falaremos sobre RELACIONAMENTOS entre entidades. At l.

Modelagem de Dados 2 - Os Relacionamentos

Sexta-feira, 06/10/2006 s 11h46, por Mauri Gonalves

Agora que definimos nossas entidades, vamos falar sobre os relacionamentos entre elas. Na matria anterior vimos como identificar os relacionamentos entre entidades, porm devemos observar alguns aspectos importantes que sinalizam erros na modelagem: 01. Quando "sobram" entidades sem relacionamentos; 02. Quando ocorrem "ciclos fechados" de relacionamentos; Exemplo: Usurio relaciona-se com Emprstimo que relaciona-se com Livro que relaciona-se com Usurio que relaciona-se com Emprstimo, etc... 03. Entidades com muitos atributos relacionando-se com entidades com apenas alguns atributos; 04. Muitas entidades relacionando-se uma mesma entidade; importante atentar para esses erros para que no haja acmulo de inconsistncias e que no torne a modelagem um processo problemtico. Mas no se preocupe em resolver tudo de uma vez s, pois mais a frente veremos formas de VALIDAR nossa modelagem, de maneira que os erros no passem despercebidos. Determinados os relacionamentos, temos que verificar o nmero de referncias de uma entidade em outra, ou seja, agora vamos verificar a CARDINALIDADE dos relacionamentos. Vejamos as possibilidades: - Relacionamento Um-Para-Um (1:1) Uma instncia da entidade A relaciona-se a uma instncia da entidade B - Relacionamento Um-Para-Vrios (1:N) Uma instncia da entidade A relaciona-se a vrias instncias da entidade B - Relacionamento Vrios-Para-vrios (N:M) Vrias instncias da entidade A relacionam-se a vrias instncias da entidade B Estas 3 cardinalidades apresentadas acima so implicitamente, CARDINALIDADES MXIMAS, mas pode-se determinar a CARDINALIDADE MNIMA, que pode ser descrita desta forma: - Relacionamento Um-Para-Vrios (0,1:1,N) Nenhuma ou uma instncia da entidade A relaciona-se uma ou vrias instancias da entidade B. Exemplo de relacionamento Um-Para-Vrios com cardinalidade mnima: Usuario - Emprestimo (1,1:0,N) - Um usurio pode estar relacionado a nenhum ou a vrios emprstimos. - Um emprstimo deve estar relacionado a somente um usurio. Concluso: Pode ser que um usurio nunca faa emprstimos, assim como pode haver usurio que faa vrios emprestimos, porm um emprstimo obrigatoriamente tem que ser feito por um nico usurio.

Exemplo de relacionamento Vrios-Para-Vrios com cardinalidade mnima: Emprestimo - Livro (0,N:1,N) - Um emprstimo pode estar relacionado a um ou a vrios livros. - Um livro pode estar relacionado a nenhum ou a vrios emprestimos. Concluso: Pode ser que um livro nunca seja emprestado, assim como pode haver livros que tenham sido emprestado vrias vezes, porm um emprstimo deve conter pelo menos um livro ou pode conter vrios. A Cardinalidade Mnima pode ser includa no Modelo Lgico, mas pouco utilizada por ser, muitas vezes, redundante e bvia, mas muito til no que refere expr a clareza dos relacionamentos entre entidades. Se voc est em dvida quanto quem o lado "Um" e quem o lado "Vrios" no seu relacionamento, use as seguintes dicas: - Veja em qual das entidades est o atributo que faz referencia outra entidade. Esta entidade onde est o atributo o lado "Vrios" a outra o lado "Um", trata-se ento de um relacionamento Um-Para-Vrios. - Se ambas as entidades tiverem atributos que referenciam uma outra, ento ambas possuem a cardinalidade "Varios", isto , trata-se de um relacionamento Vrios-Para-Vrios. Estas 2 regrinhas funcionam como frmulas. Apenas aplique-as ao seu relacionamento, sem pensar muito. Mesmo que fique um pouco confuso para voc, mais pra frente ver que elas so vlidas. Descrio do nosso Diagrama de Entidade-Relacionamento: Entidades: Usurio, Emprstimo, Livro Relacionamentos: Usuario-Emprestimo(1:N), Emprestimo-Livro(N-N) Na prxima matria mostrarei para vocs o Diagrama de Entidade-Relacionamento propriamente dito e as ferramentas de software que voc pode utilizar na modelagem do seu banco de dados. At a prxima!

Modelagem de Dados Validao do modelo ER

Tera-feira, 21/11/2006 s 12h18, por Mauri Gonalves

Nesta terceira parte da nossa srie, vou falar sobre a validao do Diagrama Entidade-Relacionamento: o DER. Tendo definido as entidades, seus atributos e relacionamentos, vamos fazer uma verificao em nosso modelo ER em busca de falhas. nesta fase que vamos validar nosso modelo ER e corrigir falhas em relacionamentos e possveis entidades que deveriam ou no existir. Nesta parte, tambm comeamos a visualizar o modelo fsico do banco de dados, onde as entidades viram tabelas e os atributos viram campos. Abaixo esto descritos os erros mais frequentes ocorridos no modelo: Associaes Incorretas: No modelo ER sempre pensamos nas associaes entre entidades no entre atributos. Seria incorreto por exemplo associar ao Livro (voltando ao nosso modelo Biblioteca) o nome do usurio que o tomou emprestado. No se pode associar o nome do usurio ao livro, e sim o usurio como um todo. Verifique se no h associaes entre atributos no seu modelo. Faa sempre associaes entre Entidades. Usar uma entidade como atributo de outra: No modelo lgico, as associaes ainda se do de forma abstrata. incorreto colocar na entidade Emprstimo o atributo Usurio, sendo que Usurio uma entidade associada e no um atributo e isso vale para qualquer outra entidade relacionada. Essa regra costuma gerar muita controvrsia porque costumamos confundir o conceito com o modelo fsico onde criamos as Chaves - mas este assunto veremos mais frente. Usar o nmero incorreto de entidades em um relacionamento: Verifique sempre os casos de mais de uma entidade associada mesma entidade. Nestes casos, o que surge um relacionamento redundante e desnecessrio. Depois de verificados e corrigidos os erros nas associaes (ou relacionamentos) devemos verificar se o modelo est completo. Nele devem ser expressadas todas as entidades, com seus atributos e relacionamentos. Para isso, verifique se possivel obter todas as informaes desejadas a partir do modelo construido e tambm se todas as transaes de dados pode ser executadas. Se tudo estiver ok, partimos para o prximo passo. Verificar redundncias: Um modelo de banco de dados deve ser "mnimo", ou seja, no apresentar nenhum tipo de redundncia. Para verificar a redundncia nas transaes com dados, analise a funo de cada relacionamento e reveja os que fizerem operaes muito semelhantes ou iguais. Verifique tambm se h ciclos associativos, por exemplo: "A associado a B que associado a C que associado a A" Neste caso, uma redundncia na parte "C que associado a A", pois C ja associado a A atravs da entidade B, ou seja, este exemplo representa uma associao desnecessria e pode ser descartada sem nenhum prejuzo para o modelo. O correto seria: "A associado a B que associado a C" Alm disso, podem haver atributos redundantes nas entidades. Atributos redundantes so aqueles que podem ter uma nomenclatura diferente porem eles

armazenam os mesmo dados, a mesma informao. Verifique a existencia destes atributos e elimine-os do modelo. Outro item considervel o aspecto de tempo do banco de dados. Quando construimos modelo ER, pensamos somente na situao momentnea do banco de dados. Para corrigir isso, devemos verificar atributos e relacionamentos que podem ser alterados durante a utilizao do banco de dados. Um exemplo timo de atributo, porm fora do nosso caso da Biblioteca, o Empregado. Suponha a existncia de uma entidade Empregado e o atributo Salario. A partir dessa entidade, pode-se criar uma entidade Salario com o atributo Data. Desta forma, obtm-se um histrico de salrios do empregado. Um exemplo de associao pode ser a associao entre Empregado e Departamento. Adicionando um atributo Data neste relacionamento, teremos um histrio de departamentos por onde o Empregado passou. Tambm importante levar em conta o armazenamento de informaes antigas. Para evitar o crescimento demasiado do banco de dados, podem ser eliminadas informaes antigas ou podem ser reinseridas no banco de outra forma. Por isso, importante pensar no caso de remoo de dados da base, que outras informaes seriam comprometidas. Deve-se planejar como guardar informaes antigas ou que com o passar do tempo no venham mais a ser utilizadas, como, por exemplo, informaes que sero usadas somente para clculos estatsticos ou vises. Pode ocorrem tambm a existncia de entidades isoladas, isto , sem nenhuma associao. A ocorrncia destas entidades no de todo incorreto, mas, na prtica, elas acabam sendo descartadas, por isso verifique se ela no faz parte de alguma associao incorreta ou que no tenha sido feita. Lembre-se que por mais simples que seja seu modelo ER, voc deve fazer a validao completa. Este o momento de corrigir erros e falhas de modelagem porque quando identificadas na modelagem fsica voc acaba tendo que voltar a esse passo para fazer a arrumao do problema. No proximo artigo, comeamos a falar sobre a Modelagem Fsica. At l.

Modelagem de Dados (Parte 04) - Abordagem Relacional

Quinta-feira, 04/01/2007 s 11h23, por Mauri Gonalves

A grande maioria dos Sistemas Gerenciadores de Banco de Dados (ou simplemente SGBD's) so Relacionais. Os bancos Relacionais so compostos por Tabelas ou Relaes. Este termo "Relaes" mais usado na literatura original sobre abordagem relacional (da a denominao "Relacional'), enquanto que "Tabela" um termo mais prtico e mais usado em produtos comerciais. Para no haver confuso de conceitos, vou me usar a terminologia "Tabela". Uma Tabela um conjunto no ordenado de linhas ou (tuplas - terminologia original) e cada linha possui campos (atributos). Cada campo identificado por um nome de campo (ou nome de atributo) e o conjunto de linhas de uma tabela, que possuem o mesmo nome chama-se coluna. Para muitos, nada disso novidade, mas no nos custa nada lembrar os conceitos. Algumas caractersticas especficas de uma tabela de banco de dados: - As linhas da tabela no so ordenadas. A recuperao de linhas em uma tabela acontece arbitrria, ou seja, a recuperao ser da forma como est no banco e pronto, a no ser que a ordem seja especificada pelo programador na sua consulta. - Os valores de campo de uma tabela de banco de dados so monovalorados. Pode-se apenas ter 1 valor em um campo, no sendo possivel armazenar "colees" como Arrays (ou Vetores) por exemplo. - A linguagem de consulta ao banco de dados permite o acesso por qualquer critrio envolvendo os campos de uma ou mais linhas. Em um arquivo de dados por exemplo necessrio um ndice ou esquema de ponteiros para buscar algum valor. Na verdade ndices tambm existem nos bancos de dados, mas isso no considerado pelo programador nas consultas s tabelas. Um item primordial quando falamos entre relacionamento entre linhas de tabelas a CHAVE. A chave primria formada por um ou mais campos de uma tabela e serve como identificador de uma linha. Porm a chave primria deve ser sempre mnima, ou seja, ser composta pelo menor nmero de campos possvel (no mnimo 1). Veremos mais adiante o uso de chaves com mais de um campo, que recebem o nome de "chave composta". Vistos os conceitos bsicos de um banco relacional, temos que considerar alguns pontos antes de iniciarmos a transformao de um modelo ER em um modelo fsico para o banco de dados: - O modelo ER no considera implementao com nenhum SGBD. muito comum, surgirem modificaes no esquema lgico para possibilitar a criao do modelo fsico e usar os recursos do SGBD. - Ao construir o seu banco fsico, voce deve considerar fatores como:

- Diminuir o nmero de acessos a disco: A cada consulta tabela, todas os campos da linha so carregados para a memria, mesmo que voce utilize apenas 1 deles) - Evitar junes: Em muitas consultar a banco, so feitas junes de dados em vrias linhas de tabelas. Utilize todos os dados necessrios de preferencia em uma nica linha diminuindo o nmero de junes, pois uma juno acaba envolvendo vrios acessos a disco. - Diminuir o nmero de chaves primrias: Fatalmente voce acabar juntado algumas tabelas que voc dividiu durante a modelagem lgico. Isso porque a presena de chaves em locais diferentes, armazenando a mesma informao acaba virando mais espao em disco utilizado e mais processamento. - Evitar campos opcionais: Tcnicamente um campo vazio no banco de dados no ocupa espao em disco, devido s tcnicas de compresso de dados existentes nos SGBDs de hoje. Mas o problema surge quando a obrigatoriedade ou no do preenchimento de um campo depende do valor de outro campo. Este fator acaba sendo resolvido via programao, ou seja, pelo sistema que vai acessar aquele banco e isso deve ser evitado. Algumas medidas de integridade de dados podem ser tomadas ja no banco, deixando o mnimo de campos que podem assumir o valor NULL. A transformao do modelo ER em um modelo relacional segue as seguinte etapas: - Traduo de Entidades e Atributos - Traduo de Relacionamentos e respectivos atributos - Traduo de generalizaes/especializaes Inicialmente, a traduo de entidades razovelmente obvia: uma entidade gera uma tabela. Cada atributo da entidade gera uma coluna e os atributos identificadores da entidade tornam-se chave primria. Essa uma traduo inicial. No decorrer da transformao entre modelos, algumas tabelas ainda podero ser fundidas ou divididas. Mesmo assim, no recomendvel apenas transcrever os nomes de atributos como nomes dos campos. Lembre que agora estamos falando de tabela fsica, de campos que sero acessados via programao ou seja, temos agora uma nova viso da situao. nessa fase que, por questes de boa prtica e organizao no processo de modelagem deseja-se que sejam definidos alguns "padres" para nomes de campos, abreviaturas e sempre primar por nomes curtos para os campos, ou seja das colunas da tabela. Para deixar mais claro a forma como voce deve fazer isso, vou mostrar um exemplo: Tem-se a entidade Pessoa com os atributos: Codigo, Nome, Endereo e Data de Nascimento. Cdigo o atributo identificador. Um exemplo de "traduo" dos campos seria: Tabela: Pessoa - Campos: CodPessoa, NomePess, EnderecoPess, DataNascPess Utilizei o seguinte padro:

- Para a chave primria, utilizei o prefixo "Cod" + o nome da tabela. - Para os demais campos utilizei o mesmo nome + o sufixo "Pess" em todos eles, identificando-os como sendo da tabela Pessoa. Mas h uma boa justificativa para esse sufixo "Pess" nos nomes: Ipotticamente em uma instruo SQL pode haver uma juno da tabela Pessoa com a tabela Departamento. Departamento tambm possui um campo Nome. recomendvel no utilizar o mesmo nome de campo em tabelas diferentes para no gerar a seguinte situao: SELECT Pessoa.Nome, Departamento.Nome FROM Pessoa, Departamento (...); Na seleo SQL de campos o mesmo nome, deve-se especificar o nome da tabela de origem, o que pode tornar a clusula muito longa, visto que consultas muitos mais complexas que essa so feitas com muita frequencia. SELECT NomePess, NomeDept FROM Pessoa, Departamento (...); A utilizao do sufixo para os mesmos campos de tabelas diferentes, nos poupa o trabalho de incluir o nome da tabela de origem, tornando a clusula SQL mais limpa e legvel, alm de tornar o campo reconhecido em qualquer consulta: (Todos os campos com final "Pess" sero reconhecidos como sendo da tabela Pessoa) Esse exemplo mostra que vrios fatores esto envolvidos na transformao para o modelo relacional. No proximo artigos seguiremos com a proxima etapa da traduo: Relacionamentos e Atributos.. Grande abrao e at l.

Modelagem de Dados - Parte 05 (Transformao entre Modelos)

Tera-feira, 06/02/2007 s 12h27, por Mauri Gonalves

Ol caros leitores! Vamos em frente com a srie de artigos sobre Modelagem de Dados. Essa parte da transformao entre modelos a parte mais interessante da modelagem. Aqui comea "de verdade" a surgir, finalmente, o banco de dados propriamente dito. Em especial a traduo dos relacionamentos (assunto que comeo a abordar hoje) o que deixa mais claro os conceitos vistos na modelagem conceitual, ou modelagem lgica. Um relacionamento nada mais do que uma "ligao" entre duas entidades (agora, Tabelas) que juntas criam informaes complexas. Como o assunto agora tabela fsica do banco de dados, nos temos que construir nossa base de forma "conectada". Para isso ns usamos as famosas CHAVES. As chaves tem variaes e diferentes finalidades. De forma rpida vou explicar um pouco sobre cada tipo de chave: Chave Primria: A chave primria o que chamvamos na modelagem lgica de "atributo identificador". Geralmente um campo da tabela que armazena uma informao nica, que no se repete em nenhum outro registro daquela mesma tabela. Desta forma ele serve como identificador daquele registro. Chave Composta: A chave composta formada pela chave primria e por alguma outra informao que tambm unica na tabela. Os dois campos juntos, formam uma chave composta. Este tipo de chave usado com mais frequencia em tabelas provenientes de relacionamentos N:N [vrios para vrios] (veremos mais frente). Chave Estrangeira: Esta chave um campo em uma tabela que armazena o contedo da chave prmria de outra tabela. Chave estrangeira sinnimo de relacionamento entre tabelas. Se h relacionamento h chave estrangeira. A primeira coisa que define a forma como voce vai traduzir o relacionamento a cardinalidade das entidades (assunto abordado no comeo da srie). Cardinalidade 1:N (Um-Para-Varios): Indica a adio de um campo na tabela correspondente ao "lado N". Esse campo ser uma chave estrangeira e vai armazenar a chave primria da tabela do "lado 1". Veja um esquema relacional que exemplifica esse tipo de cardinalidade: Funcionario (CodFuncionario, NomeFunc) Ramal (CodRamal, CodFuncionario, NumeroRamal) CodFuncionario referencia Funcionario Observe: Segundo a notao de Esquema Relacional, campo sublinhado indica Chave Primria. No esquema relacional da tabela Ramal temos dois campos sublinhados (indicando que os dois forma a chave primtica). O campo CodFuncionario no entanto uma chave estrangeira, porque ele armazena um valor que identifica um registro na tabela Funcionario. Cardinalidade N:N (Vrios-Para-Vrios): Este tipo de relacionamento gera uma terceira tabela. Neste caso nenhum dos lados do relacionamento vai armazer chave estrangeira (como no 1:N). O que vai acontecer que cria-se uma nova tabela, que vai armazenar as chaves de ambos os lados. Veja um esquema relacional que exemplifica esse tipo de cardinalidade:

Funcionario(CodFuncionario, NomeFunc) Projeto(CodProjeto, TituloProjeto) Participacao(CodFuncionario,CodProjeto) CodFuncionario referencia Funcionario CodProjeto referencia Projeto Observe: Segundo este esquema relacional, um funcionario pode participar de varios projetos, sendo que em um projeto pode-se ter vrios funcionarios. Neste caso cria-se mais uma tabela, que vai juntar as duas chaves do relacionamento. No exemplo, cria-se a tabela "Participacao" que indica o funcionario e qual projeto ele participa. Cardinalidade 1:1 (Um-Para-Um): Esse tipo de cardinalidade em grande maioria dos casos nao justifica um relacionamento. Mas pode ser implementado por questoes de organizao dos dados. Veremos futuramente na parte de Normalizao, como resolver relacionamentos 1:1.. No prximo artigo, continuamos a fazer a traduo de relacionamentos . At breve.

Modelagem de Dados - Parte 06 (Generalizaes / Especializaes)

Tera-feira, 15/05/2007 s 10h10, por Mauri Gonalves

Caros colegas. Estive ausente da coluna nesses 3 meses por motivos profissionais, mas aqui estou, e darei continuidade srie sobre Modelagem. No artigo anterior vimos como traduzir os relacionamentos. Para concluir essa etapa, vamos s recomendaes:

Traduo de relacionamentos orientada sempre pela cardinalidade mnima. Se houverem relacionamentos 1:1, verifique se no melhor fundir as 2 tabelas em uma nica. A chave primria colocada sempre na tabela que corresponde ao lado N do relacionamento 1:N. Relacionamentos N:N sempre geram uma terceira, com as chaves primrias das 2 tabelas originais. Se necessrio, escreva o esquema relacional do seu banco de dados, antes de gerar suas tabelas.

A traduo de generalizaes/especializaes tem alguns aspectos particulares que devemos analisar. Primeiramente vamos supor uma entidade com especializaes: Entidade: Pessoa - Atributos: Cdigo, Nome, Endereo e Telefone Entidade: Pessoa Fisica - Atributos: Todos os atributos de Pessoa, CPF, RG Entidade: Pessoa Jurfica - Atributos: Todos os atributos de Pessoa, CNPJ, IE, Razo Social As entidades Pessoa Fsica e Jurdica so especializaes da entidade Pessoa. Como representar isso no banco de dados? Bem, nesse caso temos 2 alternativas: 1) Criar uma nica tabela para todas as especializaes e incluir um campo diferenciador: Seria juntar todos os tipos de Pessoa, em uma nica tabela e acrescentar mais um campo para identificar a Pessoa. Exemplo: Pessoa: Cdigo, TipoDePessoa, Nome, Endereo, Telefone, CPF, RG, CNPJ, IE, RazaoSocial 2) Criar uma tabela para cada especializao e definir mais um campo identificador Pessoa: Cdigo, Nome, Endereo, Telefone Pessoa_Fisica: CodPessoa, CPF, RG Pessoa_Juridica: CodPessoa, CNPJ, IE, RazaoSocial A vantagem da primeira alternativa que no precisaremos fazer junes da tabela generalizada (Pessoa) com a tabela especializada (Pessoa Fsica ou Jurdica) quando precisarmos de informaes especficas. Outra vantagem que a

chave primria da tabela Pessoa fica armazenada somente 1 vez no banco de dados. A desvantagem que, ao fazermos uma consulta no banco de dados, a linha inteira (todos os campos) so carregados na memria, mas sabemos que havero campos em branco, dependendo do tipo de Pessoa cadastrada. Na segunda alternativa, h a necessidade de fazer junes quando formos obter todas as informaes de uma Pessoa. Porm, a vantagem que teremos somente os dados necessrios sem a necessidade de carregar todos os campos na memria, gerando mais acessos ao banco de dados. As chaves primrias de Pessoa so repetidas nas tabelas especializadas e, quando houver atualizao das informaes de uma pessoa, haver a necessidade de criar uma instruo para cada tabela especializada. A escolha de um dos tipos de traduo para generalizaes/especializaes ir depender do projeto que est sendo construdo e dos recursos disponveis para quem est modelando. Nada impede que as duas alternativas sejam usadas no mesmo projeto de banco de dados, uma alternativa pra cada caso de tabelas generalizadas. Concludas as etapas de traduo entre modelos, temos o banco de dados formado, com suas tabelas, campos e relacionamentos. No prximo artigo falarei sobre como refinar o seu modelo relacional e tambm sobre a Normalizao do seu banco de dados. Observaes: Nesta srie de artigos, eu fao uma anlise de alto nvel sobre a Modelagem de Dados sem aprofundar-me nos processos de modelagem. Se for do seu interesse, vale a pena pesquisar o contedo especfico sobre cada etapa que descrevi nessa srie. Se voc me enviou e-mails e no obteve resposta, peo a gentileza de reenviar. Fao questo de responder a todas as mensagens, apesar do pouco tempo hbil. At a prxima!

Modelagem de Dados - Final (Normalizao)

Segunda-feira, 24/09/2007 s 09h05, por Mauri Gonalves

Caros leitores. Estou de volta com a ltima parte desta srie, onde falarei sobre Normalizao. Normalizao um processo baseado nas chamadas formais normais. Uma forma normal uma regra de deve ser aplicada na construo das tabelas do banco de dados para que estas fiquem bem projetadas. Segundo autores, existem 4 formas normais. Neste artigo vou falar sobre as 3 primeiras, sendo as principais. Com o banco de dados construdo, devem-se aplicar as 3 formas normais em cada tabela, ou grupo de tabelas relacionadas. As formas tm uma ordem e so dependentes, isto , para se aplicar a segunda norma, deve-se obrigatoriamente ter aplicado a primeira e assim por diante. Ento, vamos s normas:
1 Forma Normal: Verificao de Tabelas Aninhadas.

Para uma tabela estar na primeira forma normal ela no deve conter tabelas aninhadas. Um jeito fcil de verificar esta norma fazer uma leitura dos campos das tabelas fazendo a pergunta: Este campo depende de qual?. Vamos exemplificar, com a tabela Venda. Este o esquema relacional da tabela: Venda(Codvenda, Cliente, Endereco, Cep, Cidade, Estado, Telefone, Produto, Quantidade, Valorunitario, Valorfinal). O raciocnio o seguinte: A tabela Venda, deve armazenar informaes da venda. Pois bem, verificando o campo Cliente, sabemos que ele depende de CodVenda, afinal para cada Venda h um cliente. Vendo o campo Endereo, podemos concluir que ele no depende de Codvenda, e sim de Cliente, pois uma informao referente particularmente ao cliente. No existe um endereo de venda, existe sim um endereo do cliente para qual se fez a venda. Nisso podemos ver uma tabela aninhada. Os campos entre colchetes, so referentes ao cliente e no venda. Venda (Codvenda, [Cliente, Endereo, Cep, Cidade, Estado, Telefone, Produto, Quantidade, Valorunitario, Valorfinal). A soluo extrair estes campos para uma nova tabela, adicionar uma chaveprimria nova tabela e relaciona-la com a tabela Venda criando uma chaveestrangeira. Ficaria desta forma: Cliente (Codcliente, Nome, Endereo, Cep, Cidade, Estado, Telefone). Venda (Codvenda, Codcliente, Produto, Quantidade, Valorunitario, Valorfinal). Agora aplicamos novamente primeira forma normal as 2 tabelas geradas. Uma situao comum em tabelas de cadastro o caso Cidade-Estado. Analisando friamente pela forma normal, o Estado na tabela Cliente, depende de Cidade. No

entanto Cidade, tambm depende de Estado, pois no caso de a cidade ser Curitiba o estado sempre dever ser Paran, porm se o Estado for Paran, a cidade tambm poder ser Londrina. Isso o que chamamos de Dependncia funcional: onde aparentemente, uma informao depende da outra. No caso Cidade-Estado a soluo simples: Extramos Cidade e Estado, de Cliente e geramos uma nova tabela. Em seguida, o mesmo processo feito anteriormente: adicionar uma chave-primria nova tabela e relaciona-la criando uma chave-estrangeira na antiga tabela. Cidade (Codcidade, Nome, Estado). Cliente (Codcliente, Codcidade, Nome, Endereo, Cep, Telefone). Venda (Codvenda, Codcliente, Codcidade, Produto, Quantidade, Valorunitario, Valorfinal). Seguindo com o exemplo, a tabela Cliente encontra-se na 1 forma normal, pois no h mais tabelas aninhadas. Verificando Venda, podemos enxergar mais uma tabela aninhada. Os campos entre colchetes so referente mesma coisa: Produto de Venda Venda (Codvenda, Codcliente, Codcidade, [Produto Quantidade, [Valorunitario, Valorfinal). Na maioria das situaes, produtos tm um valor previamente especificado. O Valorunitrio depende de Produto. J a Quantidade (campo entre Produto e Valorunitario) no depende do produto e sim da Venda. Cidade (Codcidade, Nome, Estado). Cliente (Codcliente, Codcidade, Nome, Endereo, Cep, Telefone). Produto (Codproduto, Nome, Valorunitario). Venda (Codvenda, Codcliente, Codcidade, Codproduto, Quantidade, Valorfinal). Passando a tabela Venda pela primeira forma normal, obtivemos 3 tabelas. Vamos prxima forma
2 Forma Normal: Verificao de Dependncias Parciais

Para uma tabela estar na segunda formal, alm de estar na primeira forma ela no deve conter dependncias parciais. Um jeito de verificar esta norma refazer a leitura dos campos fazendo a pergunta: Este campo depende de toda a chave? Se no, temos uma dependncia parcial.. Vimos antes o caso Cidade-Estado que gerava uma dependncia funcional. preciso entender este conceito para que voc entenda o que Dependncia Parcial. Aps a normalizao da tabela Venda, acabamos com uma chave composta de 4 campos: Venda (Codvenda, Codcliente, Codcidade, Codproduto, Quantidade, Valorfinal). A questo agora verificar se cada campo no-chave depende destas 4 chaves. O raciocnio seria assim: 1. O primeiro campo no-chave Quantidade. 2. Quantidade depende de Codvenda, pois para cada venda h uma quantidade especfica de itens.

3. Quantidade depende de Codvenda e Codcliente, pois para um cliente podem ser feitas vrias vendas, com quantidades diferentes. 4. Quantidade no depende de Cidade. Quem depende de Cidade Cliente. Aqui est uma dependncia parcial. 5. Quantidade depende de Codproduto, pois para cada produto da Venda uma quantidade certa. Quantidade depende de 3 campos, dos 4 que compe a chave de Venda. Quem sobrou nessa histria foi Codcidade. A tabela Cidade j est ligada com Cliente, que j est ligado com Venda. A chave Codcidade em Venda redundante, portanto podemos elimin-la. Venda (Codvenda, Codcliente, Codproduto, Quantidade, Valorfinal). O prximo campo no-chave Valorfinal. Verificando Valorfinal, da mesma forma que Quantidade, ele depende de toda a chave de Venda. Portanto vamos prxima norma.
3 Forma Normal: Verificao de Dependncias Transitivas

Para uma tabela estar na segunda formal, alm de estar na segunda forma ela no deve conter dependncias transitivas. Um jeito de verificar esta norma refazer a leitura dos campos fazendo a pergunta: Este campo depende de outro que no seja a chave? Se Sim, temos uma dependncia transitiva.. No exemplo de Venda, temos um caso de dependncia transitiva: Na tabela Venda, temos Valorfinal. Este campo o resultado do valor unitrio do produto multiplicado pela quantidade, isto , para um valor final existir ele DEPENDE de valor unitrio e quantidade. O Valorunitrio est na tabela Produto, relacionada Venda e Quantidade est na prpria Venda. Valorfinal depende destes 2 campos e eles no so campos-chave, o que nos leva a pensar: Se temos valor unitrio e quantidade, porque teremos valor final? O valor final nada mais que o resultado de um clculo de dados que j est esto no banco, o que o torna um campo redundante. Quando for necessrio ao sistema obter o valor final, basta selecionar o valor unitrio e multiplicar pela quantidade. No h porque guardar o valor final em outro campo. Aqui a soluo eliminar o campo Valorfinal. Cidade (Codcidade, Nome, Estado). Cliente (Codcliente, Codcidade, Nome, Endereco, Cep, Telefone). Produto (Codproduto, Nome, Valorunitario). Venda (Codvenda, Codcliente, Codproduto, Quantidade). Em tese, agora temos todas as tabelas normalizadas. Ainda restou o caso do campo Estado na tabela Cidade, mas eu deixarei para uma outra ocasio, pois o objetivo aqui mostrar conceitualmente o processo de normalizao do banco de dados. muito comum, no processo de normalizao enxergamos todas as formas normais ao mesmo tempo. Enquanto separamos as tabelas aninhadas, j conseguimos ver as dependncias transitivas e logo mais encontramos uma dependncia parcial, tudo assim, ao mesmo tempo. Isso normal. S tome cuidado, para no deixar nada passar batido.

Reforando o recado do artigo anterior: tem muito mais a ser visto sobre as etapas que eu mostrei nessa srie. Aqui foi s uma demonstrao do que se deve levar em conta ao modelar e construir um banco de dados ntegro, correto e que aproveita os dados da forma mais eficiente possvel. Um abrao todos e at o prximo artigo!