Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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.
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.
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.
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?
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.
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.
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.
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.
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.
Concluso
No pense que fazer modelagem de dados perda de tempo. Muito pelo contrrio: ganho de tempo e de qualidade em nossos programas.
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.
- Atributo simples: no tem outros atributos alinhados, apenas seu valor. Ex: nome. - Atributo composto: tem outros atributos alinhados. Ex: endereo.
- 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.
- 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).
Relacionamentos
So associaes entre entidades de dados. Quanto cardinalidade:
- Grau Muitos ::
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 relacionamento
Relacionamento a associao com nome e significado entre duas entidades ou entre entidades e ela mesma.
Nome
Um 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.
Opcionalidade
Esse conceito analisa os relacionamentos pelo lado da obrigatoriedade (ou opcionalidade) das ocorrncias de uma entidade se ligarem as ocorrncias de outra. Opcional
A obrigatoriedade somente por um lado do relacionamento e, por consequencia, somente uma entidade possui independncia em relao outra. Mandatrio
Auto-relacionamento
o relacionamento estabelecido entre uma entidade e ela mesma.
Relacionamento no transfervel
Existem 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 relacionamentos
A 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.