Modelo Conceitual vs Modelo Lógico -
Acessibilidade Banco de Dados
PorThiago Ferreira em	16/10/2007
Quanto há um relacionamento "um-para-muitos", a entidade do lado "N" recebe como atributo a chave primária da entidade do lado "um".
Caso haja dependência de existência entre as entidades, ou seja, uma entidade só possa existir se a outra existir, a chave primária da entidade do lado "um" passa a ser chave primária (e estrangeira) da entidade do lado "N", juntamente com a chave primária dessa entidade. Ou seja, uma chave primária composta, na entidade do lado "N".
Um aluno tem aulas de nenhuma ou várias disciplinas e uma disciplina é cursada por nenhum ou vários alunos.
Num relacionamento "muitos-para-muitos", é preciso criar uma tabela intermediária que terá como chave primária composta as chaves primárias das outras duas tabelas.
Nessa tabela intermediária, você pode colocar atributos que identifiquem a relação entre as entidades. Exemplo: ano e semestre que o aluno está cursando a disciplina.
Auto-relacionamento "um-para-muitos"
Um funcionário supervisiona nenhum ou vários funcionários e um funcionário tem somente um supervisor.
A própria entidade recebe como atributo a sua própria chave primária.
Auto-relacionamento "muitos-para-muitos"
Um aluno só poderá cursar a disciplina X se tiver sido aprovado nas disciplinas A e B. E só poderá cursar a disciplina Y se tiver sido aprovado na disciplina A.
No contexto, podemos ver que a disciplina A é pré-requisito de X e Y. E a disciplina B é pré-requisito para X.
Nesse caso, criamos uma tabela que armazenará os relacionamentos entre as disciplinas. E essa tabela terá como chave primária composta a chave primária da outra tabela (duas vezes).
Relacionamento Generalização/Especialização
Precisamos armazenar o código de identificação, cor e capacidade de passageiros dos veículos que possuímos.
Para os veículos terrestres, é interessante armazenarmos a quantidade de rodas. Para os aquáticos, o tamanho em pés. Para os aéreos, a forma de propulsão (turbina, hélice, etc).
Nesse caso, temos que os atributos código de identificação, cor e capacidade de passageiros é comum para todos os tipos de veículos, mas que temos diferenças significativas de um tipo para o outro.
Se fizéssemos somente 3 tabelas (uma para cada tipo), teríamos que repetir os campos em comum. Em princípio, isso é errado! O correto é colocarmos os atributos comuns numa tabela abstrata e nas tabelas mais concretas somente os atributos inerentes a ela.
Existem outros tipos de relacionamento, como agregação e ternário, mas não são muito comuns e por isso não tratarei.
Modelagem de banco de dados não é uma ciência exata, assim como outros tipos de modelagem.
Portanto, não há verdade absoluta.
Essas regras podem mudar de caso para caso. Mas é preciso que tenhamos atenção para "quando" quebrar essas regras. Precisamos ser muito criteriosos e fazer testes.
Acredito que esse artigo seja muito útil para muita gente. A quantidade de erros de modelagem que vejo diariamente é espantosa e só acontecem por falta de conhecimento destas e de outras regras de modelagem de banco de dados.
Caso tenham dúvidas ou comentários, sugestões, críticas, etc, por favor, postem abaixo!
Thiago, vc acha que o trabalho dos DBA´s pode ou está sendo ameaçado pelo frameworks ORM? Pois eles fazem todo o mapeamento do banco, coisa que o programador pode implementar…
20 de outubro de 2007 às 23:15
Emerson, o trabalho de um DBA é muito mais do que a modelagem do banco. Além disso, há certas peculiaridades que os sistemas não "entregam prontas", pois dependem de análise e experiência. Eu penso que os DBAs tendem a ter cada vez mais destaque num mundo sedento de informações rápidas e precisas.
Natalia Brizzi Camandona disse:
6 de junho de 2008 às 9:24
Thiago Ferreira, bom dia!
Tudo bem, gostaria de pedir um favor, tenho um trabalho para entregar ainda hoje de modelo conceitual e lógico referente a um açougue, o modelo conceitual eu ja fiz só não fiz o Lógico, será que vc poderia me dar uma forcinha? anota meu email: camandona@hotmail.com
pode mandar que posso te ajudar cara
É exatamente tudo que eu precisava, eu ainda tinha algumas duvidas relacionadas a modelagem de bd, inclusive hoje tenho uma prova sobre a mesma.
Muito bom o artigo, simples e didático!!
eu estou a criar um banco de dados sobre gestao de clientes e activacao de servicos de uma empresa de telecomunicacao.
tem as seguintes entidades e atributos:
1-Cliente(n da identificacao,nome,endereco),
2-numero[telefonico](id, serie do numero,n da identificacao, serial number ),
3-telemovel(serial number, marca, sistema, cor),
4-servicos(nome do servico, descricao)
eu acho que esta muito simples pelo titulo do trabalho, gostaria que me ajudasse nesse sentido, pfv
prezados amigos eu adorei este comentarios deste forum
Não entendi bem a parte do reladionamento generalização, os outros estão ótimos
15 de Março de 2011 às 6:22
Conseguimos entender melhor com a prática, mas já valeu a leitura deste artigo.
Caroline Thayane Ferreira. disse:
Olha Thiago Ferreira, Obrigada pela explica, foi mehor que a do professor.
att Caroline Thayane Ferreira.
olá …. muito boa a explicação……
sobre os DBAs eu concordo plenamente sobre o que você expôs……. pois são profissionais altamente capacitados em banco de dados…
vlw …. foi de grande ajuda para meus estudos pra prova de hoje….!!!
26 de julho de 2013 às 9:42
Thiago, primeiramente, temos divisões nas áreas de TI nos dias atuais, é como se você tivesse, por exemplo, falando para um médico da área pediátrica realizar um exame que deveria ser feito por um profissional da área oftalmológica, somente pelo fato de pertencerem à área da saúde. Cada um tem seu papel, especialidade e conhecimento para a construção de um sistema seguro e consistente. O desenvolvedor não poder ser totalmente responsável por fazer todas às analises, documentações e elaborações de um sistema, esses conceitos de entidade relacional e conceitual devem ser direcionados também pros analistas de banco de dados (DBA's) juntamente com os analistas de requisitos, que depois de serem feitos essas analises devesse passar pros analistas de sistemas darem um aval do que possa ser realizado e por último passar pro desenvolvedor verificar se é ou não possível desenvolver com aquelas informações levantadas e exigir um prazo para o desenvolvimento do serviço proposto, esse tipo de trabalho deve ser feito em conjunto pelos profissionais de TI, pois a "união faz a força", hoje o que vejo são DBA's se achando o bam bam bam e ficando somente com a responsabilidade de fazerem backups, recuperar o backups e migrarem os dados de um servidor pra outro, não fazem mais analise nenhum, pelo menos nos órgãos públicos só ficam repassando trabalho para os terceirizados ou repassa as responsabilidades deles para os administradores de banco de dados que seria a realização das analises de inconsistência, duplicidade do banco e performance, mas mesmo assim, colocam gente sem competência nenhum para fazer o papel de administrador que e por fim repassam para as mãos dos analistas de sistemas que por sua vez tacam nas costas do desenvolvedores para avaliarem os dados do banco e fazerem levantamentos e proporem soluções para resolver a questão dos dados do banco, ou seja, no final das contas o desenvolvedor é o que faz tudo pra que o sistema funcione, por isso, acho que dar conselhos ou ensinamentos pra desenvolvedores não é a solução, temos que começar com os analistas, pois acho que essa palavra analista já diz tudo, eles analisam o que será feito, se pulam essa etapa, realmente o desenvolvedor não vai ter toda essa gama de conhecimento para desenvolver um sistema sozinho que atenda a todos os requisitos. FAÇAM-ME O FAVOR A TODOS OS PROFISSIONAIS DE TI, COLABOREM, DEIXEM O ORGULHO DE LADO, PAREM DE FICAR REPASSANDO O PROBLEMA OU A RESPONSABILIDADE DE UM PARA O OUTRO E COMECEM A TRABALHAR EM EQUIPE, COMECEM A PROPOR SOLUÇÕES, MELHOR MODELO PARA O TRABALHO EM EQUIPE É O USO DO XP (EXTREME PROGRAMMING).
Meu prof usa seu artigo pra ensina bd a nos!!!mt bom mesmo ele!!!
boa Tarde gostaria de saber um bom livro de Banco de Dados
Perfeita a explicação rapaz… Há muito procurava algo que explicasse bem como funciona os relacionamentos em modelos relacionais e você explicou perfeitamente…
Bom dia Thiago, espero que vc ainda esteja on-line. Parabéns pelo seu artigo, muito bom. Thiago gostaria de lhe pedir uma ajuda pois tenho que entregar um trabalho na faculdade e estou com algumas dúvidas, vc pode me auxiliar.
Meu Email: andrea@andresinformatica.com.br
preciso de uma explicação de como elaborar o modelo lógico se puder fazer isto agradeço….
Jhony Yamamoto disse:
Thiago, muito bom o artigo, adorei, no entanto não consigo entender como é feita essa conversão do modelo conceitual para o lógico. Tenho muita dificuldade em entender BD. Poderia me dar uma força por favor ? fiz uma prova de BD, que no caso eu tinha que converter o modelo conceitual em lógico, até consegui criar as entidades e tals, mas me enrolo na hora de inserir os atributos às entidades. Sei que o relacionamento não preciso inserir no modelo lógico, mas os atributos são essenciais. Segue meu contato, se puder ajudar, Obrigado. Atenciosamente,
6 de dezembro de 2015 às 13:48
jhonyyamamoto@hotmail.com
Aí te envio o print com o exercício que errei na hora de inserir os atributos.
No modelo lógico não se leva em conta as chaves da entidade pai? E para o modelo físico aceitaria um valor nulo para as FKS?
Marine Pimenta disse:
Parabéns, me ajudou muito esse artigo. Obrigada mesmo!
Claudio Fabian disse:
Lex Nascimento disse:
Moss, apenas to passando pra agradecer , pois esse material é muito simplificado , e muito didático. Esclareceu muitas duvidas! agradeço
Gostei bastante do seu artigo, muito bem explicado. Uma pena que as imagens não referente as exemplificações não carregam. Seria possível corrigir isso? Ficaria muito mais claro.
Poderia consertar o post? Está sem imagens./
24 Artigos	0 Curtidas	8 Shares
mais conhecido como tmferreira (tmferreira@bol.com.br) e é formado em Análise de Sistemas pela Universidade Salgado de Oliveira. Trabalha desde 2005 com desenvolvimento WEB, na FatorClick (http://www.fatorclick.com.br). Também mantém um blog (http://www.tmferreira.com.br/blog/) sobre desenvolvimento WEB, onde escreve sobre PHP, Javascript, Banco de Dados e Webstandards.