Auto Relacionamento M:N ?
Um item deve ser comparado com outro item para saber qual tem o preço mais barato. Um item pode não ter sido comparado com nenhum outro item. O produto pode ser comparado com muitos outros e pode ter sido comparado por muitos outros.
Pessoal, alguém me ajuda, como eu representaria no modelo logico um auto relacionamento M:N com a notação do pé de galinha?
Eu fiz dessa forma no Toad Data Modeler, ta certo?
Aproveitando o momento, é certo dizer que esse é a representação do Pé de galinha? Esse tipo de representação não seria usada apenas no modelo conceitual?
[img]http://arquivo.devmedia.com.br/forum/imagem/280177-20151116-190049.png[/img]
Pessoal, alguém me ajuda, como eu representaria no modelo logico um auto relacionamento M:N com a notação do pé de galinha?
Eu fiz dessa forma no Toad Data Modeler, ta certo?
Aproveitando o momento, é certo dizer que esse é a representação do Pé de galinha? Esse tipo de representação não seria usada apenas no modelo conceitual?
[img]http://arquivo.devmedia.com.br/forum/imagem/280177-20151116-190049.png[/img]
Hugo Thomaz
Curtidas 0
Respostas
Alan Mario
16/11/2015
M:N estranho pra mim, eu conheço o N:N, N:1...
GOSTEI 0
Hugo Thomaz
16/11/2015
Tb achei estranho mas nos documentos e tutorias que estou estudando tratam n:n como m:n inclusive no curso de Modelagem de Dados daqui do devmedia.
Mas alguém pode ajudar?
Mas alguém pode ajudar?
GOSTEI 0
Marcos P
16/11/2015
Hugo,
N:N ou M:N, são siglas que representam a relação muitos:para:muitos. Nada de errado, nisso !
No seu exemplo, relacionado a produtos, repare que você usa o termo "comparado" várias vezes.
Comparar não implica, necessariamente, em um relacionamento de dados que precise ser modelado fisicamente nas tabelas.
Explico melhor : comparar preços é baseado em uma pesquisa de dados e não em relacionamento explícito de dados. A diferença pode não parecer muito importante, mas pense que a pesquisa ( de comparação ) vai acabar sendo sempre um relacionamento ( 1 : N ), pois você quer comparar o preço corrente ( 1 ), com todos os demais preços da mesma tabela ( N ).
Um relacionamento muitos:para:muitos, parte do pressuposto que a chave primária da tabela, será usada como chave estrangeira na mesma tabela. Isso não é recomendado e deve ser evitado, conforme as regras de normalização de dados.
Nesse post do DevMedia, temos um outro exemplo dessa mesma situação.
OK ?!?
N:N ou M:N, são siglas que representam a relação muitos:para:muitos. Nada de errado, nisso !
No seu exemplo, relacionado a produtos, repare que você usa o termo "comparado" várias vezes.
Comparar não implica, necessariamente, em um relacionamento de dados que precise ser modelado fisicamente nas tabelas.
Explico melhor : comparar preços é baseado em uma pesquisa de dados e não em relacionamento explícito de dados. A diferença pode não parecer muito importante, mas pense que a pesquisa ( de comparação ) vai acabar sendo sempre um relacionamento ( 1 : N ), pois você quer comparar o preço corrente ( 1 ), com todos os demais preços da mesma tabela ( N ).
Um relacionamento muitos:para:muitos, parte do pressuposto que a chave primária da tabela, será usada como chave estrangeira na mesma tabela. Isso não é recomendado e deve ser evitado, conforme as regras de normalização de dados.
Nesse post do DevMedia, temos um outro exemplo dessa mesma situação.
OK ?!?
GOSTEI 0
Hugo Thomaz
16/11/2015
Mas ai para não infligir a 3FN eu teria que criar uma nova tabela caso contrario eu teria um campo que não dependeria da chave primaria (Dependência Funcional Transitiva).
Por isso fiz como esta no desenho no Post que coloquei para ilustrar.
Eu estou com insegurança que com duvidas isso porque estou parado a muito tempo e voltei a estudar a um tempinho. Na verdade nunca exerci a profissão de programador e como estou fazendo e estudando sozinho estou cuidando da analises, engenharia do software, engenharia de bando de dados e desenvolvendo o software, até mesmo de forma didática para eu saber um pouco de cada área. Mas sozinho da uma insegurança e duvida. Mas acho que ja encontrei o caminho das pedras.
Nessa situação que postei foi por conta da ferramenta que estou usando que é a Toad Data Modeler que é a melhor que achei para gerar o DDL para um banco SQLite, ela tem uma notação de cardinalidade e relacionamento um pouco confusa mas encontrei um documento no site deles que explica bem como funciona.
Marcos, Vlw, Obrigado pela ajuda.
Por isso fiz como esta no desenho no Post que coloquei para ilustrar.
Eu estou com insegurança que com duvidas isso porque estou parado a muito tempo e voltei a estudar a um tempinho. Na verdade nunca exerci a profissão de programador e como estou fazendo e estudando sozinho estou cuidando da analises, engenharia do software, engenharia de bando de dados e desenvolvendo o software, até mesmo de forma didática para eu saber um pouco de cada área. Mas sozinho da uma insegurança e duvida. Mas acho que ja encontrei o caminho das pedras.
Nessa situação que postei foi por conta da ferramenta que estou usando que é a Toad Data Modeler que é a melhor que achei para gerar o DDL para um banco SQLite, ela tem uma notação de cardinalidade e relacionamento um pouco confusa mas encontrei um documento no site deles que explica bem como funciona.
Marcos, Vlw, Obrigado pela ajuda.
GOSTEI 0
Marcos P
16/11/2015
Hugo,
Lembre-se : aplicação das regras de normalização de dados dependem sempre do cenário a ser desenvolvido !
Elas não são um dogma !
Adapte-as ao seu uso e necessidade...
Inclusive, existem diversos autores que pregam a "desnormalização" dos modelos de dados como solução para problemas de performance em grandes sistemas.
Entender a teoria é importante, mas aplicá-la conforme a necessidade de cada projeto é fundamental.
Boa sorte !
Lembre-se : aplicação das regras de normalização de dados dependem sempre do cenário a ser desenvolvido !
Elas não são um dogma !
Adapte-as ao seu uso e necessidade...
Inclusive, existem diversos autores que pregam a "desnormalização" dos modelos de dados como solução para problemas de performance em grandes sistemas.
Entender a teoria é importante, mas aplicá-la conforme a necessidade de cada projeto é fundamental.
Boa sorte !
GOSTEI 0
Hugo Thomaz
16/11/2015
Hugo,
Lembre-se : aplicação das regras de normalização de dados dependem sempre do cenário a ser desenvolvido !
Elas não são um dogma !
Adapte-as ao seu uso e necessidade...
Inclusive, existem diversos autores que pregam a "desnormalização" dos modelos de dados como solução para problemas de performance em grandes sistemas.
Entender a teoria é importante, mas aplicá-la conforme a necessidade de cada projeto é fundamental.
Boa sorte !
Lembre-se : aplicação das regras de normalização de dados dependem sempre do cenário a ser desenvolvido !
Elas não são um dogma !
Adapte-as ao seu uso e necessidade...
Inclusive, existem diversos autores que pregam a "desnormalização" dos modelos de dados como solução para problemas de performance em grandes sistemas.
Entender a teoria é importante, mas aplicá-la conforme a necessidade de cada projeto é fundamental.
Boa sorte !
Mais uma vez obrigado Marcos, vlw pelas dicas!!!!
GOSTEI 0