Modelo Relacional - Entidades e atributosModelo Relacional de DadosO modelo relacional um modelo de dados, adequado a ser o modelo subjacente de um Sistema Gerenciador de Banco de Dados (SGBD), que se baseia no princpio em que todos os dados esto guardados em tabelas (ou, matematicamente falando, relaes). Toda sua definio terica e baseada na lgica de predicados e na teoria dos conjuntos. O conceito foi criado por Edgar Frank Codd em 1970, sendo descrito no artigo "Relational Model of Data for Large Shared Data Banks". O modelo relacional para gerncia de bancos de dados (SGBD) um modelo de dados baseado em lgica e na teoria de conjuntos. Em definio simplificada, o modelo baseia-se em dois conceitos: conceito de entidade e relao. Entidade: Uma entidade um elemento caracterizado pelos dados que so recolhidos na sua identificao vulgarmente designado por tabela. Na construo da tabela identificam-se os dados da entidade a atribuio de valores a uma entidade constri um registro da tabela. Relao: A relao determina o modo como cada registro de cada tabela se associa a registros de outras tabelas.

Historicamente ele o sucessor do modelo hierrquico e do modelo em rede. Estas arquiteturas antigas so at hoje utilizadas em alguns data centers com alto volume de dados, onde a migrao inviabilizada pelo custo que ela demandaria; existem ainda os novos modelos baseados em orientao ao objeto, que na maior parte das vezes so encontrados como kits em linguagem formal. A linguagem padro para os bancos de dados relacionais, SQL, apenas vagamente remanescente do modelo matemtico. Atualmente ela adotada, apesar de suas restries, porque ela antiga e muito mais popular que qualquer outra linguagem de banco de dados. O modelo relacional permite ao projetista criar um modelo lgico consistente da informao a ser armazenada. Este modelo lgico pode ser refinado atravs de um processo de normalizao. Um banco de dados construdo puramente baseado no modelo relacional estar inteiramente normalizado.

Regras bsicas de um banco de dados relacional segundo Codd: Informao representada por valores contidos nas tabelas; Garantia de acesso; Representao de valores nulos; Definio de catlogo on-line (dicionrio de dados);

Utilizao de sublinguagem;

Entidades e Atributos:Toda a Informao de um banco de dados relacional armazenada em Tabelas, que na linguagem do modelo relacional, tambm so chamadas de Entidades. Representam objetos do mundo real, como clientes, banco, conta etc. Por exemplo, posso ter uma Tabela "Clientes", onde seriam armazenadas informaes sobre os diversos clientes. Sobre cada um dos clientes podem ser armazenadas diversas informaes tais como: Nome RG CPF Rua Bairro Telefone CEP Data de Nascimento

Essas diversas caractersticas de cada Cliente so os "Atributos" da entidade Cliente, tambm chamados de campos da tabela Cliente. Os atributos representam as propriedades das entidades. Existem apenas para caracterizar uma entidade. "O Conjunto de todos os Atributos de um cliente e os valores dos atributos o que forma o Registro do Cliente". Com isso temos uma Tabela que constituda por um conjunto de Registros (uma linha completa com informaes sobre o cliente) e cada Registro formado por um conjunto de atributos (Nome, Endereo, etc).

Resumindo:Entidade ou Tabela: Um conjunto de Registros. Campos ou Atributos: Caractersticas Individuais da tabela.

Modelo Relacional - Chave primriaO Conceito de "Chave Primria" fundamental para o correto entendimento de como funciona um Banco de Dados baseado no modelo relacional. A funo essencial da chave primria de uma tabela identificar unicamente as suas linhas nem mais nem menos. Cada valor de chave primria deve ser nico dentro de uma tabela, de modo que o motor da base de dados possa saber a diferena entre as linhas. O mesmo valor de chave primria pode aparecer em outra tabela, mas no pode ser duplicado dentro dela. E a chave primria no pode ter um valor Nulo pois o motor de base de dados exige um valor para poder localizar o registro. A segunda maior funo da chave primria fornecer um "gancho" para a criao de relacionamentos entre tabelas. Um campo chave primria relacionado a um campo correspondente, a chave estrangeira, em outra tabela. Os valores da chave primria e da chave estrangeira so os mesmos para registros ligados por meio de um relacionamento. "Ao Definirmos um Campo como sendo uma Chave Primria, estamos informando ao Oracle que no podem existir dois registros com o mesmo valor no campo que a Chave Primria, ou seja, os valores no campo Chave Primria precisam ser nicos". Por exemplo, se defino um campo "Nmero da Identidade", da tabela Clientes, como sendo um campo do tipo Chave Primria, estou dizendo que no podem ser cadastrados dois clientes com o mesmo valor no campo "Nmero da Identidade". Na prtica estou garantindo que no possam ser cadastrados dois clientes com o mesmo Nmero de Identidade". Em outras palavras poderamos dizer que o Campo Chave Primria identifica de Maneira nica cada Registro de uma Tabela, isto , de posse do valor da Chave Primria somente localizaremos um registro com aquele valor no campo Chave Primria.

Outros exemplos de campos que podem ser definidos como chaves primria: Campo CPF em uma tabela de cadastro de clientes. Campo CNPJ em uma tabela de cadastro de fornecedores. Matrcula do aluno em uma tabela de cadastro de alunos. Cdigo da Pea em uma tabela de cadastro de peas. Matrcula do funcionrio em uma tabela de cadastro de funcionrios. Nmero do pedido em uma tabela de cadastro de pedidos

Este um conceito muito importante, pois conforme veremos mais adiante os conceitos de Integridade Referencial e Normalizao esto diretamente ligados ao conceito de Chave Primria. Aps ter definido um campo como sendo a Chave Primria da tabela, o prprio banco de dados (quer seja Access, SQL Server, ORACLE ou qualquer outro), garante que no sejam inseridos dados duplicados no campo que a chave primria. Por exemplo, se o usurio tentar cadastrar um pedido com o mesmo nmero de um pedido j existente, o registro no ser cadastrado e uma mensagem de erro ser emitida. Um ltimo detalhe importante para lembrarmos, que a Chave Primria pode ser formada pela combinao de Mais de Um Campo. Podem existir casos em que um nico campo no capaz de atuar como chave primria, pelo fato deste apresentar valores repetidos. Nestes casos podemos definir uma combinao de 2 ou mais campos para ser a nossa chave primria.

Alm disso, uma tabela somente pode ter uma Chave Primria, seja ela simples ou composta. Ou seja, no pode definir dois ou mais campos de uma tabela para serem cada um, uma chave primria separada. No confundir com o caso de uma chave primria composta, onde a unio de dois ou mais campos que forma a nica chave primria da tabela. Ou seja, cada tabela pode ter uma nica chave primria.

Como identificar uma chave-primriaGeralmente, um nmero de identificao exclusivo, como um nmero de identificao ou um nmero de srie ou cdigo, serve como uma chave primria em uma tabela. Por exemplo, voc pode ter uma tabela Clientes em que cada cliente possui um nmero de identificao do cliente exclusivo. O campo Identificao do Cliente a chave primria. Uma boa candidata a uma chave primria possui vrias caractersticas. Primeiro, ela identifica de maneira exclusiva cada linha. Segundo, nunca est vazia ou nula ela sempre contm um valor. Terceiro, ela raramente (o ideal seria nunca) muda. Um exemplo de opo ruim para chave primria um nome ou endereo. Ambos contm informaes que podem mudar com o tempo. Um bom Sistema Gerenciador de Banco de Dados (SGBD) aquele que encontra e nos fornece, rapidamente, todas as informaes necessrias que nele estejam armazenadas, mesmo que estas informaes estejam em diferentes tabelas. Para que isto seja possvel necessrio incluir um campo ou conjunto de campos que identifiquem de modo nico cada registro de uma tabela. Esta informao chamada Chave Primria. Deve-se ter certeza que este campo (ou conjunto de campos) seja sempre diferente para cada registro, por no ser permitido valores duplicados em um campo de chave primria.

Ao escolher campos de Chave Primria, considere os seguintes detalhes: No permitido duplicidade de valores ou nulos (informaes desconhecidas). Caso no exista um identificador nico para uma determinada tabela, pode-se usar um campo que numere os registros seqencialmente. Pode-se utilizar o valor deste campo para encontrar registros. O tamanho da chave primria afeta a velocidade das operaes, portanto, para um melhor desempenho, devemos utilizar o menor tamanho que acomode os valores necessrios que sero armazenados no campo.

Modelo Relacional - Relacionamento entre as tabelasUm banco de dados composto por diversas tabelas, como por exemplo: Clientes, Produtos, Pedidos, Detalhes do Pedido, etc. Embora as informaes estejam separadas em cada uma das Tabelas, na prtica devem existir relacionamentos entre as tabelas. Por exemplo: Um Pedido feito por um Cliente e neste Pedido podem existir diversos itens, itens que so gravados na tabela Detalhes do Pedido. Alm disso, cada Pedido possui um nmero nico (Cdigo do pedido), mas um mesmo Cliente pode fazer diversos pedidos e assim por diante. Em um banco de dados, precisamos de alguma maneira para representar estes relacionamentos da vida Real, em termos das tabelas e de seus atributos. Isto possvel com a utilizao de "Relacionamentos entre tabelas", os quais podem ser de trs tipos: Um para Um Um para Vrios Vrios para Vrios

Relacionamento do Tipo Um para Um:Esta relao existe quando os campos que se relacionam, so ambos do tipo Chave Primria, em suas respectivas tabelas. Cada um dos campos no apresenta valores repetidos. Na prtica existem poucas situaes onde utilizaremos um relacionamento deste tipo. Um exemplo poderia ser o seguinte: Imagine uma escola com um Cadastro de Alunos na tabela Alunos, destes apenas uma pequena parte participa da Banda da Escola. Por questes de projeto do Banco de Dados, podemos criar uma Segunda Tabela "Alunos da Banda", a qual se relaciona com a tabela Alunos atravs de um relacionamento do tipo Um para Um. Cada aluno somente cadastrada uma vez na Tabela Alunos e uma nica vez na tabela Alunos da Banda. Poderamos utilizar o Campo Matrcula do Aluno como o Campo que relaciona as duas Tabelas. Importante: O campo que relaciona duas tabelas deve fazer parte, ter sido definido, na estrutura das duas tabelas. Na tabela Alunos da Banda poderamos colocar apenas o Nmero da Matrcula do aluno, alm das informaes a respeito do Instrumento que ele toca, tempo de banda, etc. Quando fosse necessrio buscar as informaes tais como nome, endereo, etc, estas podem ser recuperadas atravs do relacionamento existente entre as duas tabelas, evitando, com isso, que a mesma informao (Nome, Endereo, etc) tenha que ser duplicada nas duas tabelas, inclusive aumentando a probabilidade de erros de digitao.

Relacionamento do Tipo Um para Vrios:Este , com certeza, o tipo de relacionamento mais comum entre duas tabelas. Uma das tabelas (o lado um do relacionamento) possui um campo que a Chave Primria e a outra tabela (o lado vrios) se relaciona atravs de um campo cujos valores relacionados podem se repetir vrias vezes. Considere o exemplo entre a tabela Clientes e Pedidos. Cada Cliente somente cadastrado uma nica vez na tabela de Clientes (por isso o campo Cdigo do Cliente, na tabela Clientes, uma chave primria, indicando que no podem ser cadastrados dois clientes com o mesmo cdigo), portanto a tabela Clientes ser o lado um do relacionamento. Ao mesmo tempo cada cliente pode fazer diversos pedidos, por isso que o mesmo Cdigo de Cliente poder aparecer vrias vezes na tabela Pedidos: tantas vezes quantos forem os pedidos que o Cliente tiver feito. Por isso que temos um relacionamento do tipo Um para Vrios entre a tabela Clientes e Pedidos, atravs do campo Cdigo do Cliente, indicando que um mesmo Cliente pode realizar diversos (vrios) pedidos. No lado Um do relacionamento o campo definido como uma Chave Primria (Campo CdigoDoCliente na tabela Clientes) e no lado Vrios no (campo CdigoDoCliente na tabela Pedidos), indicando que no lado vrios o Cdigo do Cliente pode se repetir vrias vezes, o que faz sentido, uma vez que um mesmo cliente pode fazer diversos pedidos. IMPORTANTE: Observe que o campo que o lado vrios do relacionamento no pode ser definido como chave primria. Lembrando do conceito de Chave Primria: Chave Primria o campo no qual no podem haver valores repetidos. Ora, se o campo est no lado "vrios", significa que ele poder ter o seu valor repetido em vrios registros. Por exemplo, na tabela pedidos, poder haver vrios registros para o mesmo cliente. Se o campo ter que ter valores repetidos, ento ele no pode ser definido como chave primria.

Relacionamento do tipo Vrios para Vrios:Este tipo de relacionamento "aconteceria" em uma situao onde em ambos os lados do relacionamento os valores poderiam se repetir. Vamos considerar o caso entre Produtos e Pedidos. Posso ter Vrios Pedidos nos quais aparece um determinado produto, alm disso vrios Produtos podem aparecer no mesmo Pedido. Esta uma situao em que temos um Relacionamento do Tipo Vrios para Vrios. Na prtica no possvel implementar um relacionamento deste tipo, devido a uma srie de problemas que seriam introduzidos no modelo do banco de dados. Por exemplo, na tabela Pedidos teramos que repetir o Nmero do Pedido, Nome do Cliente, Nome do Funcionrio, Data do Pedido, etc para cada item do Pedido.

Para evitar este tipo de problema bastante comum "quebrarmos" um relacionamento do tipo Vrios para Vrios em dois relacionamento do tipo Um para Vrios. Isso feito atravs da criao de uma nova tabela, a qual fica com o lado Vrios dos relacionamentos. No nosso exemplo vamos criar a tabela Detalhes do Pedido, onde ficam armazenadas as informaes sobre os diversos itens de cada pedido, a ao invs de termos um relacionamento do tipo Vrios para Vrios, teremos dois relacionamentos do tipo um para vrios, conforme descrito pela prxima tabela:

Concluso:Implementar um banco de dados sem se preocupar com um projeto cuidados dos relacionamentos, garantia certa de "encrenca" mais adiante. So consultas que retornam dados inesperados, so relatrios que retornam valores "absurdos" e por a vai. fundamental que os profissionais de desenvolvimento e de administrao de banco de dados entendem o quo impotante planejar o banco de dados, cuidadosamente, definindo quais tabelas faro parte do banco de dados, quais os campos de cada tabela, quais campos sero chave primria e qual o relacionamento entre as tabelas. Muitos acham que esta uma "perda de tempo", que o bom mesmo sentar e comear a implementar o banco de dados, depois "a gente v o que d". No perda de tempo, muito pelo contrrio, um ganho de tempo e principalmente de qualidade no produto final. Quanto tempo perdido depois, tentando corrigir erros e incosistncias que muitas vezes so decorrentes de um banco de dados mal projetado?

Modelo Relacional - Integridade ReferencialA Integridade Referencial utilizada para garantir a Integridade dos dados entre as tabelas relacionadas. Por exemplo, considere um relacionamento do tipo Um-para- Vrios entre a tabela Clientes e a tabela Pedidos (um cliente pode fazer vrios pedidos). Com a Integridade Referencial, o banco de dados no permite que seja cadastrado um pedido para um cliente que ainda no foi cadastrado. Em outras palavras, ao cadastrar um pedido, o banco de dados verifica se o cdigo do cliente que foi digitado j existe na tabela Clientes. Se no existir, o cadastro do pedido no ser aceito. Com o uso da Integridade Referencial possvel ter as seguintes garantias (ainda usando o exemplo entre as tabelas Clientes e Pedidos): Quando o Cdigo de um cliente for alterado na Tabela Clientes, podemos configurar para o banco de dados atualizar, automaticamente, todos os Cdigos do Cliente na Tabela Pedidos, de tal maneira que no fiquem Registros rfos, isto , registros de Pedidos com um Cdigo de Cliente para o qual no existe mais um correspondente na Tabela Clientes. Essa ao conhecida como "Propagar atualizao dos campos relacionados". Quando um Cliente for excludo da Tabela Clientes, podemos configurar para que o banco de dados exclua, automaticamente, na tabela Pedidos, todos os Pedidos para o Cliente que est sendo Excludo. Essa opo conhecida como "Propagar excluso dos registros relacionados". Essas opes podem ser configuradas quando da Definio dos Relacionamentos. Estas opes no so obrigatrias, isto , podemos optar por no Atualizar ou no Excluir em cascata. A Opo de "Propagar atualizao dos campos relacionados" utilizada na maioria das situaes, j a opo de "Propagar excluso dos registros relacionados" deve ser estudada caso a caso. Por exemplo, se ns quisssemos manter um histrico com os Pedidos de cada Cliente, no utilizaramos a opo "Propagar excluso dos registros relacionados"; caso no nos interessasse manter um histrico dos pedidos, poderamos utilizar esta opo.

Modelo Relacional - Normalizao de tabelasO objetivo da normalizao evitar os problemas provocados por falhas no Projeto do Banco de Dados, bem como eliminar a "mistura de assuntos" e as correspondentes repeties desnecessrias de dados. Uma Regra de Ouro que devemos observar quando do Projeto de um Banco de Dados baseado no Modelo Relacional de dados a de "no Misturar assuntos em uma mesma Tabela". Por exemplo, na Tabela Clientes devemos colocar somente campos relacionados com o assunto Clientes. No devemos misturar campos relacionados com outros assuntos, tais como Pedidos, Produtos, etc. Essa "Mistura de Assuntos" em uma mesma tabela acaba por gerar repetio desnecessria dos dados bem como inconsistncia dos dados. O Processo de Normalizao aplica uma srie de Regras sobre as Tabelas de um Banco de Dados, para verificar se estas esto corretamente projetadas. Embora existam 5 formas normais (ou regras de Normalizao), na prtica usamos um conjunto de 3 Formas Normais. Normalmente aps a aplicao das Regras de Normalizao, algumas tabelas acabam sendo divididas em duas ou mais tabelas, o que no final gera um nmero maior de tabelas do que o originalmente existente. Este processo causa a simplificao dos atributos de uma tabela, colaborando significativamente para a estabilidade do modelo de dados, reduzindo-se consideravelmente as necessidades de manuteno. Vamos entender o Processo de Normalizao na Prtica, atravs de exemplos.

Primeira Forma Normal:"Uma Tabela est na Primeira Forma Normal quando seus atributos no contm grupos de Repetio". Por isso dissemos que uma Tabela que possui Grupos de Repetio no est na Primeira Forma Normal. Considere a estrutura da Tabela Indicada na Prxima Figura

Tabela que no est na Primeira Forma Normal. Uma tabela com esta estrutura apresentaria diversos problemas. Por exemplo se um casal tiver mais de um filho, teremos que digitar o Nome do Pai e da Me diversas vezes, tantas quantos forem os filhos. Isso forma um Grupo de Repetio. Alm do mais pode ser que por erro de digitao o Nome dos Pais no seja digitado exatamente igual todas s vezes, o que pode acarretar problemas na hora de fazer pesquisas ou emitir relatrios. Este problema ocorre porque "Misturamos Assuntos" em uma mesma tabela. Colocamos as informaes dos Pais e dos Filhos em uma mesma tabela. A resoluo para este problema simples: Criamos uma tabela separada para a Informao dos Pais e Relacionamos a tabela Pais com a Tabela Filhos atravs de um relacionamento do tipo Um para Vrios, ou seja, um casal da Pais pode ter Vrios Filhos. Observem na figura abaixo as duas tabelas: Pais e Filhos, j normalizadas.

Segunda Forma Normal:Ocorre quando a chave Primria composta por mais de um campo. Neste caso, devemos observar se todos os campos que no fazem parte da chave dependem de todos os campos que compem a chave. Se algum campo depender somente de parte da chave composta, ento este campo deve pertencer a outra tabela. Observe o Exemplo Indicado na Tabela da Figura abaixo:

Tabela com uma Chave Primria Composta. No est Na Segunda Forma Normal.

A Chave Primria Composta formada pela combinao dos Campos "NmeroDaMatrcula" e "CdigoDoCurso". O Campo Avaliao depende tanto do CdigoDoCurso quanto do NmeroDaMatrcula, porm o campo DescrioDoCurso, depende apenas do CdigoDoCurso, ou seja, dado o cdigo do curso possvel localizar a respectiva descrio, independentemente do NmeroDaMatrcula. Com isso temos um campo que no faz parte da Chave Primria e depende apenas de um dos campos que compem a chave Primria Composta, por isso que dizemos que esta tabela no est na Segunda Forma Normal. A Resoluo para este problema tambm simples: "Dividimos a Tabela que no est na Segunda Forma Normal em duas outras tabelas, conforme indicado pela figura abaixo, sendo que as duas tabelas resultantes esto na Segunda Forma Normal.

Informaes sobre Avaliaes e Cursos em Tabelas Separadas. OBS -> A Distino entre a Segunda e a Terceira forma normal, que veremos logo em seguida, muitas vezes confusa. A Segunda Forma normal est ligada a ocorrncia de Chaves Primrias compostas.

Terceira Forma Normal:Na definio dos campos de uma entidade podem ocorrer casos em que um campo no seja dependente diretamente da chave primria ou de parte dela, mas sim dependente de um outro campo da tabela, campo este que no a Chave Primria. Quando isto ocorre, dizemos que a tabela no est na Terceira Forma Normal, conforme indicado pela tabela da figura abaixo:

Tabela com um Campo dependente de Outro campo que no a Chave Primria. No est na Terceira Forma Normal. Observe que o Campo DescrioDoCargo depende apenas do Campo CdigoDoCargo, o qual no faz parte da Chave Primria. Por isso dizemos que esta tabela no est na terceira forma normal. A Soluo deste problema tambm simples. Novamente basta dividir a tabela em duas outras, conforme indicado pela figura a seguir. As duas tabelas resultantes esto na Terceira Forma Normal.

Tabelas Resultantes que esto na Terceira Forma Normal. Com isso podemos concluir que como resultado do Processo de Normalizao, iremos obter um nmero maior de tabelas, porm sem problemas de redundncia e inconsistncia dos dados.

Modelo Relacional - Projetando um Banco de DadosUm banco de dados bem projetado fornece um acesso conveniente s informaes desejadas. Com uma boa estrutura, gasta-se menos tempo na construo de um banco de dados e, ao mesmo tempo, assegura-se resultados mais rpidos e precisos. Nunca demais lembrar que jamais devemos misturar assuntos em uma mesma tabela.

Etapas na estruturao e projeto de um Banco de dados: Determinar qual o objetivo do banco de dados: Isto ajuda na determinao de quais os dados devem ser armazenados. fundamental ter bem claro qual o objetivo a ser alcanado com o banco de dados. fazer o acompanhamento das despesas, a evoluo das vendas ou outro objetivo qualquer. Determinar as tabelas necessrias: Aps definirmos os objetivos do Banco de Dados, as informaes devem ser definidas e separadas em assuntos diferentes, tais como "Clientes", "Empregados", "Pedidos", pois cada um ir compor uma tabela no banco de dados. Lembre-se da regrinha nmero um: "No misturar assuntos na mesma tabela", ou seja, uma coisa uma coisa e outra coisa outra coisa. Determinar os Campos de cada Tabela: Definir quais informaes devem ser mantidas em cada tabela. Por exemplo, a tabela Clientes poderia ter um campo para o Cdigo Do Cliente, outro para o Nome Do Cliente e assim por diante. Determinar a Chave Primria de cada tabela, sendo que pode haver tabelas onde no exista uma chave primria: Determinar, em cada tabela, quais campos sero utilizados como Chave Primria. Esta uma etapa importantssima para a definio dos Relacionamentos que vem a seguir. Pode haver tabelas onde no exista uma chave primria. Determinar os Relacionamentos: Decidir como os dados de uma tabela se relacionam com os dados de outras tabelas. Por exemplo, Clientes podem Fazer Vrios Pedidos, ento existe um relacionamento do tipo Um-para-vrios entre a tabela Clientes (lado um) e a tabela Pedidos (lado vrios). Fornecedores podem fornecer Vrios Produtos, etc. Refinar a Estrutura do Banco de Dados: Antes de inserir muitos dados, ou at mesmo antes de inserir qualquer dado, verificar se a estrutura contm erros, isto , verificar se os resultados obtidos so os desejados. Isto, normalmente, pode ser obtido atravs do processo de Normalizao. Caso necessrio, deve-se alterar a estrutura do banco de dados.

Com uma boa estrutura, gasta-se menos tempo na construo e manuteno do banco de dados e, ao mesmo tempo, assegura-se resultados mais rpidos e precisos.

Dicas para determinao dos campos de uma Tabela: Relacionar diretamente cada campo ao assunto da tabela: Se um campo descreve o assunto de uma tabela diferente, este campo deve pertencer a outra tabela. O mesmo

acontece quando uma informao se repete em diversas tabelas. Este um indcio de que existem campos desnecessrios em algumas tabelas. No Incluir dados Derivados ou Calculados: No recomendado armazenar o resultado de clculos nas tabelas. O correto que o clculo seja executado quando necessitarmos do resultado, normalmente em uma consulta. Incluir todas as informaes necessrias: Como fcil esquecer informaes importantes, deve-se ter em mente todas as informaes coletadas desde o incio do processo e perguntar se com elas possvel obter todas os resultados desejados. Armazenar todas as informaes separadamente: Existe uma tendncia em armazenar informaes em um nico campo. Por exemplo, o nome do curso e o tempo de durao em uma mesmo campo. Como as duas informaes foram combinadas em um nico campo, ficar difcil conseguir um relatrio classificado pelo tempo de durao dos cursos.

Projetar o banco de dados significa fazer um diagrama Entidade x Relacionamentos onde so indicadas quais tabelas faro parte do banco de dados, quais os campos de cada tabela, qual o campo que ser a Chave Primria nas tabelas que tero Chave Primria e quais os relacionamentos entre as tabelas.

Fases do Projeto de Banco de DadosO projeto de banco dados tem por objetivo transformar as necessidades de informaes no negcio em um banco de dados. Essa tarefa, em geral, realizada em quatro fases: Anlise de requisitos: coleta informaes sobre dados; Projeto conceitual: procura capturar formalmente os requisitos de informao de um banco de dados. Traam-se os principais dados relacionamentos sem se preoucupar com as restries de implementao. Preocupa-se em descrever as informaes contidas em uma realidade. Criao do modelo de entidades e relacionamentos (MER). Projeto lgico: objetiva definir estruturas de dados que implementam os requisitos identificados na modelagem conceitual. Resulta em um esquema lgico de dados sob a tica de uma abordagem (hierrquico, rede, relacional). Direcionamento do projeto para os padres do ambiente de implementao. Entidades, atributos e relacionamentos. Projeto Fsico: define parmetros fsicos de acesso ao banco, procurando otimizar o desempenho do sistema como um todo. Nessa etapa so definidos tipo e tamanho dos campos, ndices, locais de gravao, etc. Representao efetiva dos objetos definidos no projeto lgico para o banco de dados. Tabelas, colunas, chaves e ndices.

ConclusoNo pense que fazer modelagem de dados perda de tempo. Muito pelo contrrio: ganho de tempo e de qualidade em nossos programas.

Modelo Relacional - Diagrama Entidade RelacionamentoFerramenta para modelagem conceitual de banco de dados amplamente utilizada no projeto de banco de dados.

Regras para a criao do Diagrama de Entidade_Relacionamento: Entidades Representao na forma de retngulo com bordas arredondadas; Nome deve ser um ou mais substantivos; Em caso de nome composto por mais de uma palavra, utilizar hfen; Nome da entidade deve ser em letra maiscula; Nome deve ser no singular; No utilizar preposies;

Classificao das entidadesA classificao das entidades feita com base nos atributos utilizados para identific-las. Entidade forte ou primria: so entidadades de dados que possuem alto grau de independncia com relao a existncia e identificao.

So os blocos de dados de maior peso especfico do modelo e podem ter ocorrncias independentes da presena de entidades ou de relacionamentos. Alm da independncia de existncia, normalmente possuem independncia de identificao dada por um ou mais atributos prprios. Entidade fraca ou dependente: a entidadade cuja existncia depende da existncia de outra entidade, que no caso uma entidade forte. Entidade associativa: uma entidade associativa quando a sua existncia est condicionada existncia de duas ou mais entidades, a partir das quais ela concebida, ou seja, resulta da associao de duas ou mais entidades. Seu identificador formado pela concatenao dos identificadores das entidades que se associam para lhe dar origem.

Atributos Os atributos so representados dentro do retngulo de bordas arredondadas que representam a entidade.

O nome de um atributo deve ser no singular. Caso um atributo seja um dos que representam unicamente uma ocorrncia de entidade, ele ser precedido pelo smbolo #. O valor de um atributo, caso ele seja obrigatrio, deve ser informado para cada uma das ocorrncias da entidade e, em sua representao grfica, ser precedido pelo smbolo *; caso ele seja opcional, seu valor pode ser informado para cada uma das ocorrncias da entidade e, em sua representao grfica, precedido pelo smbolo o.

Classificao dos atributos Quanto atomicidade:

- Atributo simples: no tem outros atributos alinhados, apenas seu valor. Ex: nome. - Atributo composto: tem outros atributos alinhados. Ex: endereo.

Quanto ao nmero de ocorrncias:

- Atributo monovalorado: um nico valor para cada instncia. Ex: nome - Atributo multivalorado: mais de um valor para cada entidade. Ex: dependentes, filhos. - Atributo derivado: o seu valor pode ser calculado a partir do valor de outro atributo. Ex: idade.

Quanto participao em chaves:

- Identificao: atributos usados para desempenhar o papel de identificao de entidades e relacionamentos, como chaves primrias e secundrias. - Atributo determinante ou chave: identifica unicamente cada ocorrncia de uma entidade. Ex: cdigo do funcionrio - Conexo ou relacionamento: com o advento do modelo relacional intensificou-se o conceito de chave estrangeira, definida com a presena de uma chave primria ou entidade.

Segundo Keller: Meio: os atributos podem ser internos ou externos. Origem: os atributos podem ser naturais ou artificiais. Privacidade: os atributos podem ser restritos ou pblicos. Derivao: os atributos podem ser primitivos ou derivados. Categoria: os atributos devem ser enquadrados em categorias bsicas de dados como: nome, data, descrio, quantidade etc. Essas categorias so conhecidas como

qualificadores e so utilizadas, em geral, antes do complemento a esses qualificadores. Nomenclatura: Qualificador_nomedescritivo. Formato: os atributos podem ser enquadrados em vrios formatos. Ex: timestamp, varchar.

Domnio o conjunto de valores possveis para um atributo, definindo o universo de valores permitidos para um certo item de dado. Ex: Domnio(ie_sexo) = (masculino, feminino).

RelacionamentosSo associaes entre entidades de dados. Quanto cardinalidade:

- Grau Muitos ::

- Grau Um (Linha pode ser contnua ou tracejada) :: Quanto obrigatoriedade:

- Obrigatoriedade (Linha Contnua) :: - Opcionalidade (Linha Tracejada) ----------------------

Ocorrncia: conjunto de atributos de uma determinada entidade (uma linha dentro de determinada entidade).

Relacionamento: uma correspondncia entre entidades, uma associao entre dois conjunto de dados (entidades).

Identificador ou atributo determinante: um atributo ou uma coleo de atributos que determina de modo nico uma ocorrncia de entidade.

Propriedades de um relacionamentoRelacionamento a associao com nome e significado entre duas entidades ou entre entidades e ela mesma.

NomeUm relacionamento composto pela combinao das propriedades de cardinalidade, opcionalidade e um verbo que represente a ligao de cada uma das entidades para com a outra. Os verbos compem o nome do relacionamento.

OpcionalidadeEsse conceito analisa os relacionamentos pelo lado da obrigatoriedade (ou opcionalidade) das ocorrncias de uma entidade se ligarem as ocorrncias de outra. Opcional

As ocorrncias das entidades que se relacionam so independentes das outras. Contingente

A obrigatoriedade somente por um lado do relacionamento e, por consequencia, somente uma entidade possui independncia em relao outra. Mandatrio

As entidades somente existem se houver o relacionamento entre elas.

Auto-relacionamento o relacionamento estabelecido entre uma entidade e ela mesma.

Relacionamento no transfervelExistem alguns relacionamentos que uma vez conectados no podem ser mais conectados com outras instncias da referida entidade. Essa relao representada por um pequeno losango no relacionamento.

Identificao de relacionamentosA descoberta dos relacionamentos existentes entre as entidades realizada pelo analista e usurio, obedecendo-se as seguintes etapas: Individualizar uma ocorrncia de uma entidade que integra o modelo; Questionar se h algum relacionamento entre a ocorrncia da entidade de origem com outra entidade do modelo (entidade de destino); No caso de existncia do relacionamento, batiz-lo conforme apresentado; Ao criar o relacionamento, atribuir o nome que expresse o significado da associao entre as entidades envolvidas; O relacionamento deve obedecer a um critrio de significncia, ou seja, no devem ser descritos relacionamentos que sejam pouco importantes no mbito do sistema.