Primeiro, a interface do usuário: como usuário eu odeio para pesquisar um produto em um catálogo organizado em um estritamente hierárquico maneira. Eu nunca me lembro em que sub-sub-sub-sub...-categoria um produto "exótico" está e isso me força a perder tempo explorando categorias "promissoras" apenas para descobrir que ele é categorizado em (para mim, pelo menos ) caminho estranho.
O que Kevin Peno sugere é um bom conselho e é conhecido como navegação facetada . Como Marcia Bates escreveu em Depois da Dot-Bomb :Obtendo a recuperação de informações da Web desta vez , " .. classificação facetada está para classificação hierárquica como bancos de dados relacionais estão para bancos de dados hierárquicos. .. ".
Em essência, a pesquisa facetada permite que os usuários pesquisem seu catálogo a partir de qualquer "faceta" que preferirem e permitem que eles filtrem informações escolhendo outras facetas ao longo da pesquisa. Observe que, ao contrário de como os sistemas de tags geralmente são concebidos, nada impede que você organize algumas dessas facetas hierarquicamente.
Para entender rapidamente do que se trata a pesquisa facetada, existem algumas demonstrações para explorar em Projeto de Interface de Pesquisa Flamenco - Interfaces de Pesquisa que Fluem .
Segundo, a lógica do aplicativo: o que Manitra propõe também é um bom conselho (como eu o entendo), ou seja, separar
nodes e links de uma árvore/grafo em diferentes relações. O que ele chama de "tabela ancestral" (que é um nome intuitivo muito melhor, no entanto) é conhecido como fechamento transitivo de um grafo acíclico direcionado (DAG)
(relação de acessibilidade). Além do desempenho, simplifica bastante as consultas, como disse Manitra. Mas Sugiro uma visualização para tal "tabela ancestral" (fechamento transitivo), para que as atualizações sejam em tempo real e incrementais, não periódicas por um trabalho em lote. Existe código SQL (mas acho que precisa ser adaptado um pouco para DBMSes específicos) em artigos que mencionei na minha resposta para linguagem de consulta para conjuntos de gráficos:questão de modelagem de dados . Em particular, veja Manter fechamento transitivo de gráficos em SQL (.ps - pós-escrito).
Relação produtos-categorias
O primeiro ponto do Manitra também merece destaque.
O que ele está dizendo é que entre produtos e categorias existe uma relação de muitos para muitos. Ou seja:cada produto pode estar em uma ou mais categorias e em cada categoria pode haver zero ou mais produtos.
Dadas variáveis de relação (relvars) Produtos e Categorias tal relacionamento pode ser representado, por exemplo, como um PC relvar com pelo menos atributos P# e C#, ou seja, números de produto e categoria (identificadores) em relacionamentos de chave estrangeira com Produtos e Categorias correspondentes números.
Isso é complementar ao gerenciamento das hierarquias das categorias. Claro, este é apenas um esboço de design.
Na navegação facetada no SQL
Um conceito útil para implementar "navegação facetada" é divisão relacional , ou, ainda, comparações relacionais (veja a parte inferior da página vinculada). Ou seja dividindo PC (Produtos-Categorias) por uma lista (crescente) de categorias escolhidas de um usuário (navegação de facetas) obtém-se apenas produtos em tais categorias (claro, as categorias são presumidas não todas mutuamente exclusivas, caso contrário, escolhendo duas categorias, uma obterá zero produtos).
Os SGBDs baseados em SQL geralmente carecem desses operadores (divisão e comparações), então apresento abaixo alguns trabalhos interessantes que os implementam/discutem:
- PARA TORNAR A DIVISÃO RELACIONAL COMPREENSÍVEL (.pdf de Índice de sessão FIE 2003 );
- Uma abordagem SQL mais simples (e melhor) para a divisão relacional (.pdf do Journal of Information Systems Education - Conteúdo Volume 13, Número 2 (2002) );
- Processamento de consultas frequentes de descoberta de conjuntos de itens por divisão e operadores de junção de contenção de conjunto ;
- Leis para reescrever consultas contendo operadores de divisão ;
- Algoritmos e aplicativos para quantificação universal em bancos de dados relacionais;
- Otimização de consultas com quantificação universal em orientação a objetos e Bancos de dados relacionais de objeto ;
- (acesso ACM obrigatório) Sobre a complexidade da divisão e junções de conjuntos no relacional álgebra ;
- (acesso ACM obrigatório) Algoritmos rápidos para quantificação universal em grandes bancos de dados;
e assim por diante...
Não entrarei em detalhes aqui, mas a interação entre hierarquias de categorias e navegação de facetas precisa de cuidados especiais.
Uma digressão sobre "planicidade"
Analisei brevemente o artigo vinculado por Pras , Gerenciando dados hierárquicos no MySQL , mas parei de ler depois dessas poucas linhas na introdução:
Para entender por que essa insistência na planicidade das relações é simplesmente sem sentido , imagine um cubo em um sistema de coordenadas cartesianas tridimensionais :será identificado por 8 coordenadas (trigêmeas), digamos P1(x1,y1,z1), P2(x2,y2,z2), ..., P8(x8, y8, z8) [aqui não estamos preocupados com restrições sobre essas coordenadas para que elas representem realmente um cubo].
Agora, vamos colocar esse conjunto de coordenadas (pontos) em uma variável de relação e nomearemos essa variável
Points . Nós representaremos o valor da relação de Points conforme tabela abaixo:Points| x | y | z |
=======+====+====+====+
| x1 | y1 | z1 |
+----+----+----+
| x2 | y2 | z2 |
+----+----+----+
| .. | .. | .. |
| .. | .. | .. |
+----+----+----+
| x8 | y8 | z8 |
+----+----+----+
Este cubo está sendo “achatado” pelo simples ato de representá-lo de forma tabular? Uma relação (valor) é a mesma coisa que sua representação tabular?
Uma variável de relação assume como valores conjuntos de pontos em um espaço discreto n-dimensional, onde n é o número de atributos de relação ("colunas"). O que significa, para um espaço discreto n-dimensional, ser "plano"? Apenas um disparate, como escrevi acima.
Não me entenda mal, certamente é verdade que SQL é uma linguagem mal projetada e que DBMSs baseados em SQL estão cheios de idiossincrasias e deficiências (NULLs, redundância, ...), especialmente as ruins, o DBMS-as- tipo de armazenamento mudo (sem restrições referenciais, sem restrições de integridade, ...). Mas isso não tem nada a ver com as limitações fantasiadas do modelo de dados relacional, pelo contrário:mais eles se afastam dele e pior é o resultado.
Em particular, o modelo de dados relacional, uma vez entendido, não apresenta nenhum problema em representar qualquer estrutura, mesmo hierarquias e gráficos, como detalhei com referências a artigos publicados mencionados acima. Mesmo o SQL pode, se você encobrir suas deficiências, perder algo melhor.
No "Modelo de conjunto aninhado"
Eu dei uma olhada no resto desse artigo e não estou particularmente impressionado com esse design lógico:ele sugere confundir duas entidades diferentes, nós e links , em uma relação e isso provavelmente causará constrangimento. Mas não estou inclinado a analisar esse projeto mais detalhadamente, desculpe.
EDITAR: Stephan Eggermont objetou, nos comentários abaixo, que "O modelo de lista plana é um problema. É uma abstração da implementação que dificulta o desempenho do desempenho. ... ".
Agora, meu ponto é, precisamente, que:
- este "modelo de lista simples" é uma fantasia :só porque um layout (representa) relações como tabelas ("listas planas") não significa que as relações sejam "listas planas" (um "objeto" e suas representações não são a mesma coisa);
- uma representação lógica (relação) e detalhes de armazenamento físico (decomposições horizontais ou verticais, compactação, índices (hashes, b+tree, r-tree, ...), agrupamento, particionamento, etc.) são distintos; um dos pontos do modelo de dados relacional (RDM ) é desacoplar o modelo lógico do "físico" (com vantagens tanto para usuários quanto para implementadores de SGBDs);
- o desempenho é uma consequência direta dos detalhes do armazenamento físico (implementação) e não de representação lógica (o comentário de Eggermont é um exemplo clássico de confusão lógico-física ).
O modelo RDM não restringe implementações de forma alguma; um é livre para implementar tuplas e relações como achar melhor. As relações não são necessariamente arquivos e tuplas são não necessariamente registros de um arquivo. Essa correspondência é uma implementação de imagem direta burra .
Infelizmente, as implementações de DBMS baseadas em SQL são , muitas vezes, implementações de imagem direta idiotas e elas sofrem desempenho ruim em vários cenários - OLAP /ETL existem produtos para cobrir essas deficiências.
Isso está mudando lentamente. Existem implementações comerciais e de software livre/código aberto que finalmente evitam essa armadilha fundamental:
- Vertica , que é um sucessor comercial de..
- C-Store:um SGBD orientado a colunas ;
- MonetDB ;
- LucidDB ;
- Kdb de alguma forma;
- e assim por diante...
Claro, o ponto é não que deve existir um design de armazenamento físico "ótimo", mas que qualquer design de armazenamento físico pode ser abstraído por uma boa linguagem declarativa baseado em álgebra/cálculos relacional (e SQL é um ruim exemplo) ou mais diretamente em uma linguagem de programação lógica (como Prolog, por exemplo - veja minha resposta para "conversor de prólogo para SQL " questão). Um bom SGBD deve mudar o design do armazenamento físico em tempo real, com base nas estatísticas de acesso aos dados (e/ou dicas do usuário).
Finalmente, no comentário de Eggermont, a afirmação "O modelo relacional está sendo espremido entre a nuvem e o prevalecente. " é outra bobagem mas não posso dar uma refutação aqui, este comentário já é muito longo.
